OpenShift en Google Cloud: estrategias de recuperación tras fallos para configuraciones activas-pasivas y activas-inactivas

En este documento se describe cómo planificar e implementar la recuperación tras fallos activo-pasivo y activo-inactivo para las implementaciones de OpenShift en Google Cloud , con el objetivo de minimizar el tiempo de inactividad y acelerar la recuperación en caso de desastre. Ofrece prácticas recomendadas para crear copias de seguridad de datos, gestionar la configuración como código y gestionar secretos para ayudarte a recuperar rápidamente tus aplicaciones 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 una plataforma de contenedores OpenShift desplegada 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. Se presupone que has leído el artículo Prácticas recomendadas para la recuperación ante desastres con OpenShift. Los documentos de esta serie son los siguientes:

Arquitecturas de recuperación tras desastres

En esta sección se describen las arquitecturas de los escenarios de recuperación ante desastres activo-pasivo y activo-inactivo.

Productos usados

Despliegues activo-pasivo

En el siguiente diagrama se muestra un escenario de implementación activo-pasivo para OpenShift en Google Cloud.

Implementación activa-pasiva, explicada en el texto siguiente.

Como se muestra en el diagrama anterior, en un despliegue activo-pasivo para la recuperación ante desastres, un clúster de OpenShift en la región principal gestiona 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 clúster 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 activo, lo que significa que se configura con la infraestructura y los componentes de aplicación necesarios, pero no sirve tráfico de forma activa hasta que sea necesario. Los datos de las aplicaciones se replican en el clúster pasivo para minimizar la pérdida de datos, de acuerdo con el RPO.

Uno de los clústeres regionales actúa como sitio principal (activo) y gestiona todo el tráfico de producción. Un clúster secundario, en otra región, es la reserva para la recuperación tras fallos. El clúster secundario se mantiene en un estado activo y está listo para tomar el control con un retraso mínimo en caso de que falle el clúster principal.

Descripción de los componentes de un escenario de recuperación ante desastres activo-pasivo

La arquitectura tiene la siguiente configuración:

  • Clúster de OpenShift principal (activo): se encuentra en laGoogle Cloud región principal, ejecuta la carga de trabajo de producción y sirve activamente todo el tráfico de usuarios en condiciones de funcionamiento normales.
  • Clúster secundario de OpenShift (pasivo): se encuentra en unaGoogle Cloud región independiente para aislar los fallos y actúa como clúster de reserva activo. Está configurado y en funcionamiento parcialmente, y está listo para hacerse cargo si falla el sistema principal. Tiene la infraestructura necesaria, la configuración de OpenShift y los componentes de la aplicación implementados, pero no sirve tráfico de producción activo hasta que se activa un evento de conmutación por error.
  • Google Cloud Regiones: ubicaciones geográficamente aisladas que proporcionan la base para la recuperación tras desastres. Si usas regiones independientes, te aseguras de que un evento a gran escala que afecte a una región no afecte al clúster de espera.
  • Balanceador de carga HTTPS externo global: actúa como punto de entrada único y global para el tráfico de aplicaciones. En condiciones normales, se configura para enrutar todo el tráfico al clúster principal (activo). Sus comprobaciones de estado monitorizan la disponibilidad del clúster principal.
  • Mecanismo de replicación de datos: proceso o herramientas continuos que se encargan de copiar los datos esenciales de la aplicación del clúster principal al secundario (por ejemplo, bases de datos o estado de volúmenes persistentes). Este enfoque asegura la coherencia de los datos y minimiza la pérdida de datos durante una conmutación por error, lo que te ayuda a cumplir tu objetivo de punto de recuperación.
  • Monitorización y comprobaciones de estado: sistemas que evalúan continuamente el estado y la disponibilidad del clúster principal y sus aplicaciones. Por ejemplo, Cloud Monitoring, las comprobaciones de estado del balanceador de carga y la monitorización interna del clúster. Estos sistemas son importantes para detectar rápidamente cualquier fallo.
  • Mecanismo de conmutación por error: proceso predefinido (manual, semiautomático o totalmente automático) para redirigir el tráfico del clúster principal al secundario cuando se detecta un error irrecuperable en el principal. Este proceso suele implicar la actualización de la configuración de backend del balanceador de carga global para que se dirija al clúster secundario, lo que lo convierte en el nuevo sitio activo.
  • Red de VPC: la infraestructura de red subyacente que crea la conectividad necesaria entre regiones para la replicación y la gestión de datos. Google Cloud

Implementaciones activas e inactivas

