ハードウェアおよびソフトウェアの要件

Automation Suite のデプロイに必要なハードウェアおよびソフトウェアの要件。ノードの仕様、製品の選択、クラスターのサイズ設定を網羅しています。

用語

Automation Suite のデプロイで使用される主要な概念について詳しくは、「 用語集」をご覧ください。

製品選択

既定のインストール エクスペリエンスでは、インストールする製品群を 2 つの選択肢から選びます。

• 完全 (すべての製品) - Automation Suite で利用可能なすべての製品のリストをインストールします。詳しくは、「 Automation Suite 製品」をご覧ください。

• 製品を選択 - 関心のある製品のみを選択してインストールできます。ただし、インストーラーでは製品間の依存関係が考慮されます。つまり、製品に別の製品のインストールが必要な場合は、両方をインストールする必要があります。詳しくは、「 Automation Suite 製品」をご覧ください。

  注:

  同じデプロイで後からいつでも、初回インストール後に追加の製品を有効化でき、再インストールする必要はありません。詳しくは、「 製品を管理する」をご覧ください。

  製品を追加する前に、予想される使用量に基づいてハードウェア要件を検証し、デプロイに十分な容量があることを確認することをお勧めします。詳しくは、「 要件算出ツール」をご覧ください。

デプロイ プロファイルを選択する

Automation Suite は、シングルノード、ライト モード、またはマルチノードの高可用性対応の運用環境モードでデプロイできます。プロファイルの前提条件のほとんどは同じですが、マルチノードの高可用性対応の運用モードには追加のリソースが必要です。

デプロイが完了した後は、通常、デプロイ プロファイルの変更は制限されます。ただし、シングルノード デプロイはマルチノードの高可用性 (HA) デプロイに拡張でき、ライト デプロイはマルチノードの高可用性対応デプロイに拡張できます。デプロイ プロファイルを選択する前に、「 デプロイ モードとユース ケース」をご覧ください。

重要:

選択するデプロイ プロファイルに関係なく、Linux と Kubernetes の知識が必要です。Automation Suite のインストールと構成で問題が発生した場合は、UiPath® プロフェッショナル サービスにお問い合わせください。

前提条件の一覧

前提条件の種類	前提条件
ハードウェア	シングルノード デプロイの場合は 1 台以上のマシン。この構成は、評価シナリオとデモ シナリオでのみサポートされ、運用環境のデプロイではサポートされません。 マルチノード デプロイの場合は 3 台以上のマシン。これは、運用環境のデプロイでサポートされる唯一の構成です。 インストールで発生する可能性のある問題を回避するには、デプロイで使用するすべてのノードが同じタイム ゾーンに設定されていることを確認します。
	一般的なマシン要件 詳しくはこちらをご覧ください。
	以下の製品に固有の要件: Automation Suite ロボット AI Center AI Computer Vision Document Understanding 詳しくはこちらをご覧ください。
	サポートされている RHEL バージョンと、すべての Linux マシンに ipcalc ツールがインストールされていること。RHEL と以前のバージョンの Automation Suite との相互運用性について詳しくは、「 RHEL 相互運用性マトリクス 」をご覧ください。 RHEL の新しいマイナー バージョンは、リリースから 90 日以内にサポートされます。 既定のポリシーの SELinux がサポートされています。 *
	FIPS 140-2 詳しくはこちらをご覧ください。
	ロード バランサー L4/ネットワーク ロード バランサー 詳しくはこちらをご覧ください。
	NFS サーバーの要件 (Linux ベースの NFSv3/NFSv4 バージョンを使用するオンプレミスまたはクラウドで管理される NFS サーバー) CPU - 4 vCPU RAM - 8ギガバイト ストレージ - 1 TB 外部 ObjectStore の場合、数 GB が必要です クラスター内の ObjectStore の場合、最小値は ObjectStore のサイズと同じである必要があります 詳しくはこちらをご覧ください。
	ノード ポート 詳しくはこちらをご覧ください。
