Share via

已啟用 Azure Arc 的商務持續性和災害復原SQL 受管理執行個體

  • 發行項

已啟用 Azure Arc 的SQL 受管理執行個體供應商務持續性和災害復原的功能， (BCDR) ，可協助企業從中斷復原，並在最短停機時間下繼續運作。

本文提供設定和管理商務持續性功能的重要設計考慮和建議，例如時間點還原、高可用性和災害復原。

架構

下列架構圖顯示業務關鍵服務層級中已啟用 Arc 之SQL 受管理執行個體的高可用性功能，可支援近乎零的停機時間進行容錯移轉。 如果主要實例失敗，負載平衡器會停止將流量傳送至該實例。 然後，其中一個次要實例會升級為主要實例，而新升級的實例會開始接收來自負載平衡器的讀寫流量。 在失敗的實例重新上線之後，它會新增為次要實例。

此圖顯示高可用性商務關鍵實例的作業狀態。

顯示主要複本失敗並將次要複本升階為主要複本的圖表。

顯示主要複本失敗的圖表。

顯示已還原作業狀態的圖表。

下列架構圖顯示已啟用 Arc 的SQL 受管理執行個體如何在兩個不同的月臺中部署兩個不同的 Kubernetes 叢集，以進行災害復原。

此圖顯示跨兩個叢集在災害復原設定中部署的 Azure Arc 啟用SQL 受管理執行個體。

下列架構圖顯示啟用 Arc 的SQL 受管理執行個體在起始災害復原容錯移轉時如何回應。

此圖顯示跨兩個叢集起始已啟用 Azure Arc 的SQL 受管理執行個體災害復原容錯移轉。

設計考量

若要評估已啟用 Azure Arc SQL 受管理執行個體對整體 BCDR 模型的影響，請檢閱商務持續性和災害復原中登陸區域的 BCDR 建議。 請注意， 商務持續性和災害復原 的重點只是商務持續性的設計建議，但實例的高可用性和復原也取決於基礎 Kubernetes 基礎結構的可用性。

時間點還原

  • 定義復原 點目標 的目標 (RPO) 和 復原時間目標 ， (RTO) 。

  • 決定您想要在支援的保留限制內保留和還原備份的時間長度。

  • 請考慮儲存體的影響，以及增加備份保留期的成本。 預設保留期為七天。 在此持續時間中，您最多可以還原七天，而且每五分鐘取得一次完整備份、每日差異和交易記錄備份。

  • 請考慮要針對永續性磁片區用於備份的 儲存體類別 。 如需指引，請參閱已啟用 Azure Arc 的儲存體專業領域SQL 受管理執行個體。

  • 請考慮預期資料大小和已設定保留期間內容中備份的永續性磁片區大小。

  • 如需儲存體的最佳做法，請參閱已啟用 Azure Arc 的儲存體專業領域SQL 受管理執行個體。

  • 備份一律會在主要複本上執行。 識別配置給實例的資源時，請考慮備份和還原程式的效能影響。

  • 請考慮到資料庫的時間點還原無法覆寫現有的資料庫。 不過，他們可以將資料還原至相同實例上的新資料庫。

  • 如果您的應用程式在還原程式期間處於線上狀態，請考慮完整復原資料庫所需的其他步驟。

  • 請考慮將資料庫還原至多複本實例所需的額外步驟，如 將資料庫還原至多複本實例中所述。

  • 決定資料庫管理員用來設定和還原備份的工具。 如需詳細資訊，請參閱連線到已啟用 Azure Arc 的SQL 受管理執行個體。

