アーキテクチャに関する基本的な考慮事項

マルチサイト デプロイと同様に、Automation Suite にも、インフラストラクチャ、レイテンシ、データ ソース、管理、回復時間の目標、回復ポイントの目標などのアーキテクチャ上重要な考慮事項があります。

インフラストラクチャ

両方のクラスターに同じハードウェアを使用することをお勧めします。ただし、Automation Suite クラスターは、違いがほとんどない類似のハードウェア構成でもおそらく動作します。異種のハードウェアでは、複雑さが増し、トラブルシューティングに時間がかかる場合があります。

管理

2 つの Automation Suite クラスターは独立しており、構成を共有しません。したがって、管理やメンテナンスのアクティビティは、各クラスターで個別に実行する必要があります。たとえば、両方のクラスターの SQL 接続文字列を更新し、証明書を個別に設定するなどの必要があります。さらに、2 つのクラスターを個別に監視し、個別にアップグレードするなどの必要があります。

データ ソース

ObjectStore を SQL データベースと組み合わせることにより、Automation Suite にインストールされた製品の状態を形成します。

SQL Server の構成は、マルチサイト デプロイで重要な役割を果たします。SQL Server は Automation Suite の外部コンポーネントですが、Automation Suite と連動させる際に真の高可用性を実現するために、追加で必要な手順がいくつかあります。

SQL Server は、Always On 可用性グループまたはフェイルオーバー グループに構成する必要があります。両方のサイトに分散させて、一方のサイトがダウンしたときに高可用性を厳密に確保する必要があります。両方のクラスターが接続文字列で同じ SQL リスナー エンドポイントを使用する必要があります。さらに、SQL Server/データベースが複数のサブネットにまたがって分散されている場合は、接続文字列で MultiSubnetFailover=True プロパティを設定することをお勧めします。

詳細については、「 Always On 可用性グループ」および 「Always On 可用性グループの前提条件、制限、推奨事項」をご覧ください。

外部 ObjectStore は、ノードの障害による破損の影響を受けるおそれがありません。Automation Suite から独立して、データのレプリケーションや障害復旧を実行できます。SQL Server と同様に、外部 ObjectStore も高可用性障害復旧の設定で構成する必要があります。プライマリ ObjectStore インスタンスをプライマリ データ センターに物理的に配置し、データ同期が有効化されたセカンダリ データ センターに少なくとも 1 つのセカンダリ インスタンスを配置します。ObjectStore にロード バランサーを構成すると、両方の Automation Suite クラスターが同じエンドポイントを参照するようになります。これにより、ObjectStore の内部構成に依存しないデプロイが可能になります。

重要:

AWS S3 の場合、マルチリージョン アクセス ポイントは Automation Suite で実行されるすべての製品に必要な S3 API をすべてサポートしているわけではありません。サポートされている API のリストについて詳しくは、「マルチリージョン アクセス ポイントでのサポートされている API オペレーションの使用」をご覧ください。

両方のリージョンで製品/スイートごとに 2 つのバケットを作成し、同期を有効化できます。同じリージョンで実行される Automation Suite クラスターは、同じリージョン内のバケットを参照します。

回復時間の目標

RTO に関する組織のポリシーは、マルチサイト Automation Suite クラスターの設計に不可欠です。目標の RTO を実現するには、以下の要素を考慮します。

• Traffic Manager の設計。
• セカンダリ/パッシブ クラスター内のノードの可用性。
• セカンダリ クラスターでの動的なワークロード (ML スキルなど) の可用性。
• 構成管理。

Traffic Manager

プライマリ クラスターが利用可能な場合は常にプライマリ クラスターにトラフィックをルーティングするように Traffic Manager を設定することで、回復時間を短縮できます。セカンダリ クラスターへのリダイレクトは、プライマリ クラスターがダウンしている場合にのみ実行する必要があります。これにより、トラフィックの切り替えが自動で行われ、手動切り替えの時間を短縮できます。そのためには、両方のクラスターの健全性チェックのエンポイントを使用します。

ノードの可用性

セカンダリ クラスター内のすべてのノードが実行されている場合は、ノードをオンにしてクラスターがアクティブになるのを待つことにより、時間を節約できます。ただし、インフラストラクチャのコストはほぼ 2 倍になる可能性があります。

動的なワークロードの可用性

AI Center などの一部の製品では、ML スキルを実行時に動的にデプロイします。別のクラスターへのスキルのデプロイは常に非同期です。そのため、スキルの可用性を保証できません。適切な時間内にオートメーション ソリューションがオンラインに戻るようにするには、別のクラスターでスキルを定期的に同期します。

構成の管理

Automation Suite のマルチサイト デプロイは 2 つの異なるクラスターで構成されるため、一方のクラスターで実行される操作を他方のクラスターで遅延なく実行してずれを減らす必要があります。これにより、両方のクラスターの構成がほぼ同じになり、回復フェーズに費やす労力を抑えることができます。

回復ポイントの目標

回復ポイントの目標 (RPO) に関する組織のポリシーは、マルチサイト Automation Suite クラスターの設計に不可欠です。目標の RPO を実現するには、以下の要素を考慮します。

• データ同期
• スケジュールされたバックアップ

データの同期

プライマリ データ ソースにデータを書き込む際には、データをセカンダリ クラスターにも同期する必要があります。しかし、データセンターがダウンしてデータが同期されない場合は、データ損失のリスクがあります。模範的なネットワーク構成 (2 つのデータセンター間の帯域幅が広く、レイテンシが低い場合など) では、同期速度が向上します。

スケジュールされたバックアップ

Not all disaster recovery provides complete immunity to data loss. However, you can deploy a regular and periodic backup strategy to minimize the impact of the disaster on data recovery. For details, see Backing up and restoring the cluster.