In diesem Kapitel wird erklärt, wie die Lastausgleichsparameter, die Manager, die Advisor und die Funktion Metric Server von Load Balancer konfiguriert werden.
Task | Beschreibung | Referenzinformationen |
---|---|---|
Ändern der Einstellungen für den Lastausgleich (optional) |
Sie können die folgenden Einstellungen für den Lastausgleich ändern:
|
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 |
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.
Der Manager kann in seine Gewichtungsentscheidung alle oder einige der nachfolgend genannten externen Faktoren einfließen lassen:
Oder —
CPU: Prozentsatz der auf jeder am Lastausgleich beteiligten Servermaschine genutzten CPU (Vorgabe vom Agenten Metric Server). Für Site Selector wird diese Proportion an Stelle der Spalte für aktive Verbindungen angezeigt.
Oder —
Speicher: Prozentsatz des auf jeder am Lastausgleich beteiligten Servermaschine genutzten Speichers (Vorgabe vom Metric Server Agent). Für Site Selector wird diese Proportion an Stelle der Spalte für neue Verbindungen angezeigt.
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.
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.
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.
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.
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. Beispiel:
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.
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.
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.
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.
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.
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.
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 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.
-DLB_ADV_SRC_ADDR=IP-Adresse
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.
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:
dscontrol advisor start http ClusterA:80
Dieser Befehl startet den HTTP-Advisor am Port 80 für ClusterA. Der HTTP-Advisor wird für alle
Server ausgeführt, die Port 80 von ClusterA zugeordnet sind.dscontrol advisor start angepasster_Advisor 80
Dieser Befehl startet
den Advisor angepasster_Advisor am Port 80 von
ClusterB und ClusterC. Der angepasste Advisor
wird für alle Server ausgeführt, die
Port 80 von ClusterB und ClusterC zugeordnet sind.
(Weitere Informationen zu angepassten Advisor finden Sie
im Abschnitt Angepassten (anpassbaren) Advisor erstellen.)
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.
dscontrol advisor stop angepasster_Advisor ClusterB:80
dscontrol advisor stop angepasster_Advisor 80
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.
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.
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.
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.
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
Verwenden Sie den Advisor TLS, wenn Sie feststellen, dass der Advisor SSL die Server als inaktiv kennzeichnet, obwohl Sie wissen, dass der Server weiterhin aktiv ist, und wenn Nachrichten mit dem Hinweis "No ciphers found" angezeigt werden.
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:
server set Cluster:Port:Server advisorrequest "head / http/1.0"
server set Cluster:Port:Server advisorresponse "HTTP 200 OK"
dscontrol server set Cluster:Port:Server
advisorrequest "\"head / http/1.0\""
dscontrol server set Cluster:Port:Server advisorresponse "\"HTTP 200 OK\""
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
Weitere Informationen hierzu finden Sie im Abschnitt dscontrol server — Server konfigurieren.
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.
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.
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:
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.
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.
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.
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:
Auf AIX-, HP-UX-, Linux- und Solaris-Systemen ist die Syntax ähnlich.
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.
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.
Basisklassenmethoden sind:
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.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
<Installationsstammverzeichnis>ibm\edge\lb\servers\lib\CustomAdvisors
Die Programmliste für eine Beispiel-Advisor finden Sie im Abschnitt Beispieladvisor. Nach der Installation befindet sich dieser Beispiel-Advisor im folgenden Verzeichnis:
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.
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.
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.
Der Agent Metric Server muss auf allen Servern installiert und ausgeführt werden, die am Lastausgleich teilnehmen.
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.
Port ist hier der ausgewählte RMI-Port für alle Metric-Server-Agenten. Der in der Datei metricserver.cmd festgelegte Standard-RMI-Port ist 10004.
Systemmetrik ist hier der Name des Scripts (auf dem Back-End-Server), das für jeden Server, der unter dem angegebenen Cluster (oder Sitenamen) in der Konfiguration enthalten ist, ausgeführt werden soll. Für den Kunden stehen die beiden Scripts cpuload und memload bereit. Sie können auch angepasste Scripts für Systemmetriken erstellen. Das Script enthält einen Befehl, der einen numerischen Wert im Bereich von 0 - 100 oder, bei inaktivem Server, den Wert -1 zurückgeben sollte. Dieser numerische Wert sollte eine Lastmessung und keinen Verfügbarkeitswert darstellen.
Einschränkung: Wenn der Name Ihres Scripts für Systemmetriken auf der Windows-Plattform eine andere Erweiterung als .exe hat, müssen Sie den vollständigen Namen der Datei (z. B. "meinsystemscript.bat") angeben. Dies ergibt sich aus einer Java-Einschränkung.
Optional können Kunden ihre eigenen angepassten Scriptdateien für Metriken schreiben, in denen definiert ist, welchen Befehl Metric Server auf den Servermaschinen absetzen soll. Stellen Sie sicher, dass alle angepassten Scripts ausführbar sind und sich im folgenden Verzeichnis befinden:
Angepasste Scripts müssen einen numerischen Lastwert im Bereich von 0 bis 100 zurückgeben.
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.
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:
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.