198. 聊聊OpenStack運維架構

前言

想一想，從事OpenStack雜七雜八的事兒，至今正好三年半了。做過QA測試（手動的、自動的）、CI（gerrit、jenkins、gitlab、harbor）、雲產品封裝（從系統pxe到openstack代碼）、自動化部署開發、運維監控、分佈式存儲、底層功能調研和實現、開源社區參與、Docker等等。

一個良好的架構設計和運維保障措施，能爲OpenStack雲平臺的穩定健康運行，產生不可估量的積極影響。

下面，是筆者從業OpenStack以來，關於OpenStack運維、架構設計、實施的點滴之想。在此，做一個回顧和總結。如有差錯，歡迎拍磚。

OK，咱們言歸正傳進入話題吧。如果化繁爲簡，簡單的來說，要部署一套生產環境級別的OpenStack雲平臺，至少會涉及到四個層次的內容，即物理基礎設施層、存儲層、OpenStack雲服務層和用戶應用層。如下圖所示。

物理基礎設施層

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

交換機設備

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

服務器

網卡

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

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

二者優劣比較。

在生產環境中，如果是少於90臺OpenStack節點規模的私有云，一般網絡類型對應的帶寬是（PS：90臺只是一個相對值，非絕對值，有潔癖的人請繞過）。

• 管理網絡：千兆網絡
• 外部網絡：千兆網絡
• 存儲網絡：萬兆網絡
• 租戶網絡：千兆網絡

如果是多於90臺OpenStack節點規模的私有云或公有云環境，則推薦儘量都使用萬兆網絡。

硬盤

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

CPU

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

內存

OpenStack各計算節點的內存大小，應該一致，以保證虛擬機創建管理的均衡調度等。同時，主機的Swap交換分區，應該科學合理的設置，不能使用系統默認創建的。如何設置，請參考此文。如何設置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_sharedecho 0 > /sys/kernel/mm/ksm/pages_sharingecho always > /sys/kernel/mm/transparent_hugepage/enabledecho never > /sys/kernel/mm/transparent_hugepage/defragecho 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：集羣只包括兩個節點簡稱主備。在這種配置下，系統採用主和備用機器來提供服務，系統只在主設備上提供服務。在主設備故障時，備設備上的服務被啓動來替代主設備提供的服務。典型地，可以採用 CRM 軟件比如 Pacemaker 來控制主備設備之間的切換，並提供一個虛機 IP 來提供服務。
• Active/Active 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高可用內容

如果，從部署層面來劃分，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節點用於持久化消息，客戶端根據需求分別配置主從策略。

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的統一方案，
詳細參考：High Availability for Virtual Machines。目前還處於開發階段。業界目前使用的方案大致有以下幾種：

1)檢查compute計算節點和nova 服務運行狀態，對於有問題的節點或服務進行自動修復。該方案的實現是：

①Pacemaker 監控每個計算節點上的 pacemaker_remote 的連接，來檢查該節點是否處於活動狀態。發現它不可以連接的話，啓動恢復（recovery）過程。

• 運行 ‘nova service-disable’
• 將該節點關機
• 等待 nova 發現該節點失效了
• 將該節點開機
• 如果節點啓動成功，執行 ‘nova service-enable’
• 如果節點啓動失敗，則執行 ‘nova evacuate’ 把該節點上的虛機移到別的可用計算節點上。

②Pacemaker 監控每個服務的狀態，如果狀態失效，該服務會被重啓，重啓失敗則觸發防護行爲（fencing action），即停掉該服務。

2)分佈式健康檢查，參考分佈式健康檢查：實現OpenStack計算節點高可用

如果使用第一種方案，實現計算節點和虛擬機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調度在不同的計算節點上啓動。

虛擬機操作系統故障恢復

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（服務等級協議）。

備份你的數據

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

使用合適的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-d012d9208ae1mon_initial_members = computer1, computer2, computer3mon_host = 172.17.51.54,172.17.51.55,172.17.51.56auth_cluster_required = cephxauth_service_required = cephxauth_client_required = cephx………

網絡配置

如果Ceph節點少於90臺，建議Ceph公共網絡（即Public Network）使用千兆網絡，集羣網絡（即Cluster Network）使用萬兆網絡。如果Ceph節點多於90臺，且業務負載較高，則儘量都使用萬兆網絡，在重要的環境上，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
Cinder-backups	backups	cinder
Nova	vms	cinder
Glance	images	cinder、glance

最後，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容器、操作系統負載、存儲空間等，又該使用什麼來運維監控並告警呢。自然，TPG棧便呼之欲出了（不要問我爲啥不用Zabbix）。

