共用方式為

Azure 通訊閘道的可靠性

  • 發行項

Azure 通訊閘道使用 Azure 備援機制和 SIP 特定的重試行為，確保您的服務可靠。 您的網路必須符合特定需求，以確保服務可用性。

Azure 通訊閘道的備援模型

生產 Azure 通訊閘道部署（也稱為標準部署）包含三個不同的區域：管理區域和兩個服務區域。 實驗室部署包含一個管理區域和一個服務區域。

本文說明兩個不同的區域類型及其相異的備援模型。 它涵蓋可用性區域的區域可靠性，以及災害復原的跨區域可靠性。 如需更多關於 Azure 可靠性的詳細概觀，請參閱 Azure 可靠性。

兩個服務區域、管理區域和兩個操作員月臺的圖表。

服務區域

服務區域包含用來處理網路與所選通訊服務之間之流量的語音和 API 基礎結構。

生產 Azure 通訊閘道部署有兩個服務區域，部署在主動-主動模式中（如 電信業者連線 和 Teams 電話行動程式所需）。 服務區域之間的快速容錯移轉是在基礎結構/IP 層級和應用程式 (SIP/RTP/HTTP) 層級提供。

服務區域也包含 Azure 通訊閘道的佈建 API 基礎結構。

提示

生產部署必須一律有兩個服務區域，即使選擇的其中一個服務區域位於單一區域的 Azure 地理位置（例如卡達）。 如果您選擇單一區域 Azure 地理位置，請在不同的 Azure 地理位置中選擇第二個 Azure 區域。

服務區域在作業中完全相同，並提供區域和區域失敗的復原能力。 每個服務區域都可以使用 Azure 通訊閘道執行個體承載 100% 的流量。 因此，終端使用者仍應該能夠在任何區域或區域停機期間成功撥打和接聽電話。

實驗室部署有一個服務區域。

呼叫路由需求

Azure 通訊閘道提供「成功重撥」備援模型: 終止由失敗的同儕節點處理的呼叫，但將新的呼叫路由傳送至良好的同儕節點。 此模型會鏡像 Microsoft Teams 所提供的備援模型。

針對生產環境部署，我們預期您的網路會有兩個異地備援月臺。 每個網站都應該與 Azure 通訊閘道區域配對。 備援模型仰賴網路與 Azure 通訊閘道服務區域之間的交叉連線能力。

兩個操作員網站和兩個服務區域的圖表。這兩個服務區域都會連線到兩個月臺，並具有主要和次要路由。

實驗室部署必須連線到您網路中一個月臺。

每個 Azure 通訊閘道服務區域都會提供 SRV 記錄。 此記錄包含所有 SIP 同儕節點，提供區域內 SBC 功能 (用於將呼叫路由傳送至通訊服務)。 此 SRV 記錄可以指向上線小組提供給您 /28 IP 範圍中的任何 IP 位址。

如果您的 Azure 通訊閘道包含行動控制點 (MCP)，則每個服務區域都會為 MCP 提供額外的 SRV 記錄。 每個區域的 MCP 記錄都包含優先順序最高的區域內的 MCP，以及優先順序較低的另一個區域中的 MCP。

在您網路中的每個網站都必須:

  • 根據預設，將流量傳送至其本機 Azure 通訊閘道服務區域。
  • 使用 DNS SRV 找出區域內的 Azure 通訊閘道同儕節點，如 RFC 3263 中所述。
    • 使用 _sip._tls.<regional-FQDN-from-portal>，對服務區域連線到您網路的域名進行 DNS SRV 查閱。 將 取代<regional-FQDN-from-portal>為 Azure 入口網站 中資源 [概觀] 頁面上 [主機名] 字段中每個區域的 FQDN。 例如，如果您的部署使用 commsgw.azure.com 功能變數名稱，請查閱 _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com 第一個區域。
    • 如果 SRV 查閱傳回多個目標，請使用每個目標的權數和優先順序來選取單一目標。
  • 將新的呼叫傳送至可用的 Azure 通訊閘道同儕節點。
  • 能夠接收與 Azure 通訊閘道相關聯之每個 IP 範圍中任何 IP 位址的流量。

當您的網路將呼叫路由至適用於 SBC 函式的 Azure 通訊閘道的 SIP 同儕節點時，它必須:

  • 使用 SIP OPTIONS (或 OPTIONS 和 SIP 流量的組合) 來監視 Azure 通訊閘道 SIP 同儕節點的可用性。
  • 重試收到 408 回應、503 回應或 504 回應或未收到回應的 INVITE，方法是將回應重新路由至本機網站中的其他可用同儕節點。 只有當本機服務區域中的所有同儕節點都失敗時，才去搜尋其他服務區域 (由其他區域的 SRV 記錄所定義)。
  • 永不重試收到 408、503 和 504 以外的錯誤回應的呼叫。

如果您的 Azure 通訊閘道部署包含整合式行動控制點 (MCP)，您的網路必須為 MCP 執行如下動作:

  • 偵測區域中的 MCP 何時無法使用、將該區域 SRV 記錄的目標標記為無法使用，並定期重試以判斷區域何時可再次使用。 MCP 不會回應 SIP OPTIONS。
  • 根據您的組織原則處理 MCP 的 5xx 回應。 例如，您可以重試要求，或者您可以允許呼叫繼續，而不需通過 Azure 通訊閘道並傳入 Microsoft 電話系統。

