前言
應“雲技術社區”北極熊之邀，寫點東西。思來想去雲計算範疇實在廣泛，自然就聊點最近話題異常火熱，讓廣大雲計算從業者愛之深、痛之切，想說一聲愛你，不容易的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
# reboot
內存配置方面，網易私有云的實踐是關閉 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
閱讀更多 雲技術 的文章
