Ansible Automation Platform on Azure の障害復旧
目次
Ansible Automation Platform on Azure の障害復旧
Ansible Automation Platform on Microsoft Azure は、サポート対象の Azure リージョンにおいて、マルチリージョンモデルを通じてオプションの追加バックアップ機能を提供します。このオプション機能は、管理対象アプリケーションのデプロイメント時に “Business Continuity” の手順で有効化されます。このオプションを有効にすると、プライマリー Azure リージョンの AAP データがセカンダリー Azure リージョンにバックアップされ、セカンダリーリージョンのストレージに追加の Azure インフラストラクチャーコストが発生します。デプロイメント時にしなかった場合、サポートヘルプリクエストを使用して、インスタンスでこの機能を有効にするようリクエストできます。
障害復旧機能は、プライマリーリージョンとそれに割り当てられたペアリージョン間のストレージのレプリケーションをアクティブ化します。AAP on Azure は、Microsoft が定義したリージョンペアを使用してこのソリューションを実装します。 Azure データセンターペアのリストは、Azure Cross-Region Replication (https://learn.microsoft.com/en-us/azure/reliability/cross-region-replication-azure) にあります。
障害復旧は高可用性と同義ではないことに注意してください。プライマリーリージョンが影響を受けると、サービスとデータが失われる可能性があります。
障害復旧のためのリージョンサポートとは
障害復旧機能は、すべての Azure リージョンでサポートされているわけではありません。お客様は、デプロイメント前にリージョンサポートマトリックスを参照して、必要なリージョンがサポート対象か確認する必要があります。プライマリーリージョンの夜間バックアップはすべてのインスタンスの標準ですが、セカンダリーリージョンを使用することで、プライマリー Azure リージョンで壊滅的なイベントが発生した場合のリスクをさらに軽減できます。Microsoft がサポート対象リージョンを追加するに伴い、Red Hat もこの機能を拡大できるように継続的に取り組んでいます。
| メインリージョン | マルチリージョン障害復旧 (はい/いいえ) | ペアバックアップリージョン |
|---|---|---|
| オーストラリア東部 | Y | オーストラリア南東部 |
| オーストラリア南東部 | Y | オーストラリア東部 |
| ブラジル南部 | Y | 米国中南部 |
| カナダ中部 | Y | カナダ東部 |
| カナダ東部 | Y | カナダ中部 |
| インド中部 | Y | 南インド |
| 米国中部 | Y | 米国東部 2 |
| チリ中部 | N | N/A |
| 東アジア | Y | 東南アジア |
| 米国東部 | Y | 米国西部 |
| 米国東部 2 | Y | 米国中部 |
| フランス中部 | Y | フランス南部 |
| ドイツ中西部 | Y | ドイツ北部 |
| インドネシア中部 | N | N/A |
| イスラエル中部 | N | N/A |
| イタリア北部 | N | N/A |
| 日本東部 | Y | 日本西部 |
| 日本西部 | Y | 日本東部 |
| 韓国南部 | Y | 韓国中部 |
| 韓国中部 | Y | 韓国南部 |
| マレーシア西部 | N | N/A |
| メキシコ中部 | N | N/A |
| ニュージーランド北部 | N | N/A |
| 米国中北部 | Y | 米国中南部 |
| 北ヨーロッパ | Y | 西ヨーロッパ |
| ノルウェー東部 | Y | ノルウェー西部 |
| ポーランド中部 | N | N/A |
| カタール中部 | N | N/A |
| 南アフリカ北部 | Y | 南アフリカ西部 |
| 米国中南部 | Y | 米国中北部 |
| 南インド | Y | インド中部 |
| 東南アジア | Y | 東アジア |
| スペイン中部 | N | N/A |
| スウェーデン中部 | Y | スウェーデン南部 |
| スイス北部 | Y | スイス西部 |
| UAE 北部 | Y | UAE 中部 |
| 英国南部 | Y | 英国西部 |
| 英国西部 | Y | 英国南部 |
| 米国中西部 | Y | 米国西部 2 |
| 西ヨーロッパ | Y | 北ヨーロッパ |
| 米国西部 | Y | 米国東部 |
| 米国西部 2 | Y | 米国中西部 |
| 米国西部 3 | Y | 米国東部 |
障害復旧はどのように機能しますか?
管理対象アプリケーションの夜間バックアップは、レプリケーションのために Azure ストレージに配置されます。このバックアップは、影響を受けていないリージョンの Ansible Automation Platform の新しいデプロイメントにロードされます。インスタンスの復旧に必要な時間は、復旧するデータの量と Azure リソースの可用性によって異なります。
アプリケーションはイベントからどのように復旧しますか?
管理対象アプリケーションのリージョンでサービスに影響を与えるイベントが発生している場合は、次の手順を実行する必要があります。
- 任意のリージョンに管理対象アプリケーションの 新しいインスタンス をデプロイします。プライマリーリージョンのリージョンペアを使用することが推奨されます。プライマリーインスタンスと同じ Azure サブスクリプションを使用して、管理対象アプリケーションの 2 番目のインスタンスをデプロイする必要があります。
- 注記: スムーズなデータ移行を確実に行うには、データ移行が正常に完了して検証されるまで、ネットワーク設定 (VNet ピアリングなど) をセットアップしないでください。SRE チームが復旧の成功を確認したら、ネットワークのセットアップに進むことができます。
- 管理対象アプリケーションのリージョンに障害が発生し、管理対象アプリケーションを復旧する必要があることを Red Hat カスタマーサポート に伝えます。次の情報を指定します。
- 影響を受けたインスタンスの名前
- 新しいインスタンスの名前
- Azure サブスクリプション ID
- 迅速な連携のための連絡先情報
- Red Hat Site Reliability Engineers (SRE) が復旧作業を優先的に行います。完全な復旧に必要な時間は、Azure リソースの可用性と復旧するデータの量によって異なります。
- サポートリクエストで提供された情報を使用して Red Hat の担当者がお客様に連絡し、処理が完了したことをお知らせします。新しいインスタンスに関する問題は、速やかな解決のために優先的に対処されます。
- 追加の設定を実行 します。新しいデプロイメントが完全に機能するには、追加の設定が必要になる場合があります。 カスタムドメインを使用するお客様は、DNS を調整する必要がある場合があります。 自動化メッシュノードの再設定が必要な場合があります。 お客様のネットワークでファイアウォールルールの調整が必要な場合があります。 一部の Azure インフラストラクチャー設定オプションは、インスタンスを復旧する際に保持されません。 新しいデプロイメントでこれらの特別な設定を実装するには、SRE チームにリクエストする必要があります。 以下は、これらのオプションの例です。
- 仮想ネットワーク上に設定された Azure プライベート DNS リゾルバー。
- ログをエクスポートするための Event Hub のデプロイメント。
- データベースまたはアプリケーションレベルの設定によってキャプチャーされない、Azure インフラストラクチャーに対する特別な調整。
これらの概算は、障害復旧イベントが発生した場合の期待値の設定に役立ちます。
| タスクの説明 | 対象者 | 概算時間 |
|---|---|---|
| 元のリージョンで製品が停止している間にイベントが発生した場合は、Red Hat カスタマーサポートに連絡して、重大度 1 のケースを起票してください。 | お客様 | Premium Support SLAs を参照 |
| *管理対象アプリケーションの新しいインスタンスをデプロイします。 | お客様 | \~1.5 時間 |
| Red Hat Site Reliability Engineers が復旧操作業を開始します。 | SRE | \~2 時間 |
| **サポートリクエストで提供された情報を使用して Red Hat の担当者がお客様に連絡し、処理が完了したことをお知らせします。 | Red Hat サポート | プレミアムサポート SLA の範囲内で復旧作業を完了した時点 |
*お客様は新しい環境で、VNET ピアリングやルーティングルールの定義など、「デプロイメント後のネットワーク設定」手順を実行する必要があります。これに要する時間は、Ansible on Azure の初期実装中に項目を設定するために要した時間と同じです。Ansible Automation Platform on Microsoft Azure に関するお客様の責任については、このリンク を参照してください。
**DR の概算は、次の変数に応じて各お客様の環境内のデータ量とネットワーク/トラフィック設定により異なります。
- 復旧対象サイトのデータベースサイズ (ジョブ履歴、インベントリー、その他の AAP データを含む)。
- Private Automation Hub に保存されているコレクションの数。
- Private Automation Hub に保存されている実行環境 (EE) の数。
- 復旧には、トラフィックのリダイレクト方法に応じて、リージョン間のネットワークルーティングの再設定も必要になる場合があります。
障害復旧のテスト方法は?
このプロセスは、障害復旧テストを要求するサポートリクエストを送信することでスケジュールできます。 管理対象アプリケーションの新しいインスタンスのデプロイメントを必要とするテストを実行する場合、上記の手順に従う必要があります。 障害復旧テストで元のインスタンスが破壊されることはありません。 Azure では、テストインスタンスに関連するインフラストラクチャーコストが請求されます。 48 時間以内にテストインスタンスを削除できない場合 (詳細は Azure Marketplace ポリシーを参照)、ソフトウェアサブスクリプションの料金も請求されます。
テストインスタンスで同じネットワーク設定を使用すると、障害復旧インスタンスがお客様のネットワークとピアリングしてテストされる場合に、プライマリーインスタンスが使用できなくなります。 問題を回避するために、自動化メッシュノードは両方のデプロイメントに同時に接続しないでください。
障害復旧テストに使用されたインスタンスは、テストが完了したら、元のインスタンスに影響を与えることなく削除できます。
障害復旧テストは 6 カ月ごとに 1 回まで という制限があります。
Comments