La recuperación tras fallos activa-inactiva implica mantener una región secundaria como reserva, que solo se activa durante los desastres. A diferencia de las configuraciones activo-pasivo, en las que los datos se replican continuamente, esta estrategia se basa en copias de seguridad periódicas que se almacenan en Cloud Storage, con la infraestructura aprovisionada y los datos restaurados 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 costes, por lo que es ideal para aplicaciones que pueden tolerar tiempos de recuperación más largos. También puede ayudar a las organizaciones a adaptarse a objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) ampliados.

En un escenario de recuperación tras fallos activo-inactivo, los datos se almacenan periódicamente en la región de 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 restauran a partir de la copia de seguridad más reciente. Puedes usar la API OpenShift para la protección de datos (OADP), que se basa en el proyecto de software libre Velero, para realizar copias de seguridad periódicas. Te recomendamos que almacenes estas copias de seguridad en segmentos de Cloud Storage con la gestión de versiones habilitada. En caso de desastre, puedes usar OADP para restaurar el contenido del clúster. Este enfoque minimiza los costes continuos, pero da lugar a un RTO más largo y a un RPO potencialmente mayor 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 recuperación ante desastres se activa cuando un servicio monitorizado deja de estar disponible.
  2. Una canalización aprovisiona automáticamente la infraestructura en la región de recuperación ante desastres.
  3. Se aprovisiona un nuevo clúster de OpenShift.
  4. Los datos, los secretos y los objetos de las aplicaciones se restauran desde la copia de seguridad más reciente mediante OADP.
  5. El registro de Cloud DNS se actualiza para que apunte a los balanceadores de carga regionales de la región de recuperación ante desastres.

Como se muestra en el diagrama anterior, se implementan dos clústeres regionales de OpenShift independientes, cada uno en una Google Cloud región diferente, como us-central1 y europe-west1. Cada clúster debe tener una alta disponibilidad en su región y usar varias zonas para permitir la redundancia.

Descripción de los componentes en un escenario de recuperación ante desastres activo-inactivo

La arquitectura tiene la siguiente configuración:

  • Región principal (región A): contiene el clúster de OpenShift totalmente operativo que sirve el 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 segmentos de Google Cloud Storage almacenan copias de seguridad periódicas (OADP o Velero para objetos de aplicaciones, así como PVs y copias de seguridad de bases de datos). Te recomendamos que uses el control de versiones y la replicación entre regiones en el segmento.
  • Gestión de la configuración: el repositorio de Git almacena la infraestructura como código (IaC, por ejemplo, Terraform) y los archivos de manifiesto de Kubernetes u OpenShift (para GitOps).
  • Herramientas de copias de seguridad: OADP (Velero) configurado en el clúster principal para realizar copias de seguridad programadas en Cloud Storage.
  • Orquestación: las secuencias de comandos o las herramientas de automatización activan los procesos de aprovisionamiento y restauración de la infraestructura durante la conmutación por error.

Casos prácticos

En esta sección se proporcionan ejemplos de los diferentes casos prácticos de implementaciones activas-pasivas y activas-inactivas.

Casos prácticos de recuperación ante desastres activa-pasiva

Se recomienda la recuperación ante desastres activa-pasiva en los siguientes casos prácticos:

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

Casos prácticos de recuperación ante desastres activa-inactiva

Se recomienda la recuperación ante desastres activa-inactiva en los siguientes casos prácticos:

  • Aplicaciones que pueden tolerar RTOs más largos (por ejemplo, de varios minutos a horas).
  • Entornos en los que la optimización de costes es importante y el gasto de un clúster de espera en funcionamiento continuo es prohibitivo. El coste continuo principal es el del almacenamiento de objetos, no el de la ejecución de instancias de computación.
  • Cargas de trabajo de desarrollo, pruebas o producción menos críticas.
  • Sistemas de archivado o de procesamiento por lotes en los que el tiempo de recuperación es menos importante.

Factores 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 al usar esta arquitectura de referencia para desarrollar una topología que cumpla tus requisitos específicos de seguridad, fiabilidad, coste y rendimiento.

Consideraciones sobre el diseño activo-pasivo

En esta sección se describen las consideraciones de diseño de un escenario de recuperación ante desastres activo-pasivo.

Proteger el estado y la configuración de las aplicaciones

OpenShift Container Platform proporciona OADP y ofrece una protección completa 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, PVCs, ConfigMaps, secretos y CRDs). Sin embargo, OADP no admite la copia de seguridad y la restauración de clústeres completos. Para saber cómo configurar y programar copias de seguridad, así como restaurar operaciones, consulta la documentación de Red Hat.

