GSLB Vue d'ensemble #

De nos jours, la haute disponibilité des services informatiques est un impératif. C’est la raison pour laquelle les entreprises développent des systèmes informatiques répartis dans le monde entier et hébergent des services dans plusieurs centres de données, car ils offrent les avantages suivants:

Tolérance aux pannes: lorsque le service hébergé dans le centre de données échoue, le service est activé sur l’un des autres sites disponibles.
Récupération automatique du centre de données: lorsqu'un centre de données tombe en panne, le service est automatiquement redirigé vers tout autre centre de données disponible.
Load Balancing: le trafic pourrait être optimisé en répartissant la charge entre tous les sites disponibles, améliorant ainsi le temps de latence et accélérant la fourniture du service.
Latence améliorée: le trafic de l'application client se fait directement avec le serveur réel, il n'est donc pas nécessaire de transmettre toutes les données de l'application via l'équilibreur de charge.

L'adoption et la mise en œuvre de services informatiques dans le Cloud exigent qu'une méthode basée sur le WAN soit la meilleure option pour fournir des solutions de haute disponibilité géolocalisées. C'est ce qu'on appelle Équilibrage global de la charge de service or GSLB.

Quand utiliser GSLB #

Il est recommandé d’utiliser le service GSLB pour les cas d’utilisation suivants:

Les entreprises qui hébergent leurs services dans plusieurs centres de données via le réseau étendu.
Entreprises ayant besoin de créer une haute disponibilité de services ou de centres de données.
Les fournisseurs de services Internet créent des services d'équilibrage de la charge entrante à utiliser par leurs utilisateurs.

Décidément, lorsqu'il est nécessaire de partager les utilisateurs et le trafic entre les serveurs du monde entier sans points de défaillance, GSLB est la bonne solution.

Comment fonctionne GSLB #

GSLB est un mécanisme d'équilibrage de charge sur DNS protocole, il est rapide et fiable car il utilise UDP protocole et la réponse du client est presque en temps réel.

Dans une requête DNS commune, par exemple www.zvnlb.net, un client envoie la résolution de la requête DNS aux serveurs DNS configurés locaux (par exemple 8.8.8.8 et 8.8.4.4 ) puis le système client sélectionne aléatoirement l’un des serveurs à appliquer à la requête et à envoyer la requête.

