Consideração de arquitetura e design de vários nós

Considerações de arquitetura e design de vários nós para o Automation Suite no Linux com Kubernetes.

O seguinte diagrama de arquitetura descreve uma implantação do Automation Suite no Linux com o Kubernetes instalado em seis máquinas, um balanceador de carga e armazenamento de dados. Há vários tipos de máquina: três nós do servidor, dois nós de agentes e um nó de agentes especializados.

Nós de servidor

Os nós do servidor hospedam o plano de controle do Kubernetes, que controla todo o cluster do Kubernetes. Em uma implantação típica de vários nós, é necessário um número ímpar de nós de servidor, com o número mínimo de servidores sendo três. Essa restrição é devida ao componente etcd , que faz parte do Plano de controle do Kubernetes. Para obter detalhes, consulte a documentação do etcd.

Pelo mesmo motivo, a maioria dos nós do servidor deve estar disponível a qualquer momento para manter o cluster íntegro.

Esses nós também hospedam os componentes que exigem armazenamento de dados nos nós, como Prometheus, Objectstore Ceph no cluster, UiPath Insights e registro do Docker no cluster.

Nós de agente

Os nós de agentes às vezes são chamados de nós de trabalho. O objetivo desses nós é hospedar serviços da UiPath® e outros recursos de suíte compartilhados.Como não há disco de dados conectado a esses nós, eles não podem hospedar os componentes que exigem armazenamento em disco.

Os nós de agentes não impõem nenhuma restrição no número de nós que devem estar disponíveis a qualquer momento. Enquanto o cluster resultante tiver capacidade suficiente para hospedar todos os pods dos nós perdidos, o cluster funcionará conforme o esperado, sem qualquer interrupção.

Nós de agentes especializados

Esses nós são os nós de agentes especiais dedicados a tarefas especiais, como o nó do Automation Suite Robots para a execução de UiPath Robots e o nó da GPU para o modelo do Document Understanding. Você não pode hospedar outros serviços da UiPath® nesses nós.

Load balancer

O balanceador de carga, que é instalado fora do Automation Suite, atua como um entry point para acessar aplicativos hospedados no cluster do Automation Suite. O balanceador de carga é necessário para enfrentar a tolerância a falhas de nós. Todos os nós do servidor precisam estar configurados no balanceador de carga, mas os nós de agentes também podem ser configurados. No entanto, os nós de agentes especializados não precisam.

Quando os UiPath Robots tentam acessar o Orchestrator, a chamada chega no balanceador de carga e, em seguida, é passada para qualquer um dos nós disponíveis. Cada nó também hospeda o componente de rede chamado Istio, que é um service mesh que também atua como um balanceador de carga. Quando a chamada é recebida pelo Istio que está sendo executado no nó, ele tenta localizar a instância do Orchestrator em todo o cluster. Depois que for encontrada, ele redirecionará a chamada para essa instância.

Como projetar sua implantação

Mais máquinas menores ou menos máquinas maiores?

Isso depende inteiramente de você preferir mais máquinas menores ou menos máquinas maiores, com ambas as opções tendo seus próprios prós e contras. Um número maior de máquinas menores fornece melhor resiliência a tolerância a falhas de nós em comparação com um número menor de máquinas maiores. Ao mesmo tempo, isso também introduz uma sobrecarga de gerenciamento adicional.

Por exemplo, se seu cluster do Automation Suite exigir 96 vCPU, você pode optar por uma das seguintes opções:

• Opção 1: seis máquinas de 16 vCPU cada.

  • Impacto: a perda de uma máquina reduz a capacidade do cluster em apenas 16 vCPU; portanto, isso só afeta os serviços se o cluster resultante não tiver capacidade de hospedar todos os pods. No entanto, o gerenciamento de seis máquinas implica um esforço maior.

• Opção 2: três máquinas de 32 vCPU cada

  • Impacto: a perda de uma máquina reduz a capacidade do cluster em 32 vCPU, o que tem um grande impacto no Automation Suite. No entanto, o gerenciamento de três máquinas implica um esforço menor.

Para concluir, o design da implantação depende do objetivo. Se o objetivo for uma melhor tolerância a falhas, então mais máquinas menores serão a melhor escolha. No entanto, se o objetivo for menos sobrecarga de gerenciamento, o número menor de máquinas maiores deve ser a escolha.

Todos os nós do servidor em vez de nós de agentes?

Sua opção por todos os nós do servidor em vez de nós de agentes depende de seu RTO ou RPO.

Por exemplo, digamos que seu Automation Suite precise de 80 vCPU. Você pode atingir isso da seguinte forma:

• Opção 1: cinco máquinas de servidor com 16 vCPU cada. Aqui, você pode perder no máximo dois nós do servidor.

  • Recomendado se o objetivo for resiliência à perda de dados. Mesmo que dois nós do servidor sejam perdidos, os dados permanecerão intactos e poderão ser recriados a partir das réplicas restantes.

• Opção 2: três nós de servidores e dois nós de agentes com 16 vCPU cada. Aqui, você pode perder um nó do servidor e ambos os nós de agentes; portanto, um total de três máquinas.

  • Recomendado se o objetivo for resiliência à disponibilidade dos nós. Mesmo sem três máquinas, o cluster ainda estará disponível com capacidade limitada, e depois que os nós forem retomados, todo o cluster será recuperado. No entanto, essa configuração é mais propensa à perda de dados devido ao armazenamento conectado aos nós separados. Se dois nós do servidor forem totalmente perdidos, pode ser difícil recriar os dados novamente sem restaurá-los a partir do backup.