前言

應“雲技術社群”北極熊之邀，寫點東西。思來想去雲端計算範疇實在廣泛，自然就聊點最近話題異常火熱，讓廣大雲端計算從業者愛之深、痛之切，想說一聲愛你，不容易的OpenStack吧。

這裡，僅從技術角度出發，談談OpenStack雲平臺在部署、架構和運維實施等方面的感想。

緣起，在2014年大二首次接觸到OpenStack，當時國內外資料遠沒有當前這麼豐富，為安裝一個OpenStack H版環境（一臺筆記本用VMware Workstation虛擬出2臺虛擬機器）愣是用了1個星期多，最後仍然建立虛擬機器失敗。後來為了學習OpenStack，臨近畢業時特意去上海實習工作，不覺間已經四年了。

OpenStack涉及的東西太多太多，計算、儲存、網路、架構、產品、運維、監控和效能優化、程式碼等等。這裡就各抒已見，談點自己四年以來對OpenStack的理解吧，也算是一個交代，如有差錯，歡迎拍磚。

誠然，一個良好的架構設計和運維保障措施，能為OpenStack雲平臺的穩定健康執行，產生不可估量的積極影響。如果化繁為簡，簡單的來說，要部署一套生產環境級別的OpenStack雲平臺，至少會涉及到四個層次的內容，即物理基礎設施層、儲存層、OpenStack雲服務層和使用者應用層。如下圖所示。

 

物理基礎設施層

首先，從最底層開始說起，即“物理基礎設施層”。一個基本的物理基礎設施IT環境，包括了電力裝置、空調和防火裝置、網路裝置（如交換機、路由器、防火牆、負載均衡裝置等）、儲存裝置和伺服器等。由於專業知識的限制，這裡，只涉及交換機和伺服器方面。一個基本的物理IT環境，如下圖所示。

交換機裝置

一般地，在OpenStack生產環境上，交換機埠應該做聚合（channel）。也就是將2個或多個物理埠組合在一起成為一條邏輯的鏈路從而增加交換機和網路節點之間的頻寬，將屬於這幾個埠的頻寬合併，給埠提供一個幾倍於獨立埠的獨享的高頻寬。Trunk是一種封裝技術，它是一條點到點的鏈路，鏈路的兩端可以都是交換機，也可以是交換機和路由器，還可以是主機和交換機或路由器。

伺服器

網絡卡

OpenStack雲平臺涉及到的網路有管理網路（用於OpenStack各服務之間通訊）、外部網路（提供floating ip）、儲存網路（如ceph儲存網路）和虛機網路（也稱租戶網路、業務網路）四種類型。

對應到每一種網路，伺服器都應該做網絡卡Bond，來提供伺服器網路的冗餘、高可用和負載均衡的能力，根據實際需求，可以選擇模式0或模式1。在網路流量較大的場景下推薦使用bond 0；在可靠性要求較高的場景下推薦使用bond 1。

二者優劣比較。

一般地，在小規模的私有云環境中，網路型別對應的頻寬是：

• 管理網路：千兆網路

• 外部網路：千兆網路

• 儲存網路：萬兆網路

• 租戶網路：千兆網路

 

如果是中大規模的私有云或公有云環境，則推薦儘量都使用萬兆網路。

硬碟

伺服器作業系統使用的系統盤，應該用2塊硬碟來做RAID 1，以提供系統儲存的高可靠性。且推薦使用高效能且成本可控的SAS硬碟，以提高作業系統、MySQL資料庫和Docker容器（如果使用kolla部署openstack）的IO儲存效能。

CPU

OpenStack各計算節點的CPU型號，必須一致，以保證虛擬機器的遷移功能正常可用等。

記憶體

OpenStack各計算節點的記憶體大小，應該一致，以保證虛擬機器建立管理的均衡排程等。同時，主機的Swap交換分割槽，應該科學合理的設定，不能使用系統預設建立的。

資料中心中少部分機器用於做控制節點，大部分機器都是需要執行虛擬化軟體的，虛擬化平臺上有大量的VM，而宿主機本身的系統也會跑一些服務，那麼這就勢必會造成vm之間資源搶佔，vm與宿主機系統之間的資源搶佔，我們需要通過設定規則，讓他們在各自的界限內高效執行，減少衝突搶佔。

我們可以讓宿主機執行作業系統時候，更多的選擇指定的幾個核，這樣就不會過多搶佔虛擬化中虛機的vcpu排程，通過修改核心啟動引數我們可以做到:

修改 /etc/default/grub檔案，讓系統只使用前三個核 隔離其餘核。

GRUB_CMDLINE_LINUX_DEFAULT="isolcpus=4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31"

更新核心引數

# update-grub

# rboot

記憶體配置方面，網易私有云的實踐是關閉 KVM 記憶體共享，開啟透明大頁：

echo 0 > /sys/kernel/mm/ksm/pages_shared

echo 0 > /sys/kernel/mm/ksm/pages_sharing

echo always > /sys/kernel/mm/transparent_hugepage/enabled

echo never > /sys/kernel/mm/transparent_hugepage/defrag

echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

據說，經過 SPEC CPU2006 測試，這些配置對雲主機 CPU 效能大概有7%左右的提升。

 

OpenStack雲平臺層

雲平臺高可用（HA）

高可用（HA）介紹

高可用性是指提供在本地系統單個元件故障情況下，能繼續訪問應用的能力，無論這個故障是業務流程、物理設施、IT軟/硬體的故障。最好的可用性， 就是你的一臺機器宕機了，但是使用你的服務的使用者完全感覺不到。你的機器宕機了，在該機器上執行的服務肯定得做故障切換（failover），切換有兩個維度的成本：RTO （Recovery Time Objective）和 RPO（Recovery Point Objective）。RTO 是服務恢復的時間，最佳的情況是 0，這意味著服務立即恢復；最壞是無窮大意味著服務永遠恢復不了；RPO 是切換時向前恢復的資料的時間長度，0 意味著使用同步的資料，大於 0 意味著有資料丟失，比如 ” RPO = 1 天“ 意味著恢復時使用一天前的資料，那麼一天之內的資料就丟失了。因此，恢復的最佳結果是 RTO = RPO = 0，但是這個太理想，或者要實現的話成本太高。

對 HA 來說，往往使用分散式儲存，這樣的話，RPO =0 ；同時使用 Active/Active （雙活叢集） HA 模式來使得 RTO 幾乎為0，如果使用 Active/Passive HA模式的話，則需要將 RTO 減少到最小限度。HA 的計算公式是[ 1 - (宕機時間)/（宕機時間 + 執行時間）]，我們常常用幾個 9 表示可用性：

• 2 個9：99% = 1% 365 = 3.65 24 小時/年 = 87.6 小時/年的宕機時間

• 4 個9: 99.99% = 0.01% 365 24 * 60 = 52.56 分鐘/年

• 5 個9：99.999% = 0.001% * 365 = 5.265 分鐘/年的宕機時間，也就意味著每次停機時間在一到兩分鐘。

• 11 個 9：幾年宕機幾分鐘。

 

服務的分類

HA 將服務分為兩類：

• 有狀態服務：後續對服務的請求依賴於之前對服務的請求。OpenStack中有狀態的服務包括MySQL資料庫和AMQP訊息佇列。對於有狀態類服務的HA，如neutron-l3-agent、neutron-metadata-agent、nova-compute、cinder-volume等服務，最簡便的方法就是多節點部署。比如某一節點上的nova-compute服務掛了，也並不會影響到整個雲平臺不能建立虛擬機器，或者所在節點的虛擬機器無法使用（比如ssh等）。

• 無狀態服務：對服務的請求之間沒有依賴關係，是完全獨立的，基於冗餘例項和負載均衡實現HA。OpenStack中無狀態的服務包括nova-api、nova-conductor、glance-api、keystone-api、neutron-api、nova-scheduler等。由於API服務，屬於無狀態類服務，天然支援Active/Active HA模式。因此，一般使用 keepalived +HAProxy方案來做。

 

HA 的種類

HA 需要使用冗餘的伺服器組成叢集來執行負載，包括應用和服務。這種冗餘性也可以將 HA 分為兩類：

• Active/Passive HA：即主備HA。在這種配置下，系統採用主和備用機器來提供服務，系統只在主裝置上提供服務。在主裝置故障時，備裝置上的服務被啟動來替代主裝置提供的服務。典型地，可以採用 CRM 軟體比如 Pacemaker 來控制主備裝置之間的切換，並提供一個虛擬 IP 來提供服務。

• Active/Active HA：即主主HA，包括多節點時成為多主（Multi-master）。在這種配置下，系統在叢集內所有伺服器上運行同樣的負載。以資料庫為例，對一個例項的更新，會被同步到所有例項上。這種配置下往往採用負載均衡軟體比如 HAProxy 來提供服務的虛擬 IP。

 

OpenStack雲環境高可用（HA）

雲環境是一個廣泛的系統，包括了基礎設施層、OpenStack雲平臺服務層、虛擬機器和終端使用者應用層。

 

雲環境的 HA 包括：

• 使用者應用的 HA

• 虛擬機器的 HA

• OpenStack雲平臺服務的 HA

• 基礎設施層的HA：電力、空調和防火設施、網路裝置（如交換機、路由器）、伺服器裝置和儲存裝置等

 

僅就OpenStack雲平臺服務（如nova-api、nova-scheduler、nova-compute等）而言，少則幾十，多則上百個。如果某一個服務掛了，則對應的功能便不能正常使用。因此，如何保障整體雲環境的HA高可用，便成為了架構設計和運維的重中之重。

OpenStack HA高可用架構，如下圖所示。

 

如果，從部署層面來劃分，OpenStack高可用的內容包括：

• 控制節點（Rabbitmq、mariadb、Keystone、nova-api等）

• 網路節點（neutron_dhcp_agent、neutron_l3_agent、neutron_openvswitch_agent等）

• 計算節點（Nova-Compute、neutron_openvswitch_agent、虛擬機器等）

• 儲存節點（cinder-volume、swift等）

 

控制節點HA

在生產環境中，建議至少部署三臺控制節點，其餘可做計算節點、網路節點或儲存節點。採用Haproxy + KeepAlived方式，代理資料庫服務和OpenStack服務，對外暴露VIP提供API訪問。

 

MySQL資料庫HA

mysql 的HA 方案有很多，這裡只討論openstack 官方推薦的mariadb Galara 叢集。Galera Cluster 是一套在innodb儲存引擎上面實現multi-master及資料實時同步的系統架構，業務層面無需做讀寫分離工作，資料庫讀寫壓力都能按照既定的規則分發到各個節點上去。特點如下：
1）同步複製，（>=3）奇數個節點
2）Active-active的多主拓撲結構
3）叢集任意節點可以讀和寫
4）自動身份控制,失敗節點自動脫離叢集
5）自動節點接入
6）真正的基於”行”級別和ID檢查的並行複製
7）無單點故障,易擴充套件

