- Información general
- Requisitos
- Recomendado: plantillas de implementación
- Manual: preparar la instalación
- Manual: preparar la instalación
- Paso 1: configurar el registro compatible con OCI para las instalaciones sin conexión
- Paso 2: configurar el almacén de objetos externo
- Paso 3: configurar High Availability Add-on
- Paso 4: configurar Microsoft SQL Server
- Paso 5: configurar el equilibrador de carga
- Paso 6: configurar el DNS
- Paso 7: configurar el kernel y la configuración del sistema operativo
- Paso 8: configurar los discos
- Paso 9: configurar los puertos de nodo
- Paso 10: aplicar ajustes diversos
- Paso 12: Validar e instalar los paquetes RPM necesarios
- Paso 13: Generar cluster_config.json
- Configuración de certificados
- Configuración de la base de datos
- Configuración del almacén de objetos externo
- Configuración de URL prefirmada
- Configuración de registro externo compatible con OCI
- Disaster recovery: configuraciones activas/pasivas y activas/activas
- Configuración de High Availability Add-on
- Configuración específica de Orchestrator
- Configuración específica de Insights
- Process Mining-specific configuration
- Configuración específica de Document Understanding
- Automation Suite Robots-specific configuration
- Configuración de la supervisión
- Opcional: configurar el servidor proxy
- Opcional: habilitación de la resistencia a fallos de zona en un clúster multinodo de producción preparada para alta disponibilidad
- Opcional: pasar resolv.conf personalizado
- Optional: Increasing fault tolerance
- parámetros de install-uipath.sh
- Inclusión de un nodo agente dedicado compatible con GPU
- Añadir un nodo agente dedicado a Task Mining
- Conexión de la aplicación Task Mining
- Añadir un nodo agente dedicado a Automation Suite Robots
- Paso 15: configurar el registro temporal de Docker para las instalaciones sin conexión
- Paso 16: validar los requisitos previos para la instalación
- Manual: realizar la instalación
- Después de la instalación
- Administración de clústeres
- Gestionar los productos
- Primeros pasos con el Portal de administración del clúster
- Migrating objectstore from persistent volume to raw disks
- Migrar del en el clúster a High Availability Add-on externo
- Migrating data between objectstores
- Migrating in-cluster objectstore to external objectstore
- Cambiar manualmente al clúster secundario en una configuración activa/pasiva
- Disaster Recovery: realizar operaciones posteriores a la instalación
- Convertir una instalación existente en una configuración en varios sitios
- Directrices sobre la actualización de una implementación activa/pasiva o activa/activa
- Directrices sobre la copia de seguridad y restauración de una implementación activa/pasiva o activa/activa
- Redirecting traffic for the unsupported services to the primary cluster
- Supervisión y alertas
- Migración y actualización
- Paso 1: Mover los datos de la organización de identidad de independiente a Automation Suite
- Paso 2: restaurar la base de datos del producto independiente
- Paso 3: Realizar una copia de seguridad de la base de datos de la plataforma en Automation Suite
- Paso 4: Fusionar organizaciones en Automation Suite
- Paso 5: actualizar las cadenas de conexión de los productos migrados
- Paso 6: migrar el Orchestrator independiente
- Paso 7: migrar Insights independiente
- Paso 8: eliminar el tenant predeterminado
- B) Migración de tenant único
- Migrar de Automation Suite en Linux a Automation Suite en EKS / AKS
- Actualizar Automation Suite
- Descargar los paquetes de instalación y obtener todos los archivos del primer nodo del servidor
- Recuperar la última configuración aplicada del clúster
- Actualizar la configuración del clúster
- Configurar el registro compatible con OCI para las instalaciones sin conexión
- Migrar a un registro externo compatible con OCI
- Ejecutar la actualización
- Realizar operaciones posteriores a la actualización
- Configuración específica del producto
- Uso de la herramienta de configuración de Orchestrator
- Configurar parámetros de Orchestrator
- Configuración de Orchestrator
- Configurar AppSettings
- Configurar el tamaño máximo de la solicitud
- Anular la configuración de almacenamiento a nivel de clúster
- Configurar almacenes de credenciales
- Configurar clave de cifrado por tenant
- Buenas prácticas y mantenimiento
- Solución de problemas
- Cómo solucionar los problemas de los servicios durante la instalación
- Cómo desinstalar el clúster
- Cómo limpiar los artefactos sin conexión para mejorar el espacio en disco
- Cómo borrar datos de Redis
- Cómo habilitar el registro de Istio
- Cómo limpiar manualmente los registros
- Cómo limpiar los registros antiguos almacenados en el paquete sf-logs
- Cómo deshabilitar los registros de transmisión para AI Center
- Cómo depurar instalaciones de Automation Suite fallidas
- Cómo eliminar imágenes del instalador antiguo después de la actualización
- Cómo deshabilitar la descarga de la suma de comprobación de NIC
- Cómo actualizar desde Automation Suite 2022.10.10 y 2022.4.11 a 2023.10.2
- Cómo establecer manualmente el nivel de registro de ArgoCD en Info
- No se puede ejecutar una instalación sin conexión en el sistema operativo RHEL 8.4
- Error al descargar el paquete
- La instalación sin conexión falla porque falta un binario
- Problema de certificado en la instalación sin conexión
- First installation fails during Longhorn setup
- Error de validación de la cadena de conexión SQL
- Error en la comprobación de requisitos previos para el módulo iscsid de selinux
- Azure disk not marked as SSD
- Fallo tras la actualización del certificado
- El antivirus causa problemas de instalación
- Automation Suite not working after OS upgrade
- Automation Suite requiere que backlog_wait_time se establezca en 0
- El volumen no se puede montar porque no está listo para las cargas de trabajo
- Cluster unhealthy after automated upgrade from 2021.10
- Upgrade fails due to unhealthy Ceph
- RKE2 no se inicia debido a un problema de espacio
- El volumen no se puede montar y permanece en estado de bucle de conexión/desconexión
- La actualización falla debido a objetos clásicos en la base de datos de Orchestrator
- El clúster de Ceph se encuentra en un estado degradado tras una actualización en paralelo.
- Un componente Insights en mal estado provoca el fallo de la migración
- La actualización del servicio falla para Apps
- Tiempos de actualización in situ
- La migración del registro de Docker se atasca en la fase de eliminación de PVC
- Fallo de aprovisionamiento de AI Center después de actualizar a 2023.10
- La actualización falla en entornos sin conexión
- Establecer un intervalo de tiempo de espera para los portales de gestión
- La autenticación no funciona tras la migración
- kinit: no se puede encontrar la KDC para el territorio <AD Domain> mientras se obtienen las credenciales iniciales
- kinit: keytab no contiene claves adecuadas para *** mientras se obtienen las credenciales iniciales
- Error en la operación GSSAPI debido a un código de estado no válido
- Alarma recibida por un error en el trabajo de Kerberos-tgt-update
- Proveedor de SSPI: servidor no encontrado en la base de datos de Kerberos
- Error en inicio de sesión de un usuario AD debido a una cuenta deshabilitada
- ArgoCD login failed
- Actualizar las conexiones del directorio subyacente
- Fallo en la obtención de la imagen de Sandbox
- Los pods no se muestran en la interfaz de usuario de ArgoCD
- Fallo de la sonda Redis
- El servidor RKE2 no se inicia
- Secreto no encontrado en el espacio de nombres UiPath
- ArgoCD entra en estado de progreso tras la primera instalación
- Pods MongoDB en CrashLoopBackOff o pendientes de aprovisionamiento de PVC tras su eliminación
- Unhealthy services after cluster restore or rollback
- Pods atascados en Inicialización: 0 / X
- Faltan métricas de Ceph-rook en los paneles de supervisión
- Document Understanding no se encuentra en la barra izquierda de Automation Suite
- Estado fallido al crear una sesión de etiquetado de datos
- Estado fallido al intentar implementar una habilidad ML
- El trabajo de migración falla en ArgoCD
- El reconocimiento de la escritura manual con el extractor de formularios inteligente no funciona
- Ejecutar la herramienta de diagnóstico
- Uso de la herramienta del paquete de soporte de Automation Suite
- Explorar registros
Basic architecture considerations
Al igual que con cualquier implementación en varios sitios, las consideraciones de arquitectura principales para Automation Suite tienen en cuenta la infraestructura, la latencia, el origen de datos, la gestión, el objetivo de tiempo de recuperación, el objetivo de punto de recuperación, etc.
Recomendamos utilizar el mismo hardware para ambos clústeres. Sin embargo, el clúster de Automation Suite probablemente funcionará con configuraciones de hardware similares con poca diferencia. El hardware Heterogeneo puede aumentar la complejidad y ralentizar la resolución de problemas.
La latencia tiene una importancia crucial en el diseño de un modelo activo/activo. Denota el tiempo de ida y vuelta (RTT) entre los dos clústeres de Automation Suite. Un nivel de latencia mínimo entre los dos sitios es óptimo, ya que reduce en gran medida el riesgo de pérdida de datos durante una interrupción del servicio. El RTT debe estar por debajo de un umbral de 10 ms.
Debes probar rigurosamente el RTT antes de pasar a la etapa de producción, debido a su efecto directo en las métricas de rendimiento. Si la latencia supera el punto de referencia de 10 ms entre el par de sitios, recomendamos considerar una configuración activa/pasiva en lugar de una configuración activa/activa.
Cualquier componente que requiera la sincronización debe tener un RTT de menos de 10 ms. Esto incluye servidores SQL, HAA, almacén de objetos, etc.
Los dos clústeres de Automation Suite son independientes y no comparten ninguna configuración. Por tanto, cualquier actividad de gestión o mantenimiento debe realizarse de forma individual en estos clústeres. Por ejemplo, debes actualizar las cadenas de conexión SQL en ambos clústeres, configurar certificados por separado, etc. Además, debes supervisar los dos clústeres de forma independiente, actualizarlos de forma individual, etc.
El almacén de objetos, combinado con la base de datos SQL, forma el estado de un producto instalado en Automation Suite.
La configuración de SQL Server desempeña un rol vital en una implementación en varios sitios. Aunque SQL Server es un componente externo a Automation Suite, se requieren algunos pasos adicionales para garantizar la alta calidad de vida verdadera al trabajar con Automation Suite.
MultiSubnetFailover=True en la cadena de conexión cuando SQL Server o las bases de datos se distribuyen en varias subredes.
Para obtener más detalles, consulta Grupos de disponibilidad AlwaysOn y Requisitos previos, Restricciones y recomendaciones para grupos de disponibilidad AlwaysOn.
El almacén de objetos externo es inmune a una posible corrupción debida a un fallo de nodo. La replicación de datos y Disaster Recovery pueden realizarse de forma independiente de Automation Suite. Al igual que SQL Server, el almacén de objetos externo debe tener una configuración de Disaster Recovery de alta disponibilidad. La instancia del almacén de objetos principal se encuentra físicamente ubicado en el centro de datos principal y al menos una instancia secundaria se encuentra en el centro de datos secundario con la sincronización de datos habilitada. Puedes configurar un equilibrador de carga en el almacén de objetos para garantizar que ambos clústeres de Automation Suite hagan referencia a los mismos puntos de conexión. Esto hace que la implementación sea independiente de la configuración interna del almacén de objetos.
Para AWS S3, el punto de acceso multiregión no admite todas las API de s3 necesarias para todos los productos que se ejecutan en Automation Suite. Para obtener más detalles sobre la lista de API compatibles, consulta Utilizar puntos de acceso en varias regiones con operaciones de API compatibles.
Puedes crear dos depósitos por producto/suite en ambas regiones y habilitar la sincronización. El clúster de Automation Suite que se ejecuta en la misma región hará referencia a los depósitos de esa región.
La política de tu organización respecto al objetivo de punto de recuperación es vital para diseñar tu clúster de Automation Suite en varios sitios. Para lograr el objetivo de punto de recuperación deseado, ten en cuenta los siguientes aspectos:
- Diseño del Gestor de tráfico;
- Disponibilidad de los nodos en el clúster secundario/pasivo;
- Disponibilidad de la carga de trabajo dinámica en el clúster secundario; por ejemplo, MLSkill;
- Gestión de configuración.
Para desbloquear todo el potencial de ambos clústeres, es crucial configurar Traffic Manager de forma adecuada. La configuración ideal debe facilitar la distribución del tráfico a ambos clústeres. Esta estrategia no solo garantiza una distribución de carga equilibrada, sino que también protege la continuidad del negocio, mitigando cualquier posible interrupción si cualquiera de los sitios experimenta un cierre completo.
En el caso de un desastre que haga que un sitio se vuelva completamente no operativo, el otro sitio debe tener la capacidad suficiente para garantizar que la automatización del negocio no se vea afectada. La capacidad insuficiente en el sitio en funcionamiento puede afectar negativamente a la ejecución de la empresa y potencialmente provocar problemas operativos significativos.
Algunos productos, como AI Center, implementan las habilidades de ML de forma dinámica en el runtime. La implementación de las habilidades en otro clúster es siempre asíncrona. Ello no garantiza su disponibilidad. Para garantizar que tu solución de automatización se vuelva a conectar a la hora deseada, puedes sincronizar de manera periódica las habilidades en otro clúster.
Dado que las implantaciones en varios sitios de Automation Suite constan de dos clústeres distintos, cualquier operación realizada en cualquier clúster debe realizarse a tiempo en el otro clúster para reducir la desviación. Esto garantiza que ambos clústeres posean configuraciones similares y que no se requiera un esfuerzo adicional durante la recuperación.
La política de tu organización respecto al objetivo de punto de recuperación es vital para diseñar tu clúster de Automation Suite en varios sitios. Para lograr el objetivo de punto de recuperación deseado (RPO, por sus siglas en inglés), debes tener en cuenta los siguientes aspectos:
- Sincronización de datos;
- Copia de seguridad programada.
Cuando se escriben en el origen de datos principal, los datos también deben sincronizarse con el clúster secundario. Sin embargo, existe un riesgo de pérdida de datos cuando el centro de datos está inactivo y los datos no están sincronizados. Ejemplos de configuraciones de red como, por ejemplo, gran ancho de banda y baja latencia entre los dos centros de datos, pueden acelerar la sincronización.
No todos los Disaster Recovery proporcionan inmunidad completa a la pérdida de datos. Sin embargo, puedes implementar una estrategia de copia de seguridad regular y periódica para minimizar el impacto del desastre en la recuperación de datos. Para obtener más detalles, consulta Copia de seguridad y restauración del clúster.
