Dieses Kapitel enthält die folgenden Abschnitte:
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.
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:
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:
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role secondaryDie Parameter address und partneraddress sind auf der primären und der sekundären Maschine jeweils ausgetauscht.
xxxcontrol highavailability set beatinterval 1000
xxxcontrol highavailability usereach 10.20.20.20Auf dem lokalen und dem Partnercontroller muss dieselbe Anzahl von Erreichbarkeitszielen konfiguriert werden.
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeoverDies ist nur für Wartungszwecke erforderlich.
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.
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:
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.
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 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.
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.
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:
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.
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.
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
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 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.
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.
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
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.
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.
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.
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:
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.
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:
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:
Starten Sie den Consultant und setzen Sie dann zum Starten des angepassten Advisors den folgenden Befehl ab:
Für diesen Befehl gilt Folgendes:
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.
Basisklassenmethoden sind:
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.
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 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.
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 die Controller konfigurieren.
Fügen Sie für Nortel Alteon Controller einen Switch-Consultant und dann einen Service hinzu.
Metrikname steht hier für den Namen des Metric-Server-Scripts.
Das Script für Systemmetriken befindet sich auf dem Back-End-Server und wird für jeden Server, der unter den aufgeführten Eignerangaben oder dem angegebenen Service in der Konfiguration enthalten ist, ausgeführt. Die beiden Scripts cpuload und memload stehen für Sie bereit. Sie können aber auch angepasste Scripts für Systemmetriken erstellen. Das Script enthält einen Befehl, der einen numerischen Wert zurückgeben muss. Dieser numerische Wert stellt eine Lastmessung und keinen Verfügbarkeitswert dar.
Einschränkung: Wenn der Name Ihres Scripts für Systemmetriken auf Windows-Systemen eine andere Erweiterung als .exe hat, müssen Sie den vollständigen Namen der Datei (z. B. meinsystemscript.bat) angeben. Dies ist eine Java-Codeeinschränkung.
Optional können Sie 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:
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.
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:
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.
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: