1. <wbr id="cnjas"><legend id="cnjas"></legend></wbr>

          Linux培訓
          達內IT學院

          400-111-8989

          如何構建OpenStack的高可用性

          • 發布:Linux培訓
          • 來源:網絡
          • 時間:2015-07-08 15:10

          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只有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和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和 ova-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的部分優點,這也說明了這點。

          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作心跳檢測。

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

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

          3、構建高可用性的OpenStack(High-availability OpenStack)

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

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

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

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

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

          總之,對于OpenStack的優化和改進不斷,對于OpenStack的部署和應用也在不斷嘗試和發展。需要實踐調優。實踐非常重要,好的設計和想法需要實踐來驗證。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:OpenStack的優勢與劣勢
          下一篇:OpenStack架構是構建IaaS云的最佳選擇?

          私有云比公有云更經濟,OpenStack厚積薄發

          OpenStack文檔的持續集成與持續交付是怎么實現的?

          OpenStack架構是構建IaaS云的最佳選擇?

          如何構建OpenStack的高可用性

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          欧美做爰视频免费播放_做暖全过程免费的视频_性爱免费视频 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>