採用MariaDB + Galera方案部署至少三個節點（最好節點數量為奇數），外部訪問通過Haproxy的active + backend方式代理。平時主庫為A，當A出現故障，則切換到B或C節點。如下圖所示。

 

RabbitMQ 訊息佇列HA

RabbitMQ採用原生Cluster叢集方案，所有節點同步映象佇列。小規模環境中，三臺物理機，其中2個Mem節點主要提供服務，1個Disk節點用於持久化訊息，客戶端根據需求分別配置主從策略。據說使用ZeroMQ代替預設的RabbitMQ有助於提升叢集訊息佇列效能。

OpenStack API服務HA

OpenStack控制節點上執行的基本上是API 無狀態類服務，如nova-api、neutron-server、glance-registry、nova-novncproxy、keystone等。因此，可以由 HAProxy 提供負載均衡，將請求按照一定的演算法轉到某個節點上的 API 服務，並由KeepAlived提供 VIP。

網路節點HA

網路節點上執行的Neutron服務包括很多的元件，比如 L3 Agent，openvswitch Agent，LBaas，VPNaas，FWaas，Metadata Agent 等，其中部分元件提供了原生的HA 支援。

• Openvswitch Agent HA： openvswitch agent 只在所在的網路或者計算節點上提供服務，因此它是不需要HA的

• L3 Agent HA：成熟主流的有VRRP 和DVR兩種方案

• DHCP Agent HA：在多個網路節點上部署DHCP Agent，實現HA

• LBaas Agent HA：Pacemaker + 共享儲存（放置 /var/lib/neutron/lbaas/ 目錄） 的方式來部署 A/P 方式的 LBaas Agent HA

 

儲存節點HA

儲存節點的HA，主要是針對cinder-volume、cinder-backup服務做HA，最簡便的方法就是部署多個儲存節點，某一節點上的服務掛了，不至於影響到全域性。

 

計算節點和虛擬機器 HA

計算節點和虛擬機器的HA，社群從2016年9月開始一直致力於一個虛擬機器HA的統一方案，但目前仍然沒有一個成熟的方案。實現計算節點和虛擬機器HA，要做的事情基本有三件，即。

 

① 監控

監控主要做兩個事情，一個是監控計算節點的硬體和軟體故障。第二個是觸發故障的處理事件，也就是隔離和恢復。

OpenStack 計算節點高可用，可以用pacemaker和pacemaker_remote來做。使用pacemaker_remote後，我們可以把所有的計算節點都加入到這個叢集中，計算節點只需要安裝pacemaker_remote即可。pacemaker叢集會監控計算節點上的pacemaker_remote是否 “活著”，你可以定義什麼是“活著”。比如在計算節點上監控nova-compute、neutron-ovs-agent、libvirt等程序，從而確定計算節點是否活著，亦或者租戶網路和其他網路斷了等。如果監控到某個pacemaker_remote有問題，可以馬上觸發之後的隔離和恢復事件。

 

② 隔離

隔離最主要的任務是將不能正常工作的計算節點從OpenStack叢集環境中移除，nova-scheduler就不會在把create_instance的message發給該計算節點。

Pacemaker 已經集成了fence這個功能，因此我們可以使用fence_ipmilan來關閉計算節點。Pacemaker叢集中fence_compute 會一直監控這個計算節點是否down了，因為nova只能在計算節點down了之後才可以執行host-evacuate來遷移虛擬機器，期間等待的時間稍長。這裡有個更好的辦法，就是呼叫nova service-force-down 命令，直接把計算節點標記為down，方便更快的遷移虛擬機器。

 

③ 恢復

恢復就是將狀態為down的計算節點上的虛擬機器遷移到其他計算節點上。Pacemaker叢集會呼叫host-evacuate API將所有虛擬機器遷移。host-evacuate最後是使用rebuild來遷移虛擬機器，每個虛擬機器都會通過scheduler排程在不同的計算節點上啟動。

 

當然，還可以使用分散式健康檢查服務Consul等。

 

虛擬機器作業系統故障恢復

OpenStack 中的 libvirt/KVM 驅動已經能夠很好地自動化處理這類問題。具體地，你可以在flavor的 extra_specs 或者映象的屬性中加上 hw:watchdog_action ，這樣一個 watchdog 裝置會配置到虛擬機器上。如果 hw:watchdog_action 設定為 reset，那麼虛擬機器的作業系統一旦奔潰，watchdog 會將虛擬機器自動重啟。

 

OpenStack計算資源限制

 

設定記憶體

記憶體分配超售比例，預設是 1.5 倍，生產環境不建議開啟超售

ram_allocation_ratio = 1

 

記憶體預留量，這部分記憶體不能被虛擬機器使用，以便保證系統的正常執行

reserved_host_memory_mb = 10240      //如預留10GB

 

設定CPU

在虛擬化資源使用上，我們可以通過nova來控制，OpenStack提供了一些配置，修改檔案nova.conf。虛擬機器 vCPU 的綁定範圍，可以防止虛擬機器爭搶宿主機程序的 CPU 資源，建議值是預留前幾個物理 CPU

vcpu_pin_set = 4-31

 

物理 CPU 超售比例，預設是 16 倍，超執行緒也算作一個物理 CPU

cpu_allocation_ratio = 8

 

使用多Region和AZ

如果，OpenStack雲平臺需要跨機房或地區部署，可以使用多Region和 Availability Zone（以下簡稱AZ）的方案。這樣，每個機房之間在地理位置上自然隔離，這對上層的應用來說是天然的容災方法。

 

多區域（Region）部署

