orchestrator
2021.10
false
重要 :
请注意此内容已使用机器翻译进行了部分本地化。 新发布内容的本地化可能需要 1-2 周的时间才能完成。
UiPath logo, featuring letters U and I in white
不在支持范围内

Orchestrator 安装指南

Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
上次更新日期 2024年10月31日

硬件要求

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

磁盘空间要求在很大程度上取决于:

  • 是否使用工作队列。 如果使用工作队列,则取决于每天/每周添加的平均事务数以及每个事务的大小(字段数、每个字段的大小)。
  • 已成功处理的队列项目的保留期(客户应实施自己的保留策略)。
  • 机器人记录的消息是否存储在数据库中。 如果已存储,则可以应用筛选器以仅在数据库中存储特定级别的消息(例如,将日志级别为 ErrorCritical的消息存储在数据库中,并将日志级别为 InfoWarnTrace的消息存储在 Elasticsearch 中)。
  • 记录消息的频率 - 每当机器人开发者认为值得记录消息时,他们可以随意使用“ 记录消息” 活动。
  • 旧记录消息的保留期(客户应实施自己的保留策略)。
  • 在机器人中设置的日志记录级别值。 例如,如果机器人中的日志记录级别设置为 Info,则仅将级别为 InfoWarnErrorCritical 的消息发送到 Orchestrator;级别为 DebugTraceVerbose 的消息将被忽略,因此不会到达 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,则仅将级别为 InfoWarn、“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 数据库中存储所有记录的消息。 仅将日志级别为 ErrorCritical的消息存储在数据库中。 将所有消息(包括 ErrorCritical)存储在 Elasticsearch 中。

Elasticsearch 服务器

机器人数量

CPU 核心(最小 2GHz)

RAM (GB)

硬盘 (GB)

<300

4

12

300

<400

4

16

500

<500

4

16

600

大型部署

IaaS 有人值守的部署

以下部分描述了使用 Azure 基础架构即服务 (IaaS) 产品进行的大规模可扩展部署的要求。需要以下服务:

架构

备注:

以下架构示例包含可选和/或不同的组件(例如 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 的吞吐量)

软件要求

软件

版本

操作系统

Windows Server 2016

数据库

SQL Server 2019

日志记录

Elasticsearch 7.2.0

上面列出的版本是用于所述部署和性能测试负载的版本。

负载平衡

对于多节点部署,建议使用两个 Azure 标准负载均衡器:

  • 一个用于 Orchestrator 服务器;
  • 一个用于 Elasticsearch 服务器。
High Availability Add-On
  • 对于 Orchestrator(要实现真正的高可用性,需要 3 个以上的 HAA 节点;要实现异地冗余,则需要 6 个以上的 HAA 节点)。

    重要提示:

    多节点 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 有人值守的部署

以下各节我们从性能方面深入了解 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机器人的硬件要求。

  • 中小型部署
  • 开发环境
  • 生产环境
  • 大型部署
  • IaaS 有人值守的部署
  • PaaS 有人值守的部署
  • TCP 端口

此页面有帮助吗?

获取您需要的帮助
了解 RPA - 自动化课程
UiPath Community 论坛
Uipath Logo White
信任与安全
© 2005-2024 UiPath。保留所有权利。