Escenarios de implementación

Implementación en línea

Una implementación en línea de Automation Suite es aquella que requiere acceso a Internet durante la instalación y el tiempo de ejecución. Todos los productos de UiPath® y las bibliotecas compatibles se alojan bien en el registro de UiPath® o bien en el almacén 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.

Implementación sin conexión

Una implementación sin conexión (aislada) es una configuración completamente aislada sin acceso a Internet. Este tipo de configuración requiere la instalación de un registro adicional para almacenar todas las imágenes de contenedor y binarios de los productos UiPath®, que se envían en forma de tarball.

Nota:

No se le permite cambiar el método de implementación después de la instalación. Esto significa que no puede cambiar a la instalación sin conexión si la instalación se realiza en línea y viceversa. Le recomendamos elegir su estrategia de implementación después de una consideración detenida.

Automation Suite en la implementación de EKS

Arquitectura de implementación

Puedes hacer referencia a los siguientes diagramas de arquitectura para implementar Automation Suite en EKS.

Implementación en línea

Implementación sin conexión

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 a los siguientes diagramas de arquitectura para implementar Automation Suite en AKS.

Implementación en línea

Implementación sin conexión

Información general

Un clúster AKS se implementa en una sola región donde los nodos de trabajo se distribuyen en los grupos de nodos del sistema y de 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 básicos de UiPath® también se alojan en el mismo grupo de nodos. Los grupos de nodos de usuario adicionales pueden alojar los nodos de trabajo para Automation Suite Robots, Task Mining y 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.

Modos de implementación y casos de uso

Automation Suite admite los siguientes modos de implementación:

Modo de implementación

Descripción

Multinodo: producción, preparada para alta disponibilidad

Compatible para uso de producción. Puedes elegir entre dos variedades de modo multinodo: Modo básico De forma predeterminada, la infraestructura y los componentes compartidos se establecen en modo HA, mientras que todos los servicios se establecen en no HA (el autoescalado horizontal del pod está habilitado con un mínimo de una réplica). Puedes establecer servicios específicos en HA. También tienes la opción de realizar una configuración adicional después de la implementación para tener capacidades completas de alta disponibilidad. Modo HA Alta disponibilidad totalmente habilitada, con alta disponibilidad en el clúster o alta disponibilidad externa.

Instalaciones en modo básico

Las instalaciones en modo Lite ofrecen un proceso de configuración sencillo y con pocos recursos, que incluye todas las características excepto la alta disponibilidad. El modo básico garantiza una gestión flexible de la infraestructura al permitirte habilitar la alta disponibilidad para servicios seleccionados durante o después de la instalación, según sea necesario.

Importante: Puedes utilizar el modo simplificado en producción, pero debes ser consciente de las implicaciones y riesgos de tener servicios sin alta disponibilidad habilitada.

Instalaciones de alta disponibilidad

Las instalaciones multinodo son compatibles con las implementaciones de producción, lo que proporciona una mayor escalabilidad, una mayor fiabilidad y una gestión eficiente de los recursos.