Arquitectura multinodo y consideración de diseño

Consideraciones de diseño y arquitectura multinodo para Automation Suite en Linux con Kubernetes.

El siguiente diagrama de arquitectura muestra una implementación de Automation Suite en Linux con Kubernetes instalado en seis máquinas, un equilibrador de carga y el almacenamiento de datos. Existen varios tipos de máquinas: tres nodos de servidor, dos nodos de agente y un nodo de agente especializado.

Nodos de servidor

Los nodos del servidor alojan el plano de control de Kubernetes, que controla todo el clúster de Kubernetes. En una implementación multinodo típica, se necesita un número impar de nodos de servidor, siendo tres el número mínimo de servidores. Esta restricción se debe al componente etcd , que forma parte del plano de control de Kubernetes. Para obtener más detalles, consulta la documentación de etcd.

Por la misma razón, la mayoría de los nodos del servidor deben estar disponibles en cualquier momento para mantener el clúster en buen estado.

Estos nodos también alojan los componentes que requieren el almacenamiento de datos en los nodos, como Prometheus, el almacén de objetos en el clúster Ceph, UiPath Insights y el registro de Docker en el clúster.

Nodos agente

Los nodos de agente a veces se llaman nodos de trabajo. El propósito de estos nodos es alojar los servicios de UiPath® y otras capacidades compartidas de la suite. Dado que no hay un disco de datos conectado a estos nodos, no pueden alojar los componentes que requieren el almacenamiento en disco.

Los nodos de agente no imponen ninguna restricción en el número de nodos disponibles en cualquier momento. Mientras el clúster resultante tenga la capacidad suficiente para alojar todos los pods de los nodos perdidos, el clúster funcionará como se espera sin ninguna interrupción.

Nodos de agente especializados

Estos nodos son los nodos de agente especiales dedicados a tareas especiales, como el nodo Robots de Automation Suite para la ejecución de robots y el nodo GPU para el modelo de Document Understanding. No puede alojar otros servicios de UiPath® en estos nodos.

Load balancer

El equilibrador de carga, que se instala fuera de Automation Suite, actúa como punto de entrada para acceder a las aplicaciones alojadas en el clúster de Automation Suite. El equilibrador de carga debe soportar la tolerancia a los fallos del nodo. Todos los nodos del servidor deben configurarse en el equilibrador de carga, pero los nodos de agente también pueden configurarse de forma opcional. Sin embargo, no se requieren nodos de agente especializados.

Cuando los robots intentan acceder a Orchestrator, la llamada aterriza en el equilibrador de carga y luego pasa a cualquiera de los nodos disponibles. Cada nodo también aloja el componente de red llamado Istio, que es una malla de servicios que también actúa como un equilibrador de carga. Cuando Istio recibe la llamada en el nodo, intenta localizar la instancia de Orchestrator en todo el clúster. Una vez que se encuentra, redirigirá la llamada a esa instancia.

Cómo diseñar tu implementación

¿Más máquinas más pequeñas o menos máquinas más grandes?

Depende completamente de ti si eliges más máquinas más pequeñas o menos máquinas más grandes, ya que ambas opciones tienen sus pros y sus contras. Un mayor número de máquinas más pequeñas proporciona una mejor resistencia a la tolerancia a los fallos en los nodos en comparación con un menor número de máquinas más grandes. Al mismo tiempo, también introduce una sobrecarga de gestión adicional.

Por ejemplo, si tu clúster de Automation Suite requiere un 96 vCPU, puedes optar por cualquiera de las siguientes opciones:

• Opción 1: 6 máquinas de 16vCPU cada una.

  • Impacto: perder una máquina solo reduce la capacidad del clúster en 16 vCPU, por lo que solo afecta a los servicios si el clúster resultante no tiene la capacidad para alojar todos los pods. Sin embargo, gestionar 6 máquinas implica un esfuerzo mayor.

• Opción 2: 3 máquinas de 32vCPU cada una

  • Impacto: perder una máquina reduce la capacidad del clúster en 32vCPU, que tiene un impacto importante en Automation Suite. Sin embargo, gestionar 3 máquinas implica un esfuerzo menor.

Para concluir, el diseño de implementación depende del objetivo. Si el objetivo es una mayor tolerancia a los fallos, la mejor opción es más máquinas más pequeñas. Sin embargo, si el objetivo es una menor sobrecarga de gestión, la elección debe ser el menor número de máquinas más grandes.

¿Todos los nodos de servidor en lugar de los nodos de agente?

Si optas por todos los nodos del servidor en lugar de los nodos de agente depende de tu RTO o RPO.

Por ejemplo, digamos que tu Automation Suite necesita 80 vCPU. Puedes lograrlo de la siguiente manera:

• Opción 1: 5 máquinas de servidor con 16 vCPU cada una. Aquí puede perder como máximo 2 nodos de servidor.

  • Recomendado si el objetivo es la resistencia a la pérdida de datos. Aunque se pierdan 2 nodos del servidor, los datos quedarán intactos y se podrán reconstruir a partir de las réplicas restantes.

• Opción 2: 3 nodos de servidores y 2 nodos de agente con 16 vCPU cada uno. Aquí puedes perder 1 nodo de servidor y ambos nodos de agente, por lo que un total de 3 máquinas.

  • Recomendado si el objetivo es la resistencia a la disponibilidad del nodo. Incluso sin 3 máquinas, el clúster seguirá estando disponible con una capacidad limitada y una vez que los nodos vuelvan, se recuperará todo el clúster. Sin embargo, esta configuración es más propensa a la pérdida de datos debido al almacenamiento conectado a los nodos del servidor. Si se pierden 2 nodos del servidor por completo, puede ser difícil reconstruir los datos de nuevo sin restaurarlos a partir de la copia de seguridad.