Erweiterte Funktionen für Cisco CSS Controller und Nortel Alteon Controller

Dieses Kapitel enthält die folgenden Abschnitte:

Anmerkung:
In diesem Kapitel ist xxxcontrol durch ccocontrol für Cisco CSS Controller bzw. nalcontrol für Nortel Alteon Controller zu ersetzen.

Verknüpfung

Cisco CSS Controller oder Nortel Alteon Controller kann sich auf derselben Maschine befinden wie ein Server, dessen Anforderungen verteilt werden. Dies wird als das Verknüpfen eines Servers bezeichnet. Es sind keine zusätzlichen Konfigurationsschritte erforderlich.

Anmerkung:
In Zeiten hohen Datenverkehrs konkurriert ein verknüpfter Server mit Load Balancer um Ressourcen. Sind jedoch keine überlasteten Maschinen vorhanden, kann mit einem verknüpften Server die Gesamtzahl der Maschinen reduziert werden, die für das Einrichten eines Standortes mit Lastausgleich erforderlich sind.

Hohe Verfügbarkeit

Die Funktion der hohen Verfügbarkeit ist jetzt für Cisco CSS Controller und Nortel Alteon Controller verfügbar.

Zur Verbesserung der Fehlertoleranz des Controllers stellt die Funktion für hohe Verfügbarkeit Folgendes bereit:

Konfiguration

Die vollständige Syntax für den Befehl xxxcontrol highavailability finden Sie in den Abschnitten ccocontrol highavailability — Hohe Verfügbarkeit steuern und nalcontrol highavailability — Hohe Verfügbarkeit steuern.

Gehen Sie wie folgt vor, um die hohe Verfügbarkeit für den Controller zu konfigurieren:

  1. Starten Sie auf beiden Controllermaschinen den Controllerserver.
  2. Konfigurieren Sie alle Controller identisch.
  3. Konfigurieren Sie für den lokalen Controller wie folgt die Rolle für hohe Verfügbarkeit, die Adresse und die Partneradresse:
    xxxcontrol highavailability add address 10.10.10.10 
    partneraddress 10.10.10.20 port 143 role primary
  4. Konfigurieren Sie für den Partnercontroller wie folgt die Rolle für hohe Verfügbarkeit, die Adresse und die Partneradresse:
    xxxcontrol highavailability add address 10.10.10.20 
    partneraddress 10.10.10.10 port 143 role secondary
    Die Parameter address und partneraddress sind auf der primären und der sekundären Maschine jeweils ausgetauscht.
  5. Konfigurieren Sie optional auf dem lokalen und dem Partnercontroller Parameter für hohe Verfügbarkeit. Beispiel:
    xxxcontrol highavailability set beatinterval 1000
  6. Konfigurieren Sie bei Bedarf wie folgt Erreichbarkeitsziele auf dem lokalen und dem Partnercontroller:
    xxxcontrol highavailability usereach 10.20.20.20
    Auf dem lokalen und dem Partnercontroller muss dieselbe Anzahl von Erreichbarkeitszielen konfiguriert werden.
  7. Starten Sie die Komponente mit hoher Verfügbarkeit und definieren Sie auf dem lokalen und dem Partnercontroller wie folgt eine Wiederherstellungsstrategie:
    xxxcontrol highavailability start auto
  8. Optional können Sie auf dem lokalen und Partnercontroller wie folgt Informationen zur hohen Verfügbarkeit anzeigen:
    xxxcontrol highavailability report
  9. Geben Sie optional auf dem Bereitschaftscontroller wie folgt takeover an, wenn dieser die Aufgaben des aktiven Controllers übernehmen soll:
    xxxcontrol highavailability takeover
    Dies ist nur für Wartungszwecke erforderlich.
