- 概要
- 要件
- 推奨: デプロイ テンプレート
- 手動: インストールを準備する
- 手動: インストールを準備する
- 手順 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のバージョンを確認する方法
- RHEL 8.4 OS でオフライン インストールを実行できない
- バンドルのダウンロード中のエラー
- バイナリがないため、オフライン インストールが失敗する
- オフライン インストールでの証明書の問題
- SQL 接続文字列の検証エラー
- selinux iscsid モジュールの前提条件の確認が失敗する
- Azure ディスクが SSD としてマークされない
- 証明書の更新後のエラー
- ウイルス対策が原因でインストールの問題が発生する
- OS のアップグレード後に Automation Suite が動作しない
- Automation Suite で backlog_wait_time を 0 に設定する必要がある
- ワークロードの準備ができていないためボリュームをマウントできない
- サポート バンドルのログ収集の失敗
- シングルノードのアップグレードがファブリック ステージで失敗する
- Ceph の異常によりアップグレードが失敗する
- 領域の問題のために rke2 が開始しない
- ボリュームがマウントできず、アタッチ/デタッチ ループ状態のまま
- Orchestrator データベース内のクラシック オブジェクトが原因でアップグレードが失敗する
- Ceph クラスターがサイドバイサイド アップグレード後に機能低下ステートで検出される
- 異常な Insights コンポーネントが原因で移行が失敗する
- Apps のサービス アップグレードの失敗
- インプレース アップグレードのタイムアウト
- Docker レジストリの移行が PVC の削除段階でスタックする
- v2023.10 以降へのアップグレード後に AI Center のプロビジョニングが失敗する
- オフライン環境でアップグレードが失敗する
- アップグレード中に SQL の検証が失敗する
- アップグレード後に snapshot-controller-crds ポッドが CrashLoopBackOff ステートになる
- 管理ポータルのタイムアウト期間を設定する
- 移行後に認証が機能しない
- 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 と Task Mining で正しく機能しない
- pyodbc 形式の接続文字列を使用して AutomationSuite_ProcessMining_Warehouse データベースに接続できない
- Airflow のインストールが「sqlalchemy.exc.ArgumentError: Could not parse rfc1738 URL from string ''」で失敗する
- SQL Server ポート 1433 を使用する IP テーブル ルールを追加する方法
- CData Sync を実行しているサーバーの Automation Suite の証明書が信頼されない
- 診断ツールを実行する
- Automation Suite サポート バンドルを使用する
- ログを確認する
ハードウェアおよびソフトウェアの要件
Automation Suite のデプロイで使用される主要な概念の詳細については、「用語集」をご覧ください。
既定のインストール エクスペリエンスでは、インストールする製品群を 2 つの選択肢から選びます。
- Complete (All products) – Automation Suite で利用可能なすべての製品をインストールします。詳しくは、「Automation Suite 製品」をご覧ください。
-
Select products – 関心のある製品のみを選択してインストールできます。ただし、インストーラーによって製品間の依存関係が考慮されます。つまり、ある製品を使うために別の製品をインストールする必要がある場合は、その製品を両方ともインストールする必要があります。詳しくは、「製品間の依存関係」をご覧ください。
Automation Suite を シングルノードの評価モード、ライト モード、 または マルチノードの HA 対応の運用 モードでデプロイできます。 プロファイルの前提条件はほぼ同じですが、マルチノードの HA 対応の運用モードでは追加のリソースが必要です。
デプロイが開始されると、あるデプロイ プロファイルから別のデプロイ プロファイルに切り替えたり、アップグレードすることはできません。ただし、ライト モードからマルチノードの HA 対応に切り替えたり、その逆を行ったりすることはできません。 デプロイ プロファイルを選択する前に、「 サポートされるプロファイルのユース ケース」をご覧ください。
前提条件の種類 |
前提条件 |
---|---|
ハードウェア |
|
一般的なマシン要件 | |
以下の製品に固有の要件:
| |
サポート対象の RHEL バージョンと、すべての Linux マシンにインストールされている ipcalc ツール。RHEL と以前のバージョンの Automation Suite との互換性について詳しくは、「 RHEL 相互運用性マトリクス」をご覧ください。 注:
RHEL の新しいマイナー バージョンは、リリースから 90 日以内にサポートされます。 既定のポリシーの SELinux がサポートされています。 | |
FIPS 140-2 | |
ロード バランサー L4/ネットワーク ロード バランサー | |
NFS サーバーの要件 (Linux ベースの NFSv3/NFSv4 バージョンを使用するオンプレミスまたはクラウドで管理される NFS サーバー)
| |
ノード ポート | |
ソフトウェア |
各マシンの RPM パッケージ |
SQL Server | |
ObjectStore (Azure Blob ストレージ、AWS S3、S3 互換 ObjectStore) | |
OCI 準拠のレジストリ | |
DNS | |
TLS 1.2+ | |
IPv4
(IPv6 はサポートされていません。) | |
スワップメモリが無効化されていること。 | |
|
- 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) をサポートしています。FIPS 140-2 が有効化されたホスト上で Automation Suite のクリーン インストールを実行できます。また、以前に 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 |
64 GiB |
192 GiB |
ノードあたりの最小 RAM |
N/A |
16 GiB |
クラスター ディスク* |
256 GiB SSD 最小 IOPS: 1100 |
256 GiB SSD 最小 IOPS: 1100 |
データ ディスク
|
512 GiB 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 |
Object Store
|
512 GiB SSD 最小 IOPS: 1100 |
512 GiB SSD 最小 IOPS: 1100 |
- AI Center の ML スキルやトレーニング用のストレージ要件に基づいて、クラスター ディスクの容量を増やす必要がある場合があります。
- Document Understanding モダン プロジェクトを有効化する場合、クラスター ディスクの最小容量は 512 GiB です。
Automation Suite をシングルノードの評価モードでインストールする際に、32 (v-)CPU/コア、64 GiB の RAM を搭載したマシンがない場合は、最小で 8 (v-)CPU/コアと 16 GiB の RAM を搭載したマシンを利用できます。詳しくは、「要件算出ツール」をご覧ください。
このオプションを選択する場合は、マルチノードのインストールと構成の手順に従ってください。
可能な場合は外部 ObjectStore を使用することをお勧めします。ObjectStore をクラスターから独立してスケーリングできるので、安定性が向上します。次の ObjectStore オプションがサポートされています。
- Azure Storage アカウント
- AWS S3 のストレージ バケット
- S3 互換のストレージ バケット
Automation Suite の個々の製品またはさまざまな製品の組み合わせをインストールするために満たす必要があるハードウェア要件の詳細については、Automation Suite Install Sizing Calculator (インストール サイジング計算ツール) を使用してください。
Task Mining の追加要件
Task Mining には、次の要件を満たす追加のエージェント ノードが必要です。
ハードウェア |
最小要件 |
---|---|
プロセッサ |
20 (v-)CPU/コア |
RAM |
60 GiB |
クラスター バイナリとステート ディスク |
256 GiB SSD 最小 IOPS: 1100 |
データ ディスク |
N/A |
Automation Suite ロボットの追加要件
マルチノードの HA 対応の運用環境では、Automation Suite ロボットに追加のエージェント ノードが必要です。シングルノードの評価環境では、追加の Automation Suite ロボット ノードは任意です。
Automation Suite ロボット ノードのハードウェア要件は、リソースの使用方法によって異なります。追加のエージェント ノードの要件に加えて、パッケージのキャッシュを有効化するために 10 GiB 以上の容量も必要です。
次のセクションでは、Automation Suite ロボット ノードで必要なハードウェアの量に影響する要因について説明します。
ロボットのサイズ
次の表に、すべてのロボット サイズに必要な CPU、メモリ、およびストレージを示します。
Size |
CPU |
メモリ |
ストレージ |
---|---|---|---|
小 |
0.5 |
1 GiB |
1 GiB |
標準 |
1 |
2 GiB |
2 GiB |
中 |
2 |
4 GiB |
4 GiB |
大 |
6 |
10 GiB |
10 GiB |
エージェント ノードのサイズ
Automation Suite ロボット エージェント ノードのリソースは、同時に実行できるジョブの数に影響します。その理由は、CPU コアの数と RAM の容量が、ジョブの CPU/メモリ要件で除算されるためです。
たとえば、16 CPU と 32 GiB の RAM を搭載したノードは、次のいずれかを実行できます。
- 32 個の小型のジョブ
- 16 個の標準ジョブ
- 8 個の中型のジョブ
- 2 個の大型のジョブ
複数のジョブ サイズを混在できるため、特定の時点において、同じノードで次のようなジョブの組み合わせを実行できます。
- 10 個の小型のジョブ (5 CPU と 10 GiB のメモリを消費)
- 4 個の標準ジョブ (4 CPU と 8 GiB のメモリを消費)
- 3 個の中型のジョブ (6 CPU と 12 GiB のメモリを消費)
Kubernetes のリソース消費量
ノードは Kubernetes クラスターに属しているため、サーバー上に存在する Kubernetes エージェント (kubelet) は少量のリソースを消費します。UiPath の測定結果によると、Kubelet が消費するリソースは以下のとおりです。
- 0.6 CPU
- 0.4 GiB RAM
前述のノードと同様のノードでは、実際の容量は約 15.4 CPU と 31.6 GiB の RAM になります。
マシン サイズの自動選択
すべてのクロスプラットフォーム プロセスでは、[Automation Suite ロボット] のオプションが既定で [自動] に設定されています。この設定では、サーバーレス ロボットを使用してプロセスを実行するのに適したマシン サイズが選択されます。
サイズの自動選択にあたっては、以下の表に記載された基準が順番に評価されます。ある基準が満たされた時点で、その基準に対応するマシン サイズが選択され、残りの基準は評価されません。
順序 |
基準 |
マシン サイズ |
---|---|---|
1 |
リモート デバッグのジョブである |
中 |
2 |
プロセスが UI Automation に依存している OR プロセスが UiPath Document Understanding アクティビティに依存している |
標準 |
3 |
その他の無人プロセス |
小 |
AI Center と Document Understanding の追加要件
AI Center では、完全なプラットフォーム要件に含まれるコア サービス要件に加えて、実行またはトレーニングするモデルに応じて追加のリソースが必要です。 必要な GPU ハードウェアの世代と互換性のある NVIDIA ドライバーの詳細については、「 相互運用性マトリクス」をご覧ください。
AI Center でランタイムに必要なディスク ストレージには、ML スキルとトレーニング パイプラインでそれぞれ次のような条件があります。
-
ML スキルでは、予測用のトレーニング済みモデルを保存するためのディスク領域が
/var/lib/rancher
パーティションに必要です。 最悪のシナリオでは、モデルのサイズは 20 GiB にもなります。 -
トレーニング パイプラインは、モデルをホストするために
/var/lib/rancher
パーティションのストレージを消費します。 最悪のシナリオでは、モデルのサイズが 20 GiB にもなり、さらにデータセット用のストレージが必要になることがあります。 データセット ストレージの最小サイズは 51 GiB です。推奨サイズは 105 GiB です。 これは、AI Center の専用ディスク上にある必要があります。 トレーニング パイプラインは、専用の AI Center ディスクがアタッチされているノードでのみスケジュール設定されます。
次の表で、AI Center で必要となる追加リソースについて説明します。以下の表では、すべてのサーバー ノードにデータ ディスクが必要です。エージェント ノードにデータ ディスクは必要ありません。
使用 |
CPU |
RAM (GiB) |
GPU |
ディスク (GiB) |
---|---|---|---|---|
サービング (ML スキル、1 つのレプリカ) の最小要件 |
0.6 |
2 |
0 |
|
トレーニング (パイプライン) の最小要件 |
1 |
4 |
0 |
|
DU モデルのサービング (ML スキル、1 つのレプリカ) |
1 |
4 |
0 |
|
DU モデルのトレーニング |
2 |
24 |
強く推奨 |
|
以下の表では、すべてのサーバー ノードにデータ ディスクが必要です。エージェント ノードにデータ ディスクは必要ありません。
使用 |
CPU |
RAM (GiB) |
GPU |
ディスク (GiB) |
---|---|---|---|---|
小規模な実装:
|
4 |
32 |
0 |
|
平均的な実装:
|
8 |
52 |
強く推奨 |
|
rancher
パーティションで 20 GiB = rancher
パーティションで 80 GiB
2 1 パイプライン * 105GiB = 105 データ ディスク
rancher
パーティションで 20 GiB = rancher
パーティションで 160 GiB
4 (2 パイプライン + 1 DU パイプライン) * 105GiB = 315 データ ディスク
AI Computer Vision の追加要件
この設定は、オンプレミスの Nvidia GPU で動作しますが、AWS、Azure、GCP などのクラウド プロバイダーでも動作します。推奨される GPU の種類には、十分な GPU メモリと処理能力を備えた RTX、Tesla、および Ampere ファミリの GPU が含まれます。
これら 2 種類の GPU の主な違いは、仮想化を使用した GPU には通常使用できる GPU RAM がより多く、ほとんどのクラウド プロバイダーによって提供されているという点です。GPU RAM を増やすと、モデルに入力できる画像の最大サイズが増加します。結論として、仮想化 GPU はコンシューマー向け GPU よりも大幅に高速というわけではありません。
以下のハードウェア仕様を満たすマシンが必要です。
ハードウェアの仕様 | 要件 |
---|---|
メモリ |
|
CPU |
|
GPU |
|
ストレージ |
|
Document Understanding の追加の推奨事項
パフォーマンスを向上させるには、GPU がサポートされた追加のエージェント ノードに Document Understanding をインストールできます。 ただし、Document Understanding は GPU ノードがなくても完全に機能します。 実際には、Document Understanding はすべての抽出および分類タスクに CPU 仮想マシンを使用しますが、OCR には GPU 仮想マシンを使用することを強くお勧めします。
Document Understanding フレームワーク内での CPU/GPU の使用方法の詳細については、「 CPU と GPU の使用」をご覧ください。
GPU サポートのある追加のノードを使用する場合、次の要件を満たす必要があります。
ハードウェア |
最小要件 |
---|---|
プロセッサ |
8 (v-)CPU/コア |
RAM |
52 GiB |
クラスター バイナリとステート ディスク |
256 GiB SSD 最小 IOPS: 1100 |
データ ディスク |
N/A |
GPU RAM |
11 GiB |
詳しくは、「AI Center に関する考慮事項」をご覧ください。
Document Understanding モダン プロジェクトの追加要件
最適なパフォーマンスを得るには、Document Understanding モダン プロジェクトには 5 つ以上の GPU が必要です。 次の表のシナリオ例は、300 ページを処理するには 5 つの GPU で十分であることを示しています。
機能 | Number |
---|---|
1 時間あたりに処理されるカスタム モデルのページ数 | 300 |
すぐに使えるモデルの 1 時間あたりに処理されるページ数 | 0 |
並列でトレーニングするモデルのトレーニング | 1 |
すべてのプロジェクトのページ数 - 設計時 | 200 |
プロジェクト バージョンごとのドキュメントの種類の数 | 3 |
5 つの GPU は、次の表に示すように、さまざまな機能に分散されています。
サービス | GPU の数 |
---|---|
OCR レプリカ | 1 |
カスタム モデルのトレーニング レプリカ | 1 |
カスタム モデルのレプリカ | 2 |
すぐに使えるモデルのレプリカ | 1 |
合計 | 5 |
各サービスに GPU を割り当てる方法について詳しくは、「 Document Understanding モダン プロジェクトに GPU リソースを割り当てる 」をご覧ください。
Document Understanding モダン プロジェクトでは、GPU の需要に加えて、最適なパフォーマンスを得るために特定の CPU リソースも必要になります。 最適なパフォーマンスを得るには、 18 個以上の vCPU が必要です。
objectstore
が必要です。 より小さい数から始めることができますが、明示的に拡大縮小しない限り、ストレージが完了するとアクティビティは失敗します。
1 年間の継続的処理のためにプロビジョニングする場合、Document Understanding モダン プロジェクト用に 4 TiB、その他の製品用に 512 GiB が必要です。 合計は 4.5 TiB のストレージになります。 同様に、6 か月の処理から開始する場合、Document Understanding モダン プロジェクトには 2 TiB、その他の製品には 512 GiB が必要になります。 この場合、合計は 2.5 TiB になります。
Automation Suite のインストールを開始する前に、以下の要件を満たしていることを確認する必要があります。
- RHEL のサブスクリプションがある。
- BaseOS リポジトリと AppStream リポジトリを有効化している
- 必要な RPM パッケージがインストールされている。
以下の表に、必要な RPM パッケージのリストを示します。
RPM パッケージ |
説明 |
---|---|
|
インストールのためにノードに必要です。 |
|
準備状況の確認を実行するためにノードに必要です。 |
|
オフライン インストールでのみ必要です。 |
RHEL 8.4 以降では、必要な RPM パッケージが BaseOS リポジトリと AppStream リポジトリに既定で格納されています。
Automation Suite を手動でクリーン インストールする場合は、RPM パッケージの要件を満たしていることをユーザーが確認する必要があります。この場合、必要な RPM パッケージのインストールはユーザーの責任です。
以前のバージョンの Automation Suite からアップグレードする場合、RPM パッケージはインストール済みです。
RPM パッケージをインストールおよび検証するために使用できるツールについて詳しくは、「必要な RPM パッケージを検証してインストールする」をご覧ください。
インストールには、前提条件として外部 SQL Server が必要です。Microsoft SQL Server 2016、2017、2019、2022 の Standard および Enterprise エディションがサポートされています。
Microsoft SQL Server データベース エンジンが要件を満たしている限り、追加の Microsoft SQL プラットフォーム (Azure SQL Database や Azure SQL Managed Instance など) および Amazon Relational Database Service もサポートされます。
個々の製品サポートの内容は異なります。
デプロイを計画している各製品について、以下のことが必要です。
- 製品で必要とされる SQL Server のサポート バージョンを確認する
- 製品で必要とされる SQL Server 構成の前提条件 (SQL Server のユーザー権限を含む) を適用する
製品固有の SQL Server の要件について詳しくは、「Microsoft SQL Server を構成する」をご覧ください。
Microsoft SQL Server の一般的な最小ハードウェア要件は次のとおりです。
- 8 (v-)CPU
- 32 GiB RAM
- 256 GiB SSD
ここに示す最小要件は一般的な指針であり、運用環境のデプロイにおいて信頼できる動作を保証するものではありません。信頼性のある動作に求められるハードウェア要件を決定するには、要件算出が必要です。
デプロイする予定の各製品について、計画されている使用状況を評価し、製品の指定に従って要件算出の指針を適用する必要があります。この情報は、各製品のヘルプ セクションにあります。
バックアップを有効化するには、外部 NFS サーバーが必要です。 Automation Suite は、Linux ベースのオンプレミスまたはクラウドで管理される NFS サーバー (バージョン NFSv3/NFSv4) をサポートしています。
NFS サーバーの一般的な最小ハードウェア要件は次のとおりです。
-
CPU - 4 vCPU
-
RAM - 8 GiB
-
ストレージ - 1 TiB
注: 外部 ObjectStore を使用する場合、必要なストレージ容量は数 GiB です。 クラスター内 ObjectStore を使用する場合、最小ストレージ サイズは ObjectStore のサイズと同じになります。
アクティブ/パッシブ デプロイを構成するには、次の要件を満たしていることを確認してください。
- ハードウェア
- ロード バランサー
- DNS
- 証明書
- Object Store
- Traffic Manager
両方の Automation Suite クラスターがソフトウェアおよびハードウェアの一連の要件を満たす必要があります。詳しくは、マルチノード モードのハードウェア要件をご覧ください。
両方の Automation Suite クラスターにロード バランサーが必要です。詳しくは、「ロード バランサーを構成する」をご覧ください。
DNS の要件の詳細については、「DNS を構成する」をご覧ください。