- 概要
- 要件
- インストール
- Q&A: デプロイ テンプレート
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベストプラクティスとメンテナンス
- トラブルシューティング
- インストール時にサービスをトラブルシューティングする方法
- クラスターをアンインストールする方法
- オフライン成果物をクリーンアップしてディスク領域を改善する方法
- Redis データをクリアする方法
- Istio ログを有効化する方法
- ログを手動でクリーンアップする方法
- sf-logs バンドルに保存されている古いログをクリーンアップする方法
- AI Center のストリーミング ログを無効化する方法
- 失敗した Automation Suite インストールをデバッグする方法
- アップグレード後に古いインストーラーからイメージを削除する方法
- Longhorn スナップショットを自動的にクリーンアップする方法
- NIC チェックサムオフロードを無効にする方法
- RHEL 8.4 OS でオフライン インストールを実行できない
- バンドルのダウンロード中のエラー
- バイナリがないため、オフライン インストールが失敗する
- オフライン インストールでの証明書の問題
- Longhorn のセットアップ中に最初のインストールが失敗する
- SQL 接続文字列の検証エラー
- selinux iscsid モジュールの前提条件の確認が失敗する
- Azure ディスクが SSD としてマークされない
- 証明書の更新後のエラー
- OS のアップグレード後に Automation Suite が動作しない
- Automation Suite で Backlog_wait_time を 1 に設定する必要がある
- ワークロードの準備ができていないためボリュームをマウントできない
- インストールおよびアップグレード中に RKE2 が失敗する
- 管理ポータルのタイムアウト期間を設定する
- 基になるディレクトリ接続を更新する
- 移行後にログインできない
- 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).
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- Login Failed for User <ADDOMAIN><aduser>.Reason: The Account Is Disabled.
- ArgoCD へのログインに失敗した
- サンドボックス イメージを取得できない
- ポッドが ArgoCD UI に表示されない
- Redis プローブの障害
- RKE2 サーバーの起動に失敗する
- UiPath 名前空間でシークレットが見つからない
- 初期インストール後、ArgoCD アプリが Progressing ステートになる
- MongoDB ポッドが CrashLoopBackOff になるか、削除後に PVC プロビジョニングの保留中になる
- Unexpected inconsistency; run fsck manually
- クラスターの復元後に MongoDB またはビジネス アプリケーションの機能が低下する
- self-heal-operator および sf-k8-utils リポジトリが見つからない
- クラスターの復元またはロールバック後にサービスが異常になる
- RabbitMQ ポッドが CrashLoopBackOff でスタックする
- Prometheus が CrashloopBackoff ステートでメモリ不足 (OOM) エラーを伴う
- 監視ダッシュボードに Ceph-rook メトリックが表示されない
- Automation Suite 診断ツールを使用する
- 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 つ以上のサーバー ノードが利用可能になっています。サーバーが 1 つダウンしても、デプロイは存続できます。
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 がデプロイされるクラウドとは無関係です。
