《OpenStack高可用集群（上冊）：原理與架構》—2.4.2　Mirantis OpenStack自定義高可用集群架構

2.4.2　Mirantis OpenStack自定義高可用集群架構

在Mirantis看來，OpenStack生產環境部署最重要的兩個方面是服務的高可用性和可擴展性，在滿足這兩個必要條件的前提下，OpenStack服務在節點上的分布可以靈活多變。傳統的OpenStack生產環境部署認為高可用環境就應該存在服務集中的控制節點（OpenStack APIs、MySQL/MariaDB和RabbitMQ均部署在控制節點），而Mirantis認為這些OpenStack相關的服務均可以部署在控制節點或計算節點上，并將控制節點與計算節點在“胖節點”（部署大量服務）與“瘦節點”（部署少量服務）之間權衡，如果將控制節點上的服務移到計算節點，則控制節點甚至可以消失。圖2-28中，計算節點作為“胖節點”部署了Nova-api、Nova-scheduler、Glance-api等服務，而控制節點作為“瘦節點”僅部署數據庫和消息隊列服務，同時使用物理負載均衡器來作為OpenStack服務的訪問入口（Endpoint），將來自Horzion和REST API的訪問請求進行均衡高可用。在這種部署模式下，控制節點僅部署平臺服務（數據庫和消息隊列），其他屬于OpenStack的內部服務全部部署在計算節點，因此用戶可以將數據庫獨立出來交由專門的DBA團隊負責，而消息隊列也可獨立到特定的消息集群中。通過這種方式，最終的OpenStack集群只剩下部署有“純凈”OpenStack服務的計算節點，中心化的控制節點已經消失，不僅減輕了云管理的復雜性，同時可以對集群實現幾乎是水平線性的伸縮擴展。

作為OpenStack高可用集群的另外一種部署方式，Mirantis使用HAProxy軟件替換物理負載均衡器，并將其部署在冗余節點系統上實現高可用，集群通過HAProxy實現訪問請求的負載均衡和OpenStack服務的高可用性，如圖2-29所示。圖2-29與圖2-28架構上最大的不同除了負載均衡器之外，還有就是圖2-29中OpenStack的APIs服務被部署到控制節點，而不是計算節點，因此控制節點變得“更胖”，而計算節點變得“更瘦”，兩個控制節點運行在Active/Standby模式，控制節點服務之間的故障轉移通過Pacemaker和Corosync/Heartbeat實現。

圖2-28　基于物理負載均衡器的OpenStack高可用服務部署

用戶不僅可以通過物理負載均衡器和獨立節點系統上的HAProxy軟件實現OpenStack服務的負載均衡和高可用，還可以將HAProxy集成到控制節點，并將除了計算服務之外的OpenStack服務和基礎平臺服務全部部署在控制節點上，同時控制節點可以通過添加節點和重新配置HAProxy的形式實現伸縮擴展，如圖2-30所示。在這種模式下，至少需要兩個HAProxy實例以Active/Standby模式運行在控制節點上，HAProxy的故障檢測和某個Standby狀態的HAProxy實例變為Active狀態則通過Pacemaker和Corosync/Heartbeat實現。圖2-30的高可用部署模式也是Mirantis官方文檔中推薦的OpenStack高可用服務部署模式，即圖2-30中的OpenStack高可用部署架構與圖2-25的部署架構是一致的，這種部署模式的優點是將集群服務集中部署到控制節點并使用集群管理軟件Pacemaker統一管理，同時集群所需物理設備和服務器節點數目也有所減少，其與Redhat的官方OpenStack高可用部署架構比較相似，但是Mirantis的架構并沒有實現多個服務VIP在控制節點集群上的均衡分布，而是采用單一的VIP對外提供服務。

圖2-29　基于特定負載均衡器節點的OpenStack高可用服務部署

圖2-30　基于集成負載均衡器的OpenStack高可用服務部署

彈性負載均衡 ELB OpenStack

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。