Azure 服務匯流排地理災害復原

許多企業必須能夠在資料處理資源的災難性中斷下恢復，在某些情況下，這甚至是產業法規的要求。

Azure 服務匯流排已將個別機器或甚至整個機架的重大失敗風險，分散到資料中心內跨多個失敗網域的叢集，還實作透明的失敗偵測和容錯移轉機制，讓服務在保證的服務等級內繼續運作，發生這類失敗時，通常也不會明顯中斷。 進階命名空間可有兩個以上的傳訊單位，而且這些傳訊單位分散在資料中心內的多個失敗網域，支援全作用中服務匯流排叢集模型。

針對進階層命名空間，中斷風險會進一步分散到三個位於不同實體位置的設備 (可用性區域)，而且服務會保留足夠的容量，立即應付徹底失去資料中心的重大事件。 失敗網域內的全作用中 Azure 服務匯流排叢集模型，以及可用性區域支援，在嚴重硬體失敗的復原能力，甚至是整個資料中心設施的嚴重遺失方面，優於任何內部部署訊息代理程式產品。 然而，還是可能有大規模實體損毀的嚴重情況，甚至連這些措施也難以防範。

服務匯流排異地災害復原功能旨在更輕鬆從如此重大災害中復原，並永久放棄失敗的 Azure 區域，而不需要變更應用程式設定。 放棄 Azure 區域通常牽涉數個服務，此功能旨在協助保留複合應用程式設定的完整性。 此功能適用於全球的服務匯流排進階 SKU。

異地災害復原功能確保命名空間的整個設定 (佇列、主題、訂用帳戶、篩選條件)，在配對時持續從主要命名空間複寫至次要命名空間，還可讓您隨時起始僅此一次從主要命名空間容錯移轉至次要命名空間。 容錯移轉會將已選擇的命名空間別名重新指向次要命名空間，然後中斷配對。 容錯移轉一旦起始，幾乎立即完成。

需要考量的重要事項

• 此功能可在相同設定下立即持續作業，但不會複寫保留在佇列、主題訂用帳戶或無效信件佇列中的訊息。 若要保留佇列語意，複寫不只須複寫訊息資料，還要複寫訊息代理程式中的每個狀態變更。 對於大部分服務匯流排命名空間，所需的複寫流量遠超過應用程式流量，且有高輸送量佇列時，儘管已經從主要命名空間中刪除，大部分訊息仍會複寫到次要命名空間，因而造成過度浪費流量。 對於高延遲複寫路由，其套用於您為異地災害復原選擇的許多配對，複寫流量也可能因為延遲引發的節流影響，無法持續跟上應用程式流量。
• 對主要命名空間中服務匯流排實體的 Microsoft Entra 角色型存取控制 (RBAC) 指派，不會複寫至次要命名空間。 在次要命名空間中手動建立角色指派，以安全存取這些實體。
• 不會複寫下列設定。
  • 虛擬網路設定
  • 私人端點連線
  • 啟用所有網路存取
  • 啟用信任的服務存取
  • 公用網路存取
  • 預設網路動作
  • 身分識別和加密設定 (客戶自控金鑰加密或攜帶您自己的金鑰 (BYOK) 加密)
  • 啟用自動調整
  • 停用本機驗證
• 不支援將分割命名空間與非分割命名空間進行配對。
• 如果 AutoDeleteOnIdle 為實體啟用，當故障轉移發生時，實體可能不會出現在次要命名空間中。 當次要命名空間變成主要命名空間時，上次存取狀態 (不是中繼資料的一部分) 將無法供新的主要命名空間使用，而且可能會在清除 AutoDeleteOnIdle 時刪除實體。

提示

若要在主動/主動設定中複寫佇列和主題訂用帳戶內容，並操作對應的命名空間，以應付中斷和災害，請勿依賴此異地災害復原功能集，而是遵循複寫指導。

中斷與災害

請務必注意「中斷」和「災害」之間的差異。

「中斷」是暫時無法使用 Azure 服務匯流排，而且會影響服務的某些元件，例如訊息存放區，或甚至整個資料中心。 不過，修正問題之後，服務匯流排就可再次使用。 中斷通常不會導致訊息或其他資料遺失。 這類中斷的範例可能是資料中心停電。 某些中斷只是因為暫時性或網路問題而造成的短暫連線中斷。

「災害」定義為永久或較長期遺失服務匯流排叢集、Azure 區域或資料中心。 區域或資料中心不一定能再次變成可用，也可能會關閉數小時或數天。 這類災害的範例包括火災、水災或地震。 會變成永久的災害可能會導致某些訊息、事件或其他資料遺失。 不過，在大部分情況下，應該不會遺失資料，而且在備份資料中心之後，就可以復原訊息。

Azure 服務匯流排的地理災害復原功能就是一個災害復原解決方案。 本文中所述的概念和工作流程適用於災害案例，不適用暫時性或暫時中斷。 如需 Microsoft Azure 中災害復原的詳細討論，請參閱本文。

基本概念與術語

災害復原功能會實作中繼資料災害復原，並依賴主要和次要災害復原命名空間。 異地災害復原功能僅適用於進階 SKU。 您不需要進行任何連接字串變更，因為連接是透過別名建立的。

本文中使用下列術語：

• 別名：所設定之災害復原設定的名稱。 別名提供單一穩定完整網域名稱 (FQDN) 連接字串。 應用程式會使用這個別名連接字串連接到命名空間。 使用別名可確保在觸發容錯移轉時，連接字串不會變更。

• 主要/次要命名空間：對應到別名的命名空間。 主要命名空間是「主動」，並且會接收訊息，其可以是現有或新的命名空間。 次要命名空間是「被動」，並不會接收訊息。 這兩者間的中繼資料會進行同步處理，因此，這兩者均能順暢地接受訊息，而不需進行任何應用程式程式碼或連接字串變更。 若要確保只有主動命名空間會接收訊息，您必須使用別名。

• 中繼資料：佇列、主題和訂用帳戶之類的實體，及其與命名空間關聯之服務的屬性。 只有實體及其設定會自動複寫。 不會複寫訊息。

• 容錯移轉：啟用次要命名空間的程序。

設定

下一節是設定命名空間之間配對的概觀。

首先建立或使用現有的主要命名空間，以及新的次要命名空間，然後將這兩個命名空間配對。 此配對會為您提供可用來連接的別名。 由於您使用別名，因此不需變更連接字串。 只需將新的命名空間新增至您的容錯移轉配對。

1. 建立主要進階層命名空間。

2. 在不同區域中建立次要進階層命名空間。 此步驟是選擇性的。 您可以在下一個步驟中建立配對時建立次要命名空間。

3. 在 Azure 入口網站中，瀏覽至您的主要命名空間。

4. 在左側功能表上選取 [異地復原]，然後選取工具列上的 [起始配對]。

   

5. 在 [起始配對] 頁面上，請遵循下列步驟：

   1. 選取現有的次要命名空間，或在不同區域建立次要命名空間。 在此範例中，會將現有命名空間當作次要命名空間。

   2. 針對 [別名]，輸入異地災害復原配對的別名。

   3. 然後，選取 [建立]。

      

6. 您應該會看到 [服務匯流排異地災害復原別名] 頁面，如下圖所示。 您也可以在左側功能表上選取 [異地復原]，從主要命名空間頁面瀏覽至 [異地災害復原別名] 頁面。

   

7. 在 [異地災害復原別名] 頁面上，選取左側功能表上的 [共用存取原則]，以存取別名的主要連接字串。 請使用此連接字串，不要直接使用主要/次要命名空間的連接字串。 一開始，此別名會指向主要命名空間。

8. 切換至 [概觀] 頁面。 您可以執行下列動作：

   1. 中斷主要和次要命名空間之間的配對。 選取工具列上的 [中斷配對]。
   2. 手動容錯移轉至次要命名空間。

      1. 選取工具列上的 [容錯移轉]。

      2. 輸入別名，確認您想要容錯移轉至次要命名空間。

      3. 開啟 [安全容錯移轉] 選項，安全地容錯移轉至次要命名空間。

         注意

         • 安全容錯移轉可確保在切換至次要命名空間之前，完成擱置的異地災害復原複寫。 強制或手動容錯移轉則不會等待擱置複寫完成，然後再切換至次要命名空間。
         • 目前，如果主要和次要命名空間不在相同的 Azure 訂用帳戶中，則安全容錯移轉會失敗。

      4. 接著選取 [容錯移轉]。

         

         重要

         容錯移轉會啟動次要命名空間，並從異地災害復原配對中移除主要命名空間。 建立另一個命名空間，以產生新的異地災害復原配對。

