GSLB-Übersicht

Heutzutage ist die hohe Verfügbarkeit von IT-Services ein Muss. Aus diesem Grund entwickeln Unternehmen und Organisationen weltweit verteilte Computersysteme und hosten Services in mehr als einem Rechenzentrum, da sie die folgenden Vorteile bieten:

Fehlertoleranz: Wenn der gehostete Dienst im Rechenzentrum fehlschlägt, wird der Dienst an einem der anderen verfügbaren Standorte ausgeführt.
Automatische Wiederherstellung des Datencenters: Wenn ein Datencenter ausfällt, wird der Dienst automatisch an ein anderes verfügbares Datencenter umgeleitet.
LastverteilungDer Verkehr könnte optimiert werden, indem die Last auf alle verfügbaren Standorte verteilt wird, wodurch die Latenz verbessert und die Servicebereitstellung beschleunigt wird.
Latenz verbessert: Der Client-Anwendungsdatenverkehr befindet sich direkt mit dem realen Server. Es ist nicht erforderlich, alle Anwendungsdaten durch den Load Balancer zu übergeben.

Die Übernahme und Implementierung von IT-Services in der Cloud erfordert, dass eine auf WAN basierende Methode die beste Option ist, um Hochverfügbarkeitslösungen mit geografischem Standort bereitzustellen. Das nennen wir Globaler Service-Lastausgleich or GSLB.

Wann ist GSLB zu verwenden?

Es wird empfohlen, den GSLB-Dienst für die folgenden Anwendungsfälle zu verwenden:

Unternehmen, die ihre Dienste in mehr als einem Rechenzentrum über WAN hosten.
Unternehmen, die eine hohe Verfügbarkeit von Diensten oder Rechenzentren erfordern.
Internetdienstanbieter zum Erstellen von Inbound-Lastausgleichsdiensten, die von ihren Benutzern verwendet werden.

Auf jeden Fall ist GSLB die richtige Lösung, wenn Benutzer und Datenverkehr zwischen Servern auf der ganzen Welt ohne Fehlerquellen gemeinsam genutzt werden müssen.

Wie funktioniert die GSLB?

GSLB ist ein Lastausgleichsmechanismus nach DNS Protokoll ist es schnell und zuverlässig, weil es verwendet UDP Protokoll und die Antwort des Kunden erfolgt fast in Echtzeit.

Zum Beispiel bei einer allgemeinen DNS-Anfrage www.zvnlb.netsendet ein Client die DNS-Anforderungsauflösung an die lokal konfigurierten DNS-Server (z. B. 8.8.8.8 und 8.8.4.4 ) und dann wählt das Client-System zufällig einen der Server aus, um es gegen die Anfrage zu stellen und die Anfrage zu senden.

Der ausgewählte DNS-Server empfängt die Anfrage vom Client (z. B. die IP-Adresse) www.zvnlb.net? ) und die lokal konfigurierten DNS-Server versuchen herauszufinden, wer für die Auflösung der DNS-Zone verantwortlich ist zvnlb.net.

Das vom Client verwendete DNS, 8.8.8.8 or 8.8.4.4 in diesem Fall erkennt das ns1.zvnlb.net und ns2.zvnlb.net sind für Zonenauflösungen für verantwortlich zvnlb.net Sie senden also die vom Client empfangene DNS-Abfrage (z. B. die IP-Adresse) www.zvnlb.net? ) an einen von ihnen.

Einer der Nameserver auch ns1.zvnlb.net or ns2.zvnlb.net erhält die DNS-Anfrage von 8.8.8.8 or 8.8.4.4 und dann überprüft der Nameserver, der die Anfrage empfängt, die verfügbaren Server für den Host www.zvnlb.net und es antwortet auf die DNS-Abfrage mit der Liste der verfügbaren Anwendungsserver, um die echte Anwendung für den Host bereitzustellen www.zvnlb.netDaher werden diese Informationen endgültig vom Kunden erhalten.

Nun wählt der Client zufällig einen der Anwendungsserver aus der in der DNS-Abfrage erhaltenen Liste aus und sendet die Anfrage direkt an die Anwendung http://www.zvnlb.net.