Anmerkungen:
  1. Wenn Sie einen Controller ohne hohe Verfügbarkeit konfigurieren möchten, setzen Sie keine Befehle zur hohen Verfügbarkeit ab.
  2. Falls Sie eine Konfiguration mit hoher Verfügbarkeit, die zwei Controller umfasst, in eine Konfiguration mit nur einem Controller ändern möchten, stoppen Sie zunächst auf dem Bereitschaftscontroller die hohe Verfügbarkeit. Bei Bedarf können Sie dann auch auf dem aktiven Controller die hohe Verfügbarkeit stoppen.
  3. In einer Konfiguration mit hoher Verfügbarkeit, die zwei Controller umfasst, kann es zu unerwarteten Ergebnissen kommen, wenn die Controllereigenschaften (z. B. switchconsultantid, switch address usw.) auf den Switches nicht übereinstimmen. Unerwartete Ergebnisse können sich auch einstellen, wenn die Controllereigenschaften für hohe Verfügbarkeit nicht identisch sind, z. B. port, role, reach targets, beatinterval, takeoverinterval und recovery strategy.

Ausfallerkennung

Neben dem Verlust der Konnektivität zwischen aktivem Controller und Bereitschaftscontroller, der durch die Überwachungssignale festgestellt wird, kann jetzt auch die Erreichbarkeit erkannt werden.

Wenn Sie die hohe Verfügbarkeit für Controller konfigurieren, können Sie eine Liste von Hosts angeben, die für jeden der Controller erreichbar sein müssen. Für jedes Teilnetz, das Ihre Controllermaschine benutzt, muss mindestens ein Host angegeben sein. Die Hosts können Router, IP-Server oder andere Arten von Hosts sein.

Die Erreichbarkeit von Hosts wird über Pingsignale des Advisors reach abgefragt. Es findet eine Übernahme statt, wenn keine Überwachungssignalnachrichten durchkommen oder wenn die Erreichbarkeitskriterien eher vom Bereitschaftscontroller als vom primären Controller erfüllt werden. Damit die Entscheidung anhand aller verfügbaren Informationen getroffen wird, tauschen der aktive Controller und der Bereitschaftscontroller regelmäßig Informationen über ihre Erreichbarkeit aus. Die Controller vergleichen dann ihre Erreichbarkeitsdaten mit denen des Partners und entscheiden, welcher Controller der aktive Controller sein soll.

Wiederherstellungsstrategie

Die beiden Controllermaschinen werden nach ihrer Rolle als primärer und sekundärer Controller konfiguriert. Beim Systemstart tauschen die Controller Informationen aus, bis beide Maschinen synchronisiert sind. Anschließend wechselt der primäre Controller in den aktiven Status und beginnt mit der Berechnung von Wertigkeiten und dem Aktualisieren des Switch. Die sekundäre Maschine wechselt in den Bereitschaftsstatus und überwacht die Verfügbarkeit der primären Maschine.

Stellt die Bereitschaftsmaschine an einem beliebigen Punkt fest, dass die aktive Maschine ausgefallen ist, übernimmt sie die Lastausgleichsfunktionen der (ausgefallenen) aktiven Maschine und wird selbst zur aktiven Maschine. Ist die primäre Maschine wieder betriebsbereit, ermitteln die beiden Maschinen anhand der konfigurierten Wiederherstellungsstrategie, welcher Controller der aktive Controller sein soll.

Es gibt zwei Arten von Wiederherstellungsstrategien:

Automatische Wiederherstellung

Sobald der primäre Controller wieder betriebsbereit ist, wechselt er in den aktiven Status, berechnet und aktualisiert Wertigkeiten etc. Die sekundäre Maschine wechselt in den Bereitschaftsstatus, wenn die primäre Maschine wieder aktiv ist.

Manuelle Wiederherstellung

Der aktive sekundäre Controller bleibt aktiv, wenn der primäre Controller wieder betriebsbereit ist.

Der primäre Controller wechselt in den Bereitschaftsstatus und kann nur manuell in den aktiven Status versetzt werden.

Der Parameter für die Strategie muss für beide Maschinen auf denselben Wert gesetzt werden.

Beispiele

Beispiele zur hohen Verfügbarkeit für Cisco CSS Controller finden Sie im Abschnitt Beispiele.

Beispiele zur hohen Verfügbarkeit für Nortel Alteon Controller finden Sie im Abschnitt Beispiele.

Lastausgleich mit Load Balancer optimieren

Die Controllerfunktion 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.

Gewichtung von Metrikinformationen

Der Controller kann in seine Gewichtungsentscheidung alle oder einige der nachfolgend genannten summierten Metriken einfließen lassen:

Die Standardmetriken sind activeconn und connrate.

Sie können die relative Gewichtung der Metrikwerte ändern. Die Proportionen sind vergleichbar mit Prozentsätzen. Die Summe der relativen Proportionen muss 100 % ergeben. Standardmäßig werden die Metriken "Aktive Verbindungen" und "Neue Verbindungen" in der Gewichtung 50:50 verwendet. In Ihrer Umgebung müssen Sie eventuell andere Metrikproportionen ausprobieren, um die Kombination mit der besten Leistung zu finden.

Gehen Sie wie folgt vor, um die Proportionswerte festzulegen:

Für Cisco CSS Controller
ccocontrol ownercontent metrics Metrikname1 Proportion1 Metrikname2 Proportion2
Für Nortel Alteon Controller
nalcontrol service metrics Metrikname1 Proportion1 Metrikname2 Proportion2

Wertigkeiten

Die Wertigkeiten werden ausgehend von Reaktionszeit und Verfügbarkeit der Anwendung, vom Feedback des Advisors und vom Feedback eines Systemüberwachungsprogramms wie Metric Server festgelegt. Falls Sie Wertigkeiten manuell festlegen möchten, geben Sie für den Server die Option fixedweight an. Eine Beschreibung der Option fixedweight finden Sie im Abschnitt Feste Wertigkeiten vom Controller.

Wertigkeiten gelten für alle Server, die einen Service anbieten. Für jeden einzelnen Service werden die Anforderungen entsprechend ihrer relativen Wertigkeit auf die 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.

Stellt ein Advisor fest, dass ein Server heruntergefahren wurde, wird seine Wertigkeit auf -1 gesetzt. Für Cisco CSS Controller und Nortel Alteon Controller: Der Switch wird informiert, dass der Server nicht verfügbar ist, und hört auf, dem Server Verbindungen zuzuordnen.

Feste Wertigkeiten vom Controller

Ohne den Controller können Advisor nicht ausgeführt werden und nicht erkennen, ob ein Server inaktiv ist. Wenn Sie die Advisor ausführen möchten, der Controller jedoch nicht die von Ihnen für einen bestimmten Server festgelegte Wertigkeit aktualisieren soll, verwenden Sie für Cisco CSS Controller den Befehl ccocontrol service und für Nortel Alteon Controller den Befehl nalcontrol server mit der Option fixedweight.

Mit dem Befehl fixedweight können Sie die Wertigkeit auf den gewünschten Wert setzen. Der Wert für die Serverwertigkeit bleibt während der Ausführung des Controllers unverändert erhalten, bis Sie einen weiteren Befehl absetzen, bei dem fixedweight auf no gesetzt ist.

Ruhezeiten für Wertigkeitsberechnung

Zur Optimierung der Gesamtleistung können Sie festlegen, wie oft Metriken zusammengestellt werden sollen.

Die Consultant-Ruhezeit gibt an, wie oft der Consultant die Serverwertigkeiten aktualisiert. Eine zu kurze Consultant-Ruhezeit kann sich negativ auf den Durchsatz auswirken, da der Consultant den Switch permanent unterbricht. Eine zu lange Consultant-Ruhezeit kann bedeuten, dass der Lastausgleich des Switch nicht auf genauen, auf dem neuesten Stand befindlichen Informationen basiert.

Eine Consultant-Ruhezeit von 1 Sekunde könnten Sie wie folgt festlegen:

