Alta disponibilidad (HA)

IBM® watsonx.data utiliza regiones multizona (MZR) tanto en IBM Cloud como en AWS para proporcionar una alta disponibilidad. Los distintos componentes de watsonx.data se despliegan en configuraciones Active-Active y Active-Only para ayudar a garantizar una alta disponibilidad y resistencia.

Activo-Activo

En una configuración Activo-Activo, varias instancias de un componente se ejecutan simultáneamente en diferentes Zonas de Disponibilidad (AZ). Estas instancias están equilibradas en carga y pueden gestionar peticiones en paralelo.

Características principales:

• Redundancia - Si una instancia o AZ falla, las demás continúan sirviendo tráfico sin interrupción.
• Distribución de la carga: el tráfico se distribuye entre todas las instancias activas, lo que mejora el rendimiento y reduce la latencia.
• Conmutación automática: no es necesaria la intervención manual; el sistema redirige el tráfico automáticamente.

Ventajas:

• Alta tolerancia a fallos.
• Experiencia de usuario fluida durante los fallos de zona.
• Mejor uso de los recursos.

En watsonx.data la mayoría de los componentes se despliegan en configuración Activo-Activo con réplicas en múltiples zonas para ayudar a garantizar una disponibilidad continua. Por ejemplo, Metadata Services (MDS) en el plan Enterprise.

Sólo activo

En una configuración Active-Only, un componente sólo se ejecuta en una Zona de Disponibilidad a la vez. Si esa zona falla, el componente debe reiniciarse o volver a desplegarse en otra zona.

Características principales:

• Una única instancia activa por componente.
• Reinicio automático en una nueva zona en caso de fallo.
• Ligero retraso durante la conmutación por error debido al tiempo de reinicio.

Ventajas:

• Arquitectura más sencilla.
• Reducción del consumo de recursos.
• Resiliencia con un breve tiempo de inactividad durante la conmutación por error.

En watsonx.data, los componentes de un solo inquilino se despliegan en configuración Active-Only. Estos componentes de un solo inquilino, que incluyen el motor Presto y los componentes de metastore, están distribuidos estratégicamente en tres AZ para garantizar la capacidad y la conmutación por error. Estos componentes se reinician en una nueva zona durante la anomalía. Por ejemplo, Metadata Services (MDS) en el plan Lite.

En las regiones multizona (MZR), Presto y MDS se distribuyen por distintas zonas.

Cuando una zona de disponibilidad única falla en un MZR, o se produce un error de hardware en cualquier región, las cargas de trabajo fallan automáticamente y se reinician en otras zonas dentro de esa región. Cada instancia de watsonx.data viene con un grupo de metadatos entre regiones predeterminado y un grupo de prueba opcional (10 GB). Ambos buckets están habilitados con IBM Cloud® Object Storage Versioning. La copia de seguridad de los datos se realiza habilitando la replicación en una cuenta IBM Cloud Object Storage independiente. Sin embargo, para cualquier bucket externo que el cliente introduzca en la instancia watsonx.data, el cliente es responsable de esas copias de seguridad.

En un desastre regional, recibe un correo electrónico que incluye todos los pasos que necesita seguir. Consulte las responsabilidades de watsonx.data. Los componentes de un solo arrendatario operan en un modelo 'Sólo activo', lo que garantiza un reinicio inmediato en los nuevos nodos que proporcionan el mismo servicio si se produce una anomalía.

Los componentes de un solo arrendatario se distribuyen estratégicamente en 3 AZs para mejorar la fiabilidad. Cuando un AZ falla, se garantiza la capacidad suficiente para iniciar los servicios necesarios en las AZ disponibles. Esto minimiza cualquier impacto causado por una parada de AZ.

Responsabilidades

Alta disponibilidad a nivel de aplicación

Las aplicaciones que se comunican a través de redes y servicios en la nube están sujetas a errores de conexión transitorios. Diseñe las aplicaciones para reintentar las conexiones cuando una pérdida temporal en la conectividad con el despliegue o con IBM Cloud, provoque errores. Como watsonx.data es un servicio gestionado, las actualizaciones y el mantenimiento periódicos forman parte de las operaciones normales. Dicho mantenimiento ocasionalmente provoca una interrupción temporal del servicio.

Las aplicaciones deben estar diseñadas para manejar interrupciones temporales en el servicio, implementar el manejo de errores para los mandatos fallidos e implementar la lógica de reintento para recuperarse de una interrupción temporal.

A continuación se muestran algunos de los códigos de error que se pueden esperar durante las interrupciones temporales del servicio:

Si se reinicia un nodo coordinador Presto, ya sea por motivos de mantenimiento o debido a una anomalía del sistema, es necesario que las aplicaciones restablecen su conexión con el motor Presto.

No se esperan varios minutos de indisponibilidad o interrupciones de la conexión. Abre un ticket de soporte con detalles si tienes periodos de tiempo superiores a un minuto sin conectividad para que se investiguen las interrupciones.

Estrategia de recuperación tras desastre

El objetivo de tiempo de recuperación (RTO) se refiere a la duración máxima aceptable de tiempo que un sistema o servicio puede no estar disponible después de un fallo. Define la rapidez con la que debe restablecerse el sistema para evitar una interrupción significativa de las operaciones. RTO en watsonx.data depende de los siguientes aspectos:

• El punto de copia de seguridad más reciente.
• Estado del archivo de registro.
• Pasos manuales necesarios para la restauración de metadatos.

El objetivo de punto de recuperación (RPO) se refiere a la cantidad máxima aceptable de pérdida de datos en caso de fallo. Indica la distancia en el tiempo a la que el sistema puede recuperar los datos, basándose en la copia de seguridad o instantánea correcta más reciente. La recuperación se basa en la última copia de seguridad de metadatos y el último archivo de registro realizados correctamente. Puede haber un retraso entre el fallo y el estado restaurado.

Para reforzar la resistencia de los datos y minimizar las posibles pérdidas, se ha aumentado la frecuencia de las copias de seguridad del servicio Milvus en el entorno SaaS. Este cambio reduce el Objetivo de Punto de Recuperación (RPO) a sólo 2 horas, garantizando que los datos puedan restaurarse desde un punto mucho más reciente en caso de fallo.

Ubicaciones