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 Red Hat 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 ante fallas. Se supone que leíste Prácticas recomendadas para la recuperación ante desastres. Los documentos de esta serie son los siguientes:
- Prácticas recomendadas para la recuperación ante desastres
- Prácticas recomendadas para la alta disponibilidad
- Estrategias de recuperación ante desastres para configuraciones activo-pasivo
- Estrategias de recuperación ante desastres para configuraciones activo-inactivo (esta página)
Arquitectura para la recuperación ante desastres
La DR activo-inactivo implica mantener una región secundaria como en espera, que se activa solo durante los desastres. A diferencia de las configuraciones activo-pasivo, en las que los datos se replican de forma continua, esta estrategia se basa en copias de seguridad periódicas que se almacenan en Cloud Storage, con la infraestructura aprovisionada y los datos restablecidos durante la conmutación por error. Puedes usar herramientas como Velero, integrada con la API de OpenShift para la protección de datos (OADP), para realizar copias de seguridad periódicas. Este enfoque minimiza los costos, lo que lo hace ideal para las aplicaciones que pueden tolerar tiempos de recuperación más largos. También puede ayudar a las organizaciones a alinearse con los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) extendidos.
En una situación de DR activo-inactivo, se realiza una copia de seguridad de los datos con regularidad en la región en espera, pero no se replican de forma activa. La infraestructura se aprovisiona como parte del proceso de conmutación por error y los datos se restablecen desde la copia de seguridad más reciente. Puedes usar la API de OpenShift para la protección de datos (OADP), que se basa en el proyecto de código abierto de Velero, para realizar copias de seguridad periódicas. Te recomendamos que almacenes estas copias de seguridad en buckets de Cloud Storage con el control de versiones habilitado. En caso de desastre, puedes usar OADP para restablecer el contenido del clúster. Este enfoque minimiza los costos continuos, pero genera un RTO más largo y un RPO potencialmente más alto en comparación con el activo-pasivo. Esta configuración es adecuada para aplicaciones con objetivos de tiempo de recuperación más largos.
En el siguiente diagrama, se muestra una implementación activo-inactivo y el proceso de conmutación por error:
El proceso de conmutación por error es el siguiente:
- Se activa un evento de DR cuando un servicio supervisado deja de estar disponible.
- Una canalización aprovisiona automáticamente la infraestructura en la región de DR.
- Se aprovisiona un nuevo clúster de OpenShift.
- Los datos, los secretos y los objetos de la aplicación se restablecen desde la copia de seguridad más reciente a través de OADP.
- El registro de Cloud DNS se actualiza para que apunte a los balanceadores de cargas regionales en la región de DR.
Como se muestra en el diagrama anterior, se implementan dos clústeres
regionales de OpenShift separados, cada uno en una región Google Cloud diferente, como
us-central1 y europe-west1. Cada clúster debe tener alta disponibilidad dentro de su región y usar varias zonas para permitir la redundancia.
Descripción de los componentes en una situación de DR activo-inactivo
La arquitectura tiene la siguiente configuración:
- Región principal (región A): Contiene el clúster de OpenShift completamente operativo que entrega tráfico de producción.
- Región secundaria (región B): Inicialmente, contiene recursos mínimos (VPC y subredes). La infraestructura (instancias de Compute Engine y OCP) se aprovisiona durante la conmutación por error.
- Almacenamiento de copia de seguridad: Los buckets de Google Cloud Storage almacenan copias de seguridad periódicas (OADP o Velero para objetos de aplicación, así como PV y copias de seguridad de bases de datos). Te recomendamos que uses el control de versiones y la replicación entre regiones para el bucket.
- Administración de la configuración: El repositorio de Git almacena la infraestructura como código (IaC, por ejemplo, Terraform) y los manifiestos de Kubernetes o OpenShift (para GitOps).
- Herramientas de copia de seguridad: OADP (Velero) configurado en el clúster principal para realizar copias de seguridad programadas en Cloud Storage.
- Organización: Las secuencias de comandos o las herramientas de automatización activan el aprovisionamiento de la infraestructura y restablecen los procesos durante la conmutación por error.
Productos usados
- Google Compute Engine
- Google Cloud Balanceador de cargas HTTPS externo global
- Google Cloud Balanceadores de cargas de red de transferencia
- Cloud DNS
- Grupos de extremos de red
- Cloud Storage
- Cloud SQL
- Persistent Disk
- Secret Manager
- Cloud Monitoring
- Red de VPC
Casos de uso
Se recomienda la DR activo-inactivo para los siguientes casos de uso:
- Aplicaciones que pueden tolerar RTO más largos (por ejemplo, de varios minutos a horas)
- Entornos en los que la optimización de costos es importante y el costo de un clúster en espera en ejecución continua es prohibitivo. El costo continuo principal es para el almacenamiento de objetos en lugar de para ejecutar instancias de procesamiento.
- Cargas de trabajo de desarrollo, pruebas o producción menos esenciales
- Sistemas de procesamiento por lotes o de archivo en los que el tiempo de recuperación es menos esencial
Consideraciones del diseño
En esta sección, se describen los factores de diseño, las prácticas recomendadas y las recomendaciones de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para desarrollar una topología que cumpla con tus requisitos específicos de seguridad, confiabilidad, costo y rendimiento.
Configuración de la aplicación como código (GitOps)
Te recomendamos que adoptes un enfoque de GitOps para almacenar todas las configuraciones de clúster y aplicaciones en un repositorio de Git. Este enfoque permite un restablecimiento rápido en una situación de DR, ya que permite la sincronización con un estado que se sabe que se ejecuta de manera confiable en otro clúster. Las copias de seguridad garantizan que tengas instantáneas de tu estado de ejecución. Sin embargo, también necesitas una forma confiable de volver a implementar la lógica de la aplicación, los manifiestos y las definiciones de infraestructura rápidamente después de un desastre.
Usa el operador de GitOps de OpenShift
El operador de GitOps de OpenShift, basado en Argo CD, proporciona una forma compatible con Red Hat para implementar patrones de GitOps directamente en un entorno de OpenShift. Automatiza el proceso de conciliación continua del estado del clúster con la configuración elegida y lo almacena en un repositorio de Git.
El controlador del operador de GitOps de OpenShift garantiza continuamente que el estado del clúster coincida con la configuración definida en este repositorio. Si los recursos se desvían o faltan, los concilia automáticamente. Para obtener más información, consulta Acerca de Red Hat OpenShift GitOps.
Ejecución de situaciones de DR
En caso de desastre, haz lo siguiente:
- Configura un nuevo clúster de OpenShift en otra región.
- Instala el operador de GitOps de OpenShift.
- Aplica el mismo manifiesto de la aplicación que hace referencia a tu repositorio de Git.
El operador sincroniza el estado del clúster para que coincida con tu repositorio, y vuelve a implementar rápidamente las implementaciones, los servicios, las rutas, los operadores y cualquier otro recurso que se defina en tu código.
Para evitar problemas durante la DR, te recomendamos que hagas lo siguiente:
- Mantén estrategias estrictas de ramificación y etiquetado en tu repositorio de Git para que puedas identificar configuraciones estables adecuadas para la DR.
- Verifica que tu clúster de DR tenga conectividad de red y los permisos adecuados para acceder al repositorio de Git.
- Incluye todos los tipos de recursos como código para evitar la intervención manual durante la conmutación por error (por ejemplo, componentes de infraestructura, cargas de trabajo de aplicaciones y configuraciones).
Reglas de firewall
Define políticas de firewall unificadas y aplícalas de manera coherente en ambos clústeres para controlar el flujo de tráfico y mejorar la seguridad.
Sigue el principio de privilegio mínimo, lo que significa que debes restringir el tráfico entrante y saliente solo a lo que sea necesario para la funcionalidad de la aplicación.
Deployment
Para obtener información sobre cómo implementar una topología basada en esta arquitectura de referencia, consulta la documentación de Red Hat.
¿Qué sigue?
- Obtén información para implementar la supervisión y las alertas para el estado del clúster, el estado de replicación, el éxito de la copia de seguridad y el rendimiento de la aplicación en entornos principales 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.