1、CAP理論

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

• 一致性 ( Consistency) ：任何一個(gè)讀操作總是能讀取到之前完成的寫(xiě)操作結(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ì)提供借口，只是說(shuō)明理論上3者不可絕對(duì)的滿足，而且工程上從來(lái)不要求絕對(duì)的一致性或者可用性，但是必須尋求一種平衡和***。

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

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

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

   在OpenStack架構(gòu)中，對(duì)于高可用性需要進(jìn)行很多工作來(lái)保證。因此，下面將對(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ī)來(lái)實(shí)現(xiàn)故障轉(zhuǎn)移（不過(guò)每個(gè)計(jì)算節(jié)點(diǎn)配置備份的代價(jià)相比收益似乎太大）。

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

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

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

對(duì)于單點(diǎn)問(wè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)的停止。

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

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

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

仔細(xì)分析控制節(jié)點(diǎn)提供的服務(wù)，主要就是nova-api、nova-network、nova-schedule、nova-volume，以及glance、keysonte和數(shù)據(jù)庫(kù)mysql等，這些服務(wù)是分開(kāi)提供的。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ù)載均衡來(lái)保證這樣正確工作。

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

2）nova-volume的高可靠性

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

不過(guò)，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），具體介紹見(jiàn)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)的功能，必然需要一定的開(kāi)銷，可以與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)。具體介紹見(jiàn)Nova Multi-host Mode against SPoF。

方案2: Failover

故障轉(zhuǎn)移。能夠4秒轉(zhuǎn)移到熱備份上，詳細(xì)介紹見(jiàn)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)聽(tīng)多個(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ò)，通過(guò)加強(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介紹了如何通過(guò)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開(kāi)啟、停止和監(jiān)測(cè)這些服務(wù)。

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

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

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

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

• publisher confirms 方法可以在故障時(shí)通知什么寫(xiě)入了磁盤(pán)。
• 多機(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í)候，將未處理的消息持久化到磁盤(pán)上。為了避免因?yàn)榘l(fā)送消息到寫(xiě)入消息之間的延遲導(dǎo)致信息丟失，RabbitMQ引入了Publisher Confirm機(jī)制以確保消息被真正地寫(xiě)入到磁盤(pán)中。它對(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（圖片來(lái)自RabbitMQ官方網(wǎng)站）

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

7） 數(shù)據(jù)庫(kù)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)常被用來(lái)代替共享磁盤(pán)。

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

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

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

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

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

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

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

#p#

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

一般來(lái)說(shuō)，高可用性也就是建立冗余備份，常用策略有：

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

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

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

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

總之，對(duì)于OpenStack的優(yōu)化和改進(jìn)不斷，對(duì)于OpenStack的部署和應(yīng)用也在不斷嘗試和發(fā)展。需要實(shí)踐調(diào)優(yōu)。實(shí)踐非常重要，好的設(shè)計(jì)和想法需要實(shí)踐來(lái)驗(yàn)證。

上面分別對(duì)OpenStack的各個(gè)服務(wù)進(jìn)行了說(shuō)明，我純屬拋磚引玉。希望多實(shí)踐（可參考一鍵部署OpenStack），更希望有時(shí)間的朋友能夠把一些高可靠性方案的部署添加到OneStack/HAStack。關(guān)于OpenStack高可用性的討論和說(shuō)明，大家可以多看看以下這些地方：

http://docs.openstack.org/

http://wiki.openstack.org

http://www.hastexo.com/blogs/florian/2012/03/21/high-availability-openstack

Existing High Availability Options for Networking

bringing-high-availability-openstack-keystone-and-glance

Quantum Setup

MySQL HA with Pacemaker

http://www.rabbitmq.com/ha.html