OpenShift en Google Cloud: Estrategias de recuperación ante desastres para configuraciones activo-pasivo y activo-inactivo

En este documento, se describe cómo planificar e implementar la recuperación ante desastres activa-pasiva y activa-inactiva para las implementaciones de OpenShift en Google Cloud , de modo que puedas lograr un tiempo de inactividad mínimo y una recuperación rápida en caso de desastre. Proporciona prácticas recomendadas para hacer copias de seguridad de los datos, administrar la configuración como código y controlar los secretos para garantizar que puedas recuperar rápidamente tus aplicaciones 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 una 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. Se supone que leíste Prácticas recomendadas para la recuperación ante desastres con OpenShift. Los documentos de esta serie son los siguientes:

Arquitecturas para la recuperación ante desastres

En esta sección, se describen las arquitecturas para situaciones de recuperación ante desastres activas/pasivas y activas/inactivas.

Productos usados

Implementaciones activas-pasivas

En el siguiente diagrama, se muestra una situación de implementación activa-pasiva para OpenShift en Google Cloud.

Implementación activa-pasiva, que se explica en el siguiente texto.

Como se muestra en el diagrama anterior, en una implementación activa-pasiva para la recuperación ante desastres, un clúster de OpenShift en la región principal controla todo el tráfico de producción. Se mantiene listo un clúster secundario en otra región para tomar el control si falla el principal. Esta configuración garantiza un tiempo de inactividad mínimo, ya que el clúster secundario se aprovisiona previamente y se encuentra en un estado cálido, lo que significa que está configurado con la infraestructura y los componentes de la aplicación necesarios, pero no entrega tráfico de forma activa hasta que sea necesario. Los datos de la aplicación se replican en el clúster pasivo para minimizar la pérdida de datos, lo que se alinea con el RPO.

Uno de los clústeres regionales actúa como sitio principal (activo) y controla todo el tráfico de producción. Un clúster secundario, en una región diferente, es el clúster de reserva para la recuperación ante desastres. El clúster secundario se mantiene en un estado activo y está listo para asumir el control con una demora mínima en caso de que falle el clúster principal.

Descripción de los componentes en una situación de DR activa-pasiva

La arquitectura tiene la siguiente configuración:

  • Clúster principal de OpenShift (activo): Ubicado en la regiónGoogle Cloud principal, este clúster ejecuta la carga de trabajo de producción y entrega de forma activa todo el tráfico de usuarios en condiciones operativas normales.
  • Clúster secundario de OpenShift (pasivo): Ubicado en unaGoogle Cloud región separada para el aislamiento de fallas, este clúster actúa como clúster de reserva en espera. Está parcialmente configurado y en funcionamiento, y está listo para asumir el control si falla el sistema principal. Tiene la infraestructura, la configuración de OpenShift y los componentes de la aplicación necesarios implementados, pero no entrega tráfico de producción en vivo hasta que se activa un evento de conmutación por error.
  • Google Cloud Regiones: Son ubicaciones geográficamente aisladas que proporcionan la base para la recuperación ante desastres. El uso de regiones separadas garantiza que un evento a gran escala que afecte a una región no afecte al clúster en espera.
  • Balanceador de cargas HTTPS externo global: Actúa como el único punto de entrada global para el tráfico de aplicaciones. En condiciones normales, se configura para enrutar todo el tráfico al clúster principal (activo). Sus verificaciones de estado supervisan la disponibilidad del clúster principal.
  • Mecanismo de replicación de datos: Proceso o herramientas continuos que son responsables de copiar los datos esenciales de la aplicación del clúster principal al clúster secundario (por ejemplo, el estado de las bases de datos o los volúmenes persistentes). Este enfoque garantiza la coherencia de los datos y minimiza la pérdida de datos durante una conmutación por error, lo que te ayuda a cumplir con tu RPO.
  • Supervisión y verificaciones de estado: Sistemas que evalúan de forma continua el estado y la disponibilidad del clúster principal y sus aplicaciones, por ejemplo, Cloud Monitoring, verificaciones de estado del balanceador de cargas y supervisión interna del clúster. Estos sistemas son importantes para detectar rápidamente cualquier falla.
  • Mecanismo de conmutación por error: Proceso predefinido (manual, semiautomático o completamente automático) para redireccionar el tráfico del clúster principal al secundario tras la detección de una falla irrecuperable en el principal. Por lo general, este proceso implica actualizar la configuración del backend del balanceador de cargas global para que apunte al clúster secundario, lo que lo convierte en el nuevo sitio activo.
  • Red de VPC: Es la infraestructura de red subyacente que crea la conectividad necesaria entre las regiones para la replicación y la administración de datos. Google Cloud

Implementaciones activas e inactivas

