Linux の Automation Suite のインストールガイド

最終更新日時 2024年12月19日

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

マルチサイトデプロイと同様に、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 つのデータセンター間の帯域幅が広く、レイテンシが低い場合など) では、同期速度が向上します。