確保Amazon Web Services上的SQL Server高可用性

數據庫和系統管理員長期以來擁有廣泛的選項來確保任務關鍵型數據庫應用程序保持高可用性。公共雲基礎架構（如Amazon Web Services提供的基礎架構）提供了自己的，由服務級別協議支持的其他高可用性選項。但是在公共雲中可能無法在私有云中很好地工作。使用的AWS服務中選擇不當和/或如何配置這些選項會導致故障轉移規定在實際需要時失敗。本文概述了可用於確保AWS雲中SQL Server高可用性的各種選項。

選項

對於數據庫應用程序，AWS為管理員提供兩種基本選 每個都具有不同的高可用性（HA）和災難恢復（DR）規定：Amazon Relational Database Service（RDS）和Amazon Elastic Compute Cloud（EC2）。

RDS

RDS是一種完全託管的服務，適用於任務關鍵型應用程序。它提供了六種不同數據庫引擎的選擇，但它對SQL Server的支持並不像Amazon Aurora，My SQL和MariaDB等其他選擇那樣強大。以下是管理員關於將RDS用於關鍵任務SQL Server應用程序的一些常見問題：

• 僅支持單個鏡像備用實例，
• 代理作業不是鏡像的，因此必須在備用實例中單獨創建，
• 未檢測到數據庫應用程序軟件導致的故障，
• 不支持性能優化的內存數據庫實例，
• 根據可用區分配（客戶無法控制），性能可能會受到不利影響，
• 僅具有Always On Availability Groups的數據鏡像功能需要SQL Server更昂貴的Enterprise Edition。

彈性計算雲

另一個基本選擇是Elastic Compute Cloud，它具有更強大的功能。這使得它在HA和DR至關重要時成為首選。EC2的一個主要優點是它為管理員提供了完整的控製配置，並為管理員提供了一些額外的選擇。

選擇操作系統

也許最重要的選擇是使用哪種操作系統：Windows或Linux。Windows Server故障轉移群集是Windows標配的功能強大，經過驗證的流行功能。但是WSFC需要共享存儲，而這在EC2中是不可用的。由於強大的HA / DR保護需要多可用區，甚至多區域配置，因此需要單獨的商業或定制軟件來跨服務器實例群集複製數據。Microsoft的Storage Spaces Direct（S2D）不是一個選項，因為它不支持跨可用區的配置。對於缺乏WSFC等基本集群功能的Linux，對Linux的額外HA / DR規定的需求更大。Linux為管理員提供了兩個同樣糟糕的高可用性選擇：為更昂貴的SQL Server企業版支付更多費用以實現Always On Availability Groups;或者努力製作複雜的自助式使用開源軟件的HA Linux配置運行良好。

比較

這兩種選擇都破壞了在公共雲服務中使用商用硬件上的開源軟件的成本節約理由。SQL Server for Linux僅適用於2017年開始的更新（和更昂貴）版本。對於大多數組織而言，DIY HA替代品可能過於昂貴。實際上，在所有可能的故障情況下，使分佈式複制塊設備，Corosync，Pacemaker以及可選的其他開源軟件在應用程序級別按需工作可能會非常困難。這就是為什麼只有非常大的組織才有必要的資金（技能和人員）才能考慮承擔這項任務。由於在實施Linux的任務關鍵型HA / DR規定時遇到困難，AWS建議結合使用Elastic Load Balancing和Auto Scaling來提高可用性。但是這些服務有其自身的局限性，與託管的關係數據庫服務中的局限性相似。所有這些都解釋了為什麼管理員越來越多地選擇使用專為確保云環境中的HA和DR保護而設計的故障轉移群集解決方案。

故障轉移群集專用於雲

