云計算服務提供商(CSP)排除某些失敗原因是合理的，但系統管理員將這些作為借口是不負責任的。這使得有必要通過其他方式確保應用程序的更高可用性。

高可用性限制

這個三節點SANless故障轉移集群能夠以最小的停機時間和無數據丟失處理兩個并發故障。

第三種選擇是采用第三方故障轉移集群軟件，這是專門用于為公共云、私有云和混合云上的Windows操作系統或Linux操作系統上運行的應用程序提供完整的高可用性和災難恢復解決方案。

第二個選項涉及使用集成到操作系統中的高可用性(HA)功能。Windows Server具有故障轉移集群的本機功能，但其缺乏數據復制功能。私有云中的復制通常通過某種形式的共享存儲提供，例如存儲區域網絡(SAN)。但是，在公共云中，共享存儲不可用，因此需要單獨的數據復制解決方案。

雖然這些解決方案可以在私有云中與SAN配合使用，但大多數管理員更喜歡部署無共享SANless故障轉移群集。其原因包括：消除潛在的單點故障、獲得在公共云中工作的能力、并最小化恢復點對象(RPO)、恢復時間對象(RTO)和最短恢復時間(MTTR)。

大多數云計算服務提供商都提供具有99.99%正常運行時間保證的服務等級協議(SLA)，而跨越云計算服務提供商(CSP)區域和/或區域的冗余配置增加了企業獲得滿意可用性的信心。但是這種安排存在一些嚴重問題，因為服務等級協議(SLA)中“停機時間”和“不可用”是導致應用程序失敗的原因。

通常，有三種基本選項可用于提高云計算的可用性：應用程序軟件中的規定，操作系統中內置的功能，以及專用的故障轉移集群。

在這個示例中，SQL1最初是主要活動實例，它將數據連續復制到SQL2和SQL3。如果SQL1失敗，應用程序將自動將故障轉移到SQL2，然后SQL2將成為SQL3的主要復制數據。

這些解決方案至少結合了數據復制、連續應用程序級監控、可配置的故障轉移/故障恢復恢復策略。這種集成使軟件能夠檢測應用程序級別的任何和所有停機時間，無論其原因如何，美國服務器租用，其中包括各種云計算服務等級協議(SLA)未涵蓋的原因。許多解決方案還提供高級功能，例如支持WAN優化以提高性能，以及人工切換主服務器和輔助服務器分配以促進計劃維護。

不計入停機的潛在原因包括客戶的軟件，任何第三方軟件或技術，directadmin漢化 虛擬主機，計劃的硬件和軟件維護，以及個別實例或卷的某些問題，這些問題不能歸因于某些不可用的情況。還排除了錯誤的輸入或指令，或在需要時缺乏行動，這似乎涵蓋了“人為錯誤”可能的原因。

一旦問題得到解決，SQL1可以恢復成主要節點，或者SQL2可以繼續在該容量中將數據復制到SQL1和SQL3。如果SQL2在SQL1返回操作之前失敗，SQL3將成為主要的節點。此外建議使用人工故障轉移，以防止由于到公共云的WAN鏈路中固有的較高延遲而導致數據丟失。

在Linux操作系統上，由于缺少像故障轉移集群這樣的本機功能，因此需要單獨的高可用性(HA)規定。因此，實施高可用性(HA)需要使用像Pacemaker和Corosync這樣的開源軟件為每個應用程序創建(然后維護)自定義腳本，并且只有規模非常大的組織才有能力承擔所涉及的巨大而持續努力。

5個9的故障轉移集群配置

許多應用程序提供自己的高可用性(HA)規定。一個很好的例子是Microsoft SQL Server企業版中的運營商級在可用性組上始終使用的功能。這種方法的問題在于需要針對不同的應用程序提供不同的高可用性(HA)規定，這使得持續管理成為一項持續且成本高昂的工作。

而采用正確的方法，在Amazon Web Services、谷歌云平臺和微軟Azure公共云和混合云環境中可以實現5個9的高可用性(HA)。這需要了解服務等級協議(SLA)中的限制，以及創建高可用配置的選項。

上圖顯示了一個三節點SANless故障轉移集群，可在混合云中提供5個9的高可用性以及強大的災難恢復保護。該應用程序是一個使用SQL Server標準版中的故障轉移集群實例(FCI)的數據庫。SQL1和SQL2位于公共云中具有SQL3的企業數據中心。在數據中心內，跨LAN的數據復制是同步的，以最大限度地縮短完成故障轉移所需的時間，從而最大限度地提高可用性。