9. 最後，您應該新增某些監視來偵測是否需要容錯移轉。 在大部分情況下，服務是大型生態系統的一部分，因此不太可能自動容錯移轉，容錯移轉通常都必須與其餘子系統或基礎結構同步執行。

服務匯流排標準版升級至進階版

如果您已將 Azure 服務匯流排標準命名空間移轉至 Azure 服務匯流排進階，則必須使用預先存在的別名 (也就是您的服務匯流排標準命名空間連接字串)，透過 PS/CLI 或 REST API 建立災害復原設定。

這是因為在移轉期間，Azure 服務匯流排標準命名空間連接字串/DNS 名稱本身會變成 Azure 服務匯流排進階命名空間的別名。

您的用戶端應用程式必須利用此別名 (也就是 Azure 服務匯流排標準命名空間連接字串)，來連線到已設定災害復原配對的進階命名空間。

如果您使用 Azure 入口網站來設定災害復原設定，則入口網站將會從您那裡摘錄此警告。

容錯移轉流程

容錯移轉會由客戶手動觸發 (明確地透過命令來觸發，或透過用戶端所擁有會觸發該命令的商務邏輯來觸發)，而一律不會由 Azure 觸發。 這會賦予客戶完整的所有權和可見性，以解決 Azure 骨幹上發生的中斷情況。

觸發容錯移轉之後 -

1. 別名連接字串會更新成指向次要進階命名空間。

2. 用戶端 (傳送者和接收者) 會自動連線到「次要」命名空間。

3. 「主要」與「次要」進階命名空間之間的現有配對已中斷。

一旦起始容錯移轉 -

1. 如果發生另一個中斷，您會希望能夠再次進行容錯移轉。 因此，請設定另一個被動命名空間，並更新配對。

2. 一旦主要命名空間再次可供使用之後，從先前的主要命名空間提取訊息。 然後，針對地理復原設定以外的一般訊息使用該命名空間，或者刪除舊的主要命名空間。

注意

僅支援失敗轉接語意。 在此案例中，您容錯移轉然後與新的命名空間重新配對。 不支援容錯復原；例如，在 SQL 叢集。

您可以使用監視系統或使用自訂監視解決方案來自動容錯移轉。 不過，這類自動化會採用額外的計劃和工作，這部分不在本文的範圍內。

管理

如果您發生錯誤，例如，您在初始化安裝期間配對錯誤的區域，您可以隨時中斷兩個命名空間的配對。 如果您想要使用配對的命名空間作為一般命名空間，請刪除別名。

使用現有命名空間作為別名

如果在您的情節中無法變更生產者與取用者的連線，則您可重複使用命名空間名稱當作別名名稱。 請參閱這裡的 GitHub 範例程式碼 \(英文\)。

範例

GitHub 上的範例示範如何設定及初始化容錯移轉。 這些範例示範下列概念：

• 在 Microsoft Entra ID 中使用 Azure Resource Manager 搭配服務匯流排，以設定和啟用異地災害復原所需的 .NET 範例和設定。
• 執行範例程式碼所需的步驟。
• 如何使用現有命名空間作為別名。
• 另外透過 PowerShell 或 CLI 啟用地理災害復原的步驟。
• 使用別名從目前的主要或次要命名空間傳送和接收。

考量

請注意此版本的下列考量：

• 在您的容錯移轉規劃中，您也應該考慮時間因素。 例如，如果您中斷連線時間超過 15 到 20 分鐘，您可能會決定初始化容錯移轉。
• 未複寫任何資料這個事實表示未複寫目前作用中工作階段。 此外，重複的偵測和排程訊息可能無法運作。 新的工作階段、新的排程訊息及新的重複項目可以運作。
• 容錯移轉複雜分散式基礎結構應該至少演練一次。
• 同步處理實體可能需要一些時間，大約每分鐘 50-100 個實體。 訂用帳戶和規則也算是實體。

可用性區域

服務匯流排進階 SKU 支援可用性區域，可在 Azure 區域內提供錯誤隔離位置。 服務匯流排管理三個傳訊存放區複本 (1 個主要和 2 個次要)。 服務匯流排會針對資料和管理作業，將三個複本都保持同步。 如果主要複本失敗，其中一個次要複本會升階為主要複本，不會察覺到停機。 如果應用程式看到暫時性與服務匯流排中斷連線，SDK 中的重試邏輯會自動重新連線至服務匯流排。

