- 概要
- 要件
- 推奨: デプロイ テンプレート
- Q&A: デプロイ テンプレート
- 手動: インストールを準備する
- 手動: インストールを準備する
- 手順 1: オフライン インストール用に OCI 準拠レジストリを設定する
- 手順 2: 外部 ObjectStore を構成する
- 手順 3: High Availability Add-on を構成する
- 手順 4: Microsoft SQL Server を構成する
- 手順 5: ロード バランサーを構成する
- 手順 6: DNS を構成する
- 手順 7: ディスクを構成する
- 手順 8: カーネルと OS レベルの設定を構成する
- 手順 9: ノード ポートを構成する
- 手順 10: その他の設定を適用する
- 手順 12: 必要な RPM パッケージを検証してインストールする
- 手順 13: cluster_config.json を生成する
- Cluster_config.json のサンプル
- 全般的な構成
- プロファイル構成
- 証明書の設定
- データベースの構成
- 外部 ObjectStore の構成
- 署名済み URL の構成
- ArgoCD の構成
- 外部の OCI 準拠レジストリの設定
- Disaster Recovery - アクティブ/パッシブおよびアクティブ/アクティブの構成
- High Availability Add-on の構成
- Orchestrator 固有の設定
- Insights 固有の構成
- Process Mining 固有の構成
- Document Understanding 固有の構成
- Automation Suite ロボット固有の構成
- AI Center 固有の構成
- 監視の構成
- 任意: プロキシ サーバーを構成する
- 任意: マルチノードの HA 対応の運用クラスターにおけるゾーン障害に対する復元設定を有効化する
- 任意: カスタムの Resolv.con を渡す
- 任意: フォールト トレランスを向上させる
- GPU がサポートされた専用のエージェント ノードを追加する
- Task Mining 専用のエージェント ノードを追加する
- Task Mining アプリケーションを接続する
- Automation Suite ロボット専用のエージェント ノードを追加する
- 手順 15: オフライン インストール用に一時的な Docker レジストリを設定する
- 手順 16: インストールの前提条件を検証する
- 手動: インストールを実行する
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベスト プラクティスとメンテナンス
- トラブルシューティング
- インストール時にサービスをトラブルシューティングする方法
- クラスターをアンインストールする方法
- オフライン成果物をクリーンアップしてディスク領域を改善する方法
- Redis データをクリアする方法
- Istio ログを有効化する方法
- ログを手動でクリーンアップする方法
- sf-logs バケットに保存されている古いログをクリーンアップする方法
- AI Center のストリーミング ログを無効化する方法
- 失敗した Automation Suite インストールをデバッグする方法
- アップグレード後に古いインストーラーからイメージを削除する方法
- TX チェックサム オフロードを無効化する方法
- ArgoCD のログ レベルを手動で Info に設定する方法
- AI Center のストレージを拡張する方法
- 外部レジストリーのエンコードされたpull_secret_valueを生成する方法
- TLS 1.2 で弱い暗号に対処する方法
- TLSのバージョンを確認する方法
- Ceph のバックアップとデータの復元をスケジュールする方法
- RHEL 8.4 OS でオフライン インストールを実行できない
- バンドルのダウンロード中のエラー
- バイナリがないため、オフライン インストールが失敗する
- オフライン インストールでの証明書の問題
- SQL 接続文字列の検証エラー
- selinux iscsid モジュールの前提条件の確認が失敗する
- Azure ディスクが SSD としてマークされない
- 証明書の更新後のエラー
- ウイルス対策が原因でインストールの問題が発生する
- OS のアップグレード後に Automation Suite が動作しない
- Automation Suite で backlog_wait_time を 0 に設定する必要がある
- ワークロードの準備ができていないためボリュームをマウントできない
- サポート バンドルのログ収集の失敗
- Automation Suite のアップグレード後に Insights を再インストールまたはアップグレードするとデータが失われる
- Automation Suite 2024.10.0 へのアップグレード後に Automation Hub にアクセスできない
- シングルノードのアップグレードがファブリック ステージで失敗する
- Ceph の異常によりアップグレードが失敗する
- 領域の問題のために rke2 が開始しない
- ボリュームがマウントできず、アタッチ/デタッチ ループ状態のまま
- Orchestrator データベース内のクラシック オブジェクトが原因でアップグレードが失敗する
- Ceph クラスターがサイドバイサイド アップグレード後に機能低下ステートで検出される
- 異常な Insights コンポーネントが原因で移行が失敗する
- Apps のサービス アップグレードの失敗
- インプレース アップグレードのタイムアウト
- Docker レジストリの移行が PVC の削除段階でスタックする
- v2023.10 以降へのアップグレード後に AI Center のプロビジョニングが失敗する
- オフライン環境でアップグレードが失敗する
- アップグレード中に SQL の検証が失敗する
- アップグレード後に snapshot-controller-crds ポッドが CrashLoopBackOff ステートになる
- Insights の PVC サイズが上書きされたためにアップグレードが失敗する
- 管理ポータルのタイムアウト期間を設定する
- 移行後に認証が機能しない
- 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 へのログインに失敗した
- 基になるディレクトリ接続を更新する
- Process Mining で高可用性を実行する
- Kerberos を使用してログインすると、Process Mining を取り込むことができなかった
- 障害復旧後、Dapr が Process Mining に対して正しく機能しない
- pyodbc 形式の接続文字列を使用して AutomationSuite_ProcessMining_Warehouse データベースに接続できない
- Airflow のインストールが「sqlalchemy.exc.ArgumentError: Could not parse rfc1738 URL from string ''」で失敗する
- SQL Server ポート 1433 を使用する IP テーブル ルールを追加する方法
- CData Sync を実行しているサーバーの Automation Suite の証明書が信頼されない
- Task Mining のトラブルシューティング
- 診断ツールを実行する
- Automation Suite サポート バンドルを使用する
- ログを確認する

Linux の Automation Suite のインストール ガイド
Q&A: デプロイ テンプレート
Q: マルチノードの高可用性対応運用環境プロファイルでは、完全な製品選択のプロセッサ要件は 96 (v-)CPU/コアですが、この要件にはサーバー ノードとエージェント ノードも含まれますか? それともサーバー ノードまたはエージェント ノードのどちらかを指していますか?
A: UiPath のドキュメントには、マルチノードの高可用性対応運用環境プロファイルでは、ノードあたりの最小 CPU/RAM を搭載したサーバー ノードが少なくとも 3 つ必要であると記載されています。この条件が満たされている限り、残りの CPU/RAM 要件は、同じく最小 CPU/RAM の要件を満たす追加のサーバー ノードまたはエージェント ノードのいずれかに分散できます。
Q: Task Mining には GPU が必要ですか?
A: いいえ、Task Mining に GPU は必要ありません。
Q: UiPath® Automation Suite Install Sizing Calculator (インストール サイジング計算ツール) のノードのフォールト トレランスとは何を指していますか? エージェント ノード、サーバー ノードのみ、またはその両方が対象ですか?
A: UiPath® Automation Suite Install Sizing Calculator (インストール サイジング計算ツール) の推奨事項はフォールト トレランスに基づいており、最悪のシナリオにおいても常に 3 つ以上のサーバー ノードが利用可能になっています。サーバーの数を増やすことで、サーバーがダウンしてもデプロイが失敗しないようにすることができます。
Q: Amazon Route 53 でプライベート ドメインを使用できますか?
A: はい、プライベート ホスト ゾーンがサポートされています。
Q: クラウド ソリューション (AWS など) でも DNS レコードを指定する必要がありますか? オンプレミスの DNS ソリューションを Automation Suite の AWS デプロイで使用できますか? たとえば、エンドユーザーがアクセスする URL の場合、クラウドまたはオンプレミスのどちらの DNS でレコードを解決できる必要がありますか?
A: Amazon Route 53 以外の DNS インフラストラクチャを使用できます。ただし、デプロイを実行する VPC で DNS が解決可能である必要があります。
Q: Kubernetes の一部として使用されているのは、どの CNI プラグインですか? たとえば、ベンダー提供である場合、Kubernetes ソリューションは VPC/VNET との連携をサポートします。AWS Kubernetes を使用する場合、ベンダーがワークロードを作成してデプロイすると常に、ポッドは IP アドレスを VPC 自体から取得します。つまり、AWS または Azure のサービスがワークロードにアクセスできます。
A: Cilium CNI を使用しています。Kubernetes ディストリビューションには、サポート対象の CNI が 3 つ付属していますが、AWS 固有の CNI ではありません。
Q: サービス IP とポッド IP の範囲はカスタマイズされていますか?
10.42.0.0/16
です。
Q: Automation Suite を AWS の既存の VPC にデプロイする場合、CloudFormation の代わりに TerraForm を使用できますか?
A: いいえ、できません。UiPath では、クラウド プロバイダーのネイティブの Infrastructure as Code ツールを使用しています (AWS の場合は CloudFormation、Azure の場合は ARM)。
Q: 前の質問に関して、IaC の標準が Terraform である場合、Terraform のコードを開発する必要があるのですか?
A: Automation Suite を手動でデプロイする (既存の AWS テンプレートや Azure テンプレートを使用しない) 場合は、ご質問のとおり、Terraform のコードを開発する必要があります。または、既存の CloudFormation テンプレートをデプロイに使用するか、Terraform コードの作成を支援するベースとして使用できます。
Q: Task Mining で必要な特殊なノードの数はどのように推定できますか?
A: Task Mining では、既定で専用ノードが 1 つ必要で、サポートされています。
Q: Graviton ベースのプロセスをデプロイに使用できますか?
A: いいえ、Kubernetes ディストリビューションは ARM をサポートしていません。
Q: Automation Suite は AMD でホストできますか? それとも Intel プロセッサでのみホストできますか?
A: アーキテクチャ要件を満たしている限り、どちらでも問題ありません。
Q: Automation Suite のテンプレートを Ubuntu や CentOS にデプロイできますか?
A: いいえ、Ubuntu と CentOS はサポートされていません。
Q: AWS のデプロイで EFS が自動的にデプロイされる場合、どの程度の領域が予約されますか?
A: EFS には、事前プロビジョニングされたサイズはありません。従量課金制です。EFS は、クラスター全体にわたる全ディスクの全バックアップを保持します。つまり、6 TiB のデータを使用します。これは、すべてのノードのストレージ データ ディスク領域の合計です。
Q: Azure のデプロイでは、AWS と同じように NFS ソリューションがデプロイされますか? その場合、どの程度の領域が予約されますか?
A: NFS は、複数の実装方法が可能なプロトコルです。AWS Elastic File System はそのような実装の 1 つです。NFS サーバーは別の実装です。Azure には、Azure Files という別の実装があります。バックアップを作成する場合は、これらのインフラストラクチャ要素のいずれかが必要です。
Q: 推奨クラウド サービス プロバイダーは、Azure、AWS のどちらですか?
A: 推奨クラウド サービス プロバイダーはありません。どちらもサポートされています。
Q: 自動スケーリングを有効化する場合、ノードではカスタマイズされたイメージが必要ですか?
A: 自動スケーリングではお使いの RedHat イメージが使用され、その上に UiPath® ソフトウェアがインストールされます。今のところはっきりしたデータはありませんが、コールド スタートは 5 分から 10 分の範囲内です。
Q: Microsoft SQL Server の Standard Edition を使用できますか?
A: Microsoft SQL Server 2016、2017、2019 の Standard および Enterprise エディションがサポートされています。SQL の要件の詳細については、こちらのドキュメントをご覧ください。
Q: 合計 vCPU 数の要件である 96 コアは最初から必要ですか? それともこの要件は自動スケーリングの一部になっていて、ノードはリソースの必要性に応じて追加または削除されますか?
A: システムの電源をオンにするには 96 コアが必要です。その後は、さまざまなスケーリング方法を使用できます。ただし、この数を下回らないようにする必要があります。
Q: RHEL イメージは自分で選択するのですか? それとも AWS または Azure のテンプレートで指定されているのですか? 自分でテンプレートを選択する必要がある場合は、テンプレートを介してデプロイする際にどの RHEL バージョンを使用すればよいですか?
A: デプロイでは、基本的な RHEL イメージ (実行時に決定) を使用して Auto Scaling グループ テンプレートを作成し、これを仮想マシンのプロビジョニング時に適用します。つまり、すべてのソフトウェアは新しい EC2 インスタンスの作成時にインストールされます。テンプレートでは、現在 RHEL 8.2 が使用されています。
Q: Kubernetes クラスター用以外の仮想マシンは必要ですか?
A: Automation Suite を実行するために、クラスター外に追加の仮想マシンは不要です。ただし、UiPath Robot を実行するための既存のマシンがない場合は、UiPath® Studio (IDE) 用の開発者用仮想マシンまたはデスクトップのほかに、そのためのマシンが必要になる可能性があります。
Q: CloudWatch または Azure Monitor と連携して Kubernetes ログを記録できるようにする予定はありますか?
A: 現在のところ、CloudWatch にログをプッシュするための連携はありません。
Q: Automation Suite で MySQL や PostgreSQL などのオープンソース データベース ソリューションを使用できますか?
A: Microsoft SQL Server の要件は、Automation Suite がデプロイされるクラウドとは無関係です。