這篇文章主要介紹怎么構(gòu)建OpenStack的高可用性，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

創(chuàng)新互聯(lián)公司主要為客戶提供服務(wù)項(xiàng)目涵蓋了網(wǎng)頁視覺設(shè)計(jì)、VI標(biāo)志設(shè)計(jì)、全網(wǎng)整合營銷推廣、網(wǎng)站程序開發(fā)、HTML5響應(yīng)式成都網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站建設(shè)、微商城、網(wǎng)站托管及成都網(wǎng)站維護(hù)、WEB系統(tǒng)開發(fā)、域名注冊(cè)、國內(nèi)外服務(wù)器租用、視頻、平面設(shè)計(jì)、SEO優(yōu)化排名。設(shè)計(jì)、前端、后端三個(gè)建站步驟的完善服務(wù)體系。一人跟蹤測(cè)試的建站服務(wù)標(biāo)準(zhǔn)。已經(jīng)為軟裝設(shè)計(jì)行業(yè)客戶提供了網(wǎng)站設(shè)計(jì)服務(wù)。

1、CAP理論

1） CAP 理論給出了3個(gè)基本要素：

• 一致性 ( Consistency) ：任何一個(gè)讀操作總是能讀取到之前完成的寫操作結(jié)果；

• 可用性 ( Availability) ：每一個(gè)操作總是能夠在確定的時(shí)間內(nèi)返回；

• 分區(qū)可容忍性 (Tolerance of network Partition) ：在出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況下，仍然能夠滿足一致性和可用性；

  CAP 理論指出，三者不能同時(shí)滿足。對(duì)這個(gè)理論有不少異議，但是它的參考價(jià)值依然巨大。

  這個(gè)理論并不能為不滿足這3個(gè)基本要求的設(shè)計(jì)提供借口，只是說明理論上3者不可絕對(duì)的滿足，而且工程上從來不要求絕對(duì)的一致性或者可用性，但是必須尋求一種平衡和***。

  對(duì)于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求。因此設(shè)計(jì)分布式數(shù)據(jù)系統(tǒng)，很多時(shí)候是在一致性和可用性（可靠性）之間尋求一個(gè)平衡。更多的系統(tǒng)性能和架構(gòu)的討論也是圍繞一致性和可用性展開。

2） OpenStack、Swift與CAP的工程實(shí)踐

  對(duì)照CAP理論，OpenStack的分布式對(duì)象存儲(chǔ)系統(tǒng)Swift滿足了可用性和分區(qū)容忍性，沒有保證一致性（可選的），只是實(shí)現(xiàn)了最終一致性。Swift如果GET操作沒有在請(qǐng)求頭中包含’X-Newest’頭，那么這次讀取有可能讀到的不是***的object，在一致性窗口時(shí)間內(nèi)object沒有被更新，那么后續(xù)GET操作讀取的object將是***的，保證了最終一致性；反之包含了’X-Newest’頭，GET操作始終能讀取到***的obejct，就是一致的。

在OpenStack架構(gòu)中，對(duì)于高可用性需要進(jìn)行很多工作來保證。因此，下面將對(duì)OpenStack結(jié)構(gòu)中的可用性進(jìn)行討論：

2、OpenStack的高可用性（OpenStack HA）

  要弄清楚怎么實(shí)現(xiàn)高可用性，就需要知道哪些服務(wù)容易出現(xiàn)不可靠。首先了解一些OpenStack的大致結(jié)構(gòu)。

  OpenStack由5大組件組成（計(jì)算nova，身份管理keystone，鏡像管理glance，前端管理dashboard和對(duì)象存儲(chǔ)swift）。

  nova是計(jì)算、控制的核心組件，它又包括nova-compute、nova-scheduler、nova-volume、nova-network和nova-api等服務(wù)。借用http://ken.people.info的以下這幅圖了解OpenStack的5大組件和功能：

