Azure 虛擬機中 sql server 的高可用性和災難恢復

帶有 SQL Server 的 Azure 虛擬機 (VM) 有助于降低高可用性和災難恢復 (HADR) 數據庫解決方案的成本。Azure 虛擬機支持大多數充當云解決方案和混合解決方案的 SQL Server HADR 解決方案。在僅包含 Azure 的解決方案中，整個 HADR 系統都在 Azure 中運行。而在混合配置中，解決方案的一部分在 Azure 中運行，另一部分則在組織的本地運行。Azure 環境具有靈活性，允許部分或完全遷移至 Azure，以滿足 SQL Server 數據庫系統對于預算和 HADR 的要求。

備注

Azure 具有用于創建和處理資源的兩個不同部署模型：資源管理器部署模型和經典部署模型。這篇文章介紹如何使用這兩種模型，但Microsoft 建議大多數最新部署使用 Resource Manager 模型。

有關部署類型，請參閱： https://aka.ms/AA6vwnq

了解對 HADR 解決方案的需求

有責任確保數據庫系統擁有服務級別協議 (SLA) 要求的 HADR 功能。Azure 提供了高可用性機制，例如云服務的服務修復和虛擬機的故障恢復檢測，但這一事實自身并不保證你能夠達到所需 SLA 的要求。 這些機制可以保護 VM 的高可用性，但不能保護在 VM 內部運行的 SQL Server 的高可用性。VM 聯機并正常運行時，SQL Server 實例也可能會出故障。 再者，即便是 Azure 提供的高可用性機制，也會在 VM 遇到從軟件或硬件故障進行恢復、操作系統升級等事件時，為其留出可能較長的停機時間。

此外，使用稱作異地復制的功能在 Azure 中實現的異地冗余存儲 (GRS)，可能不適合作為數據庫的災難恢復解決方案。 因為異地復制功能會異步發送數據，在發生災難的情況下，最近的更新可能丟失。

數據和日志文件各自在不同磁盤上的情況下不支持異地復制部分中提供了有關異地復制限制的詳細信息。

詳細請參閱：https://aka.ms/AA6vwns

HADR 部署體系結構

Azure 支持的 SQL Server HADR 技術包括：

Always On 可用性組

Always On 故障轉移群集實例

日志傳送

使用 Azure Blob 存儲服務執行 SQL Server 備份和還原

數據庫鏡像 - SQL Server 2016 中已棄用

可將多種技術配合使用，以實現具有高可用性和災難恢復功能的 SQL Server 解決方案。 根據所用技術的不同，混合部署可能需要使用 VPN 隧道連接 Azure 虛擬網絡。以下部分顯示了某些部署體系結構的示例。

僅限 Azure：高可用性解決方案

可針對在數據庫級別具有 AlwaysOn 可用性組（稱為可用性組）的 SQL Server 提供高可用性解決方案。 還可以在具有 AlwaysOn 故障轉移群集實例的實例級別創建高可用性解決方案。 對于其他冗余，可以通過在故障轉移群集實例上創建可用性組，在兩個級別上創建冗余。

技術

示例體系結構

可用性組

在同一區域的Azure VM 中運行的可用性副本提供高可用性。需要配置域控制器VM，因為Windows故障轉移群集需要Active Directory域。 為了實現更高的冗余和可用性，Azure Vm 可以部署在不同的可用性區域，https://aka.ms/AA6vwnx中，如可用性組概述 ，https://aka.ms/AA6w3xl中所述。如果可用性組中的SQL Server Vm 部署在可用性區域中，請使用以下文章中所述的適用于偵聽器的標準負載均衡器，https://aka.ms/AA6w3xn- AZURE SQL VM CLI，https://aka.ms/AA6w3xp & azure 快速入門模板，https://aka.ms/AA6w3xq 。 有關詳細信息，請參閱在 Azure 中配置可用性組 (GUI) ，https://aka.ms/AA6vwo2。

故障轉移群集實例

可通過4種不同的方式創建需要共享存儲的故障轉移群集實例（FCI）。 1. 使用Windows Server 2016 在 Azure Vm 中運行的雙節點故障轉移群集存儲空間直通 (S2D )， https://aka.ms/AA6vwpe提供基于軟件的虛擬 SAN。

2. 使用高級文件共享，https://aka.ms/AA6w3z3

