怎么構建OpenStack的高可用性

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

1、CAP理論

1） CAP 理論給出了3個基本要素：

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

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

• 分區可容忍性 (Tolerance of network Partition) ：在出現網絡分區的情況下，仍然能夠滿足一致性和可用性；

  CAP 理論指出，三者不能同時滿足。對這個理論有不少異議，但是它的參考價值依然巨大。

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

  對于分布式數據系統，分區容忍性是基本要求。因此設計分布式數據系統，很多時候是在一致性和可用性（可靠性）之間尋求一個平衡。更多的系統性能和架構的討論也是圍繞一致性和可用性展開。

2） OpenStack、Swift與CAP的工程實踐

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

在OpenStack架構中，對于高可用性需要進行很多工作來保證。因此，下面將對OpenStack結構中的可用性進行討論：

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

  要弄清楚怎么實現高可用性，就需要知道哪些服務容易出現不可靠。首先了解一些OpenStack的大致結構。

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

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

下面這幅圖描述了各個組件的功能和服務結構：

 同其它大部分分布式系統一樣，OpenStack也分為控制節點和計算節點兩種不同功能的節點。控制節點提供除nova-compute以外的服務。這些組件和服務都是可以獨立安裝的，可以選擇組合。

  nova-compute在每個計算節點運行，暫且假設它是可信任的；或者使用備份機來實現故障轉移（不過每個計算節點配置備份的代價相比收益似乎太大）。

控制節點的高可靠性是主要問題，而且對于不同的組件都有自己的高可靠性需求和方案。

（1）由于CotrolNode只有１個，且負責整個系統的管理和控制，因此當Cotrol Node不能提供正常服務時，怎么辦？這就是常見的單節點故障（SPoF，single point of failure）問題。

高可用性基本上是沒辦法通過一臺來達到目標的，更多的時候是設計方案確保在出問題的時候盡快接管故障機器，當然這要付出更大的成本。

對于單點問題，解決的方案一般是采用冗余設備或者熱備，因為硬件的錯誤或者人為的原因，總是有可能造成單個或多個節點的失效，有時做節點的維護或者升級，也需要暫時停止某些節點，所以一個可靠的系統必須能承受單個或多個節點的停止。

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

（2）那么如何構建冗余的控制節點？或者什么其它方法實現高可靠的控制？

很多人可能想到實現active-passive模式，使用心跳機制或者類似的方法進行備份，通過故障轉移來實現高可靠性。Openstack是沒有多個控制節點的，Pacemaker需要多種服務各自實現這種備份、監聽和切換。

仔細分析控制節點提供的服務，主要就是nova-api、nova-network、nova-schedule、nova-volume，以及glance、keysonte和數據庫mysql等，這些服務是分開提供的。nova-api、nova-network、glance等可以分別在每個計算節點上工作，RabbitMQ可以工作在主備模式，mysql可以使用冗余的高可用集群。

下面分別介紹：

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

每個計算節點可以運行自己的nova-api和nova-scheduler，提供負載均衡來保證這樣正確工作。

這樣當控制節點出現故障，計算節點的nova-api等服務都照常進行。

2）nova-volume的高可靠性

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

不過，nova-volume由iSCSI驅動，這個協議與DRBD結合，或者基于iSCSI的高可靠的硬件解決方案，可以實現高可靠。

3） 網絡服務nova-network的高可靠性

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

方案1: Multi-host

多主機。每個計算節點上配置nova-network。這樣，每個計算節點都會實現NAT, DHCP和網關的功能，必然需要一定的開銷，可以與hardware gateway方式結合，避免每個計算節點的網關功能。這樣，每個計算節點都需要安裝nova-compute外還要nova-network和nova-api，并且需要能連接外網。具體介紹見Nova Multi-host Mode against SPoF。

方案2: Failover

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

方案3: Multi-nic

多網卡技術。把VM橋接到多個網絡，VM就擁有2種傳出路由，實現故障時切換。但是這需要監聽多個網絡，也需要設計切換策略。

方案4: Hardware gateway

硬件網關。需要配置外部網關。由于VLAN模式需要對每個網絡有一個網關，而hardware gateway方式只能對所有實例使用一個網關，因此不能在VLAN模式下使用。

方案5： Quantum（OpenStack下一個版本Folsom中）

Quantum的目標是逐步實現功能完備的虛擬網絡服務。它暫時會繼續兼容舊的nova-network的功能如Flat、Flatdhcp等。但是實現了類似multi_host的功能，支持OpenStack工作在主備模式（active-backup這種高可用性模式）。

