如何使用 Azure Site Recovery (ASR) 複製使用 SIOS DataKeeper 進行群集存儲的 Windows Server 故障轉移群集 (WSFC)

介紹

因此，您已經在 Azure 中構建了一個 SQL Server 故障轉移集群實例 (FCI)，或者可能是一個 SAP ASCS/ERS 集群。 集群的每個節點都駐留在不同的可用區 (AZ) 中，或者您可能有嚴格的延遲要求並且正在使用 Placement Proximity Group (PPG) 並且您的節點都駐留在同一個可用性集中。 無論在哪種情況下，您的關鍵業務應用程序現在都比僅運行單個實例具有更高級別的可用性。

現在你有高可用性 (HA)覆蓋，你要做什麼災難恢復? 奪走多個 AZ 的區域性災難很少見，但正如最近的歷史向我們展示的那樣，大自然母親真的可以打出一記重拳。 如果整個區域離線，您需要做好準備。

Azure Site Recovery (ASR) 是 Microsoft 的災難恢復即服務 (DRaaS) 產品，可讓您將整個 VM 從一個區域複製到另一個區域。 它還可以將虛擬機和物理服務器從本地複製到 Azure，但在本博文中，我們將重點介紹 Azure 區域到區域的 DR 功能。

設置 Azure Site Recovery

我們將假設您已經使用SIOS 數據保持器. 如果沒有，這裡有一些提示可以幫助您入門。

Azure VM 上使用 SQL Server 的故障轉移群集實例SAP ASCS/SCS 集群共享磁盤的 SIOS DataKeeper Cluster Edition我們還將假設您熟悉 Azure Site Recovery。 我建議您閱讀最新的，而不是另一個關於設置 ASR 的指南文件來自微軟。 本文將重點介紹您可能沒有考慮過的一些事情，以及在故障轉移到不同子網後修復集群所需的具體步驟。

配對區域

在開始 DR 路徑之前，您應該了解 Azure 配對區域的概念。 Azure 中的每個區域都有一個首選 DR 區域。 如果您想了解有關配對區域的更多信息，請參閱文件提供了很好的背景。 有一些真的很好好處使用您的配對區域，但實際上由您決定要使用哪個區域來託管您的 DR 站點。

雲見證位置

當您最初構建集群時，您必須為您的仲裁選擇見證類型。 您可能選擇了文件共享見證或云見證。 通常，這些見證類型中的任何一種都應位於與集群節點分開的 AZ 中。

但是，當您考慮到在發生災難時，您的整個集群將在您的 DR 區域中運行時，有一個更好的選擇。 您應該使用雲見證，並將其放置在您的 DR 區域中。 通過將雲見證放置在 DR 區域中，您不僅可以為本地 AZ 故障提供彈性，還可以在整個區域發生故障並且您必須使用 ASR 來恢復 DR 區域中的集群時為您提供保護。 通過 Dynamic Quorum 和 Dynamic Witness 的魔力，您可以確定即使您的 DR 區域暫時下線，也不會影響您的生產集群。

多虛擬機一致性

使用 ASR 複製集群時，啟用多虛擬機一致性確保每個集群節點的恢復點來自同一時間點。 這確保了虛擬機之間發生的 DataKeeper 塊級複製將能夠在恢復後繼續，而無需完全重新同步。

崩潰一致性恢復點

複製集群中不支持應用程序一致的恢復點。 配置 ASR 複製選項時，不要啟用應用程序一致的恢復點。

故障轉移後保留 IP 地址？

使用 ASR 複製到 DR 站點時，有一種方法可以保持 VM 的 IP 地址相同。 微軟在題為“在故障轉移期間保留 IP 地址. 如果您可以在故障轉移後保持 IP 地址不變，它將簡化恢復過程，因為您不必修復任何基於 IP 地址的集群 IP 地址或 DataKeeper 鏡像端點。

但是，根據我的經驗，我從未見過有人真正遵循上述指導，因此在不同子網中恢復集群需要在恢復後執行一些額外步驟，然後才能使集群聯機。

您的第一次故障轉移嘗試

