4年！我對(duì)OpenStack運(yùn)維架構(gòu)的總結(jié)

作者：徐超 2018-11-05 17:06:02

運(yùn)維

系統(tǒng)運(yùn)維

云計(jì)算

OpenStack OpenStack涉及的東西太多太多，計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、架構(gòu)、產(chǎn)品、運(yùn)維、監(jiān)控和性能優(yōu)化、代碼等等。這里就各抒已見(jiàn)，談點(diǎn)自己四年以來(lái)對(duì)OpenStack的理解吧，也算是一個(gè)交代，如有差錯(cuò)，歡迎拍磚。

成都創(chuàng)新互聯(lián)公司10多年企業(yè)網(wǎng)站制作服務(wù);為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì)及高端網(wǎng)站定制服務(wù),企業(yè)網(wǎng)站制作及推廣,對(duì)玻璃貼膜等多個(gè)方面擁有多年的網(wǎng)站維護(hù)經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。

前言

應(yīng)北極熊之邀，寫(xiě)點(diǎn)東西。思來(lái)想去云計(jì)算范疇實(shí)在廣泛，自然就聊點(diǎn)最近話題異?；馃?，讓廣大云計(jì)算從業(yè)者愛(ài)之深、痛之切，想說(shuō)一聲愛(ài)你，不容易的OpenStack吧。

這里，僅從技術(shù)角度出發(fā)，談?wù)凮penStack云平臺(tái)在部署、架構(gòu)和運(yùn)維實(shí)施等方面的感想。

緣起，在2014年大二首次接觸到OpenStack，當(dāng)時(shí)國(guó)內(nèi)外資料遠(yuǎn)沒(méi)有當(dāng)前這么豐富，為安裝一個(gè)OpenStack H版環(huán)境(一臺(tái)筆記本用VMware Workstation虛擬出2臺(tái)虛擬機(jī))愣是用了1個(gè)星期多，最后仍然創(chuàng)建虛擬機(jī)失敗。后來(lái)為了學(xué)習(xí)OpenStack，臨近畢業(yè)時(shí)特意去上海實(shí)習(xí)工作，不覺(jué)間已經(jīng)四年了。

OpenStack涉及的東西太多太多，計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、架構(gòu)、產(chǎn)品、運(yùn)維、監(jiān)控和性能優(yōu)化、代碼等等。這里就各抒已見(jiàn)，談點(diǎn)自己四年以來(lái)對(duì)OpenStack的理解吧，也算是一個(gè)交代，如有差錯(cuò)，歡迎拍磚。

誠(chéng)然，一個(gè)良好的架構(gòu)設(shè)計(jì)和運(yùn)維保障措施，能為OpenStack云平臺(tái)的穩(wěn)定健康運(yùn)行，產(chǎn)生不可估量的積極影響。如果化繁為簡(jiǎn)，簡(jiǎn)單的來(lái)說(shuō)，要部署一套生產(chǎn)環(huán)境級(jí)別的OpenStack云平臺(tái)，至少會(huì)涉及到四個(gè)層次的內(nèi)容，即物理基礎(chǔ)設(shè)施層、存儲(chǔ)層、OpenStack云服務(wù)層和用戶應(yīng)用層。如下圖所示。

物理基礎(chǔ)設(shè)施層

首先，從最底層開(kāi)始說(shuō)起，即“物理基礎(chǔ)設(shè)施層”。一個(gè)基本的物理基礎(chǔ)設(shè)施IT環(huán)境，包括了電力設(shè)備、空調(diào)和防火設(shè)備、網(wǎng)絡(luò)設(shè)備(如交換機(jī)、路由器、防火墻、負(fù)載均衡設(shè)備等)、存儲(chǔ)設(shè)備和服務(wù)器等。由于專業(yè)知識(shí)的限制，這里，只涉及交換機(jī)和服務(wù)器方面。一個(gè)基本的物理IT環(huán)境，如下圖所示。

交換機(jī)設(shè)備

一般地，在OpenStack生產(chǎn)環(huán)境上，交換機(jī)端口應(yīng)該做聚合(channel)。也就是將2個(gè)或多個(gè)物理端口組合在一起成為一條邏輯的鏈路從而增加交換機(jī)和網(wǎng)絡(luò)節(jié)點(diǎn)之間的帶寬，將屬于這幾個(gè)端口的帶寬合并，給端口提供一個(gè)幾倍于獨(dú)立端口的獨(dú)享的高帶寬。Trunk是一種封裝技術(shù)，它是一條點(diǎn)到點(diǎn)的鏈路，鏈路的兩端可以都是交換機(jī)，也可以是交換機(jī)和路由器，還可以是主機(jī)和交換機(jī)或路由器。

服務(wù)器

網(wǎng)卡

OpenStack云平臺(tái)涉及到的網(wǎng)絡(luò)有管理網(wǎng)絡(luò)(用于OpenStack各服務(wù)之間通信)、外部網(wǎng)絡(luò)(提供floating ip)、存儲(chǔ)網(wǎng)絡(luò)(如ceph存儲(chǔ)網(wǎng)絡(luò))和虛機(jī)網(wǎng)絡(luò)(也稱租戶網(wǎng)絡(luò)、業(yè)務(wù)網(wǎng)絡(luò))四種類型。

對(duì)應(yīng)到每一種網(wǎng)絡(luò)，服務(wù)器都應(yīng)該做網(wǎng)卡Bond，來(lái)提供服務(wù)器網(wǎng)絡(luò)的冗余、高可用和負(fù)載均衡的能力，根據(jù)實(shí)際需求，可以選擇模式0或模式1。在網(wǎng)絡(luò)流量較大的場(chǎng)景下推薦使用bond 0;在可靠性要求較高的場(chǎng)景下推薦使用bond 1。

二者優(yōu)劣比較。

一般地，在小規(guī)模的私有云環(huán)境中，網(wǎng)絡(luò)類型對(duì)應(yīng)的帶寬是：

• 管理網(wǎng)絡(luò)：千兆網(wǎng)絡(luò)
• 外部網(wǎng)絡(luò)：千兆網(wǎng)絡(luò)
• 存儲(chǔ)網(wǎng)絡(luò)：萬(wàn)兆網(wǎng)絡(luò)
• 租戶網(wǎng)絡(luò)：千兆網(wǎng)絡(luò)

如果是中大規(guī)模的私有云或公有云環(huán)境，則推薦盡量都使用萬(wàn)兆網(wǎng)絡(luò)。

硬盤(pán)

服務(wù)器操作系統(tǒng)使用的系統(tǒng)盤(pán)，應(yīng)該用2塊硬盤(pán)來(lái)做RAID 1，以提供系統(tǒng)存儲(chǔ)的高可靠性。且推薦使用高性能且成本可控的SAS硬盤(pán)，以提高操作系統(tǒng)、MySQL數(shù)據(jù)庫(kù)和Docker容器(如果使用kolla部署openstack)的IO存儲(chǔ)性能。

CPU

OpenStack各計(jì)算節(jié)點(diǎn)的CPU型號(hào)，必須一致，以保證虛擬機(jī)的遷移功能正常可用等。

內(nèi)存

OpenStack各計(jì)算節(jié)點(diǎn)的內(nèi)存大小，應(yīng)該一致，以保證虛擬機(jī)創(chuàng)建管理的均衡調(diào)度等。同時(shí)，主機(jī)的Swap交換分區(qū)，應(yīng)該科學(xué)合理的設(shè)置，不能使用系統(tǒng)默認(rèn)創(chuàng)建的。

數(shù)據(jù)中心中少部分機(jī)器用于做控制節(jié)點(diǎn)，大部分機(jī)器都是需要運(yùn)行虛擬化軟件的，虛擬化平臺(tái)上有大量的VM，而宿主機(jī)本身的系統(tǒng)也會(huì)跑一些服務(wù)，那么這就勢(shì)必會(huì)造成vm之間資源搶占，vm與宿主機(jī)系統(tǒng)之間的資源搶占，我們需要通過(guò)設(shè)定規(guī)則，讓他們?cè)诟髯缘慕缦迌?nèi)高效運(yùn)行，減少?zèng)_突搶占。

我們可以讓宿主機(jī)運(yùn)行操作系統(tǒng)時(shí)候，更多的選擇指定的幾個(gè)核，這樣就不會(huì)過(guò)多搶占虛擬化中虛機(jī)的vcpu調(diào)度，通過(guò)修改內(nèi)核啟動(dòng)參數(shù)我們可以做到:

修改 /etc/default/grub文件，讓系統(tǒng)只使用前三個(gè)核 隔離其余核。

  
 
 
 

   
  
  
  
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" 
  
 
 
 

更新內(nèi)核參數(shù) 

  
 
 
 

   
  
  
  
# update-grub  
   
  
  
  
# reboot 
  
 
 
 

內(nèi)存配置方面，網(wǎng)易私有云的實(shí)踐是關(guān)閉 KVM 內(nèi)存共享，打開(kāi)透明大頁(yè)： 

  
 
 
 

   
  
  
  
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 
  
 
 
 

據(jù)說(shuō)，經(jīng)過(guò) SPEC CPU2006 測(cè)試，這些配置對(duì)云主機(jī) CPU 性能大概有7%左右的提升。

OpenStack云平臺(tái)層

云平臺(tái)高可用(HA)

高可用(HA)介紹

高可用性是指提供在本地系統(tǒng)單個(gè)組件故障情況下，能繼續(xù)訪問(wèn)應(yīng)用的能力，無(wú)論這個(gè)故障是業(yè)務(wù)流程、物理設(shè)施、IT軟/硬件的故障。最好的可用性， 就是你的一臺(tái)機(jī)器宕機(jī)了，但是使用你的服務(wù)的用戶完全感覺(jué)不到。你的機(jī)器宕機(jī)了，在該機(jī)器上運(yùn)行的服務(wù)肯定得做故障切換(failover)，切換有兩個(gè)維度的成本：RTO (Recovery Time Objective)和 RPO(Recovery Point Objective)。RTO 是服務(wù)恢復(fù)的時(shí)間，最佳的情況是 0，這意味著服務(wù)立即恢復(fù);最壞是無(wú)窮大意味著服務(wù)永遠(yuǎn)恢復(fù)不了;RPO 是切換時(shí)向前恢復(fù)的數(shù)據(jù)的時(shí)間長(zhǎng)度，0 意味著使用同步的數(shù)據(jù)，大于 0 意味著有數(shù)據(jù)丟失，比如 ” RPO = 1 天“ 意味著恢復(fù)時(shí)使用一天前的數(shù)據(jù)，那么一天之內(nèi)的數(shù)據(jù)就丟失了。因此，恢復(fù)的最佳結(jié)果是 RTO = RPO = 0，但是這個(gè)太理想，或者要實(shí)現(xiàn)的話成本太高。

對(duì) HA 來(lái)說(shuō)，往往使用分布式存儲(chǔ)，這樣的話，RPO =0 ;同時(shí)使用 Active/Active (雙活集群) HA 模式來(lái)使得 RTO 幾乎為0，如果使用 Active/Passive HA模式的話，則需要將 RTO 減少到最小限度。HA 的計(jì)算公式是[ 1 - (宕機(jī)時(shí)間)/(宕機(jī)時(shí)間 + 運(yùn)行時(shí)間)]，我們常常用幾個(gè) 9 表示可用性：

• 2 個(gè)9：99% = 1% 365 = 3.65 24 小時(shí)/年 = 87.6 小時(shí)/年的宕機(jī)時(shí)間
• 4 個(gè)9: 99.99% = 0.01% 365 24 * 60 = 52.56 分鐘/年
• 5 個(gè)9：99.999% = 0.001% * 365 = 5.265 分鐘/年的宕機(jī)時(shí)間，也就意味著每次停機(jī)時(shí)間在一到兩分鐘。
• 11 個(gè) 9：幾年宕機(jī)幾分鐘。

服務(wù)的分類

HA 將服務(wù)分為兩類：

• 有狀態(tài)服務(wù)：后續(xù)對(duì)服務(wù)的請(qǐng)求依賴于之前對(duì)服務(wù)的請(qǐng)求。OpenStack中有狀態(tài)的服務(wù)包括MySQL數(shù)據(jù)庫(kù)和AMQP消息隊(duì)列。對(duì)于有狀態(tài)類服務(wù)的HA，如neutron-l3-agent、neutron-metadata-agent、nova-compute、cinder-volume等服務(wù)，最簡(jiǎn)便的方法就是多節(jié)點(diǎn)部署。比如某一節(jié)點(diǎn)上的nova-compute服務(wù)掛了，也并不會(huì)影響到整個(gè)云平臺(tái)不能創(chuàng)建虛擬機(jī)，或者所在節(jié)點(diǎn)的虛擬機(jī)無(wú)法使用(比如ssh等)。
• 無(wú)狀態(tài)服務(wù)：對(duì)服務(wù)的請(qǐng)求之間沒(méi)有依賴關(guān)系，是完全獨(dú)立的，基于冗余實(shí)例和負(fù)載均衡實(shí)現(xiàn)HA。OpenStack中無(wú)狀態(tài)的服務(wù)包括nova-api、nova-conductor、glance-api、keystone-api、neutron-api、nova-scheduler等。由于API服務(wù)，屬于無(wú)狀態(tài)類服務(wù)，天然支持Active/Active HA模式。因此，一般使用 keepalived +HAProxy方案來(lái)做。

HA 的種類

HA 需要使用冗余的服務(wù)器組成集群來(lái)運(yùn)行負(fù)載，包括應(yīng)用和服務(wù)。這種冗余性也可以將 HA 分為兩類：

• Active/Passive HA：即主備HA。在這種配置下，系統(tǒng)采用主和備用機(jī)器來(lái)提供服務(wù)，系統(tǒng)只在主設(shè)備上提供服務(wù)。在主設(shè)備故障時(shí)，備設(shè)備上的服務(wù)被啟動(dòng)來(lái)替代主設(shè)備提供的服務(wù)。典型地，可以采用 CRM 軟件比如 Pacemaker 來(lái)控制主備設(shè)備之間的切換，并提供一個(gè)虛擬 IP 來(lái)提供服務(wù)。
• Active/Active HA：即主主HA，包括多節(jié)點(diǎn)時(shí)成為多主(Multi-master)。在這種配置下，系統(tǒng)在集群內(nèi)所有服務(wù)器上運(yùn)行同樣的負(fù)載。以數(shù)據(jù)庫(kù)為例，對(duì)一個(gè)實(shí)例的更新，會(huì)被同步到所有實(shí)例上。這種配置下往往采用負(fù)載均衡軟件比如 HAProxy 來(lái)提供服務(wù)的虛擬 IP。

OpenStack云環(huán)境高可用(HA)

云環(huán)境是一個(gè)廣泛的系統(tǒng)，包括了基礎(chǔ)設(shè)施層、OpenStack云平臺(tái)服務(wù)層、虛擬機(jī)和最終用戶應(yīng)用層。

云環(huán)境的 HA 包括：

• 用戶應(yīng)用的 HA
• 虛擬機(jī)的 HA
• OpenStack云平臺(tái)服務(wù)的 HA
• 基礎(chǔ)設(shè)施層的HA：電力、空調(diào)和防火設(shè)施、網(wǎng)絡(luò)設(shè)備(如交換機(jī)、路由器)、服務(wù)器設(shè)備和存儲(chǔ)設(shè)備等

僅就OpenStack云平臺(tái)服務(wù)(如nova-api、nova-scheduler、nova-compute等)而言，少則幾十，多則上百個(gè)。如果某一個(gè)服務(wù)掛了，則對(duì)應(yīng)的功能便不能正常使用。因此，如何保障整體云環(huán)境的HA高可用，便成為了架構(gòu)設(shè)計(jì)和運(yùn)維的重中之重。

OpenStack HA高可用架構(gòu)，如下圖所示。

如果，從部署層面來(lái)劃分，OpenStack高可用的內(nèi)容包括：

• 控制節(jié)點(diǎn)(Rabbitmq、mariadb、Keystone、nova-api等)
• 網(wǎng)絡(luò)節(jié)點(diǎn)(neutron_dhcp_agent、neutron_l3_agent、neutron_openvswitch_agent等)
• 計(jì)算節(jié)點(diǎn)(Nova-Compute、neutron_openvswitch_agent、虛擬機(jī)等)
• 存儲(chǔ)節(jié)點(diǎn)(cinder-volume、swift等)

控制節(jié)點(diǎn)HA

在生產(chǎn)環(huán)境中，建議至少部署三臺(tái)控制節(jié)點(diǎn)，其余可做計(jì)算節(jié)點(diǎn)、網(wǎng)絡(luò)節(jié)點(diǎn)或存儲(chǔ)節(jié)點(diǎn)。采用Haproxy + KeepAlived方式，代理數(shù)據(jù)庫(kù)服務(wù)和OpenStack服務(wù)，對(duì)外暴露VIP提供API訪問(wèn)。

MySQL數(shù)據(jù)庫(kù)HA