Quantum只需要一個nova-network的實例運行，因此不能與multi_host模式共同工作。

Quantum允許單個租戶擁有多個私人專用L2網絡，通過加強QoS，以后應該能使hadoop集群很好的在nova節點上工作。

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

4） glance、keystone的高可靠性

OpenStack的鏡像可以使用swift存儲，glance可以運行在多個主機。Integrating OpenStack ImageService (Glance) with Swift  介紹了glance使用swift存儲。

集群管理工具 Pacemaker 是強大的高可用性解決方案，能夠管理多節點集群，實現服務切換和轉移，可與Corosync 和 Heartbeat等配套使用。Pacemaker 能夠較為靈活的實現主備、N+1 、N-N 等多種模式。

bringing-high-availability-openstack-keystone-and-glance介紹了如何通過Pacemaker實現keystone和glance的高可靠。在每個節點安裝OCF代理后，它能夠告訴一個節點另一個節點是否正常運行glance和keysone服務，從而幫助Pacemaker開啟、停止和監測這些服務。

5） Swift對象存儲的高可靠性

一般情況下，OpenStack的分布式對象存儲系統Swift的HA是不需要自己添加的。因為，Swift設計時就是分布式（沒有主控節點）、容錯、冗余機制、數據恢復機制、可擴展和高可靠的。以下是Swift的部分優點，這也說明了這點。

6） 消息隊列服務RabbitMQ的高可靠性

RabbitMQ失效就會導致丟失消息，可以有多種HA機制：

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

• 多機集群機制，但是節點失效容易導致隊列失效。

• 主備模式（active-passive），能夠實現故障時轉移，但是啟動備份機可能需要延遲甚至失效。

在容災與可用性方面，RabbitMQ提供了可持久化的隊列。能夠在隊列服務崩潰的時候，將未處理的消息持久化到磁盤上。為了避免因為發送消息到寫入消息之間的延遲導致信息丟失，RabbitMQ引入了Publisher Confirm機制以確保消息被真正地寫入到磁盤中。它對Cluster的支持提供了Active/Passive與Active/Active兩種模式。例如，在Active/Passive模式下，一旦一個節點失敗，Passive節點就會馬上被激活，并迅速替代失敗的Active節點，承擔起消息傳遞的職責。如圖所示：

圖 Active/Passive Cluster（圖片來自RabbitMQ官方網站）

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

7） 數據庫mysql的高可靠性

集群并不就是高可靠，常用的構建高可靠的mysql的方法有Active-passive主備模式：使用DRBD實現主備機的災容，Heartbeat或者Corosync做心跳監測、服務切換甚至failover，Pacemaker實現服務（資源）的切換及控制等；或者類似的機制。其中主要使用Pacemaker實現了mysql的active-passive高可用集群。

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

它的工作原理是：在A主機上有對指定磁盤設備寫請求時，數據發送給A主機的kernel，然后通過kernel中的一個模塊，把相同的數據傳送給B主機的kernel中一份，然后B主機再寫入自己指定的磁盤設備，從而實現兩主機數據的同步,也就實現了寫操作高可用。DRBD一般是一主一從，并且所有的讀寫操作，掛載只能在主節點服務器上進行，，但是主從DRBD服務器之間是可以進行調換的。這里有對 DRBD 的介紹。

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

NovaZooKeeperHeartbeat介紹了使用ZooKeeper作心跳檢測。

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

Galera 是針對Mysql/InnoDB的同步的多master集群的開源項目，提供了很多的優點（如同步復制、讀寫到任意節點、自動成員控制、自動節點加入、較小延遲等），可以參考。

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

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

3、構建高可用性的OpenStack（High-availability OpenStack）

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

• 集群工作模式。多機互備，這樣模式是把每個實例備份多份，沒有中心節點，比如分布式對象存儲系統Swift、nova-network多主機模式。

• 自主模式。有時候，解決單點故障（SPoF）可以簡單的使用每個節點自主工作，通過去主從關系來減少主控節點失效帶來的問題，比如nova-api只負責自己所在節點。

• 主備模式。常見的模式active-passive，被動節點處于監聽和備份模式，故障時及時切換，比如mysql高可用集群、glance、keystone使用Pacemaker和Heartbeat等來實現。

• 雙主模式。這種模式互備互援，RabbitMQ就是active-active集群高可用性，集群中的節點可進行隊列的復制。從架構上來說，這樣就不用擔心passive節點不能啟動或者延遲太大了？

以上是“怎么構建OpenStack的高可用性”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！