Ce document explique comment combiner plusieurs équilibreurs de charge régionaux avec les règles de routage DNS de Google pour créer des architectures d'équilibrage de charge global. Ce document est destiné aux ingénieurs réseau, aux architectes de solutions et aux professionnels des opérations. Nous partons du principe que vous disposez des connaissances de base sur Google Compute Engine et que vous maîtrisez les concepts de mise en réseau tels que les équilibreurs de charge et les résolutions DNS.
Introduction
Lorsque vous créez un service global implémenté en tant qu'application s'exécutant dans plusieurs régions, vous pouvez utiliser les règles de routage DNS de géolocalisation pour définir un point de terminaison DNS global pour vos équilibreurs de charge régionaux. Dans cette approche, vous créez un point de terminaison global qui achemine le trafic vers le service local le plus proche.
Selon le type d'équilibreur de charge que vous utilisez, vous pouvez peut-être obtenir ce scénario avec des options d'équilibrage de charge global basé sur un proxy. Toutefois, dans certains cas d'utilisation, vous devez utiliser des produits d'équilibrage de charge régionaux, par exemple si votre service diffuse du trafic UDP. Les règles de routage DNS de géolocalisation peuvent également vous aider à fournir un point de terminaison DNS unique pour les applications hybrides utilisant Google Cloud conjointement avec d'autres fournisseurs de services cloud ou avec un déploiement sur site.
Architecture
Le schéma suivant montre un exemple d'architecture utilisant trois équilibreurs de charge régionaux dans trois régions différentes. Les régions sont combinées à l'aide de règles de routage DNS.
Le schéma précédent montre comment les clients situés en Oregon, en Allemagne et à Singapour effectuent des résolutions DNS vers Cloud DNS pour www.example.com. Les requêtes sont acheminées vers des équilibreurs de charge régionaux à proximité de chaque client pour atteindre une application hébergée dans trois régions différentes.
Cas d'utilisation des règles de routage DNS de géolocalisation
Cette section aborde les cas d'utilisation suivants pour l'utilisation des règles de routage DNS de géolocalisation afin de créer un service global à partir de plusieurs équilibreurs de charge régionaux :
- Un service interne accessible et distribué dans le monde entier
- Un point de terminaison DNS global pour un service externe compatible avec TCP et UDP
- Un point de terminaison DNS global pour un service hybride
Un service interne accessible et distribué dans le monde entier
Vous pouvez créer un service interne accessible et distribué à l'échelle mondiale en combinant plusieurs équilibreurs de charge internes régionaux à l'aide de règles de routage DNS de géolocalisation. Vous pouvez utiliser un équilibreur de charge réseau interne à stratégie directe ou un équilibreur de charge d'application interne. Sans règles de routage DNS, un équilibreur de charge d'application interne ne peut utiliser que des points de terminaison régionaux. Avec un équilibreur de charge réseau interne à stratégie directe qui utilise l'accès mondial, vous pouvez rendre votre service disponible dans le monde entier. Dans ce cas, les backends ne peuvent se trouver que dans une seule région. Toutefois, lorsque vous utilisez des règles de routage DNS, vous pouvez avoir des backends dans plusieurs régions.
Le schéma suivant illustre cette architecture :
Le schéma précédent montre comment les clients internes de plusieurs régions résolvent service.corp.example.com à l'aide de Cloud DNS. Les clients reçoivent toujours une réponse avec une adresse IP appartenant à un équilibreur de charge réseau interne à stratégie directe situé dans la région du client. L'équilibreur de charge pointe vers une application située dans la même région. (Dans cet exemple, l'application s'exécute sur Google Kubernetes Engine (GKE), mais ce n'est pas une condition nécessaire.) Les clients envoient le trafic de l'application à une instance locale de l'application, mais ils utilisent tous le même point de terminaison DNS service.corp.example.com.
Vous pouvez créer cette configuration en procédant comme suit :
- Vous créez les équilibreurs de charge internes dans chaque région. Si vous utilisez un équilibreur de charge réseau interne à stratégie directe, vous devez activer l'accès mondial pour vous assurer que les clients d'autres régions peuvent se connecter au service.
Vous créez une règle de routage DNS. Dans la règle, vous définissez le type sur
GEOet la valeur--routing-policy-datasur une liste des régions cibles mappées avec l'équilibreur de charge interne correspondant. Vous pouvez créer la configuration illustrée dans le schéma à l'aide de la commande suivante :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
Dans cet exemple, un enregistrement est créé avec une valeur TTL de 30 secondes pour garantir que les clients actualisent fréquemment les enregistrements DNS en cas de modification de la règle.
Lorsque vous utilisez des règles de routage DNS, chaque client reçoit une réponse DNS contenant l'adresse IP de l'équilibreur de charge interne intra-régional. Si le client se trouve en dehors d'une région où les équilibreurs de charge internes sont définis, il reçoit l'adresse IP de l'équilibreur de charge interne situé dans la région la plus proche.
Les règles de routage DNS acheminent le trafic en fonction de la région d'équilibreur de charge interne la plus proche. Si plus de 80 % des backends de cette région ne sont pas opérationnels et si vous utilisez la fonctionnalité de vérification de l'état avec des règles de routage DNS géographiques, le trafic bascule entre les régions.
Si vous n'avez pas besoin du basculement entre régions, vous pouvez modifier la commande comme suit :
- Supprimez l'option
--enable-health-checking. - Remplacez le nom de chaque règle de transfert pour l'équilibreur de charge interne par son adresse IP.
Un point de terminaison global pour un service externe compatible avec TCP et UDP
Vous pouvez également créer un point de terminaison DNS global pour un service externe en associant plusieurs équilibreurs de charge externes régionaux à l'aide de règles de routage DNS de géolocalisation. Le cas d'utilisation le plus courant consiste à utiliser un équilibreur de charge réseau passthrough externe pour toute application basée sur TCP ou UDP. Cette approche est particulièrement utile pour les applications qui utilisent le protocole UDP, car aucune option d'équilibrage de charge global n'est disponible sur Google Cloud pour UDP.
Pour les applications qui utilisent le trafic TCP et qui sont compatibles avec l'équilibreur de charge réseau proxy externe ou l'équilibreur de charge d'application externe, vous pouvez peut-être utiliser des instances de ces équilibreurs de charge globaux au lieu d'utiliser un point de terminaison DNS. Ces équilibreurs de charge assurent un équilibrage de charge interrégional avec anycast, qui fournit une adresse IP unique comme interface pour toutes vos instances backend.
Les avantages des options d'équilibrage de charge global par rapport au point de terminaison DNS sont les suivants :
- Le basculement est immédiat. Le basculement se produit sans modification visible du flux de trafic côté utilisateur.
- Le routage Internet détermine la cible de l'équilibrage de charge. Les protocoles de routage Internet transfèrent le trafic en fonction du chemin d'accès le plus court, plutôt que de choisir un emplacement cible dans Cloud DNS.
- Équilibrage de charge interrégional : L'équilibrage de charge global de Google est compatible avec le basculement interrégional. En revanche, il n'y a pas de vérification d'état avec les règles de routage DNS lorsque vous utilisez un équilibreur de charge réseau externe à stratégie directe.
Par conséquent, nous vous recommandons d'utiliser l'option d'équilibrage de charge global de Google lorsque votre application est basée sur TCP et compatible avec ces produits.
Le schéma suivant illustre l'architecture utilisant un point de terminaison DNS global :
Le schéma précédent montre comment les clients externes dans plusieurs régions résolvent www.example.com à l'aide de Cloud DNS. Les clients reçoivent une réponse avec une adresse IP appartenant à un équilibreur de charge réseau TCP/UDP situé dans la région du client. Le client peut ensuite se connecter à une application qui s'exécute dans la même région. Chaque client envoie le trafic de l'application à une instance locale du service, mais ils utilisent tous le même point de terminaison DNS www.example.com.
Vous pouvez créer cette configuration en procédant comme suit :
- Vous créez les équilibreurs de charge réseau TCP/UDP dans chaque région.
Vous créez une règle de routage DNS. Dans la règle, vous définissez le type sur
GEOet la valeur--routing-policy-datasur une liste des régions cibles mappées avec l'équilibreur de charge réseau TCP/UDP correspondant. Vous pouvez créer la configuration illustrée dans le schéma à l'aide de la commande suivante :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"
Après avoir appliqué cette règle, lorsque les clients effectuent des requêtes DNS, chaque client reçoit une réponse DNS contenant l'adresse IP de l'équilibreur de charge réseau externe à stratégie directe situé dans la région la plus proche de ce client.
Le point de terminaison global www.example.com ne peut pas être utilisé pour effectuer automatiquement le basculement entre les régions, car lorsque vous utilisez un équilibreur de charge réseau externe à stratégie directe, aucune vérification d'état n'est effectuée. Vous êtes tenu de déclencher le basculement manuellement en modifiant les enregistrements DNS.
Cette approche permet également de traiter le cas d'une application utilisant HTTP(S) avec des exigences de régionalité pour vos données, mais pour laquelle vous souhaitez tout de même diffuser des données à l'aide d'un point de terminaison global. Vous pouvez mettre en œuvre ce scénario en combinant plusieurs instances d'équilibreur de charge d'application externe régional à l'aide de règles de routage DNS de géolocalisation. Si vous n'avez pas d'exigences de régionalité, vous pouvez utiliser un équilibreur de charge d'application externe global.
Un point de terminaison DNS global pour un service hybride
Dans certains cas, vous pouvez fournir un seul point de terminaison pour une application hybride à l'aide de règles de routage DNS de géolocalisation.
Le schéma suivant illustre cette architecture :
Le schéma précédent montre comment les clients externes dans plusieurs régions résolvent www.example.com à l'aide de Cloud DNS. Cloud DNS pointe les utilisateurs Internet en Asie et aux États-Unis vers une adresse IP appartenant à un équilibreur de charge réseau TCP/UDP situé dans une région à proximité. L'application vers laquelle pointe l'équilibreur de charge s'exécute sur GKE dans la même région. Pour les utilisateurs d'Internet en Europe, Cloud DNS renvoie une adresse IP pointant vers un équilibreur de charge dans un centre de données européen sur site, avec l'application hébergée sur GKE sur VMware. (Dans cet exemple, les applications s'exécutent sur GKE sur VMware et sur GKE, mais ce n'est pas une condition nécessaire.)
Vous pouvez créer cette configuration en procédant comme suit :
- Vous créez les équilibreurs de charge réseau TCP/UDP et l'équilibreur de charge sur site dans chaque région.
Vous créez une règle de routage DNS. Dans la règle, vous définissez le type sur
GEOet la valeur--routing-policy-datasur une liste des régions cibles mappées avec l'équilibreur de charge réseau TCP/UDP correspondant. Vous pouvez créer la configuration illustrée dans le schéma à l'aide de la commande suivante :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"
En définissant l'option --routing-policy-data, vous pouvez demander à Cloud DNS de renvoyer différentes adresses IP en fonction de la région Google Cloud la plus proche.
Cependant, vous ne pouvez pas acheminer le trafic en fonction du pays ou de la région géographique exact du client. Dans l'exemple précédent, la plupart des utilisateurs sont envoyés vers une région ou vers un centre de données sur site qui se trouve sur leur continent. Toutefois, il est possible que l'algorithme utilisé par Cloud DNS pour déterminer la région Google Cloud la plus proche ne corresponde pas à des frontières de pays ou des limites géographiques spécifiques. Vous ne pouvez donc pas utiliser les règles de routage DNS de géolocalisation pour les cas d'utilisation de conformité.
D'autres cas d'utilisation nécessitant une granularité supérieure à la granularité au niveau du continent présentée dans cet exemple ne sont pas possibles avec cette approche hybride. Par exemple, si vous disposez d'un centre de données sur site dans un pays où aucune région Google Cloud n'existe, il n'est pas possible d'envoyer du trafic sur site pour les utilisateurs de ce pays ou de cette région. Vous pouvez uniquement configurer l'équilibreur de charge pour qu'il renvoie les adresses IP en fonction de la région Google Cloud la plus proche. Si vous souhaitez limiter ou acheminer le trafic en fonction d'un emplacement géographique ou d'un pays exact, vous pouvez utiliser un fournisseur tiers proposant un service d'équilibrage de charge serveur global basé sur DNS (GSLB, Global Server Load Balancing).
Étapes suivantes
- Gérer les règles de routage DNS.
- Bonnes pratiques DNS.
- Fonctionnalités de l'équilibreur de charge.
- Optimiser la latence des applications avec l'équilibrage de charge.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.