ソフトウェア	各マシンの RPM パッケージ 詳しくはこちらをご覧ください。
	SQL Server 詳しくはこちらをご覧ください。
	ObjectStore (Azure Blob ストレージ、AWS S3、S3 互換 ObjectStore) 詳しくはこちらをご覧ください。
	OCI 準拠のレジストリ 詳しくはこちらをご覧ください。
	DNS 詳しくはこちらをご覧ください。
	TLS 1.2 以降
	IPv4、IPv6、およびデュアルスタック 詳しくはこちらをご覧ください。
	スワップメモリが無効化されていること。
	TLS 証明書 ID トークン署名証明書 (認証/ベアラー トークンに署名するための証明書) 外部コンポーネント (SQL Server、ObjectStore、レジストリ、SMTP など) 用の追加の CA 証明書

^*エアギャップ インストールの場合、 rke2-selinux パッケージは自動的にはインストールされません。SELinux 関連の問題が発生した場合は、SELinux ポリシー パッケージを手動でインストールする必要があります。詳しくは、「 使い方 」セクションをご覧ください。

重要:

• Automation Suite をインストールしてデプロイするには、root 権限が必要です。ルートアクセスを必要とする特定のコンポーネントの詳細については、 ルート権限の要件を参照してください。
• Cilium が正常に機能するには、CAP_SYS_ADMIN 権限が必要です。これらの権限が付与されていることを確認してください。
• お使いのシステムでスキャン エージェントが実行されている場合、スキャン エージェントによって IP テーブルが変更されるために、インストールまたはランタイムが失敗する可能性があります。この問題を回避するには、スキャン エージェントを構成して、Automation Suite のインストールに干渉しないようにします。
• UiPath® は、Automation Suite の要件を満たしている限り、特定のファイアウォールや開発者ツールの構成を指示しません。UiPath の見解では、外部ツールの数が限られていても、Automation Suite のスムーズな操作が妨げられる可能性があります。このような問題が発生した場合は、関連するベンダーにお問い合わせください。追加の指針については、「 責任のマトリクス」をご覧ください。

ハードウェア要件

開始する前に、以下のことを考慮に入れておいてください。

• Automation Suite は、Federal Information Processing Standard 140-2 (FIPS 140-2) をサポートしています。Automation Suite のクリーン インストールは、FIPS 140-2 が有効化されたホスト上で実行できます。以前に Automation Suite のインストールを実行したマシンで FIPS 140-2 を有効化することもできます。詳しくは、「 セキュリティとコンプライアンス」をご覧ください。

  注:

  Insights は、FIPS が有効化されたホストでは現在サポートされていません。FIPS が有効化されたホストに Automation Suite をインストールする場合は、必ず Insights を無効化してください。

• 最小のハードウェア要件では、ノードの障害からデプロイを保護できません。

• マルチノードの HA 対応の運用プロファイルは、1 つのノードの障害に対してのみ回復性があります。つまり、失うことができるサーバー ノードは 1 つだけです。この制限は、エージェント ノードには適用されません。クラスター全体の容量が十分に利用可能な限り、エージェント ノードをいくら失っても、ダウンタイムなしでクラスターを使用し続けることができます。

• 「高度なインストール」の手順に従って、サーバー ノードの障害許容度を向上できます。

次のセクションでは、完全な製品選択と個々の製品の両方のハードウェア要件を示します。

完全な製品選択: ハードウェア要件

次のセクションでは、完全な製品選択のハードウェア要件について説明します。

一般的な要件

すべての製品で使用するハードウェア	シングルノードの最小要件	マルチノードの最小要件
クラスターあたりのプロセッサ数	32 (v-)CPU/コア	96 (v-)CPU/コア
ノードあたりの最小プロセッサー数	N/A	8 (v-)CPU/コア
RAM	64GB	192ギガバイト
ノードあたりの最小 RAM	N/A	16 GB
クラスター ディスク*	256 GB SSD 最小 IOPS: 1100	256 GB SSD 最小 IOPS: 1100
データ ディスク サーバー ノードでのみ必要	512ギガバイトSSD 最小 IOPS: 1100	512ギガバイトSSD 最小 IOPS: 1100
etcd ディスク サーバー ノードでのみ必要	16ギガバイトSSD 最小 IOPS: 240	16ギガバイトSSD 最小 IOPS: 240
UiPath® バンドル ディスク 最初のサーバー ノードでのみ必要 オフラインの場合のみ必要 外部レジストリが使用できない場合にのみ必要	512ギガバイトSSD 最小 IOPS: 1100	512ギガバイトSSD 最小 IOPS: 1100
Object Store サーバー ノードでのみ必要 外部 Objectstore が使用できない場合にのみ必要	512ギガバイトSSD 最小 IOPS: 1100	512ギガバイトSSD 最小 IOPS: 1100
Ceph データのバックアップ用の追加ディスク領域 クラスター内のストレージを使用するシングルノードの RKE2 セットアップでのみ必要です。	512ギガバイトSSD 最小 IOPS: 1100	N/A
AI Center	51 GB 以上 1 つのトレーニング パイプラインにつき 105 GB を推奨	51 GB 以上 1 つのトレーニング パイプラインにつき 105 GB を推奨

• クラスター ディスクの容量には、以下の考慮事項が適用されます。
• AI Center の ML スキルやトレーニング用のストレージ要件に基づいて、クラスター ディスクの容量を増やす必要がある場合があります。
• Document Understanding モダン プロジェクトを有効化する場合、クラスターの最小ディスク容量は 512 GB です。

注:

Automation Suite をシングルノードの評価モードでインストールする場合に、32 個の (v-)CPU/コアと 64 GB の RAM を搭載したマシンがない場合は、8 個以上の CPU/コアと 16 GB の RAM を搭載したマシンを持ち込めます。詳しくは、「 要件算出ツール」をご覧ください。

このオプションを選択する場合は、マルチノードのインストールと構成の手順に従ってください。

可能な場合は外部 ObjectStore を使用することをお勧めします。ObjectStore をクラスターから独立してスケーリングできるので、安定性が向上します。次の ObjectStore オプションがサポートされています。

• Azure Storage アカウント
• AWS S3 のストレージ バケット
• S3 互換のストレージ バケット

個々の製品: ハードウェア要件

Automation Suite の個々の製品またはさまざまな製品の組み合わせをインストールするために満たす必要があるハードウェア要件の詳細については、Automation Suite Install Sizing Calculator (インストール サイジング計算ツール) を使用してください。

Automation Suite ロボットの追加要件

マルチノードの HA 対応の運用環境では、Automation Suite ロボットに追加のエージェント ノードが必要です。シングルノードの評価環境では、追加の Automation Suite ロボット ノードは任意です。

Automation Suite ロボット ノードのハードウェア要件は、リソースの使用方法によって異なります。追加のエージェント ノードの要件に加えて、 パッケージのキャッシュ を有効にするために 10 GB 以上のファイル ストレージも必要です。

次のセクションでは、Automation Suite ロボット ノードで必要なハードウェアの量に影響する要因について説明します。

ロボットのサイズ

次の表に、すべてのロボット サイズに必要な CPU、メモリ、およびストレージを示します。

Size	CPU	メモリ	ストレージ
小	0.5	1 GB	1 GB
標準	1	2 GB	2 GB
中	2	4 GB	4 GB
大	6	10 GB	10 GB

エージェント ノードのサイズ

Automation Suite ロボット エージェント ノードのリソースは、同時に実行できるジョブの数に影響します。その理由は、CPU コアの数と RAM の容量が、ジョブの CPU/メモリ要件で除算されるためです。

たとえば、16 CPU と 32 GB の RAM を搭載したノードは、次のいずれかを実行できます。

• 32 個の小型のジョブ
• 16 個の標準ジョブ
• 8 個の中型のジョブ
• 2 個の大型のジョブ

複数のジョブ サイズを混在できるため、特定の時点において、同じノードで次のようなジョブの組み合わせを実行できます。

• 10 個の小型のジョブ (5 CPU と 10 GB のメモリを消費)
• 4 個の標準ジョブ (4 CPU と 8 GB のメモリを消費)
• 3 個の中型のジョブ (6 CPU と 12 GB のメモリを消費)

Kubernetes のリソース消費量

ノードは Kubernetes クラスターに属しているため、サーバー上に存在する Kubernetes エージェント (kubelet) は少量のリソースを消費します。UiPath の測定結果によると、Kubelet が消費するリソースは以下のとおりです。

