Azure VM 上 SQL Server 的 Always On 可用性群組

  • 發行項

適用於：Azure VM 上的 SQL Server

本文介紹 Azure 虛擬機器 (VM) 上 SQL Server 的 Always On 可用性群組 (AG)。

若要開始使用，請參閱可用性群組教學課程。

概觀

Azure 虛擬機器上的 Always On 可用性群組與 Always On 可用性群組內部部署類似，並且依賴基礎 Windows Server 容錯移轉叢集。 不過，由於虛擬機器裝載於 Azure 中，因此也有一些額外的考量，例如 VM 備援，以及在 Azure 網路上路由傳送流量。

下圖說明 Azure VM 上 SQL Server 的可用性群組：

Availability Group

注意

現在可以使用 Azure Migrate，將可用性群組解決方案隨即轉移到 Azure VM 上的 SQL Server。 若要深入了解，請參閱移轉可用性群組。

VM 備援

若要提高備援能力與高可用性，SQL Server VM 應位於相同的可用性設定組，或不同的可用性區域。

將一組 VM 放在相同的可用性設定組中，可防止因設備故障 (可用性設定組中的 VM 不會共用資源) 或更新 (可用性設定組中的 VM 不會同時更新) 而造成資料中心內發生中斷情形。

可用性區域可保護整個資料中心避免故障，每個區域都代表一個區域內的資料中心集合。 藉由確保將資源放在不同的可用性區域，資料中心層級的中斷不會讓所有的 VM 離線。

建立 Azure VM 時，必須在設定可用性設定組和可用性區域之間進行選擇。 Azure VM 無法同時參與兩者。

雖然可用性區域能夠提供比可用性設定組更高的可用性 (99.99% 對比 99.95%)，但也應該考慮效能。 可用性設定組內的 VM 可以放在鄰近放置群組中，以確保彼此接近，進而將兩者之間的網路延遲降到最低。 位於不同可用性區域的 VM 將會有較大的網路延遲，這可能增加在主要和次要複本之間同步處理資料所需的時間。 這可能會導致主要複本的延遲，並在發生未規劃的容錯移轉時提高資料遺失機會。 請務必在負載下測試建議的解決方案，並確保其符合效能和可用性的 SLA。

連線能力

若要比對連線至可用性群組接聽程式的內部部署體驗，請將 SQL Server VM 部署至相同虛擬網路中的多個子網路。 多個子網路不需要 Azure Load Balancer 的額外相依性，或是分散式網路名稱 (DNN)，即可將流量路由傳送至您的接聽程式。

如果您將 SQL Server VM 部署至單一子網路，則可以設定虛擬網路名稱 (VNN) 和 Azure Load Balancer 或分散式網路名稱 (DNN)，將流量路由傳送至您的可用性群組接聽程式。 請檢閱兩者之間的差異，然後針對您的可用性群組部署分散式網路名稱 (DNN) 或虛擬網路名稱 (VNN)。

在使用 DNN 時，多數 SQL Server 功能都會以明確的方式與可用性群組搭配運作，但特定功能可能需要特別考量。 若要深入了解，請參閱 AG 和 DNN 互通性。

此外，VNN 接聽程式與 DNN 接聽程式的功能之間有一些行為差異需要特別注意：

  • 容錯移轉時間：使用 DNN 接聽程式時，容錯移轉時間會更快，因為不需要等候網路負載平衡器偵測到失敗事件並變更其路由。
  • 現有連線：與容錯移轉可用性群組中「特定資料庫」建立的連線將會關閉，但主要複本的其他連線則會保持開啟狀態，因為 DNN 會在容錯移轉過程中保持連線。 這與傳統的 VNN 環境不同，其中主要複本的所有連線通常會在可用性群組容錯移轉時關閉、接聽程式會離線，而且主要複本會轉換成次要角色。 使用 DNN 接聽程式時，您可能需要調整應用程式連接字串，以確保在容錯移轉時將連線重新導向至新的主要複本。
  • 開啟的交易：針對容錯移轉可用性群組中資料庫開啟的交易將會關閉並復原，而且您需要「手動」重新連線。 例如，在 SQL Server Management Studio 中，關閉查詢視窗，然後開啟新的查詢視窗。

在 Azure 中設定 VNN 接聽程式需要負載平衡器。 Azure 中的負載平衡器有兩個主要選項：外部 (公用) 或內部。 外部 (公用) 接聽程式會使用網際網路對應負載平衡器，並與可透過網際網路存取的公用虛擬 IP (VIP) 相關聯。 內部負載平衡器只支援位於相同虛擬網路內的用戶端。 對於各個負載平衡器類型，您必須啟用伺服器直接回傳。

您仍可以透過直接連接至服務執行個體，分別連接至各個可用性複本。 此外，由於可用性群組能與資料庫鏡像用戶端回溯相容，因此只要將可用性複本設定成類似資料庫鏡像，即可連接至這類複本 (例如資料庫鏡像合作夥伴)：

  • 有一個主要複本與一個次要複本。
  • 次要複本設定為不可讀取 ([可讀取次要] 選項設為 [否])。

下列範例使用 ADO.NET 或 SQL Server Native Client 對應至類似此資料庫鏡像組態的範例用戶端連接字串：

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

如需用戶端連線的詳細資訊，請參閱：

單一子網路需要負載平衡器

當您在傳統內部部署 Windows Server 容錯移轉叢集上 (WSFC) 建立可用性群組接聽程式時，系統會使用您提供的 IP 位址為接聽程式建立 DNS 記錄，而此 IP 位址會對應至內部部署網路上交換器和路由器，這位於 ARP 資料表中目前主要複本的 MAC 位址。 叢集透過 Gratuitous ARP (GARP) 執行這項作業，每當在容錯移轉之後選取新的主要伺服器時，這會廣播與網路的最新 IP 對 MAC 位址對應。 在此情況下，IP 位址適用於接聽程式，而 MAC 是目前的主要複本。 GARP 會強制更新交換器和路由器的 ARP 資料表專案，以及連線到接聽程式 IP 位址的任何使用者，並順暢地路由傳送至目前的主要複本。

基於安全性考慮，不允許在任何公用雲端 (Azure、Google、AWS) 上廣播，因此不支援在 Azure 上使用 ARP 和 GARP。 若要克服網路環境的差異，SQL Server 單一子網路可用性群組中的 VM 依賴負載平衡器將流量路由傳送至適當的 IP 位址。 負載平衡器會設定為與接聽程式對應的前端 IP 位址，並指派探查埠，讓 Azure Load Balancer 定期輪詢可用性群組中複本的狀態。 由於只有主要複本 SQL Server VM 會回應 TCP 探查，接著會將連入流量路由傳送至成功回應探查的 VM。 此外，對應的探查埠會設定為 WSFC 叢集 IP，確保主要複本會回應 TCP 探查。

在單一子網中設定的可用性群組必須使用負載平衡器或分散式網路名稱 (DNN) 將流量路由傳送至適當的複本。 若要避免這些相依性，請在多個子網路中設定可用性群組，讓可用性群組接聽程式使用每個子網路中複本的 IP 位址進行設定，並可適當地路由流量。

如果您已在單一子網路中建立可用性群組，您可以將它移轉至多子網路環境。

租用機制

對於 SQL Server，AG 資源 DLL 會根據 AG 租用機制和 Always On 健全狀況偵測來判斷 AG 的健全狀況。 AG 資源 DLL 會透過 IsAlive 作業公開資源健全狀況。 資源監視器會以叢集的活動訊號間隔時間 (由 CrossSubnetDelay 和 SameSubnetDelay 叢集範圍的值設定) 來輪詢 IsAlive。 在主要節點上，只要資源 DLL 的 IsAlive 呼叫傳回 AG 狀況不良，叢集服務就會起始容錯移轉。

