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 información, consulta Trabajar con réplicas de lectura para Microsoft SQL Server en Amazon RDS, 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

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.

Disponibilidad de los nodos

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.

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 que no se requiera un esfuerzo adicional durante la 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.