Recuperación ante desastres para OpenShift en Google Cloud

La recuperación ante desastres (DR) es esencial para mantener la continuidad de las aplicaciones implementadas en OpenShift Container Platform enGoogle Cloud. En este documento, se proporciona una descripción general de las opciones de arquitectura para la DR con OpenShift en Google Cloud, lo que ayuda a tu organización a lograr un tiempo de inactividad mínimo y una recuperación rápida en caso de desastre.

Este documento está dirigido a los administradores de sistemas, los arquitectos de la nube y los desarrolladores de aplicaciones que son responsables de mantener la disponibilidad y la capacidad de recuperación de las aplicaciones en la plataforma de contenedores de OpenShift implementada enGoogle Cloud.

Este documento forma parte de una serie que se enfoca en las estrategias a nivel de la aplicación que garantizan que tus cargas de trabajo sigan estando altamente disponibles y se recuperen rápidamente ante las fallas. Los documentos de esta serie son los siguientes:

Planificación de DR

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

La planificación eficaz de la recuperación ante desastres implica un enfoque por capas. Comienza 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 puedas volver a implementarlos rápidamente.

Por último, tus secretos y credenciales también deben poder recuperarse y administrarse de forma segura. Si tienes en cuenta todos estos factores, puedes lograr una postura de DR que te permita crear rápidamente un nuevo clúster de OpenShift en una región diferente o conmutar por error a un clúster secundario inactivo. Este clúster secundario permanece sin conexión hasta que se produce una falla, momento en el que se inicia y se pone en línea para hacerse cargo de las operaciones con un tiempo de inactividad mínimo.

Arquitecturas para la DR

Existen diferentes opciones para las arquitecturas de implementación que puedes usar para la DR con OpenShift en Google Cloud. Cada una de estas opciones tiene diferentes implicaciones en cuanto a costo, complejidad y disponibilidad. En la siguiente tabla, se proporciona una descripción general de estas arquitecturas:

Arquitectura Descripción Caso práctico Ventajas Desventajas
Activa-pasiva Un clúster está activo y controla todo el tráfico, mientras que el otro está pasivo y listo para tomar el control. Los datos se replican en el clúster pasivo. Adecuado para aplicaciones con requisitos moderados de RTO y RPO. Es más fácil de implementar y tiene un costo más bajo para el clúster en espera. El RTO es más alto debido al tiempo de conmutación por error y a los posibles retrasos en la sincronización de datos.
Activa-inactiva Es similar a la configuración activa-pasiva, pero el clúster inactivo no se usa hasta que se produce un evento de DR. Se crean copias de seguridad de los datos con regularidad. Ideal para entornos sensibles a los costos que permiten un RTO y un RPO más altos. Menor costo operativo cuando está inactivo, adecuado para la DR en la que no se ejecuta un sistema secundario de forma activa (DR 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 queden desactualizados.
Activa-activa Ambos clústeres están activos y controlan el tráfico con balanceo de cargas y replicación de datos entre regiones. Aplicaciones críticas que requieren un tiempo de inactividad mínimo y alta disponibilidad RTO y RPO más bajos, disponibilidad continua Es la opción más compleja y costosa, y requiere una sincronización sólida de la red y los datos.

¿Qué sigue?