Le serveur DNS sélectionné reçoit la demande du client (par exemple, quelle est l'adresse IP de www.zvnlb.net? ) et les serveurs DNS configurés locaux tentent de trouver le responsable de la résolution de la zone DNS zvnlb.net.

Le DNS utilisé par le client, 8.8.8.8 or 8.8.4.4 dans ce cas, détecte que ns1.zvnlb.net et ns2.zvnlb.net sont responsables des résolutions de zone pour zvnlb.net ils envoient la requête DNS reçue par le client (par exemple, quelle est l'adresse IP de www.zvnlb.net? ) à l'un d'entre eux.

Un des serveurs de noms soit ns1.zvnlb.net or ns2.zvnlb.net reçoit la requête DNS de 8.8.8.8 or 8.8.4.4 puis le serveur de noms qui reçoit la demande vérifie l'hôte des serveurs disponibles www.zvnlb.net et il répondra à la requête DNS avec la liste des serveurs d'applications disponibles pour servir l'application réelle à l'hôte www.zvnlb.netPar conséquent, cette information sera finalement reçue par le client.

Maintenant, le client sélectionnera au hasard l'un des serveurs d'applications dans la liste reçue dans la requête DNS et enverra directement la requête à l'application. http://www.zvnlb.net.

Les serveurs de noms ns1.zvnlb.net (dans notre exemple, situé à Francfort) et ns2.zvnlb.net (dans notre exemple, situé à Toronto) vérifient régulièrement l’état de santé de l’application réelle de l’hôte www.zvnlb.net (192.235.113.3 et 194.23.52.21 dans notre cas). Si ns1.zvnlb.net or ns2.zvnlb.net détecte tout problème de vérification de l’état de santé de certains des serveurs réels, puis le serveur indisponible sera désactivé pendant un certain temps et son adresse IP ne sera pas répertoriée dans les requêtes DNS jusqu’à ce qu’il soit à nouveau disponible.

Le diagramme suivant illustre le trafic DNS décrit avec les fonctionnalités GSLB.

Configuration de GSLB pour la récupération après sinistre des centres de données #

Cette configuration est recommandée pour les services nécessitant une haute disponibilité des centres de données pour la récupération après sinistre. Par conséquent, si tous les services d'une société donnée se trouvent dans un centre de données et que ce centre de données tombe en panne, le système transfère tous les services concernés vers un autre centre de données disponible. .

Suivez cet exemple réel de configuration GSLB pour créer un centre de données actif-passif pour la récupération après sinistre.

Nous avons déployé deux RELIANOID Équilibreurs de charge répartis sur deux centres de données situés sur des sites différents, à Francfort 159.89.7.124 et Toronto 159.203.12.35 et nous avons un service Web qui répond à l'hôte DNS www.zvnlb.net, configuré dans Centre de données 1 et Centre de données 2. La conception de cette architecture va permettre d’envoyer tout le trafic des clients vers le Centre de données 1 mais si cela échoue, les clients sont redirigés vers Centre de données 2.

Pour réaliser cette configuration, suivez la procédure ci-dessous.

Connectez-vous à RELIANOID panneau Web dans le Centre de données 1 (Francfort pour notre cas), cliquez dans le menu principal GSLB module et créer un nouveau Ferme, dans notre exemple, sera appelé DNS1-Frankfurt dans le port virtuel 53.

Une fois la ferme créée, éditez-la et cliquez sur l'onglet Zones et créez la zone DNS qui sera gérée par le module GSLB, dans ce cas zvnlb.net, comme suit :

Une fois cette zone créée, veuillez effectuer la première configuration comme indiqué ci-dessous:

Notez que ns1 et ns2 sont les serveurs de noms responsables des résolutions DNS pour la zone zvnlb.net (dans notre cas, un service GSLB à Francfort et un autre à Toronto).

Ensuite, connectez-vous au RELIANOID panneau Web dans le Data Center 2, dans le menu principal sélectionnez GSLB et créer un nouveau Ferme, dans notre cas, sera appelé DNS2-Toronto dans le port virtuel 53.

Éditez la nouvelle batterie GSLB et allez à l'onglet Zones, créez ici la zone DNS qui sera gérée par ce service GSLB pour zvnlb.net comme suit:

Une fois cette nouvelle zone créée, veuillez effectuer la première configuration comme suit:

Comme le cas du GSLB dans le Centre de données 1, les serveurs de noms n1 et n2 pointera vers les services GSLB dans les deux Centre de données 1 et Centre de données 2, Respectivement.

Puis cliquez dans l'onglet Services et créez un nouveau service, par exemple webpriority:

Sélectionnez le Algorithme option Priorité: Connexions toujours au plus prio disponible et configurez le service comme suit:

Redémarrez la batterie pour appliquer les modifications. Il est nécessaire d'appliquer la même configuration de service GSLB dans les deux centres de données.

Notez que si Gardien de ferme n’est pas configuré pour appliquer un contrôle de santé, le service GSLB utilise une valeur par défaut. check_tcp au port TCP défini dans le champ de vérification de la santé de la configuration du service.

Pour activer le nouveau service, allez dans la zone créée (zvnlb.net dans notre cas) et créer un nouveau Ressources. Puis créez le en sélectionnant le nouveau Services comme indiqué ci-dessous.

Enfin, enregistrez les modifications. Il est nécessaire d'appliquer cette configuration dans les deux centres de données.

À ce stade, l'hôte www.zvnlb.net est géré par le module GSLB dans Priorité mode, de sorte que tout le trafic sera envoyé au Centre de données 1 et puis, si cela échoue, le trafic sera redirigé vers les autres Centre de données 2.

Le TTL a été configuré sur 5, c'est le type de date d'expiration qui est mis sur un enregistrement DNS. Le TTL sert à indiquer au serveur récursif ou au résolveur local combien de temps il doit conserver ledit enregistrement dans son cache. Ainsi, une valeur inférieure configurée plus rapidement les changements sont détectés.

En appliquant cette méthode, nous pourrions ajouter autant de centres de données que nécessaire en incluant de nouveaux serveurs de noms avec le service GSLB.

La requête DNS suivante indique la configuration des serveurs de noms pour zvnlb.net et la résolution DNS pour l'hôte www.zvnlb.net.

utilisateur@client : # hôte -t ​​ns zvnlb.net serveur de noms zvnlb.net ns2.zvnlb.net. Serveur de noms zvnlb.net ns1.zvnlb.net.

Les deux serveurs de noms utilisent les adresses IP virtuelles configurées dans les batteries GSLB.

Maintenant, utilisez vos serveurs DNS actuels pour résoudre un hôte (par exemple www) dans cette zone:

utilisateur@client :# nslookup www.zvnlb.net Serveur : 8.8.8.8 Adresse : 8.8.8.8#53 Réponse ne faisant pas autorité : Nom : www.zvnlb.net Adresse : 188.166.230.211

Comme il est montré, actuellement l'hôte 188.166.230.211 est le nœud d'application réelle actif dans le Centre de données 1. Dès que l'hôte n'est pas accessible (par exemple, le service http de 188.166.230.211 est en baisse) la résolution DNS changera comme indiqué ci-dessous.

utilisateur@client :# nslookup www.zvnlb.net Serveur : 8.8.8.8 Adresse : 8.8.8.8#53 Réponse ne faisant pas autorité : Nom : www.zvnlb.net Adresse : 139.59.186.84

Dès que le serveur d’application tombe en panne, la résolution DNS changera l’hôte en hôte. Centre de données 2. Une fois l'hôte dans le Centre de données 1 est en place le retour en arrière sera appliqué automatiquement.

Configuration de GSLB pour les centres de données actifs / actifs #

La haute disponibilité avec la priorité de mode est une bonne option pour un système de récupération après sinistre, mais le centre de données de sauvegarde utilisé pour la récupération n'est pas trop utilisé, il est donc généralement plus efficace d'équilibrer la charge de tout le trafic entre les données disponibles centres.

Dans ce cas, veuillez utiliser la méthode de partage de votre service GSLB appelée Round Robin Load Balancing comme indiqué dans l'exemple du nouveau service appelé web:

Maintenant, ajoutez-le dans la zone zvnlb.net et changer la configuration de la ressource www comme suit:

Enregistrez les modifications et redémarrez la batterie si nécessaire.

Pour le tester, essayez de résoudre l'hôte www.zvnlb.net et le résultat ressemblera à ce qu'il est montré:

utilisateur@client :# nslookup www.zvnlb.net Serveur : 8.8.8.8 Adresse : 8.8.8.8#53 Réponse ne faisant pas autorité : Nom : www.zvnlb.net Adresse : 188.166.230.211 Nom : www.zvnlb.net Adresse : 139.59.186.84 .XNUMX

Notez que le résolveur DNS renvoie les deux serveurs d'applications au lieu d'un comme le cas de récupération après sinistre.

Une fois que l'hôte a un échec, la résolution DNS changera automatiquement. Voir ci-dessous ce qui se passe.

root@client :# nslookup www.zvnlb.net Serveur : 8.8.8.8 Adresse : 8.8.8.8#53 Réponse ne faisant pas autorité : Nom : www.zvnlb.net Adresse : 139.59.186.84

Le serveur d'applications non disponible est désactivé de la liste de réponses DNS.

Dès que l'hôte 188.166.230.211 est à nouveau disponible, il sera inclus dans la résolution DNS.

Déléguer une zone dans le RELIANOID Service GSLB #

Dans le cas d'une zone publique (par exemple zvnlb.net) qui fournit un service GSLB en tant que résolveur de serveur de noms qui doit être reconnu par les serveurs DNS publics pour ce domaine, il est alors nécessaire d'enregistrer l'adresse IP publique utilisée par le service GSLB dans le bureau d'enregistrement de votre domaine (comme NameCheap, Goddady ou autres) . Le lien suivant explique comment enregistrer des adresses IP GSLB en tant que serveurs de noms dans une procédure de registraire de domaine.

Enregistrer un hôte en tant que serveur de noms

En suivant la procédure indiquée, vous devez vous inscrire ns1.zvnlb.net et ns2.zvnlb.net avec les IP donnés.

Création d'une sous-zone dédiée pour GSLB #

Juste au cas où il ne serait pas possible de déléguer la résolution DNS au service GSLB de RELIANOID, la configuration expliquée ci-dessous pourrait être réalisée. L'exemple suivant montre comment construire un sous-zone pour zvnlb.net qui pointe vers les NameServers de cette nouvelle sous-zone du service GSLB.

Nœud 1 (par exemple ns1.zvnlb.net avec IP 162.243.5.109) et Nœud 2 (par exemple ns2.zvnlb.net avec IP 178.62.233.104) sont des serveurs de noms configurés offrant des services de résolution DNS pour la zone zvnlb.net, cette zone est sous un service DNS public Bind9 et nous souhaitons offrir des fonctionnalités GSLB à certains hôtes de notre infrastructure. Nous avons donc décidé de créer la sous-zone DNS. cluster.zvnlb.net et configurez des batteries 2 GSLB telles que des serveurs de noms DNS à cette fin.

Nous avons créé la sous-zone pour notre domaine cluster.zvnlb.net dans nos serveurs DNS Bind9 comme suit:

Suivez maintenant la section Déléguer une zone dans le RELIANOID Service GSLB pour garder 159.89.7.124 et 159.203.12.35 dans notre exemple en tant que serveurs de noms reconnus pour la zone cluster.zvnlb.net par les serveurs DNS publics.

Ensuite, vous pouvez appliquer la configuration comme expliqué pour le domaine zvnlb.net dans la section ci-dessus Configuration de GSLB pour la récupération après sinistre des centres de données.

Pointage d'un hôte dans notre propre DNS référencé à un service GSLB #

Dans les sections précédentes, nous avons créé un hôte nommé www.zvnlb.net équilibrage de charge en modes priorité et round robin, afin que nous puissions réutiliser cette configuration afin d'offrir des capacités GSLB à un autre serveur de noms DNS qui ne prend pas en charge cette fonctionnalité par défaut.

Pour réaliser cette configuration, il suffit de créer un nouveau Ressources dans la zone DNS qui ne prend pas en charge les options GSLB (par exemple relianoid.io est géré par Bind9) comme un Nom canonique or CNAME comme il est montré ci-dessous:

Une fois que le changement est appliqué, www.relianoid.io montrera www.zvnlb.net, mais si la résolution de l'hôte www.zvnlb.net change ensuite automatiquement www.relianoid.io va changer aussi bien.

Notez que cet exemple est effectué sur un serveur DNS Bind9 mais que les noms canoniques ou CNAMES sont des configurations d'hôte DNS prises en charge par toute implémentation de service de serveur DNS.

Cette explication simple montre qu'un service GSLB peut être utilisé même si notre service DNS actuel n'offre pas de fonctionnalités GSLB, en transmettant simplement la résolution de l'hôte donné dans une zone non GSLB au service GSLB dans RELIANOID Équilibreur de charge.