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

マルチサイト Automation Suite デプロイのアーキテクチャに関する考慮事項 (レイテンシ、ハードウェア、RTO、RPO の要因を含む)。

マルチサイト デプロイと同様に、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 configuration

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

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

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

外部 ObjectStore の構成

The external objectstore is immune to possible corruption due to node failure. Data replication and disaster recovery can be carried out independently of Automation Suite. Like SQL Server, the external objectstore must be configured in a highly available Disaster Recovery setup.

The primary objectstore instance is physically located in the primary data center, and at least one secondary instance is located in the secondary data center with data sync enabled. You can configure a load balancer on the objectstore to ensure both Automation Suite clusters refer to the same endpoints. This makes the deployment independent of how the objectstore is configured internally.

重要:

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

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

すべての障害復旧でデータの損失が完全に解消するわけではありません。しかし、一定間隔の定期的なバックアップ戦略をデプロイすれば、障害がデータ復旧に与える影響を最小限に抑えることができます。詳細については、「 クラスターをバックアップおよび復元する」をご覧ください。