在Azure vm 中運行的雙節點故障轉移群集。高級文件共享是完全支持的、與故障轉移群集實例完全支持的、低延遲文件共享。 3. 使用第三方群集解決方案支持的存儲在 Azure Vm 中運行的雙節點故障轉移群集。 有關使用 SIOS DataKeeper 的具體示例，請參閱使用故障轉移群集和第三方軟件 SIOS Datakeeper 的文件共享的高可用性，https://aka.ms/AA6vwph。 4. 通過 ExpressRoute 在具有遠程iSCSI 目標共享塊存儲的 Azure Vm 中運行的雙節點故障轉移群集。 例如，NetApp 專用存儲 (NPS) 使用 Equinix 通過 ExpressRoute向Azuer VM 公開 iSCSI 目標。 對于第三方共享存儲和數據復制解決方案，如有任何關于在故障轉移時訪問數據的問題，請聯系供應商。

Azure：災難恢復解決方案

可將可用性組、數據庫鏡像或備份和還原與存儲 Blob 配合使用，為 Azure 中的 SQL Server 數據庫提供災難恢復解決方案。

技術

示例體系結構

可用性組

可用性副本在Azure VM 中跨越多個數據中心運行以實現災難恢復。這種跨區域解決方案可以防止站點完全中斷。

在某個區域內，所有副本應該位于同一云服務和同一VNet中。由于每個區域將有單獨的VNet，因此這些解決方案需要VNet到VNet連接。有關詳細信息，請參閱使用Azure門戶配置VNet到VNet 連接，https://aka.ms/AA6w7bv。 有關詳細說明，請參閱在不同區域的Azure 虛擬機上配置SQL Server可用性組，https://aka.ms/AA6wezb。

數據庫鏡像

主體和鏡像以及服務器在不同數據庫中運行以實現災難恢復。必須使用服務器證書進行部署。Azure VM上的SQL Server 2008 和 SQL Server 2008 R2 不支持SQL Server數據庫鏡像。

使用Azure Blob 存儲服務進行備份和還原

生產數據庫直接備份到不同數據中心內的Blob存儲以實現災難恢復。

有關詳細信息，請參閱Azure虛擬機中SQL Server 的備份和還原，https://aka.ms/AA6w3z7。

使用 Azure Site Recovery 將SQL Server 復制和故障轉移到Azure

一個Azure數據中心的生產SQL Server 直接復制到其他Azure數據中心的Azure 存儲以實現災難恢復。

有關詳細信息，請參閱使用 SQL Server 災難恢復和 Azure Site Recovery來保護 SQL Server，https://aka.ms/AA6vwpk。

混合IT：災難恢復解決方案

可將可用性組、數據庫鏡像、日志傳送以及備份和還原與 Azure Blob 存儲配合使用，在混合 IT 環境中為 SQL Server 數據庫提供災難恢復解決方案。

技術

示例體系結構

可用性組

某些可用性副本運行在 Azure VM 中，另一些則在本地運行，以實現跨站點災難恢復。生產站點可位于本地，也可以位于 Azure 數據中心。

由于所有可用性副本必須在同一故障轉移群集中，因此該群集必須同時跨越這兩個網絡（多子網故障轉移群集）。此配置需要在 Azure 與本地網絡之間使用VPN 連接。

為了成功地對數據庫進行災難恢復，還應在災難恢復站點上安裝副本域控制器。可以使用SSMS中的“添加副本向導”將Azure 副本添加到現有的Always On可用性組。 有關詳細信息，請參閱教程“將 Always On 可用性組擴展到Azure中”。

數據庫鏡像

一個伙伴在Azure VM 中運行，另一個則在本地運行，以實現使用服務器證書進行跨站點災難恢復。合作伙伴不必在同一 Active Directory 域中，并且不需要 VPN 連接。

另一種數據庫鏡像方案是一個合作伙伴在Azure VM中運行，另一個則在同一Active Directory 域中本地運行，以實現跨站點災難恢復。需要在Azure虛擬網絡與本地網絡之間使用 VPN 連接，詳情參閱，https://aka.ms/AA6wezc。

為了成功地對數據庫進行災難恢復，還應在災難恢復站點上安裝副本域控制器。Azure VM 上的SQL Server 2008和SQL Server 2008 R2不支持SQL Server 數據庫鏡像。

日志傳送

一個服務器在Azure VM中運行，另一個則在本地運行，以實現跨站點災難恢復。日志傳送依賴于Windows文件共享，因此需要在Azure虛擬網絡與本地網絡之間使用VPN連接。

為了成功地對數據庫進行災難恢復，還應在災難恢復站點上安裝副本域控制器。

使用Azure Blob存儲服務進行備份和還原

本地生產數據庫直接備份到Azure Blob存儲以實現災難恢復。

有關詳細信息，請參閱Azure虛擬機中SQL Server的備份和還原，https://aka.ms/AA6w7bw。

使用Azure Site Recovery將SQL Server復制和故障轉移到Azure

本地生產SQL Server直接復制到Azure存儲以實現災難恢復。

有關詳細信息，請參閱使用SQL Server 災難恢復和Azure Site Recovery來保護SQL Server， https://aka.ms/AA6wezf。

Azure中的SQL Server HADR的重要注意事項

Azure VM、存儲和網絡的運行特征與本地非虛擬化的 IT 基礎結構不同。 需要了解這些區別并設計可適應這些區別的解決方案，才能成功地在 Azure 中實現 HADR SQL Server 解決方案。

使用 Azure 中的高可用性集，可將高可用性節點放置在單獨的容錯域 (FD) 和更新域 (UD) 中。基礎 Azure 平臺為可用性集中的每個虛擬機分配一個更新域和一個容錯域。數據中心內的這種配置可以確保在發生計劃內或計劃外維護事件時，至少有一個虛擬機可用，并滿足 99.95% 的 Azure SLA 要求。 若要配置高可用性設置，請將所有參與的 SQL 虛擬機放置在同一可用性集中，以避免在維護事件期間應用程序或數據丟失。只有同一云服務中的節點可加入同一可用性集。

有關詳細信息，請參閱管理虛擬機的可用性：https://aka.ms/AA6w7c5

可用性區域是Azure區域中獨特的物理位置。每個區域由一個或多個數據中心組成，這些數據中心配置了獨立電源、冷卻和網絡。 區域內可用性區域的物理分離可確保至少有一個虛擬機可用，并滿足99.99% 的Azure SLA要求，從而保護應用程序和數據免受數據中心故障的影響。 若要配置高可用性，請將參與的SQL虛擬機分散到該區域中的可用可用性區域。會產生可用性區域間VM到VM的數據傳輸費用。

有關詳細信息，請參閱可用性區域： https://aka.ms/AA6w7c6

Azure中的DHCP服務不符合RFC標準，可能會導致創建某些故障轉移群集配置失敗，因為向群集網絡名稱分配了重復的 IP 地址（例如 IP 地址與某個群集節點相同）。實現可用性組時，這種情況會產生一個問題，因為它依賴于Windows故障轉移群集功能。

創建兩節點群集并使其聯機時，請考慮此應用場景：

· 群集聯機，NODE1會為群集網絡名稱請求一個動態分配的IP地址。

· DHCP服務除了NODE1自身的IP地址以外不提供任何 IP地址，因為DHCP服務識別出請求來自NODE1自身。

· Windows檢測到同時向NODE1和故障轉移群集網絡名稱分配了一個重復的地址，并且默認群集組未能聯機。

· 默認群集組移至NODE2，后者將NODE1的IP地址視為群集IP地址，并使默認群集組聯機。

· 當NODE2嘗試與NODE1建立連接時，在NODE1上定向的數據包從不離開NODE2，因為后者將NODE1的 IP 地址解析為其自身。NODE2無法與NODE1建立連接，丟失仲裁并關閉群集。

· 同時，NODE1可向NODE2發送數據包，但NODE2無法回復。NODE1丟失仲裁并關閉群集。

可通過將未使用的靜態 IP 地址（如 169.254.1.1 等鏈接本地 IP 地址）分配給群集網絡名稱，讓群集網絡名稱聯機，從而避免這種情況發生。

若要簡化此過程，請參閱在 Azure 中針對可用性組配置 Windows 故障轉移群集，https://aka.ms/AA6wezu。

有關詳細信息，請參閱在 Azure 中配置可用性組 (GUI)，https://aka.ms/AA6w7cc。

運行 Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2和Windows Server 2016的 Azure VM支持可用性組偵聽器。這種支持的實現，是借助于在 Azure VM上啟用的負載均衡終結點，它們都是可用性組節點。必須執行特殊的配置步驟，才能讓這些偵聽器對在Azure中運行和本地運行的客戶端應用程序都有效。

有兩個主要選項用于設置偵聽器：“外部(公共)”或“內部”。外部（公共）偵聽器使用面向Internet的負載均衡器并與可通過 Internet訪問的公共虛擬IP (VIP)相關聯。內部偵聽器使用內部負載均衡器，且僅支持同一虛擬網絡中的客戶端。 對于任一負載均衡器類型，都必須啟用直接服務器返回。