OpenStack支援依據地理位置劃分為不同的Region，所有的Regino除了共享Keystone、Horizon服務外，每個Region都是一個完整的OpenStack環境，從整體上看，多個區域之間的部署相對獨立，但可通過內網專線實現互通（如BGP-EVPN）。其架構如下圖所示。

部署時只需要部署一套公共的Keystone和Horizon服務，其它服務按照單Region方式部署即可，通過Endpoint指定Region。使用者在請求任何資源時必須指定具體的區域。採用這種方式能夠把分佈在不同的區域的資源統一管理起來，各個區域之間可以採取不同的部署架構甚至不同的版本。其優點如下：

• 部署簡單，每個區域部署幾乎不需要額外的配置，並且區域很容易實現橫向擴充套件。

• 故障域隔離，各個區域之間互不影響。

• 靈活自由，各個區域可以使用不同的架構、儲存、網路。

 

但該方案也存在明顯的不足：

• 各個區域之間完全隔離，彼此之間不能共享資源。比如在Region A建立的Volume，不能掛載到Region B的虛擬機器中。在Region A的資源，也不能分配到Region B中，可能出現Region負載不均衡問題。

• 各個區域之間完全獨立，不支援跨區域遷移，其中一個區域叢集發生故障，虛擬機器不能疏散到另一個區域叢集中。

• Keystone成為最主要的效能瓶頸，必須保證Keystone的可用性，否則將影響所有區域的服務。該問題可以通過部署多Keystone節點解決。

 

OpenStack多Region方案通過把一個大的叢集劃分為多個小叢集統一管理起來，從而實現了大規模物理資源的統一管理，它特別適合跨資料中心並且分佈在不同區域的場景，此時根據區域位置劃分Region，比如北京和上海。而對於使用者來說，還有以下好處:

• 使用者能根據自己的位置選擇離自己最近的區域，從而減少網路延遲,加快訪問速度。

• 使用者可以選擇在不同的Region間實現異地容災。當其中一個Region發生重大故障時，能夠快速把業務遷移到另一個Region中。

 

多Availability Zone部署

如果，只是想在一個機房中部署OpenStack雲環境。則只需要使用AZ方案即可。每個AZ有自己獨立供電的機架，以及OpenStack計算節點。

 

Availability Zone

一個Region可以被細分為一個或多個物理隔離或邏輯隔離的availability zones（AZ）。啟動虛擬機器時，可以指定特定的AZ甚至特定AZ中的某一個節點來啟動該虛擬機器。AZ可以簡單理解為一組節點的集合，這組節點具有獨立的電力供應裝置，比如一個個獨立供電的機房，或一個個獨立供電的機架都可以被劃分成AZ。

 

然後將應用的多個虛擬機器分別部署在Region的多個AZ上，提高虛擬機器的容災性和可用性。由於，AZ是物理隔離的，所以一個AZ掛了不會影響到其他的AZ。同時，還可以將掛了的AZ上的虛擬機器，遷移到其他正常可用的AZ上，類似於異地雙活。

 

Host Aggregate

除了AZ，計算節點也可以在邏輯上劃分為主機聚合（Host Aggregates簡稱HA）。主機聚合使用元資料去標記計算節點組。一個計算節點可以同時屬於一個主機聚合以及AZ而不會有衝突，它也可以屬於多個主機聚合。

 

主機聚合的節點具有共同的屬性，比如：cpu是特定型別的一組節點，disks是ssd的一組節點，os是linux或windows的一組節點等等。需要注意的是，Host Aggregates是使用者不可見的概念，主要用來給nova-scheduler通過某一屬性來進行instance的排程，比如講資料庫服務的 instances都排程到具有ssd屬性的Host Aggregate中，又或者讓某個flavor或某個image的instance排程到同一個Host Aggregates中。

 

簡單的來說，Region、Availability Zone和Host Aggregate這三者是從大範圍到小範圍的關係，即前者包含了後者。一個地理區域Region包含多個可用區AZ (availability zone)，同一個AZ中的計算節點又可以根據某種規則邏輯上的組合成一個組。例如在北京有一個Region，成都有一個Region，做容災之用。同時，在北京Region下，有2個AZ可用區（如酒仙橋機房和石景山機房），每個AZ都有自己獨立的網路和供電裝置，以及OpenStack計算節點等，如果使用者是在北京，那麼使用者在部署VM的時候選擇北京，可以提高使用者的訪問速度和較好的SLA（服務等級協議）。

 

選擇合適的網路方案

使用者常困擾於到底應該使用何種網路方案，如VLAN、VXLAN和GRE等。VLAN和VXLAN的區別即在於，VLAN是一種大二層網路技術，不需要虛擬路由轉換，效能相對VXLAN、GRE要好些，支援4094個網路，架構和運維簡單。VXLAN是一種疊加的網路隧道技術，將二層資料幀封裝在三層UDP資料包裡傳輸，需要路由轉換，封包和解包等，效能相對VLAN要差些，同時架構也更復雜，好處是支援1600多萬個網路，擴充套件性好。

 

如果，企業使用者在相當長的一段時間內，雲平臺規模都較小（比如在1萬臺虛擬機器數量以下），且對多租戶網路安全隔離性要求不高，那麼可以使用VLAN網路。反之，如果網路安全隔離性需求壓倒一切，或者雲平臺規模非常大，則可以使用VXLAN網路方案。

 