• 0.6 CPU
• 0.4 GB の RAM

前述のノードと同様のノードでは、実際の容量は約 15.4 CPU と 31.6 GB の RAM になります。

マシン サイズの自動選択

すべてのクロスプラットフォーム プロセスでは、[Automation Suite ロボット] のオプションが既定で [自動] に設定されています。この設定では、サーバーレス ロボットを使用してプロセスを実行するのに適したマシン サイズが選択されます。

サイズを自動的に選択すると、次の表に示す基準が順番に評価されます。1 つの基準が満たされるとすぐに、対応するマシン サイズが選択され、残りの基準は評価されません。

順序	基準	マシン サイズ
1	リモート デバッグのジョブである	中
2	プロセスが UI Automation に依存しているか、またはプロセスが UiPath Document Understanding アクティビティに依存している	標準
3	その他の無人プロセス	小

AI Center と Document Understanding の追加要件

完全なプラットフォーム要件の一部であるコア サービス要件に加えて、AI Center では、実行またはトレーニングするモデルに応じて追加のリソースが必要です。必要な GPU ハードウェア世代と互換性のある NVIDIA ドライバーについて詳しくは、「 相互運用性マトリクス」をご覧ください。

注:

AI Center でランタイムに必要なディスク ストレージには、ML スキルとトレーニング パイプラインでそれぞれ次のような条件があります。

• ML スキルには、予測用のトレーニング済みモデルを保存するための /var/lib/rancher パーティションにディスク容量が必要です。 最悪のシナリオでは、モデルのサイズが 20 GB にもなる可能性があります。
• トレーニング パイプラインは、モデルをホストするために /var/lib/rancher パーティションのストレージを消費します。 最悪のシナリオでは、モデルのサイズが 20 GB にもなり、さらにデータセット用のストレージが必要になることがあります。 データセット ストレージの最小サイズは 51 GB になることがあります。 推奨サイズは 105 GB です。 これは、AI Center の専用ディスク上にある必要があります。 トレーニング パイプラインは、専用の AI Center ディスクが接続されているノードでのみスケジュール設定されます。

次の表で、AI Center で必要となる追加リソースについて説明します。以下の表では、すべてのサーバー ノードにデータ ディスクが必要です。エージェント ノードにデータ ディスクは必要ありません。

使用	CPU	RAM (GB)	GPU	ディスク (GB)
サービング (ML スキル、1 つのレプリカ) の最小要件	0.6	2	0	rancher パーティションに 20 GB
トレーニング (パイプライン) の最小要件	1	4	0	rancher パーティションに 20 GB 最小 51 GB の AI Center ディスク パーティション (105 GB を推奨)
DU モデルのサービング (ML スキル、1 つのレプリカ)	1	4	0	rancher パーティションに 20 GB
DU モデルのトレーニング	2	24	強く推奨	rancher パーティションに 20 GB 最小 51 GB のデータ ディスク (105 GB を推奨)

注:

次の表で、AI Center の小規模および平均的な実装に必要なリソースについて説明します。これらの数は一般的な指針です。

以下の表では、すべてのサーバー ノードにデータ ディスクが必要です。エージェント ノードにデータ ディスクは必要ありません。

使用	CPU	RAM (GB)	GPU	ディスク (GB)
小規模な実装: 3 モデルのサービング 1 つの同時パイプライン	4	32	0	rancher パーティション 1 に 80 GB 105 データ ディスク 2
平均的な実装: 5 モデルのサービング 2 つの同時パイプライン DU モデルのトレーニング	8	52	強く推奨	rancherパーティションに 160 GB 3 315 データ ディスク 4

¹ (3 スキル + 1 パイプライン) * 20 GB ( rancher パーティション) = 80 GB ( rancher パーティション)

² 1 パイプライン * 105 GB = 105 データ ディスク

³ (5 スキル + 2 パイプライン + 1 DU パイプライン) * 20 GB ( rancher パーティション) = 160 GB ( rancher パーティション)

⁴ (2 パイプライン + 1 DU パイプライン) * 105 GB = 315 データ ディスク

AI Computer Vision の追加要件

この設定は、オンプレミスの Nvidia GPU で動作しますが、AWS、Azure、GCP などのクラウド プロバイダーでも動作します。推奨される GPU の種類には、十分な GPU メモリと処理能力を備えた RTX、Tesla、および Ampere ファミリの GPU が含まれます。

これら 2 種類の GPU の主な違いは、仮想化を使用した GPU には通常使用できる GPU RAM がより多く、ほとんどのクラウド プロバイダーによって提供されているという点です。GPU RAM を増やすと、モデルに入力できる画像の最大サイズが増加します。結論として、仮想化 GPU はコンシューマー向け GPU よりも大幅に高速というわけではありません。

以下のハードウェア仕様を満たすマシンが必要です。

ハードウェアの仕様	最小	推奨仕様
メモリ	8 GB	16 GB
CPU	AVX2 が有効化された 2 コア	AVX2 が有効化された 4 コア
GPU	8 GB VRAM	16 GB VRAM
ストレージ	30 GB の空き容量	—

Document Understanding の追加の推奨事項

パフォーマンスを向上させるには、GPU がサポートされた追加のエージェント ノードに Document Understanding をインストールできます。 ただし、Document Understanding の AI Center に基づくプロジェクトは、GPU ノードがなくても完全に機能します。 実際には、Document Understanding はすべての抽出および分類タスクに CPU 仮想マシンを使用しますが、OCR には GPU 仮想マシンを使用することを強くお勧めします。

Document Understanding フレームワーク内での CPU/GPU の使用について詳しくは、「 CPU と GPU の使用」をご覧ください。

GPU サポートのある追加のノードを使用する場合、次の要件を満たす必要があります。

ハードウェア	最小要件
プロセッサ	AVX2をサポートする8(v-)CPU/コア
RAM	52ギガバイト
OS ディスク	256 GB SSD 最小 IOPS: 1100
データ ディスク	N/A
GPU RAM	11ギガバイト

詳しくは、「 AI Center に関する考慮事項」セクションをご覧ください。

Document Understanding モダン プロジェクトの追加要件

CPU 推論をアクティブ化した場合は、2 つ以上の GPU が必要です。CPU 推論を有効化するには、「Document Understanding を有効化または無効化する」セクションに示すように、[enable_cpu_inference] プロパティを [true] に設定します。

注:

• 推論は最大 10 倍遅くなる可能性があります。
• 最大 125 ページのドキュメントに使用することをお勧めします。有効な制限はありません。ただし、125 ページを超えるドキュメントでは推論が失敗する可能性があります。

CPU 推論がない場合、Document Understanding モダン プロジェクトには 5 つ以上の GPU が必要です。次の表のシナリオ例は、5 GPU で 300 ページを処理する方法を示しています。

注:

Document Understanding モダン プロジェクトで推奨される最小 GPU は NVIDIA T4 です。

次の表に、GPU ノードごとにサポートされる容量関数と操作数を示します。

機能	Number
1 時間あたりに処理されるカスタム モデルのページ数	300
すぐに使えるモデルの 1 時間あたりに処理されるページ数	0
並列でトレーニングするモデルのトレーニング	1
すべてのプロジェクトのページ数 - 設計時	200
プロジェクト バージョンごとのドキュメントの種類の数	3

5 つの GPU は、次の表に示すように、さまざまな機能に分散されています。

サービス	GPU の数
OCR レプリカ	1
カスタム モデルのトレーニング レプリカ	1
カスタム モデルのレプリカ	2
すぐに使えるモデルのレプリカ	1
合計	5

各サービスに GPU を割り当てる方法について詳しくは、「 Document Understanding モダン プロジェクトに GPU リソースを割り当てる 」をご覧ください。

GPU の需要に加えて、Document Understanding モダン プロジェクトでは、最適なパフォーマンスを得るために特定の CPU リソースも必要です。最適なパフォーマンスを得るには、 18 個以上の vCPU が必要です。

最新の Document Understanding プロジェクトでは、提供されている例のアクティビティを 1 年間継続して実行するために、追加で 4 TB の objectstore が必要です。 より小さい数から始めることができますが、明示的に拡大縮小しない限り、ストレージが完了するとアクティビティは失敗します。

