Alta disponibilidad para tus apps

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

Las estrategias que se describen en este documento están dirigidas a los siguientes profesionales técnicos:

  • Arquitectos de nube que diseñan infraestructuras y arquitecturas de aplicaciones resilientes

  • Ingenieros de DevOps y de confiabilidad de sitios que implementan estrategias de implementación, automatización, supervisión y respuesta ante incidentes para cargas de trabajo de alta disponibilidad

  • Desarrolladores de aplicaciones que compilan aplicaciones tolerantes a errores que se integran con patrones de alta disponibilidad

Para obtener más información, consulta Públicos de la documentación de Google Distributed Cloud aislado.

Importancia de la alta disponibilidad

En los sistemas distribuidos modernos, la planificación para la alta disponibilidad es fundamental. El tiempo de inactividad puede generar interrupciones significativas en el negocio, pérdida de ingresos y una mala experiencia del usuario.

En el caso de las cargas de trabajo que se ejecutan 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 alta disponibilidad desde el principio es fundamental para crear servicios resilientes y confiables.

GDC proporciona capacidades de hiperescala dentro de tu entorno aislado con varios centros de datos desconectados o zonas. La HA de tus apps multizona depende de los servicios multizona, como el balanceo de cargas y el almacenamiento asíncrono. Para obtener más información sobre los servicios importantes que se deben usar para la HA, consulta las secciones Escalabilidad y balanceo de cargas y Implementación de apps de HA en zonas con almacenamiento asíncrono de este documento.

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.

Este documento se centra en los universos de GDC configurados en una topología de varias zonas. En esta configuración, un solo universo comprende varias zonas aisladas físicamente dentro de la misma ubicación.

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 permite la replicación de datos y la conmutación por error rápida, lo que constituye la base para crear aplicaciones con alta disponibilidad.

Escalabilidad y balanceo de cargas

Más allá de la redundancia básica de los componentes, administrar el tráfico de manera eficaz y permitir el escalamiento sin problemas son aspectos 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: Se ejecuta como un servicio específico de GDC y está diseñado para ofrecer alta disponibilidad y capacidad de recuperación en un entorno aislado.

  • Acceso externo: Proporciona direcciones IP externas estables desde grupos administrados por GDC, lo que proporciona 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.

Para lograr una alta disponibilidad en el tráfico de entrada externo, de modo que las solicitudes de los clientes se enruten automáticamente lejos de las zonas o instancias con errores, te recomendamos que uses un balanceador de cargas externo.

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 servicios que se ejecutan dentro del mismo clúster de GKE on GDC (tráfico este-oeste), GDC proporciona un balanceador de cargas interno (ILB). Un ILB 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: Aprovisiona el balanceo de cargas 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 y se ubican 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 escalamiento de los servicios de backend internos distribuyendo 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. Esta estrategia se suele usar para aplicaciones en niveles en las que las APIs de frontend 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. Para implementar aplicaciones de HA con una fuente de datos resiliente, implementa la replicación de almacenamiento asíncrona para la persistencia de datos y la recuperación ante desastres.

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

Para obtener más información, consulta Protección de datos con almacenamiento multizonal.

¿Qué sigue?