此路由行為的詳細資料專屬於您的網路。 您必須在整合專案期間與您的上線小組達成一致。

管理區域

管理區域包含用於 Azure 通訊閘道的訂購、監視和計費基礎結構。 這些區域內的所有基礎結構都會以區域性備援的方式部署，這表示所有資料都會自動複寫到區域內的每個可用性區域。 所有重要的設定資料也會複寫到每個服務區域，以確保 Azure 區域失敗期間服務正常運作。

可用性區域支援

可用性區域是每個 Azure 區域內的數據中心實體分隔群組。 當某個區域失敗時，服務可以故障轉移至其中一個其餘區域。

如需 Azure 中可用性區域的詳細資訊，請參閱 什麼是可用性區域？。

服務區域的區域關閉體驗

在全區域中斷期間，受影響區域處理的呼叫將被終止，且在服務的自我修復將基礎資源重新平衡到良好區域之前，區域內的容量會短暫遺失。 這種自我修復不依賴區域復原; 它是依賴 Microsoft 管理的服務自我修復狀態，使用其他區域的容量來補償遺失的區域。 承載資源的流量會以區域備援方式部署，但最低規模的流量可能由單一資源處理。 在此案例中，本文所述的容錯移轉機制會將所有流量重新平衡至其他服務區域，而承載流量的資源則會重新部署至良好區域。

管理區域的區域關閉體驗

在全區域中斷期間，不需在區域復原期間採取任何動作。 管理區域會自我修復並重新平衡以自動利用良好區域。

災害復原: 後援至其他區域

災害復原 (DR) 是指從重大影響事件中復原，例如自然災害或失敗的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。 開始思考建立災害復原方案之前，請參閱設計災害復原策略的建議。

Microsoft 在災害復原方面採取共同責任模型。 在共同責任模型中，Microsoft 確保基準基礎結構和平台服務可供使用。 此時，許多 Azure 服務不會自動複寫資料，或從失敗區域回復為交叉複寫到另一個已啟用的區域。 針對這些服務，您必須負責設定適用於您工作負載的災害復原計劃。 大多數在 Azure 平台即服務 (PaaS) 供應項目執行的服務，皆提供支援災害復原的功能和指導，您可以使用支援快速復原的特定服務功能來開發災害復原方案。

本節說明在全區域中斷期間 Azure 通訊閘道的行為。

災害復原: 服務區域的跨區域容錯移轉

在全區域中斷期間，本文中所述的容錯移轉機制 (OPTIONS 輪詢和 SIP 對失敗重試) 會將所有呼叫流量重新平衡至其他服務區域，以維持可用性。 我們將開始還原區域備援。 在延長停機期間，還原區域備援可能需要使用其他 Azure 區域。 如果需要將失敗的區域移轉至另一個區域，我們會在開始任何移轉之前向您諮詢。

Azure 通訊閘道中的 SBC 函式會提供 OPTIONS 輪詢，讓您的網路判斷同儕節點可用性。 針對 MCP，您的網路必須能夠偵測 MCP 何時無法使用，並定期重試以判斷 MCP 何時再次可用。 MCP 不會回應 SIP OPTIONS。

佈建 API 用戶端使用部署的基礎網域名稱來連絡 Azure 通訊閘道。 此網域的 DNS 記錄具有 60 秒的存留時間 (TTL)。 當一個區域失敗時，Azure 會更新 DNS 記錄以參考另一個區域，因此進行新 DNS 查閱的用戶端會收到新區域的詳細資料。 建議確保用戶端可以在逾時或 5xx 回應之後，於 60 秒後進行新的 DNS 查閱，並重試要求。

提示

實驗室部署不提供跨區域故障轉移（因為它們只有一個服務區域）。

災害復原: 管理區域的跨區域容錯移轉

透過號碼管理入口網站進行的語音流量和佈建，不會受到管理區域中失敗的影響，因為對應的 Azure 資源裝載於服務區域中。 號碼管理入口網站的使用者可能需要再次登入。

監視服務可能暫時無法使用，直到服務還原為止。 如果管理區域遇到延長停機狀況，我們會將受影響的資源移轉至另一個可用的區域。

選擇管理和服務區域

Azure 通訊閘道的單一部署旨在處理一個地理區域內的流量。 在相同地理區域內的生產部署中部署這兩個服務區域（例如 北美洲）。 此模型確保語音電話的延遲會維持在操作員連線和 Teams 電話行動版程式所要求的限制內。

當您選擇服務區域位置時，請考慮下列幾點:

  • 從可用的 Azure 區域清單中選取。 您可以在 [產品依區域別] 頁面上看到可選取為服務區域的 Azure 區域。
  • 選擇靠近您自己內部部署的區域，以及在網路與 Microsoft 之間的同儕節點位置，以減少呼叫延遲。
  • 建議使用區域配對，以在發生多區域中斷時，將復原時間降到最低。

從下列清單中選擇管理區域:

  • 美國東部
  • 美國中西部
  • 西歐
  • 英國南部
  • 印度中部
  • 加拿大中部
  • 澳大利亞東部

管理區域可以與服務區域共置。 我們建議選擇最接近您服務區域的管理區域。

服務等級協定

本文件中所述的可靠性設計是由 Microsoft 執行，無法設定。 如需深入了解 Azure 通訊閘道服務等級協定 (SLA)，請參閱 Azure 通訊閘道 SLA。

下一步