OADP proporciona procesos de copia de seguridad y restauración para volúmenes persistentes que dependen del almacenamiento de bloques y de los almacenes NFS que utilizan las aplicaciones. Puedes llevar a cabo estos procesos usando las herramientas Restic o Kopia para crear una instantánea o realizar una copia de seguridad a nivel de archivo.

OADP es útil para crear copias de seguridad de las definiciones de objetos, garantizar la coherencia de la configuración y, si es necesario, restaurar aplicaciones o espacios de nombres específicos, 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 réplica de datos entre las regiones principal y secundaria.

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

Almacenamiento en bloques (volúmenes persistentes)

Usa la réplica asíncrona de Persistent Disk de Google para copiar datos de la región primaria a la secundaria. Con este método, se crea un disco principal en la región principal y un disco secundario en la región secundaria, y se configura la replicación entre ellos. El uso de grupos coherentes asegura que ambos discos contengan datos de replicación de un punto en el tiempo común, que se utiliza para la recuperación tras desastres. Para obtener más información, consulta Configurar la replicación asíncrona de discos persistentes.

Objetos PersistentVolumes

En OpenShift, crea objetos PersistentVolume en ambos clústeres que enlacen a estos discos y asegúrate de que las aplicaciones usen las mismas reclamaciones de volumen persistente (PVCs) en ambos clústeres.

Replicación a nivel de aplicación

Algunas aplicaciones (por ejemplo, bases de datos y colas de mensajes) tienen funciones de replicación integradas que puedes configurar en varios clústeres. También puedes usar un servicio gestionado como Pub/Sub para facilitar la replicación de tipos específicos de datos o eventos de aplicaciones. 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 ayudarte a describir las consideraciones de diseño de las copias de seguridad de bases de datos, en este documento se usa PostgreSQL como base de datos de ejemplo.

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

Los operadores de bases de datos, como el operador CloudNative PostgreSQL, pueden facilitar las copias de seguridad programadas y la recuperación tras fallos de los clústeres de PostgreSQL. El operador Cloud Native PostgreSQL se integra de forma nativa con herramientas como pg_basebackup y admite copias de seguridad de replicación de streaming. 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 de streaming entre clústeres regionales primarios y secundarios para asegurarte de que los datos estén disponibles incluso en caso de interrupción en la región principal. Esta replicación de streaming suele ser síncrona en una región y asíncrona entre regiones. Para ver los pasos de configuración detallados, consulta la documentación de CloudNativePG.

En caso de desastre, puedes restaurar las copias de seguridad en un nuevo clúster de PostgreSQL, 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 mediante el operador Cloud Native PostgreSQL:

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

Servicios gestionados

Las bases de datos gestionadas, como Cloud SQL, tienen funciones de copia de seguridad y replicación integradas. 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 Información sobre 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 base de datos correctas de cada clúster.

Como la replicación asíncrona da como resultado 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 Crear y gestionar 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 redirige automáticamente el tráfico al clúster regional secundario en función de las comprobaciones del estado y las políticas de conmutación por error.

Cuando el clúster secundario pasa de ser una réplica de lectura a ser el principal, se convierte en un sitio activo y sirve el tráfico de producción. Esta promoción es necesaria para poder aceptar escrituras en la base de datos.

Para configurar la recuperación tras fallos de Cloud SQL, sigue los pasos que se describen en la documentación sobre recuperación tras fallos de Google Cloud SQL. Si usas la replicación asíncrona de bases de datos o de almacenamiento, el RPO será distinto de cero para asegurarte de 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.

Gestió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 recuperación ante desastres. Debes poder restaurar estos secretos de forma segura y fiable en un nuevo clúster.

Estos son algunos de los métodos habituales para gestionar secretos:

  • Usa secretos externos: usa una herramienta como el operador de secretos externos para extraer secretos de Google Secret Manager.
  • Crear copias de seguridad de secretos con el operador de OADP: si no utilizas un almacén externo, asegúrate de que los secretos estén incluidos en tus copias de seguridad.
  • Rotación periódica: rota los secretos periódicamente y asegúrate de que tu estrategia de gestión de secretos se adapte a los escenarios de recuperación ante desastres.
  • Pruebas: prueba la restauración de secretos en un entorno de staging para confirmar que todos los servicios se pueden iniciar con las credenciales proporcionadas.
  • Validación: valida que tu clúster de recuperación ante desastres tenga los roles de gestión de identidades y accesos o los métodos de autenticación necesarios para recuperar secretos de almacenes externos.

Redes y gestión del tráfico

Usa el balanceador de carga 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 primario y secundario). Este servicio global dirige las solicitudes de los usuarios al clúster de backend adecuado en función de la proximidad, el estado y la disponibilidad.