恢復計劃

由於您使用的是多虛擬機一致性，因此您必須使用恢復計劃對虛擬機進行故障轉移。 這文件提供了關於如何做到這一點的非常簡單的指導。 恢復計劃將要恢復的 VM 分組在一起，以確保它們一起進行故障轉移。 您甚至可以將多組虛擬機添加到同一個恢復計劃中，以確保您的整個基礎架構以有序的方式進行故障轉移。

恢復計劃還可以啟動恢復後腳本以幫助故障轉移成功完成恢復。 我在下面描述的步驟都可以作為您的恢復計劃的一部分編寫出來，從而使整個恢復過程完全自動化。 我們不會在這篇博文中介紹該過程，但 Microsoft記錄這個過程.

靜態 IP 地址

作為恢復過程的一部分，您需要確保新 VM 具有靜態 IP 地址。 您必須調整 Azure 門戶中的接口屬性，以便 VM 始終使用相同的地址。 如果您想向接口添加公共 IP 地址，此時您也應該這樣做。

網絡配置

在 DR 站點中成功恢復複製的 VM 後，您要做的第一件事是驗證基本連接。 IP 配置是否正確？ 實例是否使用正確的 DNS 服務器？ 名稱解析是否正常運行？ 你能ping通遠程服務器嗎？

如果網絡通信有任何問題，那麼下面描述的其餘步驟必然會失敗。 不要跳過這一步！

負載均衡器

您可能知道，Azure 中的集群需要您配置負載均衡器才能使客戶端連接正常工作。 負載平衡器不會作為恢復計劃的一部分進行故障轉移。 您需要基於現在駐留在這個新 vNet 中的集群構建一個新的負載均衡器。 您可以手動執行此操作，也可以將其作為恢復計劃的一部分自動執行。

網絡安全組

在這個新子網中運行還意味著您必須指定要應用於這些實例的網絡安全組。 您必須確保實例能夠通過所需端口進行通信。 同樣，您可以手動執行此操作，但最好將其編寫為您的恢復計劃的一部分。

修復 IP 集群地址

如果您無法進行前面描述的更改以恢復同一子網中的實例，則必須完成以下步驟來更新集群 IP 地址和 DataKeeper 地址以在新子網中使用。

每個集群都有一個核心集群 IP 地址。 如果在故障轉移後啟動 WSFC UI，您將看到集群將無法連接。 這是因為集群使用的 IP 地址在新子網中無效。

如果您打開該 IP 地址資源的屬性，您可以將 IP 地址更改為可在新子網中使用的地址。 確保同時更新網絡和子網掩碼。

修復該 IP 地址後，您將必須對您在集群資源中使用的任何其他集群地址執行相同的操作。

修復 DataKeeper 鏡像地址

SIOS DataKeeper 鏡像使用 IP 地址作為鏡像端點。 這些存儲在鏡像和鏡像作業中。 如果您在不同的子網中恢復基於 DataKeeper 的集群，您將看到鏡像處於 Resync Pending 狀態。 您還會注意到源 IP 和目標 IP 反映的是原始子網，而不是 DR 站點的子網。

解決此問題需要從 SIOS 運行一個名為CHANGEMIRRENDPOS . CHANGEMIRRORENDPOINTS 的用法如下。

emcmd <NEW source IP> CHANGEMIRRORENDPOINTS <volume letter> <ORIGINAL target IP> <NEW source IP> <NEW target IP> 在我們的示例中，命令和輸出如下所示。

命令運行後，DataKeeper GUI 將更新以反映新的 IP 地址，如下所示。 鏡像也將進入鏡像狀態。

結論

您現在已經成功地配置和測試了關鍵業務應用程序的災難恢復，結合使用 SIOS DataKeeper 實現高可用性和 Azure Site Recovery 實現災難恢復。 如果您有任何疑問，或者想諮詢 SIOS，以幫助您為 SQL Server、SAP ASCS 和 ERS、SAP HANA、Oracle 或其他關鍵業務應用程序等關鍵業務應用程序設計和實施高可用性和災難恢復，請聯繫我們.