什麼是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 界面展示；
• 監控報警：電話報警、郵件報警、微信報警、短信報警、報警升級機制等（無論什麼報警都可以）；
• 報警處理：當接收到報警，我們需要根據故障的級別進行處理，比如:重要緊急、重要不緊急等。根據故障的級別，配合相關的人員進行快速處理；

監控告警

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

建立集中監控平臺

在一體化運維體系中，監控平臺貫穿所有環節，它起到了生產系統涉及的軟硬件環境實時運行狀況的“監”，監控平臺事件驅動的特性也爲一體化運維體系起到神經網絡驅動的作用，進而進行了“控”，另外，監控平臺優質的運維數據可以作爲運維大數據分析的數據源，實現運維數據採集的角色。爲了提高投入效率，減少重複投入，需要建立集中監控平臺實現統一展示、統一管理，支持兩地三中心建設，具備靈活的擴展性，支持運維大數據分析。

指標權重與閥值分級

需要重點強調一下監控指標的指標權重、閥值分級與上升機制問題，做監控的人知道“監”的最重要目標是不漏報，爲了不漏報在實際實施過程中會出現監控告警過多的困難。如何讓運維人員在不漏處理監控事件，又能快速解決風險最高的事件，則需要監控的指標需要進行指標權重、閥值分級與上升機制：

1）指標權重：

監控指標的權重是爲了定義此項監控指標是否爲必須配置，比如應用軟件服務、端口監聽是一個應用可用性的重要指標，權重定義爲一級指標；對於批量狀態，則由於不少應用系統並沒有批量狀態，則定義爲二級指標。通常來說一級指標將作爲監控覆蓋面的底線，通過設置好權重，一是爲了讓運維人員知道哪些監控指標必須確保覆蓋，同時加以引入KPI考覈；二是爲了讓監控平臺建設人員有側重的優化，實現一級指標的自動配置，無需運維人員手工配置。

2）閥值分級與上升機制：

有監控指標，就需要針對監控指標定義閥值，監控閥值的設立需要有分級機制，以分通知、預警、告警三級爲例：通知需要運維人員關注，比如“交易系統登錄數2000，登錄成功率95%，平時登錄數基線500，登錄成功率96%”，由於登錄成功率並未明顯下降，可能是由於業務作了業務推廣，運維人員只需關注當前應用運行狀態再做判斷；預警代表監控事件需要運維人員處理，但重要性略低，比如“CPU使用率71%，增長趨勢非突增”，管理員受理到這個預警可以先設置爲一個維護期，待當天找個時間集中處理；告警則必須馬上處理的事件，比如“交易成功率爲10%，平時爲90%”這類監控事件己反映出交易運行問題。

對於升級，是指一個預警當長時間未處理時，需要有一個上升機制，轉化爲告警，以督辦運維人員完成監控事件的處理。

事件分級標準

前面提到了事件分級的問題，分級是將事件當前緊急程度進行標識顯示，事件升級是對於低級的事件當達到一定的程度，比如處理時間過長，則需要進行升級。我們將監控事件等級事件級別分爲通知、預警、故障三種：

• 通知：指一般的通知信息類事件。
• 預警：指已經出現異常，即將要引起生產故障的事件。
• 故障：指已經發生問題，並且已經影響到生產流程的事件，如果需要進一步細化故障級別，可以分爲一般故障和緊急故障：一般故障不需要緊急處理的故障，緊急故障需要管理員緊急處理的故障。事件細分的粒度需根據各企業團隊的管理要求而定。

事件應急響應

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

• 服務整體性能下降或異常，可以考慮重啓服務；
• 應用做過變更，可以考慮是否需要回切變更；
• 資源不足，可以考慮應急擴容；
• 應用性能問題，可以考慮調整應用參數、日誌參數；
• 數據庫繁忙，可以考慮通過數據庫快照分析，優化SQL；
• 應用功能設計有誤，可以考慮緊急關閉功能菜單；
• 還有很多……

問題處理

上面，我們瞭解到了監控目標、監控手段、監控告警、監控方法和流程之後，我們也更需要知道監控的核心是什麼。即
1）發現問題：當系統發生故障報警，我們會收到故障報警的信息 ；
2）定位問題：故障郵件一般都會寫某某主機故障、具體故障的內容，我們需要對報警內容進行分析，比如一臺服務器連不上：我們就需要考慮是網絡問題、還是負載太高導致長時間無法連接，又或者某開發觸發了防火牆禁止的相關策略等等，我們就需要去分析故障具體原因；
3）解決問題：當然我們瞭解到故障的原因後，就需要通過故障解決的優先級去解決該故障；
4）總結問題：當我們解決完重大故障後，需要對故障原因以及防範進行總結歸納，避免以後重複出現；

最後

關於，如何具體的使用EFK棧和TPG棧監控和採集OpenStack雲平臺的Log日誌和性能數據實現一體化的運維監控告警，將在後面進行專題分享。