下面這幅圖描述了各個(gè)組件的功能和服務(wù)結(jié)構(gòu)：

 同其它大部分分布式系統(tǒng)一樣，OpenStack也分為控制節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)兩種不同功能的節(jié)點(diǎn)。控制節(jié)點(diǎn)提供除nova-compute以外的服務(wù)。這些組件和服務(wù)都是可以獨(dú)立安裝的，可以選擇組合。

  nova-compute在每個(gè)計(jì)算節(jié)點(diǎn)運(yùn)行，暫且假設(shè)它是可信任的；或者使用備份機(jī)來實(shí)現(xiàn)故障轉(zhuǎn)移（不過每個(gè)計(jì)算節(jié)點(diǎn)配置備份的代價(jià)相比收益似乎太大）。

控制節(jié)點(diǎn)的高可靠性是主要問題，而且對(duì)于不同的組件都有自己的高可靠性需求和方案。

（1）由于CotrolNode只有１個(gè)，且負(fù)責(zé)整個(gè)系統(tǒng)的管理和控制，因此當(dāng)Cotrol Node不能提供正常服務(wù)時(shí)，怎么辦？這就是常見的單節(jié)點(diǎn)故障（SPoF，single point of failure）問題。

高可用性基本上是沒辦法通過一臺(tái)來達(dá)到目標(biāo)的，更多的時(shí)候是設(shè)計(jì)方案確保在出問題的時(shí)候盡快接管故障機(jī)器，當(dāng)然這要付出更大的成本。

對(duì)于單點(diǎn)問題，解決的方案一般是采用冗余設(shè)備或者熱備，因?yàn)橛布腻e(cuò)誤或者人為的原因，總是有可能造成單個(gè)或多個(gè)節(jié)點(diǎn)的失效，有時(shí)做節(jié)點(diǎn)的維護(hù)或者升級(jí)，也需要暫時(shí)停止某些節(jié)點(diǎn)，所以一個(gè)可靠的系統(tǒng)必須能承受單個(gè)或多個(gè)節(jié)點(diǎn)的停止。

常見的部署模式有：Active-passive主備模式，Active-active雙主動(dòng)模式，集群模式。

（2）那么如何構(gòu)建冗余的控制節(jié)點(diǎn)？或者什么其它方法實(shí)現(xiàn)高可靠的控制？

很多人可能想到實(shí)現(xiàn)active-passive模式，使用心跳機(jī)制或者類似的方法進(jìn)行備份，通過故障轉(zhuǎn)移來實(shí)現(xiàn)高可靠性。Openstack是沒有多個(gè)控制節(jié)點(diǎn)的，Pacemaker需要多種服務(wù)各自實(shí)現(xiàn)這種備份、監(jiān)聽和切換。

仔細(xì)分析控制節(jié)點(diǎn)提供的服務(wù)，主要就是nova-api、nova-network、nova-schedule、nova-volume，以及glance、keysonte和數(shù)據(jù)庫MySQL等，這些服務(wù)是分開提供的。nova-api、nova-network、glance等可以分別在每個(gè)計(jì)算節(jié)點(diǎn)上工作，RabbitMQ可以工作在主備模式，mysql可以使用冗余的高可用集群。

下面分別介紹：

1）nova-api和nova-scheduler的高可靠性

每個(gè)計(jì)算節(jié)點(diǎn)可以運(yùn)行自己的nova-api和nova-scheduler，提供負(fù)載均衡來保證這樣正確工作。

這樣當(dāng)控制節(jié)點(diǎn)出現(xiàn)故障，計(jì)算節(jié)點(diǎn)的nova-api等服務(wù)都照常進(jìn)行。

2）nova-volume的高可靠性

對(duì)于nova-volume目前沒有完善的HA（high availability）方法，還需要做很多工作。

不過，nova-volume由iSCSI驅(qū)動(dòng)，這個(gè)協(xié)議與DRBD結(jié)合，或者基于iSCSI的高可靠的硬件解決方案，可以實(shí)現(xiàn)高可靠。

3） 網(wǎng)絡(luò)服務(wù)nova-network的高可靠性

OpenStack的網(wǎng)絡(luò)已經(jīng)存在多種高可靠的方案，常用的你只需要使用 --multi_host 選項(xiàng)就可以讓網(wǎng)絡(luò)服務(wù)處于高可用模式（high availability mode），具體介紹見Existing High Availability Options for Networking。

方案1: Multi-host

多主機(jī)。每個(gè)計(jì)算節(jié)點(diǎn)上配置nova-network。這樣，每個(gè)計(jì)算節(jié)點(diǎn)都會(huì)實(shí)現(xiàn)NAT, DHCP和網(wǎng)關(guān)的功能，必然需要一定的開銷，可以與hardware gateway方式結(jié)合，避免每個(gè)計(jì)算節(jié)點(diǎn)的網(wǎng)關(guān)功能。這樣，每個(gè)計(jì)算節(jié)點(diǎn)都需要安裝nova-compute外還要nova-network和nova-api，并且需要能連接外網(wǎng)。具體介紹見Nova Multi-host Mode against SPoF。

方案2: Failover

故障轉(zhuǎn)移。能夠4秒轉(zhuǎn)移到熱備份上，詳細(xì)介紹見https://lists.launchpad.net/openstack/msg02099.html。不足之處是，需要備份機(jī)，而且有4秒延遲。

方案3: Multi-nic

多網(wǎng)卡技術(shù)。把VM橋接到多個(gè)網(wǎng)絡(luò)，VM就擁有2種傳出路由，實(shí)現(xiàn)故障時(shí)切換。但是這需要監(jiān)聽多個(gè)網(wǎng)絡(luò)，也需要設(shè)計(jì)切換策略。

方案4: Hardware gateway

硬件網(wǎng)關(guān)。需要配置外部網(wǎng)關(guān)。由于VLAN模式需要對(duì)每個(gè)網(wǎng)絡(luò)有一個(gè)網(wǎng)關(guān)，而hardware gateway方式只能對(duì)所有實(shí)例使用一個(gè)網(wǎng)關(guān)，因此不能在VLAN模式下使用。

方案5： Quantum（OpenStack下一個(gè)版本Folsom中）

Quantum的目標(biāo)是逐步實(shí)現(xiàn)功能完備的虛擬網(wǎng)絡(luò)服務(wù)。它暫時(shí)會(huì)繼續(xù)兼容舊的nova-network的功能如Flat、Flatdhcp等。但是實(shí)現(xiàn)了類似multi_host的功能，支持OpenStack工作在主備模式（active-backup這種高可用性模式）。

Quantum只需要一個(gè)nova-network的實(shí)例運(yùn)行，因此不能與multi_host模式共同工作。

Quantum允許單個(gè)租戶擁有多個(gè)私人專用L2網(wǎng)絡(luò)，通過加強(qiáng)QoS，以后應(yīng)該能使hadoop集群很好的在nova節(jié)點(diǎn)上工作。

對(duì)于Quantum的安裝使用，這篇文章Quantum Setup 有介紹。

4） glance、keystone的高可靠性

OpenStack的鏡像可以使用swift存儲(chǔ)，glance可以運(yùn)行在多個(gè)主機(jī)。Integrating OpenStack ImageService (Glance) with Swift  介紹了glance使用swift存儲(chǔ)。

集群管理工具 Pacemaker 是強(qiáng)大的高可用性解決方案，能夠管理多節(jié)點(diǎn)集群，實(shí)現(xiàn)服務(wù)切換和轉(zhuǎn)移，可與Corosync 和 Heartbeat等配套使用。Pacemaker 能夠較為靈活的實(shí)現(xiàn)主備、N+1 、N-N 等多種模式。

