Recuperación tras fallos de OpenShift en Google Cloud

La recuperación tras desastres es esencial para mantener la continuidad de las aplicaciones que se han implementado en la plataforma de contenedores OpenShift enGoogle Cloud. En este documento se ofrece una descripción general de las opciones de arquitectura para la recuperación ante desastres con OpenShift en Google Cloud, lo que ayudará a tu organización a minimizar el tiempo de inactividad y a recuperarse rápidamente en caso de desastre.

Este documento está dirigido a administradores de sistemas, arquitectos de la nube y desarrolladores de aplicaciones que se encargan de mantener la disponibilidad y la resiliencia de las aplicaciones en la plataforma de contenedores OpenShift implementada enGoogle Cloud.

Este documento forma parte de una serie que se centra en las estrategias a nivel de aplicación que garantizan que tus cargas de trabajo sigan teniendo una alta disponibilidad y se puedan recuperar rápidamente en caso de fallos. Los documentos de esta serie son los siguientes:

Planificación de DR

La planificación de la recuperación tras desastres es un componente fundamental para ejecutar cargas de trabajo de producción en la nube. Aunque OpenShift y Google Cloud ofrecen una redundancia sólida a nivel de infraestructura, también debes diseñar y configurar tus aplicaciones para que se recuperen rápidamente de fallos catastróficos.

Para planificar la recuperación tras fallos de forma eficaz, se necesita un enfoque por capas. Empieza por definir objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) claros para tu aplicación y tu sistema, de modo que se puedan volver a implementar rápidamente.

Por último, tus secretos y credenciales también deben poder recuperarse y gestionarse de forma segura. Si tienes en cuenta todos estos factores, podrás conseguir una postura de recuperación tras desastres que te permita crear rápidamente un nuevo clúster de OpenShift en otra región o cambiar a un clúster secundario inactivo. Este clúster secundario permanece sin conexión hasta que se produce un fallo, momento en el que se inicia y se pone online para hacerse cargo de las operaciones con un tiempo de inactividad mínimo.

Arquitecturas para la recuperación ante desastres

Hay diferentes opciones de arquitecturas de implementación que puedes usar para la recuperación ante desastres con OpenShift en Google Cloud. Cada una de estas opciones tiene implicaciones diferentes en cuanto a coste, complejidad y disponibilidad. En la siguiente tabla se ofrece una descripción general de estas arquitecturas:

Arquitectura Descripción Caso práctico Ventajas Desventajas
Activa-pasiva Un clúster está activo y gestiona todo el tráfico, mientras que el otro está en modo pasivo y listo para tomar el control. Los datos se replican en el clúster pasivo. Adecuado para aplicaciones con requisitos de RTO y RPO moderados. Es más fácil de implementar y tiene un coste menor para el clúster de espera. RTO más alto debido al tiempo de conmutación por error y posibles retrasos en la sincronización de datos.
Activo-inactivo Es similar a la configuración activo-pasivo, pero el clúster inactivo no se usa hasta que se produce un evento de recuperación ante desastres. Los datos se copian de forma periódica. Ideal para entornos sensibles a los costes que permiten un RTO y un RPO más altos. Costes operativos más bajos cuando está inactivo, lo que resulta adecuado para la recuperación ante desastres en la que un sistema secundario no está activo (recuperación ante desastres en frío) . El RTO es más alto debido al tiempo de activación y sincronización, aunque existe la posibilidad de que los datos se queden obsoletos.
Activo-activo Ambos clústeres están activos y gestionan el tráfico con el balanceo de carga y la replicación de datos entre regiones. Aplicaciones críticas que requieren un tiempo de inactividad mínimo y una alta disponibilidad. RTO y RPO más bajos, disponibilidad continua. Máxima complejidad y coste, requiere una red y sincronizaciones de datos sólidas.

Siguientes pasos