如果可用性組跨多個Azure子網（例如，跨 Azure 區域的部署），則客戶端連接字符串必須包含“MultisubnetFailover=True”。這會導致與不同子網中的副本建立并行連接。

有關設置偵聽器的說明，請參閱：

在 Azure 中配置可用性組的 ILB 偵聽器，https://aka.ms/AA6vwpt

在 Azure 中配置可用性組的外部偵聽器，https://aka.ms/AA6vwpu

仍可通過直接連接到服務實例，單獨連接到每個可用性副本。此外，由于可用性組與數據庫鏡像客戶端向后兼容，因此可以像數據庫鏡像伙伴一樣連接到可用性副本，只要這些副本配置得類似于數據庫鏡像即可：

一個主副本和一個輔助副本

將輔助副本配置為不可讀（“可讀輔助副本”選項設置為“否”）

下面是一個示例客戶端連接字符串，它對應于這個使用 ADO.NET 或 SQL Server 本機客戶端的類似于數據庫鏡像的配置：

復制

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

有關客戶端連接的詳細信息，請參閱：

將連接字符串關鍵字用于 SQL Server 本機客戶端，https://aka.ms/AA6vwpw

將客戶端連接到數據庫鏡像會話 (SQL Server)，https://aka.ms/AA6vwpx

在混合 IT 環境中連接到可用性組偵聽器，https://aka.ms/AA6wf01

可用性組偵聽器、客戶端連接和應用程序故障轉移 (SQL Server)，https://aka.ms/AA6wf03

將數據庫鏡像連接字符串用于可用性組 ，https://aka.ms/AA6wf05

混合 IT 環境中的網絡延遲

在部署HADR解決方案時，應該假設本地網絡和Azure之間可能存在很高的網絡延遲。 將副本部署到Azure時，同步模式應使用異步提交而非同步提交。同時在本地和Azure中部署數據庫鏡像服務器時，請使用高性能模式，而非高安全模式。

Azure 磁盤中的異地復制不支持將同一數據庫的數據文件和日志文件各自存儲在不同的磁盤上。GRS獨立并異步地復制對每個磁盤的更改。此機制保證單個磁盤中異地復制副本上的寫順序，但不保證多個磁盤的異地復制副本上的寫順序。如果將數據庫配置為將其數據文件和其日志文件各自存儲在不同的磁盤上，則災難后恢復的磁盤所含的數據文件副本可能比日志文件副本新，而這違反 SQL Server中的預寫日志以及事務的ACID屬性。如果無法對存儲帳戶禁用異地復制，則應將給定數據庫的所有數據和日志文件都保留在同一磁盤上。 如果因數據庫較大而必須使用多個磁盤，則需要部署上面列出的某個災難恢復解決方案以確保數據冗余。

后續步驟參閱

如果需要創建使用SQL Server的Azure虛擬機，請參閱在 Azure 上預配 SQL Server 虛擬機，https://aka.ms/AA6wf06。

若要使 Azure VM上運行的SQL Server保持最佳性能，請參閱Azure虛擬機中 SQL Server的性能最佳實踐中的指導，https://aka.ms/AA6w7ci。

有關其他與在Azure VM中運行SQL Server相關的主題，請參閱SQL Server>（Azure 虛擬機上的 SQL Server），https://aka.ms/AA6wf09。

在 Azure 中安裝新的 Active Directory 林，https://aka.ms/AA6wf0b

在 Azure VM 中創建用于可用性組的故障轉移群集， https://aka.ms/AA6wf0e

2019 Microsoft Ignite The Tour 即將到來！微軟將把這場匯聚世界前沿科技的開發者盛宴帶到你的身邊，本著“求知、求同、求索”的原則，為廣大開發者、IT專業人士以及數據分析師提供為期兩天的專屬免費深度交流培訓。北京站已經圓滿落下帷幕，深圳站、上海站將陸續在2020年1月13-14日深圳會展中心，2020年3月18-19日上海世博中心舉辦，繼續難忘的 Ignite 中國之旅。除了一如既往的專業技術交流指導——350+ 專家現場零距離互動與 100+ 深度技術研討會及培訓之外，更是首次實現了免費尊享，技術專家和開發者們將全程免費參與。

Ignite the Tour·深圳站 已開啟報名即刻掃碼注冊，尊享超值禮遇！Ignite the Tour·上海站 已開啟報名即刻掃碼注冊，尊享超值禮遇！Ignite the Tour·北京站 2019年12月10日至11日北京國家會議中心 報名已結束