Das vorliegende Kapitel erläutert die Verwendung und Verwaltung von Load Balancer und ist in folgende Abschnitte untergliedert:
Load Balancer bietet zwei Möglichkeiten an, die Konfigurationsprogramme auf einer anderen Maschine als der Maschine mit Load Balancer auszuführen. Für die Kommunikation zwischen den Konfigurationsprogrammen (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) und dem Server (dsserver, cbrserver usw.) bestehen die beiden folgenden Möglichkeiten:
Der Vorteil der Fernverwaltung mit RMI besteht darin, dass sie schneller als die webgestützte Verwaltung ist.
Die webgestützte Verwaltung hat den Vorteil, dass sie eine sichere Fernverwaltung mit Authentifizierung ist und auch bei Vorhandensein einer Firewall die Kommunikation mit der Load-Balancer-Maschine gewährleistet ist. Diese Verwaltungsmethode erfordert außerdem nicht die Installation und Verwendung von Authentifizierungsschlüsseln (lbkeys) auf der fernen Clientmaschine, die mit der Load-Balancer-Maschine kommuniziert.
Bei Verwendung von RMI lautet der Befehl zum Herstellen einer Verbindung zu einer Load-Balancer-Maschine für die Fernverwaltung dscontrol host:ferner_Host.
Stammt der RMI-Aufruf von einer anderen Maschine als der lokalen Maschine, muss eine Authentifizierung mit öffentlichem/privatem Schlüssel stattfinden, bevor der Konfigurationsbefehl akzeptiert wird.
Die Kommunikation zwischen den Steuerprogrammen, die auf derselben Maschine wie die Komponentenserver ausgeführt werden, wird nicht authentifiziert.
Verwenden Sie den folgenden Befehl, um öffentliche und private Schlüssel für die ferne Authentifizierung zu generieren:
lbkeys [create|delete]
Dieser Befehl muss auf derselben Maschine wie Load Balancer ausgeführt werden.
Bei Verwendung der Option create wird ein privater Schlüssel im Verzeichnis servers\key erstellt:
Das Script erstellt außerdem für jede Load-Balancer-Komponente öffentliche Schlüssel im Verzeichnis admin\keys:
Der Dateiname für den öffentlichen Schlüssel ist Komponente-Serveradresse-RMI-Port. Diese öffentlichen Schlüssel müssen anschließend zu den fernen Clients transportiert und in das Verwaltungsverzeichnis für Schlüssel gestellt werden.
Auf einer Load-Balancer-Maschine mit dem Hostnamen bzw. der Adresse 10.0.0.25, die für jede Komponente den Standard-RMI-Port verwendet, generiert der Befehl lbkeys create die folgenden Dateien:
Die Verwaltungsdateigruppe wurde auf einer anderen Maschine installiert. Die Dateien der öffentlichen Schlüssel müssen auf der fernen Clientmaschine in das folgende Verzeichnis gestellt werden:
Jetzt ist der ferne Client berechtigt, Load Balancer auf der Maschine 10.0.0.25 zu konfigurieren.
Dieselben Schlüssel müssen Sie auf allen fernen Clients verwenden, die berechtigt sein sollen, Load Balancer auf der Maschine 10.0.0.25 zu konfigurieren.
Würde der Befehl lbkeys create erneut ausgeführt, hätte dies die Generierung einer neuen Gruppe von öffentlichen/privaten Schlüsseln zur Folge. Dies würde bedeuten, dass alle fernen Clients, die unter Verwendung der vorherigen Schlüssel die Herstellung einer Verbindung versuchen, nicht berechtigt wären. Der neue Schlüssel müsste in das korrekte Verzeichnis auf den Clients gestellt werden, die erneut berechtigt werden sollen.
Mit dem Befehl lbkeys delete werden die privaten und öffentlichen Schlüssel von der Servermaschine gelöscht. Werden diese Schlüssel gelöscht, sind keine fernen Clients mehr berechtigt, eine Verbindung zu den Servern herzustellen.
Für lbkeys create und lbkeys delete gibt es die Option force. Die Option force unterdrückt die Eingabeaufforderungen, die von Ihnen eine Bestätigung für das Überschreiben oder Löschen der vorhandenen Schlüssel anfordern.
Wenn Sie eine RMI-Verbindung hergestellt haben, können Sie von einer Eingabeaufforderung aus über die Befehle dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol, dswizard, cbrwizard und sswizard mit den Konfigurationsprogrammen kommunizieren. Sie können Load Balancer auch über die grafische Benutzerschnittstelle (GUI) konfigurieren. Geben Sie dazu an einer Eingabeaufforderung lbadmin ein.
Für die webgestützte Verwaltung ist auf der Clientmaschine, die die Fernverwaltung durchführt, Folgendes erforderlich:
Auf der Hostmaschine, auf die Sie zugreifen, um die webgestützte Fernverwaltung durchzuführen, ist Folgendes erforderlich:
Windows:
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\PROGRA~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\PROGRA~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\PROGRA~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\PROGRA~1\IBM\edge\lb\admin\* Pass /documentation/Sprache/* C:\PROGRA~1\IBM\edge\lb\documentation\Sprache\*Sprache steht hier für das Sprachenunterverzeichnis (z. B. en_US).
AIX, HP-UX, Linux und Solaris:
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/Sprache/* /opt/ibm/edge/lb/documentation/Sprache/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Wenn Sie die webgestützte Verwaltung ausführen möchten, müssen Sie sie auf der Hostmaschine mit Load Balancer starten. Setzen Sie dazu an der Eingabeaufforderung der Hostmaschine den Befehl lbwebaccess ab.
Sie benötigen die Benutzer-ID und das Kennwort für die Hostmaschine, auf die Sie fern zugreifen. Diese Angaben stimmen mit der Benutzer-ID und dem Kennwort für die Verwaltung von Caching Proxy überein.
Greifen Sie im Webbrowser auf den folgenden URL des fernen Standortes zu, um die webgestützte Verwaltung von Load Balancer aufzurufen:
http://Hostname/lb-admin/lbadmin.htmlHostname
ist der Name der Maschine, auf die Sie zugreifen, um mit Load Balancer zu kommunizieren.
Wenn die Webseite geladen ist, erscheint im Browserfenster die GUI von Load Balancer, so dass Sie die webgestützte Fernverwaltung durchführen können.
Von der Load-Balancer-GUI aus können Sie auch Steuerbefehle für die Konfiguration absetzen. Gehen Sie dazu wie folgt vor:
Konfiguration fern aktualisieren
Wenn bei der fernen webgestützten Verwaltung mehrere Administratoren die Load-Balancer-Konfiguration von verschiedenen Standorten aus aktualisieren, müssen Sie die Konfiguration aktualisieren, um z. B. den von einem anderen Administrator hinzugefügten (oder gelöschten) Cluster, Port oder Server zu sehen. Die GUI für die webgestützte Fernverwaltung bietet die Funktionen Konfiguration aktualisieren und Alle Konfigurationen aktualisieren an.
Gehen Sie zum Aktualisieren der Konfiguration auf der webgestützten GUI wie folgt vor:
Load Balancer sendet Einträge an ein Serverprotokoll, ein Managerprotokoll, an das Protokoll eines Metriküberwachungsprogramms (protokollbezogene Kommunikation mit Metric-Server-Agenten) und an das Protokoll jedes von Ihnen verwendeten Advisors.
Sie können die Protokollstufe festlegen, um den Umfang der Nachrichten zu definieren, die in das Protokoll geschrieben werden. Bei Stufe 0 werden Fehler protokolliert. Load Balancer protokolliert außerdem Header und Datensätze von Ereignissen, die nur einmal eintreten. (Beim Starten eines Advisors wird beispielsweise eine Nachricht in das Managerprotokoll geschrieben.) Bei Stufe 1 werden weitere Informationen aufgenommen. Bis Stufe 5 nimmt die Ausführlichkeit kontinuierlich zu. Bei Stufe 5 werden alle generierten Nachrichten aufgenommen, damit sie im Falle eines Fehlers für das Debugging verwendet werden können. Die Standardeinstellung für das Managerprotokoll, das Protokoll der Advisor, das Serverprotokoll sowie das Protokoll der Subagenten ist 1.
Zudem können Sie die maximale Größe eines Protokolls festlegen. Wenn Sie eine maximale Größe für die Protokolldatei festlegen, wird die Datei wiederverwendet, d. h., wenn die Datei die angegebene Größe erreicht hat, werden alle weiteren Einträge wieder an den Anfang der Datei geschrieben und die dort befindlichen Einträge überschrieben. Sie können für die Protokollgröße keinen Wert angeben, der kleiner als der aktuelle Wert für die Protokollgröße ist. Protokolleinträge werden mit einer Zeitmarke versehen, so dass Sie erkennen können, in welcher Reihenfolge sie geschrieben wurden.
Je höher Sie die Protokollstufe setzen, desto sorgfältiger müssen Sie die Protokollgröße auswählen, da die Protokolldatei sehr schnell voll ist, wenn Sie eine Protokollierung auf einer höheren Stufe wählen. Bei Stufe 0 ist es wahrscheinlich sicher, die Standardprotokollgröße von 1 MB zu verwenden. Ab Stufe 3 sollten Sie die Größe jedoch begrenzen. Bedenken Sie aber, dass bei einem zu kleinen Wert die Protokollierung nicht mehr sinnvoll ist.
Die von Load Balancer generierten Protokolle werden standardmäßig im Unterverzeichnis logs des Installationsverzeichnisses von Load Balancer gespeichert. Wenn Sie diesen Pfad ändern möchten, setzen Sie die Variable lb_logdir im dsserver-Script entsprechend.
AIX-, HP-UX-, Linux- und Solaris-Systeme: Sie finden das dsserver-Script im Verzeichnis /usr/bin. In diesem Script ist die Variable lb_logdir auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
LB_LOGDIR=/pfad/zu/meinen/protokollen/
Windows-Systeme: Sie finden die dsserver-Datei im Verzeichnis <Installationsstammverzeichnis>ibm\edge\lb\bin. In der dsserver-Datei ist die Variable lb_logdir auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
set LB_LOGDIR=c:\pfad\zu\meinen\protokollen\
Für alle Betriebssysteme ist sicherzustellen, dass sich rechts und links vom Gleichheitszeichen keine Leerzeichen befinden und dass der Pfad mit einem Schrägstrich endet ("/" bzw. "\").
Für die Binärprotokollierung von Load Balancer wird dasselbe Verzeichnis (log) wie für die übrigen Protokolldateien verwendet. Weitere Informationen finden Sie im Abschnitt Binäre Protokolle für die Analyse von Serverstatistiken verwenden.
Sie können die Protokollstufe festlegen, um den Umfang der Nachrichten zu definieren, die in das Protokoll geschrieben werden. Bei Stufe 0 werden Fehler protokolliert. Load Balancer protokolliert außerdem Header und Datensätze von Ereignissen, die nur einmal eintreten. (Beim Starten eines Advisors wird beispielsweise eine Nachricht in das Consultant-Protokoll geschrieben.) Bei Stufe 1 werden weitere Informationen aufgenommen. Bis Stufe 5 nimmt die Ausführlichkeit kontinuierlich zu. Bei Stufe 5 werden alle generierten Nachrichten aufgenommen, damit sie im Falle eines Fehlers für das Debugging verwendet werden können. Der Standardwert für die Protokolle ist 1.
Zudem können Sie die maximale Größe eines Protokolls festlegen. Wenn Sie eine maximale Größe für die Protokolldatei festlegen, wird ein Dateiumlauf ausgelöst, d. h., wenn die Datei die angegebene Größe erreicht hat, werden alle weiteren Einträge wieder an den Anfang der Datei geschrieben und die dort befindlichen Einträge überschrieben. Sie können für die Protokollgröße keinen Wert angeben, der kleiner als der aktuelle Wert für die Protokollgröße ist. Protokolleinträge werden mit einer Zeitmarke versehen, so dass Sie erkennen können, in welcher Reihenfolge sie geschrieben wurden.
Je höher Sie die Protokollstufe setzen, desto sorgfältiger müssen Sie die Protokollgröße auswählen, da die Protokolldatei sehr schnell voll ist, wenn Sie eine Protokollierung auf einer höheren Stufe wählen. Bei Stufe 0 ist es wahrscheinlich sicher, die Standardprotokollgröße von 1 MB zu verwenden. Ab Stufe 3 sollten Sie die Größe jedoch begrenzen. Bedenken Sie aber, dass bei einem zu kleinen Wert die Protokollierung nicht mehr sinnvoll ist.
Für Cisco CSS Controller und Nortel Alteon Controller gibt es die folgenden Protokolle:
Das folgende Beispiel zeigt, wie Sie für das Protokoll der Metriküberwachung, in dem die Kommunikation mit den Metric-Server-Agenten protokolliert wird, die Protokollstufe und die maximale Größe konfigurieren können:
xxxcontrol metriccollector set Consultant-ID:Service-ID:Metrikname loglevel x logsize y
Die von den Controllern generierten Protokolle werden standardmäßig im Unterverzeichnis logs des Installationsverzeichnisses der Controller gespeichert. Wenn Sie diesen Pfad ändern möchten, setzen Sie die Variable xxx_logdir im xxxserver-Script entsprechend.
AIX-, HP-UX-, Linux- und Solaris-Systeme: Sie finden das xxxserver-Script im Verzeichnis /usr/bin. In diesem Script ist die Variable xxx_logdir auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
xxx_LOGDIR=/pfad/zu/meinen/protokollen/
Windows-Systeme: Sie finden die xxxserver-Datei im Verzeichnis <Installationsstammverzeichnis>ibm\edge\lb\bin. In der xxxserver-Datei ist die Variable xxx_logdir auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
set xxx_LOGDIR=c:\pfad\zu\meinen\protokollen\
Für alle Betriebssysteme ist sicherzustellen, dass sich rechts und links vom Gleichheitszeichen keine Leerzeichen befinden und dass der Pfad mit einem Schrägstrich endet ("/" bzw. "\").
Für die Binärprotokollierung von Load Balancer wird dasselbe Verzeichnis (log) wie für die übrigen Protokolldateien verwendet. Weitere Informationen finden Sie im Abschnitt Binäre Protokolle für die Analyse von Serverstatistiken verwenden.
Die folgenden Abschnitte erläutern die Verwendung und Verwaltung der Komponente Dispatcher.
Load Balancer betrachtet Verbindungen als veraltet, wenn während der durch das Inaktivitätszeitlimit angegebenen Zeit (Sekunden) inaktiv waren. Wird das Inaktivitätszeitlimit überschritten, entfernt Load Balancer den Eintrag für diese Verbindung aus seinen Tabellen und löscht den nachfolgenden Datenverkehr für diese Verbindung.
Auf Portebene können Sie das Inaktivitätszeitlimit beispielsweise mit dem Befehl dscontrol port set staletimeout angeben.
Das Inaktivitätszeitlimit kann auf Executor-, Cluster- und Portebene gesetzt werden. Auf Executor- und Clusterebene liegt der Standardwert bei 300 Sekunden. Es wird bis hinunter zum Port gefiltert. Auf Portebene ist der Standardwert vom jeweiligen Port abhängig. Einige herkömmliche Ports haben unterschiedliche Inaktivitätszeitlimits. Der Telnet-Port 23 hat beispielsweise ein Standardlimit von 259.200 Sekunden.
Dienste können auch eigene Inaktivitätszeitlimits haben. Für LDAP (Lightweight Directory Access Protocol) gibt es z. B. den Konfigurationsparameter idletimeout. Bei Überschreitung der von idletimeout angegebenen Zeit in Sekunden wird die Beendigung einer inaktiven Clientverbindung erzwungen. Das Inaktivitätszeitlimit (idletimeout) kann auch auf 0 gesetzt werden, so dass Verbindungen nicht zwangsweise beendet werden können.
Wenn das Inaktivitätszeitlimit von Load Balancer kleiner als das des Dienstes ist, können Konnektivitätsprobleme auftreten. Im Falle von LDAP liegt das Inaktivitätslimit von Load Balancer (staletimeout) standardmäßig bei 300 Sekunden. Ist die Verbindung 300 Sekunden inaktiv, entfernt Load Balancer den Eintrag für die Verbindung aus seinen Tabellen. Wenn das Inaktivitätszeitlimit (idletimeout) über 300 Sekunden liegt (oder auf 0 gesetzt ist), könnte der Client davon ausgehen, dass er weiterhin mit dem Server verbunden ist. Wenn der Client Pakete sendet, werden diese von Load Balancer gelöscht. Das hat zur Folge, dass LDAP blockiert, wenn eine Anfrage an den Server gesendet wird. Sie können dieses Problem vermeiden, indem Sie das Inaktivitätszeitlimit von LDAP (idletimeout) auf einen Wert ungleich null setzen, der genauso groß wie das Inaktivitätszeitlimit von Load Balancer (staletimeout) oder kleiner als dieses ist.
Ein Client sendet ein FIN-Paket, nachdem er alle Pakete gesendet hat, um dem Server mitzuteilen, dass die Transaktion beendet ist. Wenn der Dispatcher das FIN-Paket erhält, kennzeichnet er die Transaktion nicht mehr als AKTIV, sondern als BEENDET. Wenn eine Transaktion als BEENDET gekennzeichnet ist, kann der für die Verbindung reservierte Speicher bereinigt werden.
Sie können den Durchsatz bei der Reservierung und Wiederverwendung von Verbindungssätzen verbessern, indem Sie mit dem Befehl executor set fintimeout steuern, wie lange der Dispatcher Verbindungen im Status BEENDET in den Dispatcher-Tabellen als aktiv und empfangsbereit speichern soll. Sobald eine Verbindung im Status BEENDET den mit fintimeout festgelegten Zeitraum überschreitet, wird sie aus den Dispatcher-Tabellen entfernt und kann wiederverwendet werden. Das Zeitlimit für die Beendigung inaktiver Verbindungen können Sie mit dem Befehl dscontrol executor set fincount ändern.
Mit dem Befehl dscontrol executor set staletimeout können Sie steuern, wie lange der Dispatcher Verbindungen im Status HERGESTELLT in den Dispatcher-Tabellen als aktiv und empfangsbereit speichern soll, wenn kein aktiver Datenverkehr festgestellt werden kann. Weitere Informationen hierzu finden Sie im Abschnitt Inaktivitätszeitlimit verwenden.
Ausgehend von den Informationen des Executors können mehrere Diagramme angezeigt und an den Manager übergeben werden. (Die Menüoption "Überwachen" der GUI erfordert, dass die Managerfunktion aktiviert ist):
Ein Netzverwaltungssystem ist ein Programm, das ständig ausgeführt und verwendet wird, um ein Netz zu überwachen, den Status eines Netzes wiederzugeben und ein Netz zu steuern. Simple Network Management Protocol (SNMP), ein häufig verwendetes Protokoll für die Kommunikation mit Einheiten in einem Netz, ist der aktuelle Netzverwaltungsstandard. Die Netzeinheiten verfügen normalerweise über einen SNMP-Agenten und einen oder mehrere Subagenten. Der SNMP-Agent kommuniziert mit der Netzverwaltungsstation oder antwortet auf SNMP-Befehlszeilenanforderungen. Der SNMP-Subagent ruft Daten ab und aktualisiert die Daten und übergibt diese Daten an den SNMP-Agenten, der sie an den Requester weiterleitet.
Der Dispatcher stellt eine SNMP Management Information Base (ibmNetDispatcherMIB) und einen SNMP-Subagenten zur Verfügung. Damit wird Ihnen die Verwendung jedes Netzverwaltungssystems ermöglicht, wie beispielsweise Tivoli NetView, Tivoli Distributed Monitoring oder HP OpenView, um den Zustand, die Leistung und die Aktivität des Dispatchers zu überwachen. Die MIB-Daten beschreiben den Dispatcher, der verwaltet wird, und geben den aktuellen Status des Dispatchers wieder. Die MIB wird im Unterverzeichnis ..lb/admin/MIB installiert.
Das Netzverwaltungssystem verwendet SNMP-Befehle GET, um MIB-Werte auf anderen Maschinen zu überprüfen. Es kann dann den Benutzer benachrichtigen, wenn angegebene Schwellenwerte überschritten werden. Sie können anschließend die Leistung des Dispatchers beeinflussen, indem Sie Konfigurationsdaten für den Dispatcher so ändern, dass Dispatcher-Probleme im voraus bestimmt oder berichtigt werden, bevor sie den Ausfall des Dispatchers oder Webservers zur Folge haben.
Das System stellt normalerweise einen SNMP-Agenten für jede Netzverwaltungsstation zur Verfügung. Der Benutzer sendet einen Befehl GET an den SNMP-Agenten. Dieser SNMP-Agent sendet dann einen Befehl GET, um die angegebenen MIB-Variablenwerte von einem Subagenten abzurufen, der für diese MIB-Variablen zuständig ist.
Der Dispatcher stellt einen Subagenten zur Verfügung, der MIB-Daten aktualisiert und abruft. Der Subagent antwortet mit den entsprechenden MIB-Daten, wenn der SNMP-Agent einen Befehl GET sendet. Der SNMP-Agent überträgt die Daten an die Netzverwaltungsstation. Die Netzverwaltungsstation kann Sie benachrichtigen, wenn angegebene Schwellenwerte überschritten werden.
Die Dispatcher-SNMP-Unterstützung beinhaltet einen SNMP-Subagenten, der DPI-Funktionalität verwendet (DPI = Distributed Program Interface). DPI ist eine Schnittstelle zwischen einem SNMP-Agenten und seinen Subagenten. Das Betriebssystem Windows verwendet den Windows-Erweiterungsagenten als Schnittstelle zwischen einem SNMP-Agenten und seinen Subagenten.
AIX-Systeme stellen einen SNMP-Agenten bereit, der das SNMP-Multiplexer-Protokoll (SMUX) verwendet und die zusätzliche ausführbare Datei DPID2 anbietet, die als Umsetzer zwischen DPI und SMUX fungiert.
Für HP-UX-Systeme müssen Sie einen SMUX-fähigen SNMP-Agenten erwerben, da HP-UX keinen solchen bereitstellt. Load Balancer stellt DPID2 für HP-UX-Systeme bereit.
Linux-Systeme stellen einen SNMP-Agenten bereit, der SMUX verwendet. Im Lieferumfang der meisten Linux-Versionen (z. B. Red Hat) ist ein UCD-SNMP-Paket enthalten. UCD SNMP enthält ab Version 4.1 SMUX-fähige Agenten. Load Balancer stellt DPID2 für Linux-Systeme bereit.
Für Solaris-Systeme müssen Sie einen SMUX-fähigen SNMP-Agenten erwerben, da dieses Betriebssystem keinen solchen bereitstellt. Load Balancer stellt DPID2 für Solaris-Systeme im Verzeichnis /opt/ibm/edge/lb/servers/samples/SNMP bereit.
Den DPI-Agenten müssen Sie als Root ausführen. Bevor Sie den DPID2-Dämon ausführen, aktualisieren Sie die Dateien /etc/snmpd.peers und /etc/snmpd.conf wie folgt:
AIX- und Solaris-Systeme:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
Für Linux-Systeme:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_passwordIn der Datei snmpd.conf müssen Sie außerdem alle Zeilen auf Kommentar setzen, die mit den folgenden Wörter beginnen: com2sec, group, view oder access.
Führen Sie zum Installieren der SNMP-Unterstützung von HP-UX die folgenden Schritte aus:
Um das Load-Balancer-SNMP auf Systemen mit SuSE Linux verwenden zu können, müssen Sie die folgenden Schritte ausführen:
Aktualisieren Sie wie folgt snmpd (sofern der Dämon bereits aktiv ist), damit die Datei snmpd.conf neu gelesen wird:
refresh -s snmpd
Starten Sie den DPID-SMUX-Peer:
dpid2
Die Dämonen müssen in der folgenden Reihenfolge gestartet werden:
Führen Sie zum Installieren der Solaris-SNMP-Unterstützung die folgenden Schritte aus:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Auf der Website http://sunfreeware.com/ haben die Namen die Erweiterung .gz und können deshalb nicht wie ZIP- oder TAR-Dateien entpackt werden. Verwenden Sie stattdessen pkgadd Paketname.
Führen Sie zum Installieren der Windows-SNMP-Unterstützung die folgenden Schritte aus:
Verwenden Sie bei aktivem Executor den Befehl dscontrol subagent start [Name_der_Community], um den Namen der Community zu definieren, der zwischen dem Windows-Erweiterungsagenten und dem SNMP-Agenten verwendet wird.
Wichtiger Hinweis: Unter Windows 2003 reagiert SNMP standardmäßig nicht auf angegebene Community-Namen. Der SNMP-Subagent antwortet demzufolge nicht auf SNMP-Anforderungen. Um sicherzustellen, dass der SNMP-Subagent auf den Community-Namen reagiert, müssen Sie die SNMP-Service-Eigenschaften mit dem entsprechenden Community-Namen und den entsprechenden Zielhosts konfigurieren. Konfigurieren Sie die SNMP-Sicherheitseigenschaften wie folgt:
Die Kommunikation von SNMP erfolgt über das Senden und Empfangen von Nachrichten, die von verwalteten Einheiten gesendet werden, um Ausnahmebedingungen oder das Auftreten besonderer Ereignisse, wie beispielsweise das Erreichen eines Schwellenwerts, zu melden.
Der Subagent verwendet die folgenden Alarmnachrichten:
Die Nachricht indHighAvailStatus gibt an, dass sich der Wert der Statusvariablen (hasState) für hohe Verfügbarkeit geändert hat. Die gültigen Werte von hasState sind:
Die Alarmnachricht indSrvrGoneDown gibt an, dass die Wertigkeit des vom Abschnitt csID (Cluster-ID), psNum (Portnummer) und ssID (Server-ID) der Objektkennung angegebenen Servers gleich null ist. Die letzte bekannte Anzahl aktiver Verbindungen für den Server wird in der Nachricht gesendet. Diese Alarmnachricht gibt an, dass der angegebene Server inaktiviert ist, soweit Dispatcher dies feststellen konnte.
Die Alarmnachricht indDOSAttack gibt an, dass der Wert für numhalfopen (die Anzahl halboffener Verbindungen, die nur SYN-Pakete enthalten) an dem vom Abschnitt csID (Cluster-ID) und psNum (Portnummer) der Objektkennung angegebenen Port den Schwellenwert maxhalfopen überschritten hat. Die Anzahl der für den Port konfigurierten Server wird in der Alarmnachricht gesendet. Diese Alarmnachricht zeigt an, dass bei Load Balancer möglicherweise eine DoS-Attacke aufgetreten ist.
Die Alarmnachricht indDOSAttackDone gibt an, dass der Wert für numhalfopen (die Anzahl halboffener Verbindungen, die nur SYN-Pakete enthalten) an dem vom Abschnitt csID und psNum der Objektkennung angegebenen Port unter den Schwellenwert maxhalfopen gefallen ist. Die Anzahl der für den Port konfigurierten Server wird in der Alarmnachricht gesendet. Wenn Load Balancer nach dem Senden einer indDOSAttack-Alarmnachricht feststellt, dass die mögliche DoS-Attacke vorüber ist, wird diese Alarmnachricht gesendet.
Auf Betriebssystemen mit AIX, HP-UX, Linux und Solaris kann es sich aufgrund einer Einschränkung in der SMUX-API bei der Unternehmenskennung, die in Nachrichten von dem ibmNetDispatcher-Subagenten gemeldet wird, um die Unternehmenskennung von dpid2 und nicht um die Unternehmenskennung von ibmNetDispatcher, 1.3.6.1.4.1.2.6.144, handeln. Die SNMP-Verwaltungsdienstprogramme können jedoch die Quelle der Nachricht bestimmen, da die Daten eine Objektkennung aus der ibmNetDispatcher-MIB enthalten.
Mit dem Befehl dscontrol subagent start wird die SNMP-Unterstützung aktiviert. Mit dem Befehl dscontrol subagent stop wird die SNMP-Unterstützung inaktiviert.
Weitere Informationen zum Befehl dscontrol finden Sie im Abschnitt dscontrol subagent — SNMP-Subagenten konfigurieren.
In den Linux-Kernel ist das Firewall-Tool ipchains integriert. Wenn Load Balancer und ipchains gleichzeitig ausgeführt werden, sieht Load Balancer die Pakete zuerst. Erst danach werden sie von ipchains gesehen. Deshalb kann ipchains verwendet werden, um die Sicherheit einer Linux-Maschine mit Load Balancer zu erhöhen. Bei einer solchen Maschine könnte es sich beispielsweise um einen Rechner mit Load Balancer handeln, der einen Lastausgleich für Firewalls durchführt.
Wenn ipchains oder iptables für eine vollständige Einschränkung konfiguriert ist (so dass kein ein- oder ausgehender Datenverkehr zulässig ist), arbeitet die Paketweiterleitungsfunktion von Load Balancer normal weiter.
ipchains und iptables können nicht zum Filtern von eingehendem Datenverkehr verwendet werden, für den noch kein Lastausgleich durchgeführt wurde.
Ein gewisses Maß an Datenverkehr muss erlaubt sein, da Load Balancer sonst nicht fehlerfrei arbeiten kann. Nachfolgend sind einige Beispiele für eine solche Kommunikation aufgelistet:
Eine angemessene ipchains-Strategie für die Load-Balancer-Maschinen wäre, den gesamten Datenverkehr mit Ausnahme des Verkehrs von oder zu den Back-End-Servern, den Partnermaschinen für hohe Verfügbarkeit, allen Erreichbarkeitszielen oder Konfigurationshosts zu unterbinden.
Sie sollten iptables nicht aktivieren, wenn Sie Load Balancer mit einem Linux-Kernel der Version 2.4.10.x ausführen. Eine Aktivierung unter diesem Linux-Kernel kann im Laufe der Zeit zur Beeinträchtigung des Durchsatzes führen.
Wenn Sie iptables inaktivieren möchten, listen Sie die Module auf (lsmod), um festzustellen, welche Module ip_tables und ip_conntrack verwenden. Entfernen Sie sie anschließend mit den Befehlen rmmod ip_tables und rmmod ip_conntrack. Nach einem Warmstart der Maschine werden diese Module wieder hinzugefügt. Sie müssen diesen Schritt deshalb nach jedem Warmstart wiederholen.
Weitere Informationen hierzu finden Sie im Abschnitt Problem: Mögliche Störung der Paketweiterleitung durch iptables unter Linux.
Die folgenden Abschnitte erläutern die Verwendung und Verwaltung der Komponente CBR von Load Balancer.
CBR und Caching Proxy kooperieren über die API des Caching-Proxy-Plug-in bei der Bearbeitung von HTTP- und HTTPS-Anfragen (SSL). CBR kann erst mit dem Lastausgleich für die Server beginnen, wenn Caching Proxy auf derselben Maschine ausgeführt wird. Konfigurieren Sie CBR und Caching Proxy wie im Abschnitt CBR-Konfigurationsbeispiel beschrieben.
Nachdem Sie CBR gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von CBR verwendeten Protokolle ähneln den Protokollen, die im Dispatcher verwendet werden. Weitere Informationen hierzu finden Sie im Abschnitt Protokolle von Load Balancer verwenden.
In früheren Releases konnten Sie den Protokollverzeichnispfad für CBR in der Caching-Proxy-Konfigurationsdatei ändern. Jetzt können Sie den Verzeichnispfad, in dem das Protokoll gespeichert wird, in der cbrserver-Datei ändern. Weitere Informationen finden Sie im Abschnitt Pfade für die Protokolldatei ändern.
Nachdem Sie Site Selector gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von Site Selector verwendeten Protokolle ähneln den Protokollen des Dispatchers. Weitere Informationen hierzu finden Sie im Abschnitt Protokolle von Load Balancer verwenden.
Nachdem Sie Cisco CSS Controller gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von Cisco CSS Controller verwendeten Protokolle ähneln den Protokollen des Dispatchers. Weitere Informationen hierzu finden Sie im Abschnitt Protokolle von Load Balancer verwenden.
Nachdem Sie Nortel Alteon Controller gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von Nortel Alteon Controller verwendeten Protokolle ähneln den Protokollen des Dispatchers. Weitere Informationen hierzu finden Sie im Abschnitt Protokolle von Load Balancer verwenden.
Metric Server stellt Informationen zur Serverauslastung für Load Balancer bereit. Metric Server befindet sich auf jedem Server, der in den Lastausgleich einbezogen ist.
Linux- und UNIX-Systeme:
Windows-Systeme:
Klicken Sie nacheinander auf Start > Systemsteuerung > Verwaltung > Dienste. Klicken Sie mit der rechten Maustaste auf IBM Metric Server und wählen Sie "Starten" aus. Zum Stoppen des Services müssen Sie dieselben Schritte ausführen und "Beenden" auswählen.
Ändern Sie die Protokollstufe im Startscript für Metric Server. Sie können eine Protokollstufe von 0 bis 5 angeben. Die Stufen sind denen für die Load-Balancer-Protokolle vergleichbar. Daraufhin wird im Verzeichnis ...ms/logs ein Agentenprotokoll erstellt.