- 概要
- 要件
- インストール
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベスト プラクティスとメンテナンス
- トラブルシューティング
- 移行後にログインできない
- 管理ポータルのタイムアウト期間を設定する
- 基になるディレクトリ接続を更新する
- Kinit: Cannot Find KDC for Realm <AD Domain> While Getting Initial Credentials
- kinit: Keytab contains no suitable keys for *** while getting initial credentials
- GSSAPI operation failed with error: An invalid status code was supplied (Client's credentials have been revoked).
- Login Failed for User <ADDOMAIN><aduser>. Reason: The Account Is Disabled.
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- Automation Suite 診断ツールを使用する
- Automation Suite サポート バンドルを使用する
- ログを確認する
Automation Suite インストール ガイド
手動: マルチノードの高可用性対応運用環境のプロファイルの要件とインストール
このページでは、マルチノードの高可用性対応運用環境プロファイルの要件とインストール手順について説明します。
選択するデプロイ プロファイルに関係なく、Linux と Kubernetes の知識が必要です。Automation Suite のインストールと構成で問題が発生した場合は、UiPath プロフェッショナル サービスにお問い合わせください。
デプロイ プロファイルを選択する前に、「シングルノードおよびマルチノードのインストールにサポートされるユース ケース」をご覧ください。
インストール プロセスによって、ユーザーに代わって自己署名証明書が生成されます。これらの証明書は 90 日で有効期限が切れるので、インストールが完了したら速やかに、信頼された証明機関 (CA) によって署名された証明書に置き換える必要があります。証明書を更新しないと、90 日後にインストールが停止します。手順については、「証明書を管理する」をご覧ください。
マルチノードの HA 対応の運用プロファイルは、1 つのノードの障害に対してのみ回復性があります。つまり、失うことができるサーバー ノードは 1 つだけです。この制限は、エージェント ノードには適用されません。クラスター全体の容量が十分に利用可能な限り、エージェント ノードをいくら失っても、ダウンタイムなしでクラスターを使用し続けることができます。
Federal Information Processing Standard (FIPS) は、Automation Suite に対応していません。Automation Suite を実行しているサーバー上で、任意の時点で FIPS が有効化された場合、クラスターは失敗します。クラスター サーバーで FIPS が有効化されている場合、インストールがブロックされる問題がインストーラーで発生します。
ノードあたりのベースライン リソース オーバーヘッドが固定されているため、ノード サイズが大きい方が効率的です。たとえば、3 x 32 コアのノードは 6 x 16 コアのノードより効率的です。
デプロイ プロファイル |
前提条件 |
要件 |
構成 |
インストール |
---|---|---|---|---|
マルチノードの HA 対応の運用プロファイル |
ipcalc ツールがインストールされた Linux マシン 3 台以上 (RHEL 8.6、8.8)
注:
|
| ||
| ||||
DNS | N/A | |||
IPv4 重要:
IPv6 はサポートされていません。 |
N/A |
N/A | ||
信頼できる TLS、トークン署名、および SQL 接続暗号化証明書 | N/A | |||
ロード バランサー | N/A | |||
プロキシ サーバー (任意) | N/A | |||
Kerberos 認証を設定する (任意) |
N/A |
- Automation Suite をインストールおよびデプロイするには、ルート権限が必要です。
ルート アクセスを必要とする特定のコンポーネントの詳細については、「root 権限の要件」をご覧ください。 - お使いのシステムでスキャン エージェントが実行されている場合、スキャン エージェントによって IP テーブルが変更されるために、インストールまたはランタイムが失敗する可能性があります。この問題を回避するには、スキャン エージェントを構成して、Automation Suite のインストールに干渉しないようにします。
- UiPath は、Automation Suite の要件を満たしている限り、特定のファイアウォールや開発者ツールの構成を指示しません。UiPath の見解では、外部ツールの数が限られていても、Automation Suite のスムーズな操作が妨げられる可能性があります。このような問題が発生した場合は、関連するベンダーにお問い合わせください。追加の指針については、「責任のマトリクス」をご覧ください。
最小のハードウェア要件では、ノードの障害からデプロイを保護できません。
必要なストレージを理解し、それに応じた計画を立てるには、「必要なストレージを評価する」をご覧ください。
マルチノードの HA 対応の運用プロファイルは、1 つのノードの障害に対してのみ回復性があります。つまり、失うことができるサーバー ノードは 1 つだけです。この制限は、エージェント ノードには適用されません。クラスター全体の容量が十分に利用可能な限り、エージェント ノードをいくら失っても、ダウンタイムなしでクラスターを使用し続けることができます。
Federal Information Processing Standard (FIPS) は、Automation Suite に対応していません。Automation Suite を実行しているサーバー上で、任意の時点で FIPS が有効化された場合、クラスターは失敗します。クラスター サーバーで FIPS が有効化されている場合、インストールがブロックされる問題がインストーラーで発生します。
マルチノードの HA 対応の運用プロファイルを選択する場合は、以下のハードウェア要件を満たす必要があります。
マルチノードの HA 対応の運用プロファイル (運用環境のデプロイでサポートされる唯一の構成) | ||
---|---|---|
選択 |
完了 |
ベーシック |
ノード数 |
サーバー ノード 3 台以上。 フォールト トレランスを向上させるため、クラスター内のサーバー ノード数は奇数にする必要があります。 エージェント ノードの数に制限はありません。 | |
プロセッサ |
96 (v-)CPU/コア |
48 (v-)CPU/コア |
ノードあたりの最小プロセッサー数 |
16 (v-)CPU/コア |
16 (v-)CPU/コア |
RAM 合計 |
192 GiB |
96 GiB |
ノードあたりの最小 RAM |
32 GiB |
32 GiB |
ノードごとのクラスター バイナリとステート ディスク |
256 GiB SSD 最小 IOPS: 1100 |
256 GiB SSD 最小 IOPS: 1100 |
サーバー ノードごとのデータ ディスク |
2 TiB SSD 最小 IOPS: 1100 |
512 GiB SSD 最小 IOPS: 1100 |
サーバー ノードごとの etcd ディスク |
16 GiB SSD 最小 IOPS: 240 |
16 GiB SSD 最小 IOPS: 240 |
UiPath バンドル ディスク (オフライン インストールの場合のみ、いずれかのサーバー ノード上で) |
512 GiB SSD 最小 IOPS: 1100 |
512 GiB SSD 最小 IOPS: 1100 |
Task Mining 用の追加エージェント ノード (必須) | ||
プロセッサ |
20 (v-)CPU/コア |
N/A (この選択に Task Mining は存在しません) |
RAM |
60 GiB | |
クラスター バイナリとステート ディスク |
256 GiB SSD 最小 IOPS: 1100 | |
データ ディスク |
N/A | |
Document Understanding 用に GPU がサポートされた追加エージェント ノード (強く推奨) | ||
プロセッサ |
8 (v-)CPU/コア |
N/A (この選択に AI Center は存在しません) |
RAM |
52 GiB | |
クラスター バイナリとステート ディスク |
256 GiB SSD 最小 IOPS: 1100 | |
データ ディスク |
N/A | |
GPU RAM |
11 GiB |
このページでは、インストール時にどの証明書の構成が必要かについて説明します。
インストール プロセスによって、ユーザーに代わって自己署名証明書が生成されます。インストールが完了したら速やかに、信頼された証明機関 (CA) によって署名された証明書に置き換える必要があります。証明書を更新しないと、90 日後にインストールが停止します。
クラスターに外部サービスを信頼させるには、上記の証明書とは別に、追加の信頼された CA 証明書の提供が必要になる場合があります。例: SQL Server の CA 証明書、SMTP サーバーの CA 証明書など
インストール バンドルでは、インストール後に証明書を更新できるクラスター管理ツールを提供しています。
これにアクセスするには、インストーラー バンドルの保存場所に移動します。
cd /opt/UiPathAutomationSuite/
cd /opt/UiPathAutomationSuite/
証明書の更新手順については、「証明書を管理する」をご覧ください。
自己署名証明書を使用する場合、クラスターにアクセスするには次の手順を実行します。
CA (証明機関) バンドル証明書を、以下のマシンの信頼ストアに追加する必要があります。
- クライアント マシン
- ロボットが実行されるマシン
- ブラウザーで Automation Suite にアクセスするマシン
- 最初のサーバー マシン (エアギャップの場合の要件)
- エアギャップ バンドルがダウンロードされ、抽出されるマシン
RHEL マシンの信頼ストアに証明書を追加するには、以下のコマンドを実行します。
sudo cp --remove-destination rootCA.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust
sudo cp --remove-destination rootCA.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust