共用方式為

已啟用 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 關於商務持續性和災害復原中登陸區域的 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 受管理執行個體 時，請一律定義備份的記憶體類別，以避免預設為資料儲存類別。

  • 針對備份磁碟區使用支援 ReadWriteMany （RWX） 的記憶體類別。 如需指引，請參閱已啟用 Azure Arc 的記憶體專業領域 SQL 受管理執行個體。

  • 開始還原作業之前，請使用 選擇性參數 --dry-run 先驗證作業是否成功。 如需詳細資訊，請參閱 使用 az CLI 從時間點建立資料庫。

  • 建立將需要較長保留期限的備份傳送至 Azure 或其他內部部署冷記憶體的程式。

  • 視需要監視備份所取用的記憶體，以判斷您是否可以容納較長的保留期。

高可用性

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

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

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

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

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

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

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

災害復原

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

  • 執行一般災害復原演練，以驗證故障轉移程式。

  • 建立起始手動和強制故障轉移的程式。

  • 若要了解監視叢集健全狀況的最佳做法，以及瞭解何時需要故障轉移，請參閱啟用 Azure Arc 的管理和監視 SQL 受管理執行個體。

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

下一步

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