Escenarios de implementación

Implementación en línea

Una implementación en línea de Automation Suite requiere acceso a Internet durante la instalación y el tiempo de Runtime. Todos los productos de UiPath y las bibliotecas de soporte están alojados en el registro de UiPath o en la tienda de terceros de confianza de UiPath.

Puede limitar el acceso a Internet con la ayuda de un firewall restringido o un servidor proxy bloqueando todo el tráfico de Internet que no sea el requerido por Automation Suite . Para obtener más información sobre las reglas de firewall o proxy, consulta Configuración del proxy.

Automation Suite en la implementación de EKS

Arquitectura de implementación

Puede hacer referencia al siguiente diagrama de arquitectura para implementar Automation Suite en EKS:

Información general

El diagrama de arquitectura anterior muestra cómo se puede configurar Automation Suite en el clúster de AWS EKS.

Un clúster de EKS se implementa en una sola región de AWS, donde los nodos de trabajo de EC2 están en un grupo de autoescalado distribuido en tres zonas de disponibilidad. La distribución de nodos a través de las zonas de disponibilidad es lo que aporta resistencia al fallo completo de la zona.

Cada zona tiene una subred privada y una subred pública. Los nodos de trabajo EC2 se alojan en una subred privada, mientras que la subred pública aloja una dirección IP elástica y una puerta de enlace Nat. La puerta de enlace Nat es necesaria para conectarse a Internet mientras se accede al plano de control de EKS desde los nodos de trabajo y se conecta al registro de Docker para obtener las imágenes del contenedor para la implementación de Automation Suite .

Las direcciones IP elásticos alojadas en cada subred pública se pasan a Automation Suite durante la instalación para registrarla como un punto final en el que Istio debe escuchar el tráfico entrante. Por la misma razón, el equilibrador de carga de red (NLB) debe usar estos puntos finales para reenviar cualquier solicitud realizada a Automation Suite .

Los orígenes de datos como Amazon RDS para Microsoft SQL Server, el depósito S3, el sistema de archivos elástico y la caché elástica deben configurarse para tener suficiente redundancia en caso de error y se deben acceder desde la subred privada donde se alojan las instancias de trabajo EC2.

Nota:

• Automation Suite no tiene reglas de afinación para garantizar que los pods de trabajadores se distribuyan por igual en la zona. Si hay algún error a nivel de zona, puede haber una degradación momentánea del servicio, que se resolvería cuando el plano de control de EKS mueva automáticamente ese servicio a una nueva zona.

• Insights requiere que los volúmenes de EBS almacenen el panel y los otros metadatos. En AWS, los volúmenes de EBS están vinculados a la zona en la que están presentes y no se mueven cuando la zona está inactiva. Las estadísticas no estarán disponibles hasta que se recupere la zona en la que se programaron.

• EKS no permite el autoescalado por defecto, a diferencia de AKS. Para activar esta característica, normalmente debes instalar y configurar software adicional como Metrics Server y Cluster-Autoscaler, o soluciones alternativas que ofrezcan capacidades de autoescala similares.

Automation Suite en la implementación de AKS

Arquitectura de implementación

Puedes hacer referencia al siguiente diagrama de arquitectura para implementar Automation Suite en AKS:

Información general

Un clúster de AKS se implementa en una única región donde los nodos trabajadores se distribuyen por los grupos de nodos de sistema y usuario. Los componentes principales de AKS (excepto el plano de control) se alojan en el grupo de nodos del sistema, como CNI, CoreDNS, etc. Además, los servicios principales de UiPath también están alojados en el mismo grupo de nodos. Los grupos de nodos de usuarios adicionales pueden alojar los nodos de trabajo para el Automation Suite Robot, Task Mining y la GPU.

Cada grupo de nodos aloja el conjunto de escalado de máquinas virtuales (VMSS), lo que garantiza que los nodos trabajadores se distribuyan en varias zonas para proporcionar resistencia a errores de zona y escalar cuando sea necesario.

La dirección IP estática asociada con el equilibrador de carga se pasa a Automation Suite durante la instalación para registrarla como un punto final en el que Istio debe escuchar cualquier tráfico entrante. Por la misma razón, Azure Carga Equilibrador (L4) debe usar estos puntos de conexión para reenviar cualquier solicitud a Automation Suite .

Los orígenes de datos como Microsoft SQL Server, la cuenta de almacenamiento de Azure y la caché de Azure Redis deben configurarse para tener suficiente redundancia en caso de error y se deben acceder a ellos desde la subred donde se alojan los nodos de trabajo de AKS.

Además, puede ser necesario un servidor de salto / bastión adicional, que puede tener todos los privilegios necesarios para operar el clúster de AKS.

Nota:

Automation Suite no tiene reglas de afinación para garantizar que los pods de trabajadores se distribuyan por igual en la zona. Si hay algún error a nivel de zona, puede haber una degradación momentánea del servicio, que se resolverá cuando el plano de control de AKS mueva automáticamente ese servicio a una nueva zona.