- 基本情報
- 要件
- ベスト プラクティス
- インストール
- 更新
- Identity Server
- High Availability Add-on
ハードウェア要件
ハードウェア要件は、開発環境と運用環境によって異なります。運用環境と同じハードウェア要件をテストおよび開発の目的で使用することもできますが、特に大規模なデプロイの場合は、不必要な高いコストが生じてしまいます。
これらの要件は、最大 100 台の Unattended ロボットが同時に実行されることを想定しています。次のように構成された 2 台のマシンを使用できます。1台は Orchestrator および Elasticsearch (任意) 用、もう 1 台は SQL Server 用です。
Web アプリケーション サーバー
|
CPU コア数 (> 2GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|
|
4 |
4 |
150 |
SQL Server
|
CPU コア数 (> 2GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|
|
4 |
8 |
300 |
運用環境では、次の各役割に対してそれぞれ専用のサーバーを用意することを強くお勧めします。
- Orchestrator Web アプリケーション
- SQL Server データベース エンジン
- Elasticsearch と Kibana
マルチノードでのインストールでは、上記に加えて次のものが必須です。
-
Orchestrator の High Availability Add-on (HAA) (高可用性自体を実現するには 3 つ以上の HAA ノード、地理的冗長性を確保するには 6 つ以上の HAA ノードが必要です。)
注:Orchestrator のマルチノード デプロイは、通信に REdis Serialization Protocol (RESP) を使用するため、このプロトコルを使用するあらゆるソリューションによる設定が可能です。
UiPath がサポートしているソリューションは HAA のみです。
以下に詳述するように、必要な各サーバーのハードウェア構成は、デプロイのサイズによって異なります。ここでのハードウェア要件は、次の定義に基づいてデプロイされたロボットで行ったテストから導きだされたものです。
- ロボットから Orchestrator へのメッセージ送信頻度は、1 秒当たり 1 メッセージとする。
- ロボットは、60 秒間に次のメッセージを送信する。
- 40 件のメッセージログ
- 2 件のハートビート
- 6 件のアセット取得要求
- 6 件のキュー アイテム追加要求
- 6 件のキュー アイテム取得要求
最大 250 台の Unattended ロボットに対応
Web アプリケーション サーバー
|
ロボット数 |
CPU コア数 (2GHz 以上) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<20 |
4 |
4 |
100 |
|
<50 |
4 |
4 |
100 |
|
<100 |
4 |
4 |
150 |
|
<200 |
4 |
4 |
200 |
|
<250 |
4 |
4 |
200 |
UiPath.Orchestrator.dll.config ファイルで、SQL 接続文字列のプールで許可される接続の数を 200 に増やします。そのためには、Max Pool Size=200 パラメーターを接続文字列に追加し、以下の例のようにする必要があります。
<add name="Default" providerName="System.Data.SqlClient" connectionString="Server=SQL4142;Integrated Security=True;Database=UiPath;Max
Pool Size=200;" />
SQL Server
|
ロボット数 |
CPU コア数 (2GHz 以上) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<20 |
4 |
8 |
100 |
|
<50 |
4 |
8 |
200 |
|
<100 |
4 |
8 |
300 |
|
<200 |
8 |
8 |
SSD 400 |
|
<250 |
8 |
16 |
SSD 400 |
必要ディスク容量は、次の項目に大きく依存します。
- ワーク キューが使用されているかどうか。ワーク キューが使用されている場合、毎日/毎週追加されるトランザクションの平均数と、各トランザクションのサイズ (フィールドの数や各フィールドのサイズ) に依存します。
- 正常に処理されたキュー アイテムの保持期間 (ユーザーは独自の保持ポリシーを施行する必要があります)。
- ロボットによって記録されたメッセージがデータベースに格納されるかどうか。格納される場合、フィルター処理によって特定のレベルのメッセージのみを DB に格納できます (たとえば、ログ レベル Error および Critical のメッセージを DB に格納し、ログ レベルが Info、Warn および Trace のメッセージを Elasticsearch に格納する）。
- ログ メッセージの頻度 - ロボット開発者は、メッセージがログ記録に値すると考えられる場合、任意で [メッセージをログ] アクティビティを使用します。
- 古いログ記録メッセージの保持期間 (ユーザーは自身の保持ポリシーを施行する必要があります)。
- ロボットに設定されたログ記録レベルの値。たとえば、ロボットのログ記録レベルが Info に設定されている場合、Info、Warn、Error、Critical のレベルが設定されたメッセージのみが Orchestrator に送信されます。レベルが Debug、Trace および Verbose のメッセージは無視され、Orchestrator には送信されません。
Elasticsearch サーバー
|
ロボット数 |
CPU コア数 (2GHz 以上) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<20 |
4 |
4 |
100 |
|
<50 |
4 |
4 |
100 |
|
<100 |
4 |
8 |
150 |
|
<200 |
4 |
12 |
200 |
|
<250 |
4 |
12 |
300 |
必要ディスク容量は、次の項目に依存します。
- 保持期間 (ユーザーは、独自の保持ポリシーの実施が必要となります)。
- ログ メッセージの頻度 - ロボット開発者は、メッセージがログ記録に値すると考えられる場合、任意で [メッセージをログ] アクティビティを使用します。
- ロボットに設定されたログ レベルの値。たとえば、ロボットのログ レベルが Info に設定されている場合、レベルが Info、Warn、「Error」、「Critical」のメッセージのみが Orchestrator に送信されます。レベルが「Debug」、「Trace」および「Verbose」のメッセージは無視され、Orchestrator には送信されません。
注: ロボットが 50 台以上ある場合は、
-Xmsと-Xmx引数の両方をメモリの合計の半分に設定することで、Elasticsearch が使用する Java 仮想マシンに利用可能な RAM の 50% を使用するよう指示します。これはES_JAVA_OPTS環境変数を使用するか、jvm.optionsファイルを編集することで実行できます。
250 台から 500 台の Unattended ロボットに対応
Web アプリケーション サーバー
|
ロボット数 |
CPU コア数 (2GHz 以上) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
8 |
8 |
200 |
|
<400 |
8 |
8 |
220 |
|
<500 |
16 |
8 |
250 |
SQL Server
|
ロボット数 |
CPU コア数 (2GHz 以上) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
16 |
32 |
SSD 400 |
|
<400 |
16 |
32 |
SSD 500 |
|
<500 |
16 |
32 |
SSD 600 |
ロボットが 300 台以上ある場合は、SQL Server データベースにログ記録のメッセージをすべて保存しないことを検討してください。DB にはログ レベルが Error と Critical のメッセージのみを格納し、すべてのメッセージ (Error と Critical を含む) は Elasticsearch に格納してください。
Elasticsearch サーバー
|
ロボット数 |
CPU コア数 (2GHz 以上) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
4 |
12 |
300 |
|
<400 |
4 |
16 |
500 |
|
<500 |
4 |
16 |
600 |
500 以上の Unattended ロボットに対応
Orchestrator が 500 台を超えるロボットを並行実行する必要がある場合、[ネットワーク ロード バランサー] で、1 つのファームに 2 個以上の Orchestrator ノードおよび 1 個以上の HAA ノードを入力する必要があります。各ノードには、ロード バランサーからの要求に対して提供するロボット数に従ったハードウェア要件があります。ただし、SQL Server は単一のマシンです (Always On 可用性グループであっても、プライマリ レプリカが I/O 要求すべての提供を担います)。そのため、次の手順が必要です。
- SQL Server の RAM を 64GB に増やします。
- ロボットからログ レベル Error および Critical のみを DB に格納します。
SQL Server
|
ロボット数 |
CPU コア数 (2GHz 以上) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
500 |
16 |
64 |
SSD 800 |
SQL Server Standard Edition では、使用する最大 CPU コア数は 16 です。仮想マシンの場合は、このコア数をそれぞれ 4 コアを持つ 4 つの仮想ソケットとして取得していることを確認してください (8 コアを持つ 2 ソケットや 2 コアを持つ 8ソケットではなく)。Enterprise Edition では、16 コアを取得するための組み合わせは重要ではありません。
|
ポート |
説明 |
|---|---|
|
443 | ユーザーと、Robot が接続された Orchestrator とが通信するための既定のポート。 |
|
1433 | Orchestrator と SQL Server マシン間の通信用の既定のポート。 |
|
9200 | Orchestrator と Elasticsearch 間の通信。 |
|
9300 | Elasticsearch ノード間の通信 (該当する場合)。 |
|
5601 | Kibana プラグインが使用する既定のポート (該当する場合)。 |
|
3389 | 高密度ロボットに必要な RDP オートメーションを使用する場合は必要です。 |