使用可用性區域時，中繼資料和資料 (訊息) 都會複寫至可用性區域中的資料中心。

注意

「Azure 服務匯流排進階層」的「可用性區域」支援僅適用於有可用性區域存在的 Azure 區域。

透過入口網站建立進階層命名空間時，會自動為命名空間啟用可用性區域的支援 (如果在選取的區域中可用的話)。 透過其他機制 (例如 ARM/Bicep 範本、CLI 或 PowerShell) 建立進階層命名空間時，屬性 zoneRedundant 必須明確設定為 true，才能啟用可用性區域（如果在選取的區域中可用的話）。 使用這項功能沒有額外成本，而且您無法在建立命名空間之後停用或啟用此功能。

私人端點

關於異地災害復原與使用私人端點的命名空間一起使用，本節提供其他考量。 若要了解通常如何使用私人端點搭配服務匯流排，請參閱整合 Azure 服務匯流排與 Azure 私人連結。

新配對

如果您嘗試在具有私人端點的主要命名空間與沒有私人端點的次要命名空間之間建立配對，配對會失敗。 只有當主要和次要命名空間都具有私人端點時，配對才會成功。 建議您在主要和次要命名空間，以及在建立私人端點的所在虛擬網路上使用相同的設定。

注意

當您嘗試將具有私人端點的主要命名空間和次要命名空間配對時，驗證程序只會檢查次要命名空間上是否存在私人端點。 不會檢查端點是否正常運作，或在容錯移轉之後是否可運作。 您必須負責確保具有私人端點的次要命名空間在容錯移轉之後能如預期般運作。

若要測試私人端點組態是否相同，請從虛擬網路外部將取得佇列要求傳送至次要命名空間，並確認您收到來自服務的錯誤訊息。

現有配對

如果主要和次要命名空間之間的配對已存在，在主要命名空間上的私人端點建立會失敗。 若要解決此問題，請先在次要命名空間上建立私人端點，然後再為主要命名空間建立私人端點。

注意

我們允許對次要命名空間唯讀存取，也允許更新私人端點設定。

建議組態

建立應用程式和服務匯流排的災害復原組態時，您必須針對裝載您應用程式主要和次要執行個體的虛擬網路，建立主要和次要服務匯流排命名空間的私人端點。

假設您有兩個虛擬網路：VNET-1、VNET-2 和這些主要和次要命名空間： ServiceBus-Namespace1-Primary、 ServiceBus-Namespace2-Secondary。 您需要執行下列步驟：

• 在 ServiceBus-Namespace1-Primary 上，建立兩個私人端點，使用來自 VNET-1 和 VNET-2 的子網路
• 在 ServiceBus-Namespace2-Secondary 上，建立兩個私人端點，使用來自 VNET-1 和 VNET-2 的相同子網路

這種方法的優點是，容錯移轉可能會發生在與服務匯流排命名空間無關的應用程式層。 請考量下列案例：

僅限應用程式容錯移轉：這裡，應用程式不存在於 VNET-1 中，但會移至 VNET-2。 由於在主要和次要命名空間的 VNET-1 和 VNET-2 上都設定了這兩個私人端點，應用程式會正常運作。

僅限服務匯流排命名空間容錯移轉同樣地，此案例中由於在主要和次要命名空間的虛擬網路上都設定了這兩個私人端點，應用程式會正常運作。

注意

如需虛擬網路的異地災害復原指引，請參閱虛擬網路 - 商務持續性。

角色型存取控制

對主要命名空間中服務匯流排實體的 Microsoft Entra 角色型存取控制 (RBAC) 指派，不會複寫至次要命名空間。 在次要命名空間中手動建立角色指派，以安全存取這些實體。

下一步

• 請參閱地理災害復原在這裡的 REST API 參考。
• 執行地理災害復原在 GitHub 上的範例 \(英文\)。
• 請參閱地理災害復原範例以將訊息傳送至別名 \(英文\)。

若要深入了解服務匯流排傳訊，請參閱下列文章：

• 服務匯流排佇列、主題和訂用帳戶
• 開始使用服務匯流排佇列
• 如何使用服務匯流排主題和訂用帳戶
• REST API