bringing-high-availability-openstack-keystone-and-glance介紹了如何通過Pacemaker實(shí)現(xiàn)keystone和glance的高可靠。在每個(gè)節(jié)點(diǎn)安裝OCF代理后，它能夠告訴一個(gè)節(jié)點(diǎn)另一個(gè)節(jié)點(diǎn)是否正常運(yùn)行g(shù)lance和keysone服務(wù)，從而幫助Pacemaker開啟、停止和監(jiān)測(cè)這些服務(wù)。

5） Swift對(duì)象存儲(chǔ)的高可靠性

一般情況下，OpenStack的分布式對(duì)象存儲(chǔ)系統(tǒng)Swift的HA是不需要自己添加的。因?yàn)椋琒wift設(shè)計(jì)時(shí)就是分布式（沒有主控節(jié)點(diǎn)）、容錯(cuò)、冗余機(jī)制、數(shù)據(jù)恢復(fù)機(jī)制、可擴(kuò)展和高可靠的。以下是Swift的部分優(yōu)點(diǎn)，這也說明了這點(diǎn)。

Built-in Replication(N copies of accounts, container, objects) 3x+ data redundancy compared to 2x on RAID 內(nèi)建冗余機(jī)制 RAID技術(shù)只做兩個(gè)備份，而Swift最少有3個(gè)備份	High Availability 高可靠性
Easily add capacity unlike RAID resize 可以方便地進(jìn)行存儲(chǔ)擴(kuò)容	Elastic data scaling with ease 方便的擴(kuò)容能力
No central database 沒有中心節(jié)點(diǎn)	Higher performance, No bottlenecks 高性能，無瓶頸限制

6） 消息隊(duì)列服務(wù)RabbitMQ的高可靠性

RabbitMQ失效就會(huì)導(dǎo)致丟失消息，可以有多種HA機(jī)制：

• publisher confirms 方法可以在故障時(shí)通知什么寫入了磁盤。

• 多機(jī)集群機(jī)制，但是節(jié)點(diǎn)失效容易導(dǎo)致隊(duì)列失效。

• 主備模式（active-passive），能夠?qū)崿F(xiàn)故障時(shí)轉(zhuǎn)移，但是啟動(dòng)備份機(jī)可能需要延遲甚至失效。

在容災(zāi)與可用性方面，RabbitMQ提供了可持久化的隊(duì)列。能夠在隊(duì)列服務(wù)崩潰的時(shí)候，將未處理的消息持久化到磁盤上。為了避免因?yàn)榘l(fā)送消息到寫入消息之間的延遲導(dǎo)致信息丟失，RabbitMQ引入了Publisher Confirm機(jī)制以確保消息被真正地寫入到磁盤中。它對(duì)Cluster的支持提供了Active/Passive與Active/Active兩種模式。例如，在Active/Passive模式下，一旦一個(gè)節(jié)點(diǎn)失敗，Passive節(jié)點(diǎn)就會(huì)馬上被激活，并迅速替代失敗的Active節(jié)點(diǎn)，承擔(dān)起消息傳遞的職責(zé)。如圖所示：

圖 Active/Passive Cluster（圖片來自RabbitMQ官方網(wǎng)站）

active-passive模式存在所說的問題，因此，基于RabbitMQ集群引入了一種雙主動(dòng)集群機(jī)制（active-active）解決了這些問題。http://www.rabbitmq.com/ha.html這篇文章詳細(xì)介紹了RabbitMQ的高可靠部署和原理。

7） 數(shù)據(jù)庫mysql的高可靠性

集群并不就是高可靠，常用的構(gòu)建高可靠的mysql的方法有Active-passive主備模式：使用DRBD實(shí)現(xiàn)主備機(jī)的災(zāi)容，Heartbeat或者Corosync做心跳監(jiān)測(cè)、服務(wù)切換甚至failover，Pacemaker實(shí)現(xiàn)服務(wù)（資源）的切換及控制等；或者類似的機(jī)制。其中主要使用Pacemaker實(shí)現(xiàn)了mysql的active-passive高可用集群。

