In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Komponente Dispatcher berücksichtigen muss.
Dieses Kapitel enthält die folgenden Abschnitte:
Der Dispatcher stellt die folgenden Funktionen bereit:
Dispatcher bietet außerdem Advisor an, die keine protokollspezifischen Informationen austauschen. Dazu gehören der DB2-Advisor, der Angaben zum Status von DB2-Servern meldet, und der Advisor "ping", der meldet, ob der Server auf ein Pingsignal antwortet. Eine vollständige Liste der Advisor finden Sie im Abschnitt Liste der Advisor.
Sie können auch eigene Advisor schreiben. (Lesen Sie hierzu die Informationen im Abschnitt Angepassten (anpassbaren) Advisor erstellen.)
Die Benutzung der Advisor ist optional, wird jedoch empfohlen.
Die drei Schlüsselfunktionen des Dispatchers (Executor, Manager und Advisor) kommunizieren miteinander, um die eingehenden Anforderungen auf die Server zu verteilen. Neben Lastausgleichsanforderungen überwacht der Executor die Anzahl neuer, aktiver und beendeter Verbindungen. Der Executor übernimmt auch die Garbage Collection für beendete oder zurückgesetzte Verbindungen und stellt diese Informationen dem Manager zur Verfügung.
Der Manager stellt Informationen vom Executor, von den Advisor und von einem Systemüberwachungsprogramm wie Metric Server zusammen. Der Manager passt anhand der erhaltenen Informationen die Wertigkeit der Servermaschinen an den einzelnen Ports an und teilt dem Executor die neue Wertigkeit mit, die dieser dann beim Lastausgleich für neue Verbindungen verwendet.
Die Advisor überwachen die einzelnen Server am zugeordneten Port, um Antwortzeit und Verfügbarkeit der Server zu ermitteln, und übergeben diese Informationen an den Manager. Die Advisor überwachen zudem, ob ein Server aktiv oder inaktiv ist. Ohne Manager und Advisor wendet der Executor eine RoundRobin-Zeitplanung auf der Basis der aktuellen Serverwertigkeiten an.
Der Dispatcher stellt drei Weiterleitungsmethoden auf Portebene bereit: MAC-Weiterleitung, NAT/NAPT-Weiterleitung und CBR (inhaltsabhängige Weiterleitung).
Wenn der Dispatcher seine Standardweiterleitungsmethode, die MAC-Weiterleitung, anwendet, werden die eingehenden Anforderungen an den ausgewählten Server weitergeleitet. Der Server gibt die Antwort direkt, d. h. ohne Eingreifen des Dispatchers, an den Client zurück. Bei dieser Methode der Weiterleitung achtet der Dispatcher nur auf den beim Server eingehenden Datenfluss vom Client. Den vom Server zum Client abgehenden Datenverkehr muss er nicht sehen. Dadurch werden die Auswirkungen auf die Anwendung erheblich reduziert und der Durchsatz im Netz wird verbessert.
Sie können die Weiterleitungsmethode auswählen, wenn Sie mit dem Befehl dscontrol port add Cluster:Port method Wert einen Port hinzufügen. Der Wert für die Standardweiterleitungsmethode ist mac. Die Parameter für die Methode können Sie nur beim Hinzufügen des Ports angeben. Ist der Port hinzugefügt, können Sie die Einstellung für die Weiterleitungsmethode nicht mehr ändern. Weitere Informationen hierzu finden Sie im Abschnitt dscontrol port — Ports konfigurieren.
Einschränkung für Linux: Linux-Systeme nutzen ein hostgestütztes Modell, um Hardwareadressen über ARP für IP-Adressen zugänglich zu machen. Dieses Modell ist nicht mit den Anforderungen der Load-Balancer-Weiterleitungsmethode mac an einen Back-End-Server oder einen verknüpften Server mit hoher Verfügbarkeit kompatibel. Der Abschnitt Alternativen für die Festlegung eines Loopback-Aliasnamens unter Linux bei Verwendung der Load-Balancer-Weiterleitungsmethode mac beschreibt eine Reihe von Lösungen dazu, wie Sie das Verhalten des Linux-Systems so ändern können, dass es mit der Load-Balancer-Weiterleitungsmethode mac kompatibel ist.
Einschränkung für Linux auf zSeries- oder S/390-Servern: Wenn Sie zSeries- oder S/390-Server mit OSA-Karten (Open System Adapter) verwenden, gibt es Einschränkungen. Informationen zu möglichen Strategien, mit denen Sie diese Einschränkungen umgehen können, finden Sie im Abschnitt Problem: Einschränkungen für die Dispatcher-Konfiguration unter Linux auf zSeries- oder S/390-Servern mit OSA-Karten.
Bei Verwendung der Dispatcher-Methode NAT (Network Address Translation, Netzadressumsetzung) bzw. NAPT (Network Address Port Translation, Portumsetzung für Netzadressen) entfällt die Einschränkung, dass sich die am Lastausgleich beteiligten Server in einem lokal angeschlossenen Netz befinden müssen. Falls Sie Server an fernen Standorten haben, sollten Sie an Stelle einer GRE/WAN-Kapselungstechnik die Weiterleitungsmethode NAT anwenden. Mit NAPT können Sie außerdem auf mehrere Serverdämonen zugreifen, die sich auf den einzelnen am Lastausgleich beteiligten Servermaschinen befinden und jeweils an einem spezifischen Port empfangsbereit sind.
Einen Server mit mehreren Dämonen können Sie auf die beiden folgenden Arten konfigurieren:
Diese Anwendung funktioniert gut mit höheren Anwendungsprotokollen wie HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet usw.
Einschränkungen:
Für die Dispatcher-Maschine benötigen Sie drei IP-Adressen: NFA, Clusteradresse und Rückkehradresse. Sie können NAT/NAPT wie folgt implementieren (vergleichen Sie hierzu auch den Abschnitt Beispielschritte für die Konfiguration der Dispatcher-Weiterleitungsmethoden nat und cbr):
dscontrol server add Cluster:Port:Server mapport Wert returnaddress Rückkehradresse router Router-Adresse
Dieser Parameter ordnet die (für den Dispatcher bestimmte) Nummer des Zielports für die Clientanforderung der Nummer des Serverports zu, an dem der Dispatcher die Clientanforderungen verteilt. Mit mapport kann Load Balancer die Anforderung eines Clients an einem Port empfangen und an einen anderen Port der Servermaschine übertragen. Mit mapport können Sie den Lastausgleich für die Anforderungen eines Clients auf einer Servermaschine mit mehreren Serverdämonen durchführen. Der Standardwert für mapport ist die Nummer des Zielports für die Clientanforderung.
Die Rückkehradresse ist eine eindeutige Adresse oder ein Hostname, die bzw. den Sie auf der Dispatcher-Maschine konfigurieren. Der Dispatcher verwendet die Rückkehradresse beim Lastausgleich für die Clientanforderung auf dem Server als Quellenadresse. Auf diese Weise wird sichergestellt, dass der Server das Paket an die Dispatcher-Maschine zurückgibt und es nicht direkt an den Client sendet. (Der Dispatcher leitet das IP-Paket dann an den Client weiter.) Sie müssen den Wert für die Rückkehradresse beim Hinzufügen des Servers angeben. Die Rückkehradresse kann nur geändert werden, wenn Sie den Server entfernen und dann erneut hinzufügen. Die Rückkehradresse darf nicht mit dem Wert für Cluster, Server oder NFA übereinstimmen.
Wenn Sie die Weiterleitungsmethode "nat" oder "cbr" verwenden, müssen Sie eine Rückkehradresse für die Kommunikation zwischen Load Balancer und den Back-End-Servern definieren. Die Anzahl aktiver Verbindungen zwischen Load Balancer und dem Back-End-Server wird durch die Anzahl der Rückkehradressen beschränkt, die definiert sind. Load Balancer verwendet nur Ports, die auf der Rückkehradresse basieren, und keine Ports, die auf der Kombination von Rückkehradresse und Server basieren. Wenn alle verfügbaren Ports im Gebrauch sind, schlagen weitere Verbindungen fehl. Verwenden Sie in einer ausgelasteten Umgebung mehrere Rückkehradressen, um einen Engpass bei den verfügbaren Ports zu vermeiden.
Die Adresse des Routers zum fernen Server. Falls dies ein lokal angeschlossener Server ist, der sich nicht auf derselben Maschine wie Load Balancer befindet, geben Sie die Serveradresse ein. Befindet sich der Server auf derselben Maschine wie Load Balancer, verwenden Sie weiter die reale Router-Adresse.
Mit der Komponente Dispatcher können Sie das Content-Based Routing für HTTP (unter Verwendung des Regeltyps "content" (Inhalt)) und für HTTPS (unter Verwendung der Affinität von SSL-Sitzungs-IDs) ohne Caching Proxy ausführen. Für HTTP- und HTTPS-Datenverkehr ist das Content-Based Routing der Dispatcher-Weiterleitungsmethode cbr schneller als das der Komponente CBR, die Caching Proxy erfordert.
Für HTTP: Die Serverauswahl für die inhaltsabhängige Weiterleitung basiert auf dem Inhalt eines URL oder eines HTTP-Headers. Sie wird mit dem Regeltyp "content" (Inhalt) konfiguriert. Wenn Sie die Inhaltsregel konfigurieren, geben Sie für die Regel den Suchbegriff (das Muster) und eine Gruppe von Servern an. Beim Verarbeiten einer neu eingehenden Anforderung vergleicht diese Regel die angegebene Zeichenfolge mit dem URL des Clients oder mit dem in der Clientanforderung angegebenen HTTP-Header.
Findet der Dispatcher die Zeichenfolge in der Clientanforderung, leitet er diese an einen für die Regel definierten Server weiter. Anschließend gibt der Dispatcher die Antwortdaten vom Server an den Client zurück (Weiterleitungsmethode cbr).
Findet der Dispatcher die Zeichenfolge nicht in der Clientanforderung, wählt er keinen der für die Regel definierten Server aus.
Für HTTPS (SSL): Bei der inhaltsabhängigen Weiterleitung von Dispatcher erfolgt der Lastausgleich ausgehend vom Feld für die SSL-Sitzungs-ID in der Clientanforderung. Bei Verwendung von SSL enthält eine Clientanforderung die SSL-Sitzungs-ID einer früheren Sitzung und Server speichern ihre früheren SSL-Verbindungen im Cache. Durch die Dispatcher-Funktion für Affinität der SSL-Sitzungs-ID können Client und Server eine neue Verbindung aufbauen und dafür die Sicherheitsparameter der vorherigen Verbindung zum Server verwenden. Da SSL-Sicherheitsparameter wie gemeinsam verwendete Schlüssel und Verschlüsselungsalgorithmen nicht neu ausgehandelt werden müssen, benötigen die Server weniger CPU-Zyklen und der Client erhält schneller eine Antwort. Zum Aktivieren der Affinität von SSL-Sitzungs-IDs muss für den Port als protocol (Protokolltyp) SSL und als Port stickytime ein Wert ungleich null angegeben werden. Wenn die Haltezeit (stickytime) abgelaufen ist, wird der Client unter Umständen an einen anderen als den vorherigen Server verwiesen.
Für die Dispatcher-Maschine benötigen Sie drei IP-Adressen: NFA, Clusteradresse und Rückkehradresse. Gehen Sie zum Implementieren von Content-Based Routing von Dispatcher wie folgt vor (siehe auch Beispielschritte für die Konfiguration der Dispatcher-Weiterleitungsmethoden nat und cbr):
dscontrol server add Cluster:Port:Server mapport Wert returnaddress Rückkehradresse router Router-Adresse
dscontrol rule 125.22.22.03:80:Inhaltsregel1 type content pattern Muster
Muster gibt hier das für den Regeltyp "content" (Inhalt) zu verwendende Muster an. Weitere Informationen zum Regeltyp "content" (Inhalt) finden Sie im Abschnitt Auf dem Inhalt der Anforderung basierende Regeln verwenden. Weitere Informationen zu gültigen Ausdrücken für Muster können Sie Anhang B. Syntax für Inhaltsregeln (Muster) entnehmen.
Sie benötigen mindestens drei IP-Adressen für die Dispatcher-Maschine. Für das Beispiel in Abb. 12 sind die folgenden Schritte notwendig, um eine Minimalkonfiguration der Dispatcher-Weiterleitungsmethoden nat und cbr zu erzielen:
1. Starten Sie den Executor.
dscontrol executor start
2. Definieren Sie das Client-Gateway.
dscontrol executor set clientgateway 1.2.3.5
ANMERKUNG: Wenn es in Ihrem Teilnetz keinen lokalen Router gibt, müssen
Sie eine Maschine für die IP-Weiterleitung konfigurieren und
diese als Client-Gateway verwenden. Anweisungen für das Aktivieren
der IP-Weiterleitung finden Sie in der Dokumentation zum Betriebssystem.
3. Definieren Sie die Clusteradresse.
dscontrol cluster add 1.2.3.44
4. Konfigurieren Sie die Clusteradresse.
dscontrol executor configure 1.2.3.44
5. Definieren Sie den Port mit der Methode nat oder cbr.
dscontrol port add 1.2.3.44:80 method nat
oder
dscontrol port add 1.2.3.44:80 method cbr protocol http
6. Konfigurieren Sie eine Aliasrückkehradresse für Load Balancer (mit Ethernet-Karte 0).
Anmerkung: Auf Linux-Systemen benötigen Sie keine Aliasrückkehradresse,
wenn Sie auf einer verknüpften Maschine die Weiterleitungsmethode nat verwenden.
dscontrol executor configure 10.10.10.99
Sie können auch den Befehl ifconfig verwenden (nur für Linux oder UNIX):
AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0
HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up
Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up
Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up
7. Definieren Sie die Back-End-Server.
dscontrol server add 1.2.3.4:80:192.10.10.10
router 10.10.10.6 returnaddress 10.10.10.99
Das Client-Gateway (1.2.3.5) ist die Adresse für Router 1 zwischen Load Balancer und dem Client. Der Router (10.10.10.6) ist die Adresse für Router 2 zwischen Load Balancer und dem Back-End-Server. Falls Sie die Adresse für das Client-Gateway und für Router 2 nicht kennen, können Sie ein Routenverfolgungsprogramm (traceroute) mit der Clientadresse (oder Serveradresse) verwenden, um die Router-Adresse zu bestimmen. Die genaue Syntax des Programms richtet sich nach dem von Ihnen verwendeten Betriebssystem. Weitere Informationen zu diesem Programm können Sie der Dokumentation zum Betriebssystem entnehmen.
Wenn sich der Server in demselben Teilnetz wie Load Balancer befindet (so dass traceroute keine Router zurückgibt), geben Sie die Serveradresse als Router-Adresse ein. Befindet sich der Server jedoch auf derselben Maschine wie Load Balancer, sollten Sie im Feld für die Router-ID an Stelle der Serveradresse die Router-Adresse eingeben. Die Router-Adresse ist die in Schritt 7 auf der Load-Balancer-Maschine für den Befehl "server add" verwendete Adresse.
Bei Anwendung der Serverpartitionierung können Sie zwischen URLs und ihren spezifischen Anwendungen unterscheiden. Ein Webserver kann beispielsweise JSPs, HTML-Seiten und GIF-Dateien bereitstellen, Datenbankabfragen bedienen usw. Load Balancer bietet jetzt die Möglichkeit, einen cluster- und portspezifischen Server in mehrere logische Server zu partitionieren. Dadurch können Sie einen bestimmten Dienst auf der Maschine dazu anweisen festzustellen, ob eine Servlet-Engine oder eine Datenbankabfrage schneller oder gar nicht ausgeführt wird.
Mit der Serverpartitionierung kann Load Balancer z. B. erkennen, dass der HTML-Dienst Seiten schnell bereitstellt, die Datenbankverbindung jedoch nicht mehr aktiv ist. Dadurch können Sie die Last differenzierter und dienstspezifisch verteilen und müssen sich nicht auf die Wertigkeit des Gesamtservers verlassen.
Die Serverpartitionierung kann in Verbindung mit dem HTTP-Advisor und dem HTTPS-Advisor hilfreich sein. Wenn Sie beispielsweise einen HTML-Server für HTML- und GIF-Seiten sowie JSPs haben und den Server einmal unter Port 80 definieren (hinzufügen), erhalten Sie für den gesamten HTTP-Server nur einen Lastwert. Dies kann irreführend sein, weil es möglich ist, dass der GIF-Service auf dem Server nicht funktioniert. Der Dispatcher leitet GIF-Seiten unverändert an den Server weiter. Der Client sieht jedoch eine Zeitlimitüberschreitung oder einen Ausfall.
Wenn Sie den Server dreimal unter dem Port definieren (ServerHTML, ServerGIF, ServerJSP) und den Serverparameter advisorrequest für jeden logischen Server mit einer anderen Zeichenfolge definieren, können Sie den Zustand des jeweiligen Service auf dem Server abfragen. ServerHTML, ServerGIF und ServerJSP repräsentieren die drei logischen Server, die durch die Partitionierung eines physischen Servers entstanden sind. Für ServerJSP können Sie eine Zeichenfolge für advisorrequest definieren, um auf der Maschine zur Bearbeitung von JSPs den Service abzufragen. Für ServerGIF können Sie die Zeichenfolge advisorrequest so definieren, dass der GIF-Service abgefragt wird. Und für ServerHTML können Sie advisorrequest so definieren, das der HTML-Service abgefragt wird. Empfängt der Client keine Antwort von advisorrequest zur Abfrage des GIF-Services, registriert der Dispatcher, dass der logische Server (ServerGIF) inaktiv ist, die beiden anderen logischen Server jedoch weiterhin in gutem Zustand sein können. Der Dispatcher leitet keine weiteren GIFs an den physischen Server weiter, sendet jedoch unverändert JSP- und HTML-Anfragen an den Server.
Weitere Informationen zum Parameter advisorrequest finden Sie im Abschnitt Option "Anforderung/Antwort (URL)" des HTTP- oder HTTPS-Advisors konfigurieren.
Innerhalb der Dispatcher-Konfiguration können Sie einen physischen oder logischen Server mit der Hierarchie Cluster:Port:Server darstellen. Der Server kann eine eindeutige IP-Adresse der Maschine (physischer Server) sein, die als symbolischer Name oder im IP-Adressenformat angegeben wird. Wenn Sie den Server als partitionierten Server definieren, müssen Sie den Befehl dscontrol server add mit einer auflösbaren Serveradresse des physischen Servers für den Parameter address angeben. Weitere Informationen hierzu finden Sie im Abschnitt dscontrol server — Server konfigurieren.
Nachfolgend sehen Sie ein Beispiel für die Partitionierung physischer Server in logische Server zur Bearbeitung von Anforderungen verschiedenen Typs.
Cluster: 1.1.1.1
Port: 80
Server: A (IP-Adresse 1.1.1.2)
HTML-Server
Server: B (IP-Adresse 1.1.1.2)
GIF-Server
Server: C (IP-Adresse 1.1.1.3)
HTML-Server
Server: D (IP-Adresse 1.1.1.3)
JSP-Server
Server: E (IP-Adresse 1.1.1.4)
GIF-Server
Server: F (IP-Adresse 1.1.1.4)
JSP-Server
Rule1: /*.htm
Server: A
Server: C
Rule2: /*.jsp
Server: D
Server: F
Rule3: /*.gif
Server: B
Server: E
In diesem Beispiel wird der Server 1.1.1.2 in zwei logische Server partitioniert: "A" (zur Bearbeitung von HTML-Anforderungen) und "B" (zur Bearbeitung von GIF-Anforderungen). Server 1.1.1.3 wird in zwei logische Server partitioniert: "C" (zur Bearbeitung von HTML-Anforderungen) und "D" (zur Bearbeitung von JSP-Anforderungen). Server 1.1.1.4 wird in zwei logische Server partitioniert: "E" (zur Bearbeitung von GIF-Anforderungen) und "F" (zur Bearbeitung von JSP-Anforderungen).
Die Funktion für hohe Verfügbarkeit erfordert eine zweite Dispatcher-Maschine. Die erste Dispatcher-Maschine führt den Lastausgleich für den gesamten Clientdatenverkehr aus, wie dies in einer Konfiguration mit einem einzelnen Dispatcher geschehen würde. Die zweite Dispatcher-Maschine überwacht den “Zustand" der ersten Maschine und übernimmt die Aufgabe des Lastausgleichs, wenn sie erkennt, dass die erste Dispatcher-Maschine ausgefallen ist.
Jeder der beiden Maschinen wird eine bestimmte Rolle zugewiesen, entweder die der primären Maschine (primary) oder die der Ausweichmaschine (backup). Die primäre Maschine sendet ständig Verbindungsdaten an die Ausweichmaschine. Während die primäre Maschine aktiv ist (den Lastausgleich durchführt), befindet sich die Ausweichmaschine in Bereitschaft. Sie wird ständig aktualisiert und ist bereit, den Lastausgleich zu übernehmen, falls dies erforderlich ist.
In den Übertragungssitzungen zwischen den beiden Maschinen werden Überwachungssignale ausgetauscht. Mit Hilfe der Überwachungssignale kann jede Maschine den Zustand der anderen Maschine überwachen.
Stellt die Ausweichmaschine fest, dass die aktive Maschine ausgefallen ist, übernimmt sie deren Aufgaben und beginnt mit dem Lastausgleich. An diesem Punkt kehrt sich der Status der beiden Maschinen um: die Ausweichmaschine wird zur aktiven Maschine und die primäre Maschine wird zur Maschine in Bereitschaft.
In der Konfiguration mit hoher Verfügbarkeit müssen sich die primäre Maschine und die Ausweichmaschine innerhalb eines Teilnetzes befinden und identisch konfiguriert sein.
Informationen zum Konfigurieren der hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit.
Für die gegenseitige hohe Verfügbarkeit sind zwei Dispatcher-Maschinen erforderlich. Beide Maschinen führen aktiv den Lastausgleich des Clientdatenverkehrs aus und sind gleichzeitig Ausweichmaschinen. In einer Konfiguration mit einfacher hoher Verfügbarkeit führt nur eine Maschine den Lastausgleich durch. In einer Konfiguration mit gegenseitiger hoher Verfügbarkeit verteilen beide Maschinen einen Teil des Clientdatenverkehrs.
Bei der gegenseitigen hohen Verfügbarkeit wird der Clientdatenverkehr den Dispatcher-Maschinen auf der Basis einer Clusteradresse zugeordnet. Jeder Cluster kann mit der NFA (Nonforwarding Address, nicht für Weiterleitungszwecke bestimmte Adresse) seines primären Dispatchers konfiguriert werden. Die primäre Dispatcher-Maschine führt normalerweise den Lastausgleich für diesen Cluster durch. Fällt die Maschine aus, führt die andere Maschine den Lastausgleich für ihren eigenen Cluster und für den Cluster des ausgefallenen Dispatchers durch.
Abb. 14 zeigt eine Beispielkonfiguration mit gegenseitiger hoher Verfügbarkeit, bei der die “Clustergruppe A" und die “Clustergruppe B" gemeinsam genutzt werden. Jeder Dispatcher kann aktiv für seinen primären Cluster bestimmte Pakete weiterleiten. Fällt einer der Dispatcher aus, so dass er nicht länger aktiv für seinen primären Cluster bestimmte Pakete weiterleiten kann, übernimmt der andere Dispatcher die Weiterleitung der Pakete zu seinem Ausweichcluster.
Informationen zum Konfigurieren der hohen Verfügbarkeit und der gegenseitigen hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit.