- 入门指南
- 要求
- 最佳实践
- 安装
- 正在更新
- 身份服务器
- 对启动错误进行故障排除
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(要实现真正的高可用性,需要 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 负载均衡器
- 分布式 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 的吞吐量) |
软件要求
软件 |
版本 |
---|---|
操作系统 |
Windows Server 2016 |
数据库 |
SQL Server 2019 |
日志记录 |
Elasticsearch 7.2.0 |
上面列出的版本是用于所述部署和性能测试负载的版本。
负载平衡
对于多节点部署,建议使用两个 Azure 标准负载均衡器:
- 一个用于 Orchestrator 服务器;
- 一个用于 Elasticsearch 服务器。
High Availability Add-On
-
重要提示:
多节点 Orchestrator 部署使用 RESP(REdis 序列化协议)进行通信,因此可以使用依赖于此协议的任何解决方案进行配置。
仅当使用时,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 |