當公共雲服務級別不足時的選項
所有公共雲服務提供商都提供某種形式的可用性保證。 這些可能或不足，取決於每個應用程序的正常運行時間要求。這些保證通常在本月的正常運行時間範圍內為95.00％至99.99％。大多數人對服務提供商施加某種類型的“懲罰”，以達不到這些閾值。通常，大多數雲服務提供商提供99.00％的正常運行時間閾值。這相當於每月約7小時的停機時間。對於許多應用程序來說，那些兩個9可能就足夠了。但對於任務關鍵型應用程序，需要更多9個。特別是考慮到許多常見的停機原因被排除在擔保之外。當然，在使用公共雲服務的配置中，無論是專有還是作為混合安排的一部分，都可以採用經濟高效的方式實現5-9的高可用性和強大的災難恢復保護。本文重點介紹了公共雲中涉及HA和DR規定的限制。它探討了克服這些限制的三種選擇，並描述了故障轉移群集的兩種常見配置。
在雲中註意Emptor
雖然所有云服務提供商（CSP）在某種程度上不同地定義“停機時間”或“不可用”，但這些定義僅包括應用程序級別的所有可能的故障原因的有限集合。通常包括影響區域或區域的故障，或外部連接。所有CSP還提供從10％未滿足4到9的正常運行時間到25％左右的信用額度，因為它們未能滿足2到9的正常運行時間。可以將冗餘資源配置為跨越CSP基礎架構內的區域和/或區域。 它將有助於提高應用程序級別的可用性。但即使有這樣的冗餘，仍然存在一些限制，這些限制對於任務關鍵型應用程序來說通常是不可接受的。特別是那些需要高事務吞吐量性能的。這些限制包括每個主服務器只能創建一個故障轉移副本。它需要使用主數據集進行備份，並使用事件日誌來複製數據。這些和其他限制可能會增加故障期間的恢復時間，並且必須至少安排一些計劃停機時間。
重大限制
更重要的限制涉及許多排除什麼構成停機時間。以下是實際公共雲服務級別協議中的一些示例，其中包含導致應用程序級故障導致的“停機時間”或“不可用性”的內容：
- 超出CSP合理控制的因素（換句話說，一些經常發生的事情，例如運營商網絡中斷和自然災害）
- 客戶的軟件或第三方軟件或技術，包括應用程序軟件
- 錯誤的輸入或指令，或者在需要時沒有採取任何行動（換句話說，人為錯誤造成的不可避免的錯誤）
- 單個實例或卷的問題不歸因於“不可用”的具體情況
- 根據協議規定的任何硬件或軟件維護
可以肯定的是，CSP排除某些失敗原因是合理的。但是系統管理員以這些為藉口是不負責任的。有必要通過其他方式確保應用程序級別的可用性。
哪些公共雲服務級別可用？
以不犧牲安全性或性能的方式為高可用性供應資源從未是一項微不足道的努力。在私有云和公共雲基礎架構可能存在顯著差異的混合雲環境中，挑戰尤其困難。它使配置難以測試和維護。此外，它可能導致故障轉移條款在實際需要時失敗。對於CSP提供的服務級別不足的應用程序，可根據應用程序本身，操作系統中的功能或使用專用的故障轉移群集軟件提供三個附加選項。
提高應用程序級可用性的三個選項
HA / DR
可能看起來最容易實現的HA / DR選項是專為每個應用程序設計的選項。一個很好的例子是Microsoft的SQL Server數據庫及其運營商級Always On Availability Groups功能。然而，這種方法有兩個缺點。在這種情況下，企業版的許可費用較高，可能會使許多需求成本過高。更令人不安的缺點是需要針對不同的應用程序提供不同的HA / DR規定，這使得持續管理成為一個持續（和昂貴）的鬥爭。
與運行時相關的功能集成到操作系統中
提高公共雲服務級別的第二個選項涉及使用集成到操作系統中的與正常運行時間相關的功能。例如，Windows Server Failover Clustering是一個功能強大且經過驗證的功能，內置於操作系統中。但就其本身而言，WSFC可能無法提供完整的HA / DR解決方案，因為它缺乏數據複製功能。在私有云中，可以使用某種形式的共享存儲（例如存儲區域網絡）來提供數據複製。但由於共享存儲在公共雲中不可用，因此實施強大的數據複製需要使用單獨的商業或定制開發的軟件。對於缺乏WSFC等功能的Linux，需要額外的HA / DR規定和/或定制開發。使用像Pacemaker和Corosync這樣的開源軟件需要為每個應用程序創建（和測試）自定義腳本。在對所使用的任何軟件或硬件進行微小更改後，通常需要更新和重新測試這些腳本。但是因為讓完整的HA堆棧適用於每個應用程序都非常困難，只有非常大的組織才有必要的資金來考慮承擔這些工作。
專用故障轉移群集
理想情況下，HA / DR將採用“通用”方法，能夠經濟高效地在公共，私有云和混合雲上運行在Windows或Linux上的所有應用程序。這種解決方案中功能最多，價格最實惠的是第三種選擇：專用故障轉移集群。這些HA / DR解決方案完全由軟件實現，專門用於創建虛擬或物理服務器和數據存儲集群，從活動或主要實例到備用數據庫的故障轉移，以確保應用程序的高可用性水平。
這些解決方案的好處
這些解決方案至少提供了實時數據複製，連續應用程序監控和可配置故障轉移/故障恢復恢復策略的組合。一些更強大的功能提供了額外的高級功能，例如選擇塊級同步或異步複製，在較便宜的SQL Server標準版中支持故障轉移群集實例（FCI），WAN優化以提高性能和最小帶寬利用率和主服務器和輔助服務器分配的手動切換，以便於計劃維護。雖然這些通用解決方案通常與存儲無關，使它們能夠與存儲區域網絡協同工作，但通常優先選擇無共享SANless故障轉移群集，因為它們能夠消除潛在的單點故障。
兩種常見的故障轉移群集配置
每個故障轉移群集都包含兩個或更多節點。找到不同數據中心中的至少一個節點對於防止本地災難是必要的。這裡介紹兩種流行的配置：一種用於災難恢復;另一個用於提供關鍵任務高可用性和災難恢復。高事務性能通常是高可用性配置的要求。示例應用程序是一個數據庫。用於災難恢復的基本SANless故障轉移群集具有兩個節點，其中一個主節點和一個輔助或備用服務器或服務器實例。此最小配置還需要第三個節點或實例作為見證，這是實現確定主要分配的法定數量所必需的。對於數據庫應用程序，通過WAN複製到備用實例是異步的，以便在主實例中保持高性能。SANless故障轉移群集可在主服務器發生故障時快速恢復。導致適用於許多應用程序的基本DR配置。它能夠檢測幾乎所有可能的故障，包括那些未計入公共雲服務中的停機時間的故障。因此，它將在私有云，公共雲或混合雲環境中工作。例如，主服務器可以位於企業數據中心，輔助服務器部署在公共雲中。因為公共雲實例僅在主計劃的計劃維護期間或在其失敗的情況下才需要 – 可以相當快速地補救 – 上面提到的服務限制和排除對於除了最關鍵任務之外的所有人都可以接受申請。
三節點SANless故障轉移群集
復甦
服務器＃1發生故障後，IT人員會立即開始診斷並修復導致問題的任何問題。一旦修復，服務器＃1可以作為主服務器恢復，並進行手動故障恢復，或者服務器＃2可以繼續作為服務器＃1和服務器＃3的主要復制數據。如果服務器＃2在服務器＃1恢復運行之前失敗，如圖所示，服務器＃3將成為主服務器。由於服務器＃3跨越公共雲中的WAN，因此數據複製是異步的，故障轉移是手動的，以防止“複製延遲”導致丟失任何數據。SANless故障轉移群集軟件能夠在應用程序級別檢測所有可能的故障。它很容易克服上面提到的CSP限制和排除。因此，它使這個三節點配置可以完全部署在公共雲中。為了提供基於即時和自動故障轉移的相同的5 -9高可用性，服務器＃1和＃2需要位於LAN促進同步複製的單個區域或區域內。為了實現適當的DR保護，服務器＃3應位於不同的數據中心或區域，對於需要高事務吞吐量的應用程序，需要使用異步複製和手動故障轉移/故障恢復。三節點集群還可以促進所有三台服務器的計劃硬件和軟件維護。同時，繼續為應用程序及其數據提供連續的DR保護。通過提供多個地理位置分散的數據中心，公共雲提供了大量機會來提高可用性並增強災難恢復條款。SANless故障轉移群集軟件可有效，高效地使用所有計算，存儲和網絡資源。它也易於實施和操作。這些專用解決方案可最大限度地降低所有資本和運營支出。最後，導致高可用性比以前更強大，更實惠。###
關於作者
Cassius Rhue是SIOS Technology的工程總監。 他領導位於南卡羅來納州列剋星敦的軟件產品開發和工程團隊。Cassius擁有超過17年的軟件工程，開發和測試經驗。他還擁有南卡羅來納大學的計算機工程學士學位。