前言

應北極熊之邀，寫點東西。思來想去云計算范疇實在廣泛，自然就聊點最近話題異常火熱，讓廣大云計算從業(yè)者愛之深、痛之切，想說一聲愛你，不容易的OpenStack吧。

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

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

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

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

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

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

交換機設(shè)備

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

服務(wù)器

網(wǎng)卡

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

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

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

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

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

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

硬盤

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

CPU

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

內(nèi)存

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

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

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

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

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)易私有云的實踐是關(guān)閉 KVM 內(nèi)存共享，打開透明大頁： 

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ù)說，經(jīng)過 SPEC CPU2006 測試，這些配置對云主機 CPU 性能大概有7%左右的提升。

OpenStack云平臺層

云平臺高可用(HA)

高可用(HA)介紹

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

對 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：幾年宕機幾分鐘。

服務(wù)的分類

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

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

HA 的種類

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

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

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

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

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

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

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

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

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

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

控制節(jié)點HA

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

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

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

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

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

RabbitMQ 消息隊列HA

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

OpenStack API服務(wù)HA

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

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

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

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

存儲節(jié)點HA

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

計算節(jié)點和虛擬機 HA

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

① 監(jiān)控

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

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

② 隔離

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

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

③ 恢復

恢復就是將狀態(tài)為down的計算節(jié)點上的虛擬機遷移到其他計算節(jié)點上。Pacemaker集群會調(diào)用host-evacuate API將所有虛擬機遷移。host-evacuate最后是使用rebuild來遷移虛擬機，每個虛擬機都會通過scheduler調(diào)度在不同的計算節(jié)點上啟動。

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

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

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

OpenStack計算資源限制

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

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

ram_allocation_ratio = 1 

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

reserved_host_memory_mb = 10240 //如預留10GB 

設(shè)置CPU

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

vcpu_pin_set = 4-31 

物理 CPU 超售比例，默認是 16 倍，超線程也算作一個物理 CPU

cpu_allocation_ratio = 8 

使用多Region和AZ

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

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

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

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

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

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

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

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

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

多Availability Zone部署

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

Availability Zone

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

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

Host Aggregate

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

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

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

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

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

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

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

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

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

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

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

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

優(yōu)點：

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

使用合適的Docker存儲

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

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

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

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

Overlay介紹

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

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

分析

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

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

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

使用分布式存儲

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

Mon節(jié)點和OSD節(jié)點部署

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

開啟CephX認證

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

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

使用Cache Tier

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

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

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

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

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

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

獨立使用Pool

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

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

用戶應用層

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

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

1. 一個Port設(shè)備添加多組Allowed address Pairs，允許多個IP通過該Port連通。
2. 一個IP對應多組MAC地址。
3.  一個MAC地址對應多個IP

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

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

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

 

#source admin-openrc.sh //導入租戶環(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 

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

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

查看該Port的詳細信息

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

此時的allowed_address_pairs為空，就算在該實例中創(chuàng)建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 

現(xiàn)在再來查看實例Port信息

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

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

運維平臺建設(shè)

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

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

監(jiān)控目標

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

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

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

監(jiān)控體系分層

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

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

監(jiān)控手段

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

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

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

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

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

說明：

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

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

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

監(jiān)控方法

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

監(jiān)控流程

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

監(jiān)控告警

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

事件應急響應

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

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

一些所見所想

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

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

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

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

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

最后

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

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

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

作者介紹：

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