Alta disponibilidad para tus aplicaciones

Esta guía de estrategia proporciona directrices técnicas y prácticas recomendadas para diseñar e implementar cargas de trabajo de alta disponibilidad (HA) en un universo con air gap de Google Distributed Cloud (GDC) configurado con varias zonas o multizona. En la guía se describen los patrones de arquitectura, las configuraciones de servicios y las consideraciones operativas clave necesarios para minimizar el tiempo de inactividad y proporcionar continuidad del negocio a las aplicaciones que se ejecutan en GDC.

Las estrategias de alta disponibilidad están dirigidas a profesionales técnicos que participan en el diseño, la implementación y la gestión de aplicaciones en GDC, como los siguientes:

  • Arquitectos de la nube del grupo de administradores de la plataforma: diseñan infraestructuras y arquitecturas de aplicaciones resilientes en GDC.

  • Ingenieros de DevOps e ingenieros de fiabilidad de sitios web (SREs) del grupo de operadores de aplicaciones: implementar estrategias de implementación, automatización, monitorización y respuesta ante incidentes para cargas de trabajo de alta disponibilidad.

  • Desarrolladores de aplicaciones del grupo de operadores de aplicaciones: crean aplicaciones tolerantes a fallos que se integran a la perfección con patrones de infraestructura de alta disponibilidad.

Para obtener más información, consulta Audiencias de la documentación aislada de GDC.

Importancia de la alta disponibilidad

En los sistemas distribuidos modernos, es fundamental planificar la alta disponibilidad. El tiempo de inactividad, ya sea planificado o no, puede provocar interrupciones significativas en la actividad empresarial, pérdidas de ingresos, daños en la reputación y una mala experiencia de usuario. En el caso de las cargas de trabajo que se ejecutan en el perímetro o en centros de datos privados con GDC, la disponibilidad suele estar directamente relacionada con el éxito operativo principal, sobre todo en el caso de las aplicaciones sensibles a la latencia o críticas. Diseñar para la alta disponibilidad desde el principio es esencial para crear servicios resilientes y fiables.

Funciones de hiperescala, ofrecidas de forma local

GDC amplía la infraestructura y los servicios al perímetro y a tus centros de datos. Google Cloud GDC ofrece una solución de hardware y software totalmente gestionada que te permite ejecutar Google Kubernetes Engine (GKE) en clústeres de GDC y otrosGoogle Cloud servicios más cerca de donde se generan y consumen tus datos.

Esta guía se centra específicamente en los universos de GDC configurados en una topología multizona. Con la opción multizona, un único universo de GDC comprende varias zonas aisladas físicamente en la misma ubicación, como un campus de centros de datos o un área metropolitana. Estas zonas tienen alimentación, refrigeración y redes independientes, lo que proporciona protección frente a fallos de infraestructura física localizados. La conectividad de red de baja latencia y alto ancho de banda entre las zonas de un universo de GDC permite la replicación síncrona y la conmutación por error rápida, lo que sienta las bases para crear aplicaciones de alta disponibilidad.

Escalabilidad y balanceo de carga

Además de la redundancia básica de los componentes, es fundamental gestionar el tráfico de forma eficaz y permitir una escalabilidad fluida para mantener una alta disponibilidad, sobre todo en condiciones de carga variables. GDC proporciona varios mecanismos para el balanceo de carga y la gestión sofisticada del tráfico.

Balanceador de carga externo para el tráfico norte-sur

Para exponer tus aplicaciones a usuarios o sistemas que no estén en un clúster de GKE en GDC (tráfico de norte a sur), debes usar las funciones de balanceo de carga externo gestionadas de GDC. El servicio de balanceador de carga externo (ELB) proporciona estas funciones y se integra perfectamente con Kubernetes.