xxxcontrol consultant set Consultant-ID sleeptime Intervall

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, die einen Service anbieten, über der Sensitivitätsschwelle liegt, werden die von Load Balancer für die Verteilung der Verbindungen verwendeten Wertigkeiten aktualisiert. 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 werden die von Load Balancer verwendeten Wertigkeiten nicht aktualisiert, da die prozentuale Änderung nicht über dem Schwellenwert liegt. Ändert sich die Gesamtwertigkeit jedoch von 100 % auf 106 %, werden die Wertigkeiten aktualisiert. Wenn Sie die Consultant-Sensitivitätsschwelle auf einen anderen Wert als den Standardwert setzen möchten, geben Sie den folgenden Befehl ein:

  xxxcontrol consultant set Consultant-ID sensitivity geänderterProzentsat

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

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.

Anmerkung:
Eine detaillierte Liste der Advisor finden Sie im Abschnitt Liste der Advisor.

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 Consultant-Funktion, die ihn im Consultant-Bericht angibt. Der Consultant addiert anschließend die Wertigkeiten für alle Quellen entsprechend ihren Proportionen und sendet diese Werte an den Switch. Der Switch 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 Consultant. Stellt der Advisor fest, dass ein Server inaktiv ist, gibt er den speziellen Lastwert -1 zurück, um dem Switch mitzuteilen, dass der Server heruntergefahren ist. Der Switch leitet daraufhin keine Verbindungen an diesen Server weiter, solange dieser inaktiv ist.

Advisor-Ruhezeiten

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

Die Advisor-Ruhezeit legt fest, wie oft ein Advisor den Status der Server an dem von ihm überwachten Port abfragt und die Ergebnisse dann an den Consultant übergibt. Eine zu kurze Advisor-Ruhezeit kann sich negativ auf den Durchsatz auswirken, da der Advisor die Server permanent unterbricht. Eine zu lange Advisor-Ruhezeit kann bedeuten, dass die Gewichtungsentscheidungen des Consultant nicht auf genauen, auf dem neuesten Stand befindlichen Informationen basieren.

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

xxxcontrol metriccollector set Consultant-ID:HTTP sleeptime 3

Serververbindungs- und -empfangszeitlimit des Advisors

Sie können festlegen, in welcher Zeit ein Advisor feststellen soll, dass ein bestimmter Port auf einem Server oder für einen Service ausgefallen ist. 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 die Ruhezeit für Advisor und Consultant auf den kleinsten Wert (eine Sekunde) setzen.

Anmerkung:
Falls das Datenverkehrsaufkommen in Ihrer Umgebung mäßig bis hoch ist und die Reaktionszeit des Servers ansteigt, legen Sie keine zu niedrigen Werte für timeoutconnect und timeoutreceive fest. Andernfalls könnte der Advisor einen ausgelasteten Server vorschnell als ausgefallenen Server markieren.

Wenn Sie timeoutconnect für der HTTP-Advisor beispielsweise auf 9 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:

xxxcontrol metriccollector set Consultant-ID:HTTP timeoutconnect 9

Der Standardwert für das Verbindungs- und Empfangszeitlimit liegt beim Dreifachen des Wertes, der für die Ruhezeit 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 als inaktiv, wenn die Abfrage nach der festgelegten Anzahl Wiederholungen und einem weiteren Versuch nicht beantwortet wird. Ist keine Anzahl Wiederholungen festgelegt, wird standardmäßig von null Wiederholungen ausgegangen.

Für den Cisco CSS Controller können Sie den Wert retry mit dem Befehl ccocontrol ownercontent set setzen. Weitere Informationen hierzu finden Sie im Abschnitt ccocontrol ownercontent — Eignernamen und Inhaltsregel steuern.

Für den Nortel Alteon Controller können Sie den Wert retry mit dem Befehl nalcontrol service set setzen. Weitere Informationen hierzu finden Sie im Abschnitt nalcontrol service — Service konfigurieren.

Angepassten (anpassbaren) Advisor erstellen

Anmerkung:
In diesem Abschnitt wird Server als generischer Begriff verwendet und bezeichnet für Cisco CSS Controller einen Service und für Nortel Alteon Controller einen Server.

Der angepasste (anpassbare) Advisor ist ein kurzer Java™-Code, den Sie als Klassendatei bereitstellen, die vom Basiscode aufgerufen wird. Der Basiscode stellt alle Verwaltungsservices bereit. Dazu gehören unter anderem:

Er übergibt auch die Ergebnisse an den Consultant. 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 sie 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 Consultant.

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 Consultant. 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 Consultant. 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. Für die Controller wird ein Beispiel für einen angepassten Advisor, ADV_ctlrsample.java, geliefert. Nach der Installation von Load Balancer finden Sie den Beispielcode im folgenden Verzeichnis:

Anmerkung:
Wenn Sie einen angepassten Advisor zum Cisco CSS Controller oder Nortel Alteon Controller hinzufügen, müssen Sie ccoserver oder nalserver stoppen und dann erneut starten (verwenden Sie auf Windows-Systemen "Dienste"), um den Java-Prozess zu veranlassen, die neuen angepassten Advisor-Klassendateien zu lesen. Die angepassten Advisor-Klassendateien werden nur beim Systemstart geladen.

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

Ein Kompilierungsbefehl für die Windows-Plattform könnte wie folgt aussehen:

Installationsverzeichnis/java/bin/javac -classpath
    <Installationsstammverzeichnis>ibm\edge\lb\servers\lib\ibmlb.jar ADV_pam.java

Für diesen Befehl gilt Folgendes:

Die Ausgabe der Kompilierung ist eine Klassendatei, zum Beispiel:

ADV_pam.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:

Starten Sie den Consultant und setzen Sie dann zum Starten des angepassten Advisors den folgenden Befehl ab:

Für Cisco CSS Controller
ccocontrol ownercontent metrics Consultant-ID:ID_für_Eignerangaben pam 100
Für Nortel Alteon Controller
nalcontrol service metrics Consultant-ID:Service-ID pam 100

Für diesen Befehl gilt Folgendes:

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 der Arbeitslasten an den Consultant, die für den Wertigkeitsalgorithmus des Consultant 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

Die Controller suchen zunächst in der bereitgestellten Liste nach nativen Advisor. Können Sie dort einen gegebenen Advisor nicht finden, durchsuchen Sie die Liste der angepassten Advisor.

Benennung und Pfad

Beispiel-Advisor

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

Metric Server

Metric Server gibt Load Balancer Informationen zur Serverauslastung. Diese Informationen werden in Form systemspezifischer Metriken für den Serverzustand bereitgestellt. Der Consultant 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 für Cisco CSS Controller auch in den Servicebericht und für Nortel Alteon Controller in den Serverbericht gestellt.

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 die Controller konfigurieren.

Wenn Metric Server für eine vom lokalen Host abweichende Adresse ausgeführt werden soll, editieren Sie die Datei metricserver auf der am Lastausgleich beteiligten Servermaschine. 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 Folgendes zur Datei metricserver hinzu: hostname andere_Adresse.

Auf Windows-Systemen: Geben Sie in Microsoft Stack einen Aliasnamen für andere_Adresse an. Informationen zum Angeben eines Aliasnamens für eine Adresse im Microsoft Stack, finden Sie im Abschnitt über Aliasing einer Adresse im Microsoft Stack für einen Metric Server.

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, können die Controller die Kapazitätsinformationen von WLM akzeptieren und die Informationen für den Lastausgleich verwenden. Mit dem WLM-Advisor öffnen die Controller regelmäßig Verbindungen über den WLM-Port der einzelnen Server in der Consultant-Hosttabelle und akzeptieren die zurückgegebenen ganzzahligen Kapazitätswerte. Da diese ganzen Zahlen die noch verfügbare Kapazität darstellen und die Controller 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 beispielsweise beide einen akzeptablen Zustand eines Servers an). Es gibt mehrere wichtige Unterschiede zwischen dem WLM-Advisor und anderen Advisor des Controllers:

  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 Controllers gestartet wurde. Der Standard-WLM-Port ist 10007.
  2. 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.

Binäre Protokolle für die Analyse von Serverstatistiken verwenden