在VXLAN和VLAN網路通訊，即租戶私網和Floating IP外網路由轉發通訊背景下，預設在OpenStack傳統的集中式路由環境中，南北流量和跨網路的東西流量都要經過網路節點，當計算節點規模越來越大的時候，網路節點很快會成為整個系統的瓶頸，為解決這個問題引入了Distribute Virtual Router (DVR)的概念。使用DVR方案，可以將路由分佈到計算節點，南北流量和跨網段的東西流量由虛機所在計算節點上的虛擬路由進行路由，從而提高穩定性和效能。

 

備份雲平臺數據

俗話說，有備份在，睡覺也踏實。在一個實際的環境中，由於種種原因，可能發生資料被刪除的情況。比如，雲平臺中的資料庫、虛擬機器、資料卷、映象或底層儲存被刪除等，如果資料沒有進行備份，則是災難性的後果。

 

在一個由OpenStack+Ceph架構組成的雲平臺環境中，有N種資料備份方案。如OpenStack有自帶的Karbor、Freezer雲服務，Ceph也有相關的備份方案，也有其他商業的備份方案等。實際上，OpenStack雲平臺本身也提供了一些較好易用的備份功能，比如虛擬機器快照/備份、資料卷快照/備份，在使用時也倡導通過將資料卷掛載給虛擬機器，從而將資料寫入到雲盤中，間接的實現資料容災備份。

如果因為某些原因，沒有跨物理機房或地區的Region和AZ。那麼OpenStack雲平臺相關的資料備份，則是必須要做的。比如MySQL資料庫等，可以根據實際需求，每隔幾小時進行一次備份。而備份的資料，建議存放到其他機器上。關於Ceph的底層儲存備份方案，可以使用RBD Mirroring方案。

RBD Mirroring是Ceph新的非同步備份功能。支援配置兩個Ceph Cluster之間的rbd同步。在此方案下，Master Cluster使用效能較高的儲存裝置，提供給OpenStack的Glance、Cinder（cinder-volume、cinder-backup）和Nova服務使用；而Backup Cluster則使用容量空間大且廉價的儲存裝置（如SATA盤）來備份Ceph資料。不同的Ceph Cluster叢集，可以根據實際需要，選擇是否跨物理機房備份。如下圖所示。

 

優點：

• Ceph新的功能，不需要額外開發

• 同步的粒度比較小，為一個塊裝置的transaction

• 保證了Crash consistency

• 可配置pool的備份，也可單獨指定image備份

• 同步備份，不同機房的Ceph叢集，底層儲存的跨機房容災

 

使用合適的Docker儲存

如果，OpenStack雲平臺是用kolla容器化部署和管理的。那麼選擇一個正確、合適的Docker儲存，關乎你的平臺穩定和效能。

Docker 使用儲存驅動來管理映象每層內容及可讀寫的容器層，儲存驅動有 devicemapper、aufs、overlay、overlay2、btrfs、zfs 等，不同的儲存驅動實現方式有差異，映象組織形式可能也稍有不同，但都採用棧式儲存，並採用 Copy-on-Write(CoW) 策略。且儲存驅動採用熱插拔架構，可動態調整。那麼，儲存驅動那麼多，該如何選擇合適的呢？大致可從以下幾方面考慮：

• 若核心支援多種儲存驅動，且沒有顯式配置，Docker 會根據它內部設定的優先順序來選擇。優先順序為 aufs > btrfs/zfs > overlay2 > overlay > devicemapper。若使用 devicemapper 的話，在生產環境，一定要選擇 direct-lvm, loopback-lvm 效能非常差。

• 選擇會受限於 Docker 版本、作業系統、系統版本等。例如，aufs 只能用於 Ubuntu 或 Debian 系統，btrfs 只能用於 SLES （SUSE Linux Enterprise Server, 僅 Docker EE 支援）。

• 有些儲存驅動依賴於後端的檔案系統。例如，btrfs 只能運行於後端檔案系統 btrfs 上。

• 不同的儲存驅動在不同的應用場景下效能不同。例如，aufs、overlay、overlay2 操作在檔案級別，記憶體使用相對更高效，但大檔案讀寫時，容器層會變得很大；devicemapper、btrfs、zfs 操作在塊級別，適合工作在寫負載高的場景；容器層數多，且寫小檔案頻繁時，overlay2 效率比 overlay更高；btrfs、zfs 更耗記憶體。

 

Docker 容器其實是在映象的最上層加了一層讀寫層，通常也稱為容器層。在執行中的容器裡做的所有改動，如寫新檔案、修改已有檔案、刪除檔案等操作其實都寫到了容器層。儲存驅動決定了映象及容器在檔案系統中的儲存方式及組織形式。在我們的生產環境中，使用的是Centos 7.4系統及其4.15核心版本+Docker 1.13.1版本。因此使用的是overlay2儲存。下面對overlay2作一些簡單介紹。

 

Overlay介紹

OverlayFS 是一種類似 AUFS 的聯合檔案系統，但實現更簡單，效能更優。OverlayFS 嚴格來說是 Linux 核心的一種檔案系統，對應的 Docker 儲存驅動為 overlay 或者 overlay2，overlay2 需 要Linux 核心 4.0 及以上，overlay 需核心 3.18 及以上。且目前僅 Docker 社群版支援。條件許可的話，儘量使用 overlay2，與 overlay 相比，它的 inode 利用率更高。

 

和AUFS的多層不同的是Overlay只有兩層：一個upper檔案系統和一個lower檔案系統，分別代表Docker的容器層和映象層。當需要修改一個檔案時，使用CoW將檔案從只讀的lower複製到可寫的upper進行修改，結果也儲存在upper層。在Docker中，底下的只讀層就是image，可寫層就是Container。結構如下圖所示：

 

分析

• 從kernel 3.18進入主流Linux核心。設計簡單，速度快，比AUFS和Device mapper速度快。在某些情況下，也比Btrfs速度快。是Docker儲存方式選擇的未來。因為OverlayFS只有兩層，不是多層，所以OverlayFS “copy-up”操作快於AUFS。以此可以減少操作延時。

• OverlayFS支援頁快取共享，多個容器訪問同一個檔案能共享一個頁快取，以此提高記憶體使用率。

• OverlayFS消耗inode，隨著映象和容器增加，inode會遇到瓶頸。Overlay2能解決這個問題。在Overlay下，為了解決inode問題，可以考慮將/var/lib/docker掛在單獨的檔案系統上，或者增加系統inode設定。

 

使用分散式儲存

如果OpenStack雲平臺使用開源的分散式儲存系統，如Ceph、GlusterFS等。如何保證儲存系統的冗餘容災性、可靠性、安全性和效能，便顯得尤為重要。這裡，以Ceph開源分散式儲存為例進行講解。

 

Mon節點和OSD節點部署

一般地，在生產環境中，至少需要部署有3個Ceph Mon節點（數量最好為奇數）以及多個OSD節點。

 

開啟CephX認證

同時，開啟CephX認證方式，以提高資料儲存的安全性，防範被攻擊。如下所示。

# cat /etc/ceph/ceph.conf

[global]

fsid = e10d7336-23e8-4dac-a07a-d012d9208ae1

mon_initial_members = computer1, computer2, computer3

mon_host = 172.17.51.54,172.17.51.55,172.17.51.56

auth_cluster_required = cephx

auth_service_required = cephx

auth_client_required = cephx

………

 

網路配置

如果Ceph儲存節點規模較小，Ceph公共網路（即Public Network）使用千兆網路，叢集網路（即Cluster Network）使用萬兆網路即可。如果Ceph節點規模較大，且業務負載較高，則儘量都使用萬兆網路，在重要的環境上，Ceph公共網路和叢集網路，都應該單獨分開。需要注意的是，Ceph儲存節點使用的網絡卡，必須要做網絡卡Bond，防止網絡卡因故障而導致網路中斷。

 

使用Cache Tier

在一個雲端儲存環境中，出於成本的考慮，基本會少量使用SSD硬碟，大量使用SATA硬碟。在OpenStack整合Ceph的雲環境中，如何使用SSD和SATA硬碟。一般有兩種使用方法。

 

第一種：分別建立獨立的SSD和SATA儲存資源叢集。然後，Cinder塊儲存服務對接這兩套Ceph後端儲存，這樣雲平臺便可以同時建立和使用SSD介質和SATA介質的雲硬碟。

 

第二種：使用SSD硬碟建立容量相對較小但效能高的快取池（Cache tier），SATA硬碟建立容量大的但效能較低的儲存池（Storage tier）。

 

這裡，以第二種方式為例進行講解。當客戶端訪問操作資料時，會優先讀寫cache tier資料(當然要根據cache mode來決定)，如果資料在storage tier 則會提升到cache tier中，在cache tier中會有請求命中演算法、快取刷寫演算法、快取淘汰演算法等，將熱資料提升到cache tier中，將冷資料下放到storage tier中。

快取層代理自動處理快取層和後端儲存之間的資料遷移。在使用過程中，我們可以根據自己的需要，來配置遷移規則，主要有兩種場景：

• 回寫模式： 管理員把快取層配置為 writeback 模式時， Ceph 客戶端們會把資料寫入快取層、並收到快取層發來的 ACK ；寫入快取層的資料會被遷移到儲存層、然後從快取層刷掉。直觀地看，快取層位於後端儲存層的“前面”，當 Ceph 客戶端要讀取的資料位於儲存層時，快取層代理會把這些資料遷移到快取層，然後再發往 Ceph 客戶端。從此， Ceph 客戶端將與快取層進行 I/O 操作，直到資料不再被讀寫。此模式對於易變資料來說較理想（如照片/視訊編輯、事務資料等）。

• 只讀模式： 管理員把快取層配置為 readonly 模式時， Ceph 直接把資料寫入後端。讀取時， Ceph 把相應物件從後端複製到快取層，根據已定義策略、髒物件會被快取層踢出。此模式適合不變資料（如社交網路上展示的圖片/視訊、 DNA 資料、 X-Ray 照片等），因為從快取層讀出的資料可能包含過期資料，即一致性較差。對易變資料不要用 readonly 模式。

 

獨立使用Pool

Ceph可以統一OpenStack Cinder塊儲存服務（cinder-volume、cinder-backup）、Nova計算服務和Glance映象服務的後端儲存。在生產環境上，建議單獨建立4個儲存資源池（Pool）以分別對應OpenStack的4種服務儲存。同時，每個Pool的副本數建議設定為3份，如下表所示。

	Openstack服務	Ceph儲存池
Cinder-volumes	volumes
Cinder-backups	backups
Nova	vms
Glance	images

 

最後，Ceph分散式儲存部署架構，如下圖所示。

 

使用者應用層

在相當多的業務中，都會涉及到服務高可用。而一般的高可用的實現都是通過VIP(Vitrual IP)實現。VIP不像IP一樣，對應一個實際的網路介面（網絡卡），它是虛擬出來的IP地址，所以利用其特性可以實現服務的容錯和遷移工作。

 

