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結構中的可用性進行討論:
構建OpenStack的高可用性(HA,High Availability)
2、OpenStack的高可用性(OpenStack HA)
同其它大部分分佈式系統一樣,OpenStack也分爲控制節點和計算節點兩種不同功能的節點。控制節點提供除nova-compute以外的服務。這些組件和服務都是可以獨立安裝的,可以選擇組合。
nova-compute在每個計算節點運行,暫且假設它是可信任的;或者使用備份機來實現故障轉移(不過每個計算節點配置備份的代價相比收益似乎太大)。
控制節點的高可靠性是主要問題,而且對於不同的組件都有自己的高可靠性需求和方案。
(1)由於CotrolNode只有1個,且負責整個系統的管理和控制,因此當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等服務都照常進行。
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開啓、停止和監測這些服務。
Built-in Replication(N copies of accounts, container, objects) 3x+ data redundancy compared to 2x on RAID 內建冗餘機制 RAID技術只做兩個備份,而Swift最少有3個備份 | High Availability 高可靠性 |
Easily add capacity unlike RAID resize 可以方便地進行存儲擴容 | Elastic data scaling with ease 方便的擴容能力 |
No central database 沒有中心節點 | Higher performance, No bottlenecks 高性能,無瓶頸限制 |
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作心跳檢測。
其它的方案,根據 MySQLPerformance Blog 的說法,MySQL幾種高可用解決方案能達到的可用性如下:
一般來說,高可用性也就是建立冗餘備份,常用策略有:
集羣工作模式。多機互備,這樣模式是把每個實例備份多份,沒有中心節點,比如分佈式對象存儲系統Swift、nova-network多主機模式。
自主模式。有時候,解決單點故障(SPoF)可以簡單的使用每個節點自主工作,通過去主從關係來減少主控節點失效帶來的問題,比如nova-api只負責自己所在節點。
主備模式。常見的模式active-passive,被動節點處於監聽和備份模式,故障時及時切換,比如mysql高可用集羣、glance、keystone使用Pacemaker和Heartbeat等來實現。
雙主模式。這種模式互備互援,RabbitMQ就是active-active集羣高可用性,集羣中的節點可進行隊列的複製。從架構上來說,這樣就不用擔心passive節點不能啓動或者延遲太大了?
總之,對於OpenStack的優化和改進不斷,對於OpenStack的部署和應用也在不斷嘗試和發展。需要實踐調優。實踐非常重要,好的設計和想法需要實踐來驗證。