Planung für Dispatcher

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:

Anmerkung:
Frühere Versionen dieses Produkts liefen unter dem Namen Network Dispatcher. In diesen Versionen lautete der Dispatcher-Steuerbefehl ndcontrol. Jetzt lautet der Dispatcher-Steuerbefehl dscontrol.

Überlegungen bei der Planung

Der Dispatcher stellt die folgenden Funktionen bereit:

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.

Weiterleitungsmethoden

Der Dispatcher stellt drei Weiterleitungsmethoden auf Portebene bereit: MAC-Weiterleitung, NAT/NAPT-Weiterleitung und CBR (inhaltsabhängige Weiterleitung).

Dispatcher-Weiterleitungsmethode mac

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.

Dispatcher-Weiterleitungsmethode nat

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):

Content-Based Routing von Dispatcher (cbr)

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.

Anmerkung:
Die Inhaltsregel wird für die Komponente Dispatcher auf die gleiche Weise wie für die Komponente CBR konfiguriert. Der Dispatcher kann die Inhaltsregel für HTTP-Datenverkehr verwenden. Die Komponente CBR kann die Inhaltsregel für HTTP- und HTTPS-Datenverkehr (SSL) verwenden.

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):

Anmerkung:
Die für eine hohe Verfügbarkeit ausgeführte Vervielfältigung von Verbindungseinträgen stellt sicher, dass die Verbindung eines Clients nicht unterbrochen wird, wenn eine Ausweich-Dispatcher-Maschine die Aufgaben der primären Maschine übernimmt. Diese Vervielfältigung wird bei der inhaltsabhängigen Weiterleitung durch den Dispatcher nicht unterstützt.

Beispielschritte für die Konfiguration der Dispatcher-Weiterleitungsmethoden nat und cbr

Abbildung 12. Beispiel für die Dispatcher-Weiterleitungsmethoden nat und cbr
Konfiguration für die Verwendung der Dispatcher-Weiterleitungsmethoden nat und cbr

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.

Serverpartitionierung - Logische Server für einen physischen Server (IP-Adresse) konfigurieren

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.

Serverpartitionierung mit dem HTTP- oder HTTPS-Advisor

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.

Beispiel für die Konfiguration von logischen Servern auf einem physischen Server

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).

Hohe Verfügbarkeit

Einfache hohe Verfügbarkeit

Abbildung 13. Beispiel für einen Dispatcher mit einfacher hoher Verfügbarkeit
Dispatcher mit einfacher hoher Verfügbarkeit

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.

Gegenseitige hohe Verfügbarkeit

Abbildung 14. Beispiel für einen Dispatcher mit gegenseitiger hoher Verfügbarkeit
Dispatcher mit gegenseitiger hoher 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.

Anmerkung:
Auf beiden Maschinen müssen die gemeinsam genutzten Clustergruppen identisch konfiguriert werden. Das heißt, die in beiden Konfigurationen verwendeten Ports und die unter den Ports konfigurierten Server müssen identisch sein.

Informationen zum Konfigurieren der hohen Verfügbarkeit und der gegenseitigen hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit.