概要

ダイアグラム

次の図は、Automation Suite の通常のアクティブ/パッシブ デプロイを示しています。

要件

ハードウェア	要件
Global Traffic Manager (GTM)	トラフィックを Automation Suite のマルチサイト デプロイに分散します。このサービスは高可用性として設定し、どのデプロイ サイトの影響も受けないようにする必要があります。さらに、GTM で正常性チェックを設定し、エラーが発生したサイトを素早く分離できるようにする必要があります。GTM は必須ではありませんが、切り替えを高速化したい場合に推奨されます。 Global Traffic Manager (GTM) をアクティブ/パッシブ デプロイ用に構成する場合は、必ず /orchestrator_/api/status を健全性エンドポイントとして使用してください。これは、障害復旧を効果的に管理するために重要です。
ロード バランサー	すべてのサイトに、同じサイト内に構成された任意のノードにトラフィックを負荷分散できるローカル ロード バランサーが必要です。
ノード	両方のサイトに同じ数のノードが必要です。また、「 Kubernetes クラスターとノード 」に記載されているドキュメントを使用して、サイトごとにクラスターとノードを構成する必要があります。 詳しくは、「Automation Suite Install Sizing Calculator」をご覧ください。
SQL データベース	データを保存するために外部 SQL Server が必要です。障害復旧の場合、Always On 可用性グループ (または Amazon RDS の MSSQL と ReadReplica) が必要であり、プライマリ SQL Server がサイト 1 に、少なくとも 1 つのセカンダリ SQL Server (ReadReplica) がサイト 2 に物理的に配置され、データ同期が有効化されている必要があります。SQL Server の上部には SQL リスナーもデプロイされています。両方のクラスターが同じリスナーのアドレスを使用するように構成されています。 アクティブ (プライマリ) サイト/クラスターとパッシブ (セカンダリ) サイト/クラスターの両方で、データベース通信にプライマリ データベース エンドポイントを使用する必要があります。 障害が発生した場合、リードレプリカがプライマリに昇格したら、そのエンドポイントをアクティブサイトとパッシブサイトの両方で更新して、新しいデータベース接続文字列として機能するようにする必要があります。 フェイルオーバー管理を簡素化するために、Amazon Route 53 を使用してデータベースの DNS レコードを作成できます。最初に、プライマリ・データベース・エンドポイント(またはリスナー)を指す必要があります。フェイルオーバーが発生した場合は、Route 53 レコードを更新して、新しく昇格されたプライマリデータベース (以前のリードレプリカ) を指すようにすることができます。
Object Store	製品にアップロードされるファイルやパッケージはすべて ObjectStore に保存されます。障害に対する回復性を高めるには、Automation Suite のデプロイに外部 ObjectStore が必要です。 効果的な障害復旧のためには、ObjectStore インスタンスが 2 つ必要で、各データセンターにインスタンスを 1 つずつ配置する必要があります。両方のクラスターが読み取りと書き込みにアクティブに使用する ObjectStore インスタンスは、常に 1 つだけである必要があります。このプロセスは、セカンダリ インスタンスへの非同期レプリケーションで補完する必要があります。

ロード バランサーと DNS の構成

このセクションでは、通常の復旧シナリオと障害復旧シナリオの両方で動作するように設計されたシステムのインフラストラクチャのセットアップ、DNS アーキテクチャ、およびルーティング ロジックの概要を説明します。

インフラストラクチャの概要

高可用性とディザスター リカバリーをサポートするには、システムにデュアル ロード バランサーの設定が必要です。

• プライマリ ロード バランサー: 標準アプリケーション トラフィックを処理するために アクティブ (プライマリ) クラスター に割り当てられます。
• セカンダリ ロード バランサー: パッシブ (セカンダリ) クラスターに割り当てられ、プライマリで障害が発生した場合に引き継ぐ準備ができています。

各ロード バランサーには、DNS 解決のエンドポイントとして機能する一意の Elastic IP (EIP) が割り当てられます。

DNS アーキテクチャ

トラフィック管理とクラスター固有のサービスへのアクセスを容易にするために、DNS 構成の 2 つの層が採用されています。

• FQDN: アプリケーションの FQDN は、エンドユーザーがアプリケーション インターフェイスにアクセスするために使用するプライマリ ドメインです。この値は、input.jsonの [fqdn] フィールドに対応します。詳細については、「 アクティブ/パッシブ構成」をご覧ください。
• クラスター固有の FQDN: メイン アプリケーションの FQDN に加えて、各クラスターには、管理ツールおよび監視ツール用に独自の FQDN が必要です。この値は、各クラスターの input.jsonの [cluster_fqdn] フィールドで定義されます。詳細については、「 アクティブ/パッシブ構成」をご覧ください。
• サブドメイン: 包括的なサービス アクセスのために、アプリケーションの FQDN と各クラスター固有の FQDN の両方に一連のサブドメインが構成されます。これらには以下が含まれます:
  • FQDNの:
    • apps.<domain> – Apps で使用されます。
    • insights.<domain> – Insights で使用します。
  • クラスター固有の FQDN:
    • alm.<domain> – ArgoCD によってデプロイ管理に使用されます。これは、アクティブ (プライマリ) クラスターとパッシブ (セカンダリ) クラスターの両方に必要です。
    • monitoring.<domain> – 監視とアラートに使用されます。これは、アクティブ (プライマリ) クラスターとパッシブ (セカンダリ) クラスターの両方に必要です。

  すべてのサブドメインは、それぞれのルートドメインと同じElastic IP(EIP)に誘導され、一貫性とルーティングの容易さが維持されます。

DNS ルーティング ロジック

DNS ルーティング ロジックにより、ユーザー トラフィックは、システムの状態 (通常の運用時または障害復旧時) に応じて適切なロード バランサーに転送されます。

• 通常の操作 (プライマリ クラスターはアクティブ)

  標準動作モードでは、DNS は次の表に示すようにトラフィックをルーティングします。

  FQDN の種類	ルーティング ターゲット
  fqdn	プライマリ クラスター ロード バランサー
  プライマリ クラスターの FQDN	プライマリ クラスター ロード バランサー
  セカンダリ クラスターの FQDN	セカンダリ クラスター ロード バランサー

• ディザスター リカバリー (セカンダリ クラスターがアクティブ)

  プライマリ クラスターに障害が発生すると、システムはディザスタ リカバリ モードに入ります。この状態では、DNS はサービスの継続性を確保するために調整されます。

  FQDN の種類	ルーティング ターゲット
  fqdn	セカンダリ クラスター ロード バランサー
  プライマリ クラスターの FQDN	プライマリ クラスター ロード バランサー (変更なし)
  セカンダリ クラスターの FQDN	セカンダリ クラスター ロード バランサー (変更なし)