Azure Communications Gateway の信頼性

Azure Communications Gateway は、Azure 冗長メカニズムと SIP 固有の再試行動作を使用して、サービスの信頼性を確保します。 サービスの可用性を確保するには、ネットワークが特定の要件を満たしている必要があります。

Azure Communications Gateway の冗長性モデル

運用 Azure Communications Gateway のデプロイ (標準デプロイとも呼ばれます) は、 管理リージョン と 2 つのサービス リージョンという 3 つの異なるリージョンで構成 されます。 ラボのデプロイは、1 つの管理リージョンと 1 つのサービス リージョンで構成されます。

この記事では、2 つの異なるリージョンの種類とその個別の冗長性モデルについて説明します。 可用性ゾーンを使用したリージョンの信頼性と、ディザスター リカバリーによるリージョン間の信頼性の両方について説明します。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。

サービス リージョン

サービス リージョンには、ネットワークと選択した通信サービスの間のトラフィックを処理するために使用される音声および API インフラストラクチャが含まれています。

運用環境の Azure Communications Gateway のデプロイには、アクティブ/アクティブ モードでデプロイされる 2 つのサービス リージョンがあります (オペレーター接続プログラムと Teams Phone Mobile プログラムで必要に応じて)。 サービス リージョン間の高速フェールオーバーは、インフラストラクチャ/IP レベルとアプリケーション (SIP/RTP/HTTP) レベルで提供されます。

サービス リージョンには、Azure Communications Gateway の プロビジョニング API のインフラストラクチャも含まれています。

サービス リージョンは動作中に同一であり、ゾーンとリージョンの両方の障害に対する回復性を提供します。 各サービス リージョンは、Azure Communications Gateway インスタンスを使用して 100% のトラフィックを伝送できます。 そのため、エンド ユーザーは、ゾーンまたは地域のダウンタイム中に通話を正常に行って受信できる必要があります。

ラボのデプロイには、1 つのサービス リージョンがあります。

通話ルーティングの要件

Azure Communications Gateway には、"成功した再ダイヤル" 冗長性モデルが用意されています。失敗したピアによって処理される呼び出しは終了しますが、新しい呼び出しは正常なピアにルーティングされます。 このモデルは、Microsoft Teamsによって提供される冗長性モデルを反映します。

運用環境のデプロイでは、ネットワークに 2 つの地理的冗長サイトが必要です。 各サイトは、Azure Communications Gateway リージョンとペアにする必要があります。 冗長性モデルは、ネットワークと Azure Communications Gateway サービス リージョン間のクロス接続に依存します。

ラボのデプロイは、ネットワーク内の 1 つのサイトに接続する必要があります。

各 Azure Communications Gateway サービス リージョンは、SRV レコードを提供します。 このレコードには、リージョン内の (通信サービスへの呼び出しをルーティングするための) SBC 機能を提供するすべての SIP ピアが含まれています。 この SRV レコードは、オンボード チームによって提供される /28 IP 範囲の任意の IP アドレスを指すことができます。

Azure Communications Gateway にモバイル コントロール ポイント (MCP) が含まれている場合、各サービス リージョンは MCP 用に追加の SRV レコードを提供します。 各リージョンごとの MCP レコードには、最も優先度の高いリージョン内の MCP と、優先順位の低い他のリージョンの MCP が含まれます。

ネットワーク内の各サイトでは、次の手順を実行する必要があります。

ネットワークが SBC 機能のために Azure Communications Gateway の SIP ピアに呼び出しをルーティングする場合は、次の手順を実行する必要があります。

Azure Communications Gateway のデプロイに統合されたモバイル コントロール ポイント (MCP) が含まれている場合、ネットワークは MCP に対して次のように行う必要があります。

このルーティング動作の詳細は、ネットワークに固有です。 統合プロジェクト中にオンボーディングチームとそれらを合意する必要があります。

管理リージョン

管理リージョンには、Azure Communications Gateway の順序付け、監視、および課金に使用されるインフラストラクチャが含まれています。 これらのリージョン内のすべてのインフラストラクチャは、ゾーン冗長な方法でデプロイされます。つまり、すべてのデータがリージョン内の各可用性ゾーンに自動的にレプリケートされます。 すべての重要な構成データは、Azure リージョンの障害発生時にサービスが適切に機能するように、各サービス リージョンにもレプリケートされます。

可用性ゾーンのサポート

可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

サービス リージョンのゾーン ダウン エクスペリエンス

ゾーン全体の停止中、影響を受けるゾーンによって処理された呼び出しは終了され、サービスの自己復旧によって基になるリソースが正常なゾーンに再調整されるまで、リージョン内の容量が短時間失われます。 この自己修復はゾーンの復元には依存しません。Microsoft が管理するサービスの自己復旧状態は、他のゾーンの容量を使用して、失われたゾーンを補正することが期待されます。 リソースを運ぶトラフィックはゾーン冗長方式でデプロイされますが、最もスケールの低いトラフィックは 1 つのリソースによって処理される可能性があります。 この場合、この記事で説明するフェールオーバー メカニズムは、トラフィックを運ぶリソースが正常なゾーンに再デプロイされている間に、他のサービス リージョンへのすべてのトラフィックを再調整します。

管理リージョンのゾーンダウン エクスペリエンス

ゾーン全体が停止している場合のゾーン復旧中に、必要なアクションはありません。 管理リージョンは、正常なゾーンを自動的に利用するために自己修復と再調整を行います。

ディザスター リカバリー: 他のリージョンへのフォールバック

ディザスター リカバリー (DR) とは、自然災害やデプロイの失敗など、ダウンタイムやデータ損失につながる影響の大きいイベントから組織が復旧するために使用するプラクティスを指します。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を開始する前に、 ディザスター リカバリー戦略の設計に関する推奨事項を参照してください。

DR の場合、Microsoft は 共有責任モデルを使用します。 このモデルでは、Microsoft はベースライン インフラストラクチャとプラットフォーム サービスを確実に利用できるようにします。 ただし、多くの Azure サービスでは、データが自動的にレプリケートされたり、障害が発生したリージョンから別の有効なリージョンにクロスレプリケートされたりすることはありません。 それらのサービスに対して、ワークロードに適したディザスター リカバリー計画を設定する責任はユーザーにあります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されています。 サービス固有の機能を使用して高速復旧をサポートし、DR プランの開発に役立ちます。

このセクションでは、リージョン全体の停止中の Azure Communications Gateway の動作について説明します。

ディザスター リカバリー: サービス リージョンのリージョン間フェールオーバー

リージョン全体の停止中に、この記事で説明されているフェールオーバー メカニズム (OPTIONS ポーリングと障害時の SIP 再試行) によって、他のサービス リージョンへのすべての呼び出しトラフィックが再調整され、可用性が維持されます。 リージョン冗長の回復を開始します。 延長ダウンタイム中にリージョン冗長を復元するには、他の Azure リージョンを使用する必要がある場合があります。 障害が発生したリージョンを別のリージョンに移行する必要がある場合は、移行を開始する前に相談します。

Azure Communications Gateway の SBC 関数は、ネットワークがピアの可用性を判断できるようにするための OPTIONS ポーリングを提供します。 MCP の場合、ネットワークは MCP が使用できないタイミングを検出し、定期的に再試行して MCP が再び使用可能かどうかを判断できる必要があります。 MCP は SIP オプションに応答しません。

プロビジョニング API クライアントは、デプロイのベース ドメイン名を使用して Azure Communications Gateway に接続します。 このドメインの DNS レコードの有効期間 (TTL) は 60 秒です。 リージョンが失敗すると、Azure は DNS レコードを更新して別のリージョンを参照するため、新しい DNS 参照を行うクライアントは新しいリージョンの詳細を受け取ります。 クライアントが新しい DNS 参照を行い、タイムアウトまたは 5xx 応答の 60 秒後に要求を再試行できるようにすることをお勧めします。

ディザスター リカバリー: 管理リージョンのリージョン間フェールオーバー

番号管理ポータルを介した音声トラフィックとプロビジョニングは、対応する Azure リソースがサービス リージョンでホストされているため、管理リージョンでの障害の影響を受けません。 数値管理ポータルのユーザーは、もう一度サインインする必要がある場合があります。

監視サービスは、サービスが復元されるまで一時的に使用できない場合があります。 管理リージョンで長時間のダウンタイムが発生した場合は、影響を受けるリソースを別の利用可能なリージョンに移行します。

管理リージョンとサービス リージョンの選択

Azure Communications Gateway の単一のデプロイは、地理的領域内のトラフィックを処理するように設計されています。 両方のサービス リージョンを同じ地理的領域内の運用デプロイにデプロイします (北米など)。 このモデルにより、音声通話の待機時間が、オペレーター接続プログラムと Teams Phone Mobile プログラムで必要な制限内に留まるようにします。

サービス リージョンの場所を選択するときは、次の点を考慮してください。

• 使用可能な Azure リージョンの一覧から選択します。 サービス リージョンとして選択できる Azure リージョンは、[ リージョン別の製品 ] ページで確認できます。
• 通話の待ち時間を短縮するために、独自のオンプレミスに近いリージョンと、ネットワークと Microsoft の間のピアリングの場所を選択します。
• 複数 リージョンの停止が 発生した場合の復旧時間を最小限に抑えるには、リージョン ペアを使用します。

次の一覧から管理リージョンを選択します。

• 米国東部
• 米国中西部
• 西ヨーロッパ
• 英国南部
• インド中部
• カナダ中部
• オーストラリア東部

管理リージョンは、サービス リージョンと併置できます。 サービス リージョンに最も近い管理リージョンを選択することをお勧めします。

サービス レベル アグリーメント

このドキュメントで説明する信頼性設計は Microsoft によって実装されており、構成できません。 Azure Communications Gateway サービス レベル アグリーメント (SLA) の詳細については、 Azure Communications Gateway の SLA を参照してください。

次のステップ

• Azure Communications Gateway をネットワークに接続する方法について説明します
• Azure Communications Gateway がネットワークとデータをセキュリティで保護する方法について説明します
• Azure Communications Gateway のデプロイの計画の詳細を確認する