- Primeros pasos
- Requisitos
- Mejores prácticas
- Instalación
- Actualizando
- Servidor de identidad
- Complemento de alta disponibilidad
Implementación en la nube
Hay muchas opciones de implementación de nube empresarial disponibles para alojar tu Orchestrator, como Amazon Web Services (AWS), Microsoft Azure o Google Cloud Platform (GCP). Aquí detallamos una implementación grande y escalable utilizando la oferta de infraestructura como servicio (IaaS) de Azure. Los siguientes servicios son necesarios:
- Conjunto de disponibilidad de VM para Orchestator
- Conjunto de disponibilidad de VM para Elasticsearch
- Azure SQL Server
- Azure Load Balancer
- Azure Redis Cache para implementaciones multinodo
- Servicio DNS distribuido (como Cloudflare)
Los siguientes ejemplos de arquitectura contienen componentes opcionales o diversos (p. ej., CyberArk, UiPath High Availability Add-on).
El Jumpbox que se muestra no es necesario, pero es una práctica recomendada para tus entornos de producción que ofrece aislamiento y segurida.
Esta sección describe las configuraciones de hardware utilizadas para las pruebas de rendimiento que se indican en Escalar tu implementación, a continuación.
Cada nodo de Orchestrator debe configurarse de la siguiente manera:
VCPUs |
RAM (GB) |
SSD (GB) |
---|---|---|
16 |
32 |
128 |
Las especificaciones de la máquina virtual de SQL Server deben escalar en línea con el número de nodos de Orchestrator:
Nodos de Orchestrator |
VCPUs |
RAM (GB) |
---|---|---|
1-2 |
8 |
16 |
5 |
16 |
32 |
10 |
16 |
64 |
El conjunto de disponibilidad de Elasticsearch está compuesto de 3 nodos maestros y 6 nodos de datos; un total de 9 nodos, cada uno con las siguientes especificaciones:
VCPUs |
RAM (GB) |
OS SSD (GB) |
Data SSD (TB) |
---|---|---|---|
8 |
16 |
128 (con 5000 IOPS y 100 MB/s de capacidad de proceso) |
1 (con 5000 IOPS y 200 MB/s de capacidad de proceso) |
Software |
Versión |
---|---|
Sistema operativo |
Windows Server 2016 |
Bases de datos |
SQL Server 2017 |
Registro |
Elasticsearch 6.4.0 |
Las versiones antes mencionadas son las utilizadas para las implementaciones y las cargas de prueba de rendimiento descritas. Para conocer todas las versiones compatibles con Orchestrator, consulta aquí.
Para implementaciones multinodo, se recomienda utilizar dos equilibradores de carga estándar de Azure:
- Uno para los servidores de Orchestrator;
- Uno para los servidores Elasticsearch.
Las implementaciones multinodo de Orchestrator utilizan RESP (Redis Serialization Protocol, protocolo de serialización de Redis) para las comunicaciones y, por tanto, puede ser configurado con cualquier solución que implemente este protocolo, como Azure Redis Cache en este ejemplo.
UiPath solo admite las implementaciones de alta disponibilidad de Orchestrator si se usa la adición de alta disponibilidad de UiPath.
Para implementaciones multinodo, recomendamos utilizar dos instancias de Redis separadas:
- Azure Redis Cache Premium con una caché de 6 GB: el nodo primario utilizado para las asociaciones de estado de la sesión y de entidades de usuario;
- Azure Redis Cache Basic: utilizado para escalar el servicio de SignalR.
El número de nodos necesarios en tu conjunto de escalado de Orchestrator dependerá del número de UiPath Robots que se implementan:
Nodos del conjunto de escalado de Orchestrator |
N.° de UiPath Robots |
---|---|
1 |
Hasta 40 000 |
2 |
Hasta 8000 |
5 |
Hasta 24 000 |
10 |
Hasta 48 000 |
Estas implementaciones se han probado utilizando las configuraciones de hardware y software anteriores para demostrar que no hay pérdida de rendimiento con la carga especificada a continuación.
Datos estáticos
Datos estáticos hace referencia a la carga inicial existente de Orchestrator.
Entidad |
Un nodo |
Dos nodos |
Cinco nodos |
Diez nodos |
---|---|---|---|---|
Tenants |
40 |
80 |
240 |
480 |
Entornos |
2000 |
4 000 |
12 000 |
24 000 |
Robots
|
4 000
|
8 000
|
24 000
|
48 000
|
Paquetes |
8 000 |
16 000 |
48 000 |
96 000 |
Procesos |
4 000 |
8 000 |
24 000 |
48 000 |
Colas |
200 |
420 |
1200 |
2400 |
Artículos en cola |
1.120.000 |
1 500 000 |
3 000 000 |
5 000 000 |
Activos |
40 000 |
80 000 |
240 000 |
480 000 |
Programaciones |
400 |
800 |
2400 |
4800 |
Datos dinámicos
Los datos dinámicos se refieren a los datos añadidos o cambiados en Orchestrator mientras se ejecutan los procesos.
Entidad |
Un nodo |
Dos nodos |
Cinco nodos |
Diez nodos |
---|---|---|---|---|
Elementos de la cola (por día) |
112 000 |
175,000 |
672 000 |
1 250 000 |
Trabajos (por minuto) |
2000 |
4 000 |
12 000 |
24 000 |
Registros (por minuto) |
20,000 |
20,000 |
20,000 |
25,000 |
Descargas NuGet (máximo por minuto) |
2000 |
4 000 |
12 000 |
24 000 |
UiPath Robots conectados (máximo) |
4 000 |
8 000 |
24 000 |
48 000 |
Latidos (por minuto) |
10,000 |
20,000 |
60,000 |
120,000 |
Notificaciones de SignalR (por minuto) |
2000 |
4 000 |
12 000 |
24 000 |
UiPath Robots ocupados |
2000 |
4 000 |
12 000 |
24 000 |
UiPath Robots disponibles |
2000 |
4 000 |
12 000 |
24 000 |
- Arquitectura
- Arquitectura de un solo nodo
- Arquitectura multinodo
- Requisitos de hardware
- Nodos de Orchestrator
- Servidor SQL
- Conjunto de disponibilidad de Elasticsearch
- Requisitos de software
- Equilibrio de carga
- Azure Redis Cache
- Configuración
- Ajustes UiPath.Orchestrator.dll.config
- Escalar tu implementación
- Pruebas de rendimiento