高可用性

  • 檢閱工作負載的可用性需求，並決定最適合您部署已啟用 Arc SQL 受管理執行個體的服務層級：

    • 在常規用途服務層級中，有單一複本可供使用，而且可透過 Kubernetes 協調流程達成高可用性。
    • 在業務關鍵服務層級中，已啟用 Azure Arc 的SQL 受管理執行個體除了 Kubernetes 協調流程原生提供的功能之外，還提供自主可用性群組。

  • 請考慮常規用途服務層級中停機的潛在業務影響，因為只有一個複本存在而可能造成。

  • 請考慮在業務關鍵服務層級中部署多少個複本，一到三個複本。

  • 在具有兩個或多個複本的業務關鍵服務層級中部署實例時，您可以將次要複本設定為可讀取。 決定要在業務關鍵服務層中部署的次要複本數目。 如需變更數位的資訊，請參閱 設定可讀取的次要複本。

  • 使用選擇性參數--sync-secondary-to-commit，決定透過認可業務關鍵服務層級中交易所需的次要複本數目，將一致性優先于可用性。 如果複本之間有連線問題，主要複本可能不會認可任何交易：

    • 在兩個複本組態中，必須在兩個複本上認可交易，主要複本才能接收成功訊息。
    • 在三個複本組態中，至少三個複本的兩個必須認可交易才能傳回成功訊息。

  • 決定是否需要將特定複本指定為主要複本。 如需指定主要複本的詳細資訊，請參閱 慣用的主要複本。

  • 決定您將使用的 Kubernetes 服務類型、 LoadBalancer 或 NodePort。 如果您使用負載平衡器，則應用程式可以重新連線到相同的主要端點，而 Kubernetes 會將連線重新導向至新的主要端點。 如果您使用節點埠，則應用程式必須重新連線到新的 IP 位址。

災害復原

  • 在異地主要和異地次要月臺中，已啟用 Azure Arc 的實例SQL 受管理執行個體在計算和容量中必須相同，而且部署至相同的服務層級。

  • 決定當您建立兩個裝載實例的叢集可存取的災害復原組態時，要在其中儲存鏡像憑證的位置。

  • 請考慮如何監視主要實例的停機時間，以決定何時執行容錯移轉至次要實例。

  • 每個實例都有自己的端點。 請考慮您的應用程式在容錯移轉時如何存取主要端點，且中斷程度下限。

設計建議

下列各節列出時間點還原、高可用性和災害復原的設計建議。

時間點還原

高可用性

  • 執行一般鑽研，以驗證已啟用 Arc SQL 受管理執行個體 實例的高可用性。 鑽研的範例包括刪除常規用途實例中的 Pod，以及業務關鍵實例中複本失敗。

  • 在業務關鍵層中，在三個複本組態中部署實例，而不是兩個複本組態，以達到近乎零的資料遺失。

  • 若要取得更好的可用性，請在部署實例時，使用 LoadBalancer 作為服務類型。

  • 檢閱已啟用 Azure Arc SQL 受管理執行個體的高可用性限制。

  • 檢閱 支援的可用性模式 ，以根據高可用性需求決定要使用的模式。

  • 部署具有多個複本的業務關鍵實例時，請使用其中一個次要複本進行讀取工作負載。 您的應用程式連接字串必須將次要端點指定為服務接聽程式，以便重新導向至次要複本。 如需端點的相關資訊，請參閱 取得主要和次要端點和 AG 狀態。

  • 若要瞭解監視實例可用性的最佳做法，請參閱Azure Arc 啟用SQL 受管理執行個體的管理與監視。

災害復原

  • 請確定已啟用 Arc 的實例SQL 受管理執行個體主要和次要月臺的名稱不同，且網站的共用名稱稱值相同。

  • 執行一般災害復原演練來驗證容錯移轉程式。

  • 建立程式以起始手動和強制容錯移轉。

  • 若要瞭解監視叢集健康情況的最佳作法，以及瞭解何時需要容錯移轉，請參閱Azure Arc 啟用SQL 受管理執行個體的管理與監視。

  • 在 DNS 伺服器中定義 分散式可用性群組 共用名稱稱的 DNS 記錄，以避免需要在容錯移轉期間手動建立 DNS 記錄。

下一步

如需混合式和多重雲端雲端旅程的詳細資訊，請參閱下列文章：