Azure Private 5G Core の信頼性
この記事では、Azure Private 5G Core での信頼性のサポートについて説明します。 可用性ゾーンと、リージョン間のディザスター リカバリーおよび事業継続による両方のリージョンの回復性について扱います。 Azure における信頼性の概要については、Azure の信頼性に関するページを参照してください。
Azure Stack Edge (ASE) デバイスのペアに高可用性 (HA) サービスとして Azure Private 5G Core をデプロイすることもできます。 詳細については、「プライベート モバイル ネットワークをデプロイするために前提となるタスクを完了する」を参照してください。
可用性ゾーンのサポート
Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。
障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。
Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。
「可用性ゾーン サービスとリージョンのサポート」に記載されているとおり、Azure Private 5G Core サービスは、可用性ゾーンをサポートする Azure リージョンで、ゾーン冗長として自動的にデプロイされます。 リージョンで可用性ゾーンがサポートされている場合は、リージョン内に作成されたすべての Azure Private 5G Core リソースを、任意の可用性ゾーンから管理できます。
可用性ゾーンを構成または管理するために、さらに必要な作業はありません。 可用性ゾーン間のフェールオーバーは自動的に行われます。
前提条件
Azure Private 5G Core が利用可能な Azure リージョンについては、「リージョン別の利用可能な製品」を参照してください。
ゾーン ダウン エクスペリエンス
ゾーン全体の停止シナリオでは、サービスが正常なゾーンを利用できるように自動的に移行されるため、ユーザーに影響はありません。 ゾーン全体が停止する場合、その開始時に、進行中の ARM 要求がタイムアウトまたは失敗する可能性があります。 新しい要求は正常なノードに送信されるようになり、ユーザーに影響はありません。失敗した操作があれば、再試行する必要があります。 引き続き、停止中に新しいリソースを作成したり、既存のリソースを更新、監視、管理したりすることができます。
安全なデプロイ手法
アプリケーションは、リージョン内の可用性ゾーン間ですべてのクラウド状態が確実にレプリケートされるため、すべての管理操作が中断することなく続行されます。 パケット コアは Edge で実行されており、ゾーン障害の影響を受けないので、ユーザーにサービスを提供し続けます。
リージョン間のディザスター リカバリーおよび事業継続
ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。
DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。
Azure Private 5G Core は、複数リージョン (3+N) の地域でのみ使用できます。 サービスは、同じ地域のバックアップ リージョンに SIM 資格情報を自動的にレプリケートします。 つまり、リージョンの障害が発生した場合にデータは失われません。 障害が発生してから 4 時間以内に、障害が発生したリージョン内のすべてのリソースを Azure portal と ARM ツールで表示できますが、障害が発生したリージョンが復旧されるまで読み取り専用になります。 Edge で実行されているパケット コアは中断することなく動作し続け、ネットワーク接続は維持されます。
Microsoft は、Azure Private 5G Core サービスの Azure クラウド側での停止検出、通知、サポートを担当します。
停止の検出、通知、管理
Microsoft は、各リージョンで Azure Private 5G Core サービスを提供する基になるリソースを監視します。 これらのリソースに、単一の可用性ゾーンに制限されていない障害アラートまたは稼働状況の監視アラートが表示され始めた場合、Microsoft はサービスを同じ地域のサポートされている別のリージョンに移動します。 これは、アクティブ/アクティブのパターンです。 特定のリージョンのサービス正常性は、Azure Service Health で確認できます (Azure Private 5G Core は [ネットワーク] セクションに記載されています)。 通常の Azure 通信チャネルを通じて、リージョンの障害が通知されます。
サービスは Cosmos DB マルチリージョン書き込みを利用して、サービスが所有する SIM 資格情報をバックアップ リージョンに自動的にレプリケートするため、リージョンの障害が発生した場合でもデータが失われません。
失敗したリージョンにデプロイされた Azure Private 5G Core リソースは読み取り専用になりますが、他のすべてのリージョンのリソースは引き続き影響を受けません。 リソースを常に書き込めるようにしておく必要がある場合は、「ディザスター リカバリーと障害検出を設定する」の手順に従って、独自のディザスター リカバリー操作を実行し、別のリージョンでサービスを設定します。
Edge で実行されているパケット コアは中断することなく動作し続け、ネットワーク接続は維持されます。
ディザスター リカバリーと障害検出を設定する
このセクションでは、リージョンに障害が発生した場合に、Azure Private 5G Core サービスの完全にアクティブな管理プレーンを確保するために実行できるアクションについて説明します。 これは、リージョンの障害発生時にリソースを変更できるようにする場合に必要です。
これにより、パケット コア サービスが停止し、最大 8 時間、UE へのネットワーク接続が中断されるため、この手順は、Azure リージョンがダウンしている間にリソースを管理するビジネスクリティカルな理由がある場合にのみ使用することをお勧めします。
ディザスター リカバリー イベントの前に、Azure Private 5G Core をサポートする別のリージョンにリソース構成をバックアップする必要があります。 リージョンの障害が発生した場合は、バックアップ リージョンのリソースを使用してパケット コアを再デプロイできます。
準備
ディザスター リカバリーのためにバックアップする必要がある Azure Private 5G Core 構成データには、モバイル ネットワーク構成と SIM 資格情報の 2 種類があります。 推奨事項は次のとおりです。
- プライマリ リージョンに新しい SIM を追加するたびに、バックアップ リージョンの SIM 資格情報を更新する
- モバイル ネットワーク構成を 1 週間に 1 回以上バックアップする。新しいサイトの作成など、構成に頻繁または大規模な変更を加える場合は、より頻繁にバックアップしてください。
モバイル ネットワーク構成
リソースを別のリージョンに移動する方法に関するページにある手順に従って、Azure Private 5G Core リソース構成をエクスポートし、新しいリージョンにアップロードします。 バックアップ構成には新しいリソース グループを使用して、アクティブな構成から明確に分離することをお勧めします。 プライマリ リージョン内のリソースと区別するために、リソースに新しい名前を付ける必要があります。 この新しいリージョンはパッシブ バックアップであるため、競合を回避するために、パケット コア構成をエッジ ハードウェアにまだリンクしないでください。 代わりに、すべてのパケット コアの packetCoreControlPlanes.platform フィールドの値を、回復手順を実行するユーザーがアクセスできる安全な場所 (内部ドキュメントで参照されているストレージ アカウントなど) に格納します。
SIM データ
セキュリティ上の理由から、Azure Private 5G Core では、SIM 作成の一環としてサービスに提供される SIM 資格情報は返されません。 そのため、他の Azure リソースと同じ方法で SIM 構成をエクスポートすることはできません。 新しい SIM がプライマリ サービスに追加されるたびに、バックアップ モバイル ネットワークに対して新しい SIM のプロビジョニング プロセスを繰り返すことで、同じ SIM もバックアップ サービスに追加されるようにすることをお勧めします。
その他のリソース
Azure Private 5G Core デプロイでは、SIM 暗号化キーまたはローカル監視用の HTTPS 証明書を格納するために、Azure Key Vault を使用する場合があります。 キーと証明書がバックアップ リージョンで使用できることを確認するには、Azure Key Vault のドキュメントに従う必要があります。
Recovery
リージョンに障害が発生した場合は、まず、Azure portal または API を使用して構成に対してクエリを実行して、バックアップ リージョン内のすべてのリソースが存在することを検証します (ソースを別のリージョンに移動する方法に関するページを参照してください)。 すべてのリソースが存在していない場合は、ここで停止し、この手順の残りの部分は実行しないでください。 リソース構成がないと、エッジ サイトでサービスを復旧できない場合があります。
回復プロセスは、パケット コアごとに次の 3 つのステージに分割されます。
- リセットを実行して、障害が発生したリージョンから Azure Stack Edge デバイスを切断します。
- Azure Stack Edge デバイスをバックアップ リージョンに接続します。
- 再インストールしてインストールを検証します。
モバイル ネットワーク内のすべてのパケット コアに対して、このプロセスを繰り返す必要があります。
注意事項
復旧手順により、パケット コア サービスが停止し、パケット コアごとに最大 8 時間、UE へのネットワーク接続が中断されます。 この手順は、リージョンの障害時に Azure を介して Azure Private 5G Core デプロイを管理するといった、ビジネスクリティカルなニーズがある場合にのみ実行することをお勧めします。
障害が発生したリージョンから Azure Stack Edge デバイスを切断する
Azure Stack Edge デバイスは現在、パケット コア ソフトウェアを実行しており、障害が発生したリージョンから制御されています。 障害が発生したリージョンから Azure Stack Edge デバイスを切断し、実行中のパケット コアを削除するには、「Azure Stack Edge デバイスのリセットと再アクティブ化」に記載されているリセットと再アクティブ化の手順に従う必要があります。 これにより、パケット コア ソフトウェアだけでなく、Azure Stack Edge デバイスで現在実行されているすべてのソフトウェアが削除されるため、デバイスに他のソフトウェアを再インストールする機能があることを確認してください。 これにより、この Azure Stack Edge デバイス上のパケット コアに接続されているすべてのデバイスのネットワーク停止が開始されます。
Azure Stack Edge デバイスをバックアップ リージョンに接続する
「AKS クラスターを委任する」の手順に従って、Azure Stack Edge デバイスに Azure Kubernetes Service クラスターを再デプロイします。 この新しいインストールには別の名前を使用して、障害が発生したリージョンの復旧時にクラッシュしないようにしてください。 このプロセスの一環として、クラスターに関する新しいカスタムの場所 ID を取得します。これはメモしておく必要があります。
再インストールと検証
「準備」で格納した packetCoreControlPlanes.platform 値をコピーし、packetCoreControlPlane.platform.customLocation フィールドを上記の手順でメモしたカスタムの場所 ID で更新します。 packetCoreControlPlane.platform.azureStackEdgeDevice が、パケット コアをインストールする Azure Stack Edge デバイスの ID と一致していることを確認します。 次に、パケット コアを変更する手順に従って、バックアップ パケット コアをプラットフォーム値で更新します。 これにより、Azure Stack Edge デバイスへのパケット コアのデプロイがトリガーされます。
新しいサイト インストールを検証するための通常のプロセスに従って、UE 接続が復元され、すべてのネットワーク機能が動作していることを確認する必要があります。 特に、Azure portal のサイト ダッシュボードに UE 登録が表示され、データがデータ プレーンを通過していることを確認する必要があります。
失敗したリージョンの復元
障害が発生したリージョンが復旧したら、「準備」の手順に従って、アクティブなバックアップ リージョンから復旧したプライマリ リージョンへのバックアップを実行することで、2 つのリージョンの構成が同期されるようにする必要があります。
また、前の手順で破棄されていない復旧済みリージョンのリソースがないか確認して、あれば削除する必要があります。
- バックアップ リージョンに移動した Azure Stack Edge デバイスごとに、「復旧」の手順に従って、古い ARC クラスター リソースを見つけて削除する必要があります。 このリソースの ID は、「準備」でバックアップした値の packetCoreControlPlane.platform.customLocation フィールドにあります。 対応する Kubernetes クラスターが復旧プロセスの一部として削除されたため、このリソースの状態は切断されます。
- バックアップ リージョンに移動したパケット コアごとに (「復旧」の手順に従う)、復旧されたリージョン内の NFM オブジェクトを見つけて削除する必要があります。 これらはパケット コア コントロール プレーン リソースと同じリソース グループに一覧表示され、[リージョン] の値は復旧されたリージョンと一致します。
継続中の管理には次の 2 つの選択肢があります。
- 運用バックアップ リージョンを新しいプライマリ リージョンとして使用し、復旧したリージョンをバックアップとして使用します。 これ以上操作は必要ありません。
- リソースを別のリージョンに移動する方法に関するページにある手順に従って、復旧されたリージョンに戻すことにって、復旧されたリージョンを新しいアクティブなプライマリ リージョンにします。
テスト
ディザスター リカバリー計画をテストする場合は、1 つのパケット コアの復旧手順に従って、いつでも実行できます。 これにより、パケット コア サービスが停止し、最大 4 時間、UE へのネットワーク接続が中断されるため、運用以外のパケット コアのデプロイのみで実施するか、停止してもビジネスに悪影響をもたらさない場合にのみ実施することをお勧めします。