一個(gè)重要的技術(shù)是DRBD：(distributed replication block device)即分布式復(fù)制塊設(shè)備，經(jīng)常被用來代替共享磁盤。

它的工作原理是：在A主機(jī)上有對(duì)指定磁盤設(shè)備寫請(qǐng)求時(shí)，數(shù)據(jù)發(fā)送給A主機(jī)的kernel，然后通過kernel中的一個(gè)模塊，把相同的數(shù)據(jù)傳送給B主機(jī)的kernel中一份，然后B主機(jī)再寫入自己指定的磁盤設(shè)備，從而實(shí)現(xiàn)兩主機(jī)數(shù)據(jù)的同步,也就實(shí)現(xiàn)了寫操作高可用。DRBD一般是一主一從，并且所有的讀寫操作，掛載只能在主節(jié)點(diǎn)服務(wù)器上進(jìn)行，，但是主從DRBD服務(wù)器之間是可以進(jìn)行調(diào)換的。這里有對(duì) DRBD 的介紹。

HAforNovaDB - OpenStack介紹了只使用共享磁盤而沒有使用DRBD，通過Pacemaker實(shí)現(xiàn)OpenStack的高可靠。

NovaZooKeeperHeartbeat介紹了使用ZooKeeper作心跳檢測(cè)。

MySQL HA with Pacemaker 介紹了使用Pacemaker提供高可靠服務(wù)，這也是很常見的解決方案。

Galera 是針對(duì)Mysql/InnoDB的同步的多master集群的開源項(xiàng)目，提供了很多的優(yōu)點(diǎn)（如同步復(fù)制、讀寫到任意節(jié)點(diǎn)、自動(dòng)成員控制、自動(dòng)節(jié)點(diǎn)加入、較小延遲等），可以參考。

Pacemaker與DRBD、Mysql的工作模式可以參考下圖：

其它的方案，根據(jù) MySQLPerformance Blog 的說法，MySQL幾種高可用解決方案能達(dá)到的可用性如下：

3、構(gòu)建高可用性的OpenStack（High-availability OpenStack）

一般來說，高可用性也就是建立冗余備份，常用策略有：

• 集群工作模式。多機(jī)互備，這樣模式是把每個(gè)實(shí)例備份多份，沒有中心節(jié)點(diǎn)，比如分布式對(duì)象存儲(chǔ)系統(tǒng)Swift、nova-network多主機(jī)模式。

• 自主模式。有時(shí)候，解決單點(diǎn)故障（SPoF）可以簡單的使用每個(gè)節(jié)點(diǎn)自主工作，通過去主從關(guān)系來減少主控節(jié)點(diǎn)失效帶來的問題，比如nova-api只負(fù)責(zé)自己所在節(jié)點(diǎn)。

• 主備模式。常見的模式active-passive，被動(dòng)節(jié)點(diǎn)處于監(jiān)聽和備份模式，故障時(shí)及時(shí)切換，比如mysql高可用集群、glance、keystone使用Pacemaker和Heartbeat等來實(shí)現(xiàn)。

• 雙主模式。這種模式互備互援，RabbitMQ就是active-active集群高可用性，集群中的節(jié)點(diǎn)可進(jìn)行隊(duì)列的復(fù)制。從架構(gòu)上來說，這樣就不用擔(dān)心passive節(jié)點(diǎn)不能啟動(dòng)或者延遲太大了？

以上是“怎么構(gòu)建OpenStack的高可用性”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

本文題目：怎么構(gòu)建OpenStack的高可用性
本文URL：http://chinadenli.net/article28/jdsscp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、Google、建站公司、微信公眾號(hào)、網(wǎng)站策劃、網(wǎng)站改版

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)