Die Nameserver ns1.zvnlb.net (in unserem Beispiel in Frankfurt) und ns2.zvnlb.net (in unserem Beispiel in Toronto) überprüfen ständig den Gesundheitsstatus der realen Anwendung des Hosts www.zvnlb.net (192.235.113.3 und 194.23.52.21 in unserem Fall). Ob ns1.zvnlb.net or ns2.zvnlb.net Wenn bei der Überprüfung des Integritätsstatus einiger realer Server Probleme festgestellt werden, wird der nicht verfügbare Server für eine bestimmte Zeit deaktiviert und seine IP-Adresse wird nicht in den DNS-Abfragen aufgeführt, bis er wieder verfügbar ist.

Das folgende Diagramm zeigt den beschriebenen DNS-Verkehr mit GSLB-Funktionen.

Konfigurieren von GSLB für die Notfallwiederherstellung von Datencentern

Diese Konfiguration wird für Dienste empfohlen, für die eine hohe Verfügbarkeit von Datencentern für die Notfallwiederherstellung erforderlich ist. Wenn also alle Dienste eines bestimmten Unternehmens in einem Datencenter sind und ein solches Datencenter ausfällt, werden alle betroffenen Dienste in ein anderes verfügbares Datencenter verschoben .

Folgen Sie diesem Beispiel der GSLB-Konfiguration, um ein Aktiv-Passiv-Rechenzentrum für die Notfallwiederherstellung zu erstellen.

Wir haben zwei Zevenet Load Balancers in zwei Rechenzentren an verschiedenen Standorten in Frankfurt eingesetzt 159.89.7.124 und Toronto 159.203.12.35 und wir haben einen Webdienst, der auf den DNS-Host reagiert www.zvnlb.net, konfiguriert in 1 Rechenzentrum und 2 Rechenzentrum. Das Design dieser Architektur wird es erlauben, den gesamten Client-Datenverkehr an den Server zu senden 1 Rechenzentrum Wenn dies fehlschlägt, werden die Clients an weitergeleitet 2 Rechenzentrum.

Um diese Konfiguration zu erreichen, folgen Sie der nachstehenden Anleitung.

Stellen Sie eine Verbindung zum Zevenet-Webpanel im her 1 Rechenzentrum (Frankfurt für unseren Fall), klicken Sie im Hauptmenü GSLB Modul und erstellen Sie ein neues Farmwird in unserem Beispiel aufgerufen DNS1-Frankfurt im virtuellen Port 53.

Sobald die Farm erstellt wurde, bearbeiten Sie sie und gehen Sie zur Registerkarte Zonen und erstellen Sie in diesem Fall die DNS-Zone, die vom GSLB-Modul verwaltet wird zvnlb.net, wie folgt:

Nachdem diese Zone erstellt wurde, nehmen Sie bitte die erste Konfiguration vor, wie unten gezeigt:

Beachten Sie, dass ns1 und ns2 sind die Nameserver, die für die DNS-Auflösungen für die Zone verantwortlich sind zvnlb.net (In unserem Fall ein GSLB-Service in Frankfurt und ein weiterer in Toronto).

Stellen Sie dann eine Verbindung zum Zevenet-Webpanel im Data Center 2 her, und wählen Sie im Hauptmenü die Option aus GSLB und erstelle ein neues Farmin unserem Fall wird gerufen DNS2-Toronto im virtuellen Port 53.

Bearbeiten Sie die neue GSLB-Farm und wechseln Sie zur Registerkarte ZonenLegen Sie hier die DNS-Zone an, für die dieser GSLB-Dienst verwaltet wird zvnlb.net wie folgt:

Nachdem Sie diese neue Zone erstellt haben, nehmen Sie die erste Konfiguration wie folgt vor:

Wie der Fall der GSLB in der 1 Rechenzentrum, die Namenserver n1 und n2 wird in beiden auf die GSLB-Dienste verweisen 1 Rechenzentrum und 2 Rechenzentrum, Bzw.

Klicken Sie dann auf die Registerkarte Dienstleistungen und legen Sie beispielsweise einen neuen Dienst an Webpriorität:

Wähle aus Algorithmus Option Priorität: Verbindungen immer zu den meisten verfügbaren Preisen und konfigurieren Sie den Dienst wie folgt:

Starten Sie die Farm neu, um die Änderungen zu übernehmen. In beiden Rechenzentren muss dieselbe GSLB-Dienstkonfiguration angewendet werden.

