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.

Infraestructura

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.

Administración

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.

Origen de datos

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.

SQL Server debe configurarse en el grupo de disponibilidad AlwaysOn o en el grupo de fallos. Debe estar repartido en ambos sitios para garantizar una alta disponibilidad precisa cuando un sitio está inactivo. Ambos clústeres deben utilizar el mismo punto final de recepción de SQL en la cadena de conexión. Además, se recomienda establecer la propiedad 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.

Importante:

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.

Objetivo de tiempo de 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, 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.

Gestor de tráfico

Puedes reducir el tiempo de recuperación configurando el Gestor de tráfico para que dirija siempre el tráfico al clúster principal cuando esté disponible. La redirección al clúster secundario debe realizarse solo cuando el clúster principal está inactivo. Esto garantiza que el cambio de tráfico sea automático y reduce el tiempo de un cambio manual. Puedes utilizar los puntos finales de estado de ambos clústeres para lograrlo.

Disponibilidad de los nodos

Si todos los nodos del clúster secundario se están ejecutando, puedes ahorrar tiempo activando los nodos y esperando a que el clúster esté activo. Sin embargo, esto puede multiplicar casi por dos el coste de tu infraestructura.

Disponibilidad de la carga de trabajo dinámica

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.

Gestión de configuración

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 no se requiere ningún esfuerzo adicional durante la fase de recuperación.

Objetivo de punto de 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.

Sincronización de datos

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.

Copia de seguridad programada

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.