Estas son las características principales del servicio ELB que proporciona alta disponibilidad y escalabilidad:

  • Servicio gestionado: GDC gestiona ELB, que se ha diseñado para ofrecer alta disponibilidad y resiliencia.

  • Acceso externo: proporciona direcciones IP externas estables de pools gestionados por GDC, lo que ofrece un punto de entrada coherente para los clientes externos.

  • Integración del balanceador de carga con Kubernetes: aprovisiona y configura automáticamente el balanceador de carga cuando creas un Service de type: LoadBalancer de Kubernetes sin anotaciones internas específicas.

  • Conocimiento de la zona: distribuye el tráfico entrante entre los pods de aplicaciones en buen estado que se ejecutan en todas las zonas disponibles del universo de GDC. ELB se basa en las comprobaciones de disponibilidad de los pods para determinar el estado de los backends.

  • Escalabilidad: gestiona la distribución del tráfico externo a medida que tu aplicación se escala horizontalmente en nodos y zonas.

Usar un balanceador de carga externo es la forma estándar y recomendada de conseguir alta disponibilidad para el tráfico entrante externo, de modo que las solicitudes de los clientes se enruten automáticamente lejos de las zonas o instancias que fallen.

Para obtener más información, consulta Configurar balanceadores de carga externos.

Balanceador de carga interno para el tráfico este-oeste

Para la comunicación entre servicios que se ejecutan en el mismo clúster de GKE en GDC (tráfico este-oeste), GDC proporciona un balanceador de carga interno (ILB). Esto es fundamental para desacoplar los servicios internos y proporcionar rutas de comunicación internas que también sean de alta disponibilidad y escalables.

Estas son las características principales del servicio ILB que proporciona alta disponibilidad y escalabilidad:

  • Acceso interno: proporciona una dirección IP interna estable a la que solo se puede acceder desde la red de GDC, como los nodos de clúster u otros servicios internos.

  • Integración del balanceador de carga con Kubernetes: normalmente, se aprovisiona creando un Service de Kubernetes de type: LoadBalancer con una anotación específica para indicar que debe ser interno. Por ejemplo, networking.gke.io/load-balancer-type: "Internal".

  • Conocimiento de la zona: distribuye el tráfico entre los pods de backend correctos, que se identifican con sondeos de disponibilidad y se encuentran en todas las zonas disponibles. Esta distribución evita fallos de comunicación internos si una zona tiene problemas.

  • Descubrimiento de servicios y desacoplamiento: proporciona una dirección IP interna y un nombre de DNS estables con la integración de kube-dns y CoreDNS. Los servicios pueden descubrirse y comunicarse entre sí, lo que elimina la necesidad de que los clientes conozcan las direcciones IP de los pods individuales.

  • Escalabilidad: facilita el escalado de los servicios de backend internos distribuyendo el tráfico entre todas las réplicas disponibles en buen estado.

Si se usa un balanceador de carga interno para la comunicación interna entre servicios, el flujo de tráfico interno será resistente a los fallos de zona y se podrá escalar de forma eficaz, lo que complementa la alta disponibilidad que proporcionan el balanceador de carga externo y la distribución de los recursos de computación subyacentes. Se suele usar en aplicaciones por niveles en las que los frontends deben comunicarse con APIs o bases de datos backend dentro del clúster de Kubernetes.

Para obtener más información, consulta Configurar balanceadores de carga internos.

Despliegue de aplicaciones de alta disponibilidad en varias zonas con almacenamiento asíncrono

GDC te permite ejecutar infraestructuras y aplicaciones más cerca de tus fuentes de datos o usuarios finales. Lograr la alta disponibilidad en tu universo de GDC es fundamental para las cargas de trabajo críticas. Puedes desplegar aplicaciones de alta disponibilidad en varias zonas de tu universo de GDC e implementar la replicación de almacenamiento asíncrona para la persistencia de datos y la recuperación tras fallos.

Las zonas representan dominios de fallo distintos dentro de un mismo universo. Al distribuir los componentes de la aplicación y replicar los datos en distintas zonas, puede mejorar significativamente la resiliencia frente a fallos de hardware localizados o eventos de mantenimiento.

Siguientes pasos