Beachten Sie, dass wenn Farm Guardian ist nicht für die Durchführung einer Integritätsprüfung konfiguriert, der GSLB-Dienst verwendet einen Standardwert check_tcp an den im Feld Health Check in der Servicekonfiguration definierten TCP-Port.

Um den neuen Dienst zu aktivieren, wechseln Sie in die erstellte Zone (zvnlb.net in unserem Fall) und erstellen Sie ein neues Quelle. Dann erstellen Sie es, indem Sie das Neue auswählen Service wie es unten gezeigt wird.

Speichern Sie abschließend die Änderungen. Diese Konfiguration muss in beiden Rechenzentren angewendet werden.

An diesem Punkt ist der Gastgeber www.zvnlb.net wird vom GSLB-Modul in verwaltet Priorität Modus, so dass der gesamte Verkehr an den gesendet wird 1 Rechenzentrum Wenn dies fehlschlägt, wird der Datenverkehr zu den anderen verfügbaren Daten umgeleitet 2 Rechenzentrum.

Die TTL wurde auf 5 konfiguriert. Dies ist die Art des Ablaufdatums, das in einen DNS-Eintrag aufgenommen wird. Die TTL dient dazu, dem rekursiven Server oder lokalen Resolver mitzuteilen, wie lange er diesen Datensatz in seinem Cache behalten soll. Wenn also ein niedrigerer Wert schneller konfiguriert wird, werden die Änderungen erkannt.

Bei Verwendung dieser Methode könnten so viele Rechenzentren hinzugefügt werden, wie erforderlich, indem neue Namenserver mit dem GSLB-Dienst hinzugefügt werden.

Die folgende DNS-Anfrage zeigt die Nameserver-Konfiguration für zvnlb.net und die DNS-Auflösung für den Host www.zvnlb.net.

user@client:# host -t ns zvnlb.net
zvnlb.net name server ns2.zvnlb.net.
zvnlb.net name server ns1.zvnlb.net.

Beide Nameserver verwenden die in den GSLB-Farmen konfigurierten virtuellen IP-Adressen.

Verwenden Sie jetzt Ihre aktuellen DNS-Server, um einen Host aufzulösen (z. B. www) in dieser Zone:

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211

Wie es gezeigt wird, ist derzeit der Host 188.166.230.211 ist der aktive reale Anwendungsknoten im 1 Rechenzentrum. Sobald der Host nicht erreichbar ist (z. B. der http-Dienst in 188.166.230.211 ist nicht verfügbar) Die DNS-Auflösung ändert sich wie unten gezeigt.

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

Sobald der Anwendungsserver ausfällt, ändert die DNS-Auflösung den Host in den 2 Rechenzentrum. Sobald der Gastgeber in der 1 Rechenzentrum ist der Fail-Back automatisch angewendet.

Konfigurieren der GSLB für aktiv aktive Rechenzentren

Die hohe Verfügbarkeit mit der Moduspriorität ist eine gute Option für ein Disaster Recovery-System, aber das Backup-Rechenzentrum, das für die Wiederherstellung verwendet wird, wird nicht zu stark genutzt. Daher ist es normalerweise effizienter, den gesamten Datenverkehr zwischen den verfügbaren Daten zu verteilen Zentren.

Verwenden Sie in solchen Fällen bitte die Freigabemethode für Ihren GSLB-Dienst Round Robin Load Balancing wie es im Beispiel für den neuen Dienst gezeigt wird Netz:

Fügen Sie es jetzt in der Zone hinzu zvnlb.net und ändern Sie die Ressourcenkonfiguration www wie folgt:

Speichern Sie die Änderungen und starten Sie die Farm erneut, wenn Sie dazu aufgefordert werden.

Versuchen Sie zum Testen, den Host aufzulösen www.zvnlb.net und die Ausgabe sieht wie folgt aus:

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211
Name:	www.zvnlb.net
Address: 139.59.186.84

Beachten Sie, dass der DNS-Resolver beide Anwendungsserver zurückgibt, anstatt einen Server wie den Disaster Recovery-Fall.

Wenn der Host einen Fehler aufweist, ändert sich die DNS-Auflösung automatisch. Siehe unten, was passiert.

root@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

Der nicht verfügbare Anwendungsserver wird in der DNS-Antwortliste deaktiviert.