1 年間の継続的処理のためにプロビジョニングする場合、Document Understanding モダン プロジェクトに 4 TB、その他の製品に 512 GB が必要です。 合計で 4.5 TB のストレージになります。 同様に、6 か月の処理から開始する場合、Document Understanding モダン プロジェクトには 2 TB、その他の製品には 512 GB が必要です。 この場合、合計は 2.5 TB になります。

注:

詳細な計算方法とニーズに必要な容量については、 UiPath Automation Suite Install Sizing Calculator (インストール サイジング計算ツール) をご覧ください。

MIG 対応 GPU のプロビジョニング

Automation Suite の Document Understanding ワークロードは、NVIDIA MIG (マルチインスタンス GPU) テクノロジで作成された仮想 GPU (VGPU) での実行をサポートします。

これらの条件で Document Understanding を実行するには、次の要件に注意してください。

• GPU メモリ (VRAM): VGPU あたり少なくとも 16 GB。UiPath でサポートされているのは 単一のストラテジのみです。つまり、すべての VGPU はまったく同じになります。
• ストレージ:VGPUあたり80GB以上

Kubernetes で MIG 対応 GPU を有効化する

上記の最小要件と一致するか超えるプロファイルを持つ MIG 対応 GPU をクラスターにプロビジョニングしたら、GPU がスケジュール可能な Kubernetes であることを確認します。ノードは、ワークロードをスケジュールする前に、ゼロ以外の数の GPU を報告する必要があります。

GPU をスケジュール可能にするには、 デバイス プラグインのインストールに関する公式ドキュメントに従ってください。

または、デバイス プラグインを GPU ノードに手動で適用して開始することもできます。

migEnabledPoolName を GPU ノードと同じラベルに置き換えて、次の構成を適用します。

apiVersion: v1
kind: Pod
metadata:
  name: nvidia-device-plugin-pod
  namespace: gpu-resources
spec:
 affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: agentpool
            operator: In
            values:
            # To be changed to a selector that matches the GPU nodes
            - migEnabledPoolName
 containers:
 - args:
   - --fail-on-init-error=false
   env:
   - name: MPS_ROOT
     value: /run/nvidia/mps
   - name: MIG_STRATEGY
      # We only support the single strategy for now
     value: single
   - name: NVIDIA_MIG_MONITOR_DEVICES
     value: all
   - name: NVIDIA_VISIBLE_DEVICES
     value: all
   - name: NVIDIA_DRIVER_CAPABILITIES
     value: compute,utility
   image: nvcr.io/nvidia/k8s-device-plugin:v0.17.3
   imagePullPolicy: IfNotPresent
   name: nvidia-device-plugin-ctr
   securityContext:
     allowPrivilegeEscalation: true
     capabilities:
       add:
       - SYS_ADMIN
   terminationMessagePath: /dev/termination-log
   terminationMessagePolicy: File
   volumeMounts:
   - mountPath: /var/lib/kubelet/device-plugins
     name: device-plugin
 tolerations:
 - key: CriticalAddonsOnly
   operator: Exists
 - effect: NoSchedule
   key: nvidia.com/gpu
   operator: Exists
 terminationGracePeriodSeconds: 30
 volumes:
 - hostPath:
     path: /var/lib/kubelet/device-plugins
     type: ""
   name: device-plugin

プラグインをデプロイすると、ノードの [Allocatable ] セクションに、構成した MIG プロファイルに基づいて nvidia.com/gpuに VGPU の正しい数が表示されます。これで、ノードがスケジュール可能になり、Document Understanding ワークロードを実行する準備が整います。

RPM パッケージの要件

Automation Suite のインストールを開始する前に、以下の要件を満たしていることを確認する必要があります。

• RHEL サブスクリプションを持っている
• BaseOS リポジトリと AppStream リポジトリを有効化している
• 必要な RPM パッケージをインストールしている

以下の表に、必要な RPM パッケージのリストを示します。

