Im folgenden Blogbeitrag werde ich einen kurzen Überblick über die Funktionalität / Architektur des NetScaler Global Server Load Balancings (GSLBs) geben.
Was GSLB ist und wofür wird es verwendet?
GSLB dient überwiegend der Verteilung der Zugriffe über eine zentrale Zugangsadresse auf geografisch entfernte Rechenzentren. Die GSLB-Technologie arbeitet nach den gleichen allgemeinen Grundsätzen wie DNS-Lastausgleich. GSLB ist im Grunde genommen nicht anders als ein DNS Load Balancing über die verteilten Standorte, ABER mit einer breiteren Auswahl an intelligenten Zugriffsalgorithmen.
Hauptsächlich wird GSLB für folgende Zwecke verwendet:
- Lastverteilung (Active-Active Mode): die Benutzerzugriffe werden über mehrere Standorte verteilt, um die darunterliegende Infrastruktur gleichmäßig zu belasten.
- Bessere User Experience (Active-Active Mode): Die Anmeldung der Benutzer findet auf einem geografisch naheliegenden Standort statt.
- Ausfallssicherheit/Hochverfügbarkeit(Active-Active Mode): Wenn ein zur Verfügung stehender Knotenpunkt nicht mehr erreichbar ist, wird dieser aus der Verteilung rausgenommen.
- Disaster Recovery Hochverfügbarkeit (Active-Passive Mode): In dieser Situation werden die Benutzer weiterhin mit den primeren Standorten verbunden und nur wenn diese aus irgendeinen Grund nicht mehr erreichbar sind, werden die Benutzer auf die Backup-Systeme umgeleitet.
Citrix NetScaler Global Server Load Balancing - Architecture Components
Download: Citrix_NetScaler_GSLB_Architecture_Components.pdf
Download: Citrix_NetScaler_GSLB_Architecture_Components.vsdx oder hier
GSLB kann in drei unterschiedlichen Modi betrieben werden:
Active-Active - NetScaler in allen Lokationen sind immer aktiv geschaltet. Bei einer Active-Active- Bereitstellung können die Verbindungen an mehrere Standorte verteilt werden.
Active-Passive (wird oft Active-Standby genannt) - Diese Art der Bereitstellung ist für das Desaster-Recovery-Szenario vorgesehen. In diesem Fall gibt es aktive GSLB-Standorte und einen oder mehrere Recovery-Standorte (Remote Sites).
Parent-Child – Die dritte Option ist für die großen Organisationen vorgesehen und stellt eine hierarchische Struktur dar. Standardmäßig findet der Austausch der DNS-Informationen zwischen allen NetScalern statt, dies kann jedoch zu einer erhöhten Netzwerklast führen. Mit der Parent-Child Option findet die DNS-Kommunikation mittel MEP-Protokoll ausschließlich zwischen den Parent-Netscalern statt.
Es wird so realisiert, dass es nur auf wenigen Knoten ein ADNS-Service konfiguriert wird. Die untergeordnete Knoten (Child) tauschen die DNS-Informationen (MEP-Traffic) nur mit den übergeordneten Knoten (Parent) aus. Die Parent-Knoten tauschen die DNS-Informationen untereinander aus.
Ein typisches Anwendungsszenario wäre z.B. ein international tätiges Unternehmen mit zwei Hauptstandorten: USA und Deutschland. Jeder Standort ist wieder in Niederlassungen aufgeteilt z.B. in Deutschland existieren eine Zentrale und zwei Niederlassungen Nord und Süd. Wenn ein Benutzer aus Ingolstadt auf die Unternehmensseite zugreift, wird er mit der Citrix Infrastruktur, die ihm eine optimale Performance bietet, verbunden. In diesem Fall wird der Benutzer-Request nach München geleitet.
Wie es funktioniert eine klassische DNS Anfrage?
Hier finden Sie eine grobe Beschreibung des DNS-Prinzips.
1. Der Benutzer öffnet ein Browser-Fester und gibt die gewünschte URL-Adresse ein (z.B. abteilung.company.com).
Um die gesuchte Seite im Browser-Fenster anzeigen zu können, muss der Client zuerst die IP-Adresse zur URL abteilung.company.com kennen, erst dann kann er eine Anfrage an dieses Ziel senden. Der Client versucht zunächst aus seinem DNS-Cache die IP-Adresse für die Website-URL abzurufen.
2. Wenn die gesuchte Adresse sich nicht in dem lokalen Cache befindet, sendet der Client eine Anfrage an seinen lokalen DNS-Server (LDNS). Hier fordert der Client den LDNS auf, die Adresse abteilung.company.com aufzulösen. Wenn die Adresse bereits bekannt ist (sich im Cache des Servers befindet), bekommt der Client die IP-Adresse der gesuchten Seite als eine Antwort auf die gestellte Anfrage.
3. Wenn der LDNS die IP-Adresse nicht kennt, muss er nacheinander mehrere Server abfragen, bis er die gesuchte Adresse bekommt. In unseren Fall werden höchstwahrscheinlich drei DNS-Server abgefragt:
- DNS-Server des ISP. Wenn dieser DNS-Server die IP-Adresse der gesuchten Seite nicht kennt, wird den lokalen DNS-Server „empfohlen“ sich an den zuständigen TLD Server (Top Level Domain) zu wenden.
- DNS für .COM „verweist“ auf den DNS für company.com.
- DNS für company.com. Der dritte DNS-Server sendet dem Client die gesuchte IP-Adresse.
Wenn der Domain Name abteilung.company.com von mehreren Web-Servern mit unterschiedlichen IP-Adressen bedient wird, werden diese Adresse nach Round-Robin Prinzip verteilt.
Was macht GSLB anders?
Der lokale DNS-Server des Clients sendet die Anfrage an den autorisierenden DNS (NetScaler). Die ADNS-Server für diese Domäne verfügen über die IP-Adressen aller Hosts in ihrer Domäne. Der Citrix ADNS löst die IP-Adresse für abteilung.company.com auf und gibt diese Adresse dem Client zurück, aber nicht nach einem einfachen Round-Robin Prinzip, sondern nach vorher festgelegten Kriterien z.B. wenig belastete oder nächstliegende Datacenter, bessere Antwortzeiten u.s.w.
DNS-Methoden
Es gibt zwei unterschiedliche Bereitstellungsmethoden: DNS-Proxy und ADNS.
DNS-Proxy – der NetScaler emfängt die DNS-Anfrage von den Clients und leitet die DNS-Anfrage an einen lokalen DNS-Server weiter. Im Gegensatz zu ADNS beinhaltet der DNS-Proxy keine eigene Liste von IP-Adressen sondern leitet alle Client-Anfragen an die zuständigen externen DNS-Server weiter. In diesem Fall wird ein zusätzlicher virtuelle DNS-Server erforderlich.
DNS virtual servers are only necessary in a DNS proxy configuration. Otherwise, in an ADNS configuration, each GSLB site will use the locally configured DNS service with mirrored static DNS records for each site in the configuration.
ADNS – der NetScaler agiert als ein DNS-Server in einer Lokation und behält selbst die Listen von Domain-Namen und dazugehörigen IP-Adresse.
ADNS (Authoritative DNS) – ist ein autorisierter und von außen erreichbarer DNS-Server, der sich in jeder Lokation befindet und die Liste von IP-Adressen aus allen Sites beinhaltet. ADNS nimmt die Client-Anfrage entgegen und beantwortet diese.
Lesenswertes zum Thema:
- CTX122619 - How DNS(Domain Name System) works with GSLB feature on NetScaler
- CTX205268 - How do I load balance DNS traffic (DNS proxy) on NetScaler?
- Cisco - What Is the Difference between Authoritative and Recursive DNS Nameservers?
GSLB-Architektur-Komponenten
Innerhalb einer NetScaler- Appliance besteht die Architektur aus mehreren Komponenten:
GSLB Site. Eine Site ist als eine logische Abbildung des lokalen Datacenters bzw. Standorts zu verstehen. Aus Konfigurationssicht, ist die im lokalen Datacenter befindliche NetScaler Appliance immer Local, die NetScaler Appliances auf den anderen Seiten sind immer Remote. Es müssen minimum zwei GSLB Sites existieren.
GSLB vServer – ist die erste Komponente, die bei der Konfiguration des GSLB erstellt wird. Der GSLB vServer übernimmt eine Vermittlungsrolle und leitet die Clientanfragen an den entsprechenden GSLB-Service weiter. Mit dem GSLB vServer verknüpfte Services sind immer desselben Typs. Der GSLB vServer wertet dabei die konfigurierten GSLB-Methoden aus, um den geeigneten Dienst auszuwählen. Oder besser gesagt, der GSLB vServer entscheidet anhand der konfigurierten Methoden, wie der Client-Request weitergleitet wird.
Der GSLB vServer verfügt über keine eigene IP-Adresse.
GSLB Service – ist an den GSLB vServer gebunden und stellt einen angeschlossenen vServer dar, wie z.B. Load-Balancing, Content-Switching oder Gateway. Der GSLB-Dienst bestimmt, wie der eingehende Traffic weitergeleitet wird.
GSLB Service – ist immer LOCAL zu der eigenen Site und REMOTE zu der externen Site konfiguriert:
LB/CS/NG vServer – in diesem Fall handelt es sich um einen virtuellen Server, der für eine bestimmte Funktion vorgesehen ist. z.B. ein Load Balancer, Content Switch oder NetScaler Gateway.
ADNS Service – wurde bereits erläutert.
Load Balancing Algorithmen: Static Proximity - Dynamic Proximity
Es ist möglich zwei unterschiedlichen Lastausgleich-Methoden zu verwenden: Dynamic und Static. Beide Methoden verfolgen das gleiche Ziel, einen naheliegenden und wenig ausgelasteten Server zu lokalisieren.
Der wesentliche Unterschied der dynamischen Methode von der statischen liegt darin, dass die Lastausgleich-Entscheidung auf Basis der Informationen getroffen wird, die aus anderen Sites kommen.
Dynamic Proximity
Die dynamische Lastverteilung kann fünf unterschiedliche Mechanismen (Algorithmen) verwenden:
Least Connection – es wird gemessen, wie viele aktive Verbindungen ein LB/CS/NG vServer hat. Der Service mit weniger aktiven Verbindungen wird genutzt.
Least Bandwidth – die Client-Anfrage wird an die Seite, die am wenigsten netzwerktechnisch ausgelastet ist (in Mbps gemessen), gesendet.
Least Packets – in diesem Fall wird die Gesamtzahl, sowie die aktuelle Anzahl der übertragenen Pakete gemessen. Die Services mit der minimalen Zahl von Paketen werden bevorzugt.
Least Response Time – es wird ein Service mit der niedrigsten durchschnittlichen Antwortzeit ausgewählt.
Round Trip Time – diese Methode berechnet die RTT zwischen nur den LDNS des Benutzers und den GSLB Seiten, um festzustellen welche Seite näher ist. Hierbei ist es wichtig zu erwähnen, dass die besseren RTT-Zeiten nicht gezwungenermaßen zwischen naheliegenden Standort und GSLB-Site gemessen werden. Lediglich nur die Kommunikation zwischen den lokalen DNS und der GSLB-Site zu einem bestimmten Zeitpunkt schneller war.
Zur Berechnung der RTT wird eine von drei Methoden verwendet:
- PING – ein ICMP Request bedarf eigentlich keiner Erklärung.
- DNS – wenn ein ICMP Request mit Timeout endet, wird ein DNS Request gesendet.
- TCP – wird nur verwendet, wenn die beiden anderen Methoden erfolglos sind.
Falls MEP aus irgendeinem Grund nicht mehr funktioniert wird keine der oberen Methoden verwendet. GSLB wird in dieser Situation auf Round Robin zurückgreifen.
Static Proximity
Im Gegensatz zu den dynamischen Algorithmen, existieren nur zwei mögliche statische Optionen: Round Robin und Source IP Hash
Die statische Berechnung der Proximity ist dem RTT Algorithmus ähnlich. Es wird die Strecke zwischen dem lokalen DNS-Server des Clients und dem GSLB Standort gemessen.
Round Robin – die Server werden nacheinander angefragt, aber die Client-Anfragen werden anhand einer vordefinierten Gewichtung (Weight) zugewiesen.
Source IP Hash – aus der IP-Adresse des lokalen DNS-Servers wird ein Hashwert berechnet. Dieser Wert wird einem bestimmten Server zuzuordnen, um diesen bei einer Wiederverbindung richtig einordnen zu können. Das heißt, wenn die Anfragen immer von ein und demselben DNS-Server kommen (z.B. in einem Intranet), wird auch immer die gleiche IP-Adresse zugewiesen.
Proximity Typen
Es existieren auch vier weiteren Konfigurations-Typen, die es ermöglichen die Proximity festzulegen:
Static Proximity – bei diesem Typ werden die IP-Adressen der Lokationen in einer Static Location Database gespeichert. (Können auch per Policy festgelegt werden). Wenn z.B. eine DNS-Anfrage von einem lokalen DNS-Server die GSLB-Seite erreicht, wird deren IP-Adresse mit den Adressen aus der Datenbank verglichen, um diese an die naheliegende Seite weiterzuleiten.
Static Proximity Database kann entweder manuell erstellt werden oder als eine fertige Datei hinzugefügt sein. Wie z.B. GeoLocation-DB von GeoLite
Hier wird es konfiguriert: Traffic Management / GSLB / Location / Static Database / Static Database (IPv4) / Add
Die Datenbank wird in den Ordner /var/netscaler/locdb gespeichert.
Custom Entries – in diesem Fall werden alle Informationen manuell wie folgt eingegeben.
Traffic Management / GSLB / Location / Custom Entries / Add -
From IP Address | To IP Address | Location Name |
Alle manuell konfigurierten Lokationen haben Vorrang vor den Lokationen aus der Static Location DB.
DNS Policies – diese Option ist der Oberen sehr ähnlich. Die Anfrage von einem LDNS wird auf eine festgelegte Seite weitergeleitet.
DNS Views – kann in Verbindung mit DNS Policies verwendet werden, um eine andere IP-Adresse anhängig davon ob die Users ntern oder extern ist, bereitzustellen. Es kann eine Liste von präferierten Lokationen hinzugefügt werden, die absteigend abgearbeitet wird.
- CTX127590 - How to Configure a DNS View for Global Server Load Balancing on a NetScaler Appliance
- CTX130163 - How to Configure GSLB Setup for Internal Users From GUI
Metrik Exchange Protocol (MEP)
Metrik Exchange Protocol – es handelt sich dabei um ein Citrix-eigenes Protokoll, welches für die Kommunikation zwischen den GSLB-Standorten dient und die Informationen zu Netzwerk, Auslastung und Persistenz austauscht. Die weitere Site-to-Site Kommunikation findet per RPC statt.
MEP ist standardmäßig aktiviert. Direkt nach der Erstellung der GSLB Site findet der Datenaustausch statt. MEP lässt sich auch deaktivieren. Wenn MEP deaktiviert wird, werden nur folgenden statische Methode anwendbar: Round Robin, Static Proximity und Hash-based.
Die GSLB Site to Site Communication findet via RPC- Protokoll statt. Die RPC-Kommunikation wird über die NSIP (NetScaler IP) gestartet und weiter über die GSLB Public IP geroutet.
Die Ports 3009 und 3011 werden für die Kommunikation (MEP und RPC) zwischen den Standorten verwendet, wobei der Port 3009 für die sichere Datenübertragung vorgesehen ist.
Weitere lesenswerte Information:
- Citrix Tech Zone: Citrix Application Delivery Controller (ADC) Global Server Load Balancing (GSLB)
- CTX130154 - NetScaler Global Server Load Balancing - Dynamic Proximity Method
- CTX205266 - How do I setup cookie based persistence on NetScaler?
- CTX131801 - NetScaler GSLB Counters
- CTX127590 - How to Configure a DNS View for Global Server Load Balancing on a NetScaler Appliance
- CTX111081 - Understanding Metric Exchange Protocol and Monitors for Global Server Load Balancing