Automation 360 は、さまざまなレベルのエンタープライズにおける費用対効果および復元性の要件を満たす複数の導入オプションを提供します。オプションとして、単一ノードへのインストールと複数ノードへのインストールがあります。 複数ノードのデプロイメントを設定することで、高可用性(HA)クラスターおよび災害復旧(DR)サイトを構築できます。

デプロイ サービスは、Automation 360 インストーラーを使用して設定します。 典型的な Automation 360 サーバー ノードでは、以下のサービスが実行されます。

  • Automation Anywhere オートメーション サービス
  • Automation Anywhere メッセージング サービス
  • Automation Anywhere キャッシング サービス
  • Automation Anywhere 検索サービス
  • リポジトリ保存
  • (オプション) IQ Bot VM

また Automation 360 インストーラーは、複数ノードのデプロイ構成もサポートしています。

計画

デプロイ モデルを選ぶ前に、要件を特定します。 最良の結果を得るには、Automation Workspace の開発、テスト、および実稼働環境全体に同じオペレーティング システムをデプロイします。 少なくとも、テストや実稼働環境では同じ OS を使用します。

デプロイ モデル

大まかに言うと、Automation 360 をデプロイまたはインストールする方法には、単一ノードと複数ノードの 2 つがあります。 事業継続の要件に応じたオプションをお選びください。

単一ノード デプロイ

名前が示すように、Automation 360 に関連するすべてのサービスが実行される単一の物理サーバー ノードがあります。 設計上、この構成では冗長性がないため、可用性はこの単一ノードのサービスによって異なります。

データベース
単一ノード デプロイでは、Control Room サーバーがデータベース サーバーに接続できるのであれば、どこでも構いません。 これには、ネットワーク設定が含まれることがあります。
注: Control Room サーバーと同じサーバーでデータベース サーバーをホストすることはできません。サーバーでより高度な処理/メモリ構成が必要になるためです。
特性
  • 災害復旧なし (単一障害発生時点): 単一ノードに障害が発生すると、RPA の動作に悪影響が及びます。
  • 高可用性なし: サーバーが更新またはメンテナンスのためにオフラインになると、RPA 操作に影響が生じます。
  • RPA のアップスケーリングなし: RPA のデプロイがスケールアップし、ユーザーが増加すると、単一ノードが増加した負荷を管理する必要があります。 これは、RPA のパフォーマンスに悪影響を及ぼす可能性があります。
使用上の推奨事項
単一ノードのデプロイは、通常、概念実証、デモ、テスト、試用などの小規模な使用に推奨されます。
単一ノードの導入は、ダウンタイムが発生した場合、RPA の運用や事業継続に支障をきたすため、本番環境での使用は推奨されません。
注: 監査ログは、OpenSearch の単一ノード(ElasticSearch)を使用している場合、表示されないことがあります。 詳細については、Automation Anywhere サポートまでお問い合わせください。
メリット
  • 迅速かつ簡単なインストールと設定
  • 追加のサーバーは不要
  • ロード バランサーとクラスタリング構成は不要

次の図は、単一ノードの Automation Anywhere およびデータ センター コンポーネントを示しています。 Automation Anywhere コンポーネントはオレンジ色で表示され、組織が提供するコンポーネントは青色で表示されます。 クラウド上で一元的にホストされ、ライセンス サーバーなどの Automation Anywhere によって管理されるコンポーネントは、明るいオレンジ色で表示されます。

単一ノード デプロイ モデル

複数ノード デプロイ

より高い処理規模と本番環境でのより高い可用性を実現するために、Automation 360 サービスは複数のサーバー ノードにデプロイされます。 インストーラーで複数モード設定が可能です。 これには、サービスを同じデータベースにリンクするなどの追加の設定手順が含まれます。

分散アプローチ
Control Room は、特定の時間枠で大量のリクエストを処理する柔軟性を提供します。

必要に応じて、複数の物理サーバーや仮想サーバーに Control Room の複数のインスタンスをデプロイします。 これは、キャッシュ、検索、およびメッセージング サービスのクラスター設定を行うことも意味します。

ロード バランシング
ロード バランサーによって実行され、サービス活動を保護するために複数のサーバー間でアプリケーションまたはネットワーク トラフィックを分散し、ワークロードを複数のサーバー間で分散するプロセスです。 これにより、クラスター化されたサーバーでオートメーション アクティビティが継続されます。

ロード バランサーの要件

データベース
複数ノード デプロイでは、データベースは独自の組み込みフェールオーバーを使用してデータを保護します。 これにより、データベースのデータ復旧を確実なものにしています。

AWS-RDS のようなクラウドベースのデータベース サービスを使用する場合、それらのサービスの一部として高可用性と災害復旧が提供されます。この場合、それ以上のデータベース構成は必要ありません。

純粋なオンプレミス データベース シナリオでは、データセンターのプライマリ (アクティブ) とセカンダリ (パッシブ) のクラスター化された Microsoft SQL Server 間の同期レプリケーションを構成します。 これにより、データベース ノードに障害が発生した場合でも一貫性が保たれます。

同期レプリケーションの場合、Microsoft SQL Server の発行者および加入者モデルを使用して、プライマリ災害復旧サイトから、プライマリ サイトから地理的に離れた場所にあるセカンダリ災害復旧サイトにデータベースを構成します。

プライマリ サイトとセカンダリ サイト間でデータを複製

次の図は、データ センター クラスター内の 3 ノードの Automation Anywhere とデータ センター コンポーネントを示しています。 Automation Anywhere コンポーネントはオレンジ色で表示され、組織が提供するコンポーネントは青色で表示されます。 クラウド上で一元的にホストされ、ライセンス サーバーなどの Automation Anywhere によって管理されるコンポーネントは、明るいオレンジ色で表示されます。

高可用性 (HA) 導入モデル
重要: ストレッチ クラスターには対応していません。
  • すべての HA クラスター ノードが同じ場所に構成されていることを確認します。 さまざまなサイトに配置されている単一の HA クラスター内にノードを構成しないでください。 プライマリ サイトで HA クラスターを 1 つ構成し、セカンダリ サイトでもう 1 つの HA クラスターを構成します。
  • Control RoomIQ Bot は、両方のアプリケーション間の通信を確保するために、同じデータセンターで構成する必要があります。