En este documento, se describe cómo puedes combinar varios balanceadores de cargas regionales con las políticas de enrutamiento de DNS de Google para crear arquitecturas de balanceo de cargas globales. El documento está dirigido a ingenieros de redes, arquitectos de soluciones y profesionales de operaciones. Suponemos que tienes conocimientos básicos de Google Compute Engine y que estás familiarizado con conceptos de herramientas de redes, como los balanceadores de cargas y las búsquedas de DNS.
Introducción
Cuando compilas un servicio global que se implementa como una aplicación que se ejecuta en varias regiones, puedes usar políticas de enrutamiento de DNS de ubicación geográfica a fin de tener un extremo de DNS global para tus balanceadores de cargas regionales. En este enfoque, creas un extremo global que enruta el tráfico al servicio local más cercano.
Según el tipo de balanceador de cargas que uses, es posible que puedas lograr esta situación con opciones de balanceo de cargas basado en proxy global. Sin embargo, para algunos casos de uso, debes usar productos de balanceo de cargas regional, por ejemplo, si tu servicio entrega tráfico UDP. Las políticas de enrutamiento de DNS de ubicación geográfica también pueden ayudar a proporcionar un solo extremo de DNS para aplicaciones híbridas que usan Google Cloud junto con otros proveedores de servicios en la nube o una implementación local.
Arquitectura
En el siguiente diagrama, se muestra una arquitectura de muestra que usa tres balanceadores de cargas regionales en tres regiones diferentes. Las regiones se combinan con las políticas de enrutamiento de DNS.
En el diagrama anterior, se muestra cómo los clientes en Oregón, Alemania y Singapur realizan búsquedas de DNS en Cloud DNS para www.example.com. Las solicitudes se enrutan a balanceadores de cargas regionales que están cerca de cada cliente para alcanzar una aplicación alojada en tres regiones diferentes.
Casos de uso para las políticas de enrutamiento de DNS de ubicación geográfica
En esta sección, se analizan los siguientes casos de uso para usar políticas de enrutamiento de DNS de ubicación geográfica a fin de crear un servicio global a partir de varios balanceadores de cargas regionales:
- Un servicio interno accesible y distribuido a nivel global
- Un extremo de DNS global para un servicio externo que admite TCP y UDP
- Un extremo de DNS global para un servicio híbrido
Un servicio interno accesible y distribuido a nivel global
Puedes crear un servicio interno accesible y distribuido a nivel global si combinas varios balanceadores de cargas internos regionales mediante políticas de enrutamiento de DNS de ubicación geográfica. Puedes usar un balanceador de cargas de red de transferencia interno o un balanceador de cargas de aplicaciones interno. Sin las políticas de enrutamiento de DNS, un balanceador de cargas de aplicaciones interno solo puede usar extremos regionales. Con el balanceador de cargas de red de transferencia interno que usa el acceso global, puedes hacer que tu servicio esté disponible de forma global; en ese caso, los backends pueden estar en una sola región. Sin embargo, cuando usas políticas de enrutamiento de DNS, puedes tener backends en varias regiones.
En el siguiente diagrama, se muestra esta arquitectura:
En el diagrama anterior, se muestra cómo los clientes internos de varias regiones resuelven service.corp.example.com con Cloud DNS. Los clientes siempre reciben una respuesta que tiene una dirección IP que pertenece a un balanceador de cargas de red de transferencia interno que se encuentra en la región del cliente. El balanceador de cargas apunta a una aplicación que se encuentra en la misma región. En este ejemplo, la aplicación se ejecuta en Google Kubernetes Engine (GKE), pero esa no es una condición necesaria. Los clientes envían el tráfico de la aplicación a una instancia local de la aplicación, pero todos usan el mismo extremo de DNS service.corp.example.com.
Puedes crear esta configuración mediante los siguientes pasos:
- Creas los balanceadores de cargas internos en cada región. Si usas un balanceador de cargas de red de transferencia interno, debes habilitar el acceso global para asegurarte de que los clientes de otras regiones puedan conectarse al servicio.
Crea una política de enrutamiento de DNS. En la política, establece el tipo como
GEOy establece el valor--routing-policy-datacomo una lista de regiones de destino que se asignan al balanceador de cargas interno correspondiente. Puedes crear la configuración que se ilustra en el diagrama mediante el siguiente comando:gcloud beta dns record-sets create service.corp.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=fr-eu-w4;asia-east1=fr-as-e1;us-central1=fr-us-c1" \ --enable-health-checking
En el ejemplo, se crea un registro con un valor de TTL de 30 segundos para garantizar que los clientes actualicen los registros DNS con frecuencia en caso de que la política cambie.
Cuando usas políticas de enrutamiento de DNS, cada cliente recibe una respuesta de DNS que contiene la dirección IP del balanceador de cargas interno dentro de la región. Si el cliente se encuentra fuera de una región en la que se definen balanceadores de cargas internos, recibe la dirección IP del balanceador de cargas interno que se encuentra en la región más cercana.
Las políticas de enrutamiento de DNS enrutan el tráfico en función de la región del balanceador de cargas interno más cercana. Si más del 80% de los backends en esa región están en mal estado, y si usas la función de verificación de estado con políticas de enrutamiento de DNS geográfico, el tráfico pasa por todas las regiones.
Si no necesitas realizar una conmutación por error entre regiones, puedes cambiar el comando de la siguiente manera:
- Quita la marca
--enable-health-checking. - Reemplaza el nombre de cada regla de reenvío del balanceador de cargas interno por su dirección IP.
Un extremo global para un servicio externo que admite TCP y UDP
También puedes crear un extremo de DNS global para un servicio externo si combinas varios balanceadores de cargas externos regionales mediante políticas de enrutamiento de DNS de ubicación geográfica. El caso de uso más común es usar un balanceador de cargas de red de transferencia externo para cualquier aplicación basada en TCP o UDP. Este enfoque es útil, en particular, para aplicaciones que usan UDP, ya que no hay una opción de balanceo de cargas global disponible en Google Cloud para UDP.
Para las aplicaciones que usan tráfico de TCP compatible con el balanceador de cargas de red de proxy externo o el balanceador de cargas de aplicaciones externo, podrías usar instancias de esos balanceadores de cargas globales en lugar de usar un extremo de DNS. Estos balanceadores de cargas proporcionan balanceo de cargas entre regiones con anycast, que proporciona una sola dirección IP como frontend para todas las instancias de backend.
Las ventajas de usar las opciones de balanceo de cargas global en el extremo DNS son las siguientes:
- La conmutación por error es inmediata. La conmutación por error ocurre sin cambios visibles en el flujo de tráfico del lado del usuario.
- El enrutamiento de Internet determina el destino del balanceo de cargas. Los protocolos de enrutamiento de Internet reenvían el tráfico en función de la ruta más corta, en lugar de que Cloud DNS elija una ubicación de destino.
- Balanceo de cargas entre regiones. El balanceo de cargas global de Google admite la conmutación por error entre regiones. Por el contrario, no hay verificación de estado con las políticas de enrutamiento de DNS cuando usas un balanceador de cargas de red de transferencia externo.
Por lo tanto, te recomendamos que uses la opción de balanceo de cargas global de Google cuando tu aplicación se base en TCP y sea compatible con esos productos.
En el siguiente diagrama, se muestra la arquitectura mediante un extremo de DNS global:
En el diagrama anterior, se muestra cómo los clientes externos en varias regiones resuelven www.example.com mediante Cloud DNS. Los clientes reciben una respuesta con una dirección IP que pertenece a un balanceador de cargas de red TCP/UDP que está en la región del cliente. El cliente se puede conectar a una aplicación que se ejecuta en esa misma región. Cada cliente envía tráfico de aplicación a una instancia local del servicio, pero todos usan el mismo extremo de DNS www.example.com.
Puedes crear esta configuración mediante los siguientes pasos:
- Crea los balanceadores de cargas TCP/UDP de red en cada región.
Crea una política de enrutamiento de DNS. En la política, configura el tipo como
GEOy el valor--routing-policy-datacomo una lista de regiones de destino asignadas al balanceador de cargas TCP/UDP de red correspondiente. Puedes crear la configuración que se ilustra en el diagrama mediante el siguiente comando:gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.5;asia-east1=198.51.100.10;us-central1=203.0.113.33"
Después de aplicar esta política, cuando los clientes realizan solicitudes de DNS, cada cliente recibe una respuesta de DNS que contiene la dirección IP del balanceador de cargas de red de transferencia externo que se encuentra en la región más cercana a ese cliente.
El extremo global www.example.com no se puede usar para realizar la conmutación por error automáticamente para el tráfico entre regiones, ya que cuando usas un balanceador de cargas de red de transferencia externo, no hay verificación de estado. Es tu responsabilidad activar de forma manual la conmutación por error mediante el cambio de los registros DNS.
Otro caso de uso que puedes abordar con este enfoque es que tienes una aplicación que usa HTTP(S) con requisitos de regionalidad, pero aún deseas entregar datos mediante un extremo global. Para implementar esta situación, puedes combinar varias instancias del balanceador de cargas de aplicaciones externo regional con las políticas de enrutamiento de DNS de ubicación geográfica. Si no tienes requisitos de regionalidad, puedes usar un balanceador de cargas de aplicaciones externo global.
Un extremo de DNS global para un servicio híbrido
En algunos casos, puedes proporcionar un solo extremo para una aplicación híbrida mediante las políticas de enrutamiento de DNS de ubicación geográfica.
En el siguiente diagrama, se muestra esta arquitectura:
En el diagrama anterior, se muestra cómo los clientes externos en varias regiones resuelven www.example.com mediante Cloud DNS. Cloud DNS apunta a los usuarios de Internet en Asia y EE.UU. a una dirección IP que pertenece a un balanceador de cargas TCP/UDP de red que se encuentra en una región cercana a ellos. La aplicación a la que apunta el balanceador de cargas se ejecuta en GKE en la misma región. Para los usuarios de Internet en Europa, Cloud DNS muestra una dirección IP que apunta a un balanceador de cargas en un centro de datos local europeo, con la aplicación alojada en GKE en VMware. (En este ejemplo, las aplicaciones se ejecutan en GKE en VMware y en GKE, pero esa no es una condición necesaria).
Puedes crear esta configuración mediante los siguientes pasos:
- Crea los balanceadores de cargas de TCP/UDP de red y el balanceador de cargas local en cada región.
Crea una política de enrutamiento de DNS. En la política, configura el tipo como
GEOy el valor--routing-policy-datacomo una lista de regiones de destino asignadas al balanceador de cargas TCP/UDP de red correspondiente. Puedes crear la configuración que se ilustra en el diagrama mediante el siguiente comando:gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.51;asia-east1=198.51.100.10;us-central1=203.0.113.33"
Si configuras la marca --routing-policy-data, puedes hacer que Cloud DNS muestre diferentes direcciones IP según la región de Google Cloud más cercana.
Sin embargo, no puedes enrutar el tráfico según el país exacto o la región geográfica del cliente. En el ejemplo anterior, la mayoría de los usuarios se envían a una región o al centro de datos local que se encuentra en su continente. Sin embargo, es posible que el algoritmo que usa Cloud DNS para determinar la región más cercana de Google Cloud no se alinee con los límites específicos de geografía o país. Por lo tanto, no puedes usar políticas de enrutamiento de DNS de ubicación geográfica para casos de uso de cumplimiento.
Otros casos de uso que requieren un nivel de detalle mayor que el nivel de detalle a nivel de continente que se muestran en este ejemplo no son posibles con este enfoque híbrido. Por ejemplo, en los casos en los que puedas tener un centro de datos local en un país donde no existe una región de Google Cloud, no es posible enviar tráfico local para los usuarios de ese país o región. Solo puedes configurar el balanceador de cargas para que muestre direcciones IP según la región de Google Cloud más cercana. Si deseas restringir o enrutar el tráfico según la ubicación geográfica exacta o el país, puedes usar un proveedor de terceros que ofrezca un servicio de balanceo de cargas de servidor global (GSLB) basado en DNS.
¿Qué sigue?
- Administra políticas de enrutamiento de DNS.
- Prácticas recomendadas de DNS.
- Funciones del balanceador de cargas.
- Optimiza la latencia de las aplicaciones con el balanceo de cargas.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.