Sobald der Gastgeber 188.166.230.211 wieder verfügbar ist, wird es wieder in die DNS-Auflösung aufgenommen.

Delegieren einer Zone im Zevenet GSLB-Dienst

Im Falle einer öffentlichen Zone (zum Beispiel zvnlb.net), der einen GSLB-Dienst als Nameserver-Resolver bereitstellt, der von öffentlichen DNS-Servern für eine solche Domain erkannt werden muss, muss dann die vom GSLB-Service verwendete öffentliche IP-Adresse im Registrar Ihrer Domain registrieren (wie NameCheap, Goddady oder andere). . Unter dem folgenden Link wird erläutert, wie Sie GSLB-IPs als NameServer in einer Domain-Registrierungsprozedur registrieren.

Registrieren Sie einen Host als NameServer

Nach dem angegebenen Verfahren müssen Sie sich registrieren ns1.zvnlb.net und ns2.zvnlb.net mit den angegebenen IPs.

Erstellen einer dedizierten Subzone für GSLB

Für den Fall, dass die DNS-Auflösung nicht an den GSLB-Dienst von Zevenet delegiert werden kann, kann die unten erläuterte Konfiguration durchgeführt werden. Das folgende Beispiel zeigt, wie Sie eine erstellen Subzone For zvnlb.net das verweist auf die NameServer dieser neuen Subzone im GSLB-Service.

Knoten 1 (zum Beispiel ns1.zvnlb.net mit IP 162.243.5.109) und Knoten 2 (zum Beispiel ns2.zvnlb.net mit IP 178.62.233.104) sind Nameserver konfiguriert und bieten DNS-Auflösungsdienste für die Zone an zvnlb.netDiese Zone befindet sich unter einem öffentlichen DNS-Dienst von Bind9. Wir möchten GSLB-Funktionen für einige Hosts unserer Infrastruktur anbieten. Daher haben wir uns für die Einrichtung der DNS-Subzone entschieden cluster.zvnlb.net und konfigurieren Sie 2-GSLB-Farmen wie DNS-Nameserver für diesen Zweck.

Wir haben die Subzone für unsere Domain geschaffen cluster.zvnlb.net in unseren Bind9 DNS-Servern wie folgt:

Folgen Sie nun dem Abschnitt Delegieren einer Zone im Zevenet GSLB-Dienst um zu behalten 159.89.7.124 und 159.203.12.35 in unserem Beispiel als anerkannte Nameserver für die Zone cluster.zvnlb.net von öffentlichen DNS-Servern.

Anschließend können Sie die Konfiguration wie in der Domäne beschrieben anwenden zvnlb.net im Abschnitt oben Konfigurieren der GSLB für die Notfallwiederherstellung von Datencentern.

Verweist auf einen Host in unserem eigenen DNS, der auf einen GSLB-Dienst verweist

In den vorherigen Abschnitten haben wir einen Host mit dem Namen erstellt www.zvnlb.net Lastausgleich im Prioritäts- und Round-Robin-Modus, sodass wir diese Konfiguration wiederverwenden können, um einem anderen DNS-Nameserver GSLB-Funktionen anzubieten, der diese Funktion standardmäßig nicht unterstützt.

Um diese Konfiguration zu erreichen, müssen wir nur eine neue erstellen Quelle in der DNS-Zone, die keine GSLB-Optionen unterstützt (zum Beispiel zevenet.io wird von Bind9) wie a verwaltet Eindeutige Bezeichnung or CNAME wie es unten zeigt:

Sobald die Änderung angewendet wird, www.zevenet.io wird auf zeigen www.zvnlb.netaber wenn die Hostauflösung www.zvnlb.net ändert sich dann automatisch www.zevenet.io wird sich auch ändern.

Beachten Sie, dass dieses Beispiel auf einem Bind9-DNS-Server ausgeführt wird. Canonical Names oder CNAMES sind DNS-Host-Konfigurationen, die von einer beliebigen DNS-Serverdienstimplementierung unterstützt werden.

Diese einfache Erklärung zeigt, dass ein GSLB-Dienst auch dann verwendet werden kann, wenn unser aktueller DNS-Dienst keine GSLB-Funktionen bietet. Er leitet lediglich die Auflösung des angegebenen Hosts in einer Nicht-GSLB-Zone an den GSLB-Dienst in Zevenet Load Balancer weiter.