Para conectar el balanceador de carga global a tus clústeres de OpenShift, puedes usar uno de los siguientes métodos:

  • Usa balanceadores de carga regionales (NEGs de Internet): configuraGoogle Cloud grupos de puntos finales de red (NEGs) de Internet para que apunten a las direcciones IP externas de los balanceadores de carga regionales que exponen cada uno de los servicios de entrada de tus clústeres de OpenShift (routers de OCP). A continuación, el balanceador de carga global dirige el tráfico a estas IPs de balanceadores de carga regionales. Este enfoque proporciona una capa de abstracción, pero implica un salto a una red adicional.
  • Ruta directa de pods (Compute Engine_VM_IP_PORT NEGs): configura la integración de OpenShift Ingress Controller para usar Google Cloud grupos de endpoints de red (NEGs) del tipo Compute Engine_VM_IP_PORT. Este enfoque permite que el balanceador de carga mundial se dirija directamente a los pods del controlador de entrada (router) de OpenShift mediante su PodIP:TargetPort interno. Este método evita el salto adicional y el proxy adicional del nodo. Normalmente, esto conlleva una latencia menor y permite que el balanceador de carga global realice comprobaciones del estado más directas.

Ambas configuraciones permiten que el balanceador de carga global gestione la distribución del tráfico de forma eficaz entre los clústeres de diferentes regiones. Para obtener más información, consulta Configurar un balanceador de carga de aplicación externo global con un backend externo.

VPCs

Te recomendamos que utilices los siguientes métodos para gestionar las VPCs:

  • VPC compartida: usa una VPC compartida para centralizar la gestión de la red de los clústeres primarios y secundarios. Este enfoque simplifica la administración y asegura que las políticas de red sean 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 y garantizar una conectividad fluida entre los clústeres.
  • VPCs en modo personalizado: usa VPCs en modo personalizado y crea subredes específicas en las regiones en las que se ejecutan tus clústeres. Esto suele ser necesario para la red de pods nativa de VPC que requieren métodos como el enrutamiento Compute Engine_VM_IP_PORT.
  • Emparejamiento entre redes de VPC: si necesitas usar redes de VPC independientes para cada región y clúster, usa el emparejamiento 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 intervalos de IP superpuestos entre regiones para evitar problemas de enrutamiento.

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

OpenShift admite la federación de mallas de servicios, lo que permite la comunicación entre servicios desplegados en varios clústeres de OpenShift. Esta función es especialmente útil en situaciones de recuperación ante desastres en las que los servicios pueden necesitar comunicarse entre clústeres durante una conmutación por error o una replicación de datos.

Para saber cómo configurar la federación de mallas de servicios entre clústeres primarios y secundarios, consulta la documentación de Red Hat.

Consideraciones sobre el diseño activo e inactivo

En esta sección se describen las consideraciones de diseño de una solución de recuperación ante desastres activa-inactiva.

Configuración de aplicaciones como código (GitOps)

Te recomendamos que adoptes un enfoque de GitOps para almacenar todas las configuraciones de clústeres y aplicaciones en un repositorio de Git. Este enfoque permite una restauración rápida en un escenario de recuperación ante desastres, ya que habilita la sincronización con un estado que se sabe que se ejecuta de forma fiable en otro clúster. Las copias de seguridad te permiten tener instantáneas del estado de tu tiempo de ejecución, pero también necesitas una forma fiable 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.

Usar el operador GitOps de OpenShift

El operador GitOps de OpenShift, basado en Argo CD, ofrece una forma de implementar patrones de GitOps directamente en un entorno de OpenShift con la asistencia de Red Hat. 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 GitOps de OpenShift se asegura continuamente de 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 escenarios de recuperación ante desastres

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 aplicación que hace referencia a tu repositorio de Git.

El operador sincroniza el estado del clúster para que coincida con el de 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 recuperación ante desastres, te recomendamos que hagas lo siguiente:

  • Mantén estrategias estrictas de ramificación y etiquetado en tu repositorio de Git para poder identificar configuraciones estables adecuadas para la recuperación ante desastres.
  • Comprueba que tu clúster de recuperación ante desastres 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 cortafuegos

Define políticas de cortafuegos unificadas y aplícalas de forma coherente en ambos clústeres para controlar el flujo de tráfico y mejorar la seguridad.

Sigue el principio de mínimos accesos, lo que significa que debes restringir el tráfico entrante y saliente a lo que sea necesario para la funcionalidad de la aplicación.

Implementación

Para saber cómo implementar una topología basada en esta arquitectura de referencia, consulta la documentación de Red Hat.

Siguientes pasos