Realizar una actualización en paralelo

La actualización en paralelo de Automation Suite te permite realizar operaciones de actualización de forma segura utilizando un entorno paralelo en lugar de actualizar in situ.

Este método permite a los administradores cambiar el tráfico del antiguo clúster de Automation Suite (por ejemplo, la implementación azul) al nuevo clúster de Automation Suite (por ejemplo, la implementación verde) después de verificar la nueva implementación. Si detectas un problema, puedes volver a la implementación anterior rápidamente.

Al realizar una actualización en paralelo, los dos clústeres paralelos comparten una única licencia.

Requisitos

• Si AI Center está habilitado, asegúrate de cumplir los requisitos de CUDA.
• Requisitos de hardware, dependiendo del modelo que elijas:
  • Actualización en paralelo (clúster de destino de tamaño idéntico): tanto el entorno de origen como el de destino deben cumplir los mismos requisitos de hardware y software.
  • Actualización en paralelo (inicio de nodo único): puedes configurar un clúster de destino de nodo único y luego escalarlo. Asegúrate de cumplir los requisitos de hardware sugeridos por la calculadora de tamaño de instalación de Automation Suite en función de la selección de tu producto y los detalles de uso.
• Requisitos de software: tanto el entorno de origen como el de destino deben cumplir los mismos requisitos de hardware y software.

Migración de datos y responsabilidades

Datos	Mecanismo de actualización
	Estado	Responsabilidad
Sql	Retenido	Cliente
FQDN	Retenido opcional Debes elegir un nuevo FQDN para el nuevo clúster. Opcionalmente, puedes volver al FQDN anterior si es necesario.	Cliente
Paquetes bajo demanda	No migrado Ejecuta un script para ver qué paquetes hay en el clúster. Es necesario propagar manualmente.	Cliente
Certificados	No migrado Debes aportar certificados como parte de la nueva instalación del clúster.	Cliente
Configuración de clústeres	No migrado Debes generar cluster_config.json a partir del clúster de origen original para asignar los mismos servicios a la instalación del nuevo clúster.	Cliente
Alertas y paneles personalizados creados por los usuarios	No migrado Debes volver a configurar las alertas y paneles personalizados después de la actualización.	Cliente
Registros de aplicación/configuración de transmisión de Prometheus creada por los usuarios	No migrado Debes volver a configurar el registro de la aplicación y la transmisión de Prometheus.	Cliente
Cargas de trabajo dinámicas	Depende de la aplicación Los trabajos de entrenamiento del AI Center se han perdido; Las habilidades se conservan.	Habilidades (el script debe ejecutarse después de la actualización): UiPath® Trabajos de formación: cliente
Almacén de objetos	Retenido	Almacén de objetos en el clúster (Ceph): UiPath® Almacén de objetos externo: Cliente
Insights	Retenido	UiPath®
Datos de MongoDB	Retenido Los datos de MongoDB se mueven al SQL de destino.	UiPath®
RabbitMQ	No es necesario	UiPath®
Seguimiento (datos)	No es necesario Los datos de supervisión no se aplican al nuevo clúster. Important: If you do not use the built-in monitoring components, you must set up external monitoring components after the migration upgrade.	N/D
Registro de Docker	No es necesario Debes instalar un registro de Docker en el clúster o llevar un registro de Docker externo.	N/D

Descripción general del proceso

#	Pasos del proceso de actualización
1	Prepara el nuevo clúster: Prepara el archivo cluster_config.json. Instala tu nuevo clúster (solo infraestructura y almacén de objetos en el clúster (si corresponde)). Configura los certificados de CA adicionales.
2	Migra los datos al nuevo clúster: Hidrata el registro de Docker con las imágenes de actualización sin conexión. Pon el clúster en modo de mantenimiento. Clona las bases de datos de tu clúster de origen. Ejecuta el script de migración de datos en el clúster de origen. Si configuraste un almacén de objetos externo, clona los depósitos de almacén de objetos.
3	Completa la actualización: Edita el archivo cluster_config.json para que apunte a las bases de datos y depósitos clonados. Ejecuta el instalador en el clúster de destino. Si no proporcionaste los certificados durante la instalación, actualízalos después de la instalación. Valida si el clúster de destino funciona como se espera. Si has optado por la actualización en paralelo (clúster de destino de tamaño idéntico), puedes actualizar opcionalmente el FQDN del clúster de destino para que sea el mismo que el FQDN del clúster de origen. Como alternativa, puedes utilizar un nuevo FQDN. Si has optado por la actualización en paralelo (inicio de nodo único), puedes actualizar el FQDN más tarde. Habilita la copia de seguridad en el clúster de destino.
4	Escalar el clúster de destino: aplicable solo si has optado por la actualización en paralelo (inicio de nodo único): Realiza la copia de seguridad del clúster de origen (recomendado). Añade nodos de servidor y agente similares a tu clúster de origen. Edita el archivo cluster_config.json . Vuelve a ejecutar el instalador para escalar el clúster en la configuración de alta disponibilidad. Actualiza de forma opcional el FQDN del clúster de destino para que sea el mismo que el del clúster de origen. También puedes usar un nuevo FQDN.

Modelos de actualización en paralelo

Ofrecemos dos modelos para actualizaciones en paralelo:

1. Actualización en paralelo (clúster de destino de tamaño idéntico):
   • Requiere que el clúster de destino tenga los mismos recursos de hardware que el clúster de origen.
   • Listo para el tráfico una vez:

     • La migración de datos se ha completado.

     • Las comprobaciones de cordura se han realizado correctamente.

2. Actualización en paralelo (inicio de nodo único):
   • Comienza con una configuración de nodo único y luego se amplía a una configuración de alta disponibilidad. Esto reduce los requisitos iniciales de hardware necesarios para la actualización en paralelo.
   • El hardware para la configuración de nodo único debe cumplir las recomendaciones de la Calculadora de capacidad para la configuración de nodo único.
   • Para escalar:
     • Los nodos del clúster de origen pueden ser dados de baja y añadidos al clúster de destino.
   • Listo para el tráfico una vez:
     • La migración de datos se ha completado.
     • El clúster se escala a multinodo.
     • Las comprobaciones de cordura se han realizado correctamente.

Puedes encontrar una comparación entre los dos modelos en la siguiente tabla:

	Actualización en paralelo (clúster de destino de tamaño idéntico)	Actualización en paralelo (inicio de nodo único)
Requisitos de hardware	Requiere hardware idéntico para los clústeres de origen y destino.	Comienza con un hardware mínimo y se amplía según sea necesario.
Tiempo de inactividad	Tiempo de inactividad mínimo gracias al entorno de destino totalmente redundante.	Mayor tiempo de inactividad debido a las operaciones de escalado de nodos.
Impacto en el clúster de origen	Sin impacto.	Los nodos de origen pueden ser dados de baja y unidos al clúster de destino.
Proceso de reversión	Reversión simple, ya que el origen permanece intacto.	Si la operación de escalado falla en el clúster de destino, la reversión implica reintegrar los nodos en el clúster de origen.
Impacto en los costes	Mayores costes debido a la duplicación de la infraestructura.	Costes más bajos con requisitos de hardware iniciales reducidos.