《OpenStack高可用集群（上冊）：原理與架構》—1.6 云環境下的高可用設計

1.6　云環境下的高可用設計

在云計算布道的階段，關于如何對待云計算環境下服務器與傳統數據中心服務器的最形象的比喻也許就是“寵物”與“綿羊”了。在傳統數據中心里，用戶總是小心翼翼地維護如寵物般珍貴的服務器，而在云環境下，服務器就像放養的綿羊，出了任何問題隨時可以將其替換掉。這種云計算概念上的普及似乎在告訴用戶，上了云便可以高枕無憂，再也不用擔心服務器宕機帶來的噩耗，也不用再擔心業務系統的高可用受到影響。然而，事實似乎并非如此，盡管各個公有云運營商推出了4個9甚至5個9 的SLA來承諾云服務的高可用性，但是對于很多嚴重依賴IT系統的企業而言，即使完全如云運營商所承諾的那樣實現了99.99%的高可用，但是也無法承受全年52分鐘的宕機時間，更何況很少有云運營商真正做到SLA的承諾，而云運營商對于SLA失信的賠償似乎也遠不及用戶的損失。隨著云計算的不斷成熟和使用用戶的增加，各種云宕機事故所造成的影響和損失也越來越嚴重，不管是國外云巨頭亞馬遜的AWS、Google的GAE、微軟的Azure，還是國內的阿里云、青云、盛大云等均有不同程度的云宕機事件發生，而PaaS巨頭CRM領域的領頭羊Salesforce在2016年5月份丟失用戶近5個小時的數據，而且很多數據無法找回更是引起了云計算發展的一些爭議。

從理性的角度來看，公眾對于云計算領域的各種宕機事故如此關注，尤其是AWS、Azure、阿里云等巨頭的宕機事故，其關注度甚至高于自己企業的宕機事件，這與云計算早期的宣傳致使很多用戶對云計算抱有100%高可用的不切實際的期望有關。事實上，云計算不可能萬無一失，云計算會宕機也不應該成為質疑或反對云計算的理由，任何業務系統的高可用性都不是與生俱來的，而是要求用戶必須做好自己系統的設計，然后充分利用云計算提供的資源機制，而不是用戶不做任何系統高可用性設計和考慮，直接把應用程序扔到云端就萬事大吉。其實云計算和傳統IT基礎設施一樣，不可能萬無一失，系統和應用在設計時本來就應該為故障做好準備，而不是完全依賴IT基礎架構100%的可用性，例如在AWS 2011年4月份的宕機事故中，很多運行在AWS上的企業都受到了不同程度的影響，但是Twilio公司卻因為良好的業務系統高可用性設計而免于此次事故。

1.6.1　云計算HADR架構設計原則

傳統數據中心的HADR主要是基于服務器的部署架構，系統軟件主要部署在物理服務器或者虛擬機上，而高可用性設計的主要解決方案是提供冗余的硬件和系統，如應用服務器集群、主從數據庫同步復制、冗余網卡和RAID磁盤陣列等。傳統數據中心的HADR集群架構可以看作硬件服務器和系統軟件的一個垂直集合，每個服務器可以看作它的垂直子集，集群中任何一臺服務器故障，其他服務器仍然可以響應應用請求，

如圖1-22所示。

與傳統數據中心基于服務器的架構不同，對于企業而言，云計算環境下最大的技術轉換便是云的出現只是為了提供服務，即云架構的核心應該是如何呈現和利用云服務。傳統數據中心需要提供運行時的設備，如應用和數據庫服務器，并且是以獨立且不可再分的服務器單元提供，然后這些獨立不可再分的服務器單元通過軟件組成邏輯上的集群。相比之下，云架構被設計為資源抽象，如對存儲、計算、網絡以及運行時依賴資源的抽象，同時云架構也被設計成為多租戶高可擴展的架構。云架構可以看成是多種邏輯服務的水平層面集合，這種水平層面并不是簡單硬件設備的集合，而是云架構所提供的服務域（Zone），云架構上的水平層可以是API層、UI層、邏輯業務層等，如圖1-23所示。

