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

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

インフラストラクチャ

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

遅延

レイテンシは、アクティブ/アクティブモデルの設計において非常に重要です。レイテンシとは、2 つの Automation Suite クラスター間の往復時間 (RTT) を示します。 2 つのサイト間の最小待機時間レベルは、停止中のデータ損失のリスクを大幅に軽減するため、最適です。 RTT は 10 ミリ秒のしきい値を下回る必要があります。

RTT はパフォーマンスメトリックに直接影響するため、運用段階に移行する前に厳密にテストする必要があります。待機時間がサイトのペア間で 10 ミリ秒のベンチマークを超える場合は、アクティブ/アクティブ構成ではなく、アクティブ/パッシブ構成を検討することをお勧めします。

注:

同期を必要とするコンポーネントの RTT は 10 ミリ秒未満である必要があります。これには、SQL Server、HAA、ObjectStore などが含まれます。

管理

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 を適切に構成することが重要です。この設定は、理想的には両方のクラスターへのトラフィックの分散を容易にする必要があります。この戦略は、負荷分散のバランスを確保するだけでなく、ビジネス継続性を保護し、いずれかのサイトで完全なシャットダウンが発生した場合の潜在的な中断を軽減します。

ノードの可用性

障害が発生して一方のサイトが完全に動作しなくなった場合、もう一方のサイトには、ビジネスオートメーションに影響を与えないように十分な容量が必要です。機能しているサイトの容量が不十分な場合、ビジネスの運営に悪影響を及ぼし、重大な運用上の問題につながる可能性があります。

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

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

構成の管理

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

回復ポイントの目標

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

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

データの同期

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