Alta disponibilidad para tus apps

En esta guía de estrategia, se proporcionan orientación técnica y prácticas recomendadas para diseñar e implementar cargas de trabajo con alta disponibilidad (HA) en un universo aislado de Google Distributed Cloud (GDC) configurado con varias zonas o varias zonas. En la guía, se describen los patrones arquitectónicos clave, las configuraciones de servicios y las consideraciones operativas necesarias para minimizar el tiempo de inactividad y proporcionar continuidad empresarial para las aplicaciones que se ejecutan en GDC.

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

  • Arquitectos de la nube dentro del grupo de administradores de la plataforma: Diseñan arquitecturas de infraestructura y aplicaciones resilientes en GDC.

  • Ingenieros de DevOps y de confiabilidad de sitios (SRE) dentro del grupo de operadores de aplicaciones: Implementan estrategias de implementación, automatización, supervisión y respuesta ante incidentes para cargas de trabajo de alta disponibilidad.

  • Desarrolladores de aplicaciones dentro del grupo de operadores de aplicaciones: Crean aplicaciones tolerantes a errores que se integran sin problemas con los patrones de infraestructura de alta disponibilidad.

Para obtener más información, consulta Audiences for GDC air-gapped documentation.

Importancia de la alta disponibilidad

En los sistemas distribuidos modernos, la planificación para la alta disponibilidad es fundamental. El tiempo de inactividad, ya sea planificado o no, puede provocar interrupciones significativas en el negocio, pérdida de ingresos, daños a la reputación y una experiencia negativa para el 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 correlacionarse directamente con el éxito operativo principal, en especial para las aplicaciones sensibles a la latencia o críticas para la misión. Diseñar para la HA desde el principio es fundamental para crear servicios resilientes y confiables.

Capacidades de hiperescala, disponibles de forma local

GDC extiende la Google Cloud infraestructura y los servicios hasta el perímetro y tus centros de datos. GDC proporciona una solución de hardware y software completamente administrada que te permite ejecutar Google Kubernetes Engine (GKE) en clústeres de GDC y otros servicios deGoogle Cloud más cerca de donde se generan y consumen tus datos.

Esta guía se enfoca específicamente en los universos de GDC configurados en una topología de varias zonas. Con la opción multizona, un solo universo de GDC comprende varias zonas aisladas físicamente dentro de la misma ubicación, como un campus de centro de datos o un área metropolitana. Estas zonas tienen alimentación, enfriamiento y redes independientes, lo que proporciona protección contra fallas localizadas de la infraestructura física. 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 constituye la base para compilar aplicaciones altamente disponibles.

Escalabilidad y balanceo de cargas

Más allá de la redundancia básica de los componentes, la administración eficaz del tráfico y la habilitación de un escalamiento sin problemas son fundamentales para mantener una alta disponibilidad, en especial con condiciones de carga variables. GDC proporciona varios mecanismos para el balanceo de cargas y la administración sofisticada del tráfico.

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

Para exponer tus aplicaciones a usuarios o sistemas fuera de un clúster de GKE en GDC (tráfico norte-sur), usa las capacidades de balanceo de cargas externo administrado de GDC. El servicio de balanceador de cargas externo (ELB) proporciona estas capacidades y se integra sin problemas con Kubernetes.

Las características clave del servicio ELB que proporciona HA y escalabilidad son las siguientes:

  • Servicio administrado: El ELB es administrado por el GDC y está diseñado para ofrecer alta disponibilidad y capacidad de recuperación.

  • Acceso externo: Proporciona direcciones IP externas estables desde grupos administrados por GDC, lo que brinda un punto de entrada coherente para los clientes externos.

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

  • Conocimiento de la zona: Distribuye el tráfico entrante entre los pods de la aplicación en buen estado que se ejecutan en todas las zonas disponibles dentro del universo de GDC. El ELB se basa en sondeos de preparación de pods para determinar el estado del backend.

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

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

Para obtener más información, consulta Configura balanceadores de cargas externos.

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

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

Las características clave del servicio de ILB que proporciona HA y escalabilidad son las siguientes:

  • Acceso interno: Aprovisiona una dirección IP interna estable a la que solo se puede acceder desde la red de GDC, como nodos de clúster o cualquier otro servicio interno.

  • Integración del balanceador de cargas con Kubernetes: Por lo general, 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 en buen estado, que se identifican con sondeos de preparación, ubicados en todas las zonas disponibles. Esta distribución evita fallas internas de comunicación si una zona experimenta problemas.

  • Descubrimiento y desacoplamiento de servicios: Proporciona una dirección IP interna estable y un nombre de DNS 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 ajuste de escala de los servicios de backend internos, ya que distribuye el tráfico entre todas las réplicas disponibles en buen estado.

Usar un ILB para la comunicación interna entre servicios hace que el flujo de tráfico interno sea resistente a las fallas de zona y proporciona un ajuste de escala eficaz, lo que complementa la HA que proporcionan el ELB externo y la distribución de procesamiento subyacente. Esto se suele usar para aplicaciones en niveles en las que los frontends deben comunicarse con las APIs o bases de datos de backend dentro del clúster de Kubernetes.

Para obtener más información, consulta Configura balanceadores de cargas internos.

Implementación de apps con alta disponibilidad en varias zonas con almacenamiento asíncrono

GDC te permite ejecutar infraestructura y aplicaciones más cerca de tus fuentes de datos o usuarios finales. Lograr la HA en tu universo de GDC es fundamental para las cargas de trabajo críticas. Puedes implementar aplicaciones con HA en varias zonas de tu universo de GDC, con replicación de almacenamiento asíncrona para la persistencia de datos y la recuperación ante desastres.

Las zonas representan dominios de fallas distintos dentro de un solo universo. Si distribuyes los componentes de la aplicación y replicas los datos en varias zonas, puedes mejorar significativamente la resiliencia ante fallas de hardware localizadas o eventos de mantenimiento.

¿Qué sigue?