如何確保應用程式在公共雲中的可用性
採用雲端計算的注意事項是一種很好的建議。雲端計算服務提供商(CSP)都會承諾在其基礎設施中提供“高可用性”，其服務水平協議(SLA)通常提供95%至99.99%的正常執行時間，而每月服務費退款率將達到10%到50%不等。但通常沒有達到這樣的門檻，正如IT的許多方面一樣，重要的在於細節。
而採用正確的方法，在Amazon Web Services、谷歌雲平臺和微軟Azure公共雲和混合雲環境中可以實現5個9的高可用性(HA)。這需要了解服務等級協議(SLA)中的限制，以及建立高可用配置的選項。
高可用性限制
大多數雲端計算服務提供商都提供具有99.99%正常執行時間保證的服務等級協議(SLA)，而跨越雲端計算服務提供商(CSP)區域和/或區域的冗餘配置增加了企業獲得滿意可用性的信心。但是這種安排存在一些嚴重問題，因為服務等級協議(SLA)中“停機時間”和“不可用”是導致應用程式失敗的原因。
不計入停機的潛在原因包括客戶的軟體，任何第三方軟體或技術，計劃的硬體和軟體維護，以及個別例項或卷的某些問題，這些問題不能歸因於某些不可用的情況。還排除了錯誤的輸入或指令，或在需要時缺乏行動，這似乎涵蓋了“人為錯誤”可能的原因。
雲端計算服務提供商(CSP)排除某些失敗原因是合理的，但系統管理員將這些作為藉口是不負責任的。這使得有必要通過其他方式確保應用程式的更高可用性。
實現更高可靠性的選項
通常，有三種基本選項可用於提高雲計算的可用性：應用程式軟體中的規定，作業系統中內建的功能，以及專用的故障轉移叢集。
許多應用程式提供自己的高可用性(HA)規定。一個很好的例子是Microsoft SQL Server企業版中的運營商級在可用性組上始終使用的功能。這種方法的問題在於需要針對不同的應用程式提供不同的高可用性(HA)規定，這使得持續管理成為一項持續且成本高昂的工作。
第二個選項涉及使用整合到作業系統中的高可用性(HA)功能。 Windows Server具有故障轉移叢集的本機功能，但其缺乏資料複製功能。私有云中的複製通常通過某種形式的共享儲存提供，例如儲存區域網路(SAN)。但是，在公共雲中，共享儲存不可用，因此需要單獨的資料複製解決方案。
在Linux作業系統上，由於缺少像故障轉移叢集這樣的本機功能，因此需要單獨的高可用性(HA)規定。因此，實施高可用性(HA)需要使用像Pacemaker和Corosync這樣的開源軟體為每個應用程式建立(然後維護)自定義指令碼，並且只有規模非常大的組織才有能力承擔所涉及的巨大而持續努力。
第三種選擇是採用第三方故障轉移叢集軟體，這是專門用於為公共雲、私有云和混合雲上的Windows作業系統或Linux作業系統上執行的應用程式提供完整的高可用性和災難恢復解決方案。
這些解決方案至少結合了資料複製、連續應用程式級監控、可配置的故障轉移/故障恢復恢復策略。這種整合使軟體能夠檢測應用程式級別的任何和所有停機時間，無論其原因如何，其中包括各種雲端計算服務等級協議(SLA)未涵蓋的原因。許多解決方案還提供高階功能，例如支援WAN優化以提高效能，以及人工切換主伺服器和輔助伺服器分配以促進計劃維護。
雖然這些解決方案可以在私有云中與SAN配合使用，但大多數管理員更喜歡部署無共享SANless故障轉移群集。其原因包括：消除潛在的單點故障、獲得在公共雲中工作的能力、並最小化恢復點物件(RPO)、恢復時間物件(RTO)和最短恢復時間(MTTR)。
5個9的故障轉移叢集配置
上圖顯示了一個三節點SANless故障轉移叢集，可在混合雲中提供5個9的高可用性以及強大的災難恢復保護。該應用程式是一個使用SQL Server標準版中的故障轉移叢集例項(FCI)的資料庫。SQL1和SQL2位於公共雲中具有SQL3的企業資料中心。在資料中心內，跨LAN的資料複製是同步的，以最大限度地縮短完成故障轉移所需的時間，從而最大限度地提高可用性。
這個三節點SANless故障轉移叢集能夠以最小的停機時間和無資料丟失處理兩個併發故障。
在這個示例中，SQL1最初是主要活動例項，它將資料連續複製到SQL2和SQL3。如果SQL1失敗，應用程式將自動將故障轉移到SQL2，然後SQL2將成為SQL3的主要複製資料。
一旦問題得到解決，SQL1可以恢復成主要節點，或者SQL2可以繼續在該容量中將資料複製到SQL1和SQL3。如果SQL2在SQL1返回操作之前失敗， SQL3將成為主要的節點。此外建議使用人工故障轉移，以防止由於到公共雲的WAN鏈路中固有的較高延遲而導致資料丟失。
像這樣的三節點叢集還有助於為所有三臺伺服器進行計劃的硬體和軟體維護，同時為應用程式及其資料提供持續的災難恢復保護。通過易於實施和操作的方式有效和高效地使用所有資源，故障轉移叢集軟體使得5個9的高可用性更加經濟實惠，其中包括混合雲。