AG 資源 DLL 會監視內部 SQL Server 元件的狀態。 Sp_server_diagnostics 會按照 HealthCheckTimeout 所控制的間隔時間，向 SQL Server 報告這些元件的健全狀況。

不同於其他容錯移轉機制，SQL Server 執行個體在租用機制中扮演著主動的角色。 租用機制會用來作為叢集資源裝載和 SQL Server 處理序間的 LooksAlive 驗證。 此機制會用來確認兩邊 (叢集服務和 SQL Server 服務) 都有頻繁接觸、檢查彼此的狀態，最終防止核心分裂案例。

在 Azure VM 中設定 AG 時，設定這些閾值的方式通常要與在內部部署環境中設定不同。 若要根據 Azure VM 的最佳作法設定閾值設定，請參閱叢集最佳做法。

網路組態

盡可能將您的 SQL Server VM 部署至多個子網路，以避免依賴 Azure Load Balancer 或分散式網路名稱 (DNN) 將流量路由至您的可用性群組接聽程式。

在 Azure VM 容錯移轉叢集上，建議每部伺服器 (叢集節點) 一個 NIC。 Azure 網路有實體備援，因此 Azure VM 容錯移轉叢集上不需要額外的 NIC。 雖然叢集驗證報告會發出節點只能在單一網路上連線的警告，但您在 Azure VM 容錯移轉叢集上可以放心忽略此警告。

基本可用性群組

由於基本可用性群組不允許一個以上的次要複本，而且沒有次要複本的讀取權限，因此可對基本可用性群組使用資料庫鏡像連接字串。 若使用連接字串，便不需要有接聽程式。 移除接聽程式相依性對於 Azure VM 上的可用性群組很有幫助，因為移除後當您有多個其他資料庫的接聽程式時，便不需要負載平衡器，或必須將額外的 IP 新增至負載平衡器。

例如，若要使用 TCP/IP 明確地連線到 AG 資料庫 AdventureWorks 上的 Replica_A 或 Replica_B 基本 AG (或只有一個次要複本的 AG，而且次要複本中不允許讀取存取)，則用戶端應用程式可以提供下列資料庫鏡像連接字串，以成功連接至 AG

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

部署選項

提示

藉由在相同 Azure 虛擬網路內的多個子網路中建立 SQL Server VM，您的 Always On 可用性群組將不再需要 Azure Load Balancer 或分散式網路名稱 (DNN)。

有多個選項可用於將可用性群組部署至 Azure VM 上的 SQL Server，有些選項比其他選項更加自動化。

下表提供可用選項的比較：

Azure 入口網站、 Azure CLI/PowerShell 快速入門範本 手動 (單一子網路) 手動 (多個子網路)
SQL Server 版本 2016 + 2016 + 2016 + 2012 + 2012 +
SQL Server 版本 Enterprise Enterprise Enterprise Enterprise、Standard Enterprise、Standard
Windows Server 版本 2016 + 2016 + 2016 + 全部 全部
為您建立叢集 是 .是 .是 無 No
為您建立可用性群組和接聽程式 是 無 無 無 否
獨立建立接聽程式和負載平衡器 N/A 否 無 .是 N/A
可以使用這個方法建立 DNN 接聽程式嗎？ N/A 否 無 .是 N/A
WSFC 仲裁組態 雲端見證 雲端見證 雲端見證 全部 全部
多個區域進行災害復原 否 無 無 .是 是
多重子網路支援 是 無 否 N/A 是
對現有 AD 的支援 是 .是 .是 .是 是
相同區域中的多重地區進行災害復原 是 .是 .是 .是 是
沒有 AD 的分散式 AG 否 無 無 .是 是
沒有叢集的分散式 AG 否 無 無 .是 是
需要負載平衡器或 DNN No .是 .是 .是 否

後續步驟

若要開始使用，請檢閱 HADR 最佳做法，然後使用可用性群組教學課程手動部署可用性群組。

若要深入了解，請參閱：