La DR activa-inactiva implica mantener una región secundaria como reserva, 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 infraestructura aprovisionada y datos restablecidos durante la conmutación por error. Puedes usar herramientas como Velero, integrada en la API de OpenShift for Data Protection (OADP), para realizar copias de seguridad periódicas. Este enfoque minimiza los costos, por lo que es 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 activa-inactiva, se crean copias 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 a partir de 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 enfoque 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 activa-inactiva y el proceso de conmutación por error.

Proceso de conmutación por error.

El proceso de conmutación por error es el siguiente:

  1. Un evento de DR se activa cuando un servicio supervisado deja de estar disponible.
  2. Una canalización aprovisiona automáticamente la infraestructura en la región de DR.
  3. Se aprovisiona un clúster de OpenShift nuevo.
  4. 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.
  5. 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 activa-inactiva

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 copias de seguridad: Los buckets de Google Cloud Storage almacenan copias de seguridad periódicas (OADP o Velero para objetos de aplicaciones, así como copias de seguridad de PV y 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 los procesos de aprovisionamiento y restablecimiento de la infraestructura durante la conmutación por error.

Casos de uso

En esta sección, se proporcionan ejemplos de los diferentes casos de uso para las implementaciones activas-pasivas y activas-inactivas.

Casos de uso de DR activo-pasivo

Se recomienda la DR activa-pasiva para los siguientes casos de uso:

  • Aplicaciones que requieren un RTO más bajo (por ejemplo, de minutos a horas) del que se podría lograr con restablecimientos en frío, en los que los datos se restablecen a partir de una copia de seguridad a la que no se puede acceder de inmediato.
  • Sistemas en los que la replicación continua de datos es factible y el RPO debe minimizarse (por ejemplo, de minutos a segundos).
  • Sectores regulados con límites estrictos de tiempo de inactividad y aplicaciones empresariales críticas en los que el costo de mantener un clúster en espera activa se justifica por el impacto empresarial del tiempo de inactividad.

Casos de uso de DR activo-inactivo

Se recomienda la DR activa-inactiva 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 gasto de un clúster en espera en ejecución continua es prohibitivo. El principal costo continuo es el del almacenamiento de objetos, no el de la ejecución de instancias de procesamiento.
  • Cargas de trabajo de desarrollo, pruebas o producción menos críticas
  • Sistemas de procesamiento por lotes o de archivo en los que el tiempo de recuperación es menos crítico.

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.

Consideraciones de diseño activo-pasivo

En esta sección, se describen las consideraciones de diseño para una situación de DR activa-pasiva.

Protección del estado y la configuración de la aplicación

OpenShift Container Platform proporciona OADP y ofrece protección integral de recuperación ante desastres para las aplicaciones que se ejecutan en clústeres. Puedes usarlo para crear copias de seguridad de los objetos de Kubernetes y OpenShift que utilizan tanto las aplicaciones en contenedores como las máquinas virtuales (por ejemplo, implementaciones, servicios, rutas, PVC, ConfigMaps, secretos y CRD). Sin embargo, OADP no admite la copia de seguridad y la restauración completas del clúster. Para obtener información sobre cómo configurar y programar copias de seguridad, y cómo restaurar operaciones, consulta la documentación de Red Hat.

OADP proporciona procesos de copia de seguridad y restablecimiento para volúmenes persistentes que dependen del almacenamiento en bloque y los almacenes NFS que usan las aplicaciones. Puedes realizar estas acciones con las herramientas Restic o Kopia para crear instantáneas o realizar copias de seguridad a nivel de archivos.

OADP es útil para crear copias de seguridad de las definiciones de objetos, garantizar la coherencia de la configuración y, potencialmente, restablecer aplicaciones o espacios de nombres específicos si es necesario, lo que complementa la replicación de datos.

Para reducir aún más el RPO y el RTO en una configuración activa-pasiva, te recomendamos que configures la replicación de datos entre las regiones principal y secundaria.

La replicación de datos es importante para garantizar que el clúster secundario pueda hacerse cargo sin problemas. Como se describe en la siguiente sección, la implementación de la replicación de datos de los clústeres principales a los secundarios depende del tipo de almacenamiento que usa la aplicación.

Almacenamiento en bloque (volúmenes persistentes)

Usa la replicación asíncrona de Persistent Disk de Google para copiar datos de la región principal a la secundaria. Con este enfoque, creas un disco principal en la región principal, un disco secundario en la región secundaria y configuras la replicación entre ellos. El uso de grupos coherentes garantiza que ambos discos contengan datos de replicación de un momento común, que luego se usan para la DR. Para obtener más información, consulta Configura la replicación asíncrona de Persistent Disk.

Objetos PersistentVolumes

En OpenShift, crea objetos PersistentVolumes en ambos clústeres que se vinculen a estos discos y asegúrate de que las aplicaciones usen los mismos PersistentVolumeClaims (PVC) en ambos clústeres.

Replicación a nivel de la aplicación

Algunas aplicaciones (por ejemplo, bases de datos y colas de mensajes) tienen funciones de replicación integradas que puedes configurar en todos los clústeres. También puedes usar un servicio administrado, como Pub/Sub, para facilitar la replicación de tipos específicos de datos o eventos de la aplicación. (por ejemplo, bases de datos y colas de mensajes).

Copias de seguridad de bases de datos

Las aplicaciones pueden depender de diferentes tipos de productos de bases de datos. Para ayudar a delinear las consideraciones de diseño para las copias de seguridad de bases de datos, este documento usa PostgreSQL como ejemplo de base de datos.

Copias de seguridad autoalojadas con un operador de base de datos en el clúster

Los operadores de bases de datos, como el operador de CloudNative PostgreSQL, pueden facilitar las copias de seguridad programadas y la recuperación ante desastres para los clústeres de PostgreSQL. El operador de CloudNative PostgreSQL se integra de forma nativa con herramientas como pg_basebackup y admite copias de seguridad de replicación de transmisión. Puedes almacenar copias de seguridad en servicios de almacenamiento en la nube, como Google Cloud Storage (Cloud Storage), para garantizar la durabilidad y la recuperación.

Puedes configurar la replicación continua entre los clústeres regionales principales y secundarios para garantizar que los datos estén disponibles, incluso en caso de interrupción en la región principal. Por lo general, esta replicación de transmisión es síncrona dentro de una región y asíncrona entre regiones. Para obtener información detallada sobre los pasos de configuración, consulta la documentación de CloudNativePG.

En caso de desastre, puedes restablecer las copias de seguridad en un clúster de PostgreSQL nuevo, lo que garantiza un tiempo de inactividad y una pérdida de datos mínimos. A continuación, se muestra un ejemplo de fragmento de configuración para habilitar las copias de seguridad programadas con el operador de CloudNative PostgreSQL:

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

Servicios administrados

Las bases de datos administradas, como Cloud SQL, tienen funciones integradas de copia de seguridad y replicación. Te recomendamos que configures la replicación asíncrona desde la instancia de base de datos principal a una réplica en la región secundaria. Para obtener más información, consulta Acerca de la replicación en Cloud SQL. En OpenShift, configura secretos o mapas de configuración para que apunten a las cadenas de conexión de la base de datos correctas para cada clúster.

Debido a que la replicación asíncrona genera un RPO distinto de cero, existe la posibilidad de que se pierdan las escrituras de datos más recientes. Debes diseñar tu aplicación para mitigar la pérdida de datos. También puedes usar otro método de replicación.

También te recomendamos que habilites las copias de seguridad automáticas de Cloud SQL. Para obtener más información, consulta Crea y administra copias de seguridad automáticas y bajo demanda.

Proceso de conmutación por error

En caso de que falle el clúster principal, Cloud DNS redirecciona automáticamente el tráfico al clúster regional secundario según las verificaciones de estado y las políticas de conmutación por error.

Cuando el clúster secundario asciende de réplica de lectura a principal, se hace cargo como sitio activo y entrega tráfico de producción. Esta promoción es necesaria para poder aceptar escrituras en la base de datos.

Para configurar la DR para Cloud SQL, sigue los pasos que se describen en la documentación sobre recuperación ante desastres de Google Cloud SQL. El uso de la replicación asíncrona de bases de datos o almacenamiento provoca un RPO distinto de cero para garantizar que tu aplicación pueda tolerar la pérdida de las escrituras más recientes. También puedes usar otro método de replicación.

Administración segura de secretos

Los secretos, como las contraseñas de bases de datos, las claves de API y los certificados TLS, son aspectos importantes de la DR. Debes poder restablecer estos secretos de forma segura y confiable en un clúster nuevo.

Estos son algunos enfoques comunes para la administración de secretos:

  • Usa secretos externos: Usa una herramienta como el operador de secretos externos para extraer secretos de Google Secret Manager.
  • Copia de seguridad de secretos con el operador de OADP: Si no usas un almacén externo, asegúrate de que los secretos se incluyan en tus copias de seguridad.
  • Rotación periódica: Rota los secretos con regularidad y asegúrate de que tu estrategia de administración de secretos se adapte a las situaciones de DR.
  • Pruebas: Prueba la restauración de secretos en un entorno de etapa para confirmar que todos los servicios puedan iniciarse con las credenciales proporcionadas.
  • Validación: Valida que tu clúster de DR tenga los roles de IAM o los métodos de autenticación necesarios para recuperar secretos de almacenes externos.

Administración de redes y tráfico

Usa el balanceador de cargas HTTPS externo global de Google Cloudcomo punto de entrada principal para distribuir el tráfico entre varios clústeres de OpenShift (por ejemplo, clústeres principal y secundario). Este servicio global dirige las solicitudes de los usuarios al clúster de backend adecuado según la proximidad, el estado y la disponibilidad.

Para conectar el balanceador de cargas global a tus clústeres de OpenShift, puedes usar cualquiera de los siguientes enfoques:

  • Usa balanceadores de cargas regionales (NEG de Internet): ConfiguraGoogle Cloud grupos de extremos de red (NEG) de Internet para que apunten a las direcciones IP externas de los balanceadores de cargas regionales que exponen cada uno de los servicios de entrada (enrutadores de OCP) de tus clústeres de OpenShift. Luego, el balanceador de cargas global enruta el tráfico a las IPs de estos balanceadores de cargas regionales. Este enfoque proporciona una capa de abstracción, pero implica un salto a una red adicional.
  • Enrutamiento directo de Pods (Compute Engine_VM_IP_PORT NEGs): Configura la integración del controlador de entrada de OpenShift para usar grupos de extremos de red (NEG) de Google Clouddel tipo Compute Engine_VM_IP_PORT. Este enfoque permite que el balanceador de cargas global se dirija directamente a los Pods del controlador de entrada (router) de OpenShift con su PodIP:TargetPort interno. Este método omite el salto adicional y el proxy adicional del nodo. Por lo general, genera una latencia más baja y permite una verificación de estado más directa desde el balanceador de cargas global.

Ambas configuraciones permiten que el balanceador de cargas global administre la distribución del tráfico de manera eficaz en los clústeres de diferentes regiones. Para obtener más información, consulta Configura un balanceador de cargas de aplicaciones externo global con un backend externo.

VPC

Recomendamos los siguientes enfoques para la administración de VPC:

  • VPC compartida: Usa una VPC compartida para centralizar la administración de redes de los clústeres principales y secundarios. Este enfoque simplifica la administración y garantiza políticas de red coherentes en todas las regiones.
  • Enrutamiento dinámico global: Habilita el enrutamiento dinámico global en tus VPCs para propagar automáticamente las rutas entre regiones, lo que garantiza una conectividad perfecta entre los clústeres.
  • VPC en modo personalizado: Usa VPC en modo personalizado y crea subredes específicas en las regiones en las que se ejecutan tus clústeres. Esto suele ser necesario para las redes de pods nativas de VPC que requieren métodos como el enrutamiento Compute Engine_VM_IP_PORT.
  • Intercambio de tráfico entre redes de VPC: Si necesitas usar redes de VPC independientes para cada región y clúster, usa el intercambio de tráfico entre redes de VPC para conectar las regiones y los clústeres.

Subredes y direcciones IP

Crea subredes regionales en cada región para mantener la segmentación de la red y evitar conflictos de direcciones IP.

Asegúrate de que no haya rangos de IP superpuestos entre las regiones para evitar problemas de enrutamiento.

Tráfico entre clústeres con Red Hat Service Mesh

OpenShift admite la federación de Service Mesh, lo que permite la comunicación entre los servicios implementados en varios clústeres de OpenShift. Esta función es especialmente útil para situaciones de DR en las que los servicios pueden necesitar comunicarse entre clústeres durante la conmutación por error o la replicación de datos.

Para obtener información sobre cómo configurar la federación de Service Mesh entre clústeres principales y secundarios, consulta la documentación de Red Hat.

Consideraciones de diseño de referencias activas e inactivas

En esta sección, se describen las consideraciones de diseño para una solución de DR activa-inactiva.

Configuración de la aplicación como código (GitOps)

Te recomendamos que adoptes un enfoque de GitOps para almacenar todos los parámetros de configuración del clúster y la aplicación en un repositorio de Git. Este enfoque permite una restauración rápida en una situación de DR, ya que habilita 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 tiempo 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 de implementar patrones de GitOps directamente en un entorno de OpenShift. Automatiza el proceso de conciliación continua del estado de tu clúster con la configuración que elijas y la almacena en un repositorio de Git.

El controlador del operador de GitOps de OpenShift garantiza de forma continua que el estado del clúster coincida con la configuración definida en este repositorio. Si los recursos se desvían o faltan, se reconcilian automáticamente. Para obtener más información, consulta Acerca de Red Hat OpenShift GitOps.

Ejecución de la situación de DR

En caso de desastre, haz lo siguiente:

  • Configura un nuevo clúster de OpenShift en otra región.
  • Instala el operador de OpenShift GitOps.
  • Aplica el mismo manifiesto de Application 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.

Implementación

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?