RPM パッケージ	説明
iscsi-initiator-utils nfs-utils rpcbind util-linux nmap-ncat openssl httpd-tools gettext zstd	インストールのためにノードに必要です。
podman>=4.0.2 nmap-ncat bind-utils openssl wget unzip conmon=>2.0.24	準備状況の確認を実行するためにノードに必要です。
iscsi-initiator-utils gettext nfs-utils rpcbind util-linux nmap-ncat openssl httpd-tools podman=>4.0.2 zstd	オフライン インストールでのみ必要です。

注:

RHEL 8.4 以降では、必要な RPM パッケージが BaseOS リポジトリと AppStream リポジトリに既定で格納されています。

手動インストール

Automation Suite を手動でクリーン インストールする場合は、RPM パッケージの要件を満たしていることをユーザーが確認する必要があります。この場合、必要な RPM パッケージのインストールはユーザーの責任です。

以前のバージョンの Automation Suite からアップグレードする場合、RPM パッケージはインストール済みです。

RPM パッケージをインストールおよび検証するために使用できるツールについて詳しくは、「 必要な RPM パッケージを検証してインストールする」をご覧ください。

クラウド テンプレート

Azure、AWS、または GCP のテンプレートを使用して Automation Suite をインストールする場合、ユーザー側での操作は不要です。RPM パッケージを含む完全なインフラストラクチャがテンプレートによってプロビジョニングされます。

Microsoft SQL Server の一般的な要件

注:

専用の「要件」セクションで特に指定がない限り、これらの要件はすべての Automation Suite 製品に適用されます。

重要:

• Automation Suite バージョン 2.2510.0 以降は、SQL バージョン 2019 以降に対応しています。
• Process Mining のインストールを有効化する場合、Automation Suite には PostgreSQL データベースを使用する必要があります AutomationSuite_Airflow。詳しくは 、「Process Mining の SQL の要件 」をご覧ください。

Microsoft SQL Server データベース エンジンが要件を満たしている限り、追加の Microsoft SQL プラットフォーム (Azure SQL Database や Azure SQL Managed Instance など) および Amazon Relational Database Service もサポートされます。

注:

SQL Server が各クラスター VM からアクセスできることを確認します。

重要:

個々の製品サポートの内容は異なります。

デプロイを計画している各製品について、以下のことが必要です。

• 製品で必要とされる SQL Server のサポート対象バージョンを確認します
• 製品で必要とされる SQL Server 構成の前提条件 (SQL Server ユーザー権限を含む) を適用する 製品固有の SQL Server の要件について詳しくは、「 Microsoft SQL Server を構成する」をご覧ください。

Microsoft SQL Server の一般的な最小ハードウェア要件は次のとおりです。

• 8 (v-)CPU
• 32 GB の RAM
• 256 GB SSD

ここに示す最小要件は一般的な指針であり、運用環境のデプロイにおいて信頼できる動作を保証するものではありません。信頼性のある動作に求められるハードウェア要件を決定するには、要件算出が必要です。

デプロイする予定の各製品について、計画されている使用状況を評価し、製品の指定に従って要件算出の指針を適用する必要があります。この情報は、各製品のヘルプ セクションにあります。

NFS サーバーの一般的な要件

バックアップを有効化するには、外部 NFS サーバーが必要です。 Automation Suite は、Linux ベースのオンプレミスまたはクラウドで管理される NFS サーバー (バージョン NFSv3/NFSv4) をサポートしています。

重要:

NFS サーバーは運用環境で使用可能であり、アクティブに保守されている必要があります。非運用環境またはサポートされていない NFS サーバーを使用すると、そのサーバーに依存するすべてのサービスでダウンタイムが発生する可能性があり、データの損失やデータの破損につながる可能性があります。

注:

NFS サーバーが各クラスター VM からアクセスできることを確認します。

NFS サーバーの一般的な最小ハードウェア要件は次のとおりです。

• CPU - 4 vCPU
• RAM - 8ギガバイト
• ストレージ - 1 TB
  注:

  外部 ObjectStore を使用する場合、必要なストレージ容量は数 GB です。クラスター内 ObjectStore を使用する場合、最小ストレージ サイズは ObjectStore のサイズと同じになります。

