- 入门指南
- 要求
- 最佳实践
- 安装
- 正在更新
- 身份服务器
- High Availability Add-On
- 对启动错误进行故障排除
Orchestrator 安装指南
硬件要求
有多种用于托管 Orchestrator 的企业云部署可供选择，例如 Amazon Web Services(AWS)、Microsoft Azure 或 Google Cloud Platform (GCP)。根据您选择的部署提供商和计划构建的环境的大小，您需要咨询不同的硬件要求。
本章将深入探讨特定于其中一些场景的硬件要求。
硬件要求因开发环境和生产环境等因素而异。虽然与生产环境相同的硬件要求可用于测试和开发目的，但这意味着增加不必要的成本，尤其是在大规模部署时。
这些要求假设最多有 100 个无人值守机器人同时运行。 可以使用两台计算机，一台用于 Orchestrator 和（可选）Elasticsearch，另一台用于 SQL Server，配置如下：
网页应用程序服务器
|
CPU 内核 (>2GHz) |
RAM (GB) |
硬盘 (GB) |
|---|---|---|
|
4 |
4 |
150 |
SQL 服务器
|
CPU 内核 (>2GHz) |
RAM (GB) |
硬盘 (GB) |
|---|---|---|
|
4 |
8 |
300 |
对于生产环境，强烈建议为每个角色提供一台专用服务器：
- Orchestrator Web 应用程序。
- SQL Server 数据库引擎。
- Elasticsearch 和 Kibana。
对于多节点安装，除上述要求外，还需满足以下要求：
- Orchestrator High Availability add-on (HAA)（要实现真正的高可用性，需要 3 个以上的 HAA 节点；要实现异地冗余，则需 6 个以上的 HAA 节点）。
备注：
多节点 Orchestrator 部署使用 RESP（REdis 序列化协议）进行通信，因此可以使用依赖于此协议的任何解决方案进行配置。
HAA 是这类解决方案中唯一受 UiPath 支持的解决方案。
每个所需服务器的硬件配置取决于部署的大小，如下所述。 此处介绍的硬件要求是根据测试得出的，其中机器人的定义如下：
- 消息从机器人发送到 Orchestrator，频率为每秒 1 条消息
- 在 60 秒内，机器人将发送：
- 15 条消息日志
- 2 次检测信号
- 6 获取资产请求
- 6 添加队列项目请求
- 6 获取队列项目请求
最多支持 250 个无人值守机器人
网页应用程序服务器
|
机器人数量 |
CPU 核心（最小 2GHz） |
RAM (GB) |
硬盘 (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 连接字符串池中允许的连接数量增加到 500。为此，需要将 Max Pool Size=500 参数添加到连接字符串中，使其看起来类似于以下示例：
<add name="Default" providerName="System.Data.SqlClient" connectionString="Server=SQL4142;Integrated Security=True;Database=UiPath;Max
Pool Size=500;" />
SQL 服务器
|
机器人数量 |
CPU 核心（最小 2GHz） |
RAM (GB) |
硬盘 (GB) |
|---|---|---|---|
|
<20 |
4 |
8 |
100 |
|
<50 |
4 |
8 |
200 |
|
<100 |
4 |
8 |
300 |
|
<200 |
8 |
8 |
固态硬盘 400 |
|
<250 |
8 |
16 |
固态硬盘 400 |
磁盘空间要求在很大程度上取决于：
- 是否使用工作队列。 如果使用工作队列，则取决于每天/每周添加的平均事务数以及每个事务的大小（字段数、每个字段的大小）。
- 已成功处理的队列项目的保留期（客户应实施自己的保留策略）。
- 机器人记录的消息是否存储在数据库中。 如果已存储，则可以应用筛选器以仅在数据库中存储特定级别的消息（例如，将日志级别为 Error 和 Critical的消息存储在数据库中，并将日志级别为 Info、Warn 和 Trace的消息存储在 Elasticsearch 中)。
- 记录消息的频率 - 每当机器人开发者认为值得记录消息时，他们可以随意使用“ 记录消息” 活动。
- 旧记录消息的保留期（客户应实施自己的保留策略）。
- 在机器人中设置的日志记录级别值。 例如，如果机器人中的日志记录级别设置为 Info，则仅将级别为 Info、Warn、Error 和 Critical 的消息发送到 Orchestrator；级别为 Debug、Trace 和 Verbose 的消息将被忽略，因此不会到达 Orchestrator。
Elasticsearch 服务器
|
机器人数量 |
CPU 核心（最小 2GHz） |
RAM (GB) |
硬盘 (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 虚拟机使用 50% 的可用 RAM。 这可以通过ES_JAVA_OPTS环境变量或编辑jvm.options文件来完成。
支持 250 到 500 个无人值守机器人
网页应用程序服务器
|
机器人数量 |
CPU 核心（最小 2GHz） |
RAM (GB) |
硬盘 (GB) |
|---|---|---|---|
|
<300 |
8 |
8 |
200 |
|
<400 |
8 |
8 |
220 |
|
<500 |
16 |
16 |
250 |
SQL 服务器
|
机器人数量 |
CPU 核心（最小 2GHz） |
RAM (GB) |
硬盘 (GB) |
|---|---|---|---|
|
<300 |
16 |
32 |
固态硬盘 400 |
|
<400 |
16 |
32 |
固态硬盘 500 |
|
<500 |
16 |
32 |
固态硬盘 600 |
对于超过 300 个机器人，请考虑不在 SQL Server 数据库中存储所有记录的消息。 仅将日志级别为 Error 和 Critical的消息存储在数据库中。 将所有消息（包括 Error 和 Critical）存储在 Elasticsearch 中。
Elasticsearch 服务器
|
机器人数量 |
CPU 核心（最小 2GHz） |
RAM (GB) |
硬盘 (GB) |
|---|---|---|---|
|
<300 |
4 |
12 |
300 |
|
<400 |
4 |
16 |
500 |
|
<500 |
4 |
16 |
600 |
以下部分是使用 Azure 基础架构即服务 (IaaS) 产品进行的大规模可扩展部署的示例。使用了以下配置：
- Orchestrator 的虚拟机可用性集
- Elasticsearch 的 VM 可用性集
- Windows Server SQL VM
- Azure 负载均衡器
- 高可用性附加组件 （HAA）
- 分布式 DNS 服务（如 Cloudflare）
架构
单节点架构
多节点架构
硬件要求
本节介绍了下方扩展部署中所列的性能测试硬件配置。
Orchestrator 节点
每个 Orchestrator 节点都必须进行如下配置：
|
VCPUs |
RAM (GB) |
SSD (GB) |
|---|---|---|
|
16 |
32 |
128 |
SQL 服务器
SQL Server 虚拟机规格必须根据 Orchestrator 节点的数量进行扩展：
|
Orchestrator 节点 |
VCPUs |
RAM (GB) |
磁盘 |
|---|---|---|---|
|
1-2 |
8 |
16 |
1TB - 用于数据库、tempDB 和事务日志的超 SSD 磁盘 |
|
5 |
16 |
32 |
1TB - 用于数据库的超 SSD 磁盘 1TB - 用于 tempDB 的超 SSD 磁盘 1TB - 用于事务日志的超 SSD 磁盘 |
|
10 |
32 |
64 |
1TB - 用于数据库的超 SSD 磁盘 1TB - 用于 tempDB 的超 SSD 磁盘 1TB - 用于事务日志的超 SSD 磁盘 |
|
15 |
40 |
96 |
1TB - 用于数据库的超 SSD 磁盘 1TB - 用于 tempDB 的超 SSD 磁盘 1TB - 用于事务日志的超 SSD 磁盘 |
Elasticsearch 可用性集
Elasticsearch 可用性集由 3 个主节点和 6 个数据节点组成，共 9 个节点，每个节点具有以下规格：
|
VCPUs |
RAM (GB) |
OS SSD (GB) |
Data SSD (TB) |
|---|---|---|---|
|
8 |
16 |
128 （5000 IOPS 和 100 MB/s 吞吐量） |
1（具有 5000 IOPS 和 200 MB/s 的吞吐量） |
软件要求
上面列出的版本是用于所述部署和性能测试负载的版本。
负载平衡
对于多节点部署，建议使用两个 Azure 标准负载均衡器：
- 一个用于 Orchestrator 服务器；
- 一个用于 Elasticsearch 服务器。
High Availability Add-On
-
Orchestrator High Availability add-on (HAA)（要实现真正的高可用性，需要 3 个以上的 HAA 节点；要实现异地冗余，则需 6 个以上的 HAA 节点）。
重要提示：多节点 Orchestrator 部署使用 RESP（REdis 序列化协议）进行通信，因此可以使用依赖于此协议的任何解决方案进行配置。
仅当使用 UiPath High Availability Add-on 时，UiPath 才支持 Orchestrator 的高可用性部署。
扩展部署
Orchestrator 规模集中所需的节点数量取决于正在部署的机器人数量：
|
Orchestrator 规模集节点 |
机器人数量 |
|---|---|
|
1 |
高达 6,000 |
|
2 |
高达 14,000 |
|
5 |
高达 80,000 |
|
10 |
高达 200,000 |
|
15 |
高达 300,000 |
这些部署已使用上述硬件和软件配置进行测试，在以下指定负载下没有表现出性能损失。
性能测试
以下 2 个表格中显示的数据代表有人值守的部署。
静态数据
静态数据是指初始 Orchestrator 负载。
|
实体 |
一个节点 |
两个节点 |
五个节点 |
十个节点 |
十五个节点 |
|---|---|---|---|---|---|
|
租户 |
1 |
1 |
1 |
1 |
1 |
|
文件夹 |
1 |
2 |
4 |
4 |
6 |
|
机器人 |
6,000 |
14,000 |
80,000 |
200,000 |
300,000 |
|
包 |
8,000 |
16,000 |
48,000 |
48,000 |
48,000 |
|
流程 |
4,000 |
8,000 |
24,000 |
24,000 |
24,000 |
|
队列 |
600 |
1,200 |
1,800 |
2,400 |
3,000 |
|
队列项目 |
1,120,000 |
1,500,000 |
3,000,000 |
5,000,000 |
7,000,000 |
|
资产 |
500 |
1,000 |
1,500 |
3,000 |
4,500 |
动态数据
动态数据是指在执行流程时添加到 Orchestrator 或在 Orchestrator 中更改的数据。
|
实体 |
一个节点 |
两个节点 |
五个节点 |
十个节点 |
十五个节点 |
|---|---|---|---|---|---|
|
队列项目 (每天) |
300,000 |
600,000 |
4,000,000 |
9,000,000 |
10,500,000 |
|
作业 (每分钟) |
700 |
1,500 |
3,000 |
6,000 |
7,500 |
|
日志（每分钟） |
20,000 |
50,000 |
300,000 |
600,000 |
800,000 |
|
Nuget 下载 (每分钟最大) |
1,000 |
3,000 |
10,000 |
14,000 |
18,000 |
|
已连接的机器人数量 （数量上限） |
6,000 |
14,000 |
80,000 |
200,000 |
300,000 |
|
检测信号 (每分钟) |
12,000 |
28,000 |
160,000 |
400,000 |
600,000 |
|
忙碌的机器人 |
3,000 |
7,000 |
40,000 |
100,000 |
150,000 |
|
可用的机器人 |
3,000 |
7,000 |
40,000 |
100,000 |
150,000 |
以下各节我们从性能方面深入了解 PaaS 部署的功能。
架构
需要满足以下先决条件：
-
Orchestrator：
- Orchestrator 应用服务计划：20 个 P3V2 实例
- Azure SQL Server：Premium P15：4000 个 DTU
- Azure Redis 缓存 P2 Premium 13GB
-
Identity Server：
- Identity Server 应用服务计划： 2 个实例 P3V2
- Azure SQL Server：标准 S7：800 DTU
-
Elasticsearch：
性能测试
以下表格中显示的数据代表有人值守的部署。
静态数据
静态数据是指初始 Orchestrator 负载。
|
实体 |
一个节点 |
|---|---|
|
租户 |
1 |
|
文件夹 |
8,000 |
|
机器人 |
80,000 |
|
包 |
8,000 |
|
流程 |
8,000 |
|
队列 |
8,000 |
|
队列项目 |
2,000,000 |
|
资产 |
8,000 |
动态数据
动态数据是指在执行流程时添加到 Orchestrator 或在 Orchestrator 中更改的数据。
|
实体 |
一个节点 |
|---|---|
|
队列项目 (每天) |
5,000,000 |
|
作业 (每分钟) |
2,600 |
|
日志（每分钟） |
240,000 |
|
Nuget 下载 (每分钟最大) |
2,000 |
|
已连接的机器人数量 （数量上限） |
80,000 |
|
检测信号 (每分钟) |
160,000 |
|
忙碌的机器人 |
40,000 |
|
可用的机器人 |
40,000 |