Mit dem Feature für Binärprotokollierung können Serverinformationen in Binärdateien gespeichert werden. Diese Dateien können dann verarbeitet werden, um die Serverinformationen zu analysieren, die über einen bestimmten Zeitraum gesammelt wurden.

Die folgenden Informationen werden für jeden in der Konfiguration definierten Server in dem binären Protokoll gespeichert:

Zum Protokollieren von Informationen in den binären Protokollen muss der Consultant aktiv sein.

Verwenden Sie zum Konfigurieren der Binärprotokollierung die Befehlsgruppe xxxcontrol consultant binarylog.

Mit der Option "start" wird die Protokollierung von Serverinformationen in binären Protokollen im Protokollverzeichnis gestartet. Ein Protokoll wird zu Beginn jeder Stunde mit dem Datum und der Uhrzeit als Name der Datei erstellt.

Mit der Option "stop" wird die Protokollierung von Serverinformationen in binären Protokollen gestoppt. Standardmäßig ist der Protokolldienst gestoppt.

Mit der Option "set interval" wird gesteuert, wie oft Informationen in die Protokolle geschrieben werden. Der Consultant sendet in jedem Consultant-Intervall Serverdaten an den Protokollserver. Die Daten werden nur dann in die Protokolle geschrieben, wenn seit dem Schreiben des letzten Protokolleintrags die für das Protokollierungsintervall angegebene Zeit in Sekunden verstrichen ist. Standardmäßig wird das Protokollierungsintervall auf 60 Sekunden gesetzt.

Zwischen den Einstellungen für das Consultant-Intervall und das Protokollierungsintervall gibt es eine gewisse Interaktion. Da dem Protokollserver Informationen nicht schneller zur Verfügung gestellt werden, als dies im Consultant-Intervall (in Sekunden) angegeben ist, wird durch Angabe eines Protokollierungsintervalls, das kleiner als das Consultant-Intervall ist, das Protokollierungsintervall de facto auf denselben Wert wie das Consultant-Intervall gesetzt.

Mit dieser Protokollierungstechnik können Sie Serverinformationen detaillierter erfassen. Sie können alle vom Consultant festgestellten Änderungen der Serverinformationen für die Berechnung von Serverwertigkeiten erfassen. Dieser Informationsumfang ist jedoch wahrscheinlich nicht erforderlich, um die Serverauslastung und Trends zu analysieren. Werden Serverinformationen alle 60 Sekunden protokolliert, erhalten Sie Momentaufnahmen von Serverinformationen in Abhängigkeit vom zeitlichen Verlauf. Wird das Protokollierungsintervall auf einen sehr niedrigen Wert gesetzt, kann dies zu großen Datenmengen führen.

Mit der Option "set retention" wird gesteuert, wie lange Protokolldateien aufbewahrt werden. Protokolldateien, die älter als die angegebene Verweildauer (Stunden) sind, werden von dem Protokollserver gelöscht. Die geschieht nur, wenn der Protokollserver vom Consultant aufgerufen wird. Wenn Sie den Consultant stoppen, werden alte Protokolldateien demzufolge nicht gelöscht.

Im folgenden Verzeichnis stehen ein Beispiel-Java-Programm und eine Beispielbefehlsdatei zur Verfügung:

Dieses Beispiel zeigt, wie alle Informationen aus den Protokolldateien abgerufen und angezeigt werden können. Es kann für jede Art von Datenanalyse angepasst werden.

Beispiel für die Verwendung des bereitgestellten Scripts und Programms:

xxxlogreport 2002/05/01 8:00 2002/05/01 17:00

Dieser Befehl liefert einen Bericht mit den Serverdaten des Controllers vom 1. Mai 2002 in der Zeit von 8.00 bis 17.00 Uhr.

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 müssen Sie die Dateien in das folgende Verzeichnis kopieren und dann entsprechend den Anweisungen im Script umbenennen:

Die folgenden Beispielscripts stehen zur Verfügung, bei denen die Angabe xxx durch cco für Cisco CSS Controller und nal für Nortel Alteon Controller zu ersetzen ist: