Manager, Advisor und Metric Server für Dispatcher, CBR und Site Selector

In diesem Kapitel wird erklärt, wie die Lastausgleichsparameter, die Manager, die Advisor und die Funktion Metric Server von Load Balancer konfiguriert werden.

Anmerkung:
Falls Sie die Komponente Dispatcher nicht verwenden, ersetzen Sie beim Lesen dieses Kapitels dscontrol durch Folgendes:
Tabelle 10. Erweiterte Konfigurationstasks für Load Balancer
Task Beschreibung Referenzinformationen
Ändern der Einstellungen für den Lastausgleich (optional)

Sie können die folgenden Einstellungen für den Lastausgleich ändern:

  • Die proportionale Gewichtung der Statusinformationen.

    Das Standardverhältnis ist 50-50-0-0. Wenn Sie den Standardwert verwenden, werden die Informationen von den Advisor, von Metric Server und von WLM nicht benutzt.

  • Wertigkeiten
  • Feste Wertigkeiten vom Manager
  • Managerintervalle
  • Sensitivitätsschwelle
  • Glättungsfaktor
Lastausgleich mit Load Balancer optimieren
Verwendung von Scripts, um einen Alert zu generieren oder Serverausfälle zu protokollieren, wenn der Manager Server als inaktiv oder aktiv markiert Load Balancer stellt Benutzerexits bereit, die Scripts aktivieren, wenn der Manager Server als inaktiv oder aktiv markiert. Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden
Advisor verwenden Beschreibt die Advisor, die Berichte zu spezifischen Status Ihrer Server ausgeben. Advisor
Option "Anforderung/Antwort (URL)" des HTTP- oder HTTPS-Advisors verwenden Definieren Sie eine eindeutige HTTP-URL-Zeichenfolge für einen spezifischen Dienst, der auf der Maschine abgefragt werden soll. Option "Anforderung/Antwort (URL)" des HTTP- oder HTTPS-Advisors konfigurieren
Advisor self verwenden Stellt den Auslastungsstatus von Back-End-Servern für Load Balancer in einer Client/Server-WAN-Konfiguration bereit. Advisor "self" in einer Client/Server-WAN-Konfiguration verwenden
Angepasste Advisor erstellen Erklärt das Schreiben eigener angepasster Advisor. Angepassten (anpassbaren) Advisor erstellen
Verwendung des Agenten Metric Server Metric Server stellt Informationen zur Systemlast für Load Balancer bereit. Metric Server
Verwendung des WLM-Advisors (Workload Manager) Der WLM-Advisor stellt Informationen zur Systemlast für Load Balancer bereit. Advisor Workload Manager

Lastausgleich mit Load Balancer optimieren

Die Managerfunktion von Load Balancer führt den Lastausgleich ausgehend von den folgenden Einstellungen durch:

Zur Optimierung des Lastausgleichs für Ihr Netz können Sie diese Einstellungen ändern.

Proportionale Gewichtung von Statusinformationen

Der Manager kann in seine Gewichtungsentscheidung alle oder einige der nachfolgend genannten externen Faktoren einfließen lassen:

Der Manager erhält die beiden ersten Werte (aktive und neue Verbindungen) neben der aktuellen Wertigkeit jedes Servers und anderen für die Berechnungen erforderlichen Informationen vom Executor. Diese Werte basieren auf Informationen, die intern vom Executor generiert und gespeichert werden.

Anmerkung:
Für Site Selector erhält der Manager die beiden ersten Werte (CPU und Speicher) von Metric Server.

Sie können die relative Gewichtung der vier Werte pro Cluster (oder Sitename) ändern. Die Proportionen sind vergleichbar mit Prozentsätzen. Die Summe der relativen Proportionen muss 100 % ergeben. Das Standardverhältnis ist 50/50/0/0, wobei die Advisor- und Systeminformationen ignoriert werden. In Ihrer Umgebung sollten Sie andere Proportionen ausprobieren, um die Kombination mit der besten Leistung zu finden.

Anmerkung:
Wenn Sie einen Advisor (mit Ausnahme von WLM) hinzufügen und die Portproportion null ist, erhöht der Manager diesen Wert auf 1. Da die Summe der relativen Proportionen immer 100 ist, muss der höchste Wert um 1 verringert werden.

Wenn Sie den WLM-Advisor hinzufügen und die Proportion der Systemmetrik null ist, erhöht der Manager diesen Wert auf 1. Da die Summe der relativen Proportionen immer 100 ist, muss der höchste Wert um 1 verringert werden.

Die Anzahl aktiver Verbindungen hängt sowohl von der Anzahl der Clients als auch von der Zeit ab, die für die Nutzung der von den am Lastausgleich beteiligten Servermaschinen bereitgestellten Dienste erforderlich ist. Sind die Clientverbindungen schnell (wie bei kleinen Webseiten, die mit HTTP GET bedient werden), ist die Anzahl aktiver Verbindungen ziemlich klein. Wenn die Clientverbindungen langsamer sind (z. B. bei einer Datenbankabfrage), wird die Anzahl aktiver Verbindungen höher sein.

Sie sollten eine zu niedrige Proportionseinstellung für aktive und neue Verbindungen vermeiden. Wenn Sie diese beiden ersten Werte nicht jeweils auf mindestens 20 gesetzt haben, werden der Lastausgleich und die Glättungsfunktion inaktiviert.

Verwenden Sie zum Festlegen der proportionalen Gewichtung den Befehl dscontrol cluster set Cluster proportions. Weitere Informationen hierzu finden Sie im Abschnitt dscontrol cluster — Cluster konfigurieren.

Wertigkeiten

Die Managerfunktion legt Wertigkeiten ausgehend von internen Zählern des Executors, vom Feedback der Advisor und vom Feedback eines Systemüberwachungsprogramms wie Metric Server fest. Falls Sie Wertigkeiten bei Ausführung des Managers manuell festlegen möchten, geben Sie den Befehl "dscontrol server" mit der Option "fixedweight" an. Eine Beschreibung der Option fixedweight finden Sie im Abschnitt Feste Wertigkeiten vom Manager.

Wertigkeiten gelten für alle Server an einem Port. An einem bestimmten Port werden die Anfragen ausgehend von einem Vergleich der Wertigkeiten der einzelnen Server verteilt. Hat beispielsweise ein Server die Wertigkeit 10 und der andere Server die Wertigkeit 5, erhält der Server mit der Wertigkeit 10 doppelt so viele Anforderungen wie der Server mit der Wertigkeit 5.

Für die Wertigkeit, die ein Server haben kann, können Sie einen oberen Grenzwert angeben. Verwenden Sie dazu den Befehl dscontrol port set Port weightbound Wertigkeit. Mit diesem Befehl wird die Differenz festgelegt, die für die einzelnen Server hinsichtlich der Anzahl der Anforderungen gelten soll. Wird die Wertigkeitsobergrenze auf 1 gesetzt, können alle Server die Wertigkeit 1 haben. Stillgelegte Server haben die Wertigkeit 0 und inaktive Server die Wertigkeit -1. Wenn Sie diese Zahl erhöhen, vergrößern sich die Unterschiede bei der Gewichtung von Servern. Bei einer Wertigkeitsobergrenze von 2 kann ein Server doppelt so viele Anforderungen wie ein anderer Server erhalten. Bei einer Wertigkeitsobergrenze von 10 kann ein Server zehn Mal so viele Anforderungen wie ein anderer Server erhalten. Der Standardwert für die Wertigkeitsobergrenze ist 20.

Stellt ein Advisor fest, dass ein Server inaktiviert wurde, informiert er den Manager, der die Wertigkeit für den Server auf null setzt. Der Executor sendet in diesem Fall keine weiteren Verbindungen an diesen Server, solange die Wertigkeit bei null liegt. Falls es vor Änderung der Wertigkeit aktive Verbindungen zum Server gab, können diese normal beendet werden.

Wenn alle Server inaktiv sind, setzt der Manager die Wertigkeit auf die Hälfte der Gewichtungsgrenze.

Feste Wertigkeiten vom Manager

Ohne den Manager können Advisor nicht ausgeführt werden und nicht erkennen, ob ein Server inaktiv ist. Wenn Sie die Advisor ausführen möchten, der Manager jedoch nicht die von Ihnen für einen bestimmten Server festgelegte Wertigkeit aktualisieren soll, verwenden Sie den Befehl dscontrol server mit der Option fixedweight. Beispiele:

dscontrol server set Cluster:Port:Server fixedweight yes

Nachdem Sie fixedweight auf yes gesetzt haben, können Sie die Wertigkeit mit dem Befehl dscontrol server set weight auf den gewünschten Wert setzen. Der Wert für die Serverwertigkeit bleibt während der Ausführung des Managers unverändert erhalten, bis Sie einen weiteren Befehl dscontrol server absetzen, bei dem fixedweight auf no gesetzt ist. Weitere Informationen hierzu finden Sie im Abschnitt dscontrol server — Server konfigurieren.

TCP-Rücksetzanforderung an einen inaktiven Server senden (nur Komponente Dispatcher)

Wenn TCP reset aktiviert ist, sendet der Dispatcher eine TCP-Rücksetzanforderung an den Client, sofern dieser eine Verbindung zu einem Server mit der Wertigkeit 0 hat. Die Wertigkeit eines Servers kann 0 sein, weil sie mit dem Wert 0 konfiguriert wurde oder weil der Server von einem Advisor als inaktiv markiert wurde. Eine TCP-Rücksetzanforderung bewirkt eine sofortige Beendigung der Verbindung. Dieses Feature ist hilfreich für lang andauernde Verbindungen, denn sie gibt dem Client die Möglichkeit, eine unterbrochene Verbindung schnell neu auszuhandeln. Verwenden Sie zum Aktivieren von TCP-Rücksetzanforderungen den Befehl dscontrol port add|set Port reset yes. Der Standardwert für reset ist no.

Anmerkung:
Die TCP-Rücksetzanforderung kann auf alle Dispatcher-Weiterleitungsmethoden angewendet werden. Voraussetzung für die Verwendung des Feature für TCP-Rücksetzanforderungen ist jedoch, dass der Parameter clientgateway des Befehls dscontrol executor auf eine Router-Adresse gesetzt ist.

In Verbindung mit TCP-Rücksetzanforderungen kann es sinnvoll sein, das Feature advisor retry zu konfigurieren. Dieses Feature gibt einem Advisor die Möglichkeit, einen erneuten Verbindungsversuch zu starten, bevor ein Server als inaktiv markiert wird. Auf diese Weise wird verhindert, dass der Advisor den Server vorschnell als inaktiv markiert, was zu Problemen beim Zurücksetzen der Verbindung führen könnte. Ein erster gescheiterter Verbindungsversuch des Advisors muss nicht zwingend bedeuten, dass die vorhandenen Verbindungen ebenfalls unterbrochen sind. Weitere Informationen hierzu finden Sie im Abschnitt Wiederholungsversuche des Advisors.

Managerintervalle

Um den Gesamtdurchsatz zu optimieren, wird die Interaktion von Manager und Executor in ihrer Häufigkeit eingeschränkt. Sie können dieses Intervall mit den Befehlen dscontrol manager interval und dscontrol manager refresh ändern.

Mit dem Managerintervall wird angegeben, wie oft der Manager die Serverwertigkeiten aktualisiert, die der Executor für die Weiterleitung von Verbindungen benutzt. Ein zu niedriges Managerintervall kann sich negativ auf die Leistung auswirken, da der Manager den Executor permanent unterbricht. Ein zu hohes Managerintervall kann bedeuten, dass die Weiterleitung von Anforderungen durch den Executor nicht auf genauen, auf dem neuesten Stand befindlichen Informationen basiert.

Wollen Sie beispielsweise das Managerintervall auf 1 Sekunde setzen, geben Sie den folgenden Befehl ein:

 dscontrol manager interval 1

Der Manager-Aktualisierungszyklus (Refresh) gibt an, wie oft der Manager Statusinformationen vom Executor anfordert. Der Aktualisierungszyklus basiert auf der Intervallzeit.

Wollen Sie beispielsweise den Manager-Aktualisierungszyklus auf 3 setzen, geben Sie den folgenden Befehl ein:

  dscontrol manager refresh 3

In diesem Fall wartet der Manager 3 Intervalle ab, bevor er Statusinformationen vom Executor anfordert.

Sensitivitätsschwelle

Zur Optimierung des Lastausgleichs für Ihre Server stehen weitere Methoden zur Verfügung. Im Interesse einer hohen Übertragungsgeschwindigkeit werden die Wertigkeiten der Server nur aktualisiert, wenn sich signifikante Änderungen der Wertigkeit ergeben. Das permanente Aktualisieren der Wertigkeiten bei geringfügigen oder nicht vorhandenen Änderungen des Serverstatus würde zu einem unnötigen Systemaufwand führen. Wenn die prozentuale Änderung der Wertigkeit innerhalb der summierten Wertigkeit für alle Server an einem Port über der Sensitivitätsschwelle liegt, aktualisiert der Manager die vom Executor für die Verteilung der Verbindungen verwendeten Wertigkeiten. Nehmen wir beispielsweise an, die Gesamtwertigkeit ändert sich von 100 % auf 105 %. Die Änderung beträgt also 5 %. Beim standardmäßig festgelegten Sensitivitätsschwellenwert von 5 aktualisiert der Manager nicht die vom Executor verwendeten Wertigkeiten, da die prozentuale Änderung nicht über dem Schwellenwert liegt. Ändert sich die Gesamtwertigkeit jedoch von 100 % auf 106 %, aktualisiert der Manager die Wertigkeiten. Wollen Sie beispielsweise die Sensitivitätsschwelle des Managers auf einen anderen Wert als den Standardwert setzen (zum Beispiel 6), geben Sie den folgenden Befehl ein:

  dscontrol manager sensitivity 6

In den meisten Fällen müssen Sie diesen Wert nicht ändern.

Glättungsfaktor

Der Manager berechnet die Serverwertigkeiten dynamisch. Daher kann eine aktualisierte Wertigkeit erheblich von der vorherigen Wertigkeit abweichen. In den meisten Fällen stellt dies kein Problem dar. Gelegentlich kann dies jedoch zu erheblichen Schwankungen bei der Verteilung von Anforderungen führen. So kann beispielsweise ein Server aufgrund seiner hohen Wertigkeit den größten Teil der Anforderungen erhalten. Der Manager stellt fest, dass der Server über eine hohe Anzahl von aktiven Verbindungen verfügt und sehr langsam antwortet. Der Manager verschiebt die Wertigkeit dann auf die freien Server, so dass dort derselbe Effekt auftritt und Ressourcen folglich ineffizient genutzt werden.

Um die Auswirkungen dieses Problems zu verringern, benutzt der Manager einen Glättungsfaktor (smoothing index). Der Glättungsfaktor begrenzt das Maß, in dem sich die Wertigkeit eines Servers ändern kann, und gleicht Änderungen in der Anforderungsverteilung aus. Ein höherer Glättungsfaktor führt zu einer weniger drastischen Änderung der Serverwertigkeiten. Ein geringerer Glättungsfaktor führt zu einer drastischeren Änderung der Serverwertigkeiten. Der Standardwert für den Glättungsfaktor ist 1,5. Bei einem Wert von 1,5 können Serverwertigkeiten sehr dynamisch sein. Bei einem Faktor von 4 oder 5 sind die Wertigkeiten stabiler. Wenn Sie den Glättungsfaktor beispielsweise auf 4 setzen möchten, geben Sie den folgenden Befehl ein:

  dscontrol manager smoothing 4

In den meisten Fällen müssen Sie diesen Wert nicht ändern.

Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden

Load Balancer stellt Benutzerexits bereit, die Scripts aktivieren, die von Ihnen angepasst werden können. Sie können Scripts für die Ausführung automatisierter Aktionen erstellen. Eine solche Aktion wäre beispielsweise das Informieren eines Administrators über inaktive Server per Alert oder das Registrieren eines Ausfalls. Beispielscripts, die Sie anpassen können, finden Sie im folgenden Verzeichnis:

Zum Ausführen der Dateien müssen Sie sie in das folgende Verzeichnis verschieben und die Dateierweiterung "sample" entfernen:

Es stehen die folgenden Beispielscripts bereit:

Wenn alle Server eines Clusters (vom Benutzer oder von den Advisor) als inaktiv markiert wurden, wird managerAlert gestartet (sofern konfiguriert), und Load Balancer versucht, den Datenverkehr mit einer RoundRobin-Technik an die Server weiterzuleiten. Das Script serverDown wird nicht gestartet, wenn festgestellt wird, dass der letzte Server des Clusters offline ist.

Load Balancer ist so konzipiert, dass die Weiterleitungsversuche fortgesetzt werden, falls ein Server wieder online geht und auf die Anforderung reagiert. Würde Load Balancer dagegen den gesamten Datenverkehr übergehen, würde der Client keine Antwort empfangen.

Stellt Load Balancer fest, dass der erste Server eines Clusters wieder online ist, wird das Script managerClear gestartet (sofern konfiguriert). Das Script serverUp (sofern konfiguriert) wird erst ausgeführt, wenn ein weiterer Server wieder online ist.

Hinweise zur Verwendung der Scripts serverUp und serverDown:

Advisor

Advisor sind Agenten von Load Balancer. Ihr Zweck ist es, den Zustand und die Arbeitslast der Servermaschinen zu beurteilen. Dies erfolgt durch einen proaktiven Austausch mit den Servern, der dem von Clients vergleichbar ist. Advisor können als transportable Clients der Anwendungsserver betrachtet werden.

Das Produkt stellt mehrere protokollspezifische Advisor für die am häufigsten verwendeten Protokolle zur Verfügung. Es ist jedoch nicht sinnvoll, alle verfügbaren Advisor mit jeder Komponente von Load Balancer zu verwenden. (Der Advisor Telnet wird beispielsweise nicht mit der Komponente CBR verwendet.) Load Balancer unterstützt auch das Konzept des „angepassten Advisors", so dass Benutzer eigene Advisor schreiben können.

Einschränkung für die Verwendung bindungsspezifischer Serveranwendungen: Wenn Sie Advisor für einen bindungsspezifischen Server verwenden möchten, müssen Sie zwei Instanzen des Servers starten, eine Instanz, die an den Cluster:Port gebunden wird, und eine, die an den Server:Port gebunden wird. Mit dem Befehl netstat -an können Sie feststellen, ob der Server bindungsspezifisch ist. Achten Sie auf den Server:Port. Wenn der Server nicht bindungsspezifisch ist, gibt der Befehl 0.0.0.0:80 zurück. Andernfalls sehen Sie eine Adresse wie 192.168.15.103:80.

Einschränkung auf HP-UX- und Solaris-Systemen für die Verwendung bindungsspezifischer Serveranwendungen: Wenn an Stelle des Befehls ifconfig alias der Befehl arp publish verwendet wird, unterstützt Load Balancer die Verwendung von Advisor beim Lastausgleich für Server mit bindungsspezifischen Serveranwendungen (einschließlich anderer Komponenten von Load Balancer wie CBR oder Site Selector), wenn die Bindung an die Cluster-IP-Adresse erfolgt. Bei Verwendung von Advisor für eine bindungsspezifische Anwendung sollten Sie Load Balancer jedoch nicht mit der Serveranwendung auf derselben Maschine verknüpfen.

Anmerkung:
Wenn Load Balancer auf einem Computer mit mehreren Netzwerkadaptern ausgeführt wird und der Advisordatenverkehr über einen bestimmten Adapter fließen soll, können Sie für die Pakete eine bestimmte Quellen-IP-Adresse erzwingen. Falls Sie für die Advisor-Pakete eine bestimmte Quellenadresse erzwingen möchten, fügen Sie zur Zeile java...SRV_XXXConfigServer... des entsprechenden Startscripts für Load Balancer (dsserver, cbrserver oder ssserver) Folgendes hinzu:
-DLB_ADV_SRC_ADDR=IP-Adresse

Arbeitsweise der Advisor

Advisor öffnen regelmäßig eine TCP-Verbindung zu jedem Server und senden eine Anforderungsnachricht an den Server. Der Inhalt der Nachricht ist spezifisch für das Protokoll, das auf dem Server ausgeführt wird. Der HTTP-Advisor sendet beispielsweise eine HTTP-Anfrage „HEAD" an den Server.

Die Advisor warten dann auf den Empfang einer Antwort vom Server. Nach Empfang der Antwort beurteilt der Advisor den Server. Um diesen „Lastwert" zu ermitteln, messen die meisten Advisor die Zeit, bis der Server antwortet, und verwenden dann diesen Wert (in Millisekunden) als Lastwert.

Die Advisor übergeben dann den Lastwert an die Managerfunktion, die ihn im Managerbericht in der Spalte „Port" angibt. Der Manager addiert anschließend die Wertigkeiten für alle Quellen entsprechend ihren Proportionen und übergibt diese Werte an die Executor-Funktion. Der Executor benutzt diese Wertigkeiten dann für den Lastausgleich neuer ankommender Clientverbindungen.

Stellt der Advisor fest, dass ein Server aktiv ist und ordnungsgemäß arbeitet, meldet er einen positiven Lastwert ungleich null an den Manager. Stellt der Advisor fest, dass ein Server inaktiv ist, gibt er den speziellen Lastwert -1 zurück. Der Manager und der Executor leiten daraufhin keine Verbindungen an diesen Server weiter, solange dieser inaktiv ist.

Anmerkung:
Vor dem Senden der ersten Anforderungsnachricht sendet der Advisor ein Pingsignal an den Server. Auf diese Weise steht schnell ein Status zur Verfügung, mit dem festgestellt werden kann, ob die Maschine online ist. Antwortet der Server auf das Pingsignal, werden keine weiteren Pingsignale gesendet. Wenn Sie die Pingsignale inaktivieren möchten, fügen Sie zur Startscriptdatei von Load Balancer -DLB_ADV_NO_PING hinzu.

Advisor starten und stoppen

Sie können einen Advisor clusterübergreifend für einen bestimmten Port starten (Gruppen-Advisor). Sie können aber auch an einem Port verschiedene Advisor für verschiedene Cluster ausführen (cluster-/sitespezifischer Advisor). Wenn Sie Load Balancer beispielsweise mit drei Clustern (ClusterA, ClusterB, ClusterC), jeweils mit Port 80, konfiguriert haben, können Sie folgende Schritte ausführen:

Wenn Sie das vorherige Konfigurationsbeispiel für den Gruppenadvisor verwenden, können Sie bei Bedarf den angepassten Advisor angepasster_Advisor am Port 80 für einen oder beide Cluster (ClusterB und ClusterC) stoppen.

Advisorintervalle

Anmerkung:
Die Advisorstandardwerte funktionieren in den meisten Fällen effizient. Gehen Sie mit Vorsicht vor, wenn Sie andere Werte als die Standardwerte verwenden.

Das Advisorintervall legt fest, wie oft ein Advisor den Status der Server an dem von ihm überwachten Port abfragt und die Ergebnisse dann an den Manager übergibt. Ein zu niedriges Advisorintervall kann sich negativ auf die Leistung auswirken, da der Advisor die Server permanent unterbricht. Ist das Advisorintervall zu hoch, basieren die Entscheidungen des Managers hinsichtlich der Gewichtung unter Umständen nicht auf exakten aktuellen Informationen.

Wenn Sie das Intervall des HTTP-Advisors am Port 80 beispielsweise auf 3 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:

  dscontrol advisor interval http 80 3

Es ist nicht sinnvoll, ein Advisorintervall anzugeben, das kleiner als das Managerintervall ist. Das Standardadvisorintervall liegt bei sieben Sekunden.

Berichtszeitlimit für Advisor

Der Manager verwendet keine Advisorinformationen, deren Zeitmarke älter als die für das Berichtszeitlimit des Advisors festgelegte Zeit ist, um sicherzustellen, dass keine veralteten Informationen verwendet werden. Das Berichtszeitlimit des Advisors muss größer als das Sendeaufrufintervall des Advisors sein. Ist das Zeitlimit kleiner, ignoriert der Manager Berichte, die eigentlich verwendet werden müssten. Für Berichte des Advisors gilt standardmäßig kein Zeitlimit, so dass der Standardwert unlimited ist.

Wenn Sie das Berichtszeitlimit für den HTTP-Advisor am Port 80 beispielsweise auf 30 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:

dscontrol advisor timeout http 80 30 

Weitere Informationen zum Festlegen des Berichtszeitlimits für den Advisor finden Sie im Abschnitt dscontrol advisor — Advisor steuern.

Serververbindungs- und -empfangszeitlimit des Advisors

Für Load Balancer können Sie die Zeitlimits des Advisors festlegen, innerhalb deren der Ausfall eines bestimmten Server- oder Serviceports festgestellt werden soll. Die Zeitlimits für ausgefallene Server (connecttimeout und receivetimeout) bestimmen, wie lange ein Advisor wartet, bis er einen gescheiterten Sende- oder Empfangsvorgang meldet.

Für eine schnellstmögliche Erkennung ausgefallener Server müssen Sie das Verbindungs- und Empfangszeitlimit des Advisors auf den kleinsten Wert (eine Sekunde) sowie das Advisor- und Managerintervall auf den kleinsten Wert (eine Sekunde) setzen.

Anmerkung:
Falls es in Ihrer Umgebung ein mittleres bis hohes Datenverkehrsaufkommen gibt, so dass sich die Serverantwortzeit erhöht, sollten Sie die Werte connecttimeout und receivetimeout nicht zu niedrig festlegen. Andernfalls könnte der Advisor einen ausgelasteten Server vorschnell als ausgefallenen Server markieren.

Wenn Sie connecttimeout und receivetimeout für den HTTP-Advisor am Port 80 beispielsweise auf 9 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:

dscontrol advisor connecttimeout http 80 9
dscontrol advisor receivetimeout http 80 9  

Der Standardwert für das Verbindungs- und Empfangszeitlimit liegt beim Dreifachen des Wertes, der für das Intervall des Advisors angegeben wurde.

Wiederholungsversuche des Advisors

Advisor können wiederholt versuchen, eine Verbindung herzustellen, bevor sie einen Server als inaktiv markieren. Der Advisor markiert einen Server erst dann als inaktiv, wenn die Abfrage nach der festgelegten Anzahl Wiederholungen und einem weiteren Versuch nicht beantwortet wird. Der Wert für retry sollte nicht über 3 liegen. Mit dem folgenden Befehl wird retry für den LDAP-Advisor am Port 389 auf 2 gesetzt:

dscontrol advisor retry ldap 389 2

Liste der Advisor

Option "Anforderung/Antwort (URL)" des HTTP- oder HTTPS-Advisors konfigurieren

Die URL-Option des HTTP- oder HTTPS-Advisors ist für die Komponenten Dispatcher und CBR verfügbar.

Nach dem Starten eines HTTP- oder HTTPS-Advisors können Sie für den Dienst, den Sie vom Server anfordern möchten, eine eindeutige Client-HTTP-URL-Zeichenfolge definieren. Mit dieser Zeichenfolge kann der Advisor den Status einzelner Dienste auf einem Server bewerten. Dies können Sie erreichen, indem Sie logische Server, die dieselbe physische IP-Adresse haben, mit eindeutigen Servernamen definieren. Weitere Informationen hierzu finden Sie im Abschnitt Serverpartitionierung - Logische Server für einen physischen Server (IP-Adresse) konfigurieren.

Für jeden unter dem HTTP-Port definierten logischen Server können Sie für den Dienst, den Sie vom Server anfordern möchten, eine eindeutige Client-HTTP-URL-Zeichenfolge angeben. Der HTTP- oder HTTPS-Advisor verwendet die Zeichenfolge advisorrequest, um den Status der Server abzufragen. Der Standardwert ist HEAD / HTTP/1.0. Die Zeichenfolge advisorresponse ist die Antwort, nach der der Advisor die HTTP-Antwort durchsucht. Der Advisor vergleicht die Zeichenfolge advisorresponse mit der tatsächlich vom Server empfangenen Antwort. Der Standardwert ist null.

Wichtiger Hinweis: Wenn die HTTP-URL-Zeichenfolge ein Leerzeichen enthält, gilt Folgendes:

Wenn Sie die Anforderung erstellen, die der Advisor HTTP oder HTTPS an Back-End-Server sendet, um deren Funktionstüchtigkeit zu überprüfen, geben Sie nur den Anfang der HTTP-Anforderung ein. Load Balancer vervollständigt die Anforderung mit folgenden Angaben:

\r\nAccept:
*/*\r\nUser-Agent:IBM_Load_Balanacer_HTTP_Advisor\r\n\r\n 

Falls Sie weitere HTTP-Header-Felder hinzufügen möchten, bevor Load Balancer diese Zeichenfolge an das Ende der Anforderung anfügt, können Sie eine eigene \r\n-Zeichenfolge in die Anforderung aufnehmen. Nachfolgend sehen Sie eine Beispieleingabe für das Hinzufügen des HTTP-Header-Feldes "Host" zur Anforderung:

GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHost: www.w3.org
Anmerkung:
Nach dem Start eines HTTP- oder HTTPS-Advisors für eine angegebene HTTP-Portnummer, wird für Server an diesem HTTP-Port der Abfrage-/Antwortwert des Advisors aktiviert.

Weitere Informationen hierzu finden Sie im Abschnitt dscontrol server — Server konfigurieren.

Advisor "self" in einer Client/Server-WAN-Konfiguration verwenden

Der Advisor self ist für die Komponente Dispatcher verfügbar.

Wenn Load Balancer in einer Client/Server-WAN-Konfiguration (Weitverkehrsnetz) installiert ist, stellt der Dispatcher den Advisor self bereit, der Informationen zum Auslastungsstatus von Back-End-Servern sammelt.

Abbildung 31. Beispiel für eine Client/Server-WAN-Konfiguration mit dem Advisor self
Client/Server-WAN-Konfiguration mit dem Advisor self

In diesem Beispiel befinden sich der Advisor self und Metric Server auf den beiden Dispatcher-Maschinen, deren Lastausgleich vom übergeordneten Load Balancer durchgeführt wird. Der Advisor self misst insbesondere die Verbindungen pro Sekunde für die Back-End-Server des Dispatchers auf Executor-Ebene.

Der Advisor self schreibt die Ergebnisse in die Datei dsloadstat. Load Balancer stellt außerdem die externe Metrik dsload bereit. Bei Ausführung der Konfiguration des Agenten Metric Server auf den Dispatcher-Maschinen wird die externe Metrik dsload aufgerufen. Das dsload-Script extrahiert eine Zeichenfolge aus der Datei dsloadstat und gibt sie an den Agenten Metric Server zurück. Anschließend geben die Metric-Server-Agenten (von den einzelnen Dispatcher-Maschinen) den Wert für den Auslastungsstatus an den übergeordneten Load Balancer zurück, damit dieser bestimmen kann, welcher Dispatcher Clientanforderungen weiterleiten soll.

Die ausführbare Datei dsload befindet sich im folgenden Verzeichnis:

Weitere Informationen zur Verwendung von Dispatcher in WAN-Konfigurationen finden Sie im Abschnitt Dispatcher-WAN-Unterstützung konfigurieren. Weitere Informationen zu Metric Server können Sie dem Abschnitt Metric Server entnehmen.

Angepassten (anpassbaren) Advisor erstellen

Der angepasste (anpassbare) Advisor ist ein kurzer Java-Code, den Sie als Klassendatei bereitstellen, die vom Basiscode aufgerufen wird. Der Basiscode gewährleistet alle Verwaltungsdienste wie das Starten und Stoppen einer Instanz des angepassten Advisors, das Bereitstellen von Status und Berichten sowie das Aufzeichnen von Protokolldaten in einer Protokolldatei. Er übergibt auch die Ergebnisse an die Managerfunktion. Der Basiscode führt regelmäßig einen Advisorzyklus aus, wobei alle Server in der Konfiguration individuell ausgewertet werden. Dieser beginnt mit dem Öffnen einer Verbindung zu einer Servermaschine. Wenn das Socket geöffnet wird, ruft der Basiscode die Methode (Funktion) „getLoad" des angepassten Advisors auf. Der angepasste Advisor führt dann alle für die Auswertung des Serverstatus erforderlichen Schritte aus. Normalerweise sendet er eine benutzerdefinierte Nachricht an den Server und wartet dann auf eine Antwort. (Der angepasste Advisor erhält Zugriff auf den geöffneten Socket.) Der Basiscode schließt dann den Socket zu dem Server und übergibt die Lastinformationen an den Manager.

Der Basiscode und der angepasste Advisor können im normalen Modus oder im Ersetzungsmodus arbeiten. Die Auswahl der Betriebsart wird in der Datei des angepassten Advisors als Parameter der Methode constructor angegeben.

Im normalen Modus tauscht der angepasste Advisor Daten mit dem Server aus. Der Basiscode des Advisors misst die Zeit für den Austausch und berechnet den Lastwert. Der Basiscode übergibt dann diesen Lastwert an den Manager. Der angepasste Advisor muss nur null (bei Erfolg) oder -1 (bei einem Fehler) zurückgeben. Zur Angabe des normalen Modus wird das Flag replace der Methode constructor auf false (falsch) gesetzt.

Im Ersetzungsmodus führt der Basiscode keine Zeitmessungen aus. Der Code des angepassten Advisors führt alle für die funktionsspezifischen Anforderungen erforderlichen Operationen aus und gibt dann einen tatsächlichen Lastwert zurück. Der Basiscode akzeptiert diesen Wert und übergibt ihn an den Manager. Um bestmögliche Ergebnisse zu erzielen, sollten Sie den Lastwert zwischen 10 und 1000 normalisieren, wobei 10 einen schnellen Server und 1000 einen langsamen Server angibt. Zur Angabe des Ersetzungsmodus muss das Flag replace der Methode constructor auf true gesetzt werden.

Auf diese Weise können Sie eigene Advisor schreiben, die die benötigten präzisen Informationen über Server zur Verfügung stellen. Zu Load Balancer wird ein Beispiel für einen angepassten Advisor, ADV_sample.java, geliefert.

Nach der Installation von Load Balancer finden Sie den Beispielcode im folgenden Verzeichnis:

Anmerkung:
Wenn Sie einen angepassten Advisor zum Dispatcher oder zu einer anderen Komponente von Load Balancer hinzufügen, müssen Sie dsserver (bzw. auf Windows-Systemen den Dienst) stoppen und dann erneut starten, um den Java-Prozess zu veranlassen, die Klassendateien des neuen angepassten Advisors zu lesen. Die Klassendateien des angepassten Advisors werden nur beim Systemstart geladen. Es ist nicht nötig, den Executor zu stoppen. Der Executor wird weiter ausgeführt, auch wenn dsserver oder der entsprechende Dienst gestoppt wurde.

Wenn der angepasste Advisor auf zusätzliche Java-Klassen verweist, muss der Klassenpfad (classpath) in der Startscriptdatei von Load Balancer (dsserver, cbrserver, ssserver) mit dem Verzeichnis dieser Klassen aktualisiert werden.

Advisor WAS

Das Installationsverzeichnis von Load Balancer enthält Beispieldateien für angepasste Advisor, insbesondere für den Advisor WAS (WebSphere Application Server).

Die Beispieldateien für den Advisor WAS befinden sich in demselben Verzeichnis wie die Datei ADV_sample.java.

Namenskonvention

Der Dateiname für Ihren angepassten Advisor muss das Format „ADV_meinAdvisor.java" haben. Er muss mit dem Präfix „ADV_" in Großbuchstaben beginnen. Alle nachfolgenden Zeichen müssen Kleinbuchstaben sein.

Aufgrund von Java-Konventionen muss der Name der in der Datei definierten Klasse mit dem Namen der Datei übereinstimmen. Wenn Sie den Beispielcode kopieren, stellen Sie sicher, dass alle Exemplare von „ADV_sample" in der Datei in den neuen Klassennamen geändert werden.

Kompilierung

Angepasste Advisor werden in der Sprache Java geschrieben. Verwenden Sie den Java-Compiler, der zusammen mit Load Balancer installiert wird. Während der Kompilierung wird auf die folgenden Dateien Bezug genommen:

Der Klassenpfad muss während der Kompilierung auf die Datei des angepassten Advisors und die Datei mit den Basisklassen zeigen.

Beispielkompilierungsbefehl für Windows-Systeme:

Installationsverzeichnis/java/bin/javac -classpath
    Installationsverzeichnis\lb\servers\lib\ibmlb.jar ADV_fred.java

Für diesen Befehl gilt Folgendes:

Die Ausgabe der Kompilierung ist eine Klassendatei, zum Beispiel

ADV_fred.class

Kopieren Sie vor dem Starten des Advisors die Klassendatei in das folgende Verzeichnis:

Anmerkung:
Bei Bedarf können angepasste Advisor unter einem Betriebssystem kompiliert und unter einem anderen Betriebssystem ausgeführt werden. Sie können beispielsweise Ihren Advisor auf Windows-Systemen kompilieren, die Klassendatei (im Binärformat) auf eine AIX-Maschine kopieren und den Advisor dort ausführen.

Auf AIX-, HP-UX-, Linux- und Solaris-Systemen ist die Syntax ähnlich.

Ausführung

Bevor Sie den angepassten Advisor ausführen, müssen Sie die Klassendatei in das richtige Unterverzeichnis des Installationsverzeichnisses kopieren:

Konfigurieren Sie die Komponente, starten Sie die zugehörige Managerfunktion und setzen Sie wie folgt den Befehl zum Starten des angepassten Advisors ab:

dscontrol advisor start fred 123

Für diesen Befehl gilt Folgendes:

Wenn der angepasste Advisor auf zusätzliche Java-Klassen verweist, muss der Klassenpfad (classpath) in der Startscriptdatei von Load Balancer (dsserver, cbrserver, ssserver) mit dem Verzeichnis dieser Klassen aktualisiert werden.

Erforderliche Routinen

Ein angepasster Advisor erweitert wie alle anderen Advisor den Advisorbasiscode ADV_Base. Es ist der Advisorbasiscode, der die meisten Funktionen ausführt. Dazu gehört das Zurückmelden von Arbeitslasten an den Manager, die für den Wertigkeitsalgorithmus des Managers verwendet werden. Darüber hinaus stellt der Advisorbasiscode Socket-Verbindungen her, schließt Sockets und stellt Sende- und Empfangsmethoden für den Advisor bereit. Der Advisor selbst wird nur zum Senden von Daten an den Port bzw. Empfangen von Daten vom Port des empfohlenen Servers verwendet. Die TCP-Methoden innerhalb des Advisorbasiscodes sind zeitlich gesteuert, um die Last zu berechnen. Mit einem Flag der Methode "constructor" in "ADV_base" kann bei Bedarf die vorhandene Last mit der neuen, vom Advisor zurückgegebenen Last überschrieben werden.

Anmerkung:
Der Advisorbasiscode stellt in angegebenen Intervallen die Last ausgehend von einem in der Methode constructor gesetzten Wert für den Wertigkeitsalgorithmus bereit. Wenn der eigentliche Advisor noch keine gültige Last zurückgeben kann, verwendet der Advisorbasiscode die vorherige Last.

Basisklassenmethoden sind:

Suchreihenfolge

Load Balancer durchsucht zunächst die Liste der eigenen Advisor. Wenn ein bestimmter Advisor dort nicht aufgeführt ist, durchsucht Load Balancer die Kundenliste der angepassten Advisor.

Benennung und Pfad

Beispiel-Advisor

Die Programmliste für eine Beispiel-Advisor finden Sie im Abschnitt Beispieladvisor. Nach der Installation befindet sich dieser Beispiel-Advisor im folgenden Verzeichnis:

Metric Server

Diese Funktion ist für alle Komponenten von Load Balancer verfügbar.

Metric Server gibt Load Balancer Informationen zur Serverauslastung. Diese Informationen werden in Form systemspezifischer Metriken für den Serverzustand bereitgestellt. Der Manager von Load Balancer richtet Anfragen an den Agenten Metric Server, der sich auf jedem der Server befindet, und legt anhand der Metriken, die er von den Agenten erhalten hat, Wertigkeiten für den Lastausgleich fest. Die Ergebnisse werden auch in den Managerbericht gestellt.

Anmerkung:
Wenn für jeden Server zwei oder mehr Metriken ermittelt und in einen Systemauslastungswert normalisiert werden, kann es zu Rundungsfehlern kommen.

Informationen zur Verwendung (zum Starten und Stoppen) von Metric Server und zur Verwendung von Metric-Server-Protokollen finden Sie im Abschnitt Metric Server verwenden.

Ein Konfigurationsbeispiel ist in Abb. 5 dargestellt.

WLM-Einschränkung

Wie der WLM-Advisor gibt Metric Server Berichte zu kompletten Serversystemen aus und nicht zu einzelnen protokollspezifischen Serverdämonen. WLM und Metric Server stellen ihre Ergebnisse in die Spalte "System" des Managerberichts. Deshalb wird die gleichzeitige Ausführung von WLM-Advisor und Metric Server nicht unterstützt.

Vorbedingungen

Der Agent Metric Server muss auf allen Servern installiert und ausgeführt werden, die am Lastausgleich teilnehmen.

Metric Server verwenden

Nachfolgend sind die Schritte aufgeführt, mit denen Sie Metric Server für den Dispatcher konfigurieren. Wenn Sie Metric Server für andere Komponenten von Load Balancer konfigurieren möchten, sind ähnliche Schritte auszuführen.

Wenn Metric Server für eine vom lokalen Host abweichende Adresse ausgeführt werden soll, müssen Sie die Datei metricserver auf der am Lastausgleich beteiligten Servermaschine editieren. Fügen Sie in der Datei metricserver nach dem Eintrag "java" Folgendes ein:

-Djava.rmi.server.hostname=andere_Adresse

Fügen Sie außerdem vor den "if"-Anweisungen die folgende Zeile zur Datei metricserver hinzu: hostname andere_Adresse.

Auf der Windows-Plattform müssen Sie außerdem in Microsoft Stack auf der Metric-Server-Maschine den Aliasnamen für andere_Adresse angeben. Beispiel:

call netsh interface ip add address "Local Area Connection" 
  addr=9.37.51.28 mask=255.255.240.0

Wenn Sie Metriken domänenübergreifend erfassen, müssen Sie java.rmi.server.hostname im Server-Script (dsserver, cbrserver usw.) auf den vollständig qualifizierten Domänennamen (FQDN) der Maschine setzen, die die Metriken anfordert. Dies ist notwendig, weil InetAddress.getLocalHost.getHostName() nicht für jede Konfiguration und unter jedem Betriebssystem den FQDN zurückgibt.

Advisor Workload Manager

WLM ist Code, der auf MVS-Großrechnern ausgeführt wird. Er kann abgefragt werden, um die Arbeitslast auf der MVS-Maschine zu bestimmen.

Wurde MVS Workload Management auf Ihrem OS/390-System konfiguriert, kann der Dispatcher Kapazitätsinformationen von WLM akzeptieren und die Informationen für den Lastausgleich verwenden. Mit dem WLM-Advisor öffnet der Dispatcher regelmäßig Verbindungen über den WLM-Port der einzelnen Server in der Dispatcher-Hosttabelle und akzeptiert die zurückgegebenen ganzzahligen Kapazitätswerte. Da diese ganzen Zahlen die noch verfügbare Kapazität darstellen und Dispatcher Werte erwarten, die die Arbeitslast auf jeder Maschine angeben, werden die ganzzahligen Kapazitätswerte vom Advisor in Lastwerte umgekehrt und normalisiert. (Ein hoher ganzzahliger Kapazitätswert und ein niedriger Lastwert geben beide einen akzeptablen Zustand eines Servers an). Die daraus resultierenden Arbeitslasten werden in die Spalte "System" des Managerberichts gestellt.

Es gibt mehrere wichtige Unterschiede zwischen dem WLM-Advisor und anderen Advisor des Dispatchers:

  1. Andere Advisor öffnen Verbindungen zu den Servern unter Verwendung des Ports, über den der normale Clientdatenverkehr fließt. Der WLM-Advisor benutzt für das Öffnen von Verbindungen zu den Servern nicht den für normalen Datenverkehr verwendeten Port. Der WLM-Agent muss auf den einzelnen Servermaschinen so konfiguriert werden, dass er an dem Port empfangsbereit ist, an dem der WLM-Advisor des Dispatchers gestartet wurde. Der Standard-WLM-Port ist 10007.
  2. Andere Advisor bewerten nur die in der Konfiguration Cluster:Port:Server des Dispatchers definierten Server, deren Serverport mit dem Port des Advisors übereinstimmt. Der WLM-Advisor wird (unabhängig von der Angabe Cluster:Port) für alle Server in der Dispatcher-Konfiguration ausgeführt. Daher dürfen Sie bei Verwendung des WLM-Advisors nur WLM-Server definieren.
  3. Andere Advisor stellen ihre Lastinformationen in die Spalte „Port" des Managerberichts. Der WLM-Advisor stellt seine Lastinformationen in die Spalte "System" des Managerberichts.
  4. Es ist möglich, protokollspezifische Advisor zusammen mit dem WLM-Advisor zu verwenden. Die protokollspezifischen Advisor fragen die Server an den regulären Ports für Datenverkehr ab. Der WLM-Advisor fragt die Systemlast dagegen am WLM-Port ab.

Einschränkungen für Metric Server

Der WLM-Agent gibt wie der Agent Metric Server Berichte zu kompletten Serversystemen aus und nicht zu einzelnen protokollspezifischen Serverdämonen. Metric Server und WLM stellen ihre Ergebnisse in die Spalte "System" des Managerberichts. Deshalb wird die gleichzeitige Ausführung von WLM-Advisor und Metric Server nicht unterstützt.