Disaster Recovery - アクティブ/パッシブの要件

アクティブ/パッシブ デプロイを構成するには、次の要件を満たしていることを確認してください。

• ハードウェア
• ロード バランサー
• DNS
• 証明書
• Object Store
• Traffic Manager

ハードウェア

両方の Automation Suite クラスターがソフトウェアおよびハードウェアの一連の要件を満たす必要があります。詳しくは、 マルチノード モードのハードウェア要件をご覧ください。

ロード バランサー

両方の Automation Suite クラスターにロード バランサーが必要です。詳しくは、「 ロード バランサーを構成する」をご覧ください。

DNS

DNS の要件について詳しくは、「 DNS を構成する」をご覧ください。

証明書

証明書の要件について詳しくは、「 証明書の要件」をご覧ください。

DNS を開いた場合は、証明書に SAN も追加する必要があります。

Object Store

Automation Suite をマルチサイトにデプロイする際、クラスター内の ObjectStore はサポートされません。代わりに、外部 ObjectStore を使用する必要があります。

RHEL 相互運用性マトリクス

重要:

Automation Suite は RHEL での RKE2 サポートに Rancher を使用しているため、公式には以下の RHEL バージョンのみがサポートされます。同じメジャー ライン (8.x または 9.x) 内の記載されていないバージョンがインストールされて実行されることはできますが、問題が発生した場合の UiPath のサポートを保証できません。完全なサポートを受けるには、記載されている RHEL バージョンにのみデプロイしてください。

以下の表に、Automation Suite の各バージョンでサポートされている RHEL のバージョンを示します。

Automation Suite バージョン	RHEL のサポート対象バージョン
2.2510.4	9.7, 9.8, 10.0, 10.2
2.2510.3	8.8, 8.9, 8.10, 9.2, 9.4, 9.5, 9.6, 9.7, 10.0
2.2510.2	8.8, 8.9, 8.10, 9.2, 9.4, 9.5, 9.6, 9.7, 10.0
2.2510.1	8.8, 8.9, 8.10, 9.2, 9.4, 9.5, 9.6, 9.7
2.2510.0	8.8, 8.9, 8.10, 9.2, 9.4, 9.5, 9.6, 9.7

重要:

Automation Suite 2.2510.2 以降では、ホスト ノードでは cgroup v2 が実行する必要があります。cgroup v1 (RHEL 8.x のデフォルト) を使用している環境では、アップグレード前に cgroup v2 に移行する必要があります。移行手順については、「 cgroup v2 に移行する方法」を参照してください。

この要件は、 fail-cgroup-v1 kubelet フラグを使用して適用されます。このフラグは今後の RKE2 バージョンで非推奨になる予定です。2.2510.2 へのアップグレードの前後で、できるだけ早く cgroup v2 にアップグレードすることをお勧めします。

重要:

RHEL カーネル バージョンkernel-4.18.0-477.10.1.el8_8 は、Automation Suite クラスターのインストールまたは管理を中断させる 問題 の影響を受けます。どの Automation Suite ノードも、インストール前またはインストール後にこのバージョンのカーネルを使用していないことを確認してください。

RHEL 10 に関する考慮事項

重要:

RHEL 10.1 はサポートされていません。RHEL 10.1 で、データベース ファイルの保存速度が大幅に低下し、RKE サービスがクラッシュするパフォーマンスの問題が特定されました。

RHEL 10 を使用する場合は、以下の点を考慮してください。

• RHEL 10 には、ポート 9090 でリッスンするコックピット Web コンソールが既定でインストールされています。これは、Automation Suite で使用される Cilium と競合します。この競合を解決するには、 別のポートでリッスンするようにコックピット Web コンソールを構成するか、次のコマンドを使用して無効にします。

  systemctl disable --now cockpit.socket
  systemctl daemon-reload
  

• GPU カーネルモジュールは、デフォルトで RHEL 10 リポジトリに含まれなくなりました。GPU ドライバーをインストールするには、以下を実行してパッケージを個別にインストールします dnf install cuda-drivers。kernel-devel および kernel-headers GPU パッケージをカーネル バージョン 2 でテスト済み6.12.0-55.43.1.el10_0.