mysql 的HA 方案有很多，這里只討論openstack 官方推薦的mariadb Galara 集群。Galera Cluster 是一套在innodb存儲(chǔ)引擎上面實(shí)現(xiàn)multi-master及數(shù)據(jù)實(shí)時(shí)同步的系統(tǒng)架構(gòu)，業(yè)務(wù)層面無(wú)需做讀寫(xiě)分離工作，數(shù)據(jù)庫(kù)讀寫(xiě)壓力都能按照既定的規(guī)則分發(fā)到各個(gè)節(jié)點(diǎn)上去。特點(diǎn)如下：

1. 同步復(fù)制，(>=3)奇數(shù)個(gè)節(jié)點(diǎn)
2. Active-active的多主拓?fù)浣Y(jié)構(gòu)
3. 集群任意節(jié)點(diǎn)可以讀和寫(xiě)
4. 自動(dòng)身份控制,失敗節(jié)點(diǎn)自動(dòng)脫離集群
5. 自動(dòng)節(jié)點(diǎn)接入
6. 真正的基于”行”級(jí)別和ID檢查的并行復(fù)制
7. 無(wú)單點(diǎn)故障,易擴(kuò)展

采用MariaDB + Galera方案部署至少三個(gè)節(jié)點(diǎn)(最好節(jié)點(diǎn)數(shù)量為奇數(shù))，外部訪問(wèn)通過(guò)Haproxy的active + backend方式代理。平時(shí)主庫(kù)為A，當(dāng)A出現(xiàn)故障，則切換到B或C節(jié)點(diǎn)。如下圖所示。

RabbitMQ 消息隊(duì)列HA

RabbitMQ采用原生Cluster集群方案，所有節(jié)點(diǎn)同步鏡像隊(duì)列。小規(guī)模環(huán)境中，三臺(tái)物理機(jī)，其中2個(gè)Mem節(jié)點(diǎn)主要提供服務(wù)，1個(gè)Disk節(jié)點(diǎn)用于持久化消息，客戶端根據(jù)需求分別配置主從策略。據(jù)說(shuō)使用ZeroMQ代替默認(rèn)的RabbitMQ有助于提升集群消息隊(duì)列性能。

OpenStack API服務(wù)HA

OpenStack控制節(jié)點(diǎn)上運(yùn)行的基本上是API 無(wú)狀態(tài)類服務(wù)，如nova-api、neutron-server、glance-registry、nova-novncproxy、keystone等。因此，可以由 HAProxy 提供負(fù)載均衡，將請(qǐng)求按照一定的算法轉(zhuǎn)到某個(gè)節(jié)點(diǎn)上的 API 服務(wù)，并由KeepAlived提供 VIP。

網(wǎng)絡(luò)節(jié)點(diǎn)HA

網(wǎng)絡(luò)節(jié)點(diǎn)上運(yùn)行的Neutron服務(wù)包括很多的組件，比如 L3 Agent，openvswitch Agent，LBaas，VPNaas，F(xiàn)Waas，Metadata Agent 等，其中部分組件提供了原生的HA 支持。

• Openvswitch Agent HA： openvswitch agent 只在所在的網(wǎng)絡(luò)或者計(jì)算節(jié)點(diǎn)上提供服務(wù)，因此它是不需要HA的
• L3 Agent HA：成熟主流的有VRRP 和DVR兩種方案
• DHCP Agent HA：在多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)上部署DHCP Agent，實(shí)現(xiàn)HA
• LBaas Agent HA：Pacemaker + 共享存儲(chǔ)(放置 /var/lib/neutron/lbaas/ 目錄) 的方式來(lái)部署 A/P 方式的 LBaas Agent HA

存儲(chǔ)節(jié)點(diǎn)HA

存儲(chǔ)節(jié)點(diǎn)的HA，主要是針對(duì)cinder-volume、cinder-backup服務(wù)做HA，最簡(jiǎn)便的方法就是部署多個(gè)存儲(chǔ)節(jié)點(diǎn)，某一節(jié)點(diǎn)上的服務(wù)掛了，不至于影響到全局。

計(jì)算節(jié)點(diǎn)和虛擬機(jī) HA

計(jì)算節(jié)點(diǎn)和虛擬機(jī)的HA，社區(qū)從2016年9月開(kāi)始一直致力于一個(gè)虛擬機(jī)HA的統(tǒng)一方案，但目前仍然沒(méi)有一個(gè)成熟的方案。實(shí)現(xiàn)計(jì)算節(jié)點(diǎn)和虛擬機(jī)HA，要做的事情基本有三件，即。

① 監(jiān)控

監(jiān)控主要做兩個(gè)事情，一個(gè)是監(jiān)控計(jì)算節(jié)點(diǎn)的硬件和軟件故障。第二個(gè)是觸發(fā)故障的處理事件，也就是隔離和恢復(fù)。

OpenStack 計(jì)算節(jié)點(diǎn)高可用，可以用pacemaker和pacemaker_remote來(lái)做。使用pacemaker_remote后，我們可以把所有的計(jì)算節(jié)點(diǎn)都加入到這個(gè)集群中，計(jì)算節(jié)點(diǎn)只需要安裝pacemaker_remote即可。pacemaker集群會(huì)監(jiān)控計(jì)算節(jié)點(diǎn)上的pacemaker_remote是否 “活著”，你可以定義什么是“活著”。比如在計(jì)算節(jié)點(diǎn)上監(jiān)控nova-compute、neutron-ovs-agent、libvirt等進(jìn)程，從而確定計(jì)算節(jié)點(diǎn)是否活著，亦或者租戶網(wǎng)絡(luò)和其他網(wǎng)絡(luò)斷了等。如果監(jiān)控到某個(gè)pacemaker_remote有問(wèn)題，可以馬上觸發(fā)之后的隔離和恢復(fù)事件。

② 隔離

隔離最主要的任務(wù)是將不能正常工作的計(jì)算節(jié)點(diǎn)從OpenStack集群環(huán)境中移除，nova-scheduler就不會(huì)在把create_instance的message發(fā)給該計(jì)算節(jié)點(diǎn)。

Pacemaker 已經(jīng)集成了fence這個(gè)功能，因此我們可以使用fence_ipmilan來(lái)關(guān)閉計(jì)算節(jié)點(diǎn)。Pacemaker集群中fence_compute 會(huì)一直監(jiān)控這個(gè)計(jì)算節(jié)點(diǎn)是否down了，因?yàn)閚ova只能在計(jì)算節(jié)點(diǎn)down了之后才可以執(zhí)行host-evacuate來(lái)遷移虛擬機(jī)，期間等待的時(shí)間稍長(zhǎng)。這里有個(gè)更好的辦法，就是調(diào)用nova service-force-down 命令，直接把計(jì)算節(jié)點(diǎn)標(biāo)記為down，方便更快的遷移虛擬機(jī)。

③ 恢復(fù)

恢復(fù)就是將狀態(tài)為down的計(jì)算節(jié)點(diǎn)上的虛擬機(jī)遷移到其他計(jì)算節(jié)點(diǎn)上。Pacemaker集群會(huì)調(diào)用host-evacuate API將所有虛擬機(jī)遷移。host-evacuate最后是使用rebuild來(lái)遷移虛擬機(jī)，每個(gè)虛擬機(jī)都會(huì)通過(guò)scheduler調(diào)度在不同的計(jì)算節(jié)點(diǎn)上啟動(dòng)。

當(dāng)然，還可以使用分布式健康檢查服務(wù)Consul等。

虛擬機(jī)操作系統(tǒng)故障恢復(fù)

OpenStack 中的 libvirt/KVM 驅(qū)動(dòng)已經(jīng)能夠很好地自動(dòng)化處理這類問(wèn)題。具體地，你可以在flavor的 extra_specs 或者鏡像的屬性中加上 hw:watchdog_action ，這樣一個(gè) watchdog 設(shè)備會(huì)配置到虛擬機(jī)上。如果 hw:watchdog_action 設(shè)置為 reset，那么虛擬機(jī)的操作系統(tǒng)一旦奔潰，watchdog 會(huì)將虛擬機(jī)自動(dòng)重啟。

OpenStack計(jì)算資源限制

設(shè)置內(nèi)存

內(nèi)存分配超售比例，默認(rèn)是 1.5 倍，生產(chǎn)環(huán)境不建議開(kāi)啟超售

  
 
 
 

   
  
  
  
ram_allocation_ratio = 1 
  
 
 
 

內(nèi)存預(yù)留量，這部分內(nèi)存不能被虛擬機(jī)使用，以便保證系統(tǒng)的正常運(yùn)行

  
 
 
 

   
  
  
  
reserved_host_memory_mb = 10240 //如預(yù)留10GB 
  
 
 
 

設(shè)置CPU

在虛擬化資源使用上，我們可以通過(guò)nova來(lái)控制，OpenStack提供了一些配置，修改文件nova.conf。虛擬機(jī) vCPU 的綁定范圍，可以防止虛擬機(jī)爭(zhēng)搶宿主機(jī)進(jìn)程的 CPU 資源，建議值是預(yù)留前幾個(gè)物理 CPU

  
 
 
 

   
  
  
  
vcpu_pin_set = 4-31 
  
 
 
 

物理 CPU 超售比例，默認(rèn)是 16 倍，超線程也算作一個(gè)物理 CPU

  
 
 
 

   
  
  
  
cpu_allocation_ratio = 8 
  
 
 
 

使用多Region和AZ

如果，OpenStack云平臺(tái)需要跨機(jī)房或地區(qū)部署，可以使用多Region和 Availability Zone(以下簡(jiǎn)稱AZ)的方案。這樣，每個(gè)機(jī)房之間在地理位置上自然隔離，這對(duì)上層的應(yīng)用來(lái)說(shuō)是天然的容災(zāi)方法。

多區(qū)域(Region)部署

OpenStack支持依據(jù)地理位置劃分為不同的Region，所有的Regino除了共享Keystone、Horizon服務(wù)外，每個(gè)Region都是一個(gè)完整的OpenStack環(huán)境，從整體上看，多個(gè)區(qū)域之間的部署相對(duì)獨(dú)立，但可通過(guò)內(nèi)網(wǎng)專線實(shí)現(xiàn)互通(如BGP-EVPN)。其架構(gòu)如下圖所示。

部署時(shí)只需要部署一套公共的Keystone和Horizon服務(wù)，其它服務(wù)按照單Region方式部署即可，通過(guò)Endpoint指定Region。用戶在請(qǐng)求任何資源時(shí)必須指定具體的區(qū)域。采用這種方式能夠把分布在不同的區(qū)域的資源統(tǒng)一管理起來(lái)，各個(gè)區(qū)域之間可以采取不同的部署架構(gòu)甚至不同的版本。其優(yōu)點(diǎn)如下：

• 部署簡(jiǎn)單，每個(gè)區(qū)域部署幾乎不需要額外的配置，并且區(qū)域很容易實(shí)現(xiàn)橫向擴(kuò)展。
• 故障域隔離，各個(gè)區(qū)域之間互不影響。
• 靈活自由，各個(gè)區(qū)域可以使用不同的架構(gòu)、存儲(chǔ)、網(wǎng)絡(luò)。

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

• 各個(gè)區(qū)域之間完全隔離，彼此之間不能共享資源。比如在Region A創(chuàng)建的Volume，不能掛載到Region B的虛擬機(jī)中。在Region A的資源，也不能分配到Region B中，可能出現(xiàn)Region負(fù)載不均衡問(wèn)題。
• 各個(gè)區(qū)域之間完全獨(dú)立，不支持跨區(qū)域遷移，其中一個(gè)區(qū)域集群發(fā)生故障，虛擬機(jī)不能疏散到另一個(gè)區(qū)域集群中。
• Keystone成為最主要的性能瓶頸，必須保證Keystone的可用性，否則將影響所有區(qū)域的服務(wù)。該問(wèn)題可以通過(guò)部署多Keystone節(jié)點(diǎn)解決。

OpenStack多Region方案通過(guò)把一個(gè)大的集群劃分為多個(gè)小集群統(tǒng)一管理起來(lái)，從而實(shí)現(xiàn)了大規(guī)模物理資源的統(tǒng)一管理，它特別適合跨數(shù)據(jù)中心并且分布在不同區(qū)域的場(chǎng)景，此時(shí)根據(jù)區(qū)域位置劃分Region，比如北京和上海。而對(duì)于用戶來(lái)說(shuō)，還有以下好處:

• 用戶能根據(jù)自己的位置選擇離自己最近的區(qū)域，從而減少網(wǎng)絡(luò)延遲,加快訪問(wèn)速度。
• 用戶可以選擇在不同的Region間實(shí)現(xiàn)異地容災(zāi)。當(dāng)其中一個(gè)Region發(fā)生重大故障時(shí)，能夠快速把業(yè)務(wù)遷移到另一個(gè)Region中。

多Availability Zone部署

如果，只是想在一個(gè)機(jī)房中部署OpenStack云環(huán)境。則只需要使用AZ方案即可。每個(gè)AZ有自己獨(dú)立供電的機(jī)架，以及OpenStack計(jì)算節(jié)點(diǎn)。

Availability Zone

一個(gè)Region可以被細(xì)分為一個(gè)或多個(gè)物理隔離或邏輯隔離的availability zones(AZ)。啟動(dòng)虛擬機(jī)時(shí)，可以指定特定的AZ甚至特定AZ中的某一個(gè)節(jié)點(diǎn)來(lái)啟動(dòng)該虛擬機(jī)。AZ可以簡(jiǎn)單理解為一組節(jié)點(diǎn)的集合，這組節(jié)點(diǎn)具有獨(dú)立的電力供應(yīng)設(shè)備，比如一個(gè)個(gè)獨(dú)立供電的機(jī)房，或一個(gè)個(gè)獨(dú)立供電的機(jī)架都可以被劃分成AZ。

然后將應(yīng)用的多個(gè)虛擬機(jī)分別部署在Region的多個(gè)AZ上，提高虛擬機(jī)的容災(zāi)性和可用性。由于，AZ是物理隔離的，所以一個(gè)AZ掛了不會(huì)影響到其他的AZ。同時(shí)，還可以將掛了的AZ上的虛擬機(jī)，遷移到其他正?？捎玫腁Z上，類似于異地雙活。

Host Aggregate

除了AZ，計(jì)算節(jié)點(diǎn)也可以在邏輯上劃分為主機(jī)聚合(Host Aggregates簡(jiǎn)稱HA)。主機(jī)聚合使用元數(shù)據(jù)去標(biāo)記計(jì)算節(jié)點(diǎn)組。一個(gè)計(jì)算節(jié)點(diǎn)可以同時(shí)屬于一個(gè)主機(jī)聚合以及AZ而不會(huì)有沖突，它也可以屬于多個(gè)主機(jī)聚合。

主機(jī)聚合的節(jié)點(diǎn)具有共同的屬性，比如：cpu是特定類型的一組節(jié)點(diǎn)，disks是ssd的一組節(jié)點(diǎn)，os是linux或windows的一組節(jié)點(diǎn)等等。需要注意的是，Host Aggregates是用戶不可見(jiàn)的概念，主要用來(lái)給nova-scheduler通過(guò)某一屬性來(lái)進(jìn)行instance的調(diào)度，比如講數(shù)據(jù)庫(kù)服務(wù)的 instances都調(diào)度到具有ssd屬性的Host Aggregate中，又或者讓某個(gè)flavor或某個(gè)image的instance調(diào)度到同一個(gè)Host Aggregates中。

簡(jiǎn)單的來(lái)說(shuō)，Region、Availability Zone和Host Aggregate這三者是從大范圍到小范圍的關(guān)系，即前者包含了后者。一個(gè)地理區(qū)域Region包含多個(gè)可用區(qū)AZ (availability zone)，同一個(gè)AZ中的計(jì)算節(jié)點(diǎn)又可以根據(jù)某種規(guī)則邏輯上的組合成一個(gè)組。例如在北京有一個(gè)Region，成都有一個(gè)Region，做容災(zāi)之用。同時(shí)，在北京Region下，有2個(gè)AZ可用區(qū)(如酒仙橋機(jī)房和石景山機(jī)房)，每個(gè)AZ都有自己獨(dú)立的網(wǎng)絡(luò)和供電設(shè)備，以及OpenStack計(jì)算節(jié)點(diǎn)等，如果用戶是在北京，那么用戶在部署VM的時(shí)候選擇北京，可以提高用戶的訪問(wèn)速度和較好的SLA(服務(wù)等級(jí)協(xié)議)。

選擇合適的網(wǎng)絡(luò)方案

用戶常困擾于到底應(yīng)該使用何種網(wǎng)絡(luò)方案，如VLAN、VXLAN和GRE等。VLAN和VXLAN的區(qū)別即在于，VLAN是一種大二層網(wǎng)絡(luò)技術(shù)，不需要虛擬路由轉(zhuǎn)換，性能相對(duì)VXLAN、GRE要好些，支持4094個(gè)網(wǎng)絡(luò)，架構(gòu)和運(yùn)維簡(jiǎn)單。VXLAN是一種疊加的網(wǎng)絡(luò)隧道技術(shù)，將二層數(shù)據(jù)幀封裝在三層UDP數(shù)據(jù)包里傳輸，需要路由轉(zhuǎn)換，封包和解包等，性能相對(duì)VLAN要差些，同時(shí)架構(gòu)也更復(fù)雜，好處是支持1600多萬(wàn)個(gè)網(wǎng)絡(luò)，擴(kuò)展性好。

