概要

ダイアグラム

次の図は、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 リスナーもデプロイされています。両方のクラスターが同じリスナーのアドレスを使用するように構成されています。
Object Store	製品にアップロードされるファイルやパッケージはすべて ObjectStore に保存されます。障害に対する回復性を高めるには、Automation Suite のデプロイに外部 ObjectStore が必要です。 効果的な障害復旧のためには、ObjectStore インスタンスが 2 つ必要で、各データセンターにインスタンスを 1 つずつ配置する必要があります。両方のクラスターが読み取りと書き込みにアクティブに使用する ObjectStore インスタンスは、常に 1 つだけである必要があります。このプロセスは、セカンダリ インスタンスへの非同期レプリケーションで補完する必要があります。

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

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

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> – 監視とアラートに使用されます。これは、アクティブ (プライマリ) クラスターとパッシブ (セカンダリ) クラスターの両方に必要です。

  すべてのサブドメインは、それぞれのルートドメインと同じロードバランサーに転送され、一貫性とルーティングの容易さが維持されます。

DNS ルーティング ロジック

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

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

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

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

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

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

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