在常見節點中VIP配置非常簡單，沒有多大的限制。但OpenStack例項中，一個IP對應一個Port裝置。並且Neutron 有“Allowed address pairs”限制，該功能要求 Port 的MAC/IP 相互對應，那麼該IP才能連通。對Port裝置的進行操作可以實現下面幾個功能：

• 一個Port裝置新增多組Allowed address Pairs，允許多個IP通過該Port連通。

• 一個IP對應多組MAC地址。

• 一個MAC地址對應多個IP

另外在OpenStack建立的例項中建立VIP並使其能正常工作可以使用下面方法：

• 建立VIP的Port裝置(防止該VIP被再次分配)

• 更新Port裝置的Allowed address pairs

 

第一步，建立Port裝置

#source admin-openrc.sh   //匯入租戶環境變數

#openstack network list    //檢視現有網路，從中選擇建立port裝置的網路

#openstack subnet list     //檢視網路下存在子網，從中選擇port裝置所處子網

#openstack port create --network NetWork_Name --fixed-ip subnet=SubNet_Name,

ip-address=IP Port_Name

#openstack port show Port_Name

 

此時Port裝置已經建立，但該Port裝置與需要建立VIP的例項沒有任何關係，在該例項上建立VIP也是不能工作的。原因在於下面

#neutron port-list |grep Instance-IP        //找到需要配置VIP的例項的Port ID

 

檢視該Port的詳細資訊

#neutron port-show 17b580e8-1733-4e2e-b248-cde4863f4985

 

此時的allowed_address_pairs為空，就算在該例項中建立VIP，其MAC/IP也是不對應，不能工作的。那麼就要進行第二步，即更新Port的allowed_address_pairs資訊

#neutron port-update Port-ID --allowed_address_pair list-true type=dict ip_address=IP

 

例如

#neutron port-update 17b580e8-1733-4e2e-b248-cde4863f4985

--allowed_address_pairs list=true type=dict ip_address=172.24.1.202

 

現在再來檢視例項Port資訊

#neutron port-show 17b580e8-1733-4e2e-b248-cde4863f4985

此時在虛擬機器中建立VIP，就能夠正常工作了。

 

運維平臺建設

監控是整個運維乃至整個產品生命週期中最重要的一環，事前及時預警發現故障，事後提供詳實的資料用於追查定位問題。目前業界有很多不錯的開源產品可供選擇。選擇一些開源的監控系統，是一個省時省力，效率最高的方案。

 

使用Kolla容器化部署和管理OpenStack雲平臺，已成為主流趨勢。這裡，我們以容器化部署和管理OpenStack雲平臺為背景，聊聊雲平臺相關的運維平臺建設。

 

監控目標

我們先來了解什麼是監控、監控的重要性以及監控的目標，當然每個人所在的行業不同、公司不同、業務不同、崗位不同，對監控的理解也不同，但是我們需要注意，監控是需要站在公司的業務角度去考慮，而不是針對某個監控技術的使用。

 

監控的目標，包括：

1）對系統不間斷實時監控：實際上是對系統不間斷的實時監控(這就是監控)；
2）實時反饋系統當前狀態：我們監控某個硬體、或者某個系統，都是需要能實時看到當前系統的狀態，是正常、異常、或者故障；
3）保證服務可靠性安全性：我們監控的目的就是要保證系統、服務、業務正常執行；
4）保證業務持續穩定執行：如果我們的監控做得很完善，即使出現故障，能第一時間接收到故障報警，在第一時間處理解決，從而保證業務持續性的穩定執行。

 

監控體系分層

監控有賴於運維各專業條線協同完善，通過將監控體系進行分層、分類，各專業條線再去有重點的豐富監控指標。監控的物件，主要有基礎設施硬體類和應用軟體類等，如下圖所示：

• 硬體設施層：交換機、路由器、負載均衡裝置、防火牆、伺服器（硬碟、CPU、記憶體和網絡卡）等。

• 雲平臺層：日誌、資料庫、訊息佇列、作業系統、OpenStack服務、Ceph儲存、Docker容器、系統和應用負載等。

• 應用層：虛擬機器、資料卷、虛擬網絡卡等。

 

監控手段

通常情況下，隨著系統的執行，作業系統會產生系統日誌，應用程式會產生應用程式的訪問日誌、錯誤日誌、執行日誌、網路日誌，我們可以使用 EFK 來進行日誌監控。對於日誌監控來說，最常見的需求就是收集、儲存、查詢、展示。

除了對日誌進行監控外，我們還需要對系統和應用的執行狀況進行實時監控。不同的監控目標，有不同的監控手段。OpenStack雲資源的監控，如虛擬機器、映象、資料卷、虛擬網絡卡等，天然的可以由OpenStack自帶的Ceilometer+Gnocchi+Aodh等服務來做（PS：ceilometer可以將採集資料交給gnocchi做資料聚合，最後用grafana展現報表）。

 

如果，OpenStack雲平臺是基於Kolla容器化部署和執行管理的。那麼諸如Docker容器、作業系統負載、儲存空間等，又該使用什麼來運維監控並告警呢。自然，TPIG棧便呼之欲出了。

 

什麼是TPIG棧。即由Telegraf + Influxdb + Grafana + Prometheus組合成的一套運維監控工具集合。它們之間的關係是：
Prometheus/Telegraf(收集資料) —-> Influxdb(儲存資料) —-> Grafana(顯示資料)

 

說明：
Prometheus和Telegraf不是必須同時部署使用的，你可以根據自己的需要，選擇二者都部署，也可以二者選其一。

如下幾種開源工具或方案，Kolla社群都是預設支援的。最重要的是，如何去使用、完善它們。

• 日誌收集和分析處理的開源方案有EFK棧：fluentd/filebeat + elasticsearch +kibana

• 效能採集和分析處理的開源方案有TPIG棧：telegraf + influxdb + grafana + Prometheus

 

監控方法

瞭解監控物件：我們要監控的物件你是否瞭解呢？比如硬碟的IOPS？
物件效能指標：我們要監控這個東西的什麼屬性？比如 CPU 的使用率、負載、使用者態、核心態、上下文切換。
報警閾值定義：怎麼樣才算是故障，要報警呢？比如 CPU 的負載到底多少算高，使用者態、核心態分別跑多少算高？
故障處理流程：收到了故障報警，我們怎麼處理呢？有什麼更高效的處理流程嗎？

 

監控流程

• 資料採集：通過telegraf/Prometheus等對系統和應用進行資料採集；

• 資料儲存：監控資料儲存在MySQL、influxdb上，也可以儲存在其他資料庫中；

• 資料分析：當我們事後需要分析故障時，EFK棧 能給我們提供圖形以及時間等相關資訊，方面我們確定故障所在；

• 資料展示：web 介面展示；

• 監控報警：電話報警、郵件報警、微信報警、簡訊報警、報警升級機制等（無論什麼報警都可以）；

• 報警處理：當接收到報警，我們需要根據故障的級別進行處理，比如:重要緊急、重要不緊急等。根據故障的級別，配合相關的人員進行快速處理；

 

監控告警

當監控的物件超過了某一閾值或者某一服務出現了異常時，便自動傳送郵件、簡訊或微信給相關人員進行告警。

 

事件應急響應

運維最基本的指標就是保證系統的可用性，應急恢復的時效性是系統可用性的關鍵指標。通常來講應急恢復的方法有不少，比如：

• 服務整體效能下降或異常，可以考慮重啟服務；

• 應用做過變更，可以考慮是否需要回切變更；

• 資源不足，可以考慮應急擴容；

• 應用效能問題，可以考慮調整應用引數、日誌引數；

• 資料庫繁忙，可以考慮通過資料庫快照分析，優化SQL；

• 應用功能設計有誤，可以考慮緊急關閉功能選單；

• 還有很多……

 

一些所見所想

現實中，不乏遇到一些拿來主義。即將Hadoop/Spark大資料業務跑在虛擬機器中執行，然後到了線上出現各種坑。如磁碟IO效能非常差，虛擬機器搶佔宿主機資源，導致其CPU使用率超過700%等等，最後掉入自己挖的坑裡。

 

須知，雲端計算的本質是虛擬化，虛擬化的本質是一虛多，即將一個個物理的計算資源、網路資源和儲存資源等虛擬化成多個邏輯資源（如KVM、openvswitch、ceph），再由資源排程管理系統（如OpenStack）抽象化提供給使用者使用。而大資料的本質是多虛一，將多個計算、儲存和網路資源統一管理集中起來提供給大資料業務使用。

 

OpenStack可以統一管理虛擬機器和裸機。推薦的做法應是將大資料放在裸機上跑，而不是放在虛擬機器上跑。違背了技術的本質，註定過程會很痛苦。

 

有的使用者在上雲或用雲過程中，時常會糾結到底使用什麼方案才好？比如使用OpenvSwitch還是LinuxBridge？使用VLAN還是VXLAN、GRE？使用Ceph還是GlusterFS、商業儲存？要不要做二次開發等？須知，從來不是技術決定需求，而是需求決定技術選型。同樣的，選擇使用什麼技術，應該由你的實際需求來決定。適合自己的才是最好的。只能說二者各有優缺點，使用者需要做的是根據實際需求，規避掉風險點最大的，選擇優勢最明顯的那個方案。

 

在準備使用OpenStack時，一定要明確OpenStack是一個知識密集型的開源雲框架，記住是一個框架，而不是一個開箱即用的產品。所需要的各方面技術人才和技術儲備是非常廣泛的，企業通常會面臨人才缺乏問題，一方面很難從外部招到有經驗的人，另一方面是企業培養內部人才耗時耗力。如果企業只是將OpenStack做私有云供自己使用，功能需求或業務並不複雜，比如用來代替價格昂貴的VMware提供虛擬機器業務，那麼一般不需要進行二次開發。反之，將OpenStack作為一個雲產品提供給第三方使用者使用或者滿足自身複雜業務需求，那麼進行二次開發是必要的，比如統一雲資源管理、資源邏輯排程、運維監控告警、Iaas+PaaS+SaaS統一支援等。實際中，一些企業負責人把OpenStack定位成阿里雲、AWS來開發，要麼是高估了自己的能力，要麼是低估了OpenStack的難度，覺得只是修改一個Dashboard而已，最後陷入死迴圈。

 

最後

隨著技術的演化，平臺複雜化+使用者簡單化的趨勢將越來越明顯。這就要求最終呈現給使用者使用的系統必須是極簡的。我相信，OpenStack朝著這方面努力，把企業使用者的剛需轉變為現實可操作性，前途會更光明！

 

最後，感謝OpenStack和引領我入門的前公司領導和同事，為我打開了一扇走進雲端計算的大門！同時也希望，有那麼一日，OpenStack雲端計算能從大企業才能享用的舶來品，進入尋常企業家。

 

OpenStack正值青年，有理由一路走下去！

 

作者介紹：

徐超，OpenStack、Kubernetes、Docker、CI/CD從業者和學習者，《OpenStack最佳實踐-測試與CI/CD》一書作者，OpenStack開源社群參與者。個人部落格：https://xuchao918.github.io