- 概要
- 要件
- 推奨: デプロイ テンプレート
- 手動: インストールを準備する
- 手動: インストールを準備する
- 手順 1: オフライン インストール用に OCI 準拠レジストリを設定する
- 手順 2: 外部 ObjectStore を構成する
- 手順 3: High Availability Add-on を構成する
- 手順 4: Microsoft SQL Server を構成する
- 手順 5: ロード バランサーを構成する
- 手順 6: DNS を構成する
- 手順 7: カーネルと OS レベルの設定を構成する
- 手順 8: ディスクを構成する
- 手順 9: ノード ポートを構成する
- 手順 10: その他の設定を適用する
- 手順 12: 必要な RPM パッケージを検証してインストールする
- 手順 13: cluster_config.json を生成する
- 証明書の設定
- データベースの構成
- 外部 ObjectStore の構成
- 署名済み URL の構成
- 外部の OCI 準拠レジストリの設定
- 障害復旧: アクティブ/パッシブおよびアクティブ/アクティブ構成
- High Availability Add-on の構成
- Orchestrator 固有の設定
- Insights 固有の構成
- Process Mining 固有の構成
- Document Understanding 固有の構成
- Automation Suite ロボット固有の構成
- 監視の構成
- 任意: プロキシ サーバーを構成する
- 任意: マルチノードの HA 対応の運用クラスターにおけるゾーン障害に対する復元設定を有効化する
- 任意: カスタムの Resolv.con を渡す
- 任意: フォールト トレランスを向上させる
- install-uipath.sh パラメーター
- GPU がサポートされた専用のエージェント ノードを追加する
- Task Mining 専用のエージェント ノードを追加する
- Task Mining アプリケーションを接続する
- Automation Suite ロボット専用のエージェント ノードを追加する
- 手順 15: オフライン インストール用に一時的な Docker レジストリを設定する
- 手順 16: インストールの前提条件を検証する
- 手動: インストールを実行する
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベストプラクティスとメンテナンス
- トラブルシューティング
- インストール時にサービスをトラブルシューティングする方法
- クラスターをアンインストールする方法
- オフライン成果物をクリーンアップしてディスク領域を改善する方法
- Redis データをクリアする方法
- Istio ログを有効化する方法
- ログを手動でクリーンアップする方法
- sf-logs バンドルに保存されている古いログをクリーンアップする方法
- AI Center のストリーミング ログを無効化する方法
- 失敗した Automation Suite インストールをデバッグする方法
- アップグレード後に古いインストーラーからイメージを削除する方法
- NIC チェックサムオフロードを無効にする方法
- Automation Suite 2022.10.10 および 2022.4.11 から 2023.10.2 にアップグレードする方法
- ArgoCD のログ レベルを手動で Info に設定する方法
- RHEL 8.4 OS でオフライン インストールを実行できない
- バンドルのダウンロード中のエラー
- バイナリがないため、オフライン インストールが失敗する
- オフライン インストールでの証明書の問題
- Longhorn のセットアップ中に最初のインストールが失敗する
- SQL 接続文字列の検証エラー
- selinux iscsid モジュールの前提条件の確認が失敗する
- Azure ディスクが SSD としてマークされない
- 証明書の更新後のエラー
- ウイルス対策が原因でインストールの問題が発生する
- OS のアップグレード後に Automation Suite が動作しない
- Automation Suite で backlog_wait_time を 0 に設定する必要がある
- ワークロードの準備ができていないためボリュームをマウントできない
- 2021.10 からの自動アップグレード後にクラスターが異常になる
- Ceph の異常によりアップグレードが失敗する
- 領域の問題のために rke2 が開始しない
- ボリュームがマウントできず、アタッチ/デタッチ ループ状態のまま
- Orchestrator データベース内のクラシック オブジェクトが原因でアップグレードが失敗する
- Ceph クラスターがサイドバイサイド アップグレード後に機能低下ステートで検出される
- 異常な Insights コンポーネントが原因で移行が失敗する
- Apps のサービス アップグレードの失敗
- インプレース アップグレードのタイムアウト
- Docker レジストリの移行が PVC の削除段階でスタックする
- v2023.10 へのアップグレード後に AI Center をプロビジョニングできない
- オフライン環境でアップグレードが失敗する
- 管理ポータルのタイムアウト期間を設定する
- 移行後に認証が機能しない
- Kinit: Cannot Find KDC for Realm <AD Domain> While Getting Initial Credentials
- kinit: Keytab contains no suitable keys for *** while getting initial credentials
- 無効なステータス コードが原因で GSSAPI 操作が失敗した
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- アカウントが無効なため AD ユーザーのログインに失敗した
- ArgoCD へのログインに失敗した
- 基になるディレクトリ接続を更新する
- 診断ツールを実行する
- Automation Suite サポート バンドル ツールを使用する
- ログを確認する
マルチノードのアーキテクチャと設計に関する考慮事項
次のアーキテクチャ図は Linux 上の Automation Suite のデプロイを示しています。Kubernetes が 6 台のマシンにインストールされ、ロード バランサーとデータ ストレージが配されています。 マシン タイプは複数あり、サーバー ノード 3 つ、エージェント ノード 2 つ、専用エージェント ノード 1 つという構成です。
etcd
コンポーネントによるものです。詳細については、etcd のドキュメントをご覧ください。同じ理由で、クラスターを正常な状態に保つには、サーバー ノードの大部分が常に利用可能である必要があります。
これらのノードは、Prometheus、クラスタ内 ObjectStore Ceph、UiPath Insights、クラスタ内 Docker レジストリなど、ノード上にデータ ストレージを必要とするコンポーネントもホストします。
エージェント ノードは、ワーカー ノードと呼ばれることもあります。これらのノードの目的は、UiPath® サービスとその他の共有されるスイート機能をホストすることです。これらのノードにはデータ ディスクが接続されていないため、ディスク ストレージを必要とするコンポーネントをホストすることはできません。
エージェント ノードは、任意の時点で使用可能なノードの数に制限を課しません。 結果として得られるクラスターに、失われたノードのすべてのポッドをホストする十分な容量がある限り、クラスターは中断することなく期待どおりに動作します。
これらのノードは特殊なタスク専用の特殊なエージェント ノードです。たとえば、分析用の Task Mining ノード、ロボット実行用の Automation Suite ロボット ノード、Document Understanding モデル用の GPU ノードなどです。これらのノード上で他の UiPath® サービスをホストすることはできません。
Automation Suite の外部にインストールされるロード バランサーは、Automation Suite クラスターでホストされているアプリケーションにアクセスするためのエントリ ポイントとして機能します。 ロード バランサーは、ノードのフォールト トレランスに対応している必要があります。 すべてのサーバー ノードをロード バランサー上に構成する必要がありますが、エージェント ノードも任意で構成することができます。 ただし、専用エージェント ノードは不要です。
ロボットが Orchestrator にアクセスしようとすると、呼び出しはロード バランサーに送信され、利用可能な任意のノードに渡されます。 各ノードは、Istio と呼ばれるネットワーク コンポーネントもホストします。Istio はロード バランサーのような役目を果たすサービス メッシュです。 ノードで実行されている Istio が呼び出しを受信すると、クラスター全体で Orchestrator インスタンスを見つけようとします。 見つかると、呼び出しがそのインスタンスにリダイレクトされます。
多数の小容量マシンか、少数の大容量マシンか、どちらを選ぶかは完全にユーザー次第であり、どちらの選択肢にもそれぞれ長所と短所があります。 多数の小容量マシンのほうが少数の大容量マシンよりもノードのフォールト トレランスに対する回復性が高くなります。 同時に、管理オーバーヘッドも増えます。
たとえば、Automation Suite クラスターに 96 vCPU が必要な場合は、次のいずれかのオプションを選択できます。
-
オプション 1: 1 台あたり 16 vCPU のマシンを 6 台。
-
影響: 1 台のマシンを失った場合、クラスターの容量は 16 vCPU 減少するだけなので、結果として生成されるクラスターにすべてのポッドをホストする容量がない場合にのみ、サービスに影響します。 ただし、6 台のマシンを管理するには手間が増えます。
-
-
オプション 2: 1 台あたり 32vCPU のマシンを 3 台。
-
影響: 1 台のマシンを失った場合、クラスターの容量が 32 vCPU 減少し、Automation Suite に大きな影響を与えます。 ただし、3 台のマシンを管理するほうが手間は少なくなります。
-
結論として、デプロイの設計は目標によって決まるということです。 フォールト トレランスの向上が目標である場合は、多数の小容量マシンのほうが適しています。 一方、管理オーバーヘッドの削減が目標の場合は、少数の大容量マシンを選択する必要があります。
エージェント ノードではなく、すべてサーバー ノードにするべきかどうかは、RTO または RPO によって異なります。
たとえば、Automation Suite に 80 vCPU が必要だとします。 これを実現するには、次のいずれかの方法を選択できます。
-
オプション 1: 1 台あたり 16 vCPU のサーバー マシンを 5 台。 ここでは、最大 2 台のサーバー ノードを失っても運用を継続できます。
-
このオプションは、データ損失に対する回復性が目標である場合に推奨されます。 2 台のサーバー ノードが失われた場合でも、データは無事であり、残りのレプリカから再構築できます。
-
-
オプション 2: 3 台のサーバー ノードと、1 台あたり 16 vCPU のエージェント ノード 2 台。 ここでは、1 台のサーバー ノードと両方のエージェント ノード、合計で 3 台のマシンが失われても運用を継続できます。
-
このオプションは、ノードの可用性に対する回復性が目標である場合に推奨されます。 3 台のマシンが失われても、クラスターは限られた機能で引き続き使用でき、ノードが復元されると、クラスター全体が回復します。 ただし、ストレージはサーバー ノードに接続されているため、このセットアップではデータ損失が発生しやすくなります。 2 台のサーバー ノードが完全に失われた場合、バックアップからデータを復元しない限り、データを再構築することが困難になる可能性があります。
-