如果，企業(yè)用戶在相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)，云平臺(tái)規(guī)模都較小(比如在1萬(wàn)臺(tái)虛擬機(jī)數(shù)量以下)，且對(duì)多租戶網(wǎng)絡(luò)安全隔離性要求不高，那么可以使用VLan 網(wǎng)絡(luò)。反之，如果網(wǎng)絡(luò)安全隔離性需求壓倒一切，或者云平臺(tái)規(guī)模非常大，則可以使用VXLan 網(wǎng)絡(luò)方案。

在VXLAN和VLan 網(wǎng)絡(luò)通信，即租戶私網(wǎng)和Floating IP外網(wǎng)路由轉(zhuǎn)發(fā)通信背景下，默認(rèn)在OpenStack傳統(tǒng)的集中式路由環(huán)境中，南北流量和跨網(wǎng)絡(luò)的東西流量都要經(jīng)過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)，當(dāng)計(jì)算節(jié)點(diǎn)規(guī)模越來(lái)越大的時(shí)候，網(wǎng)絡(luò)節(jié)點(diǎn)很快會(huì)成為整個(gè)系統(tǒng)的瓶頸，為解決這個(gè)問(wèn)題引入了Distribute Virtual Router (DVR)的概念。使用DVR方案，可以將路由分布到計(jì)算節(jié)點(diǎn)，南北流量和跨網(wǎng)段的東西流量由虛機(jī)所在計(jì)算節(jié)點(diǎn)上的虛擬路由進(jìn)行路由，從而提高穩(wěn)定性和性能。

備份云平臺(tái)數(shù)據(jù)

俗話說(shuō)，有備份在，睡覺(jué)也踏實(shí)。在一個(gè)實(shí)際的環(huán)境中，由于種種原因，可能發(fā)生數(shù)據(jù)被刪除的情況。比如，云平臺(tái)中的數(shù)據(jù)庫(kù)、虛擬機(jī)、數(shù)據(jù)卷、鏡像或底層存儲(chǔ)被刪除等，如果數(shù)據(jù)沒(méi)有進(jìn)行備份，則是災(zāi)難性的后果。

在一個(gè)由OpenStack+Ceph架構(gòu)組成的云平臺(tái)環(huán)境中，有N種數(shù)據(jù)備份方案。如OpenStack有自帶的Karbor、Freezer云服務(wù)，Ceph也有相關(guān)的備份方案，也有其他商業(yè)的備份方案等。實(shí)際上，OpenStack云平臺(tái)本身也提供了一些較好易用的備份功能，比如虛擬機(jī)快照/備份、數(shù)據(jù)卷快照/備份，在使用時(shí)也倡導(dǎo)通過(guò)將數(shù)據(jù)卷掛載給虛擬機(jī)，從而將數(shù)據(jù)寫(xiě)入到云盤(pán)中，間接的實(shí)現(xiàn)數(shù)據(jù)容災(zāi)備份。

如果因?yàn)槟承┰颍瑳](méi)有跨物理機(jī)房或地區(qū)的Region和AZ。那么OpenStack云平臺(tái)相關(guān)的數(shù)據(jù)備份，則是必須要做的。比如MySQL數(shù)據(jù)庫(kù)等，可以根據(jù)實(shí)際需求，每隔幾小時(shí)進(jìn)行一次備份。而備份的數(shù)據(jù)，建議存放到其他機(jī)器上。關(guān)于Ceph的底層存儲(chǔ)備份方案，可以使用RBD Mirroring方案。

RBD Mirroring是Ceph新的異步備份功能。支持配置兩個(gè)Ceph Cluster之間的rbd同步。在此方案下，Master Cluster使用性能較高的存儲(chǔ)設(shè)備，提供給OpenStack的Glance、Cinder(cinder-volume、cinder-backup)和Nova服務(wù)使用;而B(niǎo)ackup Cluster則使用容量空間大且廉價(jià)的存儲(chǔ)設(shè)備(如SATA盤(pán))來(lái)備份Ceph數(shù)據(jù)。不同的Ceph Cluster集群，可以根據(jù)實(shí)際需要，選擇是否跨物理機(jī)房備份。如下圖所示。

優(yōu)點(diǎn)：

• Ceph新的功能，不需要額外開(kāi)發(fā)
• 同步的粒度比較小，為一個(gè)塊設(shè)備的transaction
• 保證了Crash consistency
• 可配置pool的備份，也可單獨(dú)指定image備份
• 同步備份，不同機(jī)房的Ceph集群，底層存儲(chǔ)的跨機(jī)房容災(zāi)

使用合適的Docker存儲(chǔ)

如果，OpenStack云平臺(tái)是用kolla容器化部署和管理的。那么選擇一個(gè)正確、合適的Docker存儲(chǔ)，關(guān)乎你的平臺(tái)穩(wěn)定和性能。

Docker 使用存儲(chǔ)驅(qū)動(dòng)來(lái)管理鏡像每層內(nèi)容及可讀寫(xiě)的容器層，存儲(chǔ)驅(qū)動(dòng)有 devicemapper、aufs、overlay、overlay2、btrfs、zfs 等，不同的存儲(chǔ)驅(qū)動(dòng)實(shí)現(xiàn)方式有差異，鏡像組織形式可能也稍有不同，但都采用棧式存儲(chǔ)，并采用 Copy-on-Write(CoW) 策略。且存儲(chǔ)驅(qū)動(dòng)采用熱插拔架構(gòu)，可動(dòng)態(tài)調(diào)整。那么，存儲(chǔ)驅(qū)動(dòng)那么多，該如何選擇合適的呢?大致可從以下幾方面考慮：

• 若內(nèi)核支持多種存儲(chǔ)驅(qū)動(dòng)，且沒(méi)有顯式配置，Docker 會(huì)根據(jù)它內(nèi)部設(shè)置的優(yōu)先級(jí)來(lái)選擇。優(yōu)先級(jí)為 aufs > btrfs/zfs > overlay2 > overlay > devicemapper。若使用 devicemapper 的話，在生產(chǎn)環(huán)境，一定要選擇 direct-lvm, loopback-lvm 性能非常差。
• 選擇會(huì)受限于 Docker 版本、操作系統(tǒng)、系統(tǒng)版本等。例如，aufs 只能用于 Ubuntu 或 Debian 系統(tǒng)，btrfs 只能用于 SLES (SUSE Linux Enterprise Server, 僅 Docker EE 支持)。
• 有些存儲(chǔ)驅(qū)動(dòng)依賴于后端的文件系統(tǒng)。例如，btrfs 只能運(yùn)行于后端文件系統(tǒng) btrfs 上。
• 不同的存儲(chǔ)驅(qū)動(dòng)在不同的應(yīng)用場(chǎng)景下性能不同。例如，aufs、overlay、overlay2 操作在文件級(jí)別，內(nèi)存使用相對(duì)更高效，但大文件讀寫(xiě)時(shí)，容器層會(huì)變得很大;devicemapper、btrfs、zfs 操作在塊級(jí)別，適合工作在寫(xiě)負(fù)載高的場(chǎng)景;容器層數(shù)多，且寫(xiě)小文件頻繁時(shí)，overlay2 效率比 overlay更高;btrfs、zfs 更耗內(nèi)存。

Docker 容器其實(shí)是在鏡像的最上層加了一層讀寫(xiě)層，通常也稱為容器層。在運(yùn)行中的容器里做的所有改動(dòng)，如寫(xiě)新文件、修改已有文件、刪除文件等操作其實(shí)都寫(xiě)到了容器層。存儲(chǔ)驅(qū)動(dòng)決定了鏡像及容器在文件系統(tǒng)中的存儲(chǔ)方式及組織形式。在我們的生產(chǎn)環(huán)境中，使用的是Centos 7.4系統(tǒng)及其4.15內(nèi)核版本+Docker 1.13.1版本。因此使用的是overlay2存儲(chǔ)。下面對(duì)overlay2作一些簡(jiǎn)單介紹。

Overlay介紹

OverlayFS 是一種類似 AUFS 的聯(lián)合文件系統(tǒng)，但實(shí)現(xiàn)更簡(jiǎn)單，性能更優(yōu)。OverlayFS 嚴(yán)格來(lái)說(shuō)是 Linux 內(nèi)核的一種文件系統(tǒng)，對(duì)應(yīng)的 Docker 存儲(chǔ)驅(qū)動(dòng)為 overlay 或者 overlay2，overlay2 需 要Linux 內(nèi)核 4.0 及以上，overlay 需內(nèi)核 3.18 及以上。且目前僅 Docker 社區(qū)版支持。條件許可的話，盡量使用 overlay2，與 overlay 相比，它的 inode 利用率更高。

和AUFS的多層不同的是Overlay只有兩層：一個(gè)upper文件系統(tǒng)和一個(gè)lower文件系統(tǒng)，分別代表Docker的容器層和鏡像層。當(dāng)需要修改一個(gè)文件時(shí)，使用CoW將文件從只讀的lower復(fù)制到可寫(xiě)的upper進(jìn)行修改，結(jié)果也保存在upper層。在Docker中，底下的只讀層就是image，可寫(xiě)層就是Container。結(jié)構(gòu)如下圖所示：

分析

從kernel 3.18進(jìn)入主流Linux內(nèi)核。設(shè)計(jì)簡(jiǎn)單，速度快，比AUFS和Device mapper速度快。在某些情況下，也比Btrfs速度快。是Docker存儲(chǔ)方式選擇的未來(lái)。因?yàn)镺verlayFS只有兩層，不是多層，所以O(shè)verlayFS “copy-up”操作快于AUFS。以此可以減少操作延時(shí)。

OverlayFS支持頁(yè)緩存共享，多個(gè)容器訪問(wèn)同一個(gè)文件能共享一個(gè)頁(yè)緩存，以此提高內(nèi)存使用率。

OverlayFS消耗inode，隨著鏡像和容器增加，inode會(huì)遇到瓶頸。Overlay2能解決這個(gè)問(wèn)題。在Overlay下，為了解決inode問(wèn)題，可以考慮將/var/lib/docker掛在單獨(dú)的文件系統(tǒng)上，或者增加系統(tǒng)inode設(shè)置。

使用分布式存儲(chǔ)

如果OpenStack云平臺(tái)使用開(kāi)源的分布式存儲(chǔ)系統(tǒng)，如Ceph、GlusterFS等。如何保證存儲(chǔ)系統(tǒng)的冗余容災(zāi)性、可靠性、安全性和性能，便顯得尤為重要。這里，以Ceph開(kāi)源分布式存儲(chǔ)為例進(jìn)行講解。

Mon節(jié)點(diǎn)和OSD節(jié)點(diǎn)部署

一般地，在生產(chǎn)環(huán)境中，至少需要部署有3個(gè)Ceph Mon節(jié)點(diǎn)(數(shù)量最好為奇數(shù))以及多個(gè)OSD節(jié)點(diǎn)。

開(kāi)啟CephX認(rèn)證

同時(shí)，開(kāi)啟CephX認(rèn)證方式，以提高數(shù)據(jù)存儲(chǔ)的安全性，防范被攻擊。如下所示。 

  
 
 
 

   
  
  
  
# 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  
   
  
  
  
……… 
  
 
 
 

網(wǎng)絡(luò)配置

如果Ceph存儲(chǔ)節(jié)點(diǎn)規(guī)模較小，Ceph公共網(wǎng)絡(luò)(即Public Network)使用千兆網(wǎng)絡(luò)，集群網(wǎng)絡(luò)(即Cluster Network)使用萬(wàn)兆網(wǎng)絡(luò)即可。如果Ceph節(jié)點(diǎn)規(guī)模較大，且業(yè)務(wù)負(fù)載較高，則盡量都使用萬(wàn)兆網(wǎng)絡(luò)，在重要的環(huán)境上，Ceph公共網(wǎng)絡(luò)和集群網(wǎng)絡(luò)，都應(yīng)該單獨(dú)分開(kāi)。需要注意的是，Ceph存儲(chǔ)節(jié)點(diǎn)使用的網(wǎng)卡，必須要做網(wǎng)卡Bond，防止網(wǎng)卡因故障而導(dǎo)致網(wǎng)絡(luò)中斷。

使用Cache Tier

在一個(gè)云存儲(chǔ)環(huán)境中，出于成本的考慮，基本會(huì)少量使用SSD硬盤(pán)，大量使用SATA硬盤(pán)。在OpenStack集成Ceph的云環(huán)境中，如何使用SSD和SATA硬盤(pán)。一般有兩種使用方法。

• 第一種：分別創(chuàng)建獨(dú)立的SSD和SATA存儲(chǔ)資源集群。然后，Cinder塊存儲(chǔ)服務(wù)對(duì)接這兩套Ceph后端存儲(chǔ)，這樣云平臺(tái)便可以同時(shí)創(chuàng)建和使用SSD介質(zhì)和SATA介質(zhì)的云硬盤(pán)。
• 第二種：使用SSD硬盤(pán)創(chuàng)建容量相對(duì)較小但性能高的緩存池(Cache tier)，SATA硬盤(pán)創(chuàng)建容量大的但性能較低的存儲(chǔ)池(Storage tier)。

這里，以第二種方式為例進(jìn)行講解。當(dāng)客戶端訪問(wèn)操作數(shù)據(jù)時(shí)，會(huì)優(yōu)先讀寫(xiě)cache tier數(shù)據(jù)(當(dāng)然要根據(jù)cache mode來(lái)決定)，如果數(shù)據(jù)在storage tier 則會(huì)提升到cache tier中，在cache tier中會(huì)有請(qǐng)求命中算法、緩存刷寫(xiě)算法、緩存淘汰算法等，將熱數(shù)據(jù)提升到cache tier中，將冷數(shù)據(jù)下放到storage tier中。

緩存層代理自動(dòng)處理緩存層和后端存儲(chǔ)之間的數(shù)據(jù)遷移。在使用過(guò)程中，我們可以根據(jù)自己的需要，來(lái)配置遷移規(guī)則，主要有兩種場(chǎng)景：

回寫(xiě)模式： 管理員把緩存層配置為 writeback 模式時(shí)， Ceph 客戶端們會(huì)把數(shù)據(jù)寫(xiě)入緩存層、并收到緩存層發(fā)來(lái)的 ACK ;寫(xiě)入緩存層的數(shù)據(jù)會(huì)被遷移到存儲(chǔ)層、然后從緩存層刷掉。直觀地看，緩存層位于后端存儲(chǔ)層的“前面”，當(dāng) Ceph 客戶端要讀取的數(shù)據(jù)位于存儲(chǔ)層時(shí)，緩存層代理會(huì)把這些數(shù)據(jù)遷移到緩存層，然后再發(fā)往 Ceph 客戶端。從此， Ceph 客戶端將與緩存層進(jìn)行 I/O 操作，直到數(shù)據(jù)不再被讀寫(xiě)。此模式對(duì)于易變數(shù)據(jù)來(lái)說(shuō)較理想(如照片/視頻編輯、事務(wù)數(shù)據(jù)等)。

只讀模式： 管理員把緩存層配置為 readonly 模式時(shí)， Ceph 直接把數(shù)據(jù)寫(xiě)入后端。讀取時(shí)， Ceph 把相應(yīng)對(duì)象從后端復(fù)制到緩存層，根據(jù)已定義策略、臟對(duì)象會(huì)被緩存層踢出。此模式適合不變數(shù)據(jù)(如社交網(wǎng)絡(luò)上展示的圖片/視頻、 DNA 數(shù)據(jù)、 X-Ray 照片等)，因?yàn)閺木彺鎸幼x出的數(shù)據(jù)可能包含過(guò)期數(shù)據(jù)，即一致性較差。對(duì)易變數(shù)據(jù)不要用 readonly 模式。

獨(dú)立使用Pool

Ceph可以統(tǒng)一OpenStack Cinder塊存儲(chǔ)服務(wù)(cinder-volume、cinder-backup)、Nova計(jì)算服務(wù)和Glance鏡像服務(wù)的后端存儲(chǔ)。在生產(chǎn)環(huán)境上，建議單獨(dú)創(chuàng)建4個(gè)存儲(chǔ)資源池(Pool)以分別對(duì)應(yīng)OpenStack的4種服務(wù)存儲(chǔ)。同時(shí)，每個(gè)Pool的副本數(shù)建議設(shè)置為3份，如下表所示。

最后，Ceph分布式存儲(chǔ)部署架構(gòu)，如下圖所示。

用戶應(yīng)用層

在相當(dāng)多的業(yè)務(wù)中，都會(huì)涉及到服務(wù)高可用。而一般的高可用的實(shí)現(xiàn)都是通過(guò)VIP(Vitrual IP)實(shí)現(xiàn)。VIP不像IP一樣，對(duì)應(yīng)一個(gè)實(shí)際的網(wǎng)絡(luò)接口(網(wǎng)卡)，它是虛擬出來(lái)的IP地址，所以利用其特性可以實(shí)現(xiàn)服務(wù)的容錯(cuò)和遷移工作。

