Este documento está dirigido a administradores de sistemas, arquitectos de la nube y desarrolladores de aplicaciones responsables de mantener la disponibilidad y la resiliencia de las aplicaciones en OpenShift Container Platform implementado en Google 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 permanezcan altamente disponibles y se puedan recuperar rápidamente en caso de fallas. Los documentos de esta serie son los siguientes:
- Prácticas recomendadas para la recuperación ante desastres (esta página)
- Prácticas recomendadas para la alta disponibilidad
- Estrategias de recuperación ante desastres para configuraciones activa-pasiva
- Estrategias de recuperación ante desastres para configuraciones activa-inactiva
Planificación de DR
La planificación para la DR 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 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 DR implica un enfoque por capas. Para comenzar, define objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) claros para tu aplicación y sistema para una reimplementación rápida.
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 realizar una conmutación 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 para el costo, la complejidad y la 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 es pasivo y está listo para hacerse cargo. Los datos se replican en el clúster pasivo. | Adecuado para aplicaciones con requisitos moderados de RTO y RPO. | Más fácil de implementar, menor costo para el clúster de espera. | RTO más alto debido al tiempo de conmutación por error, posibles retrasos en la sincronización de datos. |
| Activa-inactiva | Similar a la activa-pasiva, pero el clúster inactivo no se usa hasta que se produce un evento de DR. Se realiza una copia 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 un sistema secundario no se ejecuta de forma activa (DR en frío). | RTO 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. | Mayor complejidad y costo, requiere una red sólida y sincronizaciones de datos. |
¿Qué sigue?
- Obtén información para implementar la supervisión y las alertas para el estado del clúster, el estado de la replicación, el éxito de la copia de seguridad y el rendimiento de la aplicación en entornos primarios y secundarios.
- Obtén información para instalar OpenShift en Google Cloud.
- Obtén más información sobre las soluciones de Red Hat en Google Cloud.