圖1-23　云計算中基于邏輯服務的水平架構

針對云計算的架構環境，在云環境下要實現應用系統的HADR，需要遵循如下最佳實踐原則：

避免單點故障（SPOF）。

構成應用系統的每個組件（負載均衡器、應用服務器、數據庫）至少放置到兩個AZ（Availability Zone）上。

在獨立的AZ上預建足夠的資源以容納云宕機時AZ上需要進行遷移的云資源。

跨多個AZ進行數據同步復制或者跨區域（Region）進行數據備份以應對云宕機時進行應用程序的Failover，

AZ與Region的區別如圖1-24所示。

設置監控、告警及故障識別和自動解決或自動Failover的運行機制。

構建彈性無狀態的應用程序以便災難發生時在安全的AZ內進行實例reboot或者relaunch以恢復應用正常運行。

上述最佳云計算HADR實踐原則總結起來可以歸為4個步驟，即為Server故障設計高可用、為Zone故障設計高可用、為Cloud/Region故障設計高可用、自動故障恢復與窮盡測試：

（1）針對Server故障的高可用設計

Server在云環境以Instance（實例）的形式存在，實例通常并不像傳統的物理服務器一樣被小心呵護長期使用，云環境下的實例在任何時候都可能被替換掉，因此，針對Server級別的高可用設計最根本的就是設計彈性無狀態的應用程序，因為只有彈性無狀態的應用程序才能原生態地適應云計算環境下的高可用，無狀態應用可以通過迅速relaunch或者reboot實例而得到快速恢復，除此之外，還應該設計數據庫的鏡像（Mirror）備份、主從（Master/Slave）配置等以同步和保證數據的完整性，從而在宕機后迅速恢復數據可用性，在應用服務器的設計上應該盡量保證服務器的可擴展性，如果在成本預算上可以接受，則AWS的跨Zone自動擴展與數據同步復制高可用架構是最為理想的設計模式，如圖1-25所示。

圖1-25　AWS跨Zone自動擴展與數據同步架構

（2）針對Zone故障的高可用設計

在現實中，除了單個服務器故障外，還可能會出現數據中心的電源故障、網絡故障、閃電雷擊以及人為施工破壞等數據中心的故障，因此還需為你的應用考慮Zone故障。Zone是指一個使用獨立電源，并且與其他Zone彼此隔離的數據中心，Zone內的Server共享高帶寬、低延時、可通過私有網絡訪問的局域網。應對Zone故障的方案就是將每一個應用層的Server都擴展到至少兩個Zones上，數據也需要進行至少跨兩個Zone的復制，圖1-25中的AWS高可用架構便是如此。

（3）針對Cloud/Region的高可用設計

從AWS的觀點來看，Servers集群不是云，獨立Zone也不是云，云是由多個Zone組成的Region，Zone與Region的關系如圖1-24所示。Region就像島嶼（island），彼此之間不共享任何資源，它是一個有著自己獨立API接入點的資源系統，并且在地理位置上相距很遠，如亞洲Region與北美Region，通常將Region看成是真正的cloud。盡管一個Cloud發生出現故障的概率較低，但是如果要實現多個9的高可用性，那么跨Cloud的高可用設計也是需要考慮的，跨Cloud不僅僅是跨同一個供應商的Region，也可以是跨多個供應商的Region。

（4）自動故障恢復與窮盡測試

在設計了針對Server、Zone、Cloud故障的高可用架構后，應該讓一切故障的Failover都變得自動化，因為在真正的故障發生時，時間極其珍貴，而你很可能正好沒時間應對復雜的數據遷移與恢復等工作。任何HADR的設計都必須在考慮到全部故障點的充分測試下才能符合生產使用的要求，在高可用架構正式上線前，充分的壓力和故障模擬測試是必經的過程。

OpenStack 云計算

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

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