私有云，公共雲和混合雲的日益普及導致了針對雲環境專門構建的故障轉移群集解決方案的出現。這些HA / DR解決方案完全由軟件實現，如名稱所暗示的那樣，創建具有自動故障轉移的服務器和存儲集群，以確保應用程序級別的高可用性。這些解決方案中的大多數都提供了完整的HA / DR解決方案，其中包括實時塊級數據複製，連續應用程序監控和可配置的故障轉移/故障恢復恢復策略。一些更複雜的解決方案還提供了高級功能，例如，對於Windows和Linux，在較便宜的SQL Server標準版中支持Always on Failover Cluster Instances。它們還提供WAN優化，以最大化多區域性能。還可以手動切換主服務器和輔助服務器分配，以便於計劃維護。包括在不中斷應用程序的情況下執行定期備份的功能。大多數故障轉移群集軟件都與應用程序無關，使組織能夠擁有單一，通用的HA / DR解決方案。同樣的功能還為整個SQL Server應用程序提供了保護。這包括數據庫，登錄，代理作業等，所有這些都是以集成的方式進行的。雖然這些解決方案通常也與存儲無關，使它們能夠與共享存儲區域網絡一起使用，但通常優先考慮無共享SANless故障轉移群集，因為它能夠消除潛在的單點故障。在較便宜的SQL Server標準版中支持Always On Failover Cluster Instances（FCI），不會影響可用性或性能，這是一個主要優勢。在Windows環境中，大多數故障轉移群集軟件都通過利用內置的WSFC功能來支持FCI。它使數據庫和系統管理員的實現非常簡單。Linux在SQL Server和許多其他企業應用程序中越來越受歡迎。現在，一些故障轉移群集解決方案通過提供特定於應用程序的集成，可以像實現Windows一樣簡單地實現HA / DR規定。

典型的三節點SANless故障轉移群集

圖中的示例EC2配置顯示了典型的三節點SANless故障轉移群集，該群集配置為虛擬私有云（VPC），其中所有三個SQL Server實例位於不同的可用區中。為了消除影響整個區域的本地災難中斷的可能性，其中一個AZ位於不同的AWS區域。

三節點SANless故障轉移群集提供運營商級HA和DR保護。對於Windows或Linux，LAN和/或WAN的基本操作是相同的。服務器＃1最初是主要或活動實例，它將數據連續複製到服務器＃2和＃3。它遇到了問題。然後它會觸發到服務器＃2的自動故障轉移，服務器＃2現在成為服務器＃3的主要復制數據。

檢測到故障

如果故障是由基礎架構中斷引起的，則AWS工作人員將立即開始診斷並修復導致問題的任何問題。一旦修復，它就可以作為主服務器恢復，或服務器＃2可以繼續以該容量將數據複製到服務器＃1和＃3。如果服務器＃2在服務器＃1恢復運行之前失敗，如圖所示，服務器＃3將在手動故障轉移後成為主服務器。當然，如果故障是由應用程序軟件或配置的某些其他方面引起的，則由客戶來查找並解決問題。當然，SANless故障轉移群集只能配置一個備用實例。但是這種最小配置確實需要第三個節點作為證人。需要證人才能達到確定主要任務的法定人數。 此重要任務通常由單獨的AZ中的域控制器執行。將所有三個節點（主節點，次節點和見證節點）保存在不同的AZ中可以消除在任何區域脫機時丟失多個投票的可能性。在混合雲配置中還可以具有用於HA和/或DR目的的兩節點和三節點SANless故障轉移群集。一個這樣的三節點配置是位於企業數據中心的雙節點HA集群，其中異步數據複製到AWS或另一個雲服務以進行DR保護 – 反之亦然。在單個區域中的數據複製同步的群集中，故障轉移通常配置為自動發生。對於具有跨越多個區域的節點的群集，其中數據複製是異步的，通常手動控制故障轉移以避免數據丟失的可能性。無論使用何種區域，三節點集群還可以促進所有三台服務器的計劃硬件和軟件維護，同時為應用程序及其數據提供連續的DR保護。

最大化SQL Server的高可用性

通過在18個地理區域提供55個可用區域，AWS全球基礎架構通過配置具有多個地理位置分散的冗餘的SANless故障轉移群集，為最大化SQL Server高可用性提供了巨大的機會。這種全球覆蓋範圍還使所有SQL Server應用程序和數據都能夠位於最終用戶附近，以提供令人滿意的性能。通過專用解決方案，運營商級高可用性並不意味著支付類似運營商的高成本。由於專用的故障轉移群集軟件能夠有效和高效地使用EC2的計算，存儲和網絡資源，同時易於實施和運行，因此這些解決方案可最大限度地降低任何資本和所有運營支出，從而使高可用性更強大，更經濟實惠。以往。轉載自TheNewStack