在常見(jiàn)節(jié)點(diǎn)中VIP配置非常簡(jiǎn)單，沒(méi)有多大的限制。但OpenStack實(shí)例中，一個(gè)IP對(duì)應(yīng)一個(gè)Port設(shè)備。并且Neutron 有“Allowed address pairs”限制，該功能要求 Port 的MAC/IP 相互對(duì)應(yīng)，那么該IP才能連通。對(duì)Port設(shè)備的進(jìn)行操作可以實(shí)現(xiàn)下面幾個(gè)功能：

1. 一個(gè)Port設(shè)備添加多組Allowed address Pairs，允許多個(gè)IP通過(guò)該P(yáng)ort連通。
2. 一個(gè)IP對(duì)應(yīng)多組MAC地址。
3.  一個(gè)MAC地址對(duì)應(yīng)多個(gè)IP

另外在OpenStack創(chuàng)建的實(shí)例中建立VIP并使其能正常工作可以使用下面方法：

• 創(chuàng)建VIP的Port設(shè)備(防止該VIP被再次分配)
• 更新Port設(shè)備的Allowed address pairs

第一步，創(chuàng)建Port設(shè)備

 

  
 
 
 

   
  
  
  
#source admin-openrc.sh //導(dǎo)入租戶環(huán)境變量  
   
  
  
  
#openstack network list //查看現(xiàn)有網(wǎng)絡(luò)，從中選擇創(chuàng)建port設(shè)備的網(wǎng)絡(luò)  
   
  
  
  
#openstack subnet list //查看網(wǎng)絡(luò)下存在子網(wǎng)，從中選擇port設(shè)備所處子網(wǎng)  
   
  
  
  
#openstack port create --network NetWork_Name --fixed-ip subnet=SubNet_Name,  
   
  
  
  
ip-address=IP Port_Name  
   
  
  
  
#openstack port show Port_Name 
  
 
 
 

此時(shí)Port設(shè)備已經(jīng)創(chuàng)建，但該P(yáng)ort設(shè)備與需要建立VIP的實(shí)例沒(méi)有任何關(guān)系，在該實(shí)例上創(chuàng)建VIP也是不能工作的。原因在于下面

  
 
 
 

   
  
  
  
#neutron port-list |grep Instance-IP //找到需要配置VIP的實(shí)例的Port ID 
  
 
 
 

查看該P(yáng)ort的詳細(xì)信息

  
 
 
 

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

此時(shí)的allowed_address_pairs為空，就算在該實(shí)例中創(chuàng)建VIP，其MAC/IP也是不對(duì)應(yīng)，不能工作的。那么就要進(jìn)行第二步，即更新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 
  
 
 
 

現(xiàn)在再來(lái)查看實(shí)例Port信息

  
 
 
 

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

此時(shí)在虛擬機(jī)中創(chuàng)建VIP，就能夠正常工作了。

運(yùn)維平臺(tái)建設(shè)

監(jiān)控是整個(gè)運(yùn)維乃至整個(gè)產(chǎn)品生命周期中最重要的一環(huán)，事前及時(shí)預(yù)警發(fā)現(xiàn)故障，事后提供詳實(shí)的數(shù)據(jù)用于追查定位問(wèn)題。目前業(yè)界有很多不錯(cuò)的開(kāi)源產(chǎn)品可供選擇。選擇一些開(kāi)源的監(jiān)控系統(tǒng)，是一個(gè)省時(shí)省力，效率最高的方案。

使用Kolla容器化部署和管理OpenStack云平臺(tái)，已成為主流趨勢(shì)。這里，我們以容器化部署和管理OpenStack云平臺(tái)為背景，聊聊云平臺(tái)相關(guān)的運(yùn)維平臺(tái)建設(shè)。

監(jiān)控目標(biāo)

我們先來(lái)了解什么是監(jiān)控、監(jiān)控的重要性以及監(jiān)控的目標(biāo)，當(dāng)然每個(gè)人所在的行業(yè)不同、公司不同、業(yè)務(wù)不同、崗位不同，對(duì)監(jiān)控的理解也不同，但是我們需要注意，監(jiān)控是需要站在公司的業(yè)務(wù)角度去考慮，而不是針對(duì)某個(gè)監(jiān)控技術(shù)的使用。

監(jiān)控的目標(biāo)，包括：

• 1)對(duì)系統(tǒng)不間斷實(shí)時(shí)監(jiān)控：實(shí)際上是對(duì)系統(tǒng)不間斷的實(shí)時(shí)監(jiān)控(這就是監(jiān)控);
• 2)實(shí)時(shí)反饋系統(tǒng)當(dāng)前狀態(tài)：我們監(jiān)控某個(gè)硬件、或者某個(gè)系統(tǒng)，都是需要能實(shí)時(shí)看到當(dāng)前系統(tǒng)的狀態(tài)，是正常、異常、或者故障;
• 3)保證服務(wù)可靠性安全性：我們監(jiān)控的目的就是要保證系統(tǒng)、服務(wù)、業(yè)務(wù)正常運(yùn)行;
• 4)保證業(yè)務(wù)持續(xù)穩(wěn)定運(yùn)行：如果我們的監(jiān)控做得很完善，即使出現(xiàn)故障，能第一時(shí)間接收到故障報(bào)警，在第一時(shí)間處理解決，從而保證業(yè)務(wù)持續(xù)性的穩(wěn)定運(yùn)行。

監(jiān)控體系分層

監(jiān)控有賴于運(yùn)維各專業(yè)條線協(xié)同完善，通過(guò)將監(jiān)控體系進(jìn)行分層、分類，各專業(yè)條線再去有重點(diǎn)的豐富監(jiān)控指標(biāo)。監(jiān)控的對(duì)象，主要有基礎(chǔ)設(shè)施硬件類和應(yīng)用軟件類等，如下圖所示：

• 硬件設(shè)施層：交換機(jī)、路由器、負(fù)載均衡設(shè)備、防火墻、服務(wù)器(硬盤(pán)、CPU、內(nèi)存和網(wǎng)卡)等。
• 云平臺(tái)層：日志、數(shù)據(jù)庫(kù)、消息隊(duì)列、操作系統(tǒng)、OpenStack服務(wù)、Ceph存儲(chǔ)、Docker容器、系統(tǒng)和應(yīng)用負(fù)載等。
• 應(yīng)用層：虛擬機(jī)、數(shù)據(jù)卷、虛擬網(wǎng)卡等。

監(jiān)控手段

通常情況下，隨著系統(tǒng)的運(yùn)行，操作系統(tǒng)會(huì)產(chǎn)生系統(tǒng)日志，應(yīng)用程序會(huì)產(chǎn)生應(yīng)用程序的訪問(wèn)日志、錯(cuò)誤日志、運(yùn)行日志、網(wǎng)絡(luò)日志，我們可以使用 EFK 來(lái)進(jìn)行日志監(jiān)控。對(duì)于日志監(jiān)控來(lái)說(shuō)，最常見(jiàn)的需求就是收集、存儲(chǔ)、查詢、展示。

除了對(duì)日志進(jìn)行監(jiān)控外，我們還需要對(duì)系統(tǒng)和應(yīng)用的運(yùn)行狀況進(jìn)行實(shí)時(shí)監(jiān)控。不同的監(jiān)控目標(biāo)，有不同的監(jiān)控手段。OpenStack云資源的監(jiān)控，如虛擬機(jī)、鏡像、數(shù)據(jù)卷、虛擬網(wǎng)卡等，天然的可以由OpenStack自帶的Ceilometer+Gnocchi+Aodh等服務(wù)來(lái)做(PS：ceilometer可以將采集數(shù)據(jù)交給gnocchi做數(shù)據(jù)聚合，最后用grafana展現(xiàn)報(bào)表)。

如果，OpenStack云平臺(tái)是基于Kolla容器化部署和運(yùn)行管理的。那么諸如Docker容器、操作系統(tǒng)負(fù)載、存儲(chǔ)空間等，又該使用什么來(lái)運(yùn)維監(jiān)控并告警呢。自然，TPIG棧便呼之欲出了。

什么是TPIG棧。即由Telegraf + Influxdb + Grafana + Prometheus組合成的一套運(yùn)維監(jiān)控工具集合。它們之間的關(guān)系是：

• Prometheus/Telegraf(收集數(shù)據(jù)) —-> Influxdb(保存數(shù)據(jù)) —-> Grafana(顯示數(shù)據(jù))

說(shuō)明：

Prometheus和Telegraf不是必須同時(shí)部署使用的，你可以根據(jù)自己的需要，選擇二者都部署，也可以二者選其一。

如下幾種開(kāi)源工具或方案，Kolla社區(qū)都是默認(rèn)支持的。最重要的是，如何去使用、完善它們。

• 日志收集和分析處理的開(kāi)源方案有EFK棧：fluentd/filebeat + elasticsearch +kibana
• 性能采集和分析處理的開(kāi)源方案有TPIG棧：telegraf + influxdb + grafana + Prometheus

監(jiān)控方法

• 了解監(jiān)控對(duì)象：我們要監(jiān)控的對(duì)象你是否了解呢?比如硬盤(pán)的IOPS?
• 對(duì)象性能指標(biāo)：我們要監(jiān)控這個(gè)東西的什么屬性?比如 CPU 的使用率、負(fù)載、用戶態(tài)、內(nèi)核態(tài)、上下文切換。
• 報(bào)警閾值定義：怎么樣才算是故障，要報(bào)警呢?比如 CPU 的負(fù)載到底多少算高，用戶態(tài)、內(nèi)核態(tài)分別跑多少算高?
• 故障處理流程：收到了故障報(bào)警，我們?cè)趺刺幚砟?有什么更高效的處理流程嗎?

監(jiān)控流程

• 數(shù)據(jù)采集：通過(guò)telegraf/Prometheus等對(duì)系統(tǒng)和應(yīng)用進(jìn)行數(shù)據(jù)采集;
• 數(shù)據(jù)存儲(chǔ)：監(jiān)控?cái)?shù)據(jù)存儲(chǔ)在MySQL、influxdb上，也可以存儲(chǔ)在其他數(shù)據(jù)庫(kù)中;
• 數(shù)據(jù)分析：當(dāng)我們事后需要分析故障時(shí)，EFK棧 能給我們提供圖形以及時(shí)間等相關(guān)信息，方面我們確定故障所在;
• 數(shù)據(jù)展示：web 界面展示;
• 監(jiān)控報(bào)警：電話報(bào)警、郵件報(bào)警、微信報(bào)警、短信報(bào)警、報(bào)警升級(jí)機(jī)制等(無(wú)論什么報(bào)警都可以);
• 報(bào)警處理：當(dāng)接收到報(bào)警，我們需要根據(jù)故障的級(jí)別進(jìn)行處理，比如:重要緊急、重要不緊急等。根據(jù)故障的級(jí)別，配合相關(guān)的人員進(jìn)行快速處理;

監(jiān)控告警

當(dāng)監(jiān)控的對(duì)象超過(guò)了某一閾值或者某一服務(wù)出現(xiàn)了異常時(shí)，便自動(dòng)發(fā)送郵件、短信或微信給相關(guān)人員進(jìn)行告警。

事件應(yīng)急響應(yīng)

運(yùn)維最基本的指標(biāo)就是保證系統(tǒng)的可用性，應(yīng)急恢復(fù)的時(shí)效性是系統(tǒng)可用性的關(guān)鍵指標(biāo)。通常來(lái)講應(yīng)急恢復(fù)的方法有不少，比如：

• 服務(wù)整體性能下降或異常，可以考慮重啟服務(wù);
• 應(yīng)用做過(guò)變更，可以考慮是否需要回切變更;
• 資源不足，可以考慮應(yīng)急擴(kuò)容;
• 應(yīng)用性能問(wèn)題，可以考慮調(diào)整應(yīng)用參數(shù)、日志參數(shù);
• 數(shù)據(jù)庫(kù)繁忙，可以考慮通過(guò)數(shù)據(jù)庫(kù)快照分析，優(yōu)化SQL;
• 應(yīng)用功能設(shè)計(jì)有誤，可以考慮緊急關(guān)閉功能菜單;
• 還有很多……

一些所見(jiàn)所想

現(xiàn)實(shí)中，不乏遇到一些拿來(lái)主義。即將Hadoop/Spark大數(shù)據(jù)業(yè)務(wù)跑在虛擬機(jī)中運(yùn)行，然后到了線上出現(xiàn)各種坑。如磁盤(pán)IO性能非常差，虛擬機(jī)搶占宿主機(jī)資源，導(dǎo)致其CPU使用率超過(guò)700%等等，最后掉入自己挖的坑里。

須知，云計(jì)算的本質(zhì)是虛擬化，虛擬化的本質(zhì)是一虛多，即將一個(gè)個(gè)物理的計(jì)算資源、網(wǎng)絡(luò)資源和存儲(chǔ)資源等虛擬化成多個(gè)邏輯資源(如KVM、openvswitch、ceph)，再由資源調(diào)度管理系統(tǒng)(如OpenStack)抽象化提供給用戶使用。而大數(shù)據(jù)的本質(zhì)是多虛一，將多個(gè)計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源統(tǒng)一管理集中起來(lái)提供給大數(shù)據(jù)業(yè)務(wù)使用。

OpenStack可以統(tǒng)一管理虛擬機(jī)和裸機(jī)。推薦的做法應(yīng)是將大數(shù)據(jù)放在裸機(jī)上跑，而不是放在虛擬機(jī)上跑。違背了技術(shù)的本質(zhì)，注定過(guò)程會(huì)很痛苦。

有的用戶在上云或用云過(guò)程中，時(shí)常會(huì)糾結(jié)到底使用什么方案才好?比如使用OpenvSwitch還是LinuxBridge?使用VLAN還是VXLAN、GRE?使用Ceph還是GlusterFS、商業(yè)存儲(chǔ)?要不要做二次開(kāi)發(fā)等?須知，從來(lái)不是技術(shù)決定需求，而是需求決定技術(shù)選型。同樣的，選擇使用什么技術(shù)，應(yīng)該由你的實(shí)際需求來(lái)決定。適合自己的才是最好的。只能說(shuō)二者各有優(yōu)缺點(diǎn)，用戶需要做的是根據(jù)實(shí)際需求，規(guī)避掉風(fēng)險(xiǎn)點(diǎn)最大的，選擇優(yōu)勢(shì)最明顯的那個(gè)方案。

在準(zhǔn)備使用OpenStack時(shí)，一定要明確OpenStack是一個(gè)知識(shí)密集型的開(kāi)源云框架，記住是一個(gè)框架，而不是一個(gè)開(kāi)箱即用的產(chǎn)品。所需要的各方面技術(shù)人才和技術(shù)儲(chǔ)備是非常廣泛的，企業(yè)通常會(huì)面臨人才缺乏問(wèn)題，一方面很難從外部招到有經(jīng)驗(yàn)的人，另一方面是企業(yè)培養(yǎng)內(nèi)部人才耗時(shí)耗力。如果企業(yè)只是將OpenStack做私有云供自己使用，功能需求或業(yè)務(wù)并不復(fù)雜，比如用來(lái)代替價(jià)格昂貴的VMware提供虛擬機(jī)業(yè)務(wù)，那么一般不需要進(jìn)行二次開(kāi)發(fā)。反之，將OpenStack作為一個(gè)云產(chǎn)品提供給第三方用戶使用或者滿足自身復(fù)雜業(yè)務(wù)需求，那么進(jìn)行二次開(kāi)發(fā)是必要的，比如統(tǒng)一云資源管理、資源邏輯調(diào)度、運(yùn)維監(jiān)控告警、Iaas+PaaS+SaaS統(tǒng)一支持等。實(shí)際中，一些企業(yè)負(fù)責(zé)人把OpenStack定位成阿里云、AWS來(lái)開(kāi)發(fā)，要么是高估了自己的能力，要么是低估了OpenStack的難度，覺(jué)得只是修改一個(gè)Dashboard而已，最后陷入死循環(huán)。

最后

隨著技術(shù)的演化，平臺(tái)復(fù)雜化+用戶簡(jiǎn)單化的趨勢(shì)將越來(lái)越明顯。這就要求最終呈現(xiàn)給用戶使用的系統(tǒng)必須是極簡(jiǎn)的。我相信，OpenStack朝著這方面努力，把企業(yè)用戶的剛需轉(zhuǎn)變?yōu)楝F(xiàn)實(shí)可操作性，前途會(huì)更光明!

最后，感謝OpenStack和引領(lǐng)我入門(mén)的前公司領(lǐng)導(dǎo)和同事，為我打開(kāi)了一扇走進(jìn)云計(jì)算的大門(mén)!同時(shí)也希望，有那么一日，OpenStack云計(jì)算能從大企業(yè)才能享用的舶來(lái)品，進(jìn)入尋常企業(yè)家。

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

作者介紹：

徐超，OpenStack、Kubernetes、Docker、CI/CD從業(yè)者和學(xué)習(xí)者，《OpenStack最佳實(shí)踐-測(cè)試與CI/CD》一書(shū)作者，OpenStack開(kāi)源社區(qū)參與者。

文章標(biāo)題：4年！我對(duì)OpenStack運(yùn)維架構(gòu)的總結(jié)
文章分享：http://m.fisionsoft.com.cn/article/dphojgp.html