Estrategias de recuperación ante desastres para configuraciones activo-pasivo

En este documento, se describe cómo planificar y, luego, implementar la recuperación ante desastres activa-pasiva para las implementaciones de OpenShift en Google Cloud para ayudarte a lograr un tiempo de inactividad mínimo y una recuperación rápida en caso de desastre. Se proporcionan prácticas recomendadas para crear copias de seguridad de 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 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:

Arquitectura para la recuperación ante desastres

En el siguiente diagrama de arquitectura, 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. Un clúster secundario en una región diferente se mantiene listo 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 activo , 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 el 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 en espera para la recuperación ante desastres. El clúster secundario se mantiene en un estado activo y está listo para tomar el control con una demora mínima en caso de falla del clúster principal.

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

Esta arquitectura tiene la siguiente configuración:

  • Clúster de OpenShift principal (activo): Ubicado en la región principal Google Cloud , 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 de OpenShift secundario (pasivo): Ubicado en una Google Cloud región independiente para el aislamiento de fallas, este clúster actúa como el clúster en espera activo. Está parcialmente configurado y en ejecución, y está listo para tomar 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: Ubicaciones geográficamente aisladas que proporcionan la base para la recuperación ante desastres. El uso de regiones independientes garantiza que un evento a gran escala que afecte a una región no afecte al clúster en espera.
  • Balanceador de cargas de HTTPS externo global: Actúa como el único punto de entrada global para el tráfico de aplicaciones. En condiciones normales, está configurado 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 responsables de copiar datos esenciales de la aplicación del clúster principal al clúster secundario (por ejemplo, bases de datos o estado de 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 continuamente 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 la detección rápida de cualquier falla.
  • Mecanismo de conmutación por error: Un proceso predefinido (manual, semiautomático o completamente automático) para redireccionar el tráfico del clúster principal al secundario cuando se detecta una falla irrecuperable en el principal. Por lo general, este proceso implica actualizar la configuración de backend del balanceador de cargas global para orientar al clúster secundario, lo que lo convierte en el nuevo sitio activo.
  • Red de VPC: La infraestructura de red subyacente que Google Cloud crea la conectividad necesaria entre las regiones para la replicación y la administración de datos.

Productos usados

Casos de uso

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) que el 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 es factible la replicación continua de datos y se debe minimizar el RPO (por ejemplo, de minutos a segundos).
  • Industrias reguladas con límites estrictos de tiempo de inactividad y aplicaciones empresariales fundamentales en las que el costo de mantener un clúster en espera activo se justifica por el impacto empresarial del tiempo de inactividad.

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.

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 usan las aplicaciones alojadas en contenedores y las máquinas virtuales (por ejemplo, implementaciones, servicios, rutas, PVC, ConfigMaps, secretos y CRD). Sin embargo, OADP no admite la copia de seguridad y el restablecimiento completos del clúster. Para obtener información sobre cómo configurar y programar copias de seguridad, y cómo restablecer 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 herramientas como Restic o Kopia para crear instantáneas o realizar copias 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, 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 tomar el control sin problemas. Como se describe en la siguiente sección, la implementación de la replicación de datos del clúster principal al secundario 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 usa 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 las mismas Persistent Volume Claims (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 aplicaciones.

Copias de seguridad de bases de datos

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

Copias de seguridad autoalojadas 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 ante desastres para los clústeres de PostgreSQL. El operador 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 la durabilidad y la recuperación.

Puedes configurar la replicación de transmisión entre los clústeres regionales principal y secundario para garantizar que, incluso en caso de interrupción en la región principal, los datos estén disponibles. Por lo general, esta replicación de transmisión es síncrona dentro de una región y asíncrona en todas las regiones. Para obtener pasos de configuración detallados, 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. El siguiente es un ejemplo de fragmento de configuración para habilitar copias de seguridad programadas con el operador 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 base de datos correctas para cada clúster.

Debido a que 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 considerar 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 falla del clúster principal, Cloud DNS redirecciona automáticamente el tráfico al clúster regional secundario en función de las verificaciones de estado y las políticas de conmutación por error.

Cuando el clúster secundario se promueve de una réplica de lectura a un clúster principal, toma el control como un sitio activo y entrega tráfico de producción. Esta promoción es necesaria para poder aceptar escrituras de bases de datos.

Para configurar la DR para Cloud SQL, sigue los pasos que se describen en la documentación de 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 considerar 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.

Entre los enfoques comunes para la administración de secretos, se incluyen los siguientes:

  • Usa secretos externos: Usa una herramienta como el operador de secretos externos para extraer secretos de Google Secret Manager.
  • Crea copias de seguridad de secretos con el operador OADP: Si no usas un almacén externo, asegúrate de que los secretos estén incluidos en tus copias de seguridad.
  • Rotación regular: 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 el restablecimiento de secretos en un entorno de etapas 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 de HTTPS externo global de Google Cloudcomo el 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): Configura Google Cloud grupos de extremos de red de Internet (NEG) para que apunten a las direcciones IP externas de los balanceadores de cargas regionales que exponen cada uno de los servicios de entrada de tus clústeres de OpenShift (routers OCP). Luego, el balanceador de cargas global enruta el tráfico a estas IPs del balanceador de cargas regional. 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 Google Cloud grupos de extremos de red (NEG) de tipo Compute Engine_VM_IP_PORT. Este enfoque permite que el balanceador de cargas global se oriente directamente a los Pods del controlador de entrada de OpenShift (router) con su PodIP:TargetPort interno. Este método omite el salto adicional y el proxy adicional del nodo. Por lo general, da como resultado 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 todos 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 para los clústeres principal y secundario. 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 dentro de tus VPC para propagar automáticamente las rutas entre las regiones, lo que garantiza una conectividad fluida entre los clústeres.
  • VPC de modo personalizado: Usa VPC de modo personalizado y crea subredes específicas en las regiones en las que se ejecutan tus clústeres. A menudo, esto es 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 es necesario que uses 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, 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 es posible que los servicios necesiten 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 los clústeres principal y secundario, consulta la documentación de Red Hat.

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?