硬件要求

有多种用于托管 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

备注：

如果机器人超过 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

注意：SQL Server 标准版使用的 CPU 内核数上限为 16。对于虚拟机，请确保其为 4 个 4 内核的虚拟插槽，而不是 2 个 8 内核的插槽或 8 个 2 内核的插槽。对于企业版，16 个内核可选用任意组合方式。

对于超过 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

大型部署

IaaS 有人值守的部署

以下部分是使用 Azure 基础架构即服务 (IaaS) 产品进行的大规模可扩展部署的示例。使用了以下配置：

• Orchestrator 的虚拟机可用性集
• Elasticsearch 的 VM 可用性集
• Windows Server SQL VM
• Azure 负载均衡器
• 分布式 DNS 服务（如 Cloudflare）

架构

备注：

以下架构示例包含可选和/或不同的组件（例如 CyberArk、UiPath 高可用性加载项）。

所述 Jumpbox 不是必需的，但推荐您在生产环境使用此最佳实践，因其可提供隔离和安全。

单节点架构

多节点架构

硬件要求

本节介绍了下方扩展部署中所列的性能测试硬件配置。

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（要实现真正的高可用性，需要 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 有人值守的部署

以下各节我们从性能方面深入了解 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

TCP 端口

端口	描述
443	用户和 Orchestrator 与已连接的机器人之间通信的默认端口。
1433	Orchestrator 与 SQL Server 计算机之间通信的默认端口。
9200	Orchestrator 和 Elasticsearch 之间的通信。
9300	Elasticsearch 节点之间的通信（如果适用）。
5601	Kibana 插件使用的默认端口（如果适用）。
3389	RDP 自动化所需，高密度机器人所需。

您还可以查看 Studio 和机器人的硬件要求。