- Introdução
- Requisitos
- Requisitos de Hardware
- Requisitos de software
- Melhores práticas
- Instalação
- Atualizando
- Servidor de Identidade
- Solução de problemas de erros de inicialização
Requisitos de Hardware
Há várias opções de implantação de nuvem empresarial disponíveis para hospedar seu Orchestrator, como a Amazon Web Services (AWS), Microsoft Azure ou Google Cloud Platform (GCP). Dependendo da sua opção de implantação e do tamanho do ambiente que você pretende criar, você precisa consultar diferentes requisitos de hardware.
Esse capítulo fornece insights para os requisitos de hardware específicos para alguns desses cenários.
Os requisitos de hardware diferem do seu ambiente de desenvolvimento para o ambiente de produção. Ainda que os mesmos requisitos de hardware de seu ambiente de produção possam ser usados para testes e desenvolvimento, isso implica custos maiores e desnecessários, especialmente em implantações em grande escala.
Esses requisitos consideram um máximo de 100 robôs não assistidos rodando simultaneamente. Duas máquinas podem ser usadas, uma para o Orchestrator e Elasticsearch (opcional), e uma para o SQL Server, configuradas da seguinte maneira:
Servidor de Aplicativo da Web
|
Núcleos de CPU (> 2GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|
|
4 |
4 |
150 |
SQL Server
|
Núcleos de CPU (> 2GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|
|
4 |
8 |
300 |
Para ambientes de produção, é altamente recomendável fornecer um servidor dedicado para cada função:
- Aplicativo Web do Orchestrator.
- Motor de Banco de Dados do SQL Server.
- Elasticsearch e Kibana.
Para uma Instalação de vários nós, além do requisito acima, também é necessário o seguinte:
- para o Orchestrator (mais de três nós do HAA são necessários para alta disponibilidade verdadeira e mais de seis nós do HAA para redundância geográfica.
Observação:
As implantações do Orchestrator de vários nós usam o RESP (Protocolo de Serialização do Redis) para a comunicação, e, assim, podem ser configuradas usando qualquer solução que esteja usando esse protocolo.
O HAA é a única solução compatível com o UiPath.
A configuração de hardware para cada servidor necessário depende do tamanho da sua implantação, conforme detalhado abaixo. Os requisitos de hardware apresentados aqui foram feitos com base em testes em que um Robô foi definido da seguinte maneira:
- as mensagens são enviadas do Robô para o Orchestrator com uma frequência de 1 mensagem por segundo
- dentro de 60 segundos, o Robô envia:
- 15 mensagens de log
- 2 pulsações
- 6 solicitações de ativos
- 6 solicitações de adição de item de fila
- 6 solicitações de itens de fila
Suporte para até 250 Robôs não assistidos
Servidor de Aplicativo da Web
|
Número de Robôs |
Núcleos de CPU (min 2 GHz) |
RAM (GB) |
HDD (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. Para fazer isso, adicione o parâmetro Max Pool Size=500 à string de conexão, para que ela fique semelhante a este exemplo:
<add name="Default" providerName="System.Data.SqlClient" connectionString="Server=SQL4142;Integrated Security=True;Database=UiPath;Max
Pool Size=500;" />
SQL Server
|
Número de Robôs |
Núcleos de CPU (min 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<20 |
4 |
8 |
100 |
|
<50 |
4 |
8 |
200 |
|
<100 |
4 |
8 |
300 |
|
<200 |
8 |
8 |
SSD 400 |
|
<250 |
8 |
16 |
SSD 400 |
Os requisitos de espaço de disco dependem muito de:
- Se as filas de trabalho são usadas ou não. Se as filas de trabalho forem usadas, isso depende do número médio de transações adicionadas diariamente/semanalmente e tamanho (número de campos, tamanho de cada campo) de cada transação.
- O período de retenção para itens de fila processados com sucesso (o cliente deve implementar sua própria política de retenção).
- Se as mensagens registradas pelos Robôs são armazenadas ou não no banco de dados. Se eles forem armazenadas, um filtro pode ser aplicado apenas para armazenar em níveis específicos de DB das mensagens (por exemplo, armazenar no DB as mensagens com o nível de log Error e Critical, e armazenar em mensagens Elasticsearch com o nível de log Info, Warn e Trace).
- Frequência de registro em log - o desenvolvedor do Robô usa a atividade Log Message à vontade, sempre que eles consideram que uma mensagem deve ser registrada.
- O período de retenção para mensagens registradas antigas (o cliente deve implementar sua própria política de retenção).
- Valor do nível de registro em log configurado no Robô. Por exemplo, se o nível de registro em log no robô for definido como Informações, apenas as mensagens com os níveis Info, Warn, Error e Critical são enviadas para o Orchestrator, as mensagens com os níveis Debug, Trace e Verbose são ignoradas, elas não alcançarão o Orchestrator.
Servidor Elasticsearch
|
Número de Robôs |
Núcleos de CPU (min 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<20 |
4 |
4 |
100 |
|
<50 |
4 |
4 |
100 |
|
<100 |
4 |
8 |
150 |
|
<200 |
4 |
12 |
200 |
|
<250 |
4 |
12 |
300 |
Os requisitos de espaço de disco dependem de:
- O período de retenção (o cliente deve implementar sua própria política de retenção).
- Frequência de registro em log - o desenvolvedor do Robô usa a atividade Log Message à vontade, sempre que eles consideram que uma mensagem deve ser registrada.
- Valor do nível de registro em log configurado no Robô. Por exemplo, se o nível de registro em log no Robô for definido como Informações, apenas as mensagens com os níveis Info, Warn, "Error" e "Critical" são enviadas para o Orchestrator; as mensagens com os níveis "Debug", "Trace" e "Verbose" são ignoradas, elas não alcançarão o Orchestrator.
Observação: Para mais de 50 Robôs, você precisa instruir a Máquina Virtual Java usada pelo Elasticsearch a usar 50% da RAM disponível, definindo os argumentos
-Xmxe-Xmsà metade da quantidade total de memória. Isso é feito por meio da variável de ambienteES_JAVA_OPTSou editando o arquivojvm.options.
Suporte entre 250 e 500 Robôs não assistidos
Servidor de Aplicativo da Web
|
Número de Robôs |
Núcleos de CPU (min 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
8 |
8 |
200 |
|
<400 |
8 |
8 |
220 |
|
<500 |
16 |
16 |
250 |
SQL Server
|
Número de Robôs |
Núcleos de CPU (min 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
16 |
32 |
SSD 400 |
|
<400 |
16 |
32 |
SSD 500 |
|
<500 |
16 |
32 |
SSD 600 |
Para mais de 300 Robôs, considere não armazenar todas as mensagens registradas no banco de dados do SQL Server. Armazene no DB apenas as mensagens com o nível de registro em log Error e Critical. Armazene todas as mensagens (incluindo Error e Critical) no Elasticsearch.
Servidor Elasticsearch
|
Número de Robôs |
Núcleos de CPU (min 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
4 |
12 |
300 |
|
<400 |
4 |
16 |
500 |
|
<500 |
4 |
16 |
600 |
A seção a seguir é um exemplo de uma implantação grande e escalável usando as ofertas do Azure Infrastructure como Serviço (IaaS). Esta configuração foi usada:
- Conjunto de disponibilidade da VM para Orchestrator
- Conjunto de Disponibilidade de VM para Elasticsearch
- Windows Server SQL VM
- Balanceador de carga do Azure
- Serviço DNS distribuído (como o Cloudflare)
Arquitetura
Os exemplos de arquitetura abaixo contêm componentes opcionais e/ou diferentes (por exemplo, CyberArk, Suplemento de Alta Disponibilidade da UiPath).
O Jumpbox apresentado não é necessário, mas é uma prática recomendada para seus ambientes de produção, fornecendo isolamento e segurança.
Arquitetura de nó único
Arquitetura de vários nós
Requisitos de Hardware
Esta seção descreve as configurações de hardware usadas para os testes de desempenho listados em Escalando sua Implantação, abaixo.
Nós do Orchestrator
Cada nó do Orchestrator deve ser configurado da seguinte maneira:
|
VCPUs |
RAM (GB) |
SSD (GB) |
|---|---|---|
|
16 |
32 |
128 |
SQL Server
As especificações da máquina virtual do SQL Server devem ser escaladas de acordo com o número de nós do Orchestrator:
|
Nós do Orchestrator |
VCPUs |
RAM (GB) |
Disk |
|---|---|---|---|
|
1-2 |
8 |
16 |
1TB - disco ultra SSD para o banco de dados, tempDB e log transacional |
|
5 |
16 |
32 |
1TB - disco ultra SSD para o banco de dados 1TB - disco ultra SSD para tempDB 1TB - disco ultra SSD para o log transacional |
|
10 |
32 |
64 |
1TB - disco ultra SSD para o banco de dados 1TB - disco ultra SSD para tempDB 1TB - disco ultra SSD para o log transacional |
|
15 |
40 |
96 |
1TB - disco ultra SSD para o banco de dados 1TB - disco ultra SSD para tempDB 1TB - disco ultra SSD para o log transacional |
Conjunto de Disponibilidade do Elasticsearch
O conjunto de disponibilidade do Elasticsearch é composto de 3 nós mestre e 6 nós de dados, para um total de 9 nós, cada um com as seguintes especificações:
|
VCPUs |
RAM (GB) |
OS SSD (GB) |
Data SSD (TB) |
|---|---|---|---|
|
8 |
16 |
128 (com 5000 IOPS e 100 MB/s Throughput) |
1 (com 5000 IOPS e 200 MB/s Throughput) |
Requisitos de software
As versões listadas acima são aquelas usadas para implantações e cargas de desempenho testadas descritas.
Balanceamento de carga
Para implantações de vários nós, é recomendável usar dois balanceadores de carga Azure Standard:
- Um para os servidores do Orchestrator;
- Um para os servidores Elasticsearch.
Complemento de alta disponibilidade
-
para o Orchestrator (mais de três nós do HAA são necessários para alta disponibilidade verdadeira e mais de seis nós do HAA para redundância geográfica.
Importante:As implantações do Orchestrator de vários nós usam o RESP (Protocolo de Serialização do REdis) para a comunicação, e, assim, podem ser configuradas usando qualquer solução que implemente esse protocolo.
As implantações de alta disponibilidade do Orchestrator são compatíveis com a UiPath apenas se o High Availability Add-on da UiPath for usado.
Escalando sua Implantação
O número de nós necessários no seu conjunto de escala do Orchestrator depende do número de Robôs que estão sendo implantados:
|
Nós do Conjunto de Escala do Orchestrator |
Núm. de Robôs |
|---|---|
|
1 |
até 6.000 |
|
2 |
até 14.000 |
|
5 |
até 80.000 |
|
10 |
até 200.000 |
|
15 |
até 300.000 |
Essas implantações foram testadas usando as configurações de hardware e software acima para exibir nenhuma perda de desempenho sob a carga especificada abaixo.
Teste de desempenho
Os dados exibidos nas duas tabelas seguintes são representativos de uma implantação assistida.
Dados estáticos
Os dados estáticos se referem à carga inicial do Orchestrator.
|
Entidade |
Um nó |
Dois nós |
Cinco nós |
Dez nós |
Quinze nós |
|---|---|---|---|---|---|
|
Tenants |
1 |
1 |
1 |
1 |
1 |
|
Pastas |
1 |
2 |
4 |
4 |
6 |
|
Robôs |
6.000 |
14.000 |
80.000 |
200.000 |
300.000 |
|
Pacotes |
8.000 |
16.000 |
48.000 |
48.000 |
48.000 |
|
Processos |
4.000 |
8.000 |
24.000 |
24.000 |
24.000 |
|
Filas |
600 |
1.200 |
1.800 |
2.400 |
3.000 |
|
Itens de Fila |
1.120.000 |
1.500.000 |
3.000.000 |
5.000.000 |
7,000,000 |
|
Ativos |
500 |
1.000 |
1.500 |
3.000 |
4.500 |
Dados dinâmicos
Os dados dinâmicos se referem aos dados adicionados ou alterados no Orchestrator, pois os processos são executados.
|
Entidade |
Um nó |
Dois nós |
Cinco nós |
Dez nós |
Quinze nós |
|---|---|---|---|---|---|
|
Itens de fila (por dia) |
300.000 |
600.000 |
4.000.000 |
9.000.000 |
10.500.000 |
|
Trabalhos (por minuto) |
700 |
1.500 |
3.000 |
6.000 |
7.500 |
|
Logs (por minuto) |
20,000 |
50.000 |
300.000 |
600.000 |
800,000 |
|
Downloads do Nuget (máximo por minuto) |
1.000 |
3.000 |
10,000 |
14.000 |
18.000 |
|
Robôs conectados (máximo) |
6.000 |
14.000 |
80.000 |
200.000 |
300.000 |
|
Pulsação (por minuto) |
12.000 |
28.000 |
160.000 |
400.000 |
600.000 |
|
Robôs ocupados |
3.000 |
7.000 |
40.000 |
100.000 |
150.000 |
|
Robôs disponíveis |
3.000 |
7.000 |
40.000 |
100.000 |
150.000 |
As seguintes seções oferecem um insight sobre os recursos de uma implantação PaaS em termos de desempenho.
Arquitetura
Os seguintes pré-requisitos são necessários:
-
Orchestrator:
- Plano de Serviço de Aplicativo do Orchestrator: 20 instâncias P3V2
- Azure SQL Server: Premium P15: 4000 DTUs
- Cache do Azure Redis P2 Premium 13 GB
-
Identity Server:
- Plano de Serviço de Aplicativo do Identity Server: 2 instâncias P3V2
- Azure SQL Server: Standard S7: 800 DTU
-
Elasticsearch:
Teste de desempenho
Os dados exibidos nas seguintes tabelas são representativos de uma implantação assistida.
Dados estáticos
Os dados estáticos se referem à carga inicial do Orchestrator.
|
Entidade |
Um nó |
|---|---|
|
Tenants |
1 |
|
Pastas |
8.000 |
|
Robôs |
80.000 |
|
Pacotes |
8.000 |
|
Processos |
8.000 |
|
Filas |
8.000 |
|
Itens de Fila |
2.000.000 |
|
Ativos |
8.000 |
Dados dinâmicos
Os dados dinâmicos se referem aos dados adicionados ou alterados no Orchestrator, pois os processos são executados.
|
Entidade |
Um nó |
|---|---|
|
Itens de fila (por dia) |
5.000.000 |
|
Trabalhos (por minuto) |
2.600 |
|
Logs (por minuto) |
240.000 |
|
Downloads do Nuget (máximo por minuto) |
2.000 |
|
Robôs conectados (máximo) |
80.000 |
|
Pulsação (por minuto) |
160.000 |
|
Robôs ocupados |
40.000 |
|
Robôs disponíveis |
40.000 |
|
Porta |
Description |
|---|---|
|
443 | Porta padrão para a comunicação entre Usuários e Orchestrator com os Robôs conectados. |
|
1433 | Porta padrão para a comunicação entre o Orchestrator e a máquina SQL Server. |
|
9200 | Comunicação entre o Orchestrator e o Elasticsearch. |
|
9300 | Comunicação entre os nós do Elasticsearch, se aplicável. |
|
5601 | Porta padrão usada pelo plug-in do Kibana, se aplicável. |
|
3389 | Obrigatório para a automação de RDP, necessário para Robôs de Alta Densidade. |
Você também pode verificar os requisitos de hardware para o Studio e UiPath Robot.
