Version 2.0
GC12-2505-04
Anmerkung |
---|
Vor Verwendung dieser Informationen und des darin beschriebenen Produkts sollten die allgemeinen Informationen in Anhang I, Bemerkungen gelesen werden. |
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
WebSphere Edge Server for Multiplatforms, Administration Guide
,
IBM Form GC31-8496-06,
herausgegeben von International Business Machines
Corporation, USA
(C) Copyright International Business Machines Corporation 2001
(C)
Copyright IBM Deutschland Informationssysteme GmbH 2001
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
Kapitel 1. Erste Schritte...für einen schnellen Start!
Kapitel 2. Network Dispatcher installieren
Kapitel 3. Einführung in Network Dispatcher
Kapitel 4. Planung für Dispatcher
Kapitel 5. Dispatcher konfigurieren
Kapitel 6. Planung für Content Based Routing
Kapitel 7. Content Based Routing konfigurieren
Kapitel 8. Planung für Mailbox Locator
Kapitel 9. Mailbox Locator konfigurieren
Kapitel 10. Planung für Site Selector
Kapitel 11. Site Selector konfigurieren
Kapitel 12. Planung für Consultant für Cisco CSS Switches
Kapitel 13. Consultant für Cisco CSS Switches konfigurieren
Kapitel 14. Erweiterte Funktionen von Network Dispatcher
Kapitel 15. Betrieb und Verwaltung von Network Dispatcher
Anhang A. Syntaxdiagramm lesen
Anhang B. Befehlsreferenz für Dispatcher, CBR und Mailbox Locator
Anhang C. Syntax der content-Regel
Anhang D. Befehlsreferenz für Site Selector
Anhang E. Befehlsreferenz für Consultant für Cisco CSS Switches
Anhang F. Beispielkonfigurationsdateien
In diesem Handbuch sind die Planung, Installation, Konfiguration, Verwendung und Fehlerbehebung für IBM(R) WebSphere Edge Server Network Dispatcher für AIX, Linux, Solaris und Windows 2000 beschrieben. Zuvor hatte dieses Produkt den Namen SecureWay Network Dispatcher, eNetwork Dispatcher und Interactive Network Dispatcher.
Die neueste Version dieses Handbuchs ist im HTML- und PDF-Format auf der Website zu WebSphere Edge Server verfügbar. Sie können über den folgenden URL auf das Onlinebuch zugreifen:
http://www.ibm.com/software/webservers/edgeserver/library.html
Die Website zu WebSphere Edge Server enthält die neuesten Informationen zur Verwendung von Network Dispatcher für die Leistungsoptimierung Ihrer Server. Konfigurationsbeispiele und Szenarien sind eingeschlossen. Um auf diese Website zuzugreifen, rufen Sie den folgenden URL auf:
http://www.ibm.com/software/webservers/edgeserver
Die letzten Aktualisierungen und Verwendungshinweise zu Network Dispatcher finden Sie auf der Webseite mit Unterstützung zu WebSphere Edge Server. Klicken Sie auf dieser Webseite auf den Eintrag Search for Network Dispatcher hints and tips. Die genannte Webseite hat den folgenden URL:
http://www.ibm.com/software/webservers/edgeserver/support.html
Ihre Rückmeldung ist uns wichtig, damit wir möglichst genaue und hochwertige Informationen bieten können. Falls Sie Kommentare zum vorliegenden Handbuch oder einem anderen Dokument zu WebSphere Edge Server abgeben möchten:
Wie schnell können Sie Network Dispatcher nutzen? Das folgende Szenario gibt ein Beispiel.
Angenommen, Sie sind der Webadministrator des Unternehmens Intersplash. Sie verwalten eine lokale Website mit zwei HTTP-Servern. Bisher haben Sie die Auslastung der beiden Server nach der RoundRobin-Methode verwaltet. In letzter Zeit hat das Unternehmen jedoch expandiert, und die Kunden beschweren sich zunehmend, dass sie nicht auf die Site zugreifen können. Was ist zu tun?
Rufen Sie http://www.ibm.com/software/webservers/edgeserver auf und laden Sie die neueste Version von Network Dispatcher herunter. Dieses Produkt umfasst fünf Komponenten: Dispatcher, Content Based Routing (CBR), Mailbox Locator, Site Selector und Consultant für Cisco CSS Switches (Cisco Consultant). Im Augenblick soll nur die Komponente Dispatcher erläutert werden.
Abbildung 1. Einfache lokale Dispatcher-Konfiguration
Dieses Beispiel zeigt die Konfiguration von drei lokal angeschlossenen Workstations, die die MAC-Weiterleitungsmethode der Dispatcher-Komponente verwenden, um den Webdatenverkehr auf zwei Webserver zu verteilen. Für die Verteilung des Datenverkehrs einer anderen TCP-Anwendung oder einer kontextlosen UDP-Anwendung würde die Konfiguration im Wesentlichen genauso aussehen.
In dem Beispiel für einen schnellen Start werden drei Workstations und vier IP-Adressen benötigt. Eine Workstation wird als Dispatcher verwendet; die beiden anderen Workstations werden als Webserver verwendet. Jeder Webserver benötigt eine IP-Adresse. Die Dispatcher-Workstation benötigt eine eigene Adresse und eine Adresse für den Lastausgleich.
Workstation | Name | IP-Adresse |
---|---|---|
1 | server1.intersplash.com | 9.67.67.101 |
2 | server2.intersplash.com | 9.67.67.102 |
3 | server3.intersplash.com | 9.67.67.103 |
Netzmaske = 255.255.255.0 |
Jede Workstation enthält nur eine Standard-Ethernet-Netzschnittstellenkarte.
Name=www.intersplash.com IP=9.67.67.104
Fügen Sie zur Loopback-Schnittstelle von server2.intersplash.com und server3.intersplash.com einen Aliasnamen für www.intersplash.com hinzu.
ifconfig lo0 alias www.intersplash.com netmask 255.255.255.0
ifconfig lo0:1 www.intersplash.com 127.0.0.1 up
Sie haben jetzt alle für die beiden Webserver-Workstations erforderlichen Konfigurationsschritte ausgeführt.
Für den Dispatcher können Sie eine Konfiguration unter Verwendung der Befehlszeile, des Konfigurationsassistenten oder der grafischen Benutzerschnittstelle (GUI) erstellen.
Führen Sie folgende Schritte aus, wenn Sie die Befehlszeile verwenden:
ndcontrol executor start
ndcontrol cluster add www.intersplash.com
ndcontrol port add www.intersplash.com:80
ndcontrol server add www.intersplash.com:80:server2.intersplash.com
ndcontrol server add www.intersplash.com:80:server3.intersplash.com
ndcontrol cluster configure www.intersplash.com
ndcontrol manager start
Der Dispatcher führt den Lastausgleich jetzt ausgehend von der Serverleistung durch.
ndcontrol advisor start http 80
Der Dispatcher stellt jetzt sicher, dass keine Client-Anforderungen an einen ausgefallenen Webserver gesendet werden.
Die Basiskonfiguration mit lokal angeschlossenen Servern ist damit vollständig.
Führen Sie folgende Schritte aus, wenn Sie den Konfigurationsassistenten verwenden:
ndserver
Der Assistent führt Sie schrittweise durch den Prozess zum Erstellen einer Basiskonfiguration für die Dispatcher-Komponente. Der Assistent stellt Ihnen Fragen zu Ihrem Netz. Sie erhalten eine Anleitung für die Konfiguration eines Clusters, bei der der Dispatcher den Datenverkehr auf eine Gruppe von Servern verteilt.
Bei Verwendung des Konfigurationsassistenten erscheinen die folgenden Anzeigen:
Abbildung 2. Die grafische Benutzerschnittstelle (GUI)
Führen Sie die folgenden Schritte aus, um die grafische Benutzerschnittstelle zu starten:
ndserver
Auf der linken Seite der Anzeige erscheint eine Baumstruktur mit Network Dispatcher als Ausgangsebene und Dispatcher, Content Based Routing, Mailbox Locator, Site Selector sowie Cisco Consultant als Komponenten. Siehe Abbildung 2.
Alle Komponenten können über die GUI konfiguriert werden. Sie können Elemente in der Baumstruktur auswählen, indem Sie mit der ersten Maustaste (normalerweise der linken Maustaste) darauf klicken. Zum Aufrufen von Popup-Menüs müssen Sie die zweite Maustaste (normalerweise die rechte Maustaste) drücken. Auf die Popup-Menüs für die Baumstrukturelemente kann auch über die Menüleiste zugegriffen werden, die sich oben in der Anzeige befindet.
Durch Klicken auf das Plus- oder Minuszeichen können Sie die Elemente der Baumstruktur ein- bzw. ausblenden.
Auf der rechten Seite der Anzeige erscheinen Registerseiten mit Statusanzeigen für das derzeit ausgewählte Element.
Falls Sie Hilfe benötigen, klicken Sie oben rechts im Network-Dispatcher-Fenster auf das Fragezeichen.
Testen Sie, ob die Konfiguration korrekt ist.
Es gibt viele Möglichkeiten, Network Dispatcher für die Unterstützung Ihrer Site zu konfigurieren. Wenn Sie für Ihre Site nur einen Host-Namen haben, zu dem alle Kunden eine Verbindung herstellen, können Sie einen Cluster mit Servern definieren. Für jeden dieser Server konfigurieren Sie einen Port, über den Network Dispatcher kommuniziert. Siehe Abbildung 3.
Abbildung 3. Dispatcher-Beispielkonfiguration mit einem Cluster und zwei Ports
In diesem Beispiel ist für die Dispatcher-Komponente ein Cluster mit der Adresse www.productworks.com definiert. Dieser Cluster hat zwei Ports: Port 80 für HTTP und Port 443 für SSL. Ein Client, der eine Anforderung an http://www.productworks.com (Port 80) richtet, wird einem anderen Server zugeordnet als ein Client, der eine Anforderung an http://www.productworks.com (Port 443) richtet.
Wenn Ihre Site sehr groß ist und Sie für jedes unterstützte Protokoll mehrere dedizierte Server haben, sollten Sie Network Dispatcher auf andere Weise konfigurieren. In diesem Fall könnten Sie für jedes Protokoll einen Cluster mit nur einem Port, aber mehreren Servern definieren (siehe Abbildung 4).
Abbildung 4. Dispatcher-Beispielkonfiguration mit zwei Clustern mit jeweils einem Port
In diesem Beispiel für die Dispatcher-Komponente sind zwei Cluster definiert: www.productworks.com für Port 80 (HTTP) und www.testworks.com für Port 443 (SSL).
Wenn Ihre Site Inhalte für mehrere Unternehmen oder Abteilungen bereitstellt, die jeweils mit einem eigenen URL auf Ihre Site zugreifen, muss Network Dispatcher auf eine dritte Art konfiguriert werden. In diesem Fall könnten Sie für jede Firma oder Abteilung einen Cluster definieren und anschließend die Ports, an denen Verbindungen mit dem jeweiligen URL empfangen werden sollen (siehe Abbildung 5).
Abbildung 5. Dispatcher-Beispielkonfiguration mit zwei Clustern mit jeweils zwei Ports
In diesem Beispiel für die Dispatcher-Komponente wurden für die Sites www.productworks.com und www.testworks.com jeweils zwei Cluster mit Port 80 (HTTP) und Port 23 (Telnet) definiert.
Dieses Kapitel enthält Informationen zu den Hardwarevoraussetzungen und zur Installation von Network Dispatcher unter AIX, Linux, Solaris und Windows 2000. Beginnen Sie mit einem der folgenden Abschnitte:
Anmerkungen:
Sie können wie folgt gewährleisten, dass die Network-Dispatcher-Komponenten beim Vorhandensein mehrerer Java-Versionen die richtige Version verwenden:
Editieren Sie die Script-Dateien für jede Komponente von Network Dispatcher, für die Sie ein Upgrade durchführen. Die Script-Dateien für die einzelnen Komponenten haben die folgenden Namen:
Beispiel für Windows 2000: Wenn Java 1.3 im Verzeichnis C:\Programme\IBM\Java13\jre\bin installiert ist, müssen Sie die Zeile in ndserver.cmd wie folgt ändern:
IBM AIX 4.3.3.10 mit APARs (um die Unterstützung für Java 1.3 zu gewährleisten). Eine Liste der erforderlichen AIX APARs finden Sie in der Readme-Datei zum IBM AIX Developer Kit.
In Tabelle 1 sind die installp-Images von Network Dispatcher für AIX
aufgelistet.
Tabelle 1. installp-Images für AIX
Dispatcher (Komponente, Verwaltung, Lizenz und Nachrichten) | intnd.nd.driver intnd.nd.rte intnd.msg.nd.<Sprache>.nd intnd.admin.rte intnd.msg.<Sprache>.admin |
Administration (nur Komponente) | intnd.admin.rte intnd.msg.<Sprache>.admin |
Dokumentation | intnd.doc.rte |
Lizenz | intnd.nd.license |
Metric Server | intnd.ms.rte |
Dabei gibt <Sprache> einen der folgenden Sprachencodes an:
Falls Sie eine Probeversion des Produkts von der Website herunterladen, verwenden Sie die im Dokument http://www.ibm.com/software/webservers/edgeserver/download.html enthaltenen Installationsanweisungen.
Bei der Installation des Produkts können Sie auswählen, ob Sie nur bestimmte oder alle der in der folgenden Liste aufgeführten Optionen installieren wollen:
Führen Sie die folgenden Schritte aus, um Network Dispatcher für AIX zu installieren:
Verwendung von SMIT:
Ist der Befehl vollständig ausgeführt, drücken Sie die Taste für Ende. Wählen Sie dann im Menü "Beenden" den Eintrag SMIT beenden aus oder drücken Sie die Taste F12. Drücken Sie bei Verwendung von SMITTY die Taste F10, um das Programm zu verlassen.
Verwendung der Befehlszeile:
Führen Sie die Installation von einer CD aus, müssen Sie die folgenden Befehle eingeben, um die CD einzulegen:
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Stellen Sie anhand der folgenden Tabelle fest, welche Befehle Sie eingeben
müssen, um die gewünschten Pakete von Network Dispatcher für AIX zu
installieren:
Tabelle 2. AIX-Installationsbefehle
Network Dispatcher (mit Nachrichten); umfasst Dispatcher, CBR, Mailbox Locator, Site Selector und Cisco Consultant. | installp -acXgd Einheit intnd.nd.rte intnd.admin.rte intnd.nd.driver intnd.msg.<Sprache>.nd intnd.msg.<Sprache>.admin |
Dokumente | installp -acXgd Einheit intnd.doc.rte intnd.msg.<Sprache>.doc |
Administration (nur Komponente) | installp -acXgd Einheit intnd.admin.rte intnd.msg.<Sprache>.admin |
Lizenz | installp -acXgd Einheit intnd.nd.license |
Metric Server | installp -acXgd Einheit intnd.ms.rte intnd.msg.<Sprache>.admin |
Einheit steht hier für Folgendes:
Achten Sie darauf, dass die Ergebnisspalte in der Zusammenfassung für alle installierten Komponenten von Network Dispatcher jeweils die Angabe ERFOLGREICH enthält. Fahren Sie erst fort, wenn alle ausgewählten Komponenten erfolgreich installiert wurden.
installp -ld Einheit
Einheit steht hier für Folgendes:
Geben Sie folgendes ein, um die CD abzuhängen:
unmount /cdrom
lslpp -h | grep intnd
Wurde das gesamte Produkt installiert, gibt dieser Befehl folgendes zurück:
intnd.admin.rte intnd.doc.rte intnd.ms.rte intnd.msg.de.admin.rte intnd.msg.de.doc intnd.msg.de.nd.rte intnd.nd.driver intnd.nd.license intnd.nd.rte
Für Network Dispatcher gelten die folgenden Installationspfade:
In diesem Abschnitt wird erklärt, wie Network Dispatcher unter Red Hat Linux oder SuSE Linux unter Verwendung der Produkt-CD oder der von der Website heruntergeladenen Probeversion installiert wird. Installationsanweisungen finden Sie auf der Website (http://www.ibm.com/software/webservers/edgeserver/download.html).
Vergewissern Sie sich vor Beginn des Installationsverfahrens, dass Sie die Root-Berechtigung für die Installation der Software haben.
Gehen Sie wie folgt vor, um Network Dispatcher zu installieren:
Das Installationsimage ist eine Datei im Format ndlinux-Version.tar.
Die folgende Liste enthält die von RPM installierbaren Pakete.
Der Befehl zum Installieren der Pakete sollte von dem Verzeichnis mit den RPM-Dateien aus abgesetzt werden. Setzen Sie zum Installieren der einzelnen Pakete den Befehl rpm -i Paket.rpm ab.
rpm -i --nodeps Paket.rpm
rpm -qa | grep ibmnd
Wurde das gesamte Produkt installiert, sollte eine Liste wie die folgende generiert werden:
Für Solaris 8: Netscape Navigator ab Version 4.07 oder Netscape Communicator ab Version 4.61 zum Anzeigen der Onlinehilfe.
In diesem Abschnitt wird erklärt, wie Network Dispatcher unter Solaris von der Produkt-CD installiert wird. Falls Sie eine Probeversion des Produkts aus dem Internet downloaden, verwenden Sie die auf der Website enthaltenen Installationsanweisungen (http://www.ibm.com/software/webservers/edgeserver/download.html).
Vergewissern Sie sich vor Beginn des Installationsverfahrens, dass Sie die Root-Berechtigung für die Installation der Software haben.
Gehen Sie wie folgt vor, um Network Dispatcher zu installieren:
Geben Sie an der Eingabeaufforderung pkgadd -d Pfadname ein. Dabei ist -d Pfadname der Einheitenname des CD-ROM-Laufwerks oder das Verzeichnis auf dem Festplattenlaufwerk, in dem sich das Paket befindet. Beispiel: pkgadd -d /cdrom/cdrom0/.
Es wird eine Liste mit Paketen angezeigt, die installiert werden können. Diese Pakete sind:
Sollen alle Pakete installiert werden, geben Sie einfach "all" ein und drücken Sie die Rückführtaste. Sollen einzelne Komponenten installiert werden, geben Sie die Namen der zu installierenden Pakete duruch ein Leerzeichen oder Komma getrennt ein und drücken Sie die Rückführtaste. Möglicherweise werden Sie aufgefordert, Berechtigungen für vorhandene Verzeichnisse oder Dateien zu ändern. Drücken Sie einfach die Rückführtaste oder antworten Sie mit "yes". Sie müssen vorausgesetzte Pakete installieren (da die Installation in alphabetischer Reihenfolge und nicht in der Reihenfolge der vorausgesetzten Pakete erfolgt). Haben Sie "all" eingegeben, antworten Sie auf alle Bedienerführungen mit "yes". Die Installation wird dann erfolgreich ausgeführt.
Alle Pakete sind von dem allgemeinen Paket ibmndadm abhängig. Dieses allgemeine Paket muss zusammen mit allen anderen Paketen installiert werden.
Falls Sie das gesamte Produkt Network Dispatcher installieren möchten, müssen Sie die fünf Komponenten ibmdsp, ibmdsplic, ibmndadm, ibmnddoc und ibmndms installieren. Wenn Sie die Fernverwaltung installieren möchten, muss nur die Komponente ibmndadm installiert werden.
Die Network-Dispatcher-Komponenten sind wie folgt im Installationsverzeichnis /opt/nd/servers enthalten.
Wurde das gesamte Produkt installiert, sollte eine Liste wie die folgende generiert werden:
Beachten Sie, dass Sie sowohl das Installationspaket für das Developer Kit herunterladen müssen als auch das Installationspaket für Runtime Environment (Laufzeitumgebung), bevor Sie das InstallShield-Programm ausführen. (Weitere Informationen zur Ausführung mehrerer Java-Versionen können Sie der Anmerkung (JVER) entnehmen.)
In diesem Abschnitt wird erklärt, wie Network Dispatcher von der Produkt-CD unter Windows 2000 installiert wird. Falls Sie eine Probeversion des Produkts von der Website downloaden, verwenden Sie die auf der Website enthaltenen Installationsanweisungen (http://www.ibm.com/software/webservers/edgeserver/download.html).
Es wird eine Liste mit Paketen angezeigt, die installiert werden können.
Diese Pakete sind:
Die Produktversion von Network Dispatcher für Windows 2000 wird von den folgenden Betriebssystemen unterstützt:
Einschränkungen: Die Version von Network Dispatcher für Windows 2000 kann nicht auf derselben Maschine wie IBM Firewall installiert werden.
Vergewissern Sie sich vor Beginn der Istallation, dass Sie als Administrator oder Benutzer mit Administratorberechtigung angemeldet sind.
Falls Sie eine frühere Version installiert haben, sollten Sie diese Kopie vor Installation der aktuellen Version deinstallieren. Gehen Sie zum Deinstallieren mit der Option Software wie folgt vor:
Gehen Sie wie folgt vor, um Network Dispatcher zu installieren:
E:\setup
Für Network Dispatcher gelten die folgenden Installationspfade:
Dieses Kapitel gibt einen Überblick über Network Dispatcher und ist in die folgenden Abschnitte gegliedert:
Network Dispatcher ist eine Softwarelösung für den Lastausgleich von Servern. Dieses Produkt verbessert die Leistung von Servern erheblich, indem es TCP/IP-Sitzungsanforderungen an verschiedene Server einer Gruppe verteilt. Dieser Lastausgleich ist für Benutzer und andere Anwendungen transparent. Network Dispatcher ist vor allem bei Anwendungen wie E-Mail-Servern, WWW-Servern, parallelen Abfragen verteilter Datenbanken und anderen TCP/IP-Anwendungen nützlich.
Beim Einsatz mit Webservern kann Network Dispatcher zur optimalen Nutzung des Potenzials Ihrer Site beitragen, da er eine leistungsfähige, flexible und skalierbare Lösung für Probleme bietet, die durch eine sehr hohe Belastung auftreten können. Haben Besucher zu Zeiten höchster Belastung Schwierigkeiten, auf Ihre Site zuzugreifen, können Sie mit Network Dispatcher automatisch den optimalen Server zur Bearbeitung eingehender Anforderungen suchen.
Network Dispatcher besteht aus fünf Komponenten, die separat oder zusammen verwendet werden können, um bessere Ergebnisse beim Lastausgleich zu erzielen:
Wenn Sie mit dem Protokoll HTTP arbeiten, können Sie auch die Dispatcher-Funktion für inhaltsabhängige Weiterleitung verwenden, um die Last ausgehend vom Inhalt der Client-Anfrage zu verteilen. Der ausgewählte Server ist das Ergebnis des Abgleichs des URL mit einer angegebenen Regel.
Weitere Informationen zu den Komponenten Dispatcher, CBR, Mailbox Locator, Site Selector und Consultant für Cisco CSS Switches finden Sie im Abschnitt Komponenten von Network Dispatcher.
Die Anzahl von Benutzern und Netzen, die mit dem globalen Internet verbunden sind, wächst mit rasanter Geschwindigkeit. Dieses Wachstum verursacht Probleme hinsichtlich der Skalierbarkeit, da der Benutzerzugriff auf attraktive Sites bei einem hohen Anforderungsaufkommen möglicherweise eingeschränkt wird.
Derzeit benutzen Netzadministratoren verschiedene Methoden zur Optimierung des Zugriffs. Bei einigen dieser Methoden können Benutzer nach dem Zufallsprinzip einen anderen Server auswählen, wenn der vorher ausgewählte Server zu langsam oder überhaupt nicht antwortet. Diese Vorgehensweise ist jedoch mühsam und ineffektiv. Eine weitere Methode ist die Standard-RoundRobin-Methode, bei der der Domänennamensserver der Reihe nach Server zur Bearbeitung von Anforderungen auswählt. Dieser Ansatz ist zwar besser, aber immer noch ineffizient, da der Datenverkehr ohne Berücksichtigung der Serverauslastung weitergeleitet wird. Zudem werden bei dieser Methode auch dann noch Anforderungen an einen Server gesendet, wenn er ausgefallen ist.
Der Bedarf an einer leistungsfähigeren Lösung hat zur Entwicklung von Network Dispatcher geführt. Dieses Produkt bietet gegenüber früheren Lösungen und Lösungen von anderer Anbieter eine Vielzahl von Vorteilen:
Wenn die Anzahl der Client-Anforderungen steigt, können Sie Server dynamisch hinzufügen und Millionen von Anforderungen pro Tag auf Hunderten von Servern unterstützen.
Der Lastausgleich gewährleistet, dass jede Servergruppe die zugehörige Hardware optimal nutzen kann, da die bei einer Standard-RoundRobin-Methode häufig auftretenden Spitzenbelastungen auf ein Minimum reduziert werden.
Network Dispatcher benutzt TCP/IP-Standardprotokolle. Das Produkt kann zu einem vorhandenen Netz hinzugefügt werden, ohne dass physische Änderungen am Netz erforderlich sind. Es ist leicht zu installieren und zu konfigurieren.
Bei Anwendung der einfachen MAC-Weiterleitung muss der Dispatcher nur auf den beim Server eingehenden Datenverkehr vom Client achten, nicht aber auf den vom Server zum Client abgehenden Datenverkehr. Dies führt im Vergleich zu anderen Methoden zu einer erheblichen Reduzierung der Auswirkungen auf die Anwendung und zu einer verbesserten Leistung im Netz.
Der Dispatcher verfügt über eine integrierte Funktion für hohe Verfügbarkeit, bei der eine Partnermaschine benutzt wird, die jederzeit die Weiterleitung von Paketen übernehmen kann, wenn die primäre Dispatcher-Maschine ausfällt. Die Dispatcher-Komponente gewährleistet außerdem eine gegenseitige hohe Verfügbarkeit, so dass zwei Maschinen aktiv sein und die jeweils andere Maschine als Ausweichmaschine nutzen können. Weitere Informationen hierzu finden Sie im Abschnitt Hohe Verfügbarkeit.
Zusammen mit Caching Proxy kann die Komponente CBR HTTP- und HTTPS-Anforderungen (SSL) ausgehend vom angefragten Inhalt an bestimmte Server weiterleiten. Wenn eine Anforderung im Verzeichnisabschnitt des URL beispielsweise die Zeichenfolge "/cgi-bin/" enthält und der Servername ein lokaler Server ist, kann CBR die Anforderung an den besten Server einer speziell für die Bearbeitung von cgi-Anforderungen zugeordneten Servergruppe übertragen.
Die Dispatcher-Komponente erlaubt auch eine inhaltsabhängige Weiterleitung, erfordert jedoch nicht die Installation von Caching Proxy. Da die inhaltsabhängige Weiterleitung der Dispatcher-Komponente bei Empfang von Paketen im Kernel ausgeführt wird, ist die inhaltsabhängige Weiterleitung der Dispatcher-Komponente schneller als die der CBR-Komponente. Die Dispatcher-Komponente führt das Content Based Routing für HTTP (unter Verwendung des Regeltyps "content") und für HTTPS (unter Verwendung der Affinität von SSL-Sitzungs-IDs) durch.
Network Dispatcher für IBM WebSphere Edge Server Version 2.0 ist durch eine Reihe neuer Merkmale gekennzeichnet. Die wichtigsten dieser Merkmale sind nachfolgend aufgelistet.
Dieses Merkmal gilt für alle Komponenten von Network Dispatcher.
Network Dispatcher bietet jetzt Unterstützung für eine neuere Version von AIX, für AIX Version 5.1. Weitere Informationen hierzu finden Sie im Abschnitt Voraussetzungen für AIX.
Dieses Merkmal gilt für alle Komponenten von Network Dispatcher.
Network Dispatcher bietet jetzt Unterstützung für SuSE Linux Version 7.1 (Kernel-Version 2.4.0 - 4 GB). Früher hat Network Dispatcher nur Red Hat Linux unterstützt. Weitere Informationen hierzu finden Sie im Abschnitt Voraussetzungen für Red Hat Linux oder SuSE Linux.
Dieses Merkmal gilt für alle Komponenten von Network Dispatcher.
Network Dispatcher bietet jetzt Unterstützung für eine neuere Version von Red Hat Linux, für Red Hat Linux Version 7.1 (Kernel-Version 2.4.2-2). Weitere Informationen hierzu finden Sie im Abschnitt Voraussetzungen für Red Hat Linux oder SuSE Linux.
Dieses Merkmal gilt für alle Komponenten von Network Dispatcher.
Unter den Betriebssystemen Linux und Solaris bietet Network Dispatcher Unterstützung der Landessprache für Länder der Gruppe 1.
Dieses Merkmal gilt für alle Komponenten von Network Dispatcher.
Network Dispatcher bietet Unterstützung der Landessprache gemäß dem neuen Chinesisch-Standard GB 18030.
Dies ist eine neue Komponente von Network Dispatcher.
In Zusammenarbeit mit Cisco und dem CDN (Content Distribution Network) von Cisco wurde eine zusätzliche Komponente für Network Dispatcher entwickelt, Cisco Consultant. Diese Komponente (die ursprünglich als Standalone-Komponente eingeführt wurde) ermöglicht Network Dispatcher, Wertigkeiten für den Cisco CSS Switch zu generieren und Lastausgleichsentscheidungen für den Switch zu treffen.
Weitere Informationen hierzu finden Sie in Kapitel 12, Planung für Consultant für Cisco CSS Switches und Kapitel 13, Consultant für Cisco CSS Switches konfigurieren.
Dies ist eine neue Komponente von Network Dispatcher.
Die Komponente Site Selector verteilt die Last für eine Gruppe von Servern, indem sie für eine Namensserviceanforderung die IP-Adresse des "richtigen" Servers auswählt. Dadurch kann der Client für seine gesamte Kommunikation eine direkte Verbindung zu diesem Server herstellen. Site Selector ersetzt die in früheren Releases von Network Dispatcher enthaltene Komponente Interactive Session Support (ISS). Die Funktionalität von Site Selector ist mit der von ISS vergleichbar. Site Selector erfordert für das Einrichten einer typischen DNS-Konfiguration mit Lastausgleich jedoch weniger Schritte.
Weitere Informationen hierzu finden Sie in Kapitel 10, Planung für Site Selector und Kapitel 11, Site Selector konfigurieren.
Diese Funktion ist für alle Komponenten von Network Dispatcher verfügbar.
Metric Server liefert Network Dispatcher Informationen zur Serverauslastung in Form systemspezifischer Messwerte. Der Agent Metric Server ist eine Komponente von Network Dispatcher, die auf Servern installiert und aufgeführt werden kann, für die Network Dispatcher einen Lastausgleich durchführt. Metric Server ersetzt den System Monitoring Agent (SMA), der in früheren Releases unter Linux unterstützt wurde. Metric Server wird von allen Plattformen unterstützt. Sie sollten Metric Server zusammen mit der Komponente Site Selector verwenden.
Weitere Informationen hierzu finden Sie im Abschnitt Metric Server.
Dies ist eine neue Komponente für Network Dispatcher.
Die Komponente Mailbox Locator war früher Bestandteil der CBR-Komponente und wurde bei IMAP- und POP3-Postservern für einen Lastausgleich ausgehend von Benutzer-ID und Kennwort verwendet. Durch die Untergliederung von CBR in zwei Komponenten können Mailbox Locator (bisher als "CBR für IMAP/POP3" bekannt) und CBR mit Caching Proxy auf einer Maschine ausgeführt werden.
Weitere Informationen hierzu finden Sie in Kapitel 8, Planung für Mailbox Locator und Kapitel 9, Mailbox Locator konfigurieren.
Das Konfigurieren der Caching-Proxy-Konfigurationsdatei (ibmproxy.conf) für die Verwendung von CBR wurde optimiert, so dass auf einer Maschine mehrere Instanzen des Caching Proxy parallel bei gleichzeitiger Integration von CBR ausgeführt werden können. Weitere Informationen zum Konfigurieren von CBR mit Caching Proxy finden Sie im Abschnitt CBR-Maschine konfigurieren.
Dieses Merkmal gilt für die Dispatcher-Komponente.
Durch NAT/NAPT entfällt die Einschränkung, dass sich Back-End-Server im lokal angeschlossenen Netz befinden müssen. Durch NAT/NAPT kann der Dispatcher außerdem die Last der TCP-Anforderungen von Clients auf mehrere Serverdämonen, die auf einer physischen Maschine ausgeführt werden, verteilen. Server mit mehreren Dämonen können Sie auf zwei verschiedene Arten konfigurieren. Mit NAT können Sie mehrere Serverdämonen für die Beantwortung von Anfragen, die an verschiedene IP-Adressen gerichtet sind, konfigurieren. Dieses Konfiguration wird auch als Bindung eines Serverdämons an eine IP-Adresse bezeichnet. Mit NAPT können Sie mehrere Serverdämonen so konfigurieren, dass sie an unterschiedlichen Port-Nummern empfangsbereit sind.
Die Weiterleitungsmethode "nat" von Dispatcher bietet den Vorteil, dass sie auf Port-Ebene konfiguriert wird und Ihnen so ein höheres Maß an Detaillierung ermöglicht.
Weitere Informationen hierzu finden Sie im Abschnitt NAT/NAPT-Weiterleitungsmethode (nat) des Dispatchers.
Dieses Merkmal gilt für die Dispatcher-Komponente.
In früheren Releases von Network Dispatcher war das Content Based Routing nur bei Verwendung der CBR-Komponente zusammen mit Caching Proxy verfügbar. Jetzt können Sie mit der Dispatcher-Komponente das Content Based Routing für HTTP (unter Verwendung des Regeltyps "content") und für HTTPS (unter Verwendung der Affinität von SSL-Sitzungs-IDs) ohne Caching Proxy ausführen. Für HTTP- und HTTPS-Datenverkehr ist das Content Based Routing der Dispatcher-Komponente schneller als das der CBR-Komponente.
Weitere Informationen zur Verwendung des Regeltyps "content" und der Affinität von SSL-Sitzungs-IDs finden Sie im Abschnitt Inhaltsabhängige Weiterleitung durch die Dispatcher-Komponente (cbr).
Dieses Merkmal gilt für die inhaltsabhängige Weiterleitung durch die Dispatcher-Komponente (Weiterleitungsmethode cbr) und die CBR-Komponente.
Die passive Cookie-Affinität ermöglicht die Verteilung von Webdatenverkehr mit Affinität zu einem Server ausgehend von den Identifizierungs-Cookies, die von den Servern generiert werden. Weitere Informationen finden Sie im Abschnitt Passive Cookie-Affinität.
Dieses Merkmal gilt für die inhaltsabhängige Weiterleitung durch die Dispatcher-Komponente (Weiterleitungsmethode cbr) und die CBR-Komponente.
Die URI-Affinität ermöglicht eine Lastverteilung für Webdatenverkehr auf Caching-Proxy-Server mit effektiver Vergrößerung des Cache. Weitere Informationen finden Sie im Abschnitt URI-Affinität.
Dieses Merkmal gilt für alle Komponenten von Network Dispatcher.
In früheren Releases wurde die proportionale Bedeutung, die aktiven Verbindungen, neuen Verbindungen, Port und Systemmesswerten für Entscheidungen bezüglich des Lastausgleichs beigemessen wurde, von der Verwaltungsfunktion bestimmt. Diese Proportion wurde in der Konfiguration für die Komponente auf jeden Cluster angewendet. Alle Cluster wurden unabhängig von der Site, für die der Lastausgleich durchgeführt wurde, unter Verwendung derselben Proportion gemessen.
Dank dieser Verbesserung können Sie die proportionale Bedeutung pro Cluster (oder Site) festlegen. Weitere Informationen finden Sie im Abschnitt Proportionale Bedeutung von Statusinformationen.
Dieses Merkmal gilt für alle Komponenten von Network Dispatcher.
Network Dispatcher bietet jetzt die Möglichkeit, einen physischen Server in mehrere logische Server zu partitionieren. Dadurch können Sie beispielsweise bei einem bestimmten Dienst auf der Maschine nachfragen, ob eine Servlet-Steuerkomponente oder eine Datenbankanforderung schneller oder gar nicht ausgeführt wird. Durch diese Verbesserung können Sie die Last ausgehend von einer detaillierteren dienstspezifischen Auslastung verteilen. Weitere Informationen hierzu finden Sie im Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Doese Funktion ist für die Komponenten Dispatcher und CBR verfügbar.
Mit dieser Erweiterung der HTTP-Advisor-Funktion können Sie den Status einzelner Dienste auf einem Server bewerten. Sie können für jeden logischen Server am HTTP-Port eine eindeutige HTTP-URL-Zeichenfolge festlegen, die speziell für den Dienst gilt, den Sie vom Server abfragen möchten. Weitere Informationen hierzu finden Sie im Abschnitt Option 'Anforderung/Antwort (URL)' der HTTP-Advisor-Funktion.
Diese Funktionen sind für alle Komponenten von Network Dispatcher verfügbar.
Mit Network Dispatcher können Sie verschiedene Advisor-Funktionen starten, die über einen Port ausgeführt werden, jedoch für unterschiedliche Cluster (Sites) konfiguriert wurden. Sie können beispielsweise eine HTTP-Advisor-Funktion am Port 80 für einen Cluster (eine Site) und eine angepasste Advisor-Funktion am Port 80 für einen anderen Cluster (eine andere Site) verwenden. Weitere Informationen hierzu finden Sie im Abschnitt Advisor-Funktion starten und stoppen.
Dieses Merkmal gilt für die Dispatcher-Komponente.
Dank dieser Erweiterung kann der Dispatcher potenzielle DoS-Attacken (Denial of Service) erkennen und Administratoren per Alert darauf aufmerksam machen. Zu diesem Zweck analysiert der Dispatcher eingehende Anforderungen auf eine verdächtig hohe Anzahl halboffener Verbindungen, die ein allgemeines Kennzeichen einfacher DoS-Attacken sind.
Weitere Informationen hierzu finden Sie im Abschnitt Erkennung von DoS-Attacken.
Dieses Merkmal gilt für alle Komponenten mit Ausnahme von Consultant für Cisco CSS Switches und Site Selector.
Network Dispatcher stellt zusätzliche Benutzer-Exits 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 Protokollieren der Änderung einer hohen Verfügbarkeit oder das Informieren eines Administrators über nicht aktive Server per Alert. Network Dispatcher stellt die folgenden neuen Beispiel-Script-Dateien bereit:
Diese Funktion ist für die Dispatcher-Komponente verfügbar.
Der Dispatcher stellt eine DB2-Advisor-Funktion bereit, die mit den DB2-Servern kommuniziert. Weitere Informationen zur DB2-Advisor-Funktion finden Sie im Abschnitt Liste der Advisor-Funktionen.
Die fünf Komponenten von Network Dispatcher sind Dispatcher, Content Based Routing (CBR), Mailbox Locator, Site Selector und Consultant für Cisco CSS Switches. Network Dispatcher bietet Ihnen die Möglichkeit, die Komponenten flexibel entsprechend der Konfiguration Ihrer Site einzeln oder zusammen zu verwenden. Dieser Abschnitt gibt einen Überblick über die Komponenten.
Die Dispatcher-Komponente verteilt den Datenverkehr mit einer Kombination von Lastausgleichs- und Verwaltungssoftware auf Ihre Server. Der Dispatcher kann auch einen ausgefallenen Server erkennen und den Datenverkehr entsprechend umleiten. Dispatcher unterstützt HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet sowie alle anderen TCP-basierten bzw. kontextlosen UDP-basierten Anwendungen.
Alle an die Dispatcher-Maschine gesendeten Client-Anforderungen werden auf der Basis dynamisch festgelegter Wertigkeiten an den "besten" Server übertragen. Für diese Wertigkeiten können Sie Standardwerte benutzen oder die Werte während des Konfigurationsprozesses ändern.
Dispatcher kann drei Weiterleitungsmethoden anwenden (die für den Port angegeben werden):
Die Dispatcher-Komponente ist der Schlüssel für eine stabile, effiziente Verwaltung eines großen skalierbaren Servernetzes. Mit Network Dispatcher können Sie viele einzelne Server so verbinden, dass sie ein virtueller Server zu sein scheinen. Besucher halten Ihre Site daher für eine einzelne IP-Adresse. Der Dispatcher arbeitet unabhängig von einem Domänennamensserver. Alle Anforderungen werden an die IP-Adresse der Dispatcher-Maschine gesendet.
Der Dispatcher bringt klare Vorteile bei der Lastverteilung auf geclusterte Server und ermöglicht daher eine stabile und effiziente Verwaltung Ihrer Site.
In Abbildung 6 wird die physische Darstellung der Site mit einer Ethernet-Netzkonfiguration gezeigt. Die Dispatcher-Maschine kann installiert werden, ohne dass physische Änderungen am Netz erforderlich sind. Nachdem der Dispatcher eine Client-Anforderung an den optimalen Server übertragen hat, wird die Antwort mit der MAC-Weiterleitungsmethode ohne Eingriff des Dispatchers direkt vom Server an den Client gesendet.
Abbildung 7. Beispielsite mit Dispatcher und Metric Server für die Serververwaltung
In Abbildung 7 wird eine Site gezeigt, in der sich alle Server in einem lokalen Netz befinden. Die Dispatcher-Komponente leitet Anforderungen weiter und Metric Server stellt der Dispatcher-Maschine Informationen zur Systembelastung zur Verfügung.
In diesem Beispiel ist der Metric-Server-Dämon auf allen Servern installiert. Sie können Metric Server zusammen mit der Dispatcher-Komponente oder einer beliebigen anderen Komponente von Network Dispatcher verwenden.
Abbildung 8. Beispiel für eine Site mit Dispatcher für die Verwaltung lokaler und ferner Server
Die Weitverkehrsunterstützung von Dispatcher ermöglicht Ihnen die Verwendung lokaler und ferner Server (d. h. Server in anderen Teilnetzen). Abbildung 8 zeigt eine Konfiguration, bei der ein lokaler Dispatcher (Dispatcher 1) als Eingangspunkt für alle Anforderungen dient. Er verteilt diese Anforderungen auf seine lokalen Server (ServerA, ServerB, ServerC) und den fernen Dispatcher (Dispatcher 2), der die Last auf seine lokalen Server (ServerG, ServerH, ServerI) verteilt.
Wenn Sie die NAT-Weiterleitungsmethode oder die GRE-Unterstützung von Dispatcher nutzen, können Sie eine Weitverkehrsunterstützung auch ohne Verwendung eines Dispatchers am fernen Standort (wo sich ServerD, ServerE und ServerF befinden ) erreichen. Weitere Informationen hierzu finden Sie in den Abschnitten NAT/NAPT-Weiterleitungsmethode (nat) des Dispatchers und Unterstützung für GRE (Generic Routing Encapsulation).
CBR arbeitet mit Caching Proxy zusammen, um Client-Anforderungen an angegebene HTTP- oder HTTPS-Server (SSL) weiterzuleiten. Diese Komponente ermöglicht die Bearbeitung von Caching-Angaben für ein schnelleres Abrufen von Webdokumenten mit geringen Anforderungen an die Netzbandbreite. CBR überprüft zusammen mit Caching Proxy HTTP-Anforderungen anhand angegebener Regeltypen.
Bei Verwendung von CBR können Sie eine Gruppe von Servern angeben, die eine Anforderung ausgehend von der Übereinstimmung eines regulären Ausdrucks mit dem Inhalt der Anforderung bearbeiten. Da CBR die Angabe mehrerer Server für jede Art von Anforderung zulässt, können die Anforderungen so verteilt werden, dass eine optimale Client-Antwortzeit erreicht wird. CBR erkennt auch, wenn ein Server in einer Gruppe ausgefallen ist. In diesem Fall werden keine weiteren Anforderungen an diesen Server weitergeleitet. Der von der CBR-Komponente verwendete Lastausgleichsalgorithmus ist mit dem bewährten Algorithmus identisch, der von der Dispatcher-Komponente verwendet wird.
Wenn Caching Proxy eine Anfrage empfängt, wird diese mit den Regeln, die für die CBR-Komponente definiert wurden, abgeglichen. Wird eine Übereinstimmung gefunden, wird einer der Server, die dieser Regel zugeordnet sind, für die Bearbeitung der Anforderung ausgewählt. Caching Proxy führt dann die normale Verarbeitung aus, um die Anfrage an den ausgewählten Server weiterzuleiten.
CBR stellt mit Ausnahme der hohen hoher Verfügbarkeit, des Subagenten, der Weitverkehrsunterstützung und einiger anderer Konfigurationsbefehle dieselben Funktionen wie der Dispatcher bereit.
CBR kann erst mit dem Lastausgleich für Client-Anfragen beginnen, wenn Caching Proxy aktiv ist.
Abbildung 9. Beispielsite mit CBR für die Verwaltung lokaler Server
Abbildung 9 zeigt die logische Darstellung einer Site, bei der ein Teil der Inhalte von lokalen Server mit CBR weitergeleitet wird. Die CBR-Komponente leitet mit Caching Proxy Client-Anfragen (HTTP oder HTTPS) ausgehend vom Inhalt des URL an die Server weiter.
Mailbox Locator kann ein Anlaufpunkt für viele IMAP- oder POP3-Server sein. Jeder Server kann einen Teil der Benutzer-Mailboxes vom Anlaufpunkt bedienen lassen. Für IMAP- und POP3-Datenverkehr ist Mailbox Locator ein Proxy, der ausgehend von der vom Client bereitgestellten Benutzer-ID mit Kennwort einen geeigneten Server auswählt. Mailbox Locator bietet keine Unterstützung für den regelgestützten Lastausgleich.
Abbildung 10. Beispielsite mit Mailbox Locator für die Verwaltung lokaler Server
Abbildung 10 zeigt die logische Darstellung einer Site, bei der Mailbox Locator Client-Anfragen (Protokoll IMAP oder POP3) ausgehend von Benutzer-ID und Kennwort an einen geeigneten Server weiterleitet.
Site Selector fungiert als Namensserver und führt zusammen mit anderen Namensservern in einem Domänennamenssystem auf der Grundlage abgerufener Messungen und Wertigkeiten einen Lastausgleich für Servergruppen durch. Sie können eine Sitekonfiguration erstellen, bei der die Last innerhalb einer Servergruppe auf der Grundlage des für eine Client-Anfrage verwendeten Domänennamens verteilt wird.
Ein Client fordert die Auflösung eines Domänennamens bei einem Namensserver innerhalb seines Netzes an. Der Namensserver leitet die Anforderung an die Site-Selector-Maschine weiter. Site Selector löst den Domänennamen dann in die IP-Adresse eines der Server auf, die für den Sitenamen konfiguriert wurden. Anschließend gibt Site Selector die IP-Adresse des ausgewählten Servers an den Namensserver zurück. Der Namensserver liefert die IP-Adresse an den Client.
Metric Server ist eine Systemüberwachungskomponente von Network Dispatcher, die auf jedem am Lastausgleich beteiligten Server innerhalb der Konfiguration installiert sein muss. Mit Metric Server kann Site Selector das Aktivitätsniveau eines Servers überwachen, den Server mit der geringsten Auslastung ermitteln und einen ausgefallenen Server erkennen. Die Auslastung eines Servers ist ein Maß für das Arbeitsvolumen des Servers. Durch Anpassung der Script-Dateien für Systemmesswerte können Sie steuern, auf welche Art die Last gemessen wird. Sie können Site Selector an die Anforderungen der eigenen Umgebung anpassen und dabei Faktoren wie die Zugriffshäufigkeit, die Gesamtzahl der Benutzer und die Zugriffsarten (beispielsweise kurze Abfragen, lange Abfragen, Transaktionen mit hoher CPU-Belastung) berücksichtigen.
Abbildung 11 stellt eine Site dar, bei der die Komponente Site Selector Anfragen beantwortet. Server1, Server2 und Server3 sind lokale Server. Server4, Server5 und Server6 sind ferne Server.
Ein Client fordert die Auflösung eines Domänennamens bei einem Client-Namensserver an. Der Client-Namensserver leitet die Anfrage über den DNS an die Site-Selector-Maschine weiter (Pfad 1). Site Selector löst den Domänennamen dann in die IP-Adresse eines der Server auf. Anschließend gibt Site Selector die IP-Adresse des ausgewählten Servers an den Client-Namensserver zurück. Der Namensserver liefert die IP-Adresse an den Client.
Sobald der Client die IP-Adresse des Servers empfangen hat, leitet er alle folgenden Anfragen direkt an den ausgewählten Server weiter (Pfad 2).
Consultant für Cisco CSS Switches ist eine ergänzende Lösung für die CSS 11000 Series Switches von Cisco. Die kombinierte Lösung verbindet die zuverlässige Paket- und Inhaltsweiterleitung der CSS 11000 Series mit den ausgeklügelten Erkennungsalgorithmen von Network Dispatcher, um die Verfügbarkeit von Back-End-Servern, Anwendungen und Datenbanken festzustellen und Informationen zu laden. Cisco Consultant verwendet den Manager, die standardmäßigen und benutzerdefinierten Advisor-Funktionen von Network Dispatcher sowie Metric Server, um die Messwerte, den Zustand und die Belastung von Back-End-Servern, Anwendungen und Datenbanken zu ermitteln. Aus diesen Informationen generiert Cisco Consultant Messwerte für die Servergewichtung, die dann zur Erreichung einer optimalen Serverauswahl sowie von Lastoptimierung und Fehlertoleranz an den Cisco CSS Switch gesendet werden.
Der Cisco CSS Switch trifft seine Entscheidungen bezüglich des Lastausgleichs auf der Grundlage benutzerdefinierter Kriterien.
Cisco Consultant protokolliert zahlreiche Kriterien. Dazu gehören unter anderem:
Wenn ein Cisco CSS Switch ohne Cisco Consultant den Zustand eines Inhalte bereitstellenden Servers ermittelt, greift er dabei auf die Antwortzeiten für Inhaltsanfragen und andere Netzmesswerte zurück. Wird Cisco Consultant verwendet, gehen diese Aktivitäten vom Cisco CSS Switch auf Cisco Consultant über. Cisco Consultant beeinflusst die Fähigkeit des Servers, Inhalte bereitzustellen, und aktiviert einen Server als geeigneten Server, wenn dieser verfügbar ist, bzw. stellt ihn als geeigneten Server zurück, wenn dieser nicht mehr verfügbar ist.
Cisco Consultant:
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. Wenn ein Server beispielsweise die Wertigkeit 10 und ein anderer die Wertigkeit 5 hat, sollte der Server mit der Wertigkeit 10 doppelt so viele Anfragen erhalten wie der Server mit der Wertigkeit 5. Diese Wertigkeiten werden dem Cisco CSS Switch mit SNMP zur Verfügung gestellt. Wird ein Server mit einer höheren Wertigkeit eingestuft, überträgt der Cisco CSS Switch mehr Anfragen an diesen Server.
Abbildung 12. Beispielsite mit Cisco Consultant und Metric Server für die Verwaltung lokaler Server
Cisco Consultant ist in Verbindung mit dem Cisco CSS Switch eine Lösung, die das "Beste aus zwei Welten" auf sich vereint, super schnelles Content-Switching und ausgeklügelte Anwendungserkennung, Fehlertoleranz sowie optimale Serverauslastung. Cisco Consultant ist Bestandteil einer ergänzenden Lösung für den Cisco CSS Switch und IBM WebSphere Edge Server.
In Kapitel 2, Network Dispatcher installieren finden Sie eine Liste der Voraussetzungen für Cisco Consultant.
Die Dispatcher-Komponente stellt eine integrierte Funktion für hohe Verfügbarkeit bereit. Für diese Funktion ist eine zweite Dispatcher-Maschine erforderlich, die die primäre Maschine überwacht und den Lastausgleich übernehmen kann, wenn die primäre Maschine ausfällt. Die Dispatcher-Komponente gewährleistet außerdem eine gegenseitige hohe Verfügbarkeit, so dass sowohl die primäre als auch die sekundäre Maschine die jeweils andere Maschine als Ausweichmaschine nutzen kann. Lesen Sie hierzu die Informationen im Abschnitt Hohe Verfügbarkeit konfigurieren.
Durch eine Client-/Serverkonfiguration mit einer Dispatcher-Maschine, bei der der Datenverkehr auf zwei oder mehr Servermaschinen mit CBR, Mailbox Locator oder Site Selector verteilt wird, können Sie für diese Komponenten von Network Dispatcher ein hohes Maß an Verfügbarkeit erreichen.
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Dispatcher-Komponente berücksichtigen muss.
Dieses Kapitel enthält die folgenden Abschnitte:
Plattformvoraussetzungen:
Der Dispatcher stellt die folgenden Funktionen bereit:
Die Benutzung des Managers ist optional. Ohne den Manager wird der Lastausgleich nach einer gewichteten RoundRobin-Zeitplanung und ausgehend von den aktuellen Serverwertigkeiten durchgeführt. Es stehen keine Advisor-Funktionen zur Verfügung.
Dispatcher bietet außerdem Advisor-Funktionen an, die keine protokollspezifischen Informationen austauschen. Dazu gehören unter anderem die DB2-Advisor-Funktion, die Angaben zum Status von DB2-Servern macht, und die Ping-Advisor-Funktion, die meldet, ob der Server auf ein gesendetes "ping" antwortet. Eine vollständige Liste der Advisor-Funktionen finden Sie im Abschnitt Liste der Advisor-Funktionen.
Sie haben auch die Möglichkeit, eigene Advisor-Funktionen zu schreiben. (Lesen Sie hierzu die Informationen im Abschnitt Kundenspezifische (anpassbare) Advisor-Funktion erstellen.)
Die Benutzung der Advisor-Funktionen ist optional, wird jedoch empfohlen.
Die drei Schlüsselfunktionen des Dispatchers (Executor, Manager und Advisor) kommunizieren miteinander, um die eingehenden Anforderungen auf die Server zu verteilen. Neben Lastausgleichsanforderungen überwacht der Executor die Anzahl neuer, aktiver und beendeter Verbindungen. Der Executor übernimmt auch die Garbage Collection für beendete oder zurückgesetzte Verbindungen und stellt diese Informationen dem Manager zur Verfügung.
Der Manager stellt Informationen vom Executor, von den Advisor-Funktionen und von einem Systemüberwachungsprogramm wie Metric Server zusammen. Der Manager passt anhand der erhaltenen Informationen die Wertigkeit der Servermaschinen an den einzelnen Ports an und teilt dem Executor die neue Wertigkeit mit, die dieser dann beim Lastausgleich für neue Verbindungen verwendet.
Die Advisor-Funktionen überwachen die einzelnen Server am zugeordneten Port, um Antwortzeit und Verfügbarkeit der Server zu ermitteln, und übergeben diese Informationen an den Manager. Die Advisor-Funktionen überwachen zudem, ob ein Server aktiv oder inaktiv ist. Ohne Manager und Advisor-Funktionen wendet der Executor eine RoundRobin-Zeitplanung auf der Basis der aktuellen Serverwertigkeiten an.
Abbildung 13. Beispiel für einen Dispatcher mit einfacher hoher Verfügbarkeit
Die Funktion für hohe Verfügbarkeit erfordert eine zweite Dispatcher-Maschine. Die erste Dispatcher-Maschine führt den Lastausgleich für den gesamten Client-Datenverkehr aus, wie dies in einer Konfiguration mit einem einzelnen Dispatcher geschehen würde. Die zweite Dispatcher-Maschine überwacht den "Zustand" der ersten Maschine und übernimmt die Task des Lastausgleichs, wenn sie erkennt, dass die erste Dispatcher-Maschine ausgefallen ist.
Jeder der beiden Maschinen wird eine bestimmte Rolle zugewiesen, entweder die der primären Maschine (primary) oder die der Ausweichmaschine (backup). Die primäre Maschine sendet ständig Verbindungsdaten an die Partnermaschine. Während die primäre Maschine aktiv ist (den Lastausgleich durchführt), befindet sich die Partnermaschine in Bereitschaft. Sie wird ständig aktualisiert und ist bereit, den Lastausgleich zu übernehmen, falls dies erforderlich ist.
Die Übertragungssitzungen zwischen den beiden Maschinen werden als Überwachungssignale bezeichnet. Mit Hilfe der Überwachungssignale kann jede Maschine den Zustand der anderen Maschine überwachen.
Stellt die Ausweichmaschine fest, dass die aktive Maschine ausgefallen ist, übernimmt sie deren Aufgaben und beginnt mit dem Lastausgleich. An diesem Punkt kehrt sich der Status der beiden Maschinen um: die Partnermaschine wird zur aktiven Maschine und die primäre Maschine wird zur Maschine in Bereitschaft.
In der Konfiguration mit hoher Verfügbarkeit müssen sich die primäre Maschine und die Partnermaschine innerhalb eines Teilnetzes befinden.
Informationen zum Konfigurieren der hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit.
Abbildung 14. Beispiel für einen Dispatcher mit gegenseitiger hoher Verfügbarkeit
Für die gegenseitige hohe Verfügbarkeit sind zwei Dispatcher-Maschinen erforderlich. Beide Maschinen führen aktiv den Lastausgleich des Client-Datenverkehrs aus und beide Maschinen sind gleichzeitig Partnermaschinen. In einer Konfiguration mit einfacher hoher Verfügbarkeit führt nur eine Maschine den Lastausgleich durch. In einer Konfiguration mit gegenseitiger hoher Verfügbarkeit verteilen beide Maschinen einen Teil des Client-Datenverkehrs.
Bei der gegenseitigen hohen Verfügbarkeit wird jeder der Client-Datenverkehr den Dispatcher-Maschinen auf der Basis einer Cluster-Adresse zugeordnet. Jeder Cluster kann mit der nicht für Weiterleitungszwecke bestimmten Adresse (NFA, nonforwarding Address) seines primären Dispatchers konfiguriert werden. Die primäre Dispatcher-Maschine führt normalerweise den Lastausgleich für diesen Cluster durch. Fällt die Maschine aus, führt die andere Maschine den Lastausgleich für ihren eigenen Cluster und für den Cluster des ausgefallenen Dispatchers durch.
Abbildung 14 zeigt eine Beispielkonfiguration mit gegenseitiger hoher Verfügbarkeit, bei der die "Cluster-Gruppe A" und die "Cluster-Gruppe B" gemeinsam benutzt werden. Jeder Dispatcher kann aktiv für seinen primären Cluster bestimmte Pakete weiterleiten. Fällt einer der Dispatcher aus, so dass er nicht länger aktiv für seinen primären Cluster bestimmte Pakete weiterleiten kann, übernimmt der andere Dispatcher die Weiterleitung der Pakete zu seinem Ausweich-Cluster.
Informationen zum Konfigurieren der hohen Verfügbarkeit und der gegenseitigen hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit.
Wenn der Dispatcher seine Standardweiterleitungsmethode, die MAC-Weiterleitung, anwendet, werden die eingehenden Anforderungen an den ausgewählten Server weitergeleitet. Der Server gibt die Antwort direkt, d. h. ohne Eingreifen des Dispatchers, an den Client zurück. Bei dieser Methode der Weiterleitung achtet der Dispatcher nur auf den beim Server eingehenden Datenfluss vom Client, nicht aber auf den abgehenden Datenfluss vom Server zum Client. Dies führt zu einer erheblichen Reduzierung der Auswirkungen auf die Anwendung und zu einem verbesserten Durchsatz im Netz.
Sie können die Weiterleitungsmethode auswählen, wenn Sie mit dem Befehl ndcontrol port add Cluster:Port method Wert einen Port hinzufügen. Der Wert für die Standardweiterleitungsmethode ist mac. Die Parameter für die Methode können Sie nur beim Hinzufügen des Ports angeben. Ist der Port hinzugefügt, können Sie die Einstellung für die Weiterleitungsmethode nicht mehr ändern. Weitere Informationen hierzu finden Sie im Abschnitt ndcontrol port -- Ports konfigurieren.
Bei Verwendung der Dispatcher-Methode NAT (Konvertierung von Netzadressen) bzw. NAPT (Port-Umsetzung für Netzadressen) entfällt die Einschränkung, dass sich die am Lastausgleich beteiligten Server in einem lokal angeschlossenen Netz befinden müssen. Falls Sie Server an fernen Standorten haben, sollten Sie anstelle einer GRE/WAND-Kapselungstechnik die NAT-Weiterleitungsmethode anwenden. Mit NAPT können Sie außerdem auf mehrere Serverdämonen zugreifen, die sich auf den einzelnen am Lastausgleich beteiligten Servermaschinen befinden und jeweils an einem eindeutigen Port empfangsbereit sind.
Einen Server mit mehreren Dämonen können Sie auf die beiden folgenden Arten konfigurieren:
Diese Anwendung funktioniert gut mit höheren Anwendungsprotokollen wie HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet usw.
Einschränkungen:
Sie können NAT/NAPT wie folgt implementieren:
ndcontrol server add Cluster:Port:Server mapport Wert returnaddress Rückkehradresse router Router-Adresse
Dieser Parameter ordnet die (für den Dispatcher bestimmte) Nummer des Ziel-Ports für die Client-Anforderung der Nummer des Server-Ports zu, an dem der Dispatcher die Client-Anforderungen verteilt. Mit "mapport" kann Network Dispatcher die Anforderung eines Clients an einem Port empfangen und an einen anderen Port der Servermaschine übertragen. Mit "mapport" können Sie den Lastausgleich für die Anforderungen eines Clients auf einer Servermaschine mit mehreren Serverdämonen durchführen. Der Standardwert für "mapport" ist die Nummer des Ziel-Ports für die Client-Anforderung.
Die Rückkehradresse ist eine eindeutige Adresse oder ein Host-Name, die bzw. den Sie auf der Dispatcher-Maschine konfigurieren. Der Dispatcher verwendet die Rückkehradresse beim Lastausgleich für die Client-Anforderung auf dem Server als Quellenadresse. Auf diese Weise wird sichergestellt, dass der Server das Paket an die Dispatcher-Maschine zurückgibt und es nicht direkt an den Client sendet. (Der Dispatcher leitet das IP-Paket dann an den Client weiter.) Sie müssen den Wert für die Rückkehradresse beim Hinzufügen des Servers angeben. Die Rückkehradresse kann nur geändert werden, wenn Sie den Server entfernen und dann erneut hinzufügen. Die Rückkehradresse darf nicht mit dem Wert für Cluster, Server oder NFA übereinstimmen.
Die Adresse des Routers zum fernen Server.
In früheren Releases von Network Dispatcher war das Content Based Routing nur bei Verwendung der CBR-Komponente zusammen mit Caching Proxy verfügbar. Jetzt können Sie mit der Dispatcher-Komponente das Content Based Routing für HTTP (unter Verwendung des Regeltyps "content") und für HTTPS (unter Verwendung der Affinität von SSL-Sitzungs-IDs) ohne Caching Proxy ausführen. Für HTTP- und HTTPS-Datenverkehr ist das Content Based Routing der Dispatcher-Komponente schneller als das der CBR-Komponente.
Für HTTP: Die Serverauswahl für die inhaltsabhängige Weiterleitung basiert auf dem Inhalt eines URL oder eines HTTP-Headers. Sie wird mit dem Regeltyp "content" konfiguriert. Wenn Sie die content-Regel konfigurieren, geben Sie für die Regel den Suchbegriff (das Muster) und eine Gruppe von Servern an. Beim Verarbeiten einer neu eingehenden Anforderung vergleicht diese Regel die angegebene Zeichenfolge mit dem URL des Clients oder mit dem in der Client-Anforderung angegebenen HTTP-Header.
Findet der Dispatcher die Zeichenfolge in der Client-Anforderung, leitet er diese an einen der für die Regel definierten Server weiter. Anschließend gibt der Dispatcher die Antwortdaten vom Server an den Client zurück (Weiterleitungsmethode "cbr").
Findet der Dispatcher die Zeichenfolge nicht in der Client-Anforderung, wählt er keinen der für die Regel definierten Server aus.
Für HTTPS (SSL): Bei der inhaltsabhängigen Weiterleitung von Dispatcher erfolgt der Lastausgleich ausgehend vom Feld für die SSL-Sitzungs-ID in der Client-Anforderung. Bei Verwendung von SSL enthält eine Client-Anforderung die SSL-Sitzungs-ID einer früheren Sitzung und Server speichern ihre früheren SSL-Verbindungen im Cache. Durch die Dispatcher-Funktion für Affinität der SSL-Sitzungs-ID können Client und Server eine neue Verbindung aufbauen und dafür die Sicherheitsparameter der vorherigen Verbindung zum Server verwenden. Da SSL-Sicherheitsparameter wie gemeinsam verwendete Schlüssel und Verschlüsselungsalgorithmen nicht neu ausgehandelt werden müssen, benötigen die Server weniger CPU-Zyklen und der Client erhält schneller eine Antwort. Zum Aktivieren der Affinität von SSL-Sitzungs-IDs muss stickytime für den Port auf einen Wert ungleich null gesetzt werden. Wenn die Haltezeit (stickytime) abgelaufen ist, wird der Client unter Umständen an einen anderen als den vorherigen Server verwiesen.
Sie können die inhaltsabhängige Weiterleitung (Weiterleitungsmethode cbr) wie folgt implementieren:
ndcontrol server add Cluster:Port:Server mapport Wert returnaddress Rückkehradresse router Router-Adresse
ndcontrol rule 125.22.22.03:80:content-Regel1 type content pattern Muster
Muster gibt hier das für den Regeltyp "content" zu verwendende Muster an. Weitere Informationen zum Regeltyp "content" finden Sie im Abschnitt Regeln verwenden, die auf dem Inhalt der Anforderung basieren. Weitere Informationen zu gültigen Ausdrücken für Muster können Sie Anhang C, Syntax der content-Regel entnehmen.
Für HTTPS (SSL): Zum Konfigurieren der Affinität von SSL-Sitzungs-IDs muss der Parameter stickytime für den Port auf einen Wert ungleich null gesetzt werden. Weitere Informationen zum Parameter stickytime des port-Befehls finden Sie im Abschnitt ndcontrol rule -- Regeln konfigurieren.
Lesen Sie vor Ausführung der in diesem Kapitel beschriebenen Schritte Kapitel 4, Planung für Dispatcher. Dieses Kapitel erläutert das Erstellen einer Basiskonfiguration für die Dispatcher-Komponente von Network Dispatcher.
Tabelle 3. Konfigurations-Tasks für Dispatcher
Task | Beschreibung | Referenzinformationen |
---|---|---|
Dispatcher-Maschine konfigurieren |
Definieren Sie Ihre Lastausgleichskonfiguration.
| Dispatcher-Maschine konfigurieren |
Am Lastausgleich beteiligte Maschinen konfigurieren. | Definieren Sie einen Aliasnamen für die Loopback-Einheit. Überprüfen Sie, ob eine zusätzliche Route vorhanden ist und löschen Sie zusätzliche Routes. | Servermaschinen für Lastausgleich konfigurieren |
Es gibt vier grundlegende Methoden für die Konfiguration des Dispatchers:
Dies ist die direkte Methode für die Konfiguration des Dispatchers. Die Werte der Befehlsparameter müssen in englischen Zeichen eingegeben werden. Die einzige Ausnahme hiervon bilden Host-Namen (die in den Befehlen "cluster", "server" und "highavailability" verwendet werden) und (die in Dateibefehlen verwendeten) Dateinamen.
Starten Sie den Dispatcher wie folgt von der Befehlszeile aus:
Sie können eine Minimalversion der Parameter für den Befehl "ndcontrol" eingeben. Sie müssen nur die eindeutigen Buchstaben der Parameter eingeben. Beispiel: Wenn Sie Hilfe für den Befehl zum Speichern von Dateien aufrufen möchten, können Sie ndcontrol he f anstelle von ndcontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl ndcontrol ab, um die Eingabeaufforderung "ndcontrol" aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Die Befehle für die Konfiguration des Dispatchers können in eine Konfigurations-Script-Datei eingegeben und zusammen ausgeführt werden. Lesen Sie hierzu die Informationen im Abschnitt Beispielkonfigurationsdateien für Network Dispatcher.
ndcontrol file appendload meinScript
ndcontrol file newload meinScript
Abbildung 2 zeigt ein Beispiel für die grafische Benutzerschnittstelle (GUI).
Gehen Sie zum Starten der GUI wie folgt vor:
ndserver
Zum Konfigurieren von Dispatcher auf der GUI müssen Sie zunächst in der Baumstruktur Dispatcher auswählen. Sie können den Executor und den Manager starten, sobald Sie eine Verbindung zu einem Host hergestellt haben. Sie können auch Cluster mit Ports und Servern erstellen und Advisor-Funktionen für den Manager starten.
Mit der GUI können Sie dieselben Tasks wie mit dem Befehl ndcontrol ausführen. Zum Definieren eines Clusters von der Befehlszeile aus müssten Sie beispielsweise den Befehl ndcontrol cluster add Cluster eingeben. Zum Definieren eines Clusters von der GUI aus müssen Sie mit der rechten Maustaste auf "Executor" klicken und im daraufhin angezeigten Popup-Menü mit der linken Taste auf Cluster hinzufügen. Geben Sie die Cluster-Adresse in das Dialogfenster ein und klicken Sie dann auf OK.
Bereits vorhandene Dispatcher-Konfigurationsdateien können Sie mit der im Popup-Menü Host angezeigten Option Neue Konfiguration laden (zum vollständigen Ersetzen der derzeitigen Konfiguration) oder An aktuelle Konfiguration anfügen (zum Aktualisieren der derzeitigen Konfiguration) laden. Sie sollten Ihre Dispatcher-Konfiguration von Zeit zu Zeit mit der Option Konfigurationsdatei sichern unter in einer Datei sichern. Diese Option ist ebenfalls im Popup-Menü Host enthalten. ^Das oben auf der GUI befindliche Menü Datei bietet Ihnen die Möglichkeit, die aktuellen Host-Verbindungen in einer Datei zu speichern oder Verbindungen aus vorhandenen Dateien für alle Komponenten von Network Dispatcher wiederherzustellen.
Die Konfigurationsbefehle können auch auf einem fernen System ausgeführt werden. Weitere Informationen hierzu finden Sie im Abschnitt Authentifizierte Fernverwaltung.
Sie können auf Hilfe zugreifen, indem Sie auf das Fragezeichen in der oberen rechten Ecke des Fensters von Network Dispatcher klicken.
Weitere Informationen zur Verwendung der GUI finden Sie im Abschnitt Allgemeine Anweisungen zur Verwendung der GUI.
Weitere Informationen zur die Verwendung des Konfigurationsassistenten finden Sie im Abschnitt Konfiguration mit dem Konfigurationsassistenten.
Vor dem Konfigurieren der Dispatcher-Maschine müssen Sie (unter AIX, Linux oder Solaris) als Benutzer "root" oder (unter Windows 2000) als Administrator registriert sein.
Unter AIX, Linux und Solaris kann Network Dispatcher mit einem Server verknüpft sein. Dies bedeutet, dass sich der Network Dispatcher physisch auf einer Servermaschine befinden kann, für die er einen Lastausgleich durchführt.
Sie benötigen mindestens zwei gültige IP-Adressen für die Dispatcher-Maschine:
Diese IP-Adresse ist die primäre IP-Adresse der Dispatcher-Maschine und wird als NFA (Nonforwarding Address) bezeichnet. Dies ist standardmäßig dieselbe Adresse wie die vom Befehl hostname zurückgegebene. Benutzen Sie diese Adresse, wenn Sie zu Verwaltungszwecken (z. B. für eine Fernkonfiguration über Telnet oder für den Zugriff auf den SNMP-Subangenten) eine Verbindung zur Maschine herstellen möchten. Kann die Dispatcher-Maschine bereits andere Maschinen im Netz über ping-Aufrufe erreichen, sind keine weiteren Aktionen zum Konfigurieren der NFA erforderlich.
Eine Cluster-Adresse ist eine Adresse, die einem Host-Namen zugeordnet ist (beispielsweise www.IhreFirma.com). Diese IP-Adresse wird von einem Client benutzt, um die Verbindung zu den Servern in einem Cluster herzustellen. An dieser Adresse führt der Dispatcher den Lastausgleich durch.
Nur Solaris:
Wenn Sie vorhaben, zwei 100-Mbit/s-Ethernet-Adapter zu verwenden, sollte die Datei ibmnd.conf eine Zeile mit der Einheitenangabe hme enthalten. Falls Sie einen 10-Mbit/s-Ethernet-Adapter und einen 100-Mbit/s-Ethernet-Adapter verwenden möchten, enthält die Datei ibmnd.conf zwei Zeilen, eine Zeile für die Einheit le und eine für die Einheit hme.
Die Datei ibmnd.conf stellt Vorgaben für den Solaris-Befehl autopush bereit und muss mit dem Befehl "autopush" kompatibel sein.
Sind die beiden Cluster X und Y für einen der in ibmnd.conf aufgelisteten Adapter beispielsweise für die Komponente Mailbox Locator konfiguriert, werden die Cluster X und Y aus der Konfiguration entfernt, sobald der Befehl ndcontrol executor start oder ndcontrol executor stop abgesetzt wird. Dieses Ergebnis ist unter Umständen nicht erwünscht. Wenn die Cluster X und Y im Script goAliases konfiguriert sind, werden Sie nach dem Starten oder Stoppen des Dispatcher-Executors automatisch rekonfiguriert.
Nur Windows 2000: Vergewissern Sie sich, dass die IP-Weiterleitung für das TCP/IP-Protokoll nicht aktiviert ist. (Vergleichen Sie dazu Ihre TCP/IP-Konfiguration unter Windows 2000.)
Abbildung 15 zeigt ein Beispiel für einen mit einem Cluster, zwei Ports und drei Servern kofigurierten Dispatcher.
Abbildung 15. Beispiel der für die Dispatcher-Maschine erforderlichen IP-Adressen
Hilfe zu den in dieser Prozedur verwendeten Befehlen finden Sie in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator.
Eine Beispielkonfigurationsdatei finden Sie im Abschnitt Beispielkonfigurationsdateien für Network Dispatcher.
AIX, Linux und Solaris: Geben Sie zum Starten der Serverfunktion ndserver ein.
Windows 2000: Die Serverfunktion wird automatisch als Dienst gestartet.
Geben Sie zum Starten der Executor-Funktion den Befehl ndcontrol executor start ein. Sie können jetzt auch verschiedene Executor-Einstellungen ändern. Weitere Informationen hierzu finden Sie in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator.
Die NFA wird benutzt, um zu Verwaltungszwecken (z. B. für die Verwendung von Telnet oder SMTP) eine Verbindung zur Maschine herzustellen. Standardmäßig ist diese Adresse der Host-Name.
Geben Sie zum Definieren der NFA den Befehl ndcontrol executor set nfa IP-Adresse ein oder editieren Sie die Beispielkonfigurationsdatei. Die IP-Adresse ist entweder ein symbolischer Name oder die Adresse in Schreibweise mit Trennzeichen.
Der Dispatcher verteilt die Last der an die Cluster-Adresse gesendeten Anforderungen auf die für die Ports dieses Clusters konfigurierten Server.
Der Cluster ist entweder der symbolische Name, die Adresse in Schreibweise mit Trennzeichen oder die spezielle Adresse 0.0.0.0, die einen Platzhalter-Cluster definiert. Setzen Sie zum Definieren eines Clusters den Befehl ndcontrol cluster add ab. Setzen Sie zum Definieren von Cluster-Optionen den Befehl ndcontrol cluster set ab oder verwenden Sie die GUI zum Absetzen von Befehlen. Platzhalter-Cluster können verwendet werden, wenn mehrere IP-Adressen für den Lastausgleich eingehender Pakete in Frage kommen. Weitere Informationen hierzu finden Sie in den Abschnitten Platzhalter-Cluster verwenden, um Serverkonfigurationen zusammenzufassen, Platzhalter-Cluster für den Lastausgleich von Firewalls verwenden und Platzhalter-Cluster mit Caching Proxy für transparente Weiterleitung verwenden.
Nachdem der Cluster definiert wurde, müssen Sie normalerweise die Cluster-Adresse auf einer der Netzschnittstellenkarten der Dispatcher-Maschine konfigurieren. Setzen Sie dazu den Befehl ndcontrol cluster configure Cluster-Adresse ab. Damit wird nach einem Adapter mit einer vorhandenen Adresse gesucht, die zu demselben Teilnetz wie die Cluster-Adresse gehört. Anschließend wird der Adapterkonfigurationsbefehl des Betriebssystems für die Cluster-Adresse unter Verwendung des gefundenen Adapters und der Netzmaske für die auf diesem Adapter vorhandene Adresse abgesetzt. Beispiel:
ndcontrol cluster configure 204.67.172.72
In manchen Fällen soll die Cluster-Adresse möglicherweise nicht konfiguriert werden. Dies gilt für Cluster, die zu einem Bereitschaftsserver im Modus für hohe Verfügbarkeit hinzugefügt wurden, oder für Cluster, die zu einem Weitverkehrs-Dispatcher hinzugefügt wurden, der als ferner Server dient. Sie müssen den Befehl cluster configure auch nicht ausführen, wenn Sie im Standalone-Modus das Beispiel-Script goIdle verwenden. Informationen zum Script goIdle finden Sie im Abschnitt Scripts verwenden.
In seltenen Fällen haben Sie möglicherweise eine Cluster-Adresse, die mit keinem Teilnetz für vorhandene Adressen übereinstimmt. Verwenden Sie in diesem Fall die zweite Form des Befehls cluster configure und geben Sie explizit den Schnittstellennamen und die Netzmaske an. Verwenden Sie ndcontrol cluster configure Cluster-Adresse Schnittstellenname Netzmaske.
Beispiele:
ndcontrol cluster configure 204.67.172.72 en0 255.255.0.0 (AIX) ndcontrol cluster configure 204.67.172.72 eth0:1 255.255.0.0 (Linux) ndcontrol cluster configure 204.67.172.72 le0:1 255.255.0.0 (Solaris 7) ndcontrol cluster configure 204.67.172.72 le0 255.255.0.0 (Solaris 8) ndcontrol cluster configure 204.67.172.72 en0 255.255.0.0 (Windows 2000)
Für die zweite Form des Befehls "cluster configure" müssen Sie unter Windows 2000 den zu verwendenden Schnittstellennamen ermitteln.
Befindet sich in Ihrer Maschine nur eine einzige Ethernet-Karte, lautet der Schnittstellenname en0. Befindet sich in Ihrer Maschine nur eine einzige Token-Ring-Karte, lautet der Schnittstellenname tr0. Befinden sich in Ihrer Maschine mehrere Karten beider Typen, müssen Sie die Zuordnung der Karten festlegen. Gehen Sie wie folgt vor:
Die Netzschnittstellenadapter sind unter Network Cards aufgeführt. Klicken Sie auf die einzelnen Karten, um festzustellen, ob es sich um eine Ethernet- oder Token-Ring-Schnittstelle handelt. Der Schnittstellentyp ist in der Spalte mit der Beschreibung aufgeführt. Die mit dem Befehl ndconfig zugeordneten Namen werden den Schnittstellentypen zugeordnet. Beispielsweise setzt ndconfig die erste Ethernet-Schnittstelle in der Liste auf en0, die zweite auf en1 usw., die erste Token-Ring-Schnittstelle auf tr0, die zweite auf tr1 usw.
Nachdem Sie diese Zuordnungsinformationen erhalten haben, können auf der Netzschnittstelle die Cluster-Adresse als Aliasnamen festlegen.
Der Befehl "cluster configure" führt nur ifconfig-Befehle (oder unter Windows 2000 ndconfig-Befehle) aus, so dass Sie bei Bedarf auch die ifconfig-Befehle (bzw. ndconfig-Befehle) verwenden können.
Die Dispatcher-Komponente bietet den Befehl ndconfig an, um Cluster-Aliasnamen von der Befehlszeile aus zu konfigurieren. Der Befehl ndconfig hat dieselbe Syntax wie ein ifconfig-Befehl unter UNIX.
ndconfig en0 alias 204.67.172.72 netmask 255.255.0.0
Verwenden Sie zur Bestimmung des Schnittstellennamens dieselbe Technik wie für die zweite Form des Befehls cluster configure.
Bei Verwendung von bindungsspezifischen Serveranwendungen , die an eine Liste von IP-Adressen ohne die IP-Adresse des Servers gebunden werden, verwenden Sie anstelle von "ifconfig" den Befehl arp publish, um auf der Network-Dispatcher-Maschine dynamisch eine IP-Adresse festzulegen. Beispiel:
arp -s <Cluster> <Network-Dispatcher-MAC-Adresse> pub
Zum Definieren eines Ports können Sie den Befehl ndcontrol port add Cluster:Port eingeben, die Beispielkonfigurationsdatei editieren oder die GUI verwenden. Cluster ist entweder der symbolische Name oder die Adresse in Schreibweise mit Trennzeichen. Port ist die Nummer des Ports, den Sie für dieses Protokoll verwenden. Sie können jetzt auch verschiedene Port-Einstellungen ändern. Sie müssen alle Server für einen Port definieren und konfigurieren. Lesen Sie hierzu die Informationen in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator.
Mit der Port-Nummer 0 (null) wird ein Platzhalter-Port angegeben. Dieser Port akzeptiert Datenverkehr, der nicht für einen der definierten Ports eines Clusters bestimmt ist. Der Platzhalter-Port wird zum Konfigurieren von Regeln und Servern für alle Ports verwendet. Diese Funktion kann auch verwendet werden, wenn Sie eine identische Server-/Regelkonfiguration für mehrere Ports haben. Der Datenverkehr an einem Port könnte dann die Lastausgleichsentscheidungen für Datenverkehr an anderen Ports beeinflussen. Weitere Informationen zur Verwendung eines Platzhalter-Ports finden Sie im Abschnitt Platzhalter-Port für die Übertragung von Datenverkehr mit nicht konfiguriertem Port verwenden.
Geben Sie zum Definieren einer am Laustausgleich beteiligten Servermaschine den Befehl ndcontrol server add Cluster:Port:Server ein. Sie können auch die Beispielkonfigurationsdatei editieren oder die GUI verwenden. Cluster und Server sind entweder symbolische Namen oder Adressen in Schreibweise mit Trennzeichen. Port ist die Nummer des Ports, den Sie für dieses Protokoll verwenden. Für einen Port eines Clusters müssen Sie mehrere Server definieren, um einen Lastausgleich durchführen zu können.
Bindungsspezifische Server: Wenn die Dispatcher-Komponente die Last auf bindungsspezifische Server verteilt, müssen die Server so konfiguriert werden, dass sie an die Cluster-Adresse gebunden werden. Da der Dispatcher Pakete ohne Änderung der Ziel-IP-Adresse weiterleitet, enthalten die beim Server eingehenden Pakete noch immer die Cluster-Adresse als Ziel. Wenn ein Server für die Bindung an eine andere IP-Adresse als die Cluster-Adresse konfiguriert ist, kann der Server für den Cluster bestimmte Pakete/Anforderungen nicht akzeptieren.
Verknüpfung mehrerer Adressen: In einer verknüpften Konfiguration muss die Adresse der verknüpften Servermaschine nicht mit der NFA übereinstimmen. Wenn Ihre Maschine mit mehreren IP-Adressen definiert wurde, können Sie eine andere Adresse verwenden. Für die Dispatcher-Komponente muss die verknüpfte Servermaschine mit dem Befehl ndcontrol server als verknüpft definiert werden. Weitere Informationen zu verknüpften Servern finden Sie im Abschnitt Verknüpfte Server verwenden.
Weitere Informationen zur Syntax des Befehls ndcontrol server können Sie dem Abschnitt ndcontrol server -- Server konfigurieren entnehmen.
Die Manager-Funktion verbessert den Lastausgleich. Soll der Manager gestartet werden, geben Sie den Befehl ndcontrol manager start ein, editieren Sie die Beispielkonfigurationsdatei oder verwenden Sie die GUI.
Die Advisor-Funktionen liefern dem Manager weitere Informationen über die Fähigkeit der am Lastausgleich beteiligten Servermaschinen, auf Anforderungen zu antworten. Advisor-Funktionen sind protokollspezifisch. Soll beispielsweise die HTTP-Advisor-Funktion gestartet werden, setzen Sie den folgenden Befehl ab:
cbrcontrol advisor start http PortEine Liste der Advisor-Funktionen mit den zugehörigen Standard-Ports finden Sie in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator. Eine Beschreibung der einzelnen Advisor-Funktionen können Sie dem Abschnitt Liste der Advisor-Funktionen entnehmen.
Wenn Sie Advisor-Funktionen starten, können Sie die Wichtigkeit ändern, die in Entscheidungen für den Lastausgleich einfließenden Informationen von Advisor-Funktionen beigemessen wird. Setzen Sie zum Festlegen von Cluster-Proportionen den Befehl ndcontrol cluster set Cluster proportions ab. Weitere Informationen hierzu finden Sie im Abschnitt Proportionale Bedeutung von Statusinformationen.
Wenn es sich um einen verknüpften Server handelt (d. h., sich der Dispatcher auf der Maschine befindet, für die er den Lastausgleich durchführt) oder eine der Weiterleitungsmethoden "nat" und "cbr" verwendet wird, führen Sie die folgenden Prozeduren nicht aus.
Wird die Weiterleitungsmethode "mac" verwendet, funktioniert der Dispatcher nur auf Back-End-Servern, bei denen der Loopback-Adapter mit einer zusätzlichen IP-Adresse konfiguriert werden kann, da der Back-End-Server nicht auf ARP-Anforderungen (Adressauflösungsprotokoll) reagiert. Führen Sie die Schritte in diesem Abschnitt aus, um die am Laustausgleich beteiligten Servermaschinen zu konfigurieren.
Damit die am Lastausgleich beteiligten Servermaschinen arbeiten können, müssen Sie die Loopback-Einheit (die häufig als lo0 bezeichnet wird) auf die Cluster-Adresse setzen (oder bevorzugt die Cluster-Adresse als Aliasnamen festlegen). Bei Verwendung der Weiterleitungsmethode "mac" ändert die Dispatcher-Komponente nicht die Ziel-IP-Adresse des TCP/IP-Pakets, bevor sie dieses an eine TCP-Servermaschine weiterleitet. Wird die Loopback-Einheit auf die Cluster-Adresse gesetzt oder diese Adresse als Aliasname der Loopback-Einheit festgelegt, akzeptieren die am Lastausgleich beteiligten Servermaschinen ein an die Cluster-Adresse gerichtetes Paket.
Falls Ihr Betriebssystem Aliasnamen für Netzschnittstellen unterstützt (wie es bei AIX, Linux, Solaris oder Windows 2000 der Fall ist), sollten Sie die Cluster-Adresse als Aliasnamen der Loopback-Einheit festlegen. Ein Betriebssystem mit Unterstützung für Aliasnamen bringt den Vorteil, dass die am Lastausgleich beteiligten Servermaschinen für mehrere Cluster-Adressen konfiguriert werden können.
Setzen Sie für Linux-Kernel ab Version 2.2.14 vor dem Befehl ifconfig den folgenden Befehl ab:
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden echo 1 > /proc/sys/net/ipv4/conf/all/hidden
Wenn das Betriebssystem Ihres Servers keine Aliasnamen unterstützt, wie das z. B. bei HP-UX und OS/2 der Fall ist, müssen Sie die Loopback-Einheit auf die Cluster-Adresse setzen.
Verwenden Sie den in Tabelle 4 angegebenen betriebssystemspezifischen Befehl, um die
Loopback-Einheit oder einen Aliasnamen für die Einheit zu
definieren.
Tabelle 4. Befehle zum Festlegen eines Aliasnamens für die Loopback-Einheit (lo0) für Dispatcher
Unter einigen Betriebssystemen wurde möglicherweise eine Standard-Route erstellt, die entfernt werden muss.
route print
netstat -nr
Beispiel für Windows 2000:
Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl 0.0.0.0 0.0.0.0 9.67.128.1 9.67.133.67 1 9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1 9.67.128.0 255.255.248.0 9.67.133.67 9.67.133.67 1 9.67.133.67 255.255.255.255 127.0.0.1 127.0.0.1 1 9.67.133.158 255.255.255.255 127.0.0.1 127.0.0.1 1 9.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 224.0.0.0 9.67.133.158 9.67.133.158 1 224.0.0.0 224.0.0.0 9.67.133.67 9.67.133.67 1 255.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1
9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1
Die zusätzliche Route muss gelöscht werden. Löschen Sie die zusätzliche Route mit dem in Tabelle 5 angegebenen betriebssystemspezifischen Befehl.
Beispiel: Geben Sie zum Löschen einer zusätzlichen Route wie in der Beispielauflistung "Aktive Routen" für Schritt 2 Folgendes ein:
route delete 9.0.0.0 9.67.133.158
Tabelle 5. Befehle zum Löschen zusätzlicher Routes für Dispatcher
Wenn Sie für das in Abbildung 15 gezeigte Beispiel eine Servermaschine mit AIX konfigurieren, würde der Befehl wie folgt lauten:
route delete -net 204.0.0.0 204.67.172.72
Führen Sie zum Überprüfen der Konfiguration eines Back-End-Servers auf einer anderen Maschine im selben Teilnetz bei nicht aktivem Dispatcher und nicht konfiguriertem Cluster die folgenden Schritte aus:
arp -d Cluster
ping Cluster
Sie sollten keine Antwort empfangen. Falls Sie eine Antwort auf das "ping" erhalten, vergewissern Sie sich, dass Sie nicht mit iconfig die Schnittstelle auf die Cluster-Adresse gesetzt haben. Vergewissern Sie sich, dass keine Maschine einen veröffentlichten Eintrag "arp" für die Cluster-Adresse hat.
Für Linux-Kernel ab Version 2.2.14 müssen /proc/sys/net/ipv4/conf/lo/hidden und /proc/sys/net/ipv4/conf/all/hidden eine "1" enthalten.
arp -a
Die Ausgabe des Befehls sollte die MAC-Adresse Ihres Servers enthalten. Setzen Sie den folgenden Befehl ab:
arp -s Cluster MAC-Adresse_des_Servers
arp -d Cluster
Bei Linux-Servern ist (je nach Linux-Kernel-Version) ein Patch-Code erforderlich, um der Loopback-Einheit einen Aliasnamen zuordnen zu können.
Der Patch-Code stellt sicher, dass eine ARP-Antwort nur von einem Netzwerkadapteranschluss gesendet wird, der die in der ARP-Anfrage angeforderte IP-Adresse hat. Ohne diesen Patch-Code setzt Linux im Netz ARP-Antworten für die Aliasnamen der Loopback-Einheit ab. Der Patch-Code beseitigt auch eine ARP-Konkurrenzbedingung, wenn in einem physischen Netzwerk mehrere Netzwerkadapteranschlüsse mit verschiedenen IP-Adressen vorhanden sind.
Sie müssen den Patch-Code unter den folgenden Bedingungen installieren.
Bei Verwendung des Kernels 2.2.12 oder 2.2.13 auf einem Back-End-Server gilt Folgendes:
Anmerkungen:
Der Kernel-Patch-Code ist nicht für alle Konfigurationen erforderlich. Unter den folgenden Bedingungen müssen Sie einen Patch-Code für die Linux-Kernel-Versionen 2.4.x installieren:
Sie können diesen Patch-Code von der Adresse http://oss.software.ibm.com/developerworks/opensource/cvs/naslib downloaden.
Wählen Sie in der Download-Liste den Eintrag "CVS Tree" aus.
Wenden Sie den Patch-Code wie folgt an:
cd /usr/src/linux-2.4/net/ipv4 patch -p0 -l < arp.c.2.4.0.patch
make dep;make clean;make bzImage;make modules;make modules_install cd arch/i386/boot cat bzImage > /boot/vmlinuz-2.4.2-2-arppatch cd /usr/src/linux-2.4 cp System.map /boot/System.map-2.4.2-2-arppatch cd /etc
Ein Patch-Code für die Linux-Kernel-Versionen 2.2.12 und 2.2.13 muss auf jeder Servermaschine, die die MAC-Weiterleitungsmethode anwendet, installiert werden. Sie können diesen Patch-Code von der Adresse http://www.ibm.com/developer/linux downloaden.
Wenden Sie den Patch-Code wie folgt an:
patch -p0 < Patch-Codedatei
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_invisible
Dieser Befehl wird nur bis zum Warmstart der Maschine ausgeführt. Nach dem Warmstart ist es erforderlich, dass dieser und die nachfolgenden Schritte erneut ausgeführt werden.
ifconfig lo:1 cluster netmask 255.255.255.255 up
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der CBR-Komponente mit Caching Proxy berücksichtigen muss.
Dieses Kapitel enthält die folgenden Abschnitte:
Mit der CBR-Komponente können Sie unter Verwendung von Caching Proxy zum Weiterleiten der Anforderung HTTP- und SSL-Datenverkehr verteilen.
CBR ist dem Dispatcher hinsichtlich der Komponentenstruktur sehr ähnlich. CBR umfasst die folgenden Funktionen:
Die Benutzung des Managers ist optional. Ohne den Manager wird der Lastausgleich nach einer gewichteten RoundRobin-Zeitplanung und ausgehend von den aktuellen Serverwertigkeiten durchgeführt. Es stehen keine Advisor-Funktionen zur Verfügung.
Die drei wichtigsten Funktionen der CBR-Komponente (Executor, Manager und Advisor-Funktionen) arbeiten gemeinsam an der Verteilung der eingehenden Anforderungen auf die Server. Neben dem Verteilen von Anforderungen überwacht der Executor die Anzahl neuer und aktiver Verbindungen. Diese Informationen stellt er anschließend dem Manager zur Verfügung.
Die CBR-Komponente gibt Ihnen die Möglichkeit, eine Gruppe von Servern anzugeben, die eine Anforderung auf der Basis des Abgleichs eines regulären Ausdrucks mit dem Inhalt der Anforderung bearbeiten. Mit CBR können Sie Ihre Site partitionieren, so dass verschiedene Inhalte oder Anwendungsdienste von unterschiedlichen Servergruppen bearbeitet werden. Diese Partitionierung ist für Clients, die auf Ihre Site zugreifen, transparent. Da CBR die Angabe mehrerer Server für jede Art von Anforderung zulässt, können die Anforderungen so verteilt werden, dass eine optimale Client-Antwortzeit erreicht wird. Aufgrund der Möglichkeit, jedem Inhaltstyp mehrere Server zuzuordnen, sind Sie geschützt, wenn eine Workstation oder ein Server ausfällt. CBR erkennt den Ausfall und verteilt die Client-Anforderungen auf die übrigen Server der Gruppe.
Eine Möglichkeit, Ihre Site zu partitionieren, besteht darin, einige Server ausschließlich für die Bearbeitung von cgi-Anforderungen und eine andere Gruppe von Servern für die Bearbeitung aller anderen Anforderungen zuzuordnen. Damit wird verhindert, dass die Server aufgrund der Verarbeitung umfangreicher cgi-Scripts für den normalen html-Datenverkehr zu langsam werden und resultiert in einer insgesamt besseren Antwortzeit für die Clients. Mit Hilfe dieses Schemas könnten Sie auch leistungsstärkere Workstations für normale Anforderungen zuordnen. Dadurch würde die Antwortzeit für Clients verbessert, ohne dass alle Ihre Server aufgerüstet werden müssen. Sie könnten auch für cgi-Anforderungen leistungsstärkere Workstations zur Verfügung stellen.
Eine andere Möglichkeit zur Partitionierung Ihrer Site besteht darin, Clients, die auf Seiten mit erforderlicher Registrierung zugreifen, an eine Servergruppe zu verweisen und alle anderen Anforderungen an eine zweite Servergruppe zu senden. Damit würde verhindert, dass Browser Ihrer Site Ressourcen binden, die von Clients verwendet werden könnten, die registriert wurden. Außerdem könnten Sie leistungsstärkere Workstation verwenden, um Services für die Clients zur Verfügung zu stellen, die registriert wurden.
Sie könnten natürlich die oben genannten Methoden kombinieren, um eine noch größere Flexibilität und einen noch besseren Service zu erreichen.
Caching Proxy kommuniziert über die zugehörige Plug-In-Schnittstelle mit CBR. Caching Proxy muss auf derselben Maschine installiert sein. Mehrere Instanzen von Caching Proxy, die auf derselben Maschine ausgeführt werden, können gleichzeitig mit CBR kommunizieren. In früheren Releases konnte nur eine Instanz von Caching Proxy mit CBR kommunizieren.
CBR überprüft zusammen mit Caching Proxy HTTP-Anforderungen anhand angegebener Regeltypen. Wenn Caching Proxy aktiv ist, akzeptiert es Client-Anforderungen und fragt bei CBR den besten Server an. Bei dieser Abfrage gleicht CBR die Anforderung mit einer Gruppe von Regeln mit bestimmten Prioritäten ab. Wenn eine Regel erfüllt ist, wird aus einer vorkonfigurierten Servergruppe ein geeigneter Server ausgewählt. Abschließend teilt CBR Caching Proxy mit, welcher Server ausgewählt wurde. Die Anforderung wird dann an diesen Server weitergeleitet.
Nachdem Sie einen Cluster für den Lastausgleich definiert haben, müssen Sie sicherstellen, dass es für alle Anforderungen an diesen Cluster eine Regel für die Auswahl eines Servers gibt. Wird keine Regel gefunden, die zu einer bestimmten Anforderung passt, empfängt der Client von Caching Proxy eine Fehlerseite. Das Erstellen einer in allen fällen gültigen Regel mit einer sehr hohen Prioritätsnummer ist der einfachste Weg zu gewährleisten, dass alle Anforderungen mit einer Regel übereinstimmen. Vergewissern Sie sich, dass die von dieser Regel verwendeten Server alle Anforderungen bearbeiten können, die nicht explizit von den Regeln mit einer kleineren Prioritätsnummer bearbeitet werden. (Anmerkung: Die Regeln mit kleinerer Prioritätsnummer werden zuerst ausgewertet.)
CBR mit Caching Proxy kann SSL-Übertragungen vom Client zum Proxy empfangen und Übertragungen vom Proxy zu einem SSL-Server unterstützen. Wenn Sie für einen Server der CBR-Konfiguration einen SSL-Port für den Empfang der SSL-Anforderung vom Client definieren, können Sie den Datenverkehr mit CBR auf sichere Server (SSL-Server) verteilen und die Sicherheit Ihrer Site gewährleisten.
Zur Datei ibmproxy.conf für IBM Caching Proxy müssen Sie eine Konfigurationsanweisung hinzufügen, um die SSL-Verschlüsselung für Datenverkehr vom Proxy zum Server zu aktivieren. Diese Anweisung muss das folgende Format haben:
proxy uri-Muster url-Muster Adresse
Hier ist uri-Muster ein zu suchendes Muster (z. B. /secure/*), url-Muster ein Austausch-URL (z. B. https://ClusterA/secure/*) und Adresse die Cluster-Adresse (z. B. ClusterA).
Die CBR-Komponente mit Caching Proxy kann auch SSL-Übertragungen vom Client empfangen und die SSL-Anfrage vor der Weiterleitung an einen HTTP-Server entschlüsseln. Für den Befehl "cbrcontrol server" gibt es das optionale Schlüsselwort mapport , damit CBR SSL-Datenverkehr vom Client zum Proxy und HTTP-Datenverkehr vom Proxy zum Server unterstützen kann. Verwenden Sie dieses Schlüsselwort, wenn der Port auf dem Server ein anderer als der vom Client ankommende Port ist. Nachfolgend sehen Sie ein Beispiel für das Hinzufügen eines Ports mit dem Schlüsselwort "mapport". Der Client-Port ist 443 (SSL) und der Server-Port 80 (HTTP):
cbrcontrol server add Cluster:443 mapport 80
Die Port-Nummer für "mapport" kann eine beliebige positive ganze Zahl sein. Die Standard-Port-Nummer ist der Wert des vom Client ankommenden Ports.
Da CBR in der Lage sein muss, Empfehlungen zu einer HTTP-Anforderung für einen am Port 443 (SSL) konfigurierten Server zu geben, gibt es die spezielle Advisor-Funktion ssl2http. Diese Advisor-Funktion wird an (dem vom Client ankommenden) Port 443 gestartet und gibt Empfehlungen zu den für diesen Port konfigurierten Servern. Wenn zwei Cluster konfiguriert sind und jeder der Cluster den Port 443 und die Server mit einem anderen "mapport" konfiguriert hat, kann eine Instanz der Advisor-Funktion den entsprechenden Port öffnen. Nachfolgend ist ein Beispiel dieser Konfiguration aufgeführt:
Executor Cluster1 Port:443 Server1 mapport 80 Server2 mapport 8080 Cluster2 Port:443 Server3 mapport 80 Server4 mapport 8080 Manager Advisor ssl2http 443
Lesen Sie vor Ausführung der in diesem Kapitel beschriebenen Schritte Kapitel 6, Planung für Content Based Routing. In diesem Kapitel wird erklärt, wie eine Basiskonfiguration für die CBR-Komponente von Network Dispatcher erstellt wird.
Tabelle 6. Konfigurations-Tasks für die CBR-Komponente
Task | Beschreibung | Referenzinformationen |
---|---|---|
CBR-Maschine konfigurieren | Stellen Sie fest, welche Voraussetzungen zu erfüllen sind. | CBR-Maschine konfigurieren |
Am Lastausgleich beteiligte Maschinen konfigurieren | Definieren Sie Ihre Lastausgleichskonfiguration. | Schritt 7. Am Lastausgleich beteiligte Servermaschinen definieren |
Es gibt im Wesentlichen vier Methoden für das Erstellen einer Basiskonfiguration für die CBR-Komponente von Network Dispatcher:
Voraussetzung für die Verwendung von CBR ist die Installation von Caching Proxy.
Dies ist die direkte Methode für die Konfiguration von CBR. Die Werte der Befehlsparameter müssen in englischen Zeichen eingegeben werden. Die einzige Ausnahme hiervon bilden Host-Namen (die z. B. in den Befehlen "cluster" und "server" verwendet werden) und Dateinamen.
Starten Sie CBR wie folgt von der Befehlszeile aus:
Sie können eine gekürzte Version der Parameter für den Befehl "cbrcontrol" eingeben. Sie müssen nur die eindeutigen Buchstaben der Parameter eingeben. Beispiel: Wenn Sie Hilfe für den Befehl zum Speichern von Dateien aufrufen möchten, können Sie cbrcontrol he f anstelle von cbrcontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl cbrcontrol ab, um die Eingabeaufforderung "cbrcontrol" aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Anmerkungen:
( ) linke und rechte runde Klammer
& Et-Zeichen
| vertikaler Balken
! Ausrufezeichen
* Stern.
Die Shell des Betriebssystems könnte diese Zeichen als Sonderzeichen interpretieren und in alternativen Text konvertieren, bevor sie von "cbrcontrol" ausgewertet werden.
Die oben aufgelisteten Sonderzeichen sind optionale Zeichen für den Befehl cbrcontrol rule add und werden zum Angeben eines Musters für eine content-Regel verwendet. Der folgende Befehl ist deshalb unter Umständen nur bei Verwendung der Eingabeaufforderung "cbrcontrol>>" gültig.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern client=181.0.153.222&uri=http://10.1.203.4/nipoek/*
Wenn dieser Befehl an der Eingabeaufforderung des Betriebssystems funktionieren soll, müssen Sie das Muster wie folgt in Anführungszeichen setzen:
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "client=181.0.153.222&uri=http://10.1.203.4/nipoek/*"
Fehlen die Anführungszeichen, könnte beim Speichern der Regel in CBR ein Teil des Musters abgeschnitten werden. An der Eingabeaufforderung "cbrcontrol>>" wird die Verwendung von Anführungszeichen nicht unterstützt.
Die Befehle zum Konfigurieren von CBR können in eine Konfigurations-Script-Datei eingegeben und dann zusammen ausgeführt werden.
cbrcontrol file appendload meinScript
cbrcontrol file newload meinScript
Abbildung 2 zeigt ein Beispiel für die grafische Benutzerschnittstelle (GUI).
Gehen Sie zum Starten der GUI wie folgt vor:
Zum Konfigurieren der Komponente CBR von der GUI aus müssen Sie zunächst in der Baumstruktur Content Based Routing auswählen. Sie können den Manager starten, sobald Sie eine Verbindung zu einem Host hergestellt haben. Sie können auch Cluster mit Ports und Servern erstellen und Advisor-Funktionen für den Manager starten.
Mit der GUI können Sie dieselben Tasks wie mit dem Befehl cbrcontrol ausführen. Wenn Sie beispielsweise einen Cluster von der Befehlszeile aus konfigurieren möchten, müssten Sie den Befehl cbrcontrol cluster add Cluster eingeben. Zum Definieren eines Clusters von der GUI aus müssen Sie mit der rechten Maustaste auf "Executor" klicken und in dem daraufhin angezeigten Popup-Menü mit der linken Maustaste auf Cluster hinzufügen. Geben Sie die Cluster-Adresse in das Dialogfenster ein und klicken Sie dann auf OK.
Bereits vorhandene CBR-Konfigurationsdateien können Sie mit der im Popup-Menü Host angezeigten Option Neue Konfiguration laden (zum vollständigen Ersetzen der derzeitigen Konfiguration) oder An aktuelle Konfiguration anfügen (zum Aktualisieren der derzeitigen Konfiguration) laden. Sie sollten Ihre CBR-Konfiguration von Zeit zu Zeit mit der Option Konfigurationsdatei sichern unter in einer Datei sichern. Diese Option ist ebenfalls im Popup-Menü Host enthalten. Über das Menü Datei oben auf der GUI können Sie Ihre aktuellen Host-Verbindungen in einer Datei speichern oder Verbindungen aus vorhandenen Dateien aller Network-Dispatcher-Komponenten wiederherstellen.
Sie können auf Hilfe zugreifen, indem Sie auf das Fragezeichen in der oberen rechten Ecke des Fensters von Network Dispatcher klicken.
Weitere Informationen zur Verwendung der GUI finden Sie im Abschnitt Allgemeine Anweisungen zur Verwendung der GUI.
Führen Sie folgende Schritte aus, wenn Sie den Konfigurationsassistenten verwenden:
Starten Sie den Assistenten von der Eingabeaufforderung aus, indem Sie den Befehl cbrwizard absetzen. Sie können den Konfigurationsassistenten auch im CBR-Komponentenmenü auswählen, das auf der GUI angezeigt wird.
Unter AIX, Linux oder Solaris: Geben Sie zum Starten von Caching Proxy ibmproxy ein.
Unter Windows 2000: Rufen Sie die Anzeige "Dienste" auf, indem Sie nacheinander auf Start -> Einstellungen -> Systemsteuerung -> Verwaltung -> Dienste klicken.
Der CBR-Assistent führt Sie schrittweise durch den Prozess zum Erstellen einer Basiskonfiguration für die CBR-Komponente. Der Assistent stellt Ihnen Fragen bezüglich Ihres Netzes und führt Sie durch die Konfiguration eines Clusters, mit dem CBR den Datenverkehr auf eine Gruppe von Servern verteilen kann.
Der CBR-Konfigurationsassistent ruft die folgenden Anzeigen auf:
Vor dem Konfigurieren der CBR-Maschine müssen Sie (unter AIX, Linux oder Solaris) als Benutzer "root" oder (unter Windows 2000) als Administrator registriert sein.
Sie benötigen für jeden zu konfigurierenden Server-Cluster eine IP-Adresse. Eine Cluster-Adresse ist eine Adresse, die einem Host-Namen zugeordnet ist (beispielsweise www.company.com). Diese IP-Adresse wird von einem Client benutzt, um eine Verbindung zu den Servern eines Clusters herzustellen. Diese Adresse ist in der URL-Anforderung von dem Client enthalten. CBR verteilt alle Anforderungen, die an dieselbe Cluster-Adresse gerichtet sind.
Für Solaris: Vor Verwendung der Komponente CBR müssen die Systemstandardwerte für die prozessübergreifende Kommunikation (Inter-process Communication) geändert werden. Die maximale Größe des gemeinsam benutzten Speichersegments und die Anzahl von Semaphor-Kennungen müssen erhöht werden. Sie können Ihr System auf die Unterstützung für CBR einstellen, indem Sie die Datei /etc/system auf Ihrem System editieren und die folgenden Anweisungen hinzufügen, bevor Sie dann einen Warmstart durchführen:
set shmsys:shminfo_shmmax=0x02000000 set semsys:seminfo_semmap=750 set semsys:seminfo_semmni=30 set semsys:seminfo_semmns=750 set semsys:seminfo_semmnu=30 set semsys:seminfo_semume=30
Wenn Sie das gemeinsam benutzte Speichersegment nicht auf die oben gezeigten Werte vergrößern, kann der Befehl cbrcontrol executor start nicht ausgeführt werden.
Voraussetzung für die Verwendung von CBR ist die Installation von Caching Proxy.
Die Konfigurationsdatei für Caching Proxy (ibmproxy.conf) müssen Sie wie folgt ändern:
Setzen Sie die Anweisung für ankommenden URL CacheByIncomingUrl auf "on".
Für das CBR-Plug-In müssen Sie vier Einträge editieren:
Nachfolgend sehen Sie die spezifischen Zusätze zur Konfigurationsdatei für AIX, Linux, Solaris und Windows 2000.
Abbildung 16. CBR-Konfigurationsdatei für AIX
ServerInit /usr/lpp/nd/servers/lib/libndcbr.so:ndServerInit PreExit /usr/lpp/nd/servers/lib/libndcbr.so:ndPreExit PostExit /usr/lpp/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /usr/lpp/nd/servers/lib/libndcbr.so:ndServerTerm
Abbildung 17. CBR-Konfigurationsdatei für Linux
ServerInit /opt/nd/servers/lib/libndcbr.so:ndServerInit PreExit /opt/nd/servers/lib/libndcbr.so:ndPreExit PostExit /opt/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /opt/nd/servers/lib/libndcbr.so:ndServerTerm
Abbildung 18. CBR-Konfigurationsdatei für Solaris
ServerInit /opt/nd/servers/lib/libndcbr.so:ndServerInit PreExit /opt/nd/servers/lib/libndcbr.so:ndPreExit PostExit /opt/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /opt/nd/servers/lib/libndcbr.so:ndServerTerm
Abbildung 19. CBR-Konfigurationsdatei für Windows 2000
Allgemeiner Installationsverzeichnispfad:
ServerInit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndServerInit PreExit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndPreExit PostExit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndPostExit ServerTerm c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndServerTerm
Interner Installationsverzeichnispfad:
ServerInit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndServerInit PreExit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndPreExit PostExit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndPostExit ServerTerm c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndServerTerm
Geben Sie zum Starten der CBR-Serverfunktion in der Befehlszeile cbrserver ein.
Beim Starten von cbrserver wird automatisch eine Standardkonfigurationsdatei (default.cfg) geladen. Wenn Sie die CBR-Konfiguration in default.cfg sichern, werden alle in dieser Datei gesicherten Angaben beim nächsten Starten von cbrserver automatisch geladen.
Geben Sie zum Starten der Executor-Funktion den Befehl cbrcontrol executor start ein. Sie können jetzt auch verschiedene Executor-Einstellungen ändern. Lesen Sie hierzu die Informationen im Abschnitt ndcontrol executor -- Executor steuern.
CBR verteilt die an die Cluster-Adresse gesendeten Anforderungen auf die entsprechenden Server, die für die Ports dieses Clusters konfiguriert wurden.
Die Cluster-Adresse ist entweder ein symbolischer Name oder eine Adresse in Schreibweise mit Trennzeichen. Diese Adresse ist im Host-Abschnitt des URL enthalten.
Setzen Sie zum Definieren eines Clusters den folgenden Befehl ab:
cbrcontrol cluster add Cluster
Setzen Sie zum Festlegen von Cluster-Optionen den folgenden Befehl ab:
cbrcontrol cluster set Wert_der_Cluster-Option
Weitere Informationen hierzu finden Sie in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator.
Wenn Sie Caching Proxy als Reverse Proxy konfiguriert haben und einen Lastausgleich für mehrere Websites durchführen, müssen Sie die Cluster-Adresse jeder Website zu mindestens einer Netzschnittstellenkarte der Network-Dispatcher-Maschine hinzufügen. Andernfalls kann dieser Schritt übergangen werden.
Unter AIX, Linux oder Solaris: Fügen Sie die
Cluster-Adresse mit dem Befehl "ifconfig" zur Netzschnittstellenkarte
hinzu. Den Befehl für das von Ihnen verwendete Betriebssystem können
Sie Tabelle 7 entnehmen.
Tabelle 7. Befehle zum Erstellen eines Aliasnamens für die NIC
AIX | ifconfig Schnittstellenname alias Cluster-Adresse netmask Netzmaske |
Linux | ifconfig Schnittstellenname Cluster-Adresse netmask Netzmaske up |
Solaris 7 | ifconfig Schnittstellenname Cluster-Adresse netmask Netzmaske up |
Solaris 8 | ifconfig addif Schnittstellenname Cluster-Adresse netmask Netzmaske up |
Für Windows: Gehen Sie zum Hinzufügen der Cluster-Adresse zur Netzschnittstelle wie folgt vor:
Die Port-Nummer bezeichnet den Port, an dem die Serveranwendungen empfangsbereit sind. Für HTTP-Datenverkehr ist dies bei Verwendung von CBR mit Caching Proxy in der Regel Port 80.
Setzen Sie den folgenden Befehl ab, um für den im vorherigen Schritt definierten Cluster einen Port zu definieren:
cbrcontrol port add Cluster:Port
Setzen Sie zum Festlegen von Port-Optionen den fogenden Befehl ab:
cbrcontrol port set Cluster:Wert_der_Port-Option
Weitere Informationen hierzu finden Sie in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator.
Die Servermaschinen sind die Maschinen, auf denen die Anwendungen ausgeführt werden, deren Last verteilt werden soll. Für den Server wird der symbolische Name der Servermaschine oder deren Adresse in Schreibweise mit Trennzeichen angegeben. Setzen Sie den folgenden Befehl ab, um für Cluster und Port einen Server zu definieren:
cbrcontrol server add Cluster:Port:Server
Für einen Cluster müssen Sie pro Port mehrere Server definieren, um einen Lastausgleich durchführen zu können.
Dies ist der wichtigste Schritt beim Konfigurieren von CBR mit Caching Proxy. Mit einer Regel wird definiert, wie zwischen URL-Anforderungen unterschieden wird und wie eine Anforderung an die entsprechende Gruppe von Servern gesendet wird. Der spezielle von CBR verwendete Regeltyp ist 'content'. Setzen Sie zum Definieren einer content-Regel den folgenden Befehl ab:
cbrcontrol rule add Cluster:Port:Regel type content pattern=Muster
Der Wert Muster ist der reguläre Ausdruck, der mit dem URL in den einzelnen Client-Anforderungen verglichen wird. Weitere Informationen über zum Konfigurieren des Musters finden Sie in Anhang C, Syntax der content-Regel.
Einige der anderen in Dispatcher definierten Regeltypen können ebenfalls für CBR verwendet werden. Weitere Informationen hierzu finden Sie im Abschnitt Regelbasierten Lastausgleich konfigurieren.
Wenn für eine Client-Anforderung eine Übereinstimmung mit einer Regel gefunden wird, wird bei der der Regel zugeordneten Servergruppe der beste Server abgefragt. Die der Regel zugeordnete Servergruppe ist eine Untergruppe der Server, die für den Port definiert sind. Setzen Sie den folgenden Befehl ab, um Server zur Servergruppe einer Regel hinzuzufügen:
cbrcontrol rule useserver Cluster:Port:Regel server
Die Manager-Funktion verbessert den Lastausgleich. Setzen Sie zum Starten des Managers den folgenden Befehl ab:
cbrcontrol manager start
Die Advisor-Funktionen liefern dem Manager weitere Informationen über die Fähigkeit der am Lastausgleich beteiligten Servermaschinen, auf Anforderungen zu antworten. Advisor-Funktionen sind protokollspezifisch. Soll beispielsweise die HTTP-Advisor-Funktion gestartet werden, setzen Sie den folgenden Befehl ab:
cbrcontrol advisor start http Port
Wenn Sie Advisor-Funktionen starten, können Sie die Wichtigkeit ändern, die in Entscheidungen für den Lastausgleich einfließenden Informationen von Advisor-Funktionen beigemessen wird. Setzen Sie zum Festlegen von Cluster-Proportionen den Befehl cbrcontrol cluster set Cluster proportions ab. Weitere Informationen hierzu finden Sie im Abschnitt Proportionale Bedeutung von Statusinformationen.
/usr/lpp/nd/servers/lib
/opt/nd/servers/lib
Allgemeiner Installationsverzeichnispfad:
c:\Programme\IBM\edge\nd\servers\lib
Interner Installationsverzeichnispfad:
c:\Programme\IBM\nd\servers\lib
Starten Sie Caching Proxy in der neuen Umgebung, indem Sie an der Eingabeaufforderung den Befehl ibmproxy absetzen.
Führen Sie die folgenden Schritte aus, um CBR zu konfigurieren:
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Komponente Mailbox Locator berücksichtigen muss.
Dieses Kapitel enthält die folgenden Abschnitte:
Mit Mailbox Locator können Sie IMAP- und POP3-Datenverkehr ausgehend von Benutzer-ID und Kennwort der Client-Anforderung weiterleiten.
Mailbox Locator ist Dispatcher hinsichtlich der Komponentenstruktur sehr ähnlich. Mailbox Locator stellt die folgenden Funktionen bereit:
Die Benutzung des Managers ist optional. Ohne den Manager wird der Lastausgleich nach einer gewichteten RoundRobin-Zeitplanung und ausgehend von den aktuellen Serverwertigkeiten durchgeführt. Es stehen keine Advisor-Funktionen zur Verfügung.
Die drei wichtigsten Funktionen von Mailbox Locator (Executor, Manager und Advisor-Funktionen) arbeiten gemeinsam an der Verteilung der eingehenden Anforderungen auf die Server. Neben dem Verteilen von Anforderungen überwacht der Executor die Anzahl neuer und aktiver Verbindungen. Diese Informationen stellt er anschließend dem Manager zur Verfügung.
Setzen Sie an der Eingabeaufforderung den Befehl mlserver ab.
Mailbox Locator kann ein Anlaufpunkt für viele IMAP- oder POP3-Server sein. Jeder Server kann eine Untergruppe aller Mailboxes haben, die von dem Ansprechpartner bedient werden. Für IMAP und POP3 ist Mailbox Locator ein Proxy, der ausgehend von der vom Client bereitgestellten Benutzer-ID mit Kennwort einen geeigneten Server auswählt.
Nachfolgend finden Sie eine Beispielmethode für die Verteilung von Anforderungen ausgehend von der Client-Benutzer-ID. Wenn Sie zwei (oder mehr) POP3-Server haben, können Sie die Mailboxes bei Bedarf in alphabetischer Reihenfolge nach Benutzer-IDs unterteilen. Client-Anforderungen mit Benutzer-IDs, die mit den Buchstaben A-I beginnen, können an Server 1 weitergegeben werden, Client-Anforderungen mit Benutzer-IDs, die mit den Buchstaben J-R beginnen, an Server 2 usw.
Sie können auch auswählen, dass jede Mailbox auf mehreren Servern vorhanden ist. In diesem Fall muss der Inhalt jeder Mailbox für alle Server mit dieser Mailbox verfügbar sein. Bei einem Serverausfall kann ein anderer Server dennoch auf die Mailbox zugreifen.
Falls mehrere POP3-Postserver von nur einer Adresse repräsentiert werden sollen, kann Mailbox Locator mit einer Cluster-Adresse konfiguriert werden, die zur POP3-Postserveradresse für alle Clients wird. Die folgenden Befehle werden für diese Konfiguration verwendet:
mlcontrol cluster add POP3-Postserver mlcontrol port add POP3-Postserver:110 protocol pop3 mlcontrol server add POP3-Postserver:110:POP3-Server1+POP3-Server2+POP3-Server3
In diesem Beispiel repräsentiert POP3-Postserver die Cluster-Adresse. Port 110 mit dem Weiterleitungsprotokoll POP3 wird zum POP3-Postserver hinzugefügt. POP3-Server1, POP3-Server2 und POP3-Server3 sind POP3-Postserver, die zum Port hinzugefügt werden. Bei dieser Konfiguration können Sie die eingehenden POP3-Anforderungen Ihrer Post-Clients mit der Cluster-Adresse POP3-Postserver konfigurieren.
Wenn eine POP3- oder IMAP-Anforderung beim Proxy ankommt, versucht dieser, unter Verwendung von Benutzer-ID und Kennwort der Client-Anforderung alle für den Port konfigurierten Server zu erreichen. Die Client-Anforderung wird an den ersten Server gesendet, der antwortet. Sie sollten Mailbox Locator für IMAP- oder POP3-Server in Verbindung mit der Halte- bzw. Affinitätsfunktion verwenden. Mit der Affinitätsfunktion können nachfolgende Anforderungen mit derselben Client-Benutzer-ID an denselben Server übertragen werden. Setzen Sie stickytime für den Port auf einen Wert größer als null, um diese Affinitätsfunktion zu aktivieren. Weitere Informationen zur Affinitätsfunktion finden Sie im Abschnitt Funktionsweise der Affinität für Network Dispatcher.
Bei denProtokollen POP3 und IMAP liegt das Zeitlimit für autologout bei Inaktivität bei mindestens 10 Minuten bzw. 30 Minuten. Dieses Zeitlimit legt die Zeit der Inaktivität in Sekunden fest, nach der eine Verbindung entfernt wird. Für einen optimalen Durchsatz überschreibt Mailbox Locator das Inaktivitätszeitlimit und setzt es auf 60 Sekunden. Sie können das Inaktivitätszeitlimit ändern, indem Sie für den Befehl mlcontrol port den Wert staletimeout ändern. Informationen zum Konfigurieren dieses Befehls finden Sie im Abschnitt ndcontrol port -- Ports konfigurieren.
Lesen Sie vor Ausführung der in diesem Kapitel beschriebenen Schritte Kapitel 8, Planung für Mailbox Locator. Dieses Kapitel erläutert das Erstellen einer Basiskonfiguration für die Komponente Mailbox Locator von Network Dispatcher.
Tabelle 8. Konfigurations-Tasks für Mailbox Locator
Task | Beschreibung | Referenzinformationen |
---|---|---|
Maschine mit Mailbox Locator konfigurieren | Stellen Sie fest, welche Voraussetzungen zu erfüllen sind. | Maschine mit Mailbox Locator konfigurieren |
Am Lastausgleich beteiligte Maschinen konfigurieren | Definieren Sie Ihre Lastausgleichskonfiguration. | Schritt 4. Am Lastausgleich beteiligte Servermaschinen definieren |
Es gibt im Wesentlichen vier Methoden für das Erstellen einer Basiskonfiguration für die Komponente Mailbox Locator von Network Dispatcher:
Dies ist die direkte Methode für die Konfiguration von Mailbox Locator. Die Werte der Befehlsparameter müssen in englischen Zeichen eingegeben werden. Die einzige Ausnahme hiervon bilden Host-Namen (die z. B. in den Befehlen "cluster" und "server" verwendet werden) und Dateinamen.
Starten Sie Mailbox Locator wie folgt von der Befehlszeile aus:
Sie können eine Minimalversion der Parameter für den Befehl "mlcontrol" eingeben. Sie müssen nur die eindeutigen Buchstaben der Parameter eingeben. Beispiel: Wenn Sie Hilfe für den Befehl zum Speichern von Dateien aufrufen möchten, können Sie mlcontrol he f anstelle von mlcontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl mlcontrol ab, um die Eingabeaufforderung "mlcontrol" aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Die Befehle zum Konfigurieren von Mailbox Locator können in eine Konfigurations-Script-Datei eingegeben und dann zusammen ausgeführt werden.
mlcontrol file appendload meinScript
mlcontrol file newload meinScript
Ein Beispiel für die GUI zeigt Abbildung 2.
Gehen Sie zum Starten der GUI wie folgt vor:
Zum Konfigurieren von Mailbox Locator auf der GUI müssen Sie zunächst in der Baumstruktur Mailbox Locator auswählen. Sie können den Manager starten, sobald Sie eine Verbindung zu einem Host hergestellt haben. Sie können auch Cluster mit Ports und Servern erstellen und Advisor-Funktionen für den Manager starten.
Mit der GUI können Sie dieselben Tasks wie mit dem Befehl mlcontrol ausführen. Wenn Sie beispielsweise einen Cluster von der Befehlszeile aus konfigurieren möchten, müssten Sie den Befehl mlcontrol cluster add Cluster eingeben. Zum Definieren eines Clusters von der GUI aus müssen Sie mit der rechten Maustaste auf "Executor" klicken und im daraufhin angezeigten Popup-Menü mit der linken Taste auf Cluster hinzufügen. Geben Sie die Cluster-Adresse in das Dialogfenster ein und klicken Sie dann auf OK.
Bereits vorhandene Konfigurationsdateien für Mailbox Locator können Sie mit der im Popup-Menü Host angezeigten Option Neue Konfiguration laden (zum vollständigen Ersetzen der derzeitigen Konfiguration) oder An aktuelle Konfiguration anfügen (zum Aktualisieren der derzeitigen Konfiguration) laden. Sie sollten Ihre Mailbox-Locator-Konfiguration von Zeit zu Zeit mit der Option Konfigurationsdatei sichern unter in einer Datei sichern. Diese Option ist ebenfalls im Popup-Menü Host enthalten. Über das Menü Datei oben auf der GUI können Sie Ihre aktuellen Host-Verbindungen in einer Datei speichern oder Verbindungen aus vorhandenen Dateien aller Network-Dispatcher-Komponenten wiederherstellen.
Sie können auf Hilfe zugreifen, indem Sie auf das Fragezeichen in der oberen rechten Ecke des Fensters von Network Dispatcher klicken.
Weitere Informationen zur Verwendung der GUI finden Sie im Abschnitt Allgemeine Anweisungen zur Verwendung der GUI.
Führen Sie folgende Schritte aus, wenn Sie den Konfigurationsassistenten verwenden:
Sie können den Assistenten von der Eingabeaufforderung aus starten, indem Sie den Befehl mlwizard absetzen. Sie können den Konfigurationsassistenten aber auch auf der GUI unter der Komponente Mailbox Locator auswählen.
Der Mailbox-Locator-Assistent führt Sie schrittweise durch den Prozess zum Erstellen einer Basiskonfiguration für die Komponente Mailbox Locator. Er stellt Ihnen Fragen zu Ihrem Netz und leitet Sie beim Konfigurieren eines Clusters an, mit dem Mailbox Locator den Datenverkehr auf eine Gruppe von Servern verteilen kann.
Bei Verwendung des Konfigurationsassistenten für Mailbox Locator erscheinen die folgenden Anzeigen:
Vor dem Konfigurieren der Maschine mit Mailbox Locator müssen Sie (unter AIX, Linux oder Solaris) als Benutzer "root" oder (unter Windows 2000) als Administrator registriert sein.
Sie benötigen für jeden zu konfigurierenden Server-Cluster eine IP-Adresse. Eine Cluster-Adresse ist eine Adresse, die einem Host-Namen zugeordnet ist (beispielsweise www.IhreFirma.com). Diese IP-Adresse wird von einem Client benutzt, um die Verbindung zu den Servern in einem Cluster herzustellen. Mailbox Locator verteilt alle Anforderungen, die an dieselbe Cluster-Adresse gerichtet sind.
Geben Sie zum Starten der Serverfunktion in der Befehlszeile mlserver ein.
Mailbox Locator verteilt die an die Cluster-Adresse gesendeten Anforderungen auf die entsprechenden Server, die für die Ports dieses Clusters konfiguriert sind.
Die Cluster-Adresse ist ein symbolischer Name oder eine Adresse in Schreibweise mit Trennzeichen.
Setzen Sie zum Definieren eines Clusters den folgenden Befehl ab:
mlcontrol cluster add Cluster
Setzen Sie zum Festlegen von Cluster-Optionen den folgenden Befehl ab:
mlcontrol cluster set Wert_der_Cluster-Option
Weitere Informationen hierzu finden Sie in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator.
Die Port-Nummer bezeichnet den Port, an dem die Serveranwendungen empfangsbereit sind. Für IMAP-Datenverkehr ist dies in der Regel Port 143 und für POP3-Datenverkehr Port 110.
Setzen Sie den folgenden Befehl ab, um für den im vorherigen Schritt definierten Cluster einen Port zu definieren:
mlcontrol port add Cluster:Port protocol [pop3|imap]
Setzen Sie zum Festlegen von Port-Optionen den folgenden Befehl ab:
mlcontrol port set Cluster:Wert_der_Port-Option
Weitere Informationen hierzu finden Sie in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator.
Die Postserver sind die Maschinen, auf denen die Anwendungen ausgeführt werden, für die Sie einen Lastausgleich durchführen möchten. Für den Server wird der symbolische Name der Servermaschine oder deren Adresse in Schreibweise mit Trennzeichen angegeben. Setzen Sie zum Defnieren eines Servers für den Cluster und Port aus Schritt 3 den folgenden Befehl ab:
mlcontrol server add Cluster:Port:Server
Für einen Cluster müssen Sie pro Port mehrere Server definieren, um einen Lastausgleich durchführen zu können.
Die Manager-Funktion verbessert den Lastausgleich. Setzen Sie zum Starten des Managers den folgenden Befehl ab:
mlcontrol manager start
Die Advisor-Funktionen liefern dem Manager weitere Informationen über die Fähigkeit der am Lastausgleich beteiligten Servermaschinen, auf Anforderungen zu antworten. Advisor-Funktionen sind protokollspezifisch. Network Dispatcher stellt eine IMAP- und eine POP3-Advisor-Funktion bereit. Zum Starten der IMAP-Advisor-Funktion müssen Sie beispielsweise den folgenden Befehl absetzen:
mlcontrol advisor start imap PortEine Liste der Advisor-Funktionen mit den zugehörigen Standard-Ports finden Sie in Anhang B, Befehlsreferenz für Dispatcher, CBR und Mailbox Locator. Eine Beschreibung der einzelnen Advisor-Funktionen können Sie dem Abschnitt Liste der Advisor-Funktionen entnehmen.
Wenn Sie Advisor-Funktionen starten, können Sie die Wichtigkeit ändern, die in Entscheidungen für den Lastausgleich einfließenden Informationen von Advisor-Funktionen beigemessen wird. Setzen Sie zum Festlegen von Cluster-Proportionen den Befehl mlcontrol cluster set Cluster proportions ab. Weitere Informationen hierzu finden Sie im Abschnitt Proportionale Bedeutung von Statusinformationen.
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Komponente Site Selector berücksichtigen muss.
Dieses Kapitel enthält die folgenden Abschnitte:
Site Selector verteilt zusammen mit einem Domänennamensserver die Last auf eine Gruppe von Servern. Dazu verwendet Site Selector erfasste Messwerte und Wertigkeiten. Sie können eine Sitekonfiguration erstellen, die innerhalb einer Servergruppe einen Lastausgleich auf der Grundlage des für eine Client-Anfrage verwendeten Domänennamens durchführt.
Abbildung 20. Beispiel für eine DNS-Umgebung
Wenn Sie innerhalb Ihrer DNS-Umgebung eine Unterdomäne für Site Selector einrichten, sollte Site Selector die Berechtigung für diese Unterdomäne haben. Beispiel (siehe Abbildung 20): Ihre Firma hat die Berechtigung für die Domäne firma.com erhalten. Innerhalb der Firma gibt es mehrere Unterdomänen. Site Selector hätte in diesem Fall die Berechtigung für siteload.firma.com und die DNS-Server hätten weiterhin die Berechtigung für atlanta.firma.com und boston.firma.com.
Damit der Namensserver der Firma erkennt, dass Site Selector die Berechtigung für die Unterdomäne siteload hat, muss zur benannten Datendatei für den Server ein Namensservereintrag hinzugefügt werden. Für AIX würde ein solcher Namensservereintrag etwa wie folgt aussehen:
siteload.firma.com. IN NS siteselector.firma.com.
Hier ist siteselector.firma.com der Host-Name der Site-Selector-Maschine. In allen anderen benannten Datendateien für DNS-Server sind äquivalente Einträge erforderlich.
Ein Client fordert die Auflösung eines Domänennamens bei einem Namensserver innerhalb seines Netzes an. Der Namensserver leitet die Anforderung an die Site-Selector-Maschine weiter. Site Selector löst den Domänennamen dann in die IP-Adresse eines der Server auf, die unter dem Sitenamen konfiguriert wurden. Anschließend gibt Site Selector die IP-Adresse des ausgewählten Servers an den Namensserver zurück. Der Namensserver liefert die IP-Adresse an den Client. (Site Selector arbeitet als nicht rekursiver Namensserver (Blattknotenserver) und meldet einen Fehler, wenn die Domänennamensanforderung nicht aufgelöst werden kann.)
Abbildung 11 veranschaulicht eine Site, bei der Site Selector zusammen mit einem DNS-System die Last auf lokale und ferne Server verteilt.
Site Selector stellt die folgenden Funktionen bereit:
Die Benutzung des Managers ist optional. Ohne den Manager wird der Lastausgleich nach einer gewichteten RoundRobin-Zeitplanung und ausgehend von den aktuellen Serverwertigkeiten durchgeführt. Es stehen keine Advisor-Funktionen zur Verfügung.
Mit Metric Server kann Site Selector den Grad der Aktivität eines Servers überwachen, den Server mit der geringsten Auslastung feststellen und einen ausgefallenen Server erkennen. Die Last ist ein Maß für das Arbeitsaufkommen eines Server. Der Administrator des Systems mit Site Selector steuert die Art der Lastmessung. Sie können Site Selector an die Anforderungen der eigenen Umgebung anpassen und dabei Faktoren wie die Zugriffshäufigkeit, die Gesamtzahl der Benutzer und die Zugriffsarten (beispielsweise kurze Abfragen, lange Abfragen, Transaktionen mit hoher CPU-Belastung) berücksichtigen.
Der Lastausgleich wird auf der Basis von Serverwertigkeiten vorgenommen. Für Site Selector gibt es vier Proportionen, die der Manager zur Ermittlung der Wertigkeiten verwendet:
Alle CPU- und Speicherwerte werden von Metric Server bereitgestellt. Wenn Sie mit Site Selector arbeiten, sollten Sie demzufolge auch Metric Server verwenden.
Weitere Informationen hierzu finden Sie im Abschnitt Metric Server.
Die vier wichtigsten Funktionen von Site Selector (Namensserver, Manager, Metric Server und Advisor-Funktionen) interagieren, um die eingehenden Anforderungen auf die Server zu verteilen und aufzulösen.
Der DNS-gestützte Lastausgleich erfordert, dass Namensauflösungen zwischengespeichert werden können. Der TTL-Wert (Time To Live) bestimmt die Effizienz des DNS-gestützten Lastausgleichs. TTL legt fest, wie lange ein anderer Namensserver die aufgelöste Antwort zwischenspeichert. Bei einem kleinen TTL-Wert können geringfügige Änderungen der Server- oder Netzlast schneller realisiert werden. Wird die Zwischenspeicherung inaktiviert, müssen die Clients sich mit jeder Namensauflösungsanforderung an den maßgeblichen Namensserver wenden, was potenziell die Latenzzeit erhöht. Bei der Auswahl eines TTL-Wertes sollte sorgfältig abgewogen werden, welchen Einfluss das Inaktivieren der Zwischenspeicherung auf eine Umgebung hat. Es ist auch zu bedenken, dass der DNS-gestützte Lastausgleich potenziell von der Zwischenspeicherung von Namensauflösungen auf dem Client eingeschränkt werden kann.
TTL kann mit dem Befehl sscontrol sitename [add | set] konfiguriert werden. Weitere Informationen hierzu finden Sie im Abschnitt sscontrol sitename -- Sitenamen konfigurieren.
Die Netzproximität ist die Berechnung der Nähe jedes einzelnen Servers zum anfordernden Client. Zum Bestimmen der Netzproximität sendet der Agent Metric Server (der auf jedem Server mit Lastausgleich installiert sein muss) ein "ping" an die Client-IP-Adresse und meldet Site Selector die Antwortzeit. Site Selector bezieht die Proximitätsantwort in die Lastausgleichsentscheidung ein. Site Selector kombiniert den Wert der Netzproximitätsantwort mit der Wertigkeit vom Manager und ermittelt so die endgültige Wertigkeit für den Server.
Die Verwendung der Netzproximität mit Site Selector ist optional.
Site Selector stellt die folgenden Netzproximitätsoptionen bereit, die pro Sitenamen festgelegt werden können:
Ist dieser Wert auf ja gesetzt, sendet Metric Server ein "ping" an den Client, um die Zeit für die Proximitätsantwort zu ermitteln. Der Namensserver wartet auf die Antworten aller Metric-Server oder das Eintreten einer Zeitlimitüberschreitung. Anschließend erstellt der Namensserver für jeden Server aus der Zeit für die Proximitätsantwort und der vom Manager berechneten Wertigkeit eine kombinierte Wertigkeit. Site Selector teilt dem Client die Server-IP-Adresse mit der besten kombinierten Wertigkeit mit. (Es wird davon ausgegangen, dass die meisten Client-Namensserver ein Zeitlimit von 5 Sekunden haben. Site Selector versucht, vor Ablauf dieses Zeitlimits zu antworten.)
Ist dieser Wert auf nein gesetzt, erfolgt die Namensauflösung für den Client auf der Basis der aktuellen Wertigkeiten vom Manager. Anschließend sendet Metric Server ein "ping" an den Client, um die Zeit für die Proximitätsantwort zu ermitteln. Der Namensserver stellt die von Metric Server empfangene Antwortzeit in den Cache. Wenn der Client eine zweite Anforderung stellt, erstellt der Namensserver für jeden Server aus der aktuellen Wertigkeit vom Manager und dem zwischengespeicherten Wert der ping-Antwort eine kombinierte Wertigkeit. Site Selector gibt auf die zweite Anforderung des Clients die IP-Adresse des Servers mit der besten kombinierten Wertigkeit zurück.
Optionen für die Netzproximität können mit dem Befehl sscontrol sitename [add | set] gesetzt werden. Weitere Informationen hierzu finden Sie in Anhang D, Befehlsreferenz für Site Selector.
Lesen Sie vor Ausführung der in diesem Kapitel beschriebenen Schritte Kapitel 10, Planung für Site Selector. Dieses Kapitel erläutert das Erstellen einer Basiskonfiguration für die Komponente Site Selector von Network Dispatcher.
Tabelle 9. Konfigurations-Tasks für Site Selector
Task | Beschreibung | Referenzinformationen |
---|---|---|
Maschine mit Site Selector konfigurieren | Stellen Sie fest, welche Voraussetzungen zu erfüllen sind. | Maschine mit Site Selector konfigurieren |
Am Lastausgleich beteiligte Maschinen konfigurieren | Definieren Sie Ihre Lastausgleichskonfiguration. | Schritt 4. Am Lastausgleich beteiligte Servermaschinen definieren |
Es gibt im Wesentlichen vier Methoden für das Erstellen einer Basiskonfiguration für die Komponente Site Selector von Network Dispatcher:
Dies ist die direkte Methode für die Konfiguration von Site Selector. Die Werte der Befehlsparameter müssen in englischen Zeichen eingegeben werden. Die einzige Ausnahme hiervon bilden Host-Namen (die z. B. in den Befehlen "sitename" und "server" verwendet werden) und Dateinamen.
Starten Sie Site Selector wie folgt von der Befehlszeile aus:
Sie können eine Minimalversion der Parameter für den Befehl "sscontrol" eingeben. Sie müssen nur die eindeutigen Buchstaben der Parameter eingeben. Beispiel: Wenn Sie Hilfe für den Befehl zum Speichern von Dateien aufrufen möchten, können Sie sscontrol he f anstelle von sscontrol help file eingeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl sscontrol ab, um die Eingabeaufforderung "sscontrol" aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Die Befehle zum Konfigurieren von Site Selector können in eine Konfigurations-Script-Datei eingegeben und dann zusammen ausgeführt werden.
sscontrol file appendload meinScript
sscontrol file newload meinScript
Ein Beispiel für die GUI zeigt Abbildung 2.
Gehen Sie zum Starten der GUI wie folgt vor:
Zum Konfigurieren von Site Selector auf der GUI müssen Sie zunächst in der Baumstruktur Site Selector auswählen. Sie können den Manager starten, sobald Sie eine Verbindung zu einem Host hergestellt haben. Sie können auch Sitenamen mit Ports und Servern erstellen sowie Advisor-Funktionen für den Manager starten.
Von der GUI aus können Sie die gleichen Schritte wie mit dem Befehl sscontrol ausführen. Wenn Sie beispielsweise einen Sitenamen von der Befehlszeile aus definieren möchten, müssen Sie den Befehl sscontrol sitename add Sitename eingeben. Zum Definieren eines Sitenamens von der GUI aus müssen Sie mit der rechten Maustaste auf "Namensserver" klicken und in dem daraufhin angezeigten Popup-Menü mit der linken Maustaste auf Sitenamen hinzufügen. Geben Sie im Dialogfenster den Sitenamen ein und klicken Sie auf OK.
Bereits vorhandene Site-Selector-Konfigurationsdateien können Sie mit der im Popup-Menü Host angezeigten Option Neue Konfiguration laden (zum vollständigen Ersetzen der derzeitigen Konfiguration) oder An aktuelle Konfiguration anfügen (zum Aktualisieren der derzeitigen Konfiguration) laden. Sie sollten Ihre Site-Selector-Konfiguration von Zeit zu Zeit mit der Option Konfigurationsdatei sichern unter in einer Datei sichern. Diese Option ist ebenfalls im Popup-Menü Host enthalten. Über das Menü Datei oben auf der GUI können Sie Ihre aktuellen Host-Verbindungen in einer Datei speichern oder Verbindungen aus vorhandenen Dateien aller Network-Dispatcher-Komponenten wiederherstellen.
Sie können auf Hilfe zugreifen, indem Sie auf das Fragezeichen in der oberen rechten Ecke des Fensters von Network Dispatcher klicken.
Weitere Informationen zur Verwendung der GUI finden Sie im Abschnitt Allgemeine Anweisungen zur Verwendung der GUI.
Führen Sie folgende Schritte aus, wenn Sie den Konfigurationsassistenten verwenden:
Sie können den Assistenten von der Eingabeaufforderung aus starten, indem Sie den Befehl sswizard absetzen. Sie können den Konfigurationsassistenten aber auch auf der GUI unter der Komponente Site Selector auswählen.
Der Site-Selector-Assistent führt Sie schrittweise durch den Prozess zum Erstellen einer Basiskonfiguration für die Komponente Site Selector. Er stellt Ihnen Fragen zu Ihrem Netz und leitet Sie beim Konfigurieren eines Sitenamens an, mit dem Site Selector den Datenverkehr auf eine Gruppe von Servern verteilen kann.
Bei Verwendung des Konfigurationsassistenten für Site Selector erscheinen die folgenden Anzeigen:
Vor dem Konfigurieren der Maschine mit Site Selector müssen Sie (unter AIX, Linux oder Solaris) als Benutzer "root" oder (unter Windows 2000) als Administrator registriert sein.
Für eine Gruppe von Servern, die Sie konfigurieren, benötigen Sie einen nicht auflösbaren DNS-Host-Namen als Sitenamen. Der Sitename ist der Name, mit dem Clients auf Ihre Site zugreifen (z. B. www.IhreFirma.com). Site Selector verteilt mit dem DNS den Datenverkehr für die Site auf die Server der Gruppe.
AIX, Linux und Solaris: Geben Sie zum Starten der Serverfunktion ssserver ein.
Geben Sie zum Starten des Namensservers den Befehl sscontrol nameserver start ein.
Optional können Sie den Namensserver starten, indem Sie ihn mit dem Schlüsselwort "bindaddress" ausschließlich an die angegebene Adresse binden.
Site Selector verteilt die an den Sitenamen gesendeten Anforderungen auf die entsprechenden Server, die für die Site konfiguriert sind.
Der Sitename ist ein nicht auflösbarer Host-Name, den der Client anfordert. Der Sitename muss ein vollständig qualifizierter Domänenname sein (z. B. www.dnsdownload.com). Wenn ein Client diesen Sitename anfordert, wird eine der dem Sitenamen zugeordneten Server-IP-Adressen zurückgegeben.
Setzen Sie zum Definieren eines Sitenamens den folgenden Befehl ab:
sscontrol sitename add Sitename
Wenn Sie Optionen für den Sitenamen festlegen möchten, setzen Sie den folgenden Befehl ab:
sscontrol sitename set Wert_der_Sitenamenoption
Weitere Informationen hierzu finden Sie in Anhang D, Befehlsreferenz für Site Selector.
Die Servermaschinen sind die Maschinen, auf denen die Anwendungen ausgeführt werden, deren Last verteilt werden soll. Für den Server wird der symbolische Name der Servermaschine oder deren Adresse in Schreibweise mit Trennzeichen angegeben. Setzen Sie den folgenden Befehl ab, um für den Sitenamen von Schritt 3 einen Server zu definieren:
sscontrol server add Sitename:Server
Für einen Sitenamen müssen Sie mehrere Server definieren, um einen Lastausgleich durchführen zu können.
Die Manager-Funktion verbessert den Lastausgleich. Vergewissern Sie sich vor dem Starten der Manager-Funktion, dass auf allen am Lastausgleich beteiligten Maschinen Metric Server installiert ist.
Setzen Sie zum Starten des Managers den folgenden Befehl ab:
sscontrol manager start
Die Advisor-Funktionen liefern dem Manager weitere Informationen über die Fähigkeit der am Lastausgleich beteiligten Servermaschinen, auf Anforderungen zu antworten. Advisor-Funktionen sind protokollspezifisch. Network Dispatcher stellt zahlreiche Advisor-Funktionen bereit. Wenn Sie beispielsweise die HTTP-Advisor-Funktion für einen bestimmten Sitenamen starten möchten, setzen Sie den folgenden Befehl ab:
sscontrol advisor start http Sitename:Port
Informationen zur Verwendung von Systemmesswerten und Metric Server finden Sie im Abschnitt Metric Server.
Wenn Sie Advisor-Funktionen starten, können Sie die Wichtigkeit ändern, die in Entscheidungen für den Lastausgleich einfließenden Informationen von Advisor-Funktionen (Port-Informationen) beigemessen wird. Setzen Sie zum Festlegen der Proportionen für den Sitenamen den Befehl sscontrol sitename set Sitename proportions ab. Weitere Informationen hierzu finden Sie im Abschnitt Proportionale Bedeutung von Statusinformationen.
Sie sollten Metric Server zusammen mit der Komponente Site Selector verwenden. Informationen zum Konfigurieren von Metric Server auf allen Maschinen, für die Site Selector einen Lastausgleich durchführt, finden Sie im Abschnitt Metric Server.
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Komponente Consultant für Cisco CSS Switches berücksichtigen muss.
Dieses Kapitel umfasst:
Die Konfiguration für Cisco Consultant ist von der Konfiguration des Cisco CSS Switch abhängig (siehe Tabelle 10). Nachdem Sie die Planung und Konfiguration für den Cisco CSS Switch abgeschlossen haben, können Sie Cisco Consultant konfigurieren und verwenden. Planungs- und Konfigurationsanweisungen für den Cisco CSS Switch finden Sie in der zugehörigen Dokumentation.
Consultant umfasst Folgendes:
Die Advisor-Funktionen fragen die Server ab und analysieren die Ergebnisse nach Protokoll, bevor sie den Manager zum Festlegen der entsprechenden Wertigkeiten aufrufen. Derzeit stellt Cisco Consultant Advisor-Funktionen für HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3 (und andere) bereit. Sie können auch eigene Advisor-Funktionen schreiben. (Lesen Sie hierzu die Informationen im Abschnitt Kundenspezifische (anpassbare) Advisor-Funktion erstellen.) Die Verwendung der Advisor-Funktionen ist optional, wird jedoch empfohlen.
Metric Server gibt an Consultant Informationen zur Serverauslastung in Form systemspezifischer Messwerte weiter, die Aufschluss über den Zustand der Server geben. Der Manager fragt Metric Server auf den einzelnen Servern ab. Dabei verwendet er die Messwerte der Agenten, um die Zuordnung von Wertigkeiten für den Prozess des Lastausgleichs zu unterstützen. Die Ergebnisse werden auch in den Manager-Bericht gestellt.
Der Manager sammelt Informationen vom Cisco CSS Switch, von den Advisor-Funktionen und von Metric Server. Der Manager passt anhand der erhaltenen Informationen die Wertigkeit der Servermaschinen an den einzelnen Ports an und teilt dem Cisco CSS Switch die neue Wertigkeit mit, die dieser dann beim Lastausgleich für neue Verbindungen verwendet. Wenn der Manager feststellt, dass ein Server inaktiv ist, ordnet er diesem Server die Wertigkeit null zu und setzt den Serverbetrieb aus. Der Cisco CSS Switch stellt daraufhin die Weiterleitung von Datenverkehr an diesen Server ein.
Die Advisor-Funktionen überwachen jeden Server am zugeordneten Port, um die Antwortzeit und die Verfügbarkeit der einzelnen Server zu ermitteln. Diese Informationen werden dann an den Manager weitergegeben. Die Advisor-Funktionen überwachen zudem, ob ein Server aktiv oder inaktiv ist.
Eine ordnungsgemäße Consultant-Konfiguration muss die Konfiguration des Cisco CSS Switch spiegeln. Lesen Sie zunächst die Informationen in der Veröffentlichung Cisco Services Switch Getting Started Guide zum Konfigurieren des Cisco CSS Switch. Konfigurieren Sie Consultant erst, wenn der Switch fehlerfrei funktioniert.
Die Konfiguration des Cisco CSS Switch umfasst Eigner, content-Regeln und
Dienste, die einer Consultant-Konfiguration wie folgt zugeordnet werden:
Tabelle 10. Begriffe für die Konfiguration von Consultant und des Cisco CSS Switch
Cisco CSS Switch | Consultant |
---|---|
Virtuelle IP-Adresse (VIP) der content-Regeln von einem oder mehreren der Eigner | Cluster |
In der content-Regel enthaltener Port | Port |
Dienst | Server |
Die Consultant-Konfiguration umfasst Folgendes:
Abbildung 21. Konfigurationsbeispiel für Consultant mit 2 Clustern mit jeweils 3 Ports
Für den Executor müssen Sie eine Adresse und einen Namen der
SNMP-Benutzergemeinschaft konfigurieren, die mit den entsprechenden Attributen
des Cisco CSS Switch übereinstimmen. Informationen zum Konfigurieren
des Executors finden Sie im Abschnitt lbccontrol executor -- Executor steuern.
Cisco CSS SwitchKonfiguration | ConsultantKonfiguration |
---|---|
username admin superuser snmp community Benutzergemeinschaft private read-write |
lbccontrol executor set address 10.10.20.1 lbccontrol executor set communityname Benutzergemeinschaft |
content-Regel 1 port 80 balance weightedrr add service Server1 add service Server2 vip address 9.67.154.35 active |
lbccontrol cluster add 9.67.154.35 lbccontrol port add 9.67.154.35:80 |
content-Regel 2 protocol tcp port 443 balance weightedrr add service Server3 add service Server4 vip address 9.67.154.35 active |
lbccontrol port add 9.67.154.35:443 |
service Server1 ip address 10.10.20.2 port 80 weight 4 active |
lbccontrol server add 9.67.154.35:80:Server1 address 10.10.20.2 |
service Server3 ip address 10.10.20.4 port 443 weight 4 active |
lbccontrol server add 9.67.154.35:443:Server3 address 10.10.20.4 |
Lesen Sie vor Ausführung der in diesem Kapitel beschriebenen Schritte Kapitel 12, Planung für Consultant für Cisco CSS Switches. Dieses Kapitel erläutert das Erstellen einer Basiskonfiguration für die Komponente Consultant für Cisco CSS Switches von Network Dispatcher.
Vor Ausführung einer der in diesem Kapitel beschriebenen Konfigurationsmethoden müssen Sie die folgenden Schritte ausführen:
Tabelle 12. Konfigurations-Tasks für Consultant für Cisco CSS Switches
Task | Beschreibung | Referenzinformationen |
---|---|---|
Konfigurieren der Maschine mit Consultant für Cisco CSS Switches | Ermitteln Sie die Voraussetzungen. | Maschine mit Consultant für Cisco CSS Switches konfigurieren |
Testen der Konfiguration | Überprüfen Sie, ob die Konfiguration funktioniert. | Konfiguration testen |
Es gibt im Wesentlichen drei Methoden für das Erstellen einer Basiskonfiguration für die Komponente Consultant für Cisco CSS Switches von Network Dispatcher:
Dies ist die direkte Methode für die Konfiguration von Cisco Consultant. Bei den in diesem Handbuch beschriebenen Prozeduren wird von der Verwendung der Befehlszeile ausgegangen. Die Werte der Befehlsparameter müssen in englischen Zeichen eingegeben werden. Die einzige Ausnahme hiervon bilden Host-Namen (die z. B. in den Befehlen "cluster" und "server" verwendet werden) und Dateinamen.
Starten Sie Cisco Consultant wie folgt von der Befehlszeile aus:
Sie können eine gekürzte Version der Parameter für den Befehl "lbccontrol" eingeben. Sie müssen nur die eindeutigen Buchstaben der Parameter eingeben. Beispiel: Wenn Sie Hilfe für den Befehl zum Speichern von Dateien aufrufen möchten, können Sie lbccontrol he f anstelle von lbccontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl lbccontrol ab, um die Eingabeaufforderung "lbccontrol" aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Die Befehle zum Konfigurieren von Consultant für Cisco CSS Switches können in eine Konfigurations-Script-Datei eingegeben und dann zusammen ausgeführt werden.
lbccontrol file appendload meinScript
lbccontrol file newload meinScript
Abbildung 2 zeigt ein Beispiel für die grafische Benutzerschnittstelle (GUI).
Gehen Sie zum Starten der GUI wie folgt vor:
lbcserver
Gehen Sie zum Konfigurieren von Cisco Consultant von der GUI aus wie folgt vor:
Von der GUI aus können Sie alle mit dem Befehl lbccontrol ausführbaren Schritte ausführen. Wenn Sie beispielsweise einen Cluster von der Befehlszeile aus konfigurieren möchten, müssten Sie den Befehl lbccontrol cluster add Cluster eingeben. Zum Definieren eines Clusters von der GUI aus müssen Sie mit der rechten Maustaste auf "Executor" und dann mit der linken Maustaste auf Cluster hinzufügen klicken. Geben Sie die Cluster-Adresse in das Dialogfenster ein und klicken Sie dann auf OK.
Bereits vorhandene Konfigurationsdateien für Cisco Consultant können Sie mit der im Popup-Menü Host angezeigten Option Neue Konfiguration laden (zum vollständigen Ersetzen der derzeitigen Konfiguration) oder An aktuelle Konfiguration anfügen (zum Aktualisieren der derzeitigen Konfiguration) laden. Wählen Sie regelmäßig die Option Konfigurationsdatei sichern als aus, um Ihre Konfiguration für Cisco Consultant in einer Datei zu speichern. Wenn Sie in der Menüleiste auf Datei klicken, können Sie Ihre aktuellen Host-Verbindungen in einer Datei speichern oder Verbindungen aus vorhandenen Dateien aller Network-Dispatcher-Komponenten wiederherstellen.
Falls Sie Hilfe benötigen, klicken Sie oben rechts im Network-Dispatcher-Fenster auf das Fragezeichen.
Weitere Informationen zur Verwendung der GUI finden Sie im Abschnitt Allgemeine Anweisungen zur Verwendung der GUI.
Vor dem Konfigurieren der Maschine mit Consultant für Cisco CSS Switches müssen Sie (unter AIX, Linux oder Solaris) als Benutzer "root" oder (unter Windows 2000) als Administrator registriert sein.
Consultant muss eine Verbindung zum Cisco CSS Switch als Cisco-CSS-Switch-Administrator herstellen können.
Wenn Sie den Executor konfigurieren, müssen die Adresse und der Name der SNMP-Benutzergemeinschaft mit den entsprechenden Attributen des Cisco CSS Switch übereinstimmen.
Hilfe zu den in dieser Prozedur verwendeten Befehlen finden Sie in Anhang E, Befehlsreferenz für Consultant für Cisco CSS Switches.
Wenn lbcserver noch nicht aktiv ist, starten Sie den Dienst jetzt, indem Sie als Root den folgenden Befehl absetzen:
lbcserver
Sie müssen eine Adresse und einen Namen für die SNMP-Benutzergemeinschaft konfigurieren. Diese Werte müssen mit den entsprechenden Attributen des Cisco CSS Switch übereinstimmen.
Cluster ist entweder ein auflösbarer Name oder eine Adresse in Schreibweise mit Trennzeichen. Der Cluster entspricht der virtuellen IP-Adresse des Cisco CSS Switch für die content-Regel eines Eigners.
Geben Sie zum Definieren eines Clusters lbccontrol cluster add Cluster ein. Zum Festlegen von Cluster-Optionen müssen Sie lbccontrol cluster set eingeben.
Geben Sie zum Definieren eines Ports lbccontrol port add Cluster:Port ein. Der Port entspricht dem Port, der in der content-Regel des Cisco CSS Switch für den Eigner konfiguriert ist.
Port ist die Nummer des Ports, den Sie für dieses Protokoll verwenden und die in der content-Regel des Eigners für den Cisco CSS Switch angegeben ist. Weitere Informationen hierzu finden Sie im Abschnitt lbccontrol port -- Ports konfigurieren.
Sie können für jede Cluster-Port-Kombination mehrere Instanzen eines Servers konfigurieren. (Denken Sie daran, dass die Adresse und der Name der SNMP-Benutzergemeinschaft mit den entsprechenden Attributen des Cisco CSS Switch übereinstimmen muss.) Wenn Sie mehrere Instanzen eines Servers konfigurieren, können Sie zwischen verschiedenen Anwendungsservern unterscheiden, die sich auf einer physischen Maschine befinden und am selben Port auf dieselbe IP-Adresse reagieren.
Geben Sie zum Definieren einer am Lastausgleich beteiligten Servermaschine Folgendes ein:
lbccontrol server add Cluster:Port:Server address x.x.x.x | Host-Name
Der Server entspricht dem Dienstnamen des Cisco CSS Switch.
Für einen Cluster müssen Sie pro Port mehrere Server definieren, um einen Lastausgleich durchführen zu können. Andernfalls muss der gesamte Datenverkehr von einem Server verarbeitet werden. Lesen Sie hierzu die Informationen im Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Weitere Informationen zur Syntax des Befehls "lbccontrol server" finden Sie im Abschnitt lbccontrol server -- Server konfigurieren.
Geben Sie zum Starten des Managers den Befehl lbccontrol manager start ein. Weitere Informationen hierzu finden Sie im Abschnitt lbccontrol manager -- Manager steuern.
Die Advisor-Funktionen liefern dem Manager weitere Informationen über die Fähigkeit der am Lastausgleich beteiligten Servermaschinen, auf Anforderungen zu antworten. Advisor-Funktionen sind protokollspezifisch. Soll beispielsweise die HTTP-Advisor-Funktion gestartet werden, setzen Sie den folgenden Befehl ab:
lbccontrol advisor start http PortEine Liste der Advisor-Funktionen mit den zugehörigen Standard-Ports finden Sie im Abschnitt lbccontrol advisor -- Advisor steuern. Eine Beschreibung der einzelnen Advisor-Funktionen können Sie dem Abschnitt Liste der Advisor-Funktionen entnehmen.
Wenn Sie Advisor-Funktionen starten, müssen Sie die Cluster-Proportionen so ändern, dass die Informationen der Advisor-Funktionen in die Entscheidungen zum Lastausgleich einbezogen werden. Verwenden Sie den Befehl lbccontrol cluster proportions. Lesen Sie hierzu die Informationen im Abschnitt Proportionale Bedeutung von Statusinformationen.
Informationen zur Verwendung von Metric Server finden Sie im Abschnitt Metric Server.
Testen Sie, ob die Konfiguration korrekt ist.
In diesem Kapitel wird erklärt, wie die Lastausgleichparameter von Network Dispatcher konfiguriert werden und Network Dispatcher für die Verwendung der erweiterten Funktionen eingerichtet wird.
Tabelle 13. Erweiterte Konfigurations-Tasks für Network Dispatcher
Task | Beschreibung | Referenzinformationen |
---|---|---|
Ändern der Einstellungen für den Lastausgleich (optional) |
Sie können die folgenden Einstellungen für den Lastausgleich ändern:
| Lastausgleich mit Network Dispatcher optimieren |
Verwendung von Scripts, um einen Alert zu generieren oder Serverausfälle zu protokollieren, wenn der Manager Server als inaktiv/aktiv markiert | Network Dispatcher stellt Benutzer-Exits bereit, die Scripts aktivieren, wenn der Manager Server als inaktiv/aktiv markiert. | Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden |
Verwendung von Advisor-Funktionen und Erstellen angepasster Advisor-Funktionen | Beschreibt die Advisor-Funktionen und das Schreiben eigener angepasster Advisor-Funktionen zum protokollieren spezifischer Serverstatus | Advisor-Funktionen Kundenspezifische (anpassbare) Advisor-Funktion erstellen |
Verwendung der WLM-Advisor-Funktion (Workload Manager) | Die WLM-Advisor-Funktion stellt Informationen zur Systembelastung für Network Dispatcher bereit. | Advisor-Funktion Workload Manager |
Verwendung des Agenten Metric Server | Metric Server stellt Informationen zur Systembelastung für Network Dispatcher bereit. | Metric Server |
Verwendung der Serverpartitionierung | Definieren Sie logische Server zur Verteilung der Last ausgehend von den verfügbaren Diensten. | Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse) |
Option "Advisor-Anforderung/Antwort (URL)" | Definieren Sie eine eindeutige HTTP-URL-Zeichenfolge für einen spezifischen Dienst, der auf der Maschine abgefragt werden soll. | Option 'Anforderung/Antwort (URL)' der HTTP-Advisor-Funktion |
Verknüpfung von Network Dispatcher mit einer am Laustausgleich beteiligten Maschine | Konfigurieren Sie eine verknüpfte Network-Dispatcher-Maschine. | Verknüpfte Server verwenden |
Konfigurieren der Weitverkehrsunterstützung von Dispatcher | Konfigurieren Sie einen fernen Dispatcher für den Lastausgleich in einem WAN. Der Lastausgleich in einem WAN kann auch (ohne fernen Dispatcher) mit einer Serverplattform durchgeführt werden, die GRE unterstützt. | Dispatcher-WAN-Unterstützung konfigurieren |
Konfigurieren der hohen Verfügbarkeit oder der gegenseitigen hohen Verfügbarkeit | Konfigurieren Sie eine zweite Dispatcher-Maschine, um eine Ausweichmaschine zu haben. | Hohe Verfügbarkeit |
Konfigurieren des regelbasierten Lastausgleichs | Definieren Sie Bedingungen, unter denen eine Untergruppe Ihrer Server verwendet wird. | Regelbasierten Lastausgleich konfigurieren |
Verwendung expliziter Verbindungen | Vermeiden Sie es, den Dispatcher in Verbindungen zu umgehen. | Explizite Verbindungen benutzen |
Verwendung eines privaten Netzes | Konfigurieren Sie den Dispatcher für den Lastausgleich bei Servern in einem privaten Netz. | Konfiguration für ein privates Netz verwenden |
Zusammenfassung allgemeiner Serverkonfigurationen durch einen Platzhalter-Cluster | Adressen, die nicht explizit konfiguriert sind, verwenden den Platzhalter-Cluster für die Verteilung des Datenverkehrs. | Platzhalter-Cluster verwenden, um Serverkonfigurationen zusammenzufassen |
Verwendung eines Platzhalter-Clusters für den Lastausgleich bei Firewalls | Es erfolgt ein Lastausgleich des gesamten Datenverkehrs für Firewalls. | Platzhalter-Cluster für den Lastausgleich von Firewalls verwenden |
Verwendung eines Platzhalter-Clusters mit Caching Proxy für transparente Weiterleitung | Der Dispatcher kann zum Aktivieren einer transparenten Weiterleitung verwendet werden. | Platzhalter-Cluster mit Caching Proxy für transparente Weiterleitung verwenden |
Verwendung eines Platzhalter-Ports für die Übertragung von Datenverkehr mit nicht konfiguriertem Port | Ermöglicht die Bearbeitung von Datenverkehr, der für keinen bestimmten Port konfiguriert ist. | Platzhalter-Port für die Übertragung von Datenverkehr mit nicht konfiguriertem Port verwenden |
Verwendung der Affinitätsfunktion zum Konfigurieren einer Haltezeit für einen Cluster-Port | Ermöglicht das Übertragen von Client-Anforderungen an denselben Server. | Funktionsweise der Affinität für Network Dispatcher |
Verwendung der SDA-API (Server Directed Affinity) | Stellt eine API zur Verfügung, mit der ein externer Agent das Affinitätsverhalten des Dispatchers beeinflussen kann. | SDA-API zur Steuerung der Client-/Serveraffinität |
Verwendung der Port-übergreifenden Affinität, um die Affinität an allen Ports zu nutzen | Ermöglicht den Empfang von Client-Anforderungen von verschiedenen Ports und deren Übertragung an einen Server. | Port-übergreifende Affinität |
Verwendung der Affinitätsadressmaske zum Festlegen einer gemeinsamen IP-Teilnetzadresse | Ermöglicht das Übertragen von Client-Anforderungen, die aus demselben Teilnetz empfangen werden, an denselben Server. | Affinitätsadressmaske |
Außerkraftsetzung der Regelaffinität, damit ein Server die Port-Affinität außer Kraft setzen kann | Ermöglicht einem Server, die Einstellung für stickytime an seinem Port zu überschreiben. | Überschreibung der Regelaffinität |
Verwendung der aktiven Cookie-Affinität um die Last von Servern für CBR auszugleichen | Diese Regeloption ermöglicht die Bindung einer Sitzung an einen bestimmten Server. | Aktive Cookie-Affinität |
Verwendung der passiven Cookie-Affinität, um die Last von Servern für die inhaltsabhängige Weiterleitung und die CBR-Komponente auszugleichen. | Mit dieser Regeloption kann eine Sitzung ausgehend vom Cookie-Namen/Wert an einen bestimmten Server gebunden werden. | Passive Cookie-Affinität |
Verwendung der URI-Affinität für den Lastausgleich bei Caching-Proxy-Servern mit Zwischenspeicherung spezifischer Inhalte auf jedem einzelnen Server | Mit dieser Regeloption kann eine Sitzung ausgehend vom URI an einen bestimmten Server gebunden werden. | URI-Affinität |
Verwendung der DoS-Erkennung für die Benachrichtigung von Administratoren über potenzielle Attacken (per Alert) | Der Dispatcher analysiert eingehende Anforderungen auf eine verdächtige Anzahl halboffener TCP-Verbindungen auf Servern. | Erkennung von DoS-Attacken |
Binäre Protokollierung zur Analyse der Serverstatistik | Ermöglicht das Speichern von Serverinformationen in Binärdateien und das Abrufen dieser Informationen aus Binärdateien. | Binäres Protokollieren verwenden, um Serverstatistiken zu analysieren |
Verwendung von Cisco Consultant (zusätzliche Informationen) | Interaktion von Cisco Consultant und dem Cisco CSS Switch sowie zusätzliche Informationen zum Konfigurieren von Wertigkeiten | Zusätzliche Informationen zu den erweiterten Funktionen von Cisco Consultant |
Die Manager-Funktion von Network Dispatcher 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 Metric Server Agent). Für Site Selector wird diese Proportion anstelle 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 anstelle 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 Bedeutung 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 die Advisor-Funktion WLM hinzufügen und die Proportion der Systemmesswerte 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 vermindert 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 Client-Verbindungen schnell (wie bei kleinen Webseiten, die mit HTTP GET bedient werden), ist die Anzahl aktiver Verbindungen ziemlich klein. Wenn die Client-Verbindungen 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 von Network Dispatcher inaktiviert.
Verwenden Sie zum Festlegen der proportionalen Bedeutung den Befehl ndcontrol cluster set Cluster proportions. Weitere Informationen hierzu finden Sie im Abschnitt ndcontrol cluster -- Cluster konfigurieren.
Die Manager-Funktion legt Wertigkeiten ausgehend von internen Zählern des Executors, vom Feedback der Advisor-Funktionen 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 "ndcontrol 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 Anforderungen entsprechend ihrer relativen Wertigkeit 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 ndcontrol port set weightbound. Mit diesem Befehl wird die Differenz festgelegt, die für die einzelnen Server hinsichtlich der Anzahl der Anforderungen gelten soll. Wird die maximale Wertigkeit 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 maximalen Wertigkeit von 2 kann ein Server doppelt so viele Anforderungen wie ein anderer Server erhalten. Bei einer maximalen Wertigkeit von 10 kann ein Server zehn Mal so viele Anforderungen wie ein anderer Server erhalten. Der Standardwert für die maximale Wertigkeit ist 20.
Stellt eine Advisor-Funktion 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.
Ohne den Manager können Advisor-Funktionen nicht ausgeführt werden und nicht erkennen, ob ein Server inaktiv ist. Wenn Sie die Advisor-Funktionen ausführen möchten, der Manager jedoch nicht die von Ihnen für einen bestimmten Server festgelegte Wertigkeit aktualisieren soll, verwenden Sie den Befehl "ndcontrol server" mit der Option fixedweight. Beispiel:
ndcontrol server set Cluster:Port:Server fixedweight yes
Nachdem Sie "fixedweight" auf "yes" gesetzt haben, können Sie die Wertigkeit mit dem Befehl ndcontrol 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 "ndcontrol server" absetzen, bei dem "fixedweight" auf "no" gesetzt ist. Weitere Informationen hierzu finden Sie im Abschnitt ndcontrol server -- Server konfigurieren.
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 ndcontrol manager interval und ndcontrol manager refresh ändern.
Mit dem Manager-Intervall wird angegeben, wie oft der Manager die Serverwertigkeiten aktualisiert, die der Executor für die Weiterleitung von Verbindungen benutzt. Ein zu niedriges Manager-Intervall kann sich negativ auf die Leistung auswirken, da der Manager den Executor permanent unterbricht. Ein zu hohes Manager-Intervall kann bedeuten, dass die Weiterleitung von Anforderungen durch den Executor nicht auf genauen, auf dem neuesten Stand befindlichen Informationen basiert.
Wollen Sie beispielsweise das Manager-Intervall auf 1 Sekunde setzen, geben Sie den folgenden Befehl ein:
ndcontrol 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:
ndcontrol manager refresh 3
In diesem Fall wartet der Manager 3 Intervalle ab, bevor er Statusinformationen vom Executor anfordert.
Network Dispatcher bietet noch weitere Methoden der Optimierung des Lastausgleichs für Ihre Server. 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äßigen 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:
ndcontrol 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. Der Glättungsfaktor begrenzt das Maß, in dem sich die Wertigkeit eines Servers ändern kann, und dämpft so die Änderung bei der Verteilung von Anforderungen. 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:
ndcontrol manager smoothing 4
In den meisten Fällen müssen Sie diesen Wert nicht ändern.
Network Dispatcher stellt Benutzer-Exits 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. Scripts, die Sie anpassen können, finden Sie im Installationsverzeichnis ...nd/servers/samples. Zum Ausführen der Dateien müssen Sie sie in das Verzeichnis ...nd/servers/bin verschieben und die Erweiterung ".sample" löschen. Es stehen die folgenden Beispiel-Scripts bereit:
Advisor-Funktionen sind Agenten von Network Dispatcher. Ihr Zweck ist es, den Zustand und die Belastung 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-Funktionen für die am häufigsten verwendeten Protokolle zur Verfügung. Es ist jedoch nicht sinnvoll, alle verfügbaren Advisor-Funktionen mit jeder Komponente von Network Dispatcher zu verwenden. (Die Telnet-Advisor-Funktion wird beispielsweise nicht mit der CBR-Komponente verwendet.) Network Dispatcher unterstützt auch das Konzept der "angepassten Advisor-Funktion", so dass Benutzer eigene Advisor-Funktionen schreiben können.
Einschränkung für bindungsspezifische Serveranwendungen unter Linux: Unter Linux bietet Network Dispatcher keine Unterstützung für die Verwendung von Advisor-Funktionen beim Lastausgleich für Server mit bindungsspezifischen Serveranwendungen (einschließlich anderer Komponenten von Network Dispatcher wie Mailbox Locator oder Site Selector), wenn die Bindung an die Cluster-IP-Adresse erfolgt.
Advisor-Funktionen ö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. Die HTTP-Advisor-Funktion sendet beispielsweise eine HTTP-Anfrage "HEAD" an den Server.
Die Advisor-Funktionen warten dann auf den Empfang einer Antwort vom Server. Nach Empfang der Antwort beurteilt die Advisor-Funktion den Server. Um diesen "Lastwert" zu ermitteln, messen die meisten Advisor-Funktionen die Zeit, bis der Server antwortet, und verwenden dann diesen Wert (in Millisekunden) als Lastwert.
Die Advisor-Funktionen übergeben dann den Lastwert an die Manager-Funktion, die ihn im Manager-Bericht 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 Client-Verbindungen.
Stellt die Advisor-Funktion fest, dass ein Server aktiv ist und ordnungsgemäß arbeitet, meldet er einen positiven Lastwert ungleich null an den Manager. Stellt die Advisor-Funktion fest, dass ein Server inaktiv ist, gibt er den speziellen Lastwert -1 zurück. Der Manager und der Executor leiten in diesem Fall keine weiteren Verbindungen an diesen Server weiter.
Sie können eine Advisor-Funktion Cluster-übergreifend für einen bestimmten Port starten (Gruppen-Advisor-Funktion). Sie können aber auch an einem Port verschiedene Advisor-Funktionen für verschiedene Cluster ausführen (Cluster-/sitespezifische Advisor-Funktion). Wenn Sie Network Dispatcher beispielsweise mit drei Clustern (ClusterA, ClusterB, ClusterC), jeweils mit Port ,80 konfiguriert haben, können Sie folgende Schritte ausführen:
ndcontrol advisor start http ClusterA:80Dieser Befehl startet die Advisor-Funktion "http" am Port 80 für ClusterA. Die Advisor-Funktion "http" wird für alle Port 80 von ClusterA zugeordneten Server ausgeführt.
ndcontrol advisor start angepasster_Advisor 80Dieser Befehl startet die Advisor-Funktion angepasster_Advisor am Port 80 von ClusterB und ClusterC. Die angepasste Advisor-Funktion wird für alle Port 80 von ClusterB und ClusterC zugeordneten Server ausgeführt. (Weitere Informationen zu angepassten Advisor-Funktionen finden Sie im Abschnitt Kundenspezifische (anpassbare) Advisor-Funktion erstellen.)
Wenn Sie das obige Konfigurationsbeispiel für die Gruppen-Advisor-Funktion verwenden, können Sie bei Bedarf die angepasste Advisor-Funktion angepasster_Advisor am Port 80 für einen oder beide Cluster (ClusterB und ClusterC) stoppen.
ndcontrol advisor stop angepasster_Advisor ClusterB:80
ndcontrol advisor stop angepasster_Advisor 80
Das Advisor-Intervall legt fest, wie oft eine Advisor-Funktion den Status der Server an dem von ihr überwachten Port abfragt und die Ergebnisse dann an den Manager übergibt. Ein zu niedriges Advisor-Intervall kann sich negativ auf die Leistung auswirken, da der Advisor die Server permanent unterbricht. Ist das Advisor-Intervall zu hoch, basieren die Entscheidungen des Managers hinsichtlich der Gewichtung unter Umständen nicht auf exakten aktuellen Informationen.
Wenn Sie das Intervall der HTTP-Advisor-Funktion am Port 80 beispielsweise auf 3 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:
ndcontrol advisor interval http 80 3
Es ist nicht sinnvoll, ein Advisor-Intervall anzugeben, das kleiner als das Manager-Intervall ist. Das Standard-Advisor-Intervall liegt bei sieben Sekunden.
Der Manager verwendet keine Informationen einer Advisor-Funktion, deren Zeitmarke älter als die für das Berichtszeitlimit der Advisor-Funktion festgelegte Zeit ist, um sicherzustellen, dass keine veralteten Informationen verwendet werden. Das Berichtszeitlimit der Advisor-Funktion muss größer als das Sendeaufrufintervall der Advisor-Funktion sein. Ist das Zeitlimit kleiner, ignoriert der Manager Berichte, die logisch betrachtet verwendet werden müssten. Für Berichte der Advisor-Funktion gilt standardmäßig kein Zeitlimit, so dass der Standardwert "unlimited" ist.
Wenn Sie das Berichtszeitlimit für die HTTP-Advisor-Funktion am Port 80 beispielsweise auf 30 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:
ndcontrol advisor timeout http 80 30
Weitere Informationen zum Festlegen des Berichtszeitlimit für die Advisor-Funktion finden Sie im Abschnitt ndcontrol advisor -- Advisor steuern.
Für Network Dispatcher können Sie die Zeitlimits der Advisor-Funktion festlegen, innerhalb derer der Ausfall eines Servers festgestellt werden soll. Die Zeitlimits für ausgefallene Server ("connecttimeout" und "receivetimeout") bestimmen, wie lange eine Advisor-Funktion wartet, bis sie einen gescheiterten Sende- oder Empfangsvorgang meldet.
Für eine schnellstmögliche Erkennung ausgefallener Server müssen Sie das Verbindungs- und Empfangszeitlimit der Advisor-Funktion auf den kleinsten Wert (eine Sekunde) sowie das Intervall für Advisor-Funktion und Manager auf den kleinsten Wert (eine Sekunde) setzen.
Wenn Sie "connecttimeout" und "receivetimeout" für die HTTP-Advisor-Funktion am Port 80 beispielsweise auf 9 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:
ndcontrol advisor connecttimeout http 80 9 ndcontrol advisor receivetimeout http 80 9
Der Standardwert für das Verbindungs- und Empfangszeitlimit liegt beim Dreifachen des Wertes, der für das Intervall der Advisor-Funktion angegeben wurde.
Die kundenspezifische (anpassbare) Advisor-Funktion 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 der angepassten Advisor-Funktion, das Bereitstellen von Status und Berichten sowie das Aufzeichnen von Protokolldaten in einer Protokolldatei. Er übergibt auch die Ergebnisse an die Manager-Funktion. Der Basiscode führt regelmäßig einen Advisor-Zyklus 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" der angepassten Advisor-Funktion auf. Die angepasste Advisor-Funktion 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. (Die angepasste Advisor-Funktion 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 die angepasste Advisor-Funktion können im normalen Modus oder im Ersetzungsmodus arbeiten. Die Auswahl der Betriebsart wird in der Datei der angepassten Advisor-Funktion als Parameter der Methode "constructor" angegeben.
Im normalen Modus tauscht die angepasste Advisor-Funktion Daten mit dem Server aus. Der Basiscode der Advisor-Funktion misst die Zeit für den Austausch und berechnet den Lastwert. Der Basiscode übergibt dann diesen Lastwert an den Manager. Die angepasste Advisor-Funktion muss nur null (bei Erfolg) oder -1 (bei einem Fehler) zurückgeben. Zur Angabe des normalen Modus wird die Markierung "replace" der Methode "constructor" auf "false" (falsch) gesetzt.
Im Ersetzungsmodus führt der Basiscode keine Zeitmessungen aus. Der Code der angepassten Advisor-Funktion 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 die Markierung "replace" der Methode "constructor" auf "true" gesetzt werden.
Auf diese Weise können Sie eigene Advisor-Funktionen schreiben, die die benötigten präzisen Informationen über Server zur Verfügung stellen. Zu Network Dispatcher wird ein Beispiel für eine angepasste Advisor-Funktion, ADV_sample.java, geliefert. Nach der Installation von Network Dispatcher finden Sie den Beispielcode im Installationsverzeichnis ...nd/servers/samples/CustomAdvisors.
Die Standardinstallationsverzeichnisse sind:
Das Installationsverzeichnis von Network Dispatcher enthält Beispieldateien für angepasste Advisor-Funktionen, insbesondere für die WAS-Advisor-Funktion (WebSphere Application Server).
Die Beispieldateien für die WAS-Advisor-Funktion befinden sich in demselben Verzeichnis wie die Datei ADV_sample.java.
Der Dateiname für Ihre angepasste Advisor-Funktion 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-Funktionen werden in der Sprache Java geschrieben. Sie müssen deshalb einen Java-1.3-Compiler für Ihre Maschine erwerben und installieren. Während der Kompilierung wird auf die folgenden Dateien Bezug genommen:
Der Klassenpfad muss während der Kompilierung auf die Datei der angepassten Advisor-Funktion und die Datei mit den Basisklassen zeigen.
Ein Kompilierungsbefehl für Windows 2000 könnte wie folgt aussehen:
javac -classpath <Installationsverzeichnis>\nd\servers\lib\ibmnd.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 der Advisor-Funktion die Klassendatei in das Unterverzeichnis ...nd/servers/lib/CustomAdvisors des Installationsverzeichnisses von Network Dispatcher.
Für AIX, Linux und Sun ist die Syntax ähnlich.
Bevor Sie die angepasste Advisor-Funktion ausführen, müssen Sie die Klassendatei in das richtige Unterverzeichnis von Network Dispatcher kopieren:
.../nd/servers/lib/CustomAdvisors/ADV_fred.class
Konfigurieren Sie die Komponente, starten Sie die zugehörige Manager-Funktion und setzen Sie wie folgt den Befehl zum Starten der angepassten Advisor-Funktion ab:
ndcontrol advisor start fred 123
Für diesen Befehl gilt Folgendes:
Eine angepasste Advisor-Funktion erweitert wie alle anderen Advisor-Funktionen den Advisor-Basiscode ADV_Base. Es ist der Advisor-Basiscode, der die meisten Funktionen ausführt. Dazu gehört das Zurückmelden von Belastungen an den Manager, die für den Wertigkeitsalgorithmus des Managers verwendet werden. Darüber hinaus stellt der Advisor-Basiscode Socket-Verbindungen her, schließt Sockets und stellt Sende- und Empfangsmethoden für die Advisor-Funktion bereit. Die Advisor-Funktion 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 Advisor-Basiscodes sind zeitlich gesteuert, um die Last zu berechnen. Mit einer Markierung der Methode "constructor" in ADV_base kann bei Bedarf die vorhandene Last mit der neuen, von der Advisor-Funktion zurückgegebenen Last überschrieben werden.
Basisklassenmethoden sind:
Network Dispatcher durchsucht zunächst die Liste der eigenen Advisor-Funktionen. Wenn eine bestimmte Advisor-Funktion dort nicht aufgeführt ist, durchsucht Network Dispatcher die Kundenliste der angepassten Advisor-Funktionen.
/usr/lpp/nd/servers/lib/CustomAdvisors/
/opt/nd/servers/lib/CustomAdvisors/
/opt/nd/servers/lib/CustomAdvisors/
Allgemeiner Installationsverzeichnispfad:
C:\Programme\IBM\edge\nd\servers\lib\CustomAdvisors
Interner Installationsverzeichnispfad:
C:\Programme\IBM\nd\servers\lib\CustomAdvisors
Die Programmliste für eine Beispiel-Advisor-Funktion finden Sie im Abschnitt Beispiel-Advisor-Funktion. Nach der Installation befindet sich diese Beispiel-Advisor-Funktion im Verzeichnis ...nd/servers/samples/CustomAdvisors.
WLM ist Code, der auf MVS-Großrechnern ausgeführt wird. Er kann abgefragt werden, um die Belastung 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 der Advisor-Funktion WLM öffnet der Dispatcher regelmäßig Verbindungen über den WLM-Port der einzelnen Server in der Dispatcher-Host-Tabelle und akzeptiert die zurückgegebenen ganzzahligen Kapazitätswerte. Da diese ganzen Zahlen die noch verfügbare Kapazitüt darstellen und der Dispatcher Werte erwartet, die die Belastung auf jeder Maschine angeben, werden die ganzzahligen Kapazitätswerte vom Advisor in Lastwerte umgekehrt und normalisiert (d. h., ein hoher ganzzahliger Kapazitätswert und ein niedriger Lastwert geben beide einen akzeptablen Zustand eines Servers an). Die daraus resultierenden Belastungen werden in die Spalte 'System' des Manager-Berichts gestellt.
Es gibt mehrere wichtige Unterschiede zwischen dem WLM-Advisor und anderen Advisor-Funktionen 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 Manager-Berichts. Deshalb wird die gleichzeitige Ausführung der Advisor-Funktionen WLM und Metric Server nicht unterstützt.
Diese Funktion ist für alle Komponenten von Network Dispatcher verfügbar.
Metric Server gibt Network Dispatcher Informationen zur Serverauslastung. Diese Informationen werden in Form systemspezifischer Messwerte für den Serverzustand bereitgestellt. Der Manager von Network Dispatcher richtet Anfragen an den Agenten Metric Server, der sich auf jedem der Server befindet, und legt anhand der Messwerte, die er von den Agenten erhalten hat, Wertigkeiten für den Lastausgleich fest. Die Ergebnisse werden auch in den Manager-Bericht gestellt.
Ein Konfigurationsbeispiel ist in Abbildung 11 dargestellt.
Wie die Advisor-Funktion WLM 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 Manager-Berichts. Deshalb wird die gleichzeitige Ausführung der Advisor-Funktionen WLM und Metric Server nicht unterstützt.
Der Agent Metric Server muss auf Servern installiert und ausgeführt werden, für die Network Dispatcher einen Lastausgleich durchführt.
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 Network Dispatcher 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.
Systemmesswert 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 Systemmesswerte erstellen. Das Script enthält einen Befehl, der einen numerischen Wert im Bereich von 0-100 zurückgeben sollte. Dieser numerische Wert sollte eine Lastmessung und keinen Verfügbarkeitswert darstellen.
Einschränkung: Wenn der Name Ihres Scripts für Systemmesswerte unter Windows 2000 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 Script-Dateien für Messwerte schreiben, in denen definiert ist, welchen Befehl Metric Server auf den Servermaschinen absetzen soll. Vergewissern Sie sich, dass alle angepassten Scripts ausführbar sind und sich im Verzeichnis ...nd/ms/script 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 Anweisungen "if" die folgende Zeile zur Datei "metricserver" hinzu: hostname andere_Adresse.
Unter Windows 2000 müssen Sie außerdem in Microsoft Stack den Aliasnamen für andere_Adresse angeben. Informationen zum Angeben eines Aliasnamens für eine Adresse in Microsoft Stack finden Sie auf Seite ***.
Wenn Sie einen Server in der Network-Dispatcher-Konfiguration angeben, können Sie die Last ausgehend vom Status des gesamten Servers (mit dem Agenten Metric Server) und/oder vom Status einer Port-spezifischen Anwendung (mit der Advisor-Funktion) verteilen.
Bei Anwendung der Serverpartitionierung können Sie darüber hinaus zwischen URLs und ihren spezifischen Anwendungen unterscheiden. Ein Webserver kann beispielsweise JSPs und HTML-Seiten bereitstellen, Datenbankabfragen bedienen usw. Network Dispatcher bietet jetzt die Möglichkeit, einen Cluster- und Port-spezifischen Server in mehrere logische Server zu partitionieren. Dadurch können Sie einen bestimmten Dienst auf der Maschine anweisen festzustellen, ob eine Servlet-Steuerkomponente oder eine Datenbankabfrage schneller oder gar nicht ausgeführt wird.
Mit der Serverpartitionierung kann Network Dispatcher z. B. erkennen, dass der HTML-Dienst Seiten schnell bereitstellt, die Datenbankverbindung jedoch nicht mehr aktiv ist. Dadurch können Sie die Last mit größerer Detaillierung und dienstspezifisch verteilen und müssen sich nicht auf die Wertigkeit des Gesamtservers verlassen.
Innerhalb der Network-Dispatcher-Konfiguration können Sie einen physischen oder logischen Server mit der Hierarchie Cluster:Port:Server darstellen. Der Server kann eine eindeutige IP-Adresse der Maschine (physischer Server) sein, die als symbolischer Name oder in Schreibweise mit Trennzeichen angegeben wird. Wenn Sie den Server als partitionierten Server konfigurieren, müssen Sie den Befehl ndcontrol server add mit einer auflösbaren Serveradresse des physischen Servers für den Parameter address angeben. Weitere Informationen hierzu finden Sie im Abschnitt ndcontrol server -- Server konfigurieren.
Nachfolgend sehen Sie ein Beispiel für die Partitionierung physischer Server in logische Server zur Bearbeitung von Anforderungen verschiedenen Typs.
Cluster: 1.1.1.1 Port: 80 Server: A (IP address 1.1.1.2) html server Server: B (IP address 1.1.1.2) gif server Server: C (IP address 1.1.1.3) html server Server: D (IP address 1.1.1.3) jsp server Server: E (IP address 1.1.1.4) gif server Server: F (IP address 1.1.1.4) jsp server Rule1: \*.htm Server: A Server: C Rule2: \*.jsp Server: D Server: F Rule3: \*.gif Server: B Server: E
In diesem Beispiel wird der Server 1.1.1.2 in zwei logische Server partitioniert, A (zur Bearbeitung von HTML-Anforderungen) und B (zur Bearbeitung von GIF-Anforderungen). Server 1.1.1.3 wird in zwei logische Server partitioniert, C (zur Bearbeitung von HTML-Anforderungen) und D (zur Bearbeitung von JSP-Anforderungen). Server 1.1.1.4 wird in zwei logische Server partitioniert, E (zur Bearbeitung von GIF-Anforderungen) und F (zur Bearbeitung von JSP-Anforderungen).
Die URL-Option der HTTP-Advisor-Funktion ist für die Komponenten Dispatcher und CBR verfügbar.
Nach dem Starten einer HTTP-Advisor-Funktion 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 die HTTP-Advisor-Funktion 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 - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Für jeden unter dem HTTP-Port definierten logischen Server können Sie eine für den Dienst, den Sie vom Server anfordern möchten, eine eindeutige Client-HTTP-URL-Zeichenfolge angeben. Die HTTP-Advisor-Funktion verwendet die Zeichenfolge advisorrequest, um den Status der Server abzufragen. Der Standardwert ist HEAD / HTTP/1.0. Die Zeichenfolge advisorresponse ist die Antwort der Advisor-Funktion, nach der die HTTP-Advisor-Funktion die HTTP-Antwort durchsucht. Die HTTP-Advisor-Funktion 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/2.0" server set Cluster:Port:Server advisorresponse "HTTP 200 OK"
ndcontrol server set Cluster:Port:Server advisorrequest "\"head / http/2.0\"" ndcontrol server set Cluster:Port:Server advisorresponse "\"HTTP 200 OK\""
Network Dispatcher kann sich auf derselben Maschine befinden wie ein Server, für dessen Anforderungen er einen Lastausgleich durchführt. Dies wird als das Verknüpfen eines Servers bezeichnet. Die Verknüpfung gilt für die Komponenten Dispatcher, Site Selector, Mailbox Locator und Cisco Consultant. Für CBR wird die Verknüpfung auch unterstützt. Dies gilt jedoch nur bei Verwendung bindungsspezifischer Webserver und Caching-Proxy-Server.
Red Hat Linux Version 7.1 (Linux-Kernel-Version 2.4.2-2) oder SuSE Linux Version 7.1 (Linux-Kernel-Version 2.4.0 - 4 GB): Wenn Sie bei Ausführung der Dispatcher-Komponente mit der Weiterleitungsmethode "mac" sowohl die Verknüpfung als auch die hohe Verfügbarkeit konfigurieren möchten, müssen Sie einen Patch-Code für den Linux-Kernel installieren. Weitere Informationen zum Installieren des Patch-Codes finden Sie im Abschnitt Patch-Code für Linux-Kernel (zum Unterdrücken von ARP-Antworten an der Loopback-Schnittstelle) installieren. Wenn Sie diese Anweisungen ausführen, übergehen Sie den Schritt zum Angeben des Aliasnamens für den Loopback-Adapter. Fügen Sie die Anweisung "ifconfig" zur Script-Datei für hohe Verfügbarkeit (goStandby) hinzu, um einen Aliasnamen für den Loopback-Adapter anzugeben. Die genannte Script-Datei wird ausgeführt, wenn ein Dispatcher in den Bereitschaftsstatus wechselt.
Solaris: Sie können keine WAND-Advisor-Funktionen konfigurieren, wenn der Eingangspunkt-Dispatcher verknüpft ist. Weitere Informationen hierzu finden Sie im Abschnitt Ferne Advisor mit der Weitverkehrsunterstützung verwenden.
In früheren Releases mussten die Adresse des verknüpften Servers und die NFA (Non-Forwarding Address) in der Konfiguration übereinstimmen. Diese Einschränkung wurde aufgehoben.
Für das Konfigurieren eines verknüpften Servers bietet der Befehl ndcontrol server eine Option mit dem Namen collocated an, die auf yes oder no gesetzt werden kann. Die Standardeinstellung ist "no". Die Adresse des Servers muss eine gültige IP-Adresse einer Netzschnittstellenkarte in der Maschine sein.
Einen verknüpften Server können Sie auf eine der folgenden Arten konfigurieren:
Weitere Informationen über die Syntax für den Befehl ndcontrol server enthält ndcontrol server -- Server konfigurieren.
CBR unterstützt die Verknüpfung auf allen Plattformen, ohne zusätzliche Konfigurationsschritte zu erfordern. Die verwendeten Webserver und der verwendete Caching Proxy müssen jedoch bindungsspezifisch sein.
Mailbox Locator unterstützt die Verknüpfung auf allen Plattformen. Der Server muss allerdings an eine andere Adresse als Network Dispatcher gebunden werden. Wenn Sie einen POP3- oder IMAP-Server auf derselben Maschine verknüpfen möchten, muss dieser an eine IP-Adresse gebunden werden, die sich von der Cluster-Adresse unterscheidet. Dies können Sie durch Verwendung der Loopback-Adresse erreichen.
Site Selector unterstützt die Verknüpfung auf allen Plattformen, ohne zusätzliche Konfigurationsschritte zu erfordern.
Cisco Consultant unterstützt die Verknüpfung auf allen Plattformen, ohne zusätzliche Konfigurationsschritte zu erfordern.
Diese Funktion ist nur für die Dispatcher-Komponente verfügbar.
Wenn Sie die WAN-Unterstützung und die Weiterleitungsmethode "nat" von Dispatcher nicht verwenden, erfordert die Dispatcher-Konfiguration, dass die Dispatcher-Maschine und die zugehörigen Server demselben LAN-Segment zugeordnet sind (siehe Abbildung 22). Das Paket eines Clients wird auf der ND-Maschine empfangen und an den Server gesendet und dann wieder von dem Server direkt an den Client gesendet.
Abbildung 22. Beispiel einer Konfiguration mit einem LAN-Segment
Durch die WAN-Erweiterung von Dispatcher werden Server an anderen Standorten, die als ferne Server bezeichnet werden, unterstützt (siehe Abbildung 23). Wenn GRE am fernen Standort nicht unterstützt wird und Sie nicht die Dispatcher-Weiterleitungsmethode "nat" verwenden, muss der ferne Standort aus einer Dispatcher-Maschine (Dispatcher 2) und den lokal angeschlossenen Servern (ServerG, ServerH und ServerI) bestehen. Alle Dispatcher-Maschinen müssen unter demselben Betriebssystem ausgeführt werden. Das Paket eines Clients kann jetzt vom Internet an eine Dispatcher-Maschine und von dort an eine Dispatcher-Maschine an einem anderen geografischen Standort sowie an einen der dort lokal angeschlossenen Server gesendet werden.
Abbildung 23. Beispiel einer Konfiguration mit lokalen und fernen Servern
Damit kann eine Cluster-Adresse weltweit alle Client-Anforderungen unterstützen und die Last auf Server auf der ganzen Welt verteilen.
An der Dispatcher-Maschine, die das Paket anfänglich empfängt, können weiterhin lokale Server angeschlossen sein, und die Dispatcher-Maschine kann die Last auf ihre lokalen Server und auf die fernen Server verteilen.
Weitverkehrsbefehle sind nicht komplex. Führen Sie folgende Schritte aus, um die Weitverkehrsunterstützung zu konfigurieren:
ndcontrol server add Cluster:Port:Server router Adresse
Weitere Informationen zum Schlüsselwort "router" finden Sie im Abschnitt ndcontrol server -- Server konfigurieren.
Auf Eingangspunkt-Dispatchern der meisten Plattformen funktionieren die Advisor-Funktionen ohne spezielle Konfiguration.
Linux: Es gibt eine Einschränkung für die Verwendung von fernen Advisor-Funktionen in Konfigurationen mit WAN-Unterstützung. Protokollspezifische Advisor-Funktionen wie die HTTP-Advisor-Funktion, die auf der Eingangspunkt-Dispatcher-Maschine ausgeführt werden, können den Status der Servermaschinen am fernen Standort nicht richtig bewerten. Sie können dieses Problem minimieren, indem Sie einen der folgenden Schritte ausführen:
Beide genannten Optionen ermöglichen der Advisor-Funktion auf der Eingangspunkt-Dispatcher-Maschine, den Status der fernen Dispatcher-Maschine zu bewerten.
Solaris: Auf Eingangspunkt-Dispatcher-Maschinen müssen Sie (anstelle von "ifconfig" oder Cluster-Konfigurationsmethoden) die Konfigurationsmethode "arp" verwenden. Beispiel:
arp -s <meine_Cluster-Adresse> <meine_MAC-Adresse> pub
Auf fernen Dispatchern müssen Sie für jede ferne Cluster-Adresse die folgenden Konfigurationsschritte ausführen. Für eine Konfiguration mit hoher Verfügbarkeit am fernen Network-Dispatcher-Standort müssen Sie diese Schritte auf beiden Maschinen ausführen.
AIX
ifconfig lo0 alias 9.67.34.123 netmask 255.255.255.255
Linux
ifconfig lo:1 9.67.34.123 netmask 255.255.255.255 up
Solaris
Windows 2000
ndconfig en0 alias 9.55.30.45 netmask 255.255.240.0
arp -a
arp -d 9.67.34.123
und suchen Sie nach der Adresse Ihrer Maschine.
route add 9.67.34.123 mask 255.255.255.255 9.55.30.45
Abbildung 24. WAN-Beispielkonfiguration mit fernen Network-Dispatcher-Maschinen
Dieses Beispiel bezieht sich auf die in Abbildung 24 gezeigte Konfiguration.
Nachfolgend wird beschrieben, wie die Dispatcher-Maschinen für die Unterstützung der Cluster-Adresse xebec am Port 80 konfiguriert werden. ND1 ist als "Eingangspunkt" definiert. Es wird eine Ethernet-Verbindung vorausgesetzt. Für ND1 sind fünf Server definiert, drei lokale (ServerA, ServerB, ServerC) und zwei ferne (ND2 und ND3). Für die fernen Dispatcher ND2 und ND3 sind jeweils drei lokale Server definiert.
An der Konsole des ersten Dispatchers (ND1) folgende Schritte ausführen:
ndcontrol executor start
ndcontrol executor set nfa ND1
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND1. konfigurieren Sie außerdem xebec als Cluster-Adresse.
ndcontrol cluster configure xebec
An der Konsole des zweiten Dispatchers (ND2) folgende Schritte ausführen:
ndcontrol executor start
ndcontrol executor set nfa ND2
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND2
An der Konsole des dritten Dispatchers (ND3) folgende Schritte ausführen:
ndcontrol executor start
ndcontrol executor set nfa ND3
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND3
Generic Routing Encapsulation (GRE) ist ein Internet-Protokoll, das in RFC 1701 und RFC 1702 spezifiziert ist. Bei Verwendung von GRE kann Network Dispatcher Client-IP-Pakete in IP/GRE-Pakete integrieren und an Serverplattformen mit GRE-Unterstützung wie OS/390 weiterleiten. Mit der GRE-Unterstützung kann die Dispatcher-Komponente die Arbeitslast von Paketen auf mehrere Serveradressen verteilen, die einer MAC-Adresse zugeordnet sind.
Network Dispatcher implementiert GRE als Teil der WAND-Funktion (Wide Area Network Dispatcher). Auf diese Weise stellt Network Dispatcher WAN-Lastausgleich direkt für alle Serversysteme zur Verfügung, die GRE-Pakete entpacken können. Network Dispatcher muss nicht auf einem fernen System installiert sein, wenn die fernen Server eingebundene GRE-Pakete unterstützen. Network Dispatcher integriert WAND-Pakete, deren GRE-Feld auf den Dezimalwert 3735928559 gesetzt ist.
Abbildung 25. WAN-Beispielkonfiguration mit einer Serverplattform, die GRE unterstützt
Wenn Sie für dieses Beispiel (Abbildung 25) einen fernen ServerD mit GRE-Unterstützung hinzufügen möchten, müssen Sie ihn in Ihrer Network-Dispatcher-Konfiguration definieren, wie Sie einen WAND-Server in der Hierarchie Cluster:Port:Server definieren würden:
ndcontrol server add Cluster:Port:ServerD router Router1
Die Advisor-Funktion "self" ist für die Dispatcher-Komponente verfügbar.
Wenn Network Dispatcher in einer Client/Server-WAND-Konfiguration (Wide Area Network Dispatcher) installiert ist, stellt der Dispatcher eine self-Advisor-Funktion bereit, die Informationen zum Auslastungsstatus von Back-End-Servern sammelt.
Abbildung 26. Beispiel für eine Client/Server-WAND-Konfiguration mit Advisor-Funktion "self"
In diesem Beispiel befinden sich die Advisor-Funktion "self" und Metric Server auf den beiden Dispatcher-Maschinen, deren Lastausgleich vom übergeordneten Network Dispatcher durchgeführt wird. Die Advisor-Funktion "self" misst insbesondere die Verbindungen pro Sekunde für die Back-End-Server des Dispatchers auf Executor-Ebene.
Der Selbst-Advisor schreibt die Ergebnisse in die Datei ndloadstat. Network Dispatcher stellt außerdem den externen Messwert "ndload" bereit. Bei Ausführung der Konfiguration des Agenten Metric Server auf den Dispatcher-Maschinen wird der externe Messwert "ndload" aufgerufen. Das ndload-Script extrahiert eine Zeichenfolge aus der Datei "ndloadstat" 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 Network Dispatcher zurück, damit dieser bestimmen kann, welcher Dispatcher Client-Anforderungen weiterleiten soll.
Die Ausführbare Datei "ndload" befindet sich im Network-Dispatcher-Verzeichnis .../nd/ms/script.
Die Funktion der hohen Verfügbarkeit ist nur für die Dispatcher-Komponente verfügbar.
Um die Verfügbarkeit des Dispatchers zu verbessern, benutzt die Dispatcher-Funktion für hohe Verfügbarkeit die folgenden Mechanismen:
Nach Möglichkeit sollte mindestens eines der Paare die Überwachungssignale über ein anderes als das für den regulären Cluster-Datenverkehr vorgesehene Teilnetz austauschen. Durch Abgrenzung des durch die Überwachungssignale verursachten Datenverkehrs können in Spitzenbelastungszeiten Fehler bei der Übernahme vermieden werden. Außerdem kann so die Zeit verkürzt werden, die nach einer Überbrückung für eine vollständige Wiederherstellung benötigt wird.
Die vollständige Syntax des Befehls ndcontrol highavailability steht in ndcontrol highavailability -- Hohe Verfügbarkeit steuern.
In Dispatcher-Maschine konfigurieren sind die meisten der nachfolgend aufgeführten Taskst genauer beschrieben.
Nur für Windows 2000: Konfigurieren Sie zusätzlich jede NFA (nicht für Weiterleitung bestimmte Adresse) mit dem Befehl ndconfig. Beispiel:
ndconfig en0 NFA netmask Netzmaske
ndcontrol cluster set ClusterA primaryhost NFAdispatcher1 ndcontrol cluster set ClusterB primaryhost NFAdispatcher2
ndcontrol cluster set ClusterB primaryhost NFAdispatcher2 ndcontrol cluster set ClusterA primaryhost NFAdispatcher1
ndcontrol highavailability heartbeat add Quellenadresse Zieladresse
Primäre Maschine - highavailability heartbeat add 9.67.111.3 9.67.186.8 Partnermaschine - highavailability heartbeat add 9.67.186.8 9.67.111.3Für mindestens ein Überwachungssignale austauschendes Paar müssen die NFAs als Quellen- und Zieladresse definiert sein.
Nach Möglichkeit sollte mindestens eines der Paare die Überwachungssignale über ein anderes als das für den regulären Cluster-Datenverkehr vorgesehene Teilnetz austauschen. Durch Abgrenzung des durch die Überwachungssignale verursachten Datenverkehrs können in Spitzenbelastungszeiten Fehler bei der Übernahme vermieden werden. Außerdem kann so die Zeit verkürzt werden, die nach einer Überbrückung für eine vollständige Wiederherstellung benötigt wird.
ndcontrol highavailability reach add 9.67.125.18Erreichbarkeitsziele werden empfohlen, sind aber nicht erforderlich. Fehlererkennung mit Hilfe von Überwachungssignal und Erreichbarkeitsziel enthält weitere Informationen.
ndcontrol highavailability backup add primary [auto | manual] Port
ndcontrol highavailability backup add backup [auto | manual] Port
ndcontrol highavailability backup add both [auto | manual] Port
ndcontrol highavailability statusDie Maschinen sollten jeweils die korrekte Rolle (Partnermaschine und/oder primäre Maschine), die korrekten Status und die korrekten untergeordneten Status aufweisen. Die primäre Maschine sollte aktiv und synchronisiert sein. Die Ausweichmaschine sollte sich im Bereitschaftsmodus befinden und innerhalb kurzer Zeit synchronisiert werden. Der Parameter für die Strategie muss für beide Maschinen auf denselben Wert gesetzt sein.
Anmerkungen:
Neben den Basiskriterien der Fehlererkennung (durch Überwachungssignale erkannter Verlust der Konnektivität zwischen aktivem Dispatcher und Bereitschafts-Dispatcher) gibt es einen weiteren Fehlererkennungsmechanismus, der als Erreichbarkeitskriterien bezeichnet wird. Wenn Sie den Dispatcher konfigurieren, können Sie eine Liste von Hosts angeben, die für jeden der Dispatcher erreichbar sein sollten, damit die Dispatcher fehlerfrei arbeiten können.
Sie müssen mindestens einen Host für jedes Teilnetz auswählen, das die Dispatcher-Maschine verwendet. Die Hosts können Router, IP-Server oder andere Arten von Hosts sein. Die Erreichbarkeit von Hosts wird über Ping-Aufrufe durch den Erreichbarkeits-Advisor abgefragt. Es findet eine Übernahme statt, wenn keine Überwachungssignalnachrichten durchkommen oder wenn die Erreichbarkeitskriterien von dem Dispatcher in Bereitschaft eher erfüllt werden als von dem primären Dispatcher. Damit die Entscheidung anhand aller verfügbaren Informationen getroffen wird, sendet der aktive Dispatcher regelmäßig Informationen über seine Erreichbarkeit an den Dispatcher in Bereitschaft. Der Dispatcher in Bereitschaft vergleicht dann diese Informationen mit seinen eigenen Erreichbarkeitsinformationen und entscheidet, ob eine Übernahme vorgenommen werden soll oder nicht.
Es werden zwei Dispatcher-Maschinen konfiguriert, die primäre Maschine und eine zweite Maschine, die so genannte Partnermaschine. Wird die primäre Maschine gestartet, leitet sie die gesamten Verbindungsdaten so lange an die Partnermaschine weiter, bis die beiden Maschinen synchronisiert sind. Die primäre Maschine wird aktiv, d. h., sie beginnt mit dem Lastausgleich. Die Partnermaschine überwacht in der Zwischenzeit den Status der primären Maschine und befindet sich in Bereitschaft.
Stellt die Partnermaschine an einem beliebigen Punkt fest, dass die primäre Maschine ausgefallen ist, übernimmt sie die Lastausgleichsfunktionen der primären Maschine und wird zur aktiven Maschine. Ist die primäre Maschine wieder betriebsbereit, gehen die Maschinen anhand der vom Benutzer konfigurierten Wiederherstellungsstrategie vor. Es gibt zwei Arten von Strategie:
Der Parameter für die Strategie muss für beide Maschinen auf denselben Wert gesetzt werden.
Bei der Strategie der manuellen Wiederherstellung können Sie über den Befehl takeover das Weiterleiten von Paketen durch eine bestimmte Maschine erzwingen. Die manuelle Wiederherstellung ist nützlich, wenn die andere Maschine gewartet wird. Die automatische Wiederherstellung ist für den normalen, nichtüberwachten Betrieb konzipiert.
In einer Konfiguration mit gegenseitiger hoher Verfügbarkeit gibt es keinen Fehler auf Cluster-Basis. Tritt ein Fehler bei einer Maschine auf, übernimmt die andere Maschine die Rolle für beide Cluster, auch wenn der Fehler nur einen Cluster betrifft.
Damit der Dispatcher Pakete weiterleiten kann, müssen auf einer Netzschnittstelleneinheit Aliasnamen für jede Cluster-Adresse erstellt werden.
Da die Dispatcher-Maschinen bei einem erkannten Fehler ihren Status tauschen, müssen die oben angegebenen Befehle automatisch abgesetzt werden. Dazu führt der Dispatcher vom Benutzer erstellte Scripts aus. Beispiel-Scripts finden Sie im Verzeichnis ...nd/servers/samples. Zum Ausführen müssen Sie diese in das Verzeichnis ...nd/servers/bin verschieben.
Sie können die folgenden Beispiel-Scripts verwenden:
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
In den Scripts goStandby und GoInOp muss der Aliasname entfernt werden. Beispiel:
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
Wenn die Maschine mehrere NICs enthält, überprüfen Sie zunächst, welche Schnittstelle verwendet werden sollte. Setzen Sie dazu an der Eingabeaufforderung den Befehl netsh interface ip show address ab. Dieser Befehl gibt eine Liste der zur Zeit konfigurierten Schnittstellen zurück und versieht die Angabe "Local Area Connection" mit einer Nummer (z. B. "Local Area Connection 2"), so dass Sie bestimmen, welche Schnittstelle Sie verwenden sollten.
Mit einem auf Regeln basierenden Lastausgleich kann genau abgestimmt werden, wann und warum Pakete an welche Server gesendet werden. Network Dispatcher überprüft alle hinzugefügten Regeln von der ersten Priorität bis zur letzten Priorität, stoppt bei der ersten Regel, die wahr ist, und führt dann den Lastausgleich zwischen allen Servern aus, die mit der Regel verbunden sind. Die Last wird bereits ausgehend von Ziel und Port ausgeglichen, jedoch unter Verwendung von Regeln, die erweiterte Möglichkeiten für die Verteilung von Verbindungen bieten.
In den meisten Fällen sollten Sie beim Konfigurieren von Regeln eine immer gültige Standardregel konfigurieren, um auch Anforderungen zu registrieren, die von den anderen Regeln höherer Priorität nicht erfasst werden. Dies könnte beispielsweise die Antwort "Die Site ist derzeit leider nicht verfügbar, versuchen Sie es später erneut" sein, wenn alle anderen Server nicht für die Client-Anforderung verwendet werden können.
Sie sollten den regelbasierten Lastausgleich für Dispatcher und Site Selector verwenden, wenn Sie aus bestimmten Gründen nur einen Teil Ihrer Server nutzen möchten. Für die CBR-Komponente müssen Sie in jedem Fall Regeln verwenden.
Es sind folgende Arten von Regeln verfügbar:
Es wird empfohlen, einen Plan der Logik zu erstellen, die von den Regeln befolgt werden soll, bevor der Konfiguration Regeln hinzugefügt werden.
Jede Regel hat einen Namen, einen Typ und eine Priorität und kann neben einer Servergruppe auch einen Anfangs- und Endbereich haben. Dem Regeltyp "content" für die CBR-Komponente ist ein reguläter Ausdruck (pattern) für den Abgleich zugeordnet. (Beispiele und Szenarien für die Verwendung der content-Regel sowie eine gültige pattern-Syntax für die content-Regel finden Sie in Anhang C, Syntax der content-Regel.)
Regeln werden in der Reihenfolge ihrer Priorität ausgewertet. Eine Regel mit der Priorität 1 (kleinere Nummer) wird vor einer Regel mit der Priorität 2 (größere Nummer) ausgewertet. Die erste Regel, die erfüllt ist, wird verwendet. Sobald eine Regel erfüllt ist, werden keine weiteren Regeln ausgewertet.
Eine Regel ist erfüllt, wenn die beiden folgenden Bedingungen zutreffen:
Sind einer Regel keine Server zugeordnet, muss für die Regel nur die erste Bedingung zutreffen, um erfüllt zu sein. In diesem Fall löscht der Dispatcher die Verbindungsanforderung. Site Selector gibt die Namensserveranforderung mit einem Fehler zurück und CBR veranlasst Caching Proxy, eine Fehlerseite auszugeben.
Wird keine der Regeln erfüllt, wählt Dispatcher aus allen für den Port verfügbaren Servern einen Server aus. Site Selector wählt aus allen für den Sitenamen verfügbaren Servern einen Server aus, und CBR veranlasst Caching Proxy, eine Fehlerseite auszugeben.
Dieser Regeltyp ist für die Komponenten Dispatcher, CBR und Site Selector verfügbar.
Möglicherweise sollen Regeln auf der Basis der Client-IP-Adresse verwendet werden, wenn Kunden auf der Basis ihrer IP-Adresse berücksichtigt und Ressourcen zugeordnet werden sollen.
Beispielsweise haben Sie festgestellt, dass in Ihrem Netz in großem Umfang ein unbezahlter und deshalb unerwünschter Datenaustausch von Clients mit bestimmten IP-Adressen stattfindet. Sie erstellen eine Regel mit dem Befehl ndcontrol rule. Beispiel:
ndcontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
Diese "ni"-Regel blendet alle Verbindungen für IBM Clients aus. Anschließend fügen Sie die Server zur Regel hinzu, auf die IBM Mitarbeiter Zugriff haben sollen. Werden keine Server zur Regel hinzugefügt, werden Anforderungen von den Adressen 9.x.x.x von keinem Ihrer Server bedient.
Dieser Regeltyp ist für die Komponenten Dispatcher, CBR und Site Selector verfügbar.
Möglicherweise sollen aus Gründen der Kapazitätsplanung Regeln verwendet werden, die auf der Uhrzeit basieren. Ist beispielsweise Ihre Website täglich zu bestimmten Zeiten besonders stark frequentiert, können Sie HTTP während der gesamten Zeit fünf Server zuordnen und dann während der Spitzenzeit weitere fünf Server hinzufügen.
Ein anderer Grund für die Verwendung einer Regel, die auf der Uhrzeit basiert, kann vorliegen, wenn Sie jede Nacht um Mitternacht einige der Server zur Wartung herunterfahren möchten. In diesem Fall würden Sie eine Regel erstellen, mit der die Server während der benötigten Wartungszeit ausgeschlossen werden.
Dieser Regeltyp ist für die Komponenten Dispatcher und CBR verfügbar.
Vielleicht möchten Sie Regen verwenden, die auf den Verbindungen pro Sekunde an einem Port basieren, wenn einige Ihrer Server auch von anderen Anwendungen benutzt werden sollen. Sie können beispielsweise zwei Regeln erstellen:
Möglicherweise verwenden Sie Telnet und möchten Sie zwei Ihrer fünf Server für Telnet reservieren, es sei denn, die Verbindungen pro Sekunde überschreiten eine bestimmte Stufe. In diesem Fall würde der Dispatcher zu Spitzenzeiten die Last auf alle fünf Server verteilen.
Dieser Regeltyp ist für die Komponenten Dispatcher und CBR verfügbar.
Wenn Ihre Server überlastet sind und beginnen, Pakete zu verwerfen, möchten Sie vielleicht Regeln anwenden, die auf der Gesamtanzahl der an einem Port aktiven Verbindungen basieren. Von bestimmten Webservern werden weiterhin Verbindungen akzeptiert, auch wenn sie nicht über genügend Threads verfügen, um auf die Anforderung zu antworten. Von dem Client wird daraufhin eine Zeitlimitüberschreitung angefordert, und der Kunde, der Ihre Website aufruft, erhält keinen Service. Sie können Regeln verwenden, die auf den aktiven Verbindungen basieren, um die Kapazität innerhalb eines Pools mit Servern auszugleichen.
Sie wissen beispielsweise aus Erfahrung, dass Ihre Server den Service einstellen, nachdem sie 250 Verbindungen akzeptiert haben. Sie können eine Regel mit dem Befehl ndcontrol rule oder mit dem Befehl cbrcontrol rule erstellen. Beispiel:
ndcontrol rule add 130.40.52.153:80:pool2 type aktiv beginrange 250 endrange 500 oder cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
Sie würden dann der Regel Ihre aktuellen Server plus einige zusätzliche Server hinzufügen, die andernfalls für eine andere Verarbeitung verwendet werden.
Dieser Regeltyp ist nur in der Dispatcher-Komponente verfügbar.
Wenn Ihre Clients eine Software verwenden, die für Anforderungen von TCP/IP einen bestimmten Port anfordert, möchten Sie vielleicht Regeln auf der Basis des Client-Ports verwenden.
Sie könnten beispielsweise eine Regel erstellen, die angibt, dass für alle Anforderungen mit einem Client-Port von 10002 eine Gruppe besonders schneller Server bereitgestellt wird, da bekannt ist, dass alle Client-Anforderungen mit diesem Port von einer besonders wichtigen Kundengruppe stammen.
Dieser Regeltyp ist nur in der Dispatcher-Komponente verfügbar.
Möglicherweise sollen Regeln verwendet werden, die auf dem Inhalt des Felds "Type of Service" (TOS) im IP-Header basieren. Wird beispielsweise eine Client-Anforderung mit einem TOS-Wert empfangen, der einen normalen Service angibt, kann die Anforderung an eine Servergruppe weitergeleitet werden. Wird eine andere Client-Anforderung mit einem anderen TOS-Wert empfangen, der einen Service mit höherer Priorität angibt, kann die Anforderung an eine andere Servergruppe weitergeleitet werden.
Die TOS-Regel ermöglicht die vollständige Konfiguration jedes Bits im TOS-Byte unter Verwendung des Befehls ndcontrol rule. Für signifikante Bits, die im TOS-Byte abgeglichen werden sollen, verwenden Sie 0 oder 1. Andernfalls wird der Wert x verwendet. Das folgende Beispiel zeigt das Hinzufügen einer TOS-Regel:
ndcontrol rule add 9.67.131.153:80:tsr type Service tos 0xx1010x
Regeln für Kapazitätsauslastung und Bandbreite sind nur für die Dispatcher-Komponente verfügbar.
Bei Verwendung der Kapazitätsauslastungsfunktion misst der Dispatcher die Menge an Daten, die von jedem seiner Server übertragen wird. Dispatcher protokolliert die Kapazität auf Server-, Regel-, Port-, Cluster- und Executor-Ebene. Für jede dieser Ebenen existiert ein neuer Byte-Zählerwert: übertragene Kilobytes pro Sekunde. Der Wert (übertragene Kilobytes pro Sekunde) wird über ein Intervall von 60 Sekunden ermittelt. Sie können diese Kapazitätswerte in der grafischen Benutzerschnittstelle (GUI) oder in der Ausgabe eines Befehlszeilenberichts anzeigen.
Dispatcher gibt Ihnen die Möglichkeit, mit der Regel Reservierte Bandbreite Gruppen von Servern in Ihrer Konfiguration eine angegebene Bandbreite zuzuordnen. Überschreitet der Datenverkehr die Schwelle der reservierten Bandbreite können Sie wie folgt vorgehen:
Wenn Sie wie oben beschrieben die Regel "Gemeinsam genutzte Bandbreite" zusammen mit der Regel "Reservierte Bandbreite" anwenden, können Sie für bevorzugte Clients einen besseren Serverzugang gewährleisten und so den Durchsatz für Transaktionen dieser Clients optimieren. Beispiel: Durch Anwendung der Regel "Gemeinsame Bandbreite" zur Verwendung ungenutzter Bandbreite können Sie denjenigen Kunden, die Onlinehandel auf Server-Clustern betreiben, einen höheren Serverzugriff ermöglichen als den Kunden, die die Server-Cluster zur Investitionssuche verwenden.
Beachten Sie folgende Überlegungen, um festzustellen, inwieweit Ihnen die Regeln zur Verwendung der Bandbreite Unterstützung bieten können beim Verwalten des Antwortdatenverkehrs, der von den Servern an die Clients fließt:
Dieser Regeltyp ist nur in der Dispatcher-Komponente verfügbar.
Mit der Regel "Reservierte Bandbreite" können Sie einen Lastausgleich auf der Basis der von einer Servergruppe gelieferten Datenmenge in Kilobytes pro Sekunde durchführen. Durch Festlegen eines Schwellenwertes (Zuordnen eines bestimmten Bandbreitenbereichs) für jede Gruppe von Servern in der Konfiguration können Sie die von jeder Cluster-Port-Kombination genutzte Bandbreite steuern und gewährleisten. Nachfolgend sehen Sie ein Beispiel für das Hinzufügen einer reservedbandwidth-Regel:
ndcontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
Der Anfangs- und Endbereich werden in Kilobytes pro Sekunde angegeben.
Dieser Regeltyp ist nur in der Dispatcher-Komponente verfügbar.
Wenn die übertragene Datenmenge die Begrenzung für die Regel "Reservierte Bandbreite" überschreitet, können Sie mit der Regel "Gemeinsam genutzte Bandbreite" nicht genutzte Bandbreite der Site verfügbar machen. Sie können diese Regel so definieren, dass die Bandbreite auf Cluster-Ebene oder auf Executor-Ebene gemeinsam genutzt wird. Durch gemeinsame Nutzung der Bandbreite auf Cluster-Ebene kann innerhalb desselben Clusters eine maximale Bandbreite über mehrere Ports (Anwendungen/Protokolle) hinweg von einem oder mehreren Ports genutzt werden. Durch gemeinsame Nutzung der Bandbreite auf Executor-Ebene kann innerhalb der gesamten Dispatcher-Konfiguration eine maximale Bandbreite von einem oder mehreren Clustern genutzt werden.
Vor der Konfiguration der Regel "Gemeinsame Bandbreite" müssen Sie die maximale Bandbreite (Kilobytes pro Sekunde) angeben, die auf Executor- oder Cluster-Ebene gemeinsam genutzt werden kann, indem Sie den Befehl ndcontrol executor oder ndcontrol cluster mit der Option "sharedbandwidth" verwenden.Nachfolgend sind Beispiele für die Befehlssyntax aufgeführt:
ndcontrol executor set sharedbandwidth Größe ndcontrol cluster [add | set] 9.12.32.9 sharedbandwidth Größe
Größe ist für "sharedbandwidth" ein ganzzahliger Wert (in Kilobytes pro Sekunde). Der Standardwert ist Null. Ist der Wert gleich Null, kann die Bandbreite nicht gemeinsam benutzt werden. Das Maximum, das Sie für "sharedbandwidth" angeben, darf nicht größer als der Wert für die gesamte verfügbare Bandbreite (gesamte Serverkapazität) sein.
Nachfolgend einige Beispiele für das Hinzufügen oder Definieren einer sharedbandwidth-Regel:
ndcontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel Wertndcontrol rule set 9.20.34.11:80:shrule sharelevel Wert
Der Wert für "sharelevel" ist "executor" oder "cluster". Der Parameter "sharelevel" ist für die Regel "sharebandwidth" erforderlich.
Dieser Regeltyp ist nur in der Komponente Site Selector verfügbar.
Für die Regel "Messwert für alle" wählen Sie einen Systemmesswert (cpuload, memload oder ein eigenes angepasstes Script für Systemmesswerte) aus. Site Selector vergleicht den Systemmesswert (der vom Agenten Metric Server auf jedem Server mit Lastausgleich zurückgegeben wird) mit dem von Ihnen für die Regel festgelegten Anfangs- und Endbereich. Die Regel ist erst erfüllt, wenn der aktuelle Messwert für alle Server der Gruppe innerhalb des für die Regel festgelegten Bereichs liegt.
Nachfolgend sehen Sie ein Beispiel für das Hinzufügen einer Regel "Messwert für alle" zu Ihrer Konfiguration:
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
Dieser Regeltyp ist nur in der Komponente Site Selector verfügbar.
Für die Regel "Durchschnitt der Messwerte" wählen Sie einen Systemmesswert (cpuload, memload oder ein eigenes angepasstes Script für Systemmesswerte) aus. Site Selector vergleicht den Systemmesswert (der vom Agenten Metric Server auf jedem Server mit Lastausgleich zurückgegeben wird) mit dem von Ihnen für die Regel festgelegten Anfangs- und Endbereich. Die Regel ist erst erfüllt, wenn der Durchschnitt der aktuellen Messwerte auf allen Servern der Gruppe innerhalb des für die Regel festgelegten Bereichs liegt.
Nachfolgend sehen Sie ein Beispiel für das Hinzufügen einer Regel "Durchschnitt der Messwerte" zu Ihrer Konfiguration:
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
Dieser Regeltyp ist für die Komponenten Dispatcher, CBR und Site Selector verfügbar.
Es kann eine Regel erstellt werden, die "immer wahr" ist. Eine solche Regel wird immer ausgewählt, es sei denn, alle ihr zugeordneten Server sind inaktiv. Aus diesem Grund sollte sie eine niedrigere Priorität als andere Regeln haben.
Sie können sogar mehrere Regeln haben, die "immer wahr" sind. Jeder Regel kann eine Gruppe mit Servern zugeordnet sein. Die erste wahre Regel mit einem verfügbaren Server wird ausgewählt. Angenommen, Sie haben sechs Server. Zwei dieser Server sollen unter allen Umständen den Datenaustausch steuern, es sei denn, beide Server sind inaktiv. Sind die ersten beiden Server inaktiv, soll eine zweite Gruppe mit Servern den Datenaustausch steuern. Sind alle vier dieser Server inaktiv, sollen die letzten zwei Server den Datenaustausch steuern. Sie könnten drei Regeln erstellen, die "immer wahr" sind. Die erste Gruppe mit Servern wird dann immer ausgewählt, wenn mindestens ein Server aktiv ist. Sind beide inaktiv, wird ein Server aus der zweiten Gruppe ausgewählt, usw.
Als weiteres Beispiel können Sie mit einer Regel, die "immer wahr" ist, sicherstellen, daß eingehende Clients keinen Service erhalten, wenn sie nicht den festgelegten Regeln entsprechen. Mit Hilfe des Befehls ndcontrol rule würden Sie die folgende Regel erstellen:
ndcontrol rule add 130.40.52.153:80:jamais type true priority 100
Wenn Sie anschließend keine Server zur Regel hinzufügen, werden die Client-Pakete ohne Antwort gelöscht.
Sie können mehrere Regeln definieren, die "immer wahr" sind, und dann durch Ändern der Prioritätsebene festlegen, welche Regel ausgeführt werden soll.
Dieser Regeltyp ist für die Komponenten Dispatcher und CBR verfügbar.
Dieser Regeltyp wird verwendet, wenn Anforderungen an Gruppen von Servern gesendet werden sollen, die speziell für die Bearbeitung eines bestimmten Teils des Sitedatenverkehrs konfiguriert wurden. Beispielsweise wollen Sie eine Gruppe von Servern für die Bearbeitung aller cgi-bin-Anforderungen, eine andere Gruppe für die Bearbeitung aller Audiodatenstromanforderungen und eine dritte Gruppe für die Bearbeitung aller anderen Anforderungen verwenden. Sie würden eine Regel mit einem pattern-Wert hinzufügen, der mit dem Pfad zu Ihrem cgi-bin-Verzeichnis übereinstimmt, eine zweite Regel, die mit dem Dateityp Ihrer Audio-Streaming-Dateien übereinstimmt, und eine dritte Regel, die immer wahr ist, um den restlichen Datenverkehr zu bearbeiten. Sie würden dann jeder Regel die entsprechenden Server hinzufügen.
Wichtiger Hinweis: Beispiele und Szenarien für die Verwendung der content-Regel sowie eine gültige pattern-Syntax für die content-Regel finden Sie in Anhang C, Syntax der content-Regel.
Zum Hinzufügen von Regeln können Sie den Befehl ndcontrol rule add verwenden, die Beispielkonfigurationsdatei editieren oder die grafische Benutzerschnittstelle (GUI) benutzen. Sie können für jeden definierten Port eine oder mehrere Regel(n) hinzufügen.
Der Prozess besteht aus zwei Schritten: Hinzufügen der Regel und Definieren der Server, die verwendet werden sollen, wenn die Regel wahr ist. Beispielsweise möchte der Systemadministrator die Auslastung der Proxy-Server durch die einzelnen Unternehmensbereiche verfolgen. Dem Systemadministrator sind die IP-Adressen bekannt, die jedem Unternehmensbereich zugeordnet sind. Der Systemadministrator würde die erste Gruppe mit Regeln auf der Basis der Client-IP-Adressen erstellen, um zwischen den Lasten der einzelnen Unternehmensbereiche unterscheiden zu können.
ndcontrol rule add 130.40.52.153:80:Ber1 type ip b 9.1.0.0 e 9.1.255.255 ndcontrol rule add 130.40.52.153:80:Ber2 type ip b 9.2.0.0 e 9.2.255.255 ndcontrol rule add 130.40.52.153:80:Ber3 type ip b 9.3.0.0 e 9.3.255.255
Anschließend würde der Systemadministrator jeder Regel einen anderen Server hinzufügen und dann die Last auf jedem der Server messen, um dem Unternehmensbereich die verwendeten Services korrekt in Rechnung zu stellen. Beispiel:
ndcontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 ndcontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 ndcontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
Die Option für Serverauswertung ist nur in der Dispatcher-Komponente verfügbar.
Der Befehl ndcontrol rule bietet eine Serverauswertungsoption für Regeln an. Mit der Option evaluate können Sie die Regelbedingungen für alle Server an einem Port oder für die in der Regel angegebenen Server auswerten. (In früheren Versionen von Network Dispatcher konnten nur die Regelbedingungen für alle Server an einem Port erfasst werden.)
Nachfolgend einige Beispiele für das Hinzufügen oder Definieren der Auswertungsoption für eine Regel "Reservierte Bandbreite":
ndcontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate Ebene ndcontrol rule set 9.22.21.3:80:rbweval evaluate Ebene
Die Ebene für die Option "evaluate" kann auf "port" oder "rule" gesetzt werden. Der Standardwert ist "port".
Mit der Option zum Erfassen der Regelbedingungen für die in der Regel definierten Server können Sie zwei Regeln mit den folgenden Kenndaten konfigurieren:
Wenn der Datenverkehr den Schwellenwert für die in der ersten Regel angegebenen Server überschreitet, wird er an den in der zweiten Regel definierten Server ("Site ausgelastet") gesendet. Sinkt die Zahl der Datenübertragungen unter den Schwellenwert, der für die Server in der ersten Regel definiert ist, werden die nachfolgenden Datenübertragungen erneut an die Server in der ersten Regel gesendet.
Wenn Sie bei den für das vorherige Beispiel beschriebenen Regeln den Wert der Option "evaluate" für die erste Regel auf port setzen (damit die Regelbedingungen für alle Server am Port ausgewertet werden) und der Datenverkehr den Schwellenwert für diese Regel überschreitet, wird er an den der zweiten Regel zugeordneten Server ("Site ausgelastet") gesendet.
Die erste Regel misst den Datenverkehr aller Server (einschließlich des Verkehrs für den Server "Site ausgelastet") am Port, um festzustellen, ob der Schwellenwert überschritten wird. Geht die Überlastung der der ersten Regel zugeordneten Server zurück, kann der Datenverkehr entgegen der Absicht weiterhin an den Server "Site ausgelastet" gesendet werden, sofern der Datenverkehr am Port weiterhin den Schwellenwert für die erste Regel überschreitet.
Normalerweise sind die Lastausgleichsfunktionen des Dispatchers unabhängig vom Inhalt der Sites, auf denen das Produkt benutzt wird. In einem bestimmten Bereich kann der Inhalt der Site jedoch von Bedeutung sein und können Entscheidungen über den Inhalt erhebliche Auswirkungen auf die Effektivität des Dispatchers haben. Dies ist der Bereich der Verbindungsadressierung.
Wenn Ihre Seiten Links enthalten, die auf einzelne Server für Ihre Site zeigen, zwingen Sie einen Client, auf eine bestimmte Maschine zuzugreifen und so die sonst wirksame Lastausgleichsfunktion zu umgehen. Aus diesem Grund wird empfohlen, dass Sie in allen auf Ihren Seiten enthaltenen Verbindungen (Links) immer die Adresse des Dispatchers benutzen. Berücksichtigen Sie, dass die Art der benutzten Adressierung nicht immer offensichtlich ist, wenn Ihre Site eine automatisierte Programmierung benutzt, bei der HTML dynamisch erstellt wird. Um den Lastausgleich zu optimieren, sollten Sie auf alle expliziten Adressierungen achten und sie, falls möglich, vermeiden.
Sie können den Dispatcher und die TCP-Servermaschinen für ein privates Netz konfigurieren. Durch diese Konfiguration können Konkurrenzsituationen auf dem öffentlichen oder externen Netz, die sich auf die Leistung auswirken, verringert werden.
Unter AIX hat diese Konfiguration auch den Vorteil, dass der schnelle SP High Performance Switch genutzt werden kann, wenn der Dispatcher und die TCP-Servermaschinen auf Knoten in einem SP Frame ausgeführt werden.
Um ein privates Netz zu erstellen, muss jede Maschine über mindestens zwei LAN-Karten verfügen, wobei eine der Karten mit dem privaten Netz verbunden wird. Zudem muss die zweite LAN-Karte auf einem anderen Teilnetz konfiguriert werden, damit die Dispatcher-Maschine die Client-Anforderungen über das private Netz an die TCP-Servermaschinen sendet.
Windows 2000: Führen Sie den folgenden Befehl aus:
ndconfig en1 10.0.0.x netmask 255.255.255.0
Hier ist en1 der Name der zweiten Schnittstellenkarte in der Dispatcher-Maschine, 10.0.0.x die Netzadresse der zweiten Schnittstellenkarte und 255.255.255.0 die Netzmaske des privaten Netzes.
Die über den Befehl ndcontrol server add hinzugefügten Server müssen mit den Adressen des privaten Netzes hinzugefügt werden. Beispielsweise muss bei dem Beispiel für den Server Apple in Abbildung 27 der Befehl wie folgt aussehen:
ndcontrol server add Cluster-Adresse:80:10.0.0.1
Er darf nicht wie folgt aussehen:
ndcontrol server add Cluster-Adresse :80:9.67.131.18
Wenn mit Site Selector Lastinformationen für den Dispatcher bereitstellen, muss Site Selector so konfiguriert werden, dass die Last an den privaten Adressen gemeldet wird.
Abbildung 27. Beispiel für ein privates Netz mit dem Dispatcher
Die Verwendung der Konfiguration für ein privates Netz ist nur in der Dispatcher-Komponente gültig.
Das Wort "Platzhalter" bezieht sich auf die Fähigkeit des Clusters, mehreren IP-Adressen zu entsprechen (d. h. agiert als Platzhalter). Cluster-Adresse 0.0.0.0 wird verwendet, um einen Platzhalter-Cluster anzugeben.
Wenn Sie für viele Cluster-Adressen einen Lastausgleich durchführen müssen und die Port-/Serverkonfigurationen für alle Cluster identisch sind, können Sie die Cluster in einer Sternkonfiguration zusammenfassen.
Sie müssen dennoch jede Cluster-Adresse explizit auf einem der Netzwerkadapter Ihrer Dispatcher-Workstation konfigurieren. Sie sollten jedoch keine der Cluster-Adressen mit dem Befehl ndcontrol cluster add zur Dispatcher-Konfiguration hinzufügen.
Fügen Sie nur den Platzhalter-Cluster (Adresse 0.0.0.0) hinzu und konfigurieren Sie die Ports und Server wie für den Lastausgleich erforderlich. Für den Datenverkehr an jede der auf dem Adapter konfigurierten Adressen erfolgt ein Lastausgleich unter Verwendung der Platzhalter-Cluster-Konfiguration.
Ein Vorteil dieser Methode besteht darin, dass der Datenverkehr an alle Cluster-Adressen bei der Bestimmung des besten Servers berücksichtigt wird. Ist der Datenverkehr bei einem Cluster besonders hoch, und hat der Cluster viele aktive Verbindungen auf einem der Server erstellt, findet für den Datenverkehr an andere Cluster-Adressen ein Lastausgleich unter Verwendung dieser Informationen statt.
Sie können den Platzhalter-Cluster mit tatsächlichen Clustern kombinieren, wenn Sie einige Cluster-Adressen mit eindeutiger Port-/Serverkonfiguration und einige Cluster-Adressen mit gemeinsamer Konfigurationen haben. Die eindeutigen Konfigurationen müssen jeweils einer tatsächlichen Cluster-Adresse zugeordnet werden. Alle gemeinsamen Konfigurationen können dem Platzhalter-Cluster zugeordnet werden.
Die Verwendung eines Platzhalter-Clusters für die Zusammenfassung von Serverkonfigurationen ist nur in der Dispatcher-Komponente gültig.
Die Verwendung eines Platzhalter-Clusters für den Lastausgleich von Firewalls ist nur in der Dispatcher-Komponente gültig. Cluster-Adresse 0.0.0.0 wird verwendet, um einen Platzhalter-Cluster anzugeben.
Der Platzhalter-Cluster kann für den Lastausgleich von Datenverkehr an Adressen verwendet werden, die nicht explizit auf einem Netzwerkadapter der Dispatcher-Workstation konfiguriert sind. Dazu muss der Dispatcher mindestens den gesamten Datenverkehr sehen können, für den ein Lastausgleich erfolgen soll. Die Dispatcher-Workstation erkennt keinen Datenverkehr an Adressen, die nicht explizit auf einem ihrer Netzwerkadapter konfiguriert wurden. Eine Ausnahme hiervon bilden Adressen, die für bestimmten Datenverkehr als Standard-Route konfiguriert sind.
Wurde der Dispatcher als Standard-Route konfiguriert, erfolgt der Lastausgleich für den TCP- oder UDP-Datenverkehr, der über die Dispatcher-Maschine transportiert wird, unter Verwendung der Platzhalter-Cluster-Konfiguration.
Diese Methode kann für den Lastausgleich von Firewalls verwendet werden. Da Firewalls Pakete für jede Zieladresse und jeden Ziel-Port verarbeiten können, müssen Sie den Lastausgleich für den Datenverkehr unabhängig von der Zieladresse und dem Ziel-Port durchführen können.
Firewalls werden verwendet, um den Datenverkehr von nicht gesicherten Clients zu gesicherten Servern zu steuern und die Antworten von den gesicherten Servern zu bearbeiten sowie den Datenverkehr von Clients auf der gesicherten Seite zu Servern auf der nicht gesicherten Seite zu steuern und die Antworten zu bearbeiten.
Sie müssen zwei Dispatcher-Maschinen konfigurieren, eine für den Lastausgleich des nicht gesicherten Datenverkehrs an die nicht gesicherten Firewall-Adressen und eine für den Lastausgleich des gesicherten Datenverkehrs an die gesicherten Firewall-Adressen. Da beide Dispatcher den Platzhalter-Cluster und den Platzhalter-Port mit verschiedenen Gruppen von Serveradressen verwenden müssen, ist es erforderlich, dass sich die beiden Dispatcher auf zwei separaten Workstations befinden.
Die Verwendung eines Platzhalter-Clusters mit Caching Proxy für transparente Weiterleitung ist nur für die Dispatcher-Komponente möglich. Cluster-Adresse 0.0.0.0 wird verwendet, um einen Platzhalter-Cluster anzugeben.
Bei Verwendung der Platzhalter-Cluster-Funktion kann der Dispatcher eine transparente Weiterleitung für einen Caching-Proxy-Server aktivieren, der sich auf derselben Maschine wie der Dispatcher befindet. Dies ist nur eine AIX-Funktion, da zwischen der Dispatcher-Komponente und der TCP-Komponente des Betriebssystems eine Kommunikation stattfinden muss.
Zum Aktivieren dieses Merkmals müssen Sie Caching Proxy für den Empfang von Client-Anforderungen am Port 80 starten. Anschließend konfigurieren Sie einen Platzhalter-Cluster. Konfigurieren Sie im Platzhalter-Cluster den Port 80. Für Port 80 konfigurieren Sie die NFA der Dispatcher-Maschine als einzigen Server. Der gesamte Client-Datenverkehr an Adressen des Ports 80 wird nun an den Caching-Proxy-Server auf der Dispatcher-Workstation gesendet. Anschließend wird die Client-Anforderung wie üblich weitergeleitet. Die Antwort wird von Caching Proxy an den Client zurückgesendet. In diesem Modus führt die Dispatcher-Komponente keinen Lastausgleich durch.
Der Platzhalter-Port kann für Datenverkehr verwendet werden, der nicht für einen explizit konfigurierten Port bestimmt ist. Eine solche Verwendung wäre der Lastausgleich für Firewalls. Zum anderen kann mit einem Platzhalter-Port sichergestellt werden, dass an einen nicht konfigurierten Port gerichteter Datenverkehr entsprechend bearbeitet wird. Durch Definieren eines Platzhalter-Ports ohne Server stellen Sie sicher, dass alle Anforderungen an einen nicht konfigurierten Port gelöscht und nicht an das Betriebssystem zurückgesendet werden. Ein Platzhalter-Port wird mit der Port-Nummer 0 (null) angegeben. Beispiel:
ndcontrol port add Cluster:0
Wenn Sie den Port eines Clusters als "sticky" konfigurieren, aktivieren Sie die Affinitätsfunktion. Wird der Port eines Clusters als sticky konfiguriert, können nachfolgende Client-Anforderungen an denselben Server übertragen werden. Dies geschieht, indem für die Option "Haltezeit für Port" einige Sekunden angegeben werden. Sie können die Funktion inaktivieren, indem Sie stickytime auf null setzen.
Interaktion mit Port-übergreifender Affinität: Wird die Port-übergreifende Affinität aktiviert, müssen die Werte für "stickytime" der gemeinsam benutzten Ports identisch (und ungleich null) sein. Weitere Informationen befinden sich unter Port-übergreifende Affinität.
Wird bei inaktivierter Funktion eine neue TCP-Verbindung von einem Client empfangen, verwendet der Dispatcher den zu diesem Zeitpunkt richtigen Server und leitet die Pakete an diesen Server weiter. Wird eine weitere Verbindung von demselben Client empfangen, behandelt der Dispatcher diese Verbindung als eine neue Verbindung und wählt wieder den zu diesem Zeitpunkt richtigen Server aus.
Bei Aktivierung der Funktion wird eine nachfolgende Anforderung von demselben Client an denselben Server geleitet.
Nach einer gewissen Zeit hört der Client auf, Transaktionen zu senden, so dass der Affinitätseintrag entfernt wird. Jeder Affinitätseintrag bleibt nur für die für "stickytime" festlegte Zeit in Sekunden erhalten. Werden innerhalb der Haltezeit (stickytime) weitere Verbindungen empfangen, ist der Affinitätseintrag noch gültig, so dass die Anforderung an denselben Server weitergeleitet wird. Wenn eine Verbindung nicht innerhalb der Haltezeit empfangen wird, wird der Eintrag gelöscht. Für eine nach Ablauf der Haltezeit empfangene Verbindung wird ein neuer Server ausgewählt.
Die Verwendung der Server Directed Affinity (SDA) API ist nur in der Dispatcher-Komponente gültig.
Die SDA-Funktion stellt eine API zur Verfügung, die es einem externen Agenten ermöglicht, das Dispatcher-Affinitätsverhalten zu beeinflussen.
SDA-Funktionen
Ihre Anwendung hat möglicherweise angezeigt, dass die Serversysteme in der Lage sind, Client-Anforderungen an bestimmte Servermaschinen zu übertragen, und die Serversysteme dies besser können als der Dispatcher. Sie möchten, dass der Client mit dem Server Ihrer Wahl "kommuniziert" und nicht mit dem Server, der von der Lastausgleichsfunktion des Dispatchers ausgewählt wurde. Die SDA-Funktion stellt diese API zur Verfügung. Sie können jetzt Ihre eigene Software schreiben, um einen SDA-Agenten zu implementieren, der mit einem Empfangsprogramm im Dispatcher kommuniziert. Er kann dann die Dispatcher-Affinitätstabellen bearbeiten, um
Sätze, die von einem SDA-Agenten in eine Affinitätstabelle eingefügt wurden, bleiben für unbegrenzte Zeit in der Tabelle. Sie verlieren nicht ihre Gültigkeit durch Zeitlimitüberschreitung. Sie werden nur entfernt, wenn sie von dem SDA-Agenten gelöscht werden oder wenn ein Dispatcher-Advisor feststellt, dass der Server inaktiv ist.
SDA-Komponenten des Dispatchers
Der Dispatcher implementiert ein neues Socket-Empfangsprogramm, um Anforderungen von einem SDA-Agenten zu akzeptieren und zu bearbeiten. Öffnet ein SDA-Agent eine Verbindung mit dem Dispatcher, akzeptiert das Empfangsprogramm die Verbindung und lässt die Verbindung geöffnet. Mehrere Anforderungen und Antworten können über diese anhaltende Verbindung fließen. Der Socket schließt, wenn er vom SDA-Agenten geschlossen wird oder wenn der Dispatcher einen nicht behebbaren Fehler erkennt. Innerhalb des Dispatchers nimmt das Empfangsprogramm jede Anforderung von dem SDA-Agenten entgegen, kommuniziert mit der entsprechenden Affinitätstabelle in dem Dispatcher-Executor-Kernel und bereitet eine Antwort für den SDA-Agenten vor.
Weitere Informationen hierzu finden Sie in den folgenden Dateien im Installationsverzeichnis von Network Dispatcher:
Die Port-übergreifende Affinität gilt nur für die Dispatcher-Komponente.
Die Port-übergreifende Affinität ist Ausdehnung der Haltefunktion auf mehrere Ports. Wird beispielsweise eine Client-Anforderung zuerst an einem Port und die nächste Anforderung an einem anderen Port empfangen, kann der Dispatcher die Client-Anforderungen bei Port-übergreifender Affinität an denselben Server senden. Für die Verwendung dieser Funktion müssen die Ports folgende Bedingungen erfüllen:
Mehrere Ports können eine Verbindung zu einem crossport herstellen. Wenn vom selben Client weitere Verbindungen an demselben Port oder einem gemeinsam benutzten Port ankommen, wird auf denselben Server zugegriffen. Nachfolgend sehen Sie eine Beispielkonfiguration für mehrere Ports mit einer Port-übergreifenden Affinität für Port 10:
ndcontrol port set Cluster:20 crossport 10 ndcontrol port set Cluster:30 crossport 10 ndcontrol port set Cluster:40 crossport 10
Nachdem Sie die Port-übergreifende Affinität konfiguriert haben, können Sie den Wert für stickytime des Ports flexibel ändern. Sie sollten "stickytime" jedoch für alle gemeinsam benutzten Ports auf denselben Wert setzen, da andernfalls unerwartete Ergebnisse auftreten können.
Wenn Sie die Port-übergreifende Affinität aufheben möchten, setzen Sie den Wert für crossport auf seine eigene Port-Nummer zurück. ndcontrol port -- Ports konfigurieren enthält ausführliche Informationen über die Befehlssyntax für die Option crossport.
Die Affinitätsadressmaske gilt nur für die Dispatcher-Komponente.
Die Affinitätsadressmaske ist eine Erweiterung der Sticky-Funktion, mit der Clients auf der Basis gemeinsamer Teilnetzadressen zusammengefasst werden. Die Angabe von stickymask im Befehl ndcontrol port ermöglicht es Ihnen, die höherwertigen Bits der 32-Bit-IP-Adresse zu maskieren. Wenn diese Funktion aktiviert ist und eine Client-Anforderung zum ersten Mal eine Verbindung zu dem Port herstellt, , werden alle nachfolgenden Anforderungen von Clients mit derselben Teilnetzadresse (repräsentiert vom maskierten Abschnitt der Adresse) an denselben Server übertragen.
Wenn Sie beispielsweise alle eingehenden Client-Anforderungen mit derselben Netzadresse der Klasse A an einen Server übergeben möchten, setzen Sie den stickymask-Wert für den Port auf 8 (Bits). Sollen Client-Anforderungen mit derselben Netzadresse der Klasse B zusammengefasst werden, setzen Sie den Wert für stickymask auf 16 (Bits). Sollen Client-Anforderungen mit derselben Netzadresse der Klasse C zusammengefasst werden, setzen Sie den Wert für stickymask auf 24 (Bits).
Die besten Ergebnisse werden erzielt, wenn Sie den Wert für stickymask beim erstmaligen Starten von Network Dispatcher definieren. Wird der Wert für stickymask dynamisch geändert, können unvorhersehbare Ergebnisse auftreten.
Interaktion mit Port-übergreifender Affinität: Wenn Sie die Port-übergreifende Affinität aktivieren, müssen die Werte für "stickymask" der gemeinsam benutzten Ports identisch sein. Weitere Informationen befinden sich unter Port-übergreifende Affinität.
Um die Affinitätsadressmaske zu aktivieren, geben Sie einen ähnlichen Befehl ndcontrol port wie den folgenden aus:
ndcontrol port set Cluster:Port stickymask 8
Gültige Werte für stickymask sind 8, 16, 24 und 32. Der Wert 8 gibt an, dass die ersten 8 höherwertigen Bits der IP-Adresse (Netzadresse der Klasse A) maskiert werden. Der Wert 16 gibt an, dass die ersten 16 höherwertigen Bits der IP-Adresse (Netzadresse der Klasse B) maskiert werden. Der Wert 24 gibt an, dass die ersten 24 höherwertigen Bits der IP-Adresse (Netzadresse der Klasse C) maskiert werden. Wird der Wert 32 angegeben, wird die gesamte IP-Adresse maskiert, wodurch die Affinitätsadressmaskenfunktion inaktiviert wird. Der Standardwert für stickymask ist 32.
ndcontrol port -- Ports konfigurieren enthält ausführliche Informationen über die Befehlssyntax für stickymask (Affinitätsadressmaskenfunktion).
Mit der Außerkraftsetzung der Regelaffinität können Sie Affinität eines Ports für einen Bestimmten Server außer Kraft setzen. Angenommen, Sie verwenden eine Regel, um die Anzahl der Verbindungen mit jedem Anwendungsserver zu begrenzen, und haben einen Überlaufserver mit einer Regel 'immer wahr', die "Bitte später erneut versuchen" für diese Anwendung angibt. Der Port hat einen stickytime-Wert von 25 Minuten. Sie möchten also nicht, dass der Client an diesen Server gebunden wird. Durch Außerkraftsetzung der Regelaffinität können Sie bewirken, dass der Überlaufserver die diesem Port normalerweise zugehordnete Affinität außer Kraft setzt. Fordert der Client das nächste Mal den Cluster an, erfolgt ein Lastausgleich auf der Basis des besten verfügbaren Anwendungsservers und nicht des Überlaufservers.
ndcontrol server -- Server konfigurieren enthält ausführliche Informationen über die Befehlssyntax beim Überschreiben der Regelaffinität mit der Option sticky im Befehl server.
Die Stilllegung gehaltener Verbindungen gilt für die Komponenten Dispatcher und CBR.
Wenn Sie aus bestimmten Gründen (Aktualisierungen, Upgrades, Wartung usw.) einen Server aus der Network-Dispatcher-Konfiguration entfernen müssen, können Sie den Befehl ndcontrol manager quiesce verwenden. Mit dem Unterbefehl "quiesce" können vorhandene Verbindungen beendet werden (ohne weiter bedient zu werden). Nachfolgende neue Verbindungen vom Client zum stillgelegten Server werden nur weitergeleitet, wenn die Verbindung als gehaltene Verbindung (sticky) bezeichnet ist und die Haltezeit (stickytime) nicht abgelaufen ist. Alle anderen neuen Verbindungen zum Server werden vom Unterbefehl "quiesce" unterbunden.
Verwenden Sie quiesce "now" nur, wenn Sie die Haltezeit definiert haben und vor Ablauf der Haltezeit neue Verbindungen an einen anderen als den stillgelegten Server gesendet werden sollen. Im folgenden Beispiel wird die Option "now" für die Stilllegung des Servers 9.40.25.67 verwendet:
ndcontrol manager quiesce 9.40.25.67 now
Die Option "now" bestimmt wie folgt, was mit gehaltenen Verbindungen geschehen soll:
Auf diese Weise können Server schrittweise stillgelegt werden. Sie können einen Server beispielsweise nach und nach stilllegen und dann auf den Zeitpunkt des geringsten Datenverkehrsaufkommen warten (vielleicht am frühen Morgen), um den Server vollständig aus der Konfiguration zu entfernen.
Mit dem Befehl ndcontrol rule können Sie die folgenden Arten der Affinität angeben:
Der Standardwert für die Option "affinity" ist "none". Die Option stickytime für den Port-Befehl (port) muss auf null gesetzt (inaktiviert) sein, damit die Option affinity des Regelbefehls (rule) auf die aktive oder passive Cookie-Affinität bzw. auf die URI-Affinität gesetzt werden kann. Ist für die Regel eine Affinität definiert, kann keine Haltezeit für den Port aktiviert werden.
Die aktive Cookie-Affinität gilt nur für die Komponente CBR. Die passive Cookie-Affinität und die URI-Affinität gelten für die Komponente CBR sowie für die Weiterleitungsmethode "cbr" der Dispatcher-Komponente.
Die aktive Cookie-Affinität gilt nur für die CBR-Komponente. Sie bietet eine Möglichkeit, Clients an einen bestimmten Server zu "binden". Diese Funktion wird aktiviert, indem der Wert stickytime einer Regel auf eine positive Zahl und die Affinität auf "activecookie" gesetzt wird. Dies kann beim Hinzufügen der Regel oder mit dem Befehl "rule set" geschehen. Ausführliche Informationen zur Befehlssyntax finden Sie im Abschnitt ndcontrol rule -- Regeln konfigurieren.
Wenn eine Regel für aktive Cookie-Affinität aktiviert wurde, wird der Lastausgleich für neue Client-Anforderungen mit Standrad-CBR-Algorithmen durchgeführt. Aufeinanderfolgende Anforderungen eines Clients werden dabei an den zu Beginn ausgewählten Server gesendet. Der ausgewählte Server ist als Cookie in der Antwort an den Client gespeichert. Solange die zukünftigen Anforderungen des Clients das Cookie enthalten und jede Anforderung innerhalb der Haltezeit empfangen wird, bleibt der Client an den anfänglichen Server gebunden.
Mit der aktiven Cookie-Affinität wird sichergestellt, dass die Arbeitslast eines Clients über einen bestimmten Zeitraum hinweg an denselben Server weitergeleitet wird. Dies wird erreicht, indem ein Cookie gesendet wird, das von dem Client-Browser gespeichert wird. Das Cookie enthält die Kombination Cluster:Port, auf deren Grundlage die Entscheidung getroffen wurde, den Server, an den die Arbeitslast weitergeleitet wurde, und eine Zeitmarke für das Zeitlimit, bei dessen Erreichung die Affinität ungültig wird. Bei Erfüllung einer Regel mit gesetzter aktiver Cookie-Affinität wird das vom Client gesendete Cookie überprüft. Wenn ein Cookie mit der Kennung für die Cluster:Port-Kombination gefunden wird, die die Regel erfüllt, werden der Server, an den die Arbeitslast weitergeleitet werden soll, und die Zeitmarke für das Zeitlimit aus dem Cookie extrahiert. Wenn der Server noch zu der von der Regel verwendeten Gruppe gehört, seine Wertigkeit größer als null ist und die Zeitmarke für den Verfall einen späteren Zeitpunkt als die aktuelle Zeit angibt, wird der Server in dem Cookie für den Lastausgleich ausgewählt. Ist eine der vorhergehenden drei Bedingungen nicht erfüllt, wird ein Server unter Verwendung des normalen Algorithmus ausgewählt. Nach Auswahl eines Servers (mit einer der beiden Methoden) wird ein neues Cookie erstellt, das IBMCBR, die Angabe Cluster:Port:ausgewählterServer und eine Zeitmarke enthält. Die Zeitmarke gibt die Uhrzeit an, zu der die Affinität ungültig wird. Die Angabe "Cluster:Port:ausgewählterServer" wird codiert, so dass keine Informationen zur CBR-Konfiguration erkennbar sind. Ein "Verfalls"parameter wird auch in das Cookie eingefügt. Dieser Parameter hat ein Format, das der Browser verstehen kann, und bewirkt, dass das Cookie zwei Stunden nach Erreichen der Zeitmarke für den Verfall ungültig wird. Damit soll vermieden werden, dass die Cookie-Datenbank des Clients zu sehr anwächst.
Dieses neue Cookie wird dann in die Kopfzeilen eingefügt, die an den Client gesendet werden. Ist der Browser des Clients so konfiguriert, dass er Cookies akzeptiert, sendet er nachfolgende Anforderungen zurück.
Die Option für aktive Cookie-Affinität für den Regelbefehl (rule) kann nur auf "activecookie" gesetzt werden, wenn die Haltezeit (stickytime) für den Port gleich null (inaktiviert) ist. Ist die aktive Cookie-Affinität für eine Regel aktiviert, kann keine Haltezeit für den Port aktiviert werden.
Verwenden Sie zum Aktivieren der aktiven Cookie-Affinität für eine bestimmte Regel wie folgt den Befehl "rule set":
rule set Cluster:Port:Regel stickytime 60 rule set Cluster:Port:Regel affinity activecookie
Die Haltezeit wird in der Regel für CGIs oder Servlets verwendet, die den Client-Status auf dem Server speichern. Der Status wird durch eine Cookie-ID identifiziert (dies sind Server-Cookies). Der Client-Status ist nur auf dem ausgewählten Server gespeichert. Der Client benötigt also das Cookie von diesem Server, um diesen Status zwischen Anforderungen zu wahren.
Die passive Cookie-Affinität gilt für die inhaltsabhängige Weiterleitung (cbr) durch die Dispatcher-Komponente und die CBR-Komponente. Informationen zum Konfigurieren der Dispatcher-Weiterleitungsmethode "cbr" finden Sie im Abschnitt Inhaltsabhängige Weiterleitung durch die Dispatcher-Komponente (cbr).
Die passive Cookie-Affinität bietet eine Möglichkeit, Clients an einen bestimmten Server zu binden. Wenn Sie für eine Regel die Affinität auf "passivecookie" setzen, können Sie den Webdatenverkehr mit Affinität zu einem Server verteilen. Die Affinität basiert auf den von den Servern generierten Identifizierungs-Cookies. Die passive Cookie-Affinität wird auf Regelebene konfiguriert. Wird eine Regel mit aktivierter passiver Cookie-Affinität erfüllt, wählt Network Dispatcher den Server ausgehend von dem im HTTP-Header der Client-Anforderung enthaltenen Cookie-Namen aus. Die Server, an die Network Dispatcher neue eingehende Anforderungen sendet, werden anhand der Cookies, die während der bisherigen Verbindungen von den Servern generiert wurden, ausgewählt. Wenn in der Client-Anforderung kein Cookie-Wert gefunden wird oder dieser nicht mit einem der Server-Cookie-Werte übereinstimmt, wird der Server mit Hilfe der gewichteten RoundRobin-Methode ausgewählt.
Gehen Sie zum Konfigurieren der passiven Cookie-Affinität wie folgt vor:
Die Option für passive Cookie-Affinität für den Regelbefehl (rule) kann nur auf "passivecookie" gesetzt werden, wenn die Haltezeit (stickytime) für den Port gleich null (inaktiviert) ist. Ist die passive Cookie-Affinität für eine Regel aktiviert, kann keine Haltezeit für den Port aktiviert werden.
Die URI-Affinität gilt für die Weiterleitungsmethode "cbr" von Dispatcher und die CBR-Komponente. Informationen zum Konfigurieren der Weiterleitungsmethode "cbr" finden Sie im Abschnitt Inhaltsabhängige Weiterleitung durch die Dispatcher-Komponente (cbr).
Bei Verwendung der URI-Affinität kann die Arbeitslast des Webdatenverkehrs so auf Caching-Proxy-Server verteilt werden, dass auf den einzelnen Servern unterschiedlicher Inhalt im Cache gespeichert werden kann. Auf diese Weise vergrößern Sie effektiv den Cache Ihrer Site, da eine redundante Zwischenspeicherung von Inhalten auf mehreren Maschinen vermieden wird. Konfigurieren Sie die URI-Affinität auf Regelebene. Wenn eine Regel mit aktivierter URI-Affinität erfüllt ist und die entsprechende Gruppe von Servern verfügbar und aktiv ist, leitet Network Dispatcher neue eingehende Client-Anforderungen mit demselben URI an einen Server weiter.
Normalerweise verteilt Network Dispatcher Anforderungen auf mehrere Server, die identische Inhalte bereitstellen. Wenn Sie Network Dispatcher mit einer Gruppe von Caching-Servern verwenden, wird häufig abgerufener Inhalt unter Umständen auf allen Servern zwischengespeichert. Daraus ergibt sich eine sehr hohe Client-Belastung, wenn auf mehreren Maschinen zwischengespeicherte identische Inhalte repliziert werden. Diese Vorgehensweise ist besonders für Websites mit großem Datenvolumen sinnvoll.
Wenn Ihre Website jedoch nur ein mittleres Client-Datenvolumen mit den verschiedensten Inhalten unterstützt und Sie einen großen, auf mehrere Server verteilten Cache bevorzugen, ist der Durchsatz Ihrer Site besser, wenn jeder Caching Server eindeutige Inhalte enthält und Network Dispatcher die Anforderungen nur an den Caching Server mit den entsprechenden Inhalten weiterleitet.
Bei Verwendung der URI-Affinität können Sie mit Network Dispatcher den zwischengespeicherten Inhalt auf einzelne Server verteilen und so eine redundante Zwischenspeicherung von Inhalten auf mehreren Maschinen vermeiden. Durch diese Erweiterung kann der Durchsatz von Serversites mit vielfältigen Inhalten, die Caching-Proxy-Server verwenden, verbessert werden. Identische Anforderungen werden an einen Server gesendet, so dass der Inhalt nur auf einem Server zwischengespeichert wird. Mit jeder zum Pool hinzugefügten Servermaschine vergrößert sich der effektive Cache.
Gehen Sie zum Konfigurieren der URI-Affinität wie folgt vor:
Die Option für URI-Affinität für den Regelbefehl (rule) kann nur auf URI gesetzt werden, wenn die Haltezeit (stickytime) für den Port gleich null (inaktiviert) ist. Ist die URI-Affinität für eine Regel aktiviert, kann keine Haltezeit für den Port aktiviert werden.
Diese Funktion ist nur für die Dispatcher-Komponente verfügbar.
Der Dispatcher ist in der Lage, potenzielle DoS-Attacken zu erkennen und Administratoren durch einen Alert zu benachrichtigen. Dazu analysiert der Dispatcher eingehende Anforderungen auf eine verdächtige Anzahl halboffener TCP-Verbindungen von Servern, die ein allgemeines Kennzeichen einfacher DoS-Attacken sind. Bei einer DoS-Attacke empfängt eine Site eine große Anzahl fabrizierter SYN-Pakete von einer Vielzahl von Quellen-IP-Adressen und Quellen-Port-Nummern. Folgepakete für diese TCP-Verbindungen werden jedoch nicht empfangen. Dies führt zu einer großen Anzahl halboffener TCP-Verbindungen auf den Servern, so dass diese mit der Zeit sehr langsam werden und keine neuen ankommenden Verbindungen mehr akzeptieren können.
Network Dispatcher stellt Benutzer-Exits , die Scripts aufrufen. Diese Scripts können so angepasst werden, dass der Administrator per Alert von einer möglichen DoS-Attacke informiert wird. Dispatcher stellt im Verzeichnis ...nd/servers/samples das folgende Beispiel-Script bereit:
Zum Ausführen der Dateien müssen Sie sie in das Verzeichnis ...nd/servers/bin verschieben und die Erweiterung ".sample" löschen.
Zum Implementieren der Erkennung von DoS-Attacken müssen Sie wie folgt den Parameter maxhalfopen des Befehls ndcontrol port setzen:
ndcontrol port set 127.40.56.1:80 maxhalfopen 1000
Im obigen Beispiel vergleicht der Dispatcher die aktuelle Gesamtanzahl halboffener Verbindungen (für alle Server des Clusters 127.40.56.1 am Port 80) mit dem Schwellenwert 1000 (der vom Parameter "maxhalfopen" angegeben ist). Übersteigt die Anzahl der aktuellen halboffenen Verbindungen den Schwellenwert, wird ein Alert-Script (halfOpenAlert) aufgerufen. Fällt die Anzahl halboffener Verbindungen unter den Schwellenwert, wird ein anderes Alert-Script aufgerufen, um das Ende der Attacke anzuzeigen.
Bestimmen Sie wie folgt den Wert, den Sie für "maxhalfopen" definieren sollten: Wenn auf Ihrer Site ein mäßiger bis starker Datenverkehr zu verzeichnen ist, erstellen Sie in regelmäßigen Abständen (vielleicht alle 10 Minuten) mit ndcontrol port halfopenaddressreport Cluster:Port einen Bericht zu halboffenen Verbindungen. Der Bericht gibt die aktuelle Gesamtanzahl der empfangenen halboffenen Verbindungen an. Setzen Sie "maxhalfopen" auf einen Wert, der 50 % bis 200 % über der höchsten Anzahl halboffener Verbindungen liegt, die auf Ihrer Site aufgetreten sind.
Neben statistischen Daten generiert "halfopenaddressreport" für alle Client-Adressen (maximal 8000 Adresspaare), deren Serverzugriff halboffene Verbindungen zur Folge hatten, Einträge im Protokoll (..nd/servers/logs/dispatcher/halfOpen.log).
Back-End-Server können Sie zusätzlich vor DoS-Attacken schützen, indem Sie Platzhalter-Cluster und -Ports konfigurieren. Fügen Sie unter jedem konfigurierten Cluster einen Platzhalter-Port ohne Server hinzu. Fügen Sie außerdem einen Platzhalter-Cluster mit einem Platzhalter-Port und ohne Server hinzu. Dies hat zur Folge, dass alle Pakete, die an einen Platzhalter-Cluster oder -Port gesendet werden, gelöscht werden. Informationen zu Platzhalter-Clustern und -Ports finden Sie in den Abschnitten Platzhalter-Cluster verwenden, um Serverkonfigurationen zusammenzufassen und Platzhalter-Port für die Übertragung von Datenverkehr mit nicht konfiguriertem Port verwenden.
Die binäre Protokollierung ermöglicht das Speichern von Serverdaten in Binärdateien. 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:
Einige dieser Informationen werden im Rahmen des Manager-Zyklus aus dem Executor abgerufen. Der Manager muss daher aktiv sein, damit die Informationen in den binären Protokollen aufgezeichnet werden können.
Verwenden Sie den Befehl ndcontrol log set, um das binäre Protokollieren zu konfigurieren.
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. Der Protokolldienst wird standardmäßig gestoppt.
Mit der Option 'set interval' wird gesteuert, wie oft Informationen in die Protokolle geschrieben werden. Der Manager sendet in jedem Manager-Intervall Serverdaten an den Protokollserver. Die Daten werden nur in die Protokolle geschrieben, wenn seit dem Schreiben des letzten Protokolleintrags die für das Protokollintervall angegebene Zeit in Sekunden verstrichen ist. Standardmäßig wird das Protokollierungsintervall auf 60 Sekunden gesetzt. Zwischen den Einstellungen für das Manager-Intervall und das Protokollierungsintervall gibt es eine gewisse Interaktion. Da dem Protokollserver Informationen nicht schneller zur Verfügung gestellt werden als dies im Manager-Intervall (in Sekunden) angegeben ist, wird durch Angabe eines Protokollierungsintervalls, das kleiner als das Manager-Intervall ist, das Protokollierungsintervall de facto auf denselben Wert wie das Manager-Intervall gesetzt. Mit dieser Protokollierungstechnik können Sie Serverinformationen mit größerer Detaillierung erfassen. Sie können alle vom Manager 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. Dies geschieht nur, wenn der Protokollserver von dem Manager aufgerufen wird, d. h., wird der Manager gestoppt, werden alte Protokolldateien nicht gelöscht.
Mit der Option 'status' werden die aktuellen Einstellungen des Protokolldienstes zurückgegeben. Diese Einstellungen geben an, ob der Service gestartet ist und welche Werte für das Intervall und die Verweildauer angegeben sind.
Im Verzeichnis ...nd/servers/samples/BinaryLog 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 unter Verwendung des bereitgestellten Scripts und Programms für Dispatcher:
ndlogreport 2001/05/01 8:00 2001/05/01 17:00
Dieser Befehl liefert einen Bericht mit den Serverdaten der Dispatcher-Komponente vom 1. Mai 2001 in der Zeit von 8.00 Uhr bis 17.00 Uhr. (Verwenden Sie für CBR cbrlogreport. Für Mailbox Locator müssen Sie mllogreport verwenden. Verwenden Sie für Cisco Consultant lbclogreport.)
Für Cisco Consultant führt der Cisco CSS Switch die Tasks aus, die der Executor bei der Dispatcher-Komponente übernimmt. Neben der aktuellen Wertigkeit der einzelnen Server und einigen anderen für Berechnungen erforderlichen Informationen erhält der Manager vom Cisco CSS Switch die Werte für aktive und neue Verbindungen. Diese Werte basieren auf Informationen, die intern im Cisco CSS Switch generiert und gespeichert werden.
Cisco Consultant fragt die MIB (Verwaltungsinformationsdatenbank) des Cisco CSS Switch ab, um Informationen zu den aktiven und neuen Verbindungen zu erhalten, und empfängt folgendes:
apSvcConnections OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Aktuelle Anzahl der TCP-Verbindungen für diesen Dienst" DEFVAL { 0 } --DEFAULT ap-display-name Service Connections ::= {apSvcEntry 20}
Die Objektkennung für apSvcConnections lautet wie folgt:
1.3.6.1.4.1.2467.1.15.2.1.20
Die Anzahl der aktiven Verbindungen hängt von der Anzahl der Clients sowie von der Zeit ab, die für die Nutzung der von den am Lastausgleich beteiligten Servermaschinen bereitgestellten Dienste erforderlich ist. Bei schnellen Client-Verbindungen (wie sie für kleine Webseiten, die mit HTTP GET bedient werden, typisch sind), ist die Anzahl der aktiven Verbindungen ziemlich klein. Wenn die Client-Verbindungen langsamer sind (z. B. bei einer Datenbankabfrage), ist die Anzahl aktiver Verbindungen größer.
Der Index für diese Variable sieht wie folgt aus:
INDEX { apCntsvcOwnName, apCntsvcCntName, apCntsvcSvcName }Der MIB-Eintrag sieht wie folgt aus:
apCntsvcHits OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Gesamtanzahl der Abläufe, die diesem Dienst für diese content-Regel zugeordnet wurden" DEFVAL { 0 } --DEFAULT ap-display-name Hits --DEFAULT apjam-popup-ref apCntSvcInst, Statistics --DEFAULT apjam-chart-def cntSvcHitsChart, pie, apCntInst, "Hit Information Per Service: --DEFAULT apjam-chart-item cntSvcHitsChart, getnext, apCntsvcSvcName ::= {apSvcEntry 20}
Die Objektkennung für apCntsvcHits lautet wie folgt:
1.3.6.1.4.1.2467.1.18.2.1.4
Der Cisco CSS Switch muss für den Lastausgleich mit der gewichteten RoundRobin-Methode konfiguriert werden. Informationen hierzu finden Sie im Abschnitt "Configuring Weight" der Veröffentlichung Content Services Switch Basic Configuration Guide.
Die Manager-Funktion legt Wertigkeiten auf der Grundlage von internen Zählern des Cisco CSS Switch und von Feedback der Advisor-Funktionen und von Metric Server fest. Falls Sie Wertigkeiten bei Ausführung des Managers manuell festlegen möchten, geben Sie den Befehl lbccontrol server mit der Option fixedweight an.
Ist keiner der Server verfügbar, sind alle Wertigkeiten gleich null. Wenn keiner der Server Anforderungen verarbeitet und alle Wertigkeiten gleich null sind, werden die Wertigkeiten auf die Hälfte der Wertigkeitsgrenze gesetzt, um für Server, die in der Lage sind, Anforderungen zu verarbeiten, eine Chancengleichheit zu gewährleisten. Das Überwachungsprogramm zeigt die Nullwertigkeiten als gültig an. An allen anderen Stellen zeigt Cisco Consultant jedoch eine Wertigkeit an, die der Hälfte der Wertigkeitsgrenze entspricht.
Wertigkeiten werden mit SNMP an den Cisco CSS Switch gesendet. Cisco Consultant setzt apSvcWeight in der Datenbank svcExt.mib. Der MIB-Eintrag apSvcWeight sieht wie folgt aus:
apSvcWeight OBJECT-TYPE SYNTAX Integer 32(1..10) MAX-ACCESS read-create STATUS current DESCRIPTION "Dienstwertigkeit, die zusammen mit Messwerten für die Arbeitslast bei Entscheidungen bezüglich der Lastzuordnung verwendet wird. Anhand der Wertigkeit können Abläufe einem bestimmten Dienst zugeteilt werden." DEFVAL { 1 } --DEFAULT ap-display-name Service Weight --DEFAULT apjam-popup-ref apServicesGroupInst, Properties, Advanced --DEFAULT apjam-wizard-field 2, normal ::= {apSvcEntry 16}
Die Objektkennung für apSvcWeight lautet wie folgt:
1.3.6.1.4.1.2467.1.15.2.1.12
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 lbccontrol port set weightbound. Dieser Befehl gibt die Unterschiede für die Anzahl der Anforderungen an, die jeder Server erhält. Wenn Sie die maximale Wertigkeit auf 1 setzen, können alle Server die Wertigkeit 1 haben. Zurückgestellte Server erhalten 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. Wird die maximale Wertigkeit auf 2 gesetzt, kann ein Server doppelt so viele Anforderungen wie ein anderer Server erhalten.
Erkennt eine Advisor-Funktion, dass ein Server offline ist, teilt sie dies dem Manager mit. Der Manager setzt dann die Wertigkeit des Servers auf null. Ist die Wertigkeit eines Servers größer als null, wird sie an den Cisco CSS Switch gesendet. Der Server wird aktiviert. Wenn die Serverwertigkeit jedoch kleiner als null oder gleich null ist, wird der Server zurückgestellt. Zum Aktivieren und Aussetzen von Diensten wird die MIB-Variable apSvcEnable in der svcExt.mib des Cisco CSS Switch gesetzt. Der MIB-Eintrag apSvcEnable sieht wie folgt aus:
apSvcEnable OBJECT-TYPE SYNTAX Integer disable(0) enable(1) MAX-ACCESS read-create STATUS current DESCRIPTION "Status des Dienstes - aktiviert oder inaktiviert" DEFVAL { disable } --DEFAULT ap-display-name Status --DEFAULT apjam-popup-ref apServicesGroupInst, Properties --DEFAULT apjam-wizard-field 2, normal ::= {apSvcEntry 12}
Die Objektkennung für apSvcEnable lautet wie folgt:
1.3.6.1.4.1.2467.1.15.2.1.16
Dieses Kapitel erläutert die Verwendung und Verwaltung von Network Dispatcher und ist in folgende Abschnitte untergliedert:
Network Dispatcher stellt eine Option zur Verfügung, mit der die Konfigurationsprogramme auf einer anderen Maschine als der Maschine ausgeführt werden können, auf der die Network-Dispatcher-Server ausgeführt werden.
Die Kommunikation zwischen den Konfigurationsprogrammen (ndcontrol, cbrcontrol, mlcontrol, sscontrol, lbccontrol, ndwizard, cbrwizard, mlwizard, sswizard, ndadmin) wird mit Java Remote Method Invocation (RMI) durchgeführt. Der Befehl, mit dem die Verbindung zu einer Network Dispatcher-Maschine für die Fernverwaltung hergestellt wird, lautet ndcontrol host:ferner_Host. Stammt der RMI-Aufruf von einer anderen Maschine als der lokalen Maschine, muss eine Authentifizierung mit allgemeinem Schlüssel und 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:
Dieser Befehl muss auf derselben Maschine wie Network Dispatcher ausgeführt werden.
Bei Verwendung der Option create wird im Schlüsselverzeichnis des Servers (...nd/servers/key/) ein öffentlicher Schlüssel erstellt. Im Verwaltungsverzeichnis für Schlüssel (...nd/admin/keys/) der einzelnen Network-Dispatcher-Komponenten werden private Schlüssel erstellt. Der Dateiname für den privaten Schlüssel ist Komponente-Serveradresse-RMI-Port. Diese privaten Schlüssel müssen anschließend zu den fernen Clients transportiert und in das Verwaltungsverzeichnis für Schlüssel gestellt werden.
Auf einer Network-Dispatcher-Maschine mit der Adresse 10.0.0.25 (hostname), die für jede Komponente den Standard-RMI-Port verwendet, generiert der Befehl ndkeys create die folgenden Dateien:
Die Verwaltungsdateigruppe wurde auf einer anderen Maschine installiert. Die Dateien der privaten Schlüssel müssen auf der fernen Client-Maschine in das Verzeichnis .../nd/admin/keys gestellt werden.
Jetzt ist der ferne Client berechtigt, Network Dispatcher auf der Maschine 10.0.0.25 zu konfigurieren.
Dieselben Schlüssel müssen Sie auf allen fernen Clients verwenden, die berechtigt sein sollen, Network Dispatcher auf der Maschine 10.0.0.25 zu konfigurieren.
Würde der Befehl ndkeys create erneut ausgeführt, hätte dies die Generierung einer neuen Gruppe von allgemeinen/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 ndkeys delete werden die öffentlichen und privaten 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 "ndkeys create" und "ndkeys 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.
Network Dispatcher sendet Einträge an ein Serverprotokoll, ein Manager-Protokoll, an das Protokoll eines Messwertüberwachungsprogramms (protokollbezogene Kommunikation mit Metric-Server-Agenten) und an das Protokoll jeder von Ihnen verwendeten Advisor-Funktion.
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. Network Dispatcher protokolliert außerdem Header und Datensätze von Ereignissen, die nur einmal eintreten. (Beim Starten einer Advisor-Funktion wird beispielsweise eine Nachricht in das Manager-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. Die Standardeinstellung für das Serverprotokoll ist 0. Für das Manager-Protokoll, das Protokoll der Advisor-Funktionen sowie das Protokoll der Subagenten ist die Standardeinstellung 1.
Zudem können Sie die maximale Größe eines Protokolls festlegen. Wenn Sie eine maximale Größe für die Protokolldatei festlegen, findet ein Dateiumbruch statt. Hat die Datei die angegebene Größe erreicht, 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 vorsichtiger 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 Network Dispatcher generierten Protokolle werden standardmäßig im Unterverzeichnis logs des Installationsverzeichnisses von Network Dispatcher gespeichert. Wenn Sie diesen Pfad ändern möchten, setzen Sie die Variable nd_logdir im ndserver-Script entsprechend.
AIX, Linux und Solaris: Sie finden das ndserver-Script im Verzeichnis /usr/bin. In diesem Script ist die Variable nd_logdir auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
ND_LOGDIR=/Pfad/für/meine/Protokolle/
Windows 2000: Sie finden die ndserver-Datei im Systemverzeichnis von Windows 2000 (in der Regel c:\WINNT\SYSTEM32). In der ndserver-Datei ist die Variable nd_logdir auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
set ND_LOGDIR=c:\Pfad\für\meine\Protokolle\
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äre Protokollierung von Network Dispatcher wird dasselbe Verzeichnis (log) wie für die übrigen Protokolldateien verwendet. Weitere Informationen hierzu finden Sie in Binäres Protokollieren verwenden, um Serverstatistiken zu analysieren.
Dieser Abschnitt erläutert die Verwendung und Verwaltung der Dispatcher-Komponente.
Network Dispatcher betrachtet Verbindungen als veraltet, wenn sie die durch das Inaktivitätszeitlimit angegebene Zeit (Sekunden) lang inaktiv waren. Wird das Inaktivitätszeitlimit überschritten, entfernt Network Dispatcher den Eintrag für diese Verbindung aus seinen Tabellen und löscht den nachfolgenden Datenverkehr für diese Verbindung.
Auf Port-Ebene können Sie das Inaktivitätszeitlimit beispielsweise mit dem Befehl ndcontrol port set staletimeout angeben.
Das Inaktivitätszeitlimit kann auf Executor-, Cluster- und Port-Ebene gesetzt werden. Auf Executor- und Cluster-Ebene liegt der Standardwert bei 300 Sekunden. Es wird bis hinunter zum Port gefiltert. Auf Port-Ebene 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 32.000.000 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 Client-Verbindung 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 Network Dispatcher kleiner als das des Dienstes ist, können Konnektivitätsprobleme auftreten. Im Falle von LDAP liegt das Inaktivitätslimit von Network Dispatcher (staletimeout) standardmäßig bei 300 Sekunden. Ist die Verbindung 300 Sekunden inaktiv, entfernt Network Dispatcher 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 Network Dispatcher 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 Network Dispatcher (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 von der Speicherbereinigungsfunktion, die in den Executor integriert ist, bereinigt werden.
Über die Schlüsselwörter fintimeout und fincount können Sie festlegen, wie oft der Executor eine Speicherbereinigung durchführt und wie viel Speicher bereinigt wird. Der Executor prüft regelmäßig die Liste der von ihm zugeordneten Verbindungen. Wenn die Anzahl der Verbindungen mit dem Status BEENDET größer-gleich der im Schlüsselwort fincount festgelegten Anzahl der beendeten Verbindungen ist, versucht der Executor, den Speicher freizugeben, der für diese Verbindungsdaten benutzt wird. Die Standardanzahl beendeter Verbindungen kann durch Eingabe des Befehls ndcontrol executor set fincount geändert werden.
Die Speicherbereinigungsfunktion gibt den Speicher für alle Verbindungen mit dem Status BEENDET frei, die älter sind als die im Schlüsselwort fintimeout als Zeitlimit für die Beendigung inaktiver Verbindungen angegebene Anzahl von Sekunden. Das Zeitlimit für die Beendigung inaktiver Verbindungen kann durch Eingabe des Befehls ndcontrol executor set fintimeout geändert werden.
Das Inaktivitätszeitlimit gibt die Zeit der Inaktivität einer Verbindung in Sekunden an, nach der die Verbindung entfernt wird. Weitere Informationen hierzu finden Sie im Abschnitt Inaktivitätszeitlimit verwenden. Die Anzahl beendeter Verbindungen hat auch Auswirkungen darauf, wie oft "lange inaktive" Verbindungen entfernt werden. Wenn Ihre Dispatcher-Maschine keine hohe Speicherkapazität hat, sollten Sie Anzahl beendeter Verbindungen (FIN-Zähler) auf einen niedrigeren Wert setzen. Bei einer stark frequentierten Website sollten Sie den FIN-Zähler auf einen höheren Wert setzen.
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 Manager-Funktion 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-Verwaltungsinformationsbasis (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 ..nd/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 Protocol Interface). DPI ist eine Schnittstelle zwischen einem SNMP-Agenten und seinen Subagenten.
Abbildung 28. SNMP-Befehle für AIX und Solaris
AIX stellt 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 Solaris müssen Sie einen SMUX-fähigen SNMP-Agenten erwerben, da dieses Betriebssystem keinen solchen bereitstellt. Network Dispatcher stellt DPID2 für Solaris im Verzeichnis /opt/nd/servers/samples/SNMP bereit.
Den DPI-Agenten müssen Sie als Benutzer "root" ausführen. Bevor Sie den DPID2-Dämon ausführen, aktualisieren Sie die Dateien /etc/snmpd.peers und /etc/snmpd.conf wie folgt:
"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
Aktualisieren Sie snmpd, damit die Datei /etc/snmpd.conf erneut gelesen wird:
refresh -s snmpd
Starten Sie den DPID-SMUX-Peer:
dpid2
Die Dämonen müssen in der folgenden Reihenfolge gestartet werden:
Abbildung 29. SNMP-Befehle für Windows 2000
Wenn Sie einen DPI-fähigen SNMP-Agenten für Windows 2000 benötigen, installieren Sie die Windows-NT-Version aus dem IBM SystemView Agent Toolkit von http://www.tivoli.com/support/sva.
Bevor Sie den SystemView-SNMPD-Prozess starten, müssen Sie die SNMP-Unterstützung von Microsoft Windows inaktivieren. Der snmp-Prozess von SystemView unterstützt DPI-Subagenten und Microsoft-kompatible Agenten.
Sie können die Windows-SNMP-Unterstützung wie folgt inaktivieren:
Befolgen Sie die Anweisungen im Abschnitt Namen einer Benutzergemeinschaft für SNMP angeben, um den SystemView-SNMP-Agenten zu konfigurieren.
Sie sollten den Namen der SNMP-Benutzergemeinschaft konfigurieren. Der standardmäßige SNMP-Benutzergemeinschaftsname lautet public. Auf UNIX-Systemen wird der Name in einer Datei mit dem Namen /etc/snmpd.conf festgelegt.
Der Name der Benutzergemeinschaft muss auf allen Systemen konsistent konfiguriert und verwendet werden. Wenn der Name der Benutzergemeinschaft für Network Dispatcher in der Konfiguration des SNMP-Agenten auf "UnsereGemeinschaft" gesetzt wurde, muss er in der Konfiguration des Subagenten ebenfalls auf "UnsereGemeinschaft" gesetzt werden.
Unter Windows 2000 müssen Sie vor dem Erstellen des Namens für die Benutzergemeinschaft den IBM SystemView SNMP Agent konfigurieren.
Dieser Schritt ermöglicht es jedem Host in jedem Netz, auf die SNMP-MIB-Variablen zuzugreifen. Wenn Sie überprüft haben, dass diese Werte funktionieren, können Sie sie entsprechend Ihren Anforderungen ändern.
Verwenden Sie bei aktivem Executor den Befehl ndcontrol subagent start [Name_der_Benutzergemeinschaft], um den Namen der Benutzergemeinschaft zu definieren, der zwischen dem DPI-Subagenten des Dispatchers und dem SNMP-Agenten verwendet wird. Standardmäßig lautet der Name der Benutzergemeinschaft public. Wenn Sie diesen Wert ändern, müssen Sie auch den neuen Namen der Benutzergemeinschaft zum SystemView-Agenten hinzufügen. Verwenden Sie dazu wie oben angegeben "snmpcfg".
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) des Hochverfügbarkeitsstatus geändert hat. Die gültigen Werte von hasState sind:
Die Alarmnachricht indSrvrGoneDown gibt an, dass die Wertigkeit des vom Abschnitt csAddr, psNum, ssAddr 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 csAddr, psNum 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 Network Dispatcher 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 csAddr 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 Network Dispatcher nach dem Senden einer indDOSAttack-Alarmnachricht feststellt, dass die mögliche DoS-Attacke vorüber ist, wird diese Alarmnachricht gesendet.
Aufgrund einer Einschränkung in der SMUX-API kann es sich 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 ndcontrol subagent start wird die SNMP-Unterstützung aktiviert. Mit dem Befehl ndcontrol subagent stop wird die SNMP-Unterstützung inaktiviert.
Weitere Informationen über den Befehl ndcontrol befinden sich unter ndcontrol subagent -- SNMP-Subagenten konfigurieren.
In den Linux-Kernel ist das Firewall-Tool ipchains integriert. Wenn Network Dispatcher und ipchains gleichzeitig ausgeführt werden, sieht Network Dispatcher die Pakete zuerst. Erst danach werden sie von ipchains gesehen. Deshalb kann ipchains verwendet werden, um die Sicherheit einer Linux-Maschine mit Network Dispatcher zu erhöhen. Bei einer solchen Maschine könnte es sich beispielsweise um einen Rechner mit Network Dispatcher 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 Network Dispatcher 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 Network Dispatcher sonst nicht fehlerfrei arbeiten kann. Nachfolgend sind einige Beispiele für eine solche Kommunikation aufgelistet:
Eine angemessene ipchains-Strategie für die Network-Dispatcher-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 reach-Zielen oder Konfigurations-Hosts zu unterbinden.
Dieser Abschnitt erläutert die Verwendung und Verwaltung der CBR-Komponente von Network Dispatcher.
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 Network Dispatcher verwenden.
Nachdem Sie Mailbox Locator gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von Mailbox Locator verwendeten Protokolle ähneln den Protokollen des Dispatchers. Weitere Informationen befinden sich unter Protokolle von Network Dispatcher verwenden.
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 befinden sich unter Protokolle von Network Dispatcher verwenden.
Nachdem Sie Cisco Consultant gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von Cisco Consultant verwendeten Protokolle ähneln den Protokollen des Dispatchers. Weitere Informationen befinden sich unter Protokolle von Network Dispatcher verwenden.
Metric Server stellt Informationen zur Serverauslastung für Network Dispatcher bereit. Metric Server befindet sich auf jedem Server, der in den Lastausgleich einbezogen ist.
Ändern Sie die Protokollstufe im Start-Script für Metric Server. Sie können eine Protokollstufe von 0 bis 5 angeben. Die Stufen sind denen für die Network-Dispatcher-Protokolle vergleichbar. Daraufhin wird im Verzeichnis ...ms/logs ein Agentenprotokoll erstellt.
Anhand der Informationen in diesem Kapitel können Fehler erkannt und behoben werden, die sich auf Network Dispatcher beziehen. Suchen Sie nach dem Fehler, den Sie erkannt haben, in Fehlerbehebungstabellen.
Die nachfolgenden Tabellen sind zur Fehlerbehebung für Dispatcher,
CBR, Mailbox Locator, Site Selector und Consultant für Cisco CSS Switches
bestimmt.
Tabelle 14. Tabelle zur Fehlerbehebung für Dispatcher
Fehler | Mögliche Ursache | Siehe... |
---|---|---|
Dispatcher wird nicht korrekt ausgeführt | In Konflikt stehende Port-Nummern | Port-Nummern für Dispatcher überprüfen |
Ein auf der Dispatcher-Maschine konfigurierter Server antwortet nicht auf Lastausgleichsanforderungen | Falsche oder sich widersprechende Adresse | Problem: Dispatcher und Server antworten nicht |
Kein Service für Verbindungen von Client-Maschinen oder Zeitlimitüberschreitung bei Verbindungen |
| Problem: Dispatcher-Anforderungen werden nicht verteilt |
Client-Maschinen erhalten keinen Service oder überschreiten das Zeitlimit | Funktion für hohe Verfügbarkeit arbeitet nicht | Problem: Die Dispatcher-Funktion für hohe Verfügbarkeit arbeitet nicht |
Es kann kein Überwachungssignal hinzugefügt werden (Windows 2000) | Die Quellenadresse ist auf keinem Adapter konfiguriert | Problem: Es kann kein Überwachungssignal hinzugefügt werden (Windows 2000) |
Server verarbeitet keine Anforderungen (Windows) | Es wurde eine zusätzliche Route in der Route-Tabelle erstellt. | Problem: Zusätzliche Routes (Windows 2000) |
Advisor arbeiten nicht korrekt mit der Weitverkehrsunterstützung | Advisor werden auf fernen Maschinen nicht ausgeführt | Problem: Advisor arbeiten nicht korrekt |
SNMPD kann nicht gestartet oder weiter ausgeführt werden (Windows 2000). | Der in den SNMP-Befehlen übergebene Name der Benutzergemeinschaft stimmt nicht mit dem Namen der Benutzergemeinschaft überein, der zum Starten des Subagenten verwendet wurde. | Problem: SNMPD wird nicht korrekt ausgeführt (Windows 2000) |
Dispatcher, Microsoft IIS und SSL arbeiten nicht oder setzen die Arbeit nicht fort | Protokollübergreifend können keine verschlüsselten Daten gesendet werden. | Problem: Dispatcher, Microsoft IIS und SSL funktionieren nicht (Windows 2000) |
Verbindung zur fernen Maschine zurückgewiesen | Es wird noch eine ältere Version der Schlüssel verwendet. | Problem: Dispatcher-Verbindung zu einer fernen Maschine |
Der Befehl ndcontrol oder ndadmin schlägt mit der Nachricht 'Server antwortet nicht' oder 'Zugriff auf RMI-Server nicht möglich' fehl |
| Problem: Befehl ndcontrol oder ndadmin schlägt fehl |
Wenn Netscape als Standardbrowser zum Anzeigen der Onlinehilfe verwendet wird, erscheint die Fehlernachricht "Datei ... nicht gefunden" (Windows 2000). | Falsche Einstellung für die HTML-Dateizuordnung | Problem: Fehlernachricht "Datei nicht gefunden... beim Anzeigen der Onlinehilfe (Windows 2000) |
Beim Starten von ndserver unter Solaris 2.7 erscheint die Fehlernachricht "stty: : No such device or address". | Diese Fehlernachricht können Sie ignorieren. Es liegt kein Fehler vor. "ndserver" wird ordnungsgemäß ausgeführt. | Problem: Irrelevante Fehlernachricht beim Starten von ndserver unter Solaris 2.7 |
Die grafische Benutzerschnittstelle wird nicht richtig gestartet. | Unzureichender Paging-Bereich. | Problem: Die grafische Benutzerschnittstelle (GUI) wird nicht richtig gestartet |
Fehler bei der Ausführung von Dispatcher mit installiertem Caching Proxy | Caching-Proxy-Dateiabhängigkeit | Problem: Fehler bei der Ausführung von Dispatcher mit installiertem Caching Proxy |
Die grafische Benutzerschnittstelle wird nicht richtig angezeigt. | Die Auflösung ist nicht korrekt. | Problem: Die grafische Benutzerschnittstelle (GUI) wird nicht richtig angezeigt |
Die Hilfetextanzeigen werden manchmal von anderen Fenstern verdeckt. | Java-Einschränkung | Problem: Unter 2000 sind die Hilfefenster manchmal von anderen offenen Fenstern verdeckt |
Network Dispatcher kann Rahmen nicht verarbeiten und weiterleiten. | Für jede NIC ist eine eindeutige MAC-Adresse erforderlich. | Problem: Network Dispatcher kann Rahmen nicht verarbeiten und weiterleiten |
Die Anzeige ist blau. | Es ist keine Netzwerkkarte installiert/konfiguriert. | Problem: Beim Starten des Executors von Network Dispatcher erscheint eine blaue Anzeige |
Automatische Pfaderkennung verhindert Datenrückfluss | Die Loopback-Adresse wird als Aliasname für den Cluster verwendet. | Problem: Automatische Pfaderkennung verhindert Datenrückfluss mit Network Dispatcher |
Die Advisor-Funktionen zeigen alle Server als inaktiv an. | Die TCP-Kontrollsumme wurde falsch berechnet. | Problem: Die Advisor-Funktionen zeigen alle Server als inaktiv an |
Keine hohe Verfügbarkeit im Weitverkehrsmodus von Network Dispatcher | Der ferne Dispatcher muss auf dem lokalen Dispatcher als Server eines Clusters definiert werden. | Problem: Keine hohe Verfügbarkeit im Weitverkehrsmodus von Network Dispatcher |
Die GUI Blockiert oder verhält sich nicht erwartungsgemäß, wenn versucht wird, eine große Konfigurationsdatei zu laden. | Java kann nicht auf so viel Speicher zugreifen, wie für die Bearbeitung einer so großen Änderung der GUI erforderlich ist. | Problem: Beim Laden einer großen Konfigurationsdatei blockiert die GUI oder verhält sich nicht erwartungsgemäß |
Tabelle 15. Tabelle zur Fehlerbehebung für CBR
Fehler | Mögliche Ursache | Siehe... |
CBR wird nicht korrekt ausgeführt | In Konflikt stehende Port-Nummern | Port-Nummern für CBR überprüfen |
Der Befehl cbrcontrol oder ndadmin scheitert mit der Nachricht 'Server antwortet nicht' oder 'Zugriff auf RMI-Server nicht möglich'. | Befehle können nicht ausgeführt werden, weil der Stack SOCKSifiziert ist oder cbrserver nicht gestartet wurde. | Problem: Der Befehl cbrcontrol oder ndadmin scheitert |
Die Last von Anforderungen wird nicht verteilt. | Caching Proxy wurde vor dem Executor gestartet. | Problem: Anforderungen werden nicht verteilt |
Unter Solaris scheitert der Befehl "cbrcontrol executor start" mit der Nachricht 'Fehler: Executor wurde nicht gestartet'. | Unter Umständen müssen die IPC-Standardwerte geändert werden, um den Befehl ordnungsgemäß ausführen zu können. | Problem: Unter Solaris scheitert der Befehl cbrcontrol executor start |
URL-Regel arbeitet nicht | Syntax- oder Konfigurationsfehler | Problem: Syntax- oder Konfigurationsfehler |
Tabelle 16. Tabelle zur Fehlerbehebung für Mailbox Locator
Fehler | Mögliche Ursache | Siehe... |
Mailbox Locator wird nicht korrekt ausgeführt | In Konflikt stehende Port-Nummern | Port-Nummern für Mailbox Locator überprüfen |
Der Befehl "mlserver" gibt die Ausnahmebedingung "java.rmi.RMI Security Exception: security.fd.read" zurück. | Die Systembegrenzung für Dateideskriptoren ist für die Anzahl der Anforderungen, die "mlserver" zu bedienen versucht, zu klein. | Problem: Der Befehl mlserver wird gestoppt |
Der Befehl "mlcontrol" oder "ndadmin" scheitert mit der Nachricht 'Server antwortet nicht' oder 'Zugriff auf RMI-Server nicht möglich'. | Befehle können nicht ausgeführt werden, weil der Stack SOCKSifiziert ist oder "mlserver" nicht gestartet wurde. | Problem: Der Befehl mlcontrol oder ndadmin scheitert |
Ein Port kann nicht hinzugefügt werden. | An diesem Port ist bereits eine andere Anwendung empfangsbereit. | Problem: Ein Port kann nicht hinzugefügt werden |
Bei dem Versuch, einen Port hinzuzufügen, wird ein Weiterleitungsfehler empfangen. | Die Cluster-Adresse wurde nicht vor dem Start des Proxy auf einer NIC konfiguriert, oder an diesem Port wird eine andere Anwendung ausgeführt. | Problem: Empfang eines Proxy-Fehlers beim Hinzufügen eines Ports |
Tabelle 17. Tabelle zur Fehlerbehebung für Site Selector
Fehler | Mögliche Ursache | Siehe... |
---|---|---|
Site Selector wird nicht korrekt ausgeführt | Konflikt verursachende Port-Nummer | Port-Nummern für Site Selector überprüfen |
Site Selector gewichtet vom Solaris-Client eingehende Anforderungen nicht nach der RoundRobin-Methode. | Solaris-Systeme führen einen Namensservice-Cache-Dämon aus. | Problem: Site Selector verteilt den Datenverkehr von Solaris-Clients nicht nach der RoundRobin-Methode |
Der Befehl "sscontrol" oder "ndadmin" scheitert mit der Nachricht 'Server antwortet nicht' oder 'Zugriff auf RMI-Server nicht möglich'. | Befehle können nicht ausgeführt werden, weil der Stack SOCKSifiziert ist oder "ssserver" nicht gestartet wurde. | Problem: Der Befehl sscontrol oder ndadmin scheitert |
"ssserver" kann unter Windows 2000 nicht gestartet werden. | Unter Windows muss der Host-Name nicht im DNS enthalten sein. | Problem: ssserver wird unter Windows 2000 nicht gestartet |
Für eine Maschine mit duplizierten Routes wird der Lastausgleich nicht richtig durchgeführt. Die Namensauflösung scheint nicht zu funktionieren. | Eine Site-Selector-Maschine enthält mehrere Adapter, die mit demselben Teilnetz verbunden sind. | Problem: Site Selector führt bei duplizierten Routes den Lastausgleich nicht korrekt durch |
Tabelle 18. Tabelle zur Fehlerbehebung für Consultant für Cisco CSS Switches
Fehler | Mögliche Ursache | Siehe... |
---|---|---|
"lbcserver" wird nicht gestartet. | In Konflikt stehende Port-Nummern | Port-Nummern für Cisco Consultant überprüfen |
Der Befehl "lbccontrol" oder "ndadmin" scheitert mit der Nachricht 'Server antwortet nicht' oder 'Zugriff auf RMI-Server nicht möglich'. | Befehle können nicht ausgeführt werden, weil der Stack SOCKSifiziert ist oder "lbcserver" nicht gestartet wurde. | Problem: Der Befehl lbccontrol oder ndadmin scheitert |
Empfangener Fehler: Für Port 14099 kann kein Eintrag in der Registrierungsdatenbank erstellt werden. | Abgelaufene Produktlizenz | Problem: Für Port 14099 kann kein Eintrag in der Registrierungsdatenbank erstellt werden |
Tabelle 19. Tabelle zur Fehlerbehebung für Metric Server
Fehler | Mögliche Ursache | Siehe... |
---|---|---|
IOException für Metric Server unter Windows 2000 bei Ausführung von benutzerdefinierten Messwertdateien mit der Erweiterung .bat oder .cmd | Es ist ein vollständiger Messwertname erforderlich. | Problem: IOException für Metric Server unter Windows 2000 bei Ausführung von benutzerdefinierten Messwertdateien mit der Erweiterung .bat oder .cmd |
Metric Server meldet die Lastinformationen nicht an die Network-Dispatcher-Maschine | Mögliche Ursachen sind unter anderem:
| Problem: Metric Server meldet die Last nicht an die Network-Dispatcher-Maschine |
Beim Übertragen von Schlüsselringen zum Server enthält das Metric-Server-Protokoll den Eintrag "Für den Zugriff auf den Agenten ist eine Kennung erforderlich". | Der Schlüsselring ist beschädigt und kann deshalb nicht autorisiert werden. | Problem: Metric-Server-Protokoll meldet, dass für den Zugriff auf den Agenten eine Kennung erforderlich ist |
Falls beim Ausführen des Dispatchers Probleme auftreten, verwendet unter Umständen eine Ihrer Anwendungen eine Port-Nummer, die normalerweise vom Dispatcher benutzt wird. Der Dispatcher-Server benutzt die folgenden Port-Nummern.
Wenn eine andere Anwendung eine der Dispatcher-Port-Nummern benutzt, können Sie die Port-Nummer für Dispatcher wie folgt ändern:
Wenn beim Ausführen von CBR Fehler auftreten, verwendet unter Umständen eine Ihrer Anwendungen eine Port-Nummer, die normalerweise von CBR benutzt wird. CBR benutzt die folgenden Port-Nummern:
Wenn eine andere Anwendung eine der CBR-Port-Nummern verwendet, können Sie die CBR-Port-Nummern wie folgt ändern:
Wenn bei Ausführung von Mailbox Locator Fehler auftreten, verwendet unter Umständen eine Ihrer Anwendungen eine Port-Nummer, die normalerweise von Mailbox Locator benutzt wird. Mailbox Locator benutzt die folgenden Port-Nummern:
Wenn eine andere Anwendung eine der Port-Nummern für Mailbox Locator verwendet, können Sie die Port-Nummern für Mailbox Locator wie folgt ändern:
Wenn bei Ausführung der Komponente Site Selector Fehler auftreten, verwendet unter Umständen eine Ihrer Anwendungen eine Port-Nummer, die normalerweise von Site Selector benutzt wird. Site Selector benutzt die folgenden Port-Nummern:
Wenn eine andere Anwendung eine der Port-Nummern für Site Selector verwendet, können Sie die Port-Nummern für Site Selector wie folgt ändern:
Wenn bei Ausführung von Cisco Consultant Fehler auftreten, verwendet unter Umständen eine andere Anwendung eine Port-Nummer, die normalerweise vom lbserver der Komponente Cisco Consultant benutzt wird. Cisco Consultant benutzt die folgenden Port-Nummern:
14099 zum Empfang der Befehle von lbccontrol
10004 zum Senden von Messwertabfragen an Metric Server
Wenn eine andere Anwendung eine der Port-Nummern für Consultant verwendet, können Sie die Port-Nummern für Consultant wie folgt ändern:
Dieses Problem kann auftreten, wenn eine andere Anwendung einen der Ports benutzt, die normalerweise vom Dispatcher verwendet werden. Weitere Informationen enthält Port-Nummern für Dispatcher überprüfen.
Dieses Problem tritt auf, wenn eine andere Adresse als die angegebene Adresse verwendet wird. Stellen Sie bei Verknüpfung von Dispatcher und Server sicher, dass dass die in der Konfiguration verwendete Serveradresse die NFA ist oder als verknüpft konfiguriert ist.
Bei diesem Problem erfolgt beispielsweise kein Service für Verbindungen von Client-Maschinen, oder es treten Zeitsperren für Verbindungen auf. Überprüfen Sie folgendes, um den Fehler zu bestimmen:
Dieses Problem tritt auf, wenn eine Dispatcher-Umgebung mit hoher Verfügbarkeit konfiguriert ist und bei Verbindungen der Client-Maschinen kein Service erfolgt oder Zeitlimits abgelaufen sind. Überprüfen Sie folgendes, um den Fehler zu korrigieren oder zu bestimmen:
Dieser Fehler tritt unter Windows 2000 auf, wenn die Quellenadresse nicht auf einem Adapter konfiguriert wurde. Überprüfen Sie folgendes, um den Fehler zu korrigieren oder zu bestimmen:
ndconfig tr0 <IP-Adresse> netmask <Netzmaske> oder ndcontrol cluster configure
Nach dem Konfigurieren von Servermaschinen stellen Sie unter Umständen fest, dass Sie unbeabsichtigt eine oder mehrere zusätzliche Routes erstellt haben. Werden diese zusätzlichen Routes nicht entfernt, kann der Dispatcher nicht ordnungsgemäß arbeiten. Informationen zum Feststellen und Löschen zusätzlicher Routes finden Sie im Abschnitt Servermaschinen für Lastausgleich konfigurieren.
Wird die Weitverkehrsunterstützung verwendet und scheinen die Advisor nicht korrekt zu arbeiten, müssen Sie sicherstellen, dass sie sowohl auf den lokalen als auch auf den fernen Dispatchern gestartet wurden. Lesen Sie hierzu die Informationen im Abschnitt Ferne Advisor mit der Weitverkehrsunterstützung verwenden.
Wird bei Verwendung von SNMP-Subagenten der DNMP-Dämon von SystemView Agent nicht gestartet oder nicht weiter ausgeführt, vergewissern Sie sich, dass die SNMP-Benutzergemeinschaft mit dem Programm snmpcfg konfiguriert wurde. Für den Zugriff auf SNMP-Daten von dem Dispatcher-Subagenten muss der in den SNMP-Befehlen übergebene Benutzergemeinschaftsname mit dem Benutzergemeinschaftsnamen übereinstimmen, mit dem der Subagent gestartet wurde.
Werden Dispatcher, Microsoft IIS und SSL verwendet und arbeiten diese nicht zusammen, kann dies auf ein Problem mit der Aktivierung der SSL-Sicherheit zurückzuführen sein. Weitere Informationen dazu, wie Sie ein Schlüsselpaar generieren, ein Zertifikat erhalten und ein Verzeichnis so konfigurieren, dass es SSL erfordert, finden Sie in der zu Windows 2000 gelieferten Veröffentlichung Microsoft Information and Peer Web Services Information and Planning Guide. Der lokale URL des Dokuments, das in einem Webbrowser angezeigt werden kann, lautet file:///C|/WINNT/system32/inetsrv/iisadmin/htmldocs/inetdocs.htm.
Der Dispatcher verwendet Schlüssel, die es Ihnen ermöglichen, eine Verbindung zu einer fernen Maschine herzustellen und die Maschine zu konfigurieren. Die Schlüssel geben einen RMI-Port für die Verbindung an. Sie können den RMI-Port aus Sicherheitsgründen oder bei Konflikten ändern. Wird der RMI-Port geändert, ändert sich auch der Dateiname des Schlüssels. Wenn Ihr Schlüsselverzeichnis für eine ferne Maschine mehrere Schlüssel enthält, die verschiedene RMI-Ports angeben, verwendet die Befehlszeile nur den ersten gefundenen Schlüssel. Ist dies der falsche Schlüssel, wird die Verbindung zurückgewiesen. Die Verbindung wird erst hergestellt, wenn der falsche Schlüssel gelöscht wurde.
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Der wahlfreie Port kann Fehler verursachen, wenn eine der Verwaltungskonsolen auf derselben Maschine als Firewall oder über eine Firewall ausgeführt wird. Wird beispielsweise Network Dispatcher auf derselben Maschine als Firewall ausgeführt, können beim Absetzen von ndcontrol-Befehlen Fehler wie der folgende angezeigt werden: Fehler: Server antwortet nicht.
Sie können diesen Fehler vermeiden, indem Sie die (im PATH enthaltene) Script-Datei ndserver editieren und den von RMI verwendeten wahlfreien Port festlegen. Nehmen Sie -DND_RMI_SERVER_PORT=Port in die Zeichenfolge END_ACCESS auf. Port steht hier für den von Ihnen anzugebenden Port.
Beispiel:
END_ACCESS='-DND_CLIENT_KEYS_DIRECTORY=/usr/lpp/nd/admin/keys/dispatcher -DND_SERVER_KEYS_DIRECTORY=/usr/lpp/nd/dispatcher/key -DND_RMI_SERVER_PORT=10100' ND_RMIPORT=10099
Starten Sie anschließend erneut ndserver und öffnen Sie den Datenverkehr für die Ports 10099 und 10100 oder für den Port, den Sie für die Host-Adresse, von der die Verwaltungskonsole ausgeführt wird, ausgewählt haben.
Wenn Sie unter Windows 2000 Netscape als Standardbrowser verwenden, wird bei diesem Fehler die Nachricht "Netscape kann die Datei '<Dateiname>.html' (oder eine ihrer Komponenten nicht finden. Stellen Sie sicher, dass Pfad- und Dateiname stimmen und alle erforderlichen Bibliotheken verfügbar sind".
Das Problem beruht auf einer falschen Einstellung für die HTML-Dateizuordnung.Das Problem kann wie folgt gelöst werden:
Beim Starten von ndserver auf Plattformen mit Solaris 2.7 wird fälschlicherweise die folgende Fehlernachricht angezeigt: "stty: : No such device or address". Diese Fehlernachricht können Sie ignorieren. "ndserver" wird ordnungsgemäß ausgeführt.
Die grafische Benutzerschnittstelle ndadmin erfordert für eine einwandfreie Funktion einen ausreichenden Paging-Bereich. Wenn der Paging-Bereich nicht reicht, wird die GUI möglicherweise nicht vollständig gestartet. Überprüfen Sie in einem solchen Fall den Paging-Bereich und erhöhen Sie ihn gegebenenfalls.
Wenn Sie Network Dispatcher deinstallieren, um eine andere Version zu installieren, und bei dem Versuch, die Dispatcher-Komponente zu starten, eine Fehlernachricht empfangen, überprüfen Sie, ob Caching Proxy installiert ist. Caching Proxy ist von einer der Dispatcher-Dateien abhängig. diese Datei wird nur bei der Deinstallation von Caching Proxy deinstalliert.
Sie können dieses Problem wie folgt vermeiden:
Falls die GUI von Network Dispatcher nicht richtig angezeigt wird, überprüfen Sie die Auflösung für den Desktop des Betriebssystems. Die GUI wird am besten bei einer Auflösung von 1024 x 768 Bildpunkten angezeigt.
Wenn Sie unter Windows 2000 zum ersten Mal Hilfefenster öffnen, werden diese manchmal hinter vorhandene Fenster gestellt. Klicken Sie in diesem Fall auf das Fenster, um es wieder in den Vordergrund zu stellen.
Unter Solaris haben alle Netzwerkadapter standardmäßig dieselbe MAC-Adresse. Wenn sich jeder Adapter in einem anderen IP-Teilnetz befindet, verursacht dies keine Probleme. In einer Switch-Umgebung, in der mehrere NICs mit derselben MAC-Adresse und derselben IP-Teilnetzadresse mit einem Switch kommunizieren, sendet der Switch den gesamten für die eine MAC-Adresse (und beide IP-Adressen) bestimmten Datenverkehr über eine Leitung. Nur der Adapter, der als letzter einen Rahmen über die Leitung gesendet hat, sieht die für beide Adapter bestimmten IP-Pakete. Solaris löscht unter Umständen Pakete für eine gültige IP-Adresse, die an der "falschen" Schnittstelle ankommen.
Wenn in ibmnd.conf nicht alle Netzschnittstellen für Network Dispatcher konfiguriert sind und die nicht in ibmnd.conf definierte NIC einen Rahmen empfängt, kann Network Dispatcher den Rahmen nicht verarbeiten und weiterleiten.
Sie können dieses Problem vermeiden, indem Sie die Standardeinstellung überschreiben und für jede Schnittstelle eine eindeutige MAC-Adresse definieren. Verwenden Sie den dafür den folgenden Befehl:
ifconfig Schnittstelle ether MAC-Adresse
Beispiel:
ifconfig hme0 ether 01:02:03:04:05:06
Unter Windows 2000 müssen Sie vor dem Starten des Executors eine Netzwerkkarte installiert und konfiguriert haben.
Das Betriebssystem AIX enthält einen Netzparameter für die automatische Erkennung der MTU, die auf einem Pfad transportiert werden kann. Stellt das Betriebssystem während einer Transaktion mit einem Client fest, dass es für ausgehende Pakete eine kleinere MTU (größte zu übertragende Einheit) verwenden muss, veranlasst die automatische Erkennung der MTU für einen Pfad AIX, eine Route zu erstellen, um sich diese Daten merken zu können. Die neue Route ist für diese spezielle Client-IP-Adresse bestimmt und zeichnet die für das Erreichen der Adresse erforderliche MTU auf.
Nachdem die Route erstellt wurde, könnte auf den Servern ein Problem auftreten, weil die Loopback-Einheit als Alias für den Cluster verwendet wird. Wenn die Gateway-Adresse für die Route in das Teilnetz des Clusters / der Netzmaske fällt, erstellt AIX die Route zur Loopback-Adresse. Der Grund hierfür ist, dass dies die letzte Schnittstelle (Alias) war, über die dieses Teilnetz erreicht wurde.
Wenn der Cluster beispielsweise 9.37.54.69 ist, die Netzmaske 255.255.255.0 lautet und das angestrebte Gateway 9.37.54.1 ist, verwendet AIX die Loopback-Adresse für die Route. Dadurch können die Antworten des Servers die Maschine nicht verlassen und der Client wartet bis zur Überschreitung des Zeitlimits. Normalerweise sieht der Client eine Antwort vom Cluster. Danach wird die Route erstellt und der Client empfängt keine weiteren Antworten.
Für dieses Problem gibt es zwei mögliche Lösungen.
Anmerkungen:
Windows 2000 stellt eine neue Funktion mit der Bezeichnung Task Offload bereit. Bei Anwendung dieser Funktion wird die TCP-Kontrollsumme nicht vom Betriebssystem, sondern von der Adapterkarte berechnet. Dies verbessert den Durchsatz des Systems. Bei aktiviertem Task Offload melden die Advisor-Funktionen von Network Dispatcher, dass Server inaktiv sind, obwohl sie tatsächlich aktiv sind.
Das Problem besteht darin, dass die TCP-Kontrollsumme für Pakete, die von der Cluster-Adresse kommen (was für den Advisor-Datenverkehr zutrifft) nicht richtig berechnet wird.
Sie können dieses Problem vermeiden, indem Sie die Einstellungen für die Adapterkarte aufrufen und Task Offload inaktivieren.
Erstmalig wurde dieses Problem beim ANA62044 QuadPort Adapter von Adaptec beobachtet. Bei dieser Adapterkarte hat die Funktion die Bezeichnung Transmit Checksum Offload. Umgehen Sie das Problem durch Inaktivieren von Transmit Checksum Offload.
Wenn Sie einen WAN-Dispatcher konfigurieren, müssen Sie den fernen Dispatcher auf Ihrem lokalen Dispatcher als Server in einem Cluster definieren. In der Regel werden Sie die NFA des fernen Dispatchers als Zieladresse des fernen Servers verwenden. Wenn Sie anschließend die Funktion für hohe Verfügbarkeit auf dem fernen Dispatcher konfigurieren, kann diese nicht ausgeführt werden. Der Grund hierfür ist, dass der lokale Dispatcher immer auf die primäre Maschine des fernen Standorts zeigt, wenn Sie für den Zugriff auf den fernen Server die NFA verwenden.
Sie können dieses Problem wie folgt umgehen:
Wenn der ferne primäre Dispatcher aktiviert wird, richtet er auf seinem Adapter einen Aliasnamen für diese Adresse ein, so dass die Adresse Datenverkehr akzeptieren kann. Tritt ein Fehler auf, wird die Adresse auf die Ausweichmaschine versetzt. Der weitere Datenverkehr für diese Adresse wird dann von der Ausweichmaschine akzeptiert.
Wenn Sie versuchen, eine große Konfigurationsdatei (im Schnitt mit mehr als 200 add-Befehlen) zu laden, kann die GUI blockieren oder ein unerwartetes Verhalten zeigen. Ein solches Verhalten wäre beispielsweise ein extrem langsames Reagieren auf Anzeigeänderungen.
Dieses Problem tritt auf, weil Java nicht auf so viel Speicher zugreifen kann, wie für die Bearbeitung einer so großen Änderung der GUI erforderlich ist.
Die Laufzeitumgebung bietet eine Option an, mit der der Java zur Verfügung stehende Speicherzuordnungspool vergrößert werden kann.
Die Option ist -Xmxn, bei der n die maximale Größe des Speicherzuordnungspools in Bytes angibt. Der Wert n muss ein Vielfaches von 1024 und größer als 2 MB sein. Nach dem Wert n können Sie k bzw. K für Kilobytes oder m bzw. M für Megabytes angeben. Zwei Beispiele für gültige Angaben sind -Xmx128M und -Xmx81920k. Der Standardwert ist 64 MB. Für SPARC-Plattformen mit Solaris 7 und Solaris 8 gilt ein Maximalwert von 4000m. Bei Plattformen mit Solaris 2.6 und x86 gilt ein Maximalwert von 2000m.
Fügen Sie diese Option hinzu, indem Sie wie folgt die Script-Datei ndadmin ändern:
START jrew -mx64m %END_ACCESS% %CONFIG_DIR% -DEND_INSTALL_PATH=%IBMNDPATH% -cp %NDCLASSPATH% com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode1
$JREDIR/$JRE -mx64m $END_ACCESS $CONFIG_DIR -DEND_INSTALL_PATH=/opt/&BASEDIR -cp $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode &1
re -mx64m $END_ACCESS $CONFIG_DIR $NDLOCALE -DEND_INSTALL_PATH=/opt/nd -classpath $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode 1>/dev/null 2>&1 &1
ava -mx64m $END_ACCESS $CONFIG_DIR $NDLOCALE -DEND_INSTALL_PATH=/usr/lpp/&BASEDIR -classpath $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode 1>/dev/null 2>&1 &
Für n wird kein bestimmter Wert empfohlen. Er sollte jedoch über dem Standardwert für die Option liegen. Ein guter Ausgangswert wäre das Zweifache des Standardwertes.
Dieses Problem kann auftreten, wenn eine andere Anwendung einen der Ports benutzt, die von CBR verwendet werden. Weitere Informationen enthält Port-Nummern für CBR überprüfen.
Der Befehl cbrcontrol gibt die Nachricht "Fehler: Server antwortet nicht" zurück, oder der Befehl ndadmin gibt die Nachricht "Fehler: Zugriff auf RMI-Server nicht möglich" zurück. Diese Fehler können auftreten, wenn der Stack Ihrer Maschine SOCKSifiziert ist. Um dieses Problem zu beheben, editieren Sie die Datei socks.cnf, damit sie die folgenden Zeilen enthält:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Derartige Fehler können auch auftreten, wenn Sie cbrserver noch nicht gestartet haben.
Anforderungen werden nicht verteilt, obwohl Caching Proxy und CBR gestartet wurden. Dieser Fehler kann auftreten, wenn Sie Caching Proxy vor dem Executor starten. Ist dies der Fall, enthält das Protokoll stderr für Caching Proxy die Fehlernachricht "ndServerInit: Keine Verbindung zum Executor möglich". Vermeiden Sie dieses Problem, indem Sie den Executor vor Caching Proxy starten.
Unter Solaris gibt der Befehl cbrcontrol executor start die Nachricht : "Fehler: Executor wurde nicht gestartet" zurück. Dieser Fehler tritt auf, wenn Sie die prozessübergreifende Kommunikation (IPC, Inter-process Communication) für das System nicht so konfigurieren, dass die maximale Größe eines gemeinsam benutzten Speichersegments und die Anzahl der gemeinsam benutzten Semaphor-IDs über dem Standardwert des Betriebssystems liegen. Wenn Sie das gemeinsam benutzte Speichersegment vergrößern und die Anzahl der gemeinsam benutzten Semaphor-IDs erhöhen möchten, müssen Sie die Datei /etc/system editieren. Weitere Informationen zum Konfigurieren dieser Datei finden Sie auf Seite ***.
Wenn der URL nicht funktioniert, kann dies an einem Syntax- oder Konfigurationsfehler liegen. Überprüfen Sie bei diesem Problem folgendes:
Dieser Fehler kann auftreten, wenn eine andere Anwendung einen der von Mailbox Locator verwendeten Ports benutzt. Weitere Informationen enthält Port-Nummern für Mailbox Locator überprüfen.
Auf einer UNIX-Plattform tritt dieser Fehler auf, mlserver zur die Verteilung einer großen Anzahl von IMAP/POP3-Client-Anforderungen verwendet wird und der Systemgrenzwert für Dateideskriptoren für die Anzahl der Anforderungen, die mlserver zu bedienen versucht, zu niedrig ist. Der mlserver erzeugt die folgende Ausnahmebedingung und wird dann gestoppt:
java.rmi.RMISecurityException: security.fd.read
Die protokollspezifische Proxy-Protokolldatei meldet folgendes:
SocketException=java.net.SocketException: Socket geschlossen
Lösen Sie dieses Problem, indem Sie den Grenzwert nofiles (AIX, Linux) oder open files in der Shell ändern, in der mlserver gestartet wird. Erhöhen Sie den Grenzwert für nofiles auf eine angemessene Zahl, die größer als der aktuelle Grenzwert für nofiles ist. Mit ulimit -a können Sie die aktuelle Begrenzung für nofiles anzeigen und mit ulimit -n Werte den Wert erhöhen.
Der Befehl mlcontrol gibt die Nachricht "Fehler: Server antwortet nicht" zurück, oder der Befehl ndadmin gibt die Nachricht "Fehler: Zugriff auf RMI-Server nicht möglich" zurück. Diese Fehler können auftreten, wenn der Stack Ihrer Maschine SOCKSifiziert ist. Um dieses Problem zu beheben, editieren Sie die Datei socks.cnf, damit sie die folgenden Zeilen enthält:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Derartige Fehler können auch auftreten, wenn Sie mlserver noch nicht gestartet haben.
Wenn Sie versuchen, einen Port zu einer Konfiguration hinzuzufügen, empfangen Sie unter Umständen die Nachricht Fehler: Port kann nicht hinzugefügt werden. Es ist möglich, dass bereits eine andere Anwendung an diesem Port empfangsbereit ist. Mailbox Locator versucht einen Proxy zu starten, der an die Cluster-IP-Adresse des im Befehl angegebenen Ports gebunden wird. Ist schon eine andere Anwendung an diese IP-Adresse gebunden oder für alle IP-Adressen dieses Ports empfangsbereit, kann der Proxy nicht gestartet werden. Wenn Sie Mailbox Locator an diesem Port verwenden möchten, müssen Sie die den Konflikt verursachende Anwendung stoppen.
Auf der Linux-Plattform kann der Dämon xinetd eine Listener-Funktion starten, ohne beispielsweise ein POP3-Programm auszuführen. Es ist deshalb wichtig, dass Sie mit netstat -a überprüfen, ob am gewünschten Port eine Anwendung empfangsbereit ist.
Für Mailbox Locator generiert der Befehl mlcontrol port add die Fehlernachricht "Der Proxy in Cluster <Cluster>, port <Port> wurde nicht gestartet". Das Problem kann gelöst werden, indem die Cluster-Adresse auf einer NIC konfiguriert wird, bevor der Proxy gestartet wird. Vergewissern Sie sich außerdem, dass an diesem Port keine andere Anwendung ausgeführt wird, die für die Cluster-Adresse empfangsbereit ist (dazu gehören auch alle generell empfangsbereiten Anwendungen).
Dieser Fehler kann auftreten, wenn eine andere Anwendung einen der von Site Selector verwendeten Ports benutzt. Weitere Informationen enthält Port-Nummern für Site Selector überprüfen.
Symptom: Site Selector gewichtet von Solaris-Clients eingehende Anforderungen nicht nach der RoundRobin-Methode.
Mögliche Ursache: Solaris-Systeme führen einen Namensservice-Cache-Dämon aus. Wenn dieser Dämon aktiv ist, wird die nächste Anfrage aus diesem Cache beantwortet, ohne dass Site Selector abgefragt wird.
Lösung: Schalten Sie den Namensserver-Cache-Dämon auf der Solaris-Maschine aus.
Der Befehl sscontrol gibt die Nachricht "Fehler: Server antwortet nicht" zurück, oder der Befehl ndadmin gibt die Nachricht "Fehler: Zugriff auf RMI-Server nicht möglich" zurück. Diese Fehler können auftreten, wenn der Stack Ihrer Maschine SOCKSifiziert ist. Um dieses Problem zu beheben, editieren Sie die Datei socks.cnf, damit sie die folgenden Zeilen enthält:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Derartige Fehler können auch auftreten, wenn Sie ssserver noch nicht gestartet haben.
Site Selector muss an einem DNS teilnehmen können. Alle zur Konfiguration gehörenden Maschinen sollten ebenfalls an diesem System teilnehmen. Unter Windows muss nicht immer der konfigurierte Host-Name im DNS enthalten sein. Site Selector wird nur ordnungsgemäß gestartet, wenn der Host-Name der Komponente im DNS definiert ist.
Prüfen Sie, ob dieser Host im DNS definiert ist. Editieren Sie die Datei ssserver.cmd und löschen Sie das "w" des Eintrags "javaw". Auf diese Weise erhalten Sie weitere Fehlernachrichten.
Der Namensserver von Site Selector wird an keine Adresse der Maschine gebunden. Er beantwortet alle Anfragen, die an gültige IP-Adressen auf der Maschine gerichtet sind. Site Selector verlässt sich darauf, dass das Betriebssystem die Anwort an den Client zurückgibt. Wenn die Site-Selector-Maschine mehrere Adapter enthält und eine beliebige Anzahl dieser Adapter mit demselben Teilnetz verbunden sind, sendet das Betriebssystem die Antwort an den Client unter Umständen von einer Adresse, die sich von der Adresse unterscheidet, an die der Client seine Anfrage gesendet hat. Einige Client-Anwendungen akzeptieren keine Antworten, die sie von einer Adresse empfangen, die sich von der Adresse unterscheidet, an die sie die Anfrage gesendet haben. Das erweckt den Anschein, als würde die Namensauflösung nicht funktionieren.
Dieser Fehler kann auftreten, wenn eine andere Anwendung einen Port verwendet, der vom lbcserver des Consultant verwendet wird. Weitere Informationen hierzu finden Sie im Abschnitt Port-Nummern für Cisco Consultant überprüfen.
Der Befehl lbccontrol gibt die Nachricht "Fehler: Server antwortet nicht" zurück, oder der Befehl ndadmin gibt die Nachricht "Fehler: Zugriff auf RMI-Server nicht möglich" zurück. Diese Fehler können auftreten, wenn der Stack Ihrer Maschine SOCKSifiziert ist. Um dieses Problem zu beheben, editieren Sie die Datei socks.cnf, damit sie die folgenden Zeilen enthält:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Derartige Fehler können auch auftreten, wenn Sie lbcserver noch nicht gestartet haben.
Dieses Problem kann auftreten, wenn eine gültige Produktlizenz fehlt. Wenn Sie versuchen, lbcserver zu starten, empfangen Sie die folgende Nachricht:
Ihre Lizenz ist abgelaufen. IBM Ansprechpartner oder autorisierten IBM Händler kontaktieren.
Sie können dieses Problem wie folgt lösen:
Für Metric Server unter Windows 2000 müssen Sie für benutzerdefinierte Messwerte den vollständigen Namen angeben. Anstelle von benutzermesswert müssten Sie beispielsweise benutzermesswert.bat angeben. Der Name benutzermesswert ist in der Befehlszeile gültig, funktioniert jedoch nicht bei Ausführung von einer Laufzeitumgebung aus. Wenn Sie nicht den vollständigen Namen des Messwertes verwenden, empfangen Sie eine Metric Server IOException. Setzen Sie in der metricserver-Befehlsdatei die Variable LOG_LEVEL auf den Wert 3 und überprüfen Sie die Protokollausgabe. In diesem Beispiel sieht die Ausnahmebedingung wie folgt aus:
... java.io.IOException: CreateProcess: usermetric error=2
Dafür, dass Metric Server keine Lastinformationen an Network Dispatcher meldet, kann es mehrere Gründe geben. Überprüfen Sie Folgendes, um die Ursache zu ermitteln:
Das Metric-Server-Protokoll enthält diese Fehlernachricht, nachdem Schlüsselringe zum Server übertragen wurden.
Dieser Fehler wird registriert, wenn der Schlüsselring aufgrund einer Beschädigung des Schlüsselpaares nicht autorisiert werden kann. Versuchen Sie wie folgt, diesen Fehler zu beheben:
Im Syntaxdiagramm wird gezeigt, wie ein Befehl angegeben wird, damit das Betriebssystem die Eingabe korrekt interpretieren kann. Lesen Sie das Syntaxdiagramm von links nach rechts und von oben nach unten entlang der horizontalen Linie (Hauptpfad).
In den Syntaxdiagrammen werden die folgenden Symbole benutzt:
Alle im Syntaxdiagramm aufgeführten Interpunktionszeichen, beispielsweise Doppelpunkte, Fragezeichen und Minuszeichen, müssen wie gezeigt übernommen werden.
In den Syntaxdiagrammen werden die folgenden Arten von Parametern benutzt:
Parameter werden als Schlüsselwörter oder Variablen klassifiziert. Schlüsselwörter werden in Kleinbuchstaben gezeigt und können in Kleinbuchstaben eingegeben werden. Ein Befehlsname ist beispielsweise ein Schlüsselwort. Variablen stehen in Kursivschrift und stellen Namen oder Werte dar, die von Ihnen zur Verfügung gestellt werden müssen.
In dem folgenden Beispiel ist der Befehl user ein Schlüsselwort. Die erforderliche Variable ist die Benutzer-ID und die optionale Variable das Kennwort. Ersetzen Sie die Variablen durch Ihre eigenen Werte.
>>-user--Benutzer-ID--+----------+----------------------------->< '-Kennwort-'
Erforderliche Schlüsselwörter: Erforderliche Schlüsselwörter und Variablen stehen im Hauptpfad.
>>-Erforderliches_Schlüsselwort--------------------------------><
Erforderliche Schlüsselwörter und Werte müssen eingegeben werden.
Sich gegenseitig ausschließende Parameter aus einer Gruppe auswählen: Sind mehrere Schlüsselwörter oder Variablen aufgeführt, die sich gegenseitig ausschließen und aus denen ein Schlüsselwort oder eine Variable ausgewählt werden muss, sind sie vertikal in alphanumerischer Anordnung aufgeführt.
>>-+-Erforderlicher_Parameter_1-+------------------------------>< '-Erforderlicher_Parameter_2-'
Optionale Werte: Optionale Schlüsselwörter und Variablen stehen unter dem Hauptpfad.
>>-+---------------+------------------------------------------->< '-Schlüsselwort-'
Sie können auswählen, ob sie optionale Schlüsselwörter oder Variablen angeben wollen oder nicht.
Optionale Schlüsselwörter oder Parameter aus einer Gruppe auswählen: Sind mehrere Schlüsselwörter oder Variablen aufgeführt, die sich gegenseitig ausschließen und aus denen ein Schlüsselwort oder eine Variable ausgewählt werden kann, sind sie vertikal in alphanumerischer Anordnung unter dem Hauptpfad aufgeführt.
>>-+-------------+--------------------------------------------->< +-Parameter_1-+ '-Parameter_2-'
Variablen: Wörter in Kursivschrift sind Variablen. Erscheint eine Variable in der Syntax, muss sie wie im Text angegeben durch einen ihrer erlaubten Namen oder Werte ersetzt werden.
>>-Variable----------------------------------------------------><
Zeichen, die keine alphanumerischen Zeichen sind: Enthält ein Diagramm ein Zeichen, das kein alphanumerisches Zeichen ist (beispielsweise einen Doppelpunkt, ein Anführungszeichen oder ein Minuszeichen), müssen Sie dieses Zeichen als Teil der Syntax angeben. Im folgenden Beispiel müssen Sie den Cluster und den Port im Format Cluster:Port angeben.
>>-Cluster:Port------------------------------------------------><
Dieser Anhang beschreibt die Verwendung der ndcontrol-Befehle von Dispatcher. Sie können diesen Anhang auch als Befehlsreferenz für CBR und Mailbox Locator verwenden. CBR und Mailbox Locator verwenden eine Untergruppe der Dispatcher-Befehle. Weitere Informationen hierzu finden Sie im Abschnitt Konfigurationsunterschiede bei CBR, Mailbox Locator und Dispatcher.
Nachfolgend sind die in diesem Anhang beschriebenen Befehle aufgelistet:
Sie können eine Minimalversion der Parameter für den Befehl "ndcontrol" eingeben. Sie müssen nur die eindeutigen Buchstaben der Parameter eingeben. Beispiel: Wenn Sie Hilfe für den Befehl zum Speichern von Dateien aufrufen möchten, können Sie ndcontrol he f anstelle von ndcontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl ndcontrol ab, um die Eingabeaufforderung "ndcontrol" aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Die Befehlszeilenschnittstelle von CBR und Mailbox Locator umfasst im Wesentlichen einen Teil der Befehlszeilenschnittstelle von Dispatcher. Verwenden Sie anstelle des Befehls "ndcontrol" zum Konfigurieren der Komponente den Befehl cbrcontrol (für die CBR-Komponente) oder den Befehl mlcontrol (für die Komponente Mailbox Locator).
Nachfolgend sind einige der Befehle aufgelistet, die in CBR ignoriert werden.
Nachfolgend sind einige der Befehle aufgelistet, die in Mailbox Locator ignoriert werden.
>>-ndcontrol--advisor--+-connecttimeout--Name--+-Port---------+--Zeitlimit_in_Sekunden-+->< | '-Cluster:Port-' | +-interval--Name--+-Port---------+--Sekunden--------------------+ | '-Cluster:Port-' | +-list----------------------------------------------------------+ +-loglevel--Name--+-Port---------+--Ebene-----------------------+ | '-Cluster:Port-' | +-logsize--Name--+-Port---------+--+-unlimited-------+----------+ | '-Cluster:Port-' '-Anzahl_Einträge-' | +-receivetimeout--Name--+-Port---------+--Zeitlimit_in_Sekunden-+ | '-Cluster:Port-' | +-report--Name--+-Port---------+--------------------------------+ | '-Cluster:Port-' | +-start--Name--+-Port---------+--+----------------+-------------+ | '-Cluster:Port-' '-Protokolldatei-' | +-status--Name--+-Port---------+--------------------------------+ | '-Cluster:Port-' | +-stop--Name--+-Port---------+----------------------------------+ | '-Cluster:Port-' | +-timeout--Name--+-Port---------+--+-unlimited-+----------------+ | '-Cluster:Port-' '-Sekunden--' | '-version--Name--+-Port---------+-------------------------------' '-Cluster:Port-'
Die Namen angepasster Advisor-Funktionen haben das Format xxxx, wobei ADV_xxxx der Name der Klasse ist, die die angepasste Advisor-Funktion implementiert. Weitere Informationen hierzu finden Sie im Abschnitt Kundenspezifische (anpassbare) Advisor-Funktion erstellen.
Der Cluster kann als Adresse in Schreibweise mit Trennzeichen oder als symbolischer Name angegeben werden. Der Port wird als Nummer des Ports angegeben, der von der Advisor-Funktion überwacht wird.
Advisor-Name | Protokoll | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | privat | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
ibmproxy | HTTP (über Caching Proxy) | 80 |
imap | IMAP | 143 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | privat | 12345 |
smtp | SMTP | 25 |
ssl | HTTP | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | privat | 10007 |
Die Standarddatei ist Advisor-Name_Port.log, z. B. http_80.log. Wollen Sie das Verzeichnis ändern, in dem die Protokolldateien gespeichert werden, lesen Sie die Informationen unter Pfade für die Protokolldatei ändern. Die Standardprotokolldateien für Cluster- oder sitespezifische Advisor-Funktionen werden mit der Cluster-Adresse erstellt, z. B. http_127.40.50.1_80.log.
Beispiele
ndcontrol advisor start http 127.40.50.1:80
ndcontrol advisor start http 88
ndcontrol advisor stop http 127.40.50.1:80
ndcontrol advisor connecttimeout http 80 30
ndcontrol advisor connecttimeout http 127.40.50.1:80 20
ndcontrol advisor interval ftp 21 6
ndcontrol advisor listDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
--------------------------------------- | ADVISOR | CLUSTER:PORT | ZEITLIMIT| --------------------------------------- | http |127.40.50.1:80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
ndcontrol advisor loglevel http 80 0
ndcontrol advisor logsize ftp 21 5000
ndcontrol advisor receivetimeout http 80 60
ndcontrol advisor report ftp 21Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Advisor-Bericht: --------------- Advisor-Name ............. Ftp Port-Nummer .............. 21 Cluster-Adresse .......... 9.67.131.18 Serveradresse ............ 9.67.129.230 Last ..................... 8 Cluster-Adresse .......... 9.67.131.18 Serveradresse ............ 9.67.131.215 Last ..................... -1
ndcontrol advisor status http 80Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Advisor-Status: --------------- Intervall (Sekunden) .................... 7 Zeitlimit (Sekunden) .................... unlimited Zeitlimit für Verbindung (Sekunden) ..... 21 Zeitlimit für Empfang (Sekunden) ........ 21 Advisor-Protokolldateiname .............. Http_80.log Protokollstufe .......................... 1 Maximale Managerprotokollgröße (Bytes)... unlimited
ndcontrol advisor timeout ftp 21 5
ndcontrol advisor version ssl 443Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Version: 04.00.00.00 - 07/12/2001-10:09:56-EDT
>>-ndcontrol--cluster--+-add--Cluster+C2+...--+---------------------------------------+-+->< | +-proportions--Aktiv--Neu--Port--System-+ | | +-maxports--Größe-----------------------+ | | +-maxservers--Größe---------------------+ | | +-stickytime--Zeit----------------------+ | | +-weightbound--Wertigkeit---------------+ | | +-porttype--Typ-------------------------+ | | +-primaryhost--Adresse------------------+ | | +-staletimeout--Inaktivitätszeitlimit---+ | | '-sharedbandwidth--Größe----------------' | +-set--Cluster+C2+...--+-maxports--Größe---------------------+---+ | +-maxservers--Größe-------------------+ | | +-stickytime--Zeit--------------------+ | | +-weightbound--Wertigkeit-------------+ | | +-porttype--Typ-----------------------+ | | +-primaryhost--Adresse----------------+ | | +-staletimeout--Inaktivitätszeitlimit-+ | | '-sharedbandwidth--Größe--------------' | +-remove--Cluster------------------------------------------------+ +-report--Cluster------------------------------------------------+ +-status--Cluster------------------------------------------------+ +-configure--Cluster--+--------------------------------+---------+ | '-Schnittstellenname - Netzmaske-' | '-unconfigure--Cluster-------------------------------------------'
Generell können Sie einen Doppelpunkt (:) als Platzhalter verwenden. Die einzige Ausnahme hiervon bildet der Befehl "ndcontrol cluster add". Der Befehl ndcontrol cluster set : weightbound 80 bewirkt beispielsweise, dass für alle Cluster eine Wertigkeit von 80 festgelegt wird.
Wird der primäre Host (primaryhost) eines Clusters geändert, nachdem die primäre Maschine und Partnermaschine bereits gestartet wurden, und ist die beiderseitige Hochverfügbarkeit aktiv, müssen Sie auch den neuen primären Host zur Übernahme zwingen. Außerdem müssen Sie die Scripts aktualisieren und den Cluster manuell aus der Konfiguration entfernen und dann richtig konfigurieren. Weitere Informationen hierzu finden Sie im Abschnitt Gegenseitige hohe Verfügbarkeit.
Beispiele
ndcontrol cluster add 130.40.52.153
ndcontrol cluster remove 130.40.52.153
ndcontrol cluster set 9.6.54.12 proportions 60 35 5 0
ndcontrol cluster add 0.0.0.0
ndcontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
ndcontrol cluster status 9.67.131.167Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Cluster-Status: --------------- Adresse ................................. 9.67.131.167 Anzahl Ziel-Ports ....................... 3 Standardhaltezeit ....................... 0 Strd.-Zeitlimit für Inaktivität ......... 30 Strd.-Gewichtungsgrenze für Port ........ 20 Max. Anzahl Ports ....................... 8 Strd.-Port-Protokoll .................... tcp/udp Strd. max. Anzahl Server ................ 32 Proportion für aktive Verbindungen ...... 0.5 Proportion für neue Verbindungen ........ 0.5 Port-spezifische Proportion ............. 0 Proportion für Systemmetrik ............. 0 Gemeinsame Bandbreite (KBytes) .......... 0 Adresse des primären Hosts .............. 9.67.131.167
>>-ndcontrol--executor--+-report---------------------------------------+->< +-set--+-nfa--IP-Adresse---------------------+-+ | +-maxclusters--Größe------------------+ | | +-maxports--Größe---------------------+ | | +-fincount--Zähler für BEENDET--------+ | | +-fintimeout--Zeitlimit für BEENDET---+ | | +-maxservers--Größe-------------------+ | | +-staletimeout--Inaktivitätszeitlimit-+ | | +-stickytime--Zeit--------------------+ | | +-clientgateway--Adresse--------------+ | | +-weightbound--Wertigkeit-------------+ | | +-porttype--Typ-----------------------+ | | +-wideportnumber--Port----------------+ | | '-sharedbandwidth--Größe--------------' | +-start----------------------------------------+ +-status---------------------------------------+ '-stop-----------------------------------------'
Beispiele
ndcontrol executor status Executor-Status: ---------------- NFA .................................... 9.67.131.151 Client-Gateway-Adresse ................. 0.0.0.0 Anzahl beendeter Verbindungen .......... 4.000 Zeitlimit beend. inakt. Verbindungen ... 60 Port-Nr. für Weitverkehrsnetz .......... 2.001 Gemeinsame Bandbreite (KBytes) ......... 0 Strd. max. Ports pro Cluster ........... 8 Max. Anzahl Cluster .................... 100 Strd. max. Anzahl Server pro Port ...... 32 Strd.-Zeitlimit für Port ............... 300 Haltezeit für Port ..................... 0 Gewichtungsgrenze für Port ............. 20 Max. Anzahl Cluster .................... 100
ndcontrol executor set nfa 130.40.52.167
ndcontrol executor set maxclusters 4096
ndcontrol executor start
ndcontrol executor stop
>>-ndcontrol--file--+-delete--Datei[.erw]----------+----------->< +-appendload--Datei[.erw]------+ +-report-----------------------+ +-save--Datei[.erw]--+-------+-+ | '-force-' | '-newload--Datei[.erw]---------'
Die Dateierweiterung (.erw) kann vom Benutzer festgelegt oder übergangen werden.
Allgemeiner Installationsverzeichnispfad -- c:\Programme\ibm\edge\nd\servers\configurations\Komponente
Interner Installationsverzeichnispfad -- c:\Programme\ibm\nd\servers\configurations\Komponente
Beispiele
ndcontrol file delete Datei3 Datei (Datei3) wurde gelöscht.
ndcontrol file newload Datei1.sv Datei (Datei1.sv) wurde in den Dispatcher geladen.
ndcontrol file appendload Datei2.sv Datei (Datei2.sv) wurde an die aktuelle Konfiguration angehängt und geladen.
ndcontrol file report DATEIBERICHT: Datei1.save Datei2.sv Datei3
ndcontrol file save Datei3 Die Konfiguration wurde in Datei (Datei3) gesichert.
>>-ndcontrol--help--+-help-------------+----------------------->< +-host-------------+ +-executor---------+ +-manager----------+ +-advisor----------+ +-cluster----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-subagent---------+ +-highavailability-+ +-file-------------+ +-set--------------+ +-status-----------+ '-log--------------'
Beispiele
ndcontrol helpDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
ARGUMENTE BEFEHL HELP: --------------------------------- Verwendung: help <Hilfeoption> Beispiel: help cluster help - vollständigen Hilfetext drucken advisor - Hilfe zum Befehl advisor cluster - Hilfe zum Befehl cluster executor - Hilfe zum Befehl executor file - Hilfe zum Befehl file host - Hilfe zum Befehl host log - Hilfe zum Befehl log manager - Hilfe zum Befehl manager metric - Hilfe zum Befehl metric port - Hilfe zum Befehl port rule - Hilfe zum Befehl rule server - Hilfe zum Befehl server set - Hilfe zum Befehl set status - Hilfe zum Befehl status subagent - Hilfe zum Befehl subagent highavailability - Hilfe zum Befehl highavailabilityParameter innerhalb von <> sind Variablen.
fintimeout <Cluster-Adresse>|all <Zeit> - Zeitlimit für beendete inaktive Verbindungen ändern (Verwenden Sie 'all', um alle Cluster zu ändern)
>>-ndcontrol--highavailability--+-status------------------------------------------+->< +-backup--+-add--+-primary-+--+-auto---+--P-+-----+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete--------------------------' | +-reach--+-add----+--Adresse--Maske---------------+ | '-delete-' | +-heartbeat--+-add--Quellenadresse--Zieladresse-+-+ | '-delete--Adresse------------------' | '-takeover--+---------+---------------------------' '-Adresse-'
Darüber hinaus gibt das Schlüsselwort status Informationen über verschiedene untergeordnete Status zurück:
Konfiguration mit beiderseitiger Hochverfügbarkeit (Rolle jeder Dispatcher-Maschine lautet both):
Anmerkungen:
Beispiele
ndcontrol highavailability status
Ausgabe:
Hochverfügbarkeitsstatus: ------------------------- Rolle ....................... primary Wiederanlaufstrategie ....... manual Status ...................... Aktiv Untergeordneter Status ...... Synchronisiert Primärer Host ............... 9.67.131.151 Port ........................ 12345 Bevorzugtes Ziel ............ 9.67.134.223 Signalstatus: ----------------- Anzahl ............... 1 Erreichbark.-Status: -------------------- Anzahl ............... 1
ndcontrol highavailability backup add primary auto 80
ndcontrol highavailability reach add 9.67.125.18
Primäre Maschine - highavailability heartbeat add 9.67.111.3 9.67.186.8 Partnermaschine - highavailability heartbeat add 9.67.186.8 9.67.111.3
ndcontrol highavailability takeover
>>-ndcontrol--host:--ferner_Host-------------------------------><
ndcontrol host:ferner_Host
Nachdem dieser Befehl in der Eingabeaufforderung ausgegeben wurde, geben Sie einen beliebigen gültigen Befehl ndcontrol ein, der für die ferne Network Dispatcher-Maschine ausgegeben werden soll.
>>-ndcontrol--log--+-start--------------------------------+---->< +-stop---------------------------------+ +-set--+-Aufbewahrungszeit - Stunden-+-+ | '---Intervall - Sekunden------' | '-status-------------------------------'
>>-ndcontrol--manager--+-interval--Sekunden-----------------------+->< +-loglevel--Stufe--------------------------+ +-logsize--+-unlimited-+-------------------+ | '-Bytes-----' | +-quiesce--Server--+-----+-----------------+ | '-now-' | +-reach set--+-Intervall - Sekunden------+-+ | '-+-Stufe für loglevel----+-' | | '---Größe für logsize---' | +-refresh--Aktualisierungszyklus-----------+ +-report--+----------------+---------------+ | '-Cluster+C2+...-' | +-restart--Nachricht-----------------------+ +-sensitivity--Wertigkeit------------------+ +-smoothing--Glättungsfaktor---------------+ +-start--+-----------------------------+---+ | '-Protokolldatei--Metric-Port-' | +-status-----------------------------------+ +-stop-------------------------------------+ +-unquiesce--Server------------------------+ '-version----------------------------------'
Wenn Sie die Serverpartitionierung verwenden, geben Sie den eindeutigen Namen des logischen Servers an. Weitere Informationen hierzu finden Sie im Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Die Standarddatei wird in dem Verzeichnis logs installiert. Lesen Sie hierzu die Informationen in Anhang F, Beispielkonfigurationsdateien. Wollen Sie das Verzeichnis ändern, in dem die Protokolldateien gespeichert werden, lesen Sie die Informationen unter Pfade für die Protokolldatei ändern.
Beispiele
ndcontrol manager interval 5
ndcontrol manager loglevel 0
ndcontrol manager logsize 1000000
ndcontrol manager quiesce 130.40.52.153
ndcontrol manager refresh 3
ndcontrol manager reportDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
---------------------------------- | HOST-TAB.VERZEI. | STATUS | ---------------------------------- | 9.67.129.221| AKTIV| | 9.67.129.213| AKTIV| | 9.67.134.223| AKTIV| ---------------------------------- ----------------------------------------------------------------------------------- | 9.67.131.18| GEWICHT | AKTIV % 48| NEU % 48 | PORT % 4 | SYSTEM % 0 | ----------------------------------------------------------------------------------- | PORT: 80 |DERZ| NEU |GW |VERBIND|GW |VERBIND | GW | LAST | GW | LAST | ----------------------------------------------------------------------------------- | 9.67.129.221| 8 | 8 | 10 | 0| 10 | 0 | 7 | 29 | 0 | 0| | 9.67.134.223| 11 | 11 | 10 | 0| 10 | 0 | 12 | 17 | 0 | 0| ----------------------------------------------------------------------------------- | PORT GESAMT | 19 | 19 | | 0| | 0 | | 46 | | 0| ----------------------------------------------------------------------------------- ----------------------------------------------------------------------------------- | 9.67.131.18| GEWICHT | AKTIV % 48| NEU % 48 | PORT % 4 | SYSTEM % 0 | ----------------------------------------------------------------------------------- | PORT: 23 |DERZ| NEU |GW |VERBIND|GW |VERBIND | GW | LAST | GW | LAST | ----------------------------------------------------------------------------------- | 9.67.129.213| 10 | 10 | 10 | 0| 10 | 0 | 10 | 71 | 0 | 0| | 9.67.134.223| 0 | 0 | 10 | 0| 10 | 0 |-9999 | -1 | 0 | 0| ----------------------------------------------------------------------------------- | PORT GESAMT | 10 | 10 | | 0| | 0 | | 70 | | 0| ----------------------------------------------------------------------------------- -------------------------------- | ADVISOR | PORT | ZEITLIMIT| -------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | --------------------------------
ndcontrol manager restart Neustart des Managers für Code-AktualisierungDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
320-14:04:54 Neustart des Managers für Code-Aktualisierung
ndcontrol manager sensitivity 10
ndcontrol manager smoothing 2,0
ndcontrol manager start ndmgr.log
ndcontrol manager statusDieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Manager-Status: ============= Port für Metrik ........................................ 10.004 Name der Managerprotokolldatei ......................... manager.log Managerprotokollstufe .................................. 1 Max. Managerprotokollgröße (Bytes) ..................... unlimited Sensitivitätsstufe ..................................... 0,05 Glättungsfaktor ........................................ 1,5 Aktualisierungsintervall (Sekunden) .................... 2 Gewichtungsaktualisierungszyklus ....................... 2 Erreichbarkeit - Protokollstufe ........................ 1 Erreichbarkeit - Max. Protokollgröße (Bytes) ........... unlimited Erreichbarkeit - Aktualisierungsintervall (Sekunden) ... 7
ndcontrol manager stop
ndcontrol manager quiesce 130.40.52.153 now
ndcontrol manager quiesce 130.40.52.153
ndcontrol manager unquiesce 130.40.52.153
ndcontrol manager version
>>-ndcontrol--metric--+-add--Cluster+C2+...+CN:Messwert+Messwert1+...+MesswertN--------+->< +-remove--Cluster+C2+...+CN:Messwert+Messwert1+...+MesswertN-----+ +-proportions--Cluster+C2+...+CN Proportion1 Prop2 Prop3...PropN-+ '-status--Cluster+C2+...+CN:Messwert+Messwert1+...+MesswertN-----'
Anmerkung: Bei Cisco Consultant entspricht die Cluster-Adresse der virtuellen IP-Adresse (VIP-Adresse) in der content-Regel des Eigners in der Konfiguration des Cisco CSS Switch.
Beispiele
sscontrol metric add Site1:Messwert1
sscontrol metric proportions Site1 0 100
sscontrol metric status Site1:Messwert1Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Metrikstatus: ------------ Cluster ....................... 10.10.10.20 Metrikname .................... Messwert1 Metrikproportion .............. 50 Server .................... plm3 Metrikdaten ............... -1
>>-ndcontrol--port--+-add--Cluster:Port--+-------------------------+-+->< | +-crossport--anderer_Port-+ | | +-maxservers--Größe-------+ | | +-stickymask--Wert--------+ | | +-stickytime--Zeit--------+ | | +-method--Typ-------------+ | | +-staletimeout--Wert------+ | | +-weightbound--Wertigkeit-+ | | +-porttype--Typ-----------+ | | '-protocol--Typ-----------' | +-set--Cluster:Port--+-crossport--anderer_Port-+-+ | +-maxservers--Größe-------+ | | +-stickymask--Wert--------+ | | +-stickytime--Zeit--------+ | | +-staletimeout--Wert------+ | | +-weightbound--Wertigkeit-+ | | +-porttype--Typ-----------+ | | '-maxhalfopen--Wert-------' | +-remove--Cluster:Port---------------------------+ +-report--Cluster:Port---------------------------+ +-status--Cluster:Port---------------------------+ '-halfopenaddressreport--Cluster:Port------------'
Unter Windows muss die Adresse in der Windows-Netzwerkkonfiguration enthalten sein. Der Befehl cluster configure reicht nicht aus, weil er die Aliasnamensumsetzung nur simuliert und der Proxy nicht an diese simulierte IP-Adresse gebunden werden kann. Für alle anderen Betriebssysteme ist der Befehl cluster configure ausreichend, weil er die IP-Adresse mit ifconfig in einen Aliasnamen umsetzt.
Wenn Sie die Port-übergreifende Affinität aufheben möchten, setzen Sie den Wert für crossport auf seine eigene Port-Nummer zurück. Weitere Informationen zur Port-übergreifenden Affinität finden Sie im Abschnitt Port-übergreifende Affinität.
Für die Dispatcher-Komponente:
Für die CBR-Komponente: Wenn Sie die Haltezeit (stickytime) für den Port auf einen Wert ungleich null setzen, muss der Affinitätstyp der Regel auf den Standard (none) gesetzt sein. Die regelbasierte Affinität (passive Cookie-Affinität, URI-Affinität, aktive Cookie-Affinität) kann nicht gleichzeitig festgelegt werden, wenn die Haltezeit für den Port gesetzt ist.
Ein positiver Wert gibt an, dass überprüft wird, ob die aktuelle Anzahl halboffener Verbindungen den Schwellenwert überschreitet. Wenn der aktuelle Wert über dem Schwellenwert liegt, wird ein Alert-Script aufgerufen. Weitere Informationen finden Sie im Abschnitt Erkennung von DoS-Attacken.
Beispiele
ndcontrol port add 130.40.52.153:80+23
ndcontrol port set 130.40.52.153:0
mlcontrol port add 9.37.60.91:20 protocol pop3
ndcontrol port set 130.40.52.153:80 weightbound 10
ndcontrol port set 130.40.52.153:80+23 stickytime 60
ndcontrol port set 130.40.52.153:80 crossport 23
ndcontrol port remove 130.40.52.153:23
ndcontrol port status 9.67.131.153:80Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Port-Status: ------------ Port-Nummer .................... 80 Cluster-Adresse ................ 9.67.131.153 Anzahl Server .................. 2 Zeitlimit für Inaktivität ...... 30 Gewichtungsgrenze .............. 20 Max. Anzahl Server ............. 32 Haltezeit ...................... 0 Port-Typ ....................... tcp/udp Weiterleitungsmethode........... MAC-gestützte Weiterleitung StickyBits der Maske ........... 32 Port-übergreifende Affinität ... 80 Max. Anz. halb geöffneter Verb. 0
ndcontrol port halfopenaddressreport 9.67.127.121:80Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Bericht zu halboffenen Verbindungen wurde erfolgreich erstellt. ------------ Adressenbericht zu halb geöffneten Verbindungen für Cluster:Port = 9.67.127.121:80 Summe Adressen mit halb geöffneten Verbindungen ....... 0 Gesamtanzahl halb geöffneter Verbindungen ............. 0 Größte Anzahl halb geöffneter Verbindungen ............ 0 Durchschnittliche Zahl halb geöffneter Verbindungen ... 0 Durchschnittl. Zeit für halb geöffnete Verb. (Sek.) ... 0 Summe empfangener halb geöffneter Verbindungen ........ 0
>>-ndcontrol--rule--+-add--Cluster:Port:Regel--type--Typ--| Optionen |-+->< +-dropserver--Cluster:Port:Regel--Server-----------+ +-remove--Cluster:Port:Regel-----------------------+ +-report--Cluster:Port:Regel-----------------------+ +-set--Cluster:Port:Regel--| Optionen |------------+ +-status--Cluster:Port:Regel-----------------------+ '-useserver--Cluster:Port:Regel--Server+S2+...-----' Optionen |--+-------------------------------------+----------------------| +-beginrange--Niedrig--endrange--Hoch-+ +-priority--Ebene---------------------+ +-pattern=--Muster--------------------+ +-tos--Wert---------------------------+ +-stickytime--Zeit--------------------+ +-affinity--Affinitätstyp-------------+ +-cookiename--Wert--------------------+ +-evaluate--Ebene---------------------+ '-sharelevel--Ebene-------------------'
Weitere Informationen hierzu finden Sie im Abschnitt Aktive Cookie-Affinität.
Der Affinitätstyp "activecookie" aktiviert eine Lastverteilung des Webdatenverkehrs mit Affinität an einen Server. Die Affinität basiert auf Cookies, die von Network Dispatcher generiert werden.
Der Affinitätstyp "passivecookie" aktiviert die Verteilung von Webdatenverkehr mit Affinität zu einem Server ausgehend von den Identifizierungs-Cookies, die von den Servern generiert werden. Für die passive Cookie-Affinität müssen Sie den Parameter "cookiename" verwenden.
Der Affinitätstyp "URI" aktiviert den Lastausgleich für Webdatenverkehr auf Caching-Proxy-Servern mit effektiver Vergrößerung des Cache.
Weitere Informationen hierzu finden Sie in den Abschnitten Aktive Cookie-Affinität, Passive Cookie-Affinität und URI-Affinität.
Weitere Informationen hierzu finden Sie im Abschnitt Passive Cookie-Affinität.
Wenn Sie die Serverpartitionierung verwenden, geben Sie den eindeutigen Namen des logischen Servers an. Weitere Informationen hierzu finden Sie im Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Beispiele
ndcontrol rule add 9.37.67.100:80:trule type true priority 100
ndcontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
ndcontrol rule add Cluster1:80:timerule type time beginrange 11 endrange 14 ndcontrol rule useserver Cluster1:80:timerule Server05
ndcontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
ndcontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
ndcontrol cluster set 9.67.131.153 sharedbandwidth 200 ndcontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-ndcontrol--server--+-add--Cluster:Port:Server--+-------------------------------+-+->< | +-Adresse--Adresse--------------+ | | +-collocated--Wert--------------+ | | +-sticky--Wert------------------+ | | +-weight--Wert------------------+ | | +-fixedweight--Wert-------------+ | | +-mapport--Port-Wert------------+ | | +-router--Adresse---------------+ | | +-cookievalue--Wert-------------+ | | +-returnaddress--Adresse--------+ | | +-advisorrequest--Zeichenfolge--+ | | '-advisorresponse--Zeichenfolge-' | +-set--Cluster:Port:Server--+-collocated--Wert--------------+-+ | +-sticky--Wert------------------+ | | +-weight--Wert------------------+ | | +-fixedweight--Wert-------------+ | | +-router--Adresse---------------+ | | +-cookievalue--Wert-------------+ | | +-advisorrequest--Zeichenfolge--+ | | '-advisorresponse--Zeichenfolge-' | +-down--Cluster:Port:Server-----------------------------------+ +-remove--Cluster:Port:Server---------------------------------+ +-report--Cluster:Port:Server---------------------------------+ +-up--Cluster:Port:Server-------------------------------------+ '-status--Cluster:Port:Server---------------------------------'
Wenn Sie einen eindeutigen Namen verwenden, der nicht in eine IP-Adresse aufgelöst wird, müssen Sie den Befehl ndcontrol server add mit dem Serverparameter address verwenden. Weitere Informationen hierzu finden Sie im Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Beispiele
ndcontrol server add 130.40.52.153:80:27.65.89.42
ndcontrol server set 130.40.52.153:80:27.65.89.42 sticky nein
ndcontrol server down 130.40.52.153:80:27.65.89.42
ndcontrol server remove ::27.65.89.42
ndcontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
ndcontrol server set 130.40.52.153:80:27.65.89.42 weight 10
ndcontrol server up 130.40.52.153:80:27.65.89.42
ndcontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
ndcontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/2.0\""
>>-ndcontrol--set--+-loglevel--Stufe--------+------------------>< +-logsize--+-unlimited-+-+ | '-Größe-----' | '-logstatus--------------'
>>-ndcontrol--status-------------------------------------------><
Beispiele
ndcontrol statusDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
Executor wurde gestartet. Manager wurde gestartet. -------------------------------- | ADVISOR | PORT | ZEITLIMIT| -------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | --------------------------------
>>-ndcontrol--subagent--+-loglevel--Stufe---------------------------------+->< +-logsize--+-Byte------+--------------------------+ | '-unlimited-' | +-report------------------------------------------+ +-start--+--------------------------------------+-+ | '-Benutzergemeinschaft--Protokolldatei-' | +-status------------------------------------------+ +-stop--------------------------------------------+ '-version-----------------------------------------'
Beispiele
ndcontrol subagent start bigguy bigguy.log
Dieser Anhang beschreibt die Syntax der content-Regel (des Musters) für die CBR-Komponente und die Weiterleitungsmethode "cbr" der Dispatcher-Komponente sowie Szenarien und Beispiele für ihre Verwendung.
Diese Angaben gelten nur, wenn Sie als Regeltyp "content" ausgewählt haben.
Beachten Sie bei der Syntax des gewünschten Musters die folgenden Einschränkungen:
Auf reservierte Schlüsselwörter folgt immer ein Gleichheitszeichen "=".
Ein Browser, der http://www.firma.com/pfad/webseite.htm aufruft, kann folgende Werte ergeben:
Method=GET URI=/pfad/webseite.htm Version=/HTTP/1.1 Host=www.firma.com Connection=Keep-Alive Referer=http://www.firma.com/pfad/elternwebseite.htm
Der folgende Befehl ist beispielsweise nur gültig, wenn die Eingabeaufforderung cbrcontrol>> verwendet wird.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern client=181.0.153.222&uri=http://10.1.203.4/nipoek/*
Wenn dieser Befehl mit Sonderzeichen an der Eingabeaufforderung des Betriebssystems funktionieren soll, müssen Sie den pattern-Wert wie folgt in Anführungszeichen (" ") setzen:
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "client=181.0.153.222&uri=http://10.1.203.4/nipoek/*"
Fehlen die Anführungszeichen, könnte beim Speichern der Regel in CBR ein Teil des Musters abgeschnitten werden. An der Eingabeaufforderung "cbrcontrol>>" wird die Verwendung von Anführungszeichen nicht unterstützt.
Nachfolgend finden Sie eine Zusammenstellung möglicher Szenarien und Beispiele für die Mustersyntax.
Szenario 1:
Zur Konfiguration für einen Cluster-Namen gehört eine Gruppe von Webservern für standardmäßigen HTML-Inhalt, eine weitere Gruppe von Webservern mit WebSphere Application Server für Servlet-Anforderungen, eine dritte Gruppe von Lotus-Notes-Servern für NSF-Dateien usw. Der Zugriff auf die Client-Daten ist erforderlich, um zwischen den angeforderten Seiten unterscheiden zu können. Die Daten müssen außerdem an die jeweils geeigneten Server gesendet werden. Die Erkennungsregeln für das content-Muster ermöglichen die für diese Tasks notwendige Trennung. Es wird eine Reihe von Regeln konfiguriert, die die nötige Trennung der Anforderungen automatisch vornehmen. Mit den folgenden Befehlen können Sie die genannte Trennung in drei Gruppen erreichen:
>>rule add Cluster1:80:servlets type content pattern uri=*/servlet/* priority 1 >>rule uses Cluster1:80:servlets Server1+Server2
>>rule add Cluster1:80:notes type content pattern uri=*.nsf* priority 2 >>rule uses Cluster1:80:notes Server3+Server4
>>rule add Cluster1:80:regular type true priority 3 >>rule uses Cluster1:80:regular Server5+Server6
Wenn Network Dispatcher eine Anforderung für eine NSF-Datei empfängt, wird zuerst die servlets-Regel angewendet, bei der jedoch keine Übereinstimmung gefunden wird. Anschließend wird die Anforderung mit der notes-Regel abgeglichen und eine Übereinstimmung festgestellt. Die Client-Daten werden auf Server3 und Server4 verteilt.
Szenario 2
Ein weiteres allgemeines Szenario ist die Steuerung unterschiedlicher interner Gruppen durch die Hauptwebsite. Beispiel: www.firma.com/software bezieht verschiedene Server und Inhalte aus dem Bereich www.firma.com/hardware ein. Da alle Anforderungen vom Root-Cluster www.firma.com ausgehen, sind content-Regeln erforderlich, um die URI-Unterscheidung für den Lastausgleich vorzunehmen. Die Regel für dieses Szenario würde etwa wie folgt aussehen:
>>rule add Cluster1:80:Bereich1 type content pattern uri=/software/* priority 1 >>rule uses Cluster1:80:Bereich1 Server1+Server2
>>rule add Cluster1:80:Bereich2 type content pattern uri=/hardware/* priority 2 >>rule uses Cluster1:80:Bereich2 Server3+Server4
Szenario 3
Bei bestimmten Kombinationen ist die Reihenfolge wichtig, in der die Regeln durchsucht werden. Im Szenario 2 wurden die Clients beispielsweise ausgehend von einem Verzeichnis in ihrem Anforderungspfad aufgeteilt. Der Zielverzeichnispfad kann jedoch auf verschiedenen Ebenen dieses Pfades vorhanden sein und dort jeweils zu anderen Ergebnissen führen. So ist das Ziel www.firma.com/pcs/fixes/software beispielsweise von www.firma.com/mainframe/fixes/software verschieden. Die Regeln müssen dieser Möglichkeit Rechnung tragen und so konfiguriert werden, dass die nicht zu vielen Szenarien gleichzeitig gerecht werden. Die Platzhaltersuche "uri=*/software/*" wäre in diesem Falle zu breit angelegt. Alternative Regeln könnten wie folgt strukturiert sein:
Mit einer kombinierten Suche kann hier eine Eingrenzung vorgenommen werden:
>>rule add Cluster1:80:pcs type content pattern (uri=/pcs/*)&(uri=*/software/*) >>rule uses Cluster 1:80:pcs Server1
In Fällen, wo keine Kombinationen anwendbar sind, ist die Reihenfolge wichtig:
>>rule add Cluster1:80:pc1 type content pattern uri=/pcs/* >>rule uses Cluster1:80:pc1 Server2
Die zweite Regel wird angewendet, wenn "pcs" im Verzeichnis nicht an erster Stelle, sondern an einer späteren Stelle erscheint.
>>rule add Cluster1:80:pc2 type content pattern uri=/*/pcs/* >>rule uses Cluster1:80:pc2 Server3
In fast allen Fällen sollten Sie die Regeln durch eine Standardregel always true ergänzen, die für alles gelten, was nicht unter die übrigen Regeln fällt. In Szenarien, in denen alle Server für einen bestimmten Client nicht in Frage kommen, könnte dies auch ein Server mit der Antwort "Die Site ist derzeit nicht verfügbar, versuchen Sie es später erneut" sein.
>>rule add Cluster1:80:sorry type true priority 100 >>rule uses Cluster1:80:sorry Server5
Dieser Anhang beschreibt die Verwendung der folgenden sscontrol-Befehle für Site Selector:
Sie können eine Minimalversion der Parameter für den Befehl "sscontrol" eingeben. Sie müssen nur die eindeutigen Buchstaben der Parameter eingeben. Beispiel: Wenn Sie Hilfe für den Befehl zum Speichern von Dateien aufrufen möchten, können Sie sscontrol he f anstelle von sscontrol help file eingeben.
>>-sscontrol--advisor--+-connecttimeout--Name--+-Port----------+--Sekunden------+->< | '-Sitename:Port-' | +-interval--Name--+-Port----------+--Sekunden------------+ | '-Sitename:Port-' | +-list---------------------------------------------------+ +-loglevel--Name--+-Port----------+--Stufe---------------+ | '-Sitename:Port-' | +-logsize--Name--+-Port----------+--+-size | ----------+-+ | '-Sitename:Port-' '-Bytes------------' | +-receivetimeout--Name--+-Port----------+--Sekunden------+ | '-Sitename:Port-' | +-report--Name--+-Port----------+------------------------+ | '-Sitename:Port-' | +-start--Name--+-Port----------+--+----------------+-----+ | '-Sitename:Port-' '-Protokolldatei-' | +-status--Name--+-Port----------+------------------------+ | '-Sitename:Port-' | +-stop--Name--+-Port----------+--------------------------+ | '-Sitename:Port-' | +-timeout--Name--+-Port----------+-----------------------+ | '-Sitename:Port-' | '-version--Name--+-Port----------+--Sekunden-------------' '-Sitename:Port-'
Advisor-Name | Protokoll | Port |
---|---|---|
Connect | nicht anwendbar | benutzerdefiniert |
db2 | privat | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
imap | IMAP | 143 |
nntp | NNTP | 119 |
PING | PING | 0 |
pop3 | POP3 | 110 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
Die Standarddatei ist Advisor-Name_Port.log, z. B. http_80.log. Informationen zum Ändern des Verzeichnisses, in dem Protokolldateien gespeichert werden, finden Sie im Abschnitt Pfade für die Protokolldatei ändern.
Sie können nur eine Advisor-Funktion pro Sitenamen starten.
Beispiele
sscontrol advisor connecttimeout http 80 30
sscontrol advisor interval ftp 21 6
sscontrol advisor listDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
--------------------------------------- | ADVISOR | SITENAME:PORT | ZEITLIMIT | --------------------------------------- | http | 80 |unlimited | | ftp | 21 |unlimited | ---------------------------------------
sscontrol advisor loglevel http meineSite:80 0
sscontrol advisor logsize ftp meineSite:21 5000
sscontrol advisor receivetimeout http 80 60
sscontrol advisor report ftp 21Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Advisor-Bericht: --------------- Advisor-Name ............. http Port-Nummer .............. 80 Sitename ................. meineSite Serveradresse ............ 9.67.129.230 Last ..................... 8
sscontrol advisor start ftp 21 ftpadv.log
sscontrol advisor status http 80Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Advisor-Status: --------------- Intervall (Sekunden) .................... 7 Zeitlimit (Sekunden) .................... unlimited Zeitlimit für Verbindung (Sekunden) ..... 21 Zeitlimit für Empfang (Sekunden) ........ 21 Advisor-Protokolldateiname .............. Http_80.log Protokollstufe .......................... 1 Maximale Managerprotokollgröße (Bytes)... unlimited
sscontrol advisor stop http 80
sscontrol advisor timeout ftp 21 5
sscontrol advisor version ssl 443
>>-sscontrol--file--+-delete--Dateiname.erw----------+--------->< +-appendload--Dateiname.erw------+ +-report-------------------------+ +-save--Dateiname.erw--+-------+-+ | '-force-' | '-newload--Dateiname.erw---------'
Die Dateierweiterung (.erw) ist optional und kann beliebig gewählt werden.
Allgemeiner Installationsverzeichnispfad -- c:\Programme\ibm\edge\nd\servers\configurations\Komponente
Interner Installationsverzeichnispfad -- c:\Programme\ibm\nd\servers\configurations\Komponente
Beispiele
sscontrol file delete Datei3 Datei (Datei3) wurde gelöscht.
sscontrol file newload Datei1.sv Datei (Datei1.sv) wurde in den Dispatcher geladen.
sscontrol file appendload Datei2.sv Datei (Datei2.sv) wurde an die aktuelle Konfiguration angehängt und geladen.
sscontrol file report DATEIBERICHT: Datei1.save Datei2.sv Datei3
sscontrol file save Datei3 Die Konfiguration wurde in Datei (Datei3) gesichert.
>>-sscontrol--help--+-advisor----+----------------------------->< +-file-------+ +-help-------+ +-host-------+ +-manager----+ +-metric-----+ +-nameserver-+ +-rule-------+ +-server-----+ +-set--------+ +-sitename---+ '-status-----'
Beispiele
sscontrol helpDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
ARGUMENTE BEFEHL HELP: --------------------------------- Verwendung: help <Hilfeoption> Beispiel: help name help - vollständigen Hilfetext drucken advisor - Hilfe zum Befehl advisor file - Hilfe zum Befehl file host - Hilfe zum Befehl host manager - Hilfe zum Befehl manager metric - Hilfe zum Befehl metric sitename - Hilfe zum Befehl sitename nameserver - Hilfe zum Befehl nameserver rule - Hilfe zum Befehl rule server - Hilfe zum Befehl server set - Hilfe zum Befehl set status - Hilfe zum Befehl statusParameter innerhalb von < > sind Variablen.
logsize <Bytezahl | unlimited> -Maximale Anzahl Bytes für Protokolldatei festlegen
>>-sscontrol--manager--+-interval--Sekunden-----------------------------------+->< +-loglevel--Stufe--------------------------------------+ +-logsize--+-size | unlimited-+------------------------+ | '-Bytes------------' | +-reach set--+-Intervall - Sekunden------------------+-+ | '-+-Stufe für loglevel----------------+-' | | '---Größe für logsize | unlimited---' | +-report--Sitename+Sn2+...+SnN-------------------------+ +-restart--Nachricht-----------------------------------+ +-sensitivity--Wertigkeit------------------------------+ +-smoothing--Glättungsfaktor---------------------------+ +-start--+-----------------------------+---------------+ | '-Protokolldatei--Metric-Port-' | +-status-----------------------------------------------+ +-stop-------------------------------------------------+ '-version----------------------------------------------'
Die Standarddatei ist im Verzeichnis logs installiert. Lesen Sie hierzu die Informationen in Anhang F, Beispielkonfigurationsdateien. Wollen Sie das Verzeichnis ändern, in dem die Protokolldateien gespeichert werden, lesen Sie die Informationen unter Pfade für die Protokolldatei ändern.
Beispiele
sscontrol manager interval 5
sscontrol manager loglevel 0
sscontrol manager logsize 1000000
sscontrol manager reportDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
---------------------------------- | SERVER | STATUS | ---------------------------------- | 9.67.129.221| AKTIV | | 9.67.129.213| AKTIV | | 9.67.134.223| AKTIV | ---------------------------------- ----------------------------- |LEGENDE ZUM MANAGERBERICHT | ----------------------------- | CPU | CPU-Last | | MEM | Speicherlast | | SYS | Systemmetrik | |JETZT | Aktuelle Gewichtung| | NEU | Neue Gewichtung | |GWT | Gewichtung | ----------------------------- ------------------------------------------------------------------------ | meineSite | GWT | CPU 49 % | MEM 50 % | PORT 1 % | SYS 0 % | ------------------------------------------------------------------------ | |JETZT NEU |GWT LAST |GWT LAST |GWT LAST |GWT LAST | ------------------------------------------------------------------------ | 9.37.56.180 | 10 10 |-99 -1|-99 -1|-99 -1| 0 0| ------------------------------------------------------------------------ | SUMMEN:| 10 10 | -1| -1| -1| 0| ------------------------------------------------------------------------ ----------------------------------------- | ADVISOR | SITENAME:PORT | ZEITLIMIT | ----------------------------------------- | http | 80 | unlimited | -----------------------------------------
sscontrol manager restart Neustart des Managers für CodeaktualisierungDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
320-14:04:54 Neustart des Managers für Codeaktualisierung
sscontrol manager sensitivity 10
sscontrol manager smoothing 2.0
sscontrol manager start ndmgr.log
sscontrol manager statusDieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Manager-Status: ============= Metrik-Port ............................................ 10004 Name der Managerprotokolldatei ......................... manager.log Managerprotokollstufe .................................. 1 Max. Managerprotokollgröße (Bytes) ..................... unlimited Sensitivitätsstufe ..................................... 5 Glättungsfaktor ........................................ 1,5 Aktualisierungsintervall (Sekunden) .................... 2 Gewichtungsaktualisierungszyklus ....................... 2 Erreichbarkeit - Protokollstufe ........................ 1 Erreichbarkeit - Max. Protokollgröße (Bytes) ........... unlimited Erreichbarkeit - Aktualisierungsintervall (Sekunden) ... 7
sscontrol manager stop
sscontrol manager version
>>-sscontrol--metric--+-add--Sitename+Sn2+...+SnN:Messwert+Messwert1+...+MesswertN--------+->< +-remove--Sitename+Sn2+...+SnN:Messwert+Messwert1+...+MesswertN-----+ +-proportions--Sitename+Sn2+...+SnN:Proportion1 Prop2 Prop3...PropN-+ '-status--Sitename+Sn2+...+SnN Messwert+Messwert1+...+MesswertN-----'
Beispiele
sscontrol metric add Site1:Messwert1
sscontrol metric proportions Site1 0 100
sscontrol metric status Site1:Messwert1Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Metrikstatus: ------------ Sitename ..................... Site1 Metrikname .................... Messwert1 Metrikproportion .............. 50 Server ......... 9.37.56.100 Metrikdaten .... -1
>>-sscontrol--nameserver--+-start--+----------------------+-+-->< | '-bindaddress--Adresse-' | +-stop----------------------------+ '-status--------------------------'
>>-sscontrol--rule--+-add--Sitename+Sn2+...+SnN:Regel+Regel2+...+RegelN--type--Wert--| Wert |--| Optionen |-+->< +-dropserver--Sitename+Sn2+...+SnN:Regel+Regel2+...+RegelN--Server+S2+...+SnN-----------+ +-remove--Sitename+Sn2+...+SnN:Regel+Regel2+...+RegelN----------------------------------+ +-set--Sitename+Sn2+...+SnN:Regel+Regel2+...+RegelN--| Wert |--| Optionen |-------------+ +-status--Sitename+Sn2+...+SnN:Regel+Regel2+...+RegelN----------------------------------+ '-useserver--Sitename+Sn2+...+SnN:Regel+Regel2+...+RegelN--Server+S2+...+SnN------------' Optionen |--+-------------------------------------+----------------------| +-beginrange--Niedrig--endrange--Hoch-+ +-priority--Wert----------------------+ '-metricname--Wert--------------------'
Beispiele
sscontrol rule add Sitename:Regelname type true priority 100
sscontrol rule add Sitename:Regelname type ip b 9.0.0.0 e 9.255.255.255
sscontrol rule add Sitename:Regelname type time beginrange 11 endrange 14 sscontrol rule useserver Sitename:Regelname Server05
>>-sscontrol--server--+-add--Sitename+Sn2+...+SnN:Server+Server2+...+ServerN--+------------------------+-+->< | +-metricaddress--Adresse-+ | | '-weight--Wert-----------' | +-down--Sitename+Sn2+...+SnN:Server+Server2+...+ServerN----------------------------+ +-remove--Sitename+Sn2+...+SnN:Server+Server2+...+ServerN--------------------------+ +-set--Sitename+Sn2+...+SnN:Server+Server2+...+ServerN--+------------------------+-+ | +-metricaddress--Adresse-+ | | '-weight--Wert-----------' | +-status--Sitename+Sn2+...+SnN:Server+Server2+...+ServerN--------------------------+ '-up--Sitename+Sn2+...+SnN:Server+Server2+...+ServerN------------------------------'
Beispiele
sscontrol server add Site1:27.65.89.42
sscontrol server down Site1:27.65.89.42
sscontrol server remove :27.65.89.42
sscontrol server up Site1:27.65.89.42
>>-sscontrol--set--+-loglevel--Stufe--------+------------------>< +-logsize--+-unlimited-+-+ | '-Größe-----' | '-logstatus--------------'
>>-sscontrol--sitename--+-add--Sitename+Sn2+...+SnN--+--------------------------------------------+-+->< | +-cachelife--Wert----------------------------+ | | +-networkproximity--yes | no-----------------+ | | +-proportions--CPU--Speicher--Port--Messwert-+ | | +-proximitypercentage--Wert------------------+ | | +-stickytime--Zeit---------------------------+ | | +-ttl--Zeit----------------------------------+ | | +-waitforallresponses--yes | no--------------+ | | '-weightbound--Wertigkeit--------------------' | +-remove--Sitename+Sn2+...+SnN----------------------------------------------+ +-set--Sitename+Sn2+...+SnN--+--------------------------------------------+-+ | +-cachelife--Wert----------------------------+ | | +-networkproximity--yes | no-----------------+ | | +-proportions--CPU--Speicher--Port--Messwert-+ | | +-proximitypercentage--Wert------------------+ | | +-stickytime--Zeit---------------------------+ | | +-ttl--Zeit----------------------------------+ | | +-waitforallresponses--yes | no--------------+ | | '-weightbound--Wertigkeit--------------------' | '-status--Sitename+Sn2+...+SnN----------------------------------------------'
Beispiele
sscontrol sitename add 130.40.52.153
sscontrol sitename set meineSite networkproximity yes
sscontrol sitename set meineSite cachelife 1900000
sscontrol sitename set meineSeite proximitypercentage 45
sscontrol sitename set meineSite waitforallresponses no
sscontrol sitename set meineSite ttl 7
sscontrol sitename set meineSite proportions 50 48 1 1
sscontrol sitename remove 130.40.52.153
sscontrol sitename status meineSiteDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
Status des Sitenamens: --------------- Sitename ........................... meineSite Gewichtungsgrenze .................. 20 TTL ................................ 5 Haltezeit .......................... 0 Anzahl Server ...................... 1 Proportion für CpuLoad ............. 49 Proportion für MemLoad ............. 50 Proportion für Port ................ 1 Proportion für Systemmetrik ........ 0 Advisor am Port .................... 80 Verwendete Proximität .............. N
>>-sscontrol--status-------------------------------------------><
Beispiele
sscontrol statusDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
Namensserver wurde gestartet. Manager wurde gestartet. ----------------------------------------- | ADVISOR | SITENAME:PORT | ZEITLIMIT | ---------------------------------------- | http | 80 | unlimited | -----------------------------------------
Dieser Anhang beschreibt die Verwendung der folgenden lbccontrol-Befehle für Consultant für Cisco CSS Switches:
Sie können eine Minimalversion der Parameter für den Befehl "ndcontrol" eingeben. Sie müssen nur die eindeutigen Buchstaben der Parameter eingeben. Beispiel: Wenn Sie Hilfe für den Befehl zum Speichern von Dateien aufrufen möchten, können Sie lbccontrol he f anstelle von lbccontrol help file eingeben.
Der Präfix "lbc" weist auf den Lastausgleich für Consultant hin.
>>-lbccontrol--advisor--+-connecttimeout--Name--+-Port---------+--Zeitlimit_in_Sekunden-+->< | '-Cluster:Port-' | +-interval--Name--+-Port---------+--Sekunden--------------------+ | '-Cluster:Port-' | +-list----------------------------------------------------------+ +-loglevel--Name--+-Port---------+--Stufe-----------------------+ | '-Cluster:Port-' | +-logsize--+-Port---------+--Port--+-size | unlimited-+---------+ | '-Cluster:Port-' '-Bytes------------' | +-receivetimeout--Name--+-Port---------+--Zeitlimit_in_Sekunden-+ | '-Cluster:Port-' | +-report--Name--+-Port---------+--------------------------------+ | '-Cluster:Port-' | +-start--Name--+-Port---------+--+----------------+-------------+ | '-Cluster:Port-' '-Protokolldatei-' | +-status--Name--+-Port---------+--------------------------------+ | '-Cluster:Port-' | +-stop--Name--+-Port---------+----------------------------------+ | '-Cluster:Port-' | +-timeout--Name--+-Port---------+--+-seconds | unlimited-+------+ | '-Cluster:Port-' '-Sekunden------------' | '-version--Name--+-Port---------+-------------------------------' '-Cluster:Port-'
Advisor-Name | Protokoll | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | privat | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
ibmproxy | HTTP (über Caching Proxy) | 80 |
imap | IMAP | 143 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | privat | 10007 |
Die Standarddatei ist Advisor-Name_Port.log, z. B. http_80.log. Wollen Sie das Verzeichnis ändern, in dem die Protokolldateien gespeichert werden, lesen Sie die Informationen unter Pfade für die Protokolldatei ändern.
Legen Sie die Manager-Proportionen fest, um sicherzustellen, dass die Advisor-Informationen verwendet werden.
Beispiele
lbccontrol advisor connecttimeout http 80 30
lbccontrol advisor interval ftp 21 6
lbccontrol advisor listDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
------------------------------ | ADVISOR | PORT | ZEITLIMIT| ------------------------------ | http | 80 | unlimited | | ftp | 21 | unlimited | ------------------------------
lbccontrol advisor loglevel http 80 0
lbccontrol advisor logsize ftp 21 5000
lbccontrol advisor receivetimeout http 80 60
lbccontrol advisor report ftp 21Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Advisor-Bericht: --------------- Advisor-Name ............. Ftp Port-Nummer .............. 21 Cluster-Adresse .......... 9.67.131.18 Serveradresse ............ 9.67.129.230 Last ..................... 8 Cluster-Adresse .......... 9.67.131.18 Serveradresse ............ 9.67.131.215 Last ..................... -1
lbccontrol advisor start ftp 21 ftpadv.log
lbccontrol advisor status http 80Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Advisor-Status: --------------- Intervall (Sekunden) .................... 15 Zeitlimit (Sekunden) .................... unlimited Zeitlimit für Verbindung (Sekunden) ..... 21 Zeitlimit für Empfang (Sekunden) ........ 21 Advisor-Protokolldateiname .............. Http_80.log Protokollstufe .......................... 1 Maximale Managerprotokollgröße (Bytes)... unlimited
lbccontrol advisor stop http 80
lbccontrol advisor timeout ftp 21 5
lbccontrol advisor version ssl 443
>>-lbccontrol--cluster--+-add--Cluster+C2+...--+-proportions--Aktiv--Neu--Port--System-+-+->< | '-weightbound--Wertigkeit---------------' | +-set--Cluster+C2+...--+-proportions--Aktiv--Neu--Port--System-+-+ | '-weightbound--Wertigkeit---------------' | +-remove--Cluster------------------------------------------------+ '-status--Cluster------------------------------------------------'
Beispiele
lbccontrol cluster add 130.40.52.153
lbccontrol cluster remove 130.40.52.153
lbccontrol cluster proportions 60 35 5 0
lbccontrol cluster status 9.67.131.167Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Cluster-Status: --------------- Adresse ................................. 9.67.131.167 Anzahl Ziel-Ports ....................... 3 Strd.-Gewichtungsgrenze für Port ........ 10 Proportion für aktive Verbindungen ...... 49 Proportion für neue Verbindungen ........ 49 Port-spezifische Proportion ............. 2 Proportion für Systemmetrik ............. 0
>>-lbccontrol--executor--+-set--+-address--Wert-------+-+------>< | +-communityname--Wert-+ | | +-timeout--Wert-------+ | | '-retries--Wert-------' | '-status-----------------------'
Beispiele
lbccontrol executor status Executor-Status: ---------------- Adresse ............................. 9.67.131.151 Community-Name ...................... public Zeitlimitwert ....................... 3 Anzahl Wiederholungen ............... 2
lbccontrol executor set address 130.40.52.167
>>-lbccontrol--file--+-delete--Dateiname.erw-------------+----->< +-appendload--Dateiname.erw---------+ +-report----------------------------+ +-save--Dateiname.erw--force--------+ '-newload--Dateiname.erw--+-------+-' '-force-'
Die Dateierweiterung (.erw) ist optional und kann beliebig gewählt werden.
Allgemeiner Installationsverzeichnispfad -- c:\Programme\ibm\edge\nd\servers\configurations\Komponente
Interner Installationsverzeichnispfad -- c:\Programme\ibm\nd\servers\configurations\Komponente
Beispiele
lbccontrol file delete Datei3 Datei (Datei3) wurde gelöscht.
lbccontrol file newload Datei1.sv Datei (Datei1.sv) wurde in den Dispatcher geladen.
lbccontrol file appendload Datei2.sv Datei (Datei2.sv) wurde an die aktuelle Konfiguration angehängt und geladen.
lbccontrol file report DATEIBERICHT: Datei1.save Datei2.sv Datei3
lbccontrol file save Datei3 Die Konfiguration wurde in Datei (Datei3) gesichert.
>>-lbccontrol--help--+-advisor--+------------------------------>< +-cluster--+ +-executor-+ +-file-----+ +-help-----+ +-host-----+ +-log------+ +-manager--+ +-metric---+ +-port-----+ +-server---+ +-set------+ '-status---'
Beispiele
lbccontrol helpDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
ARGUMENTE BEFEHL HELP: --------------------------------- Verwendung: help <Hilfeoption> Beispiel: help cluster executor - Hilfe zum Befehl executor cluster - Hilfe zum Befehl cluster port - Hilfe zum Befehl port server - Hilfe zum Befehl server manager - Hilfe zum Befehl manager metric - Hilfe zum Befehl metric advisor - Hilfe zum Befehl advisor file - Hilfe zum Befehl file host - Hilfe zum Befehl host log - Hilfe zum Befehl log set - Hilfe zum Befehl set status - Hilfe zum Befehl status help - vollständigen Hilfetext druckenParameter innerhalb von < > sind Variablen.
>>-lbccontrol--host:--ferner_Host------------------------------><
lbccontrol host:ferner_Host
Setzen Sie diesen Befehl an einer Eingabeaufforderung ab. Geben Sie dann einen gültigen lbccontrol-Befehl ein, der an die ferne Maschine mit Cisco Consultant abgesetzt werden soll.
>>-lbccontrol--log--+-start-----------------------+------------>< +-stop------------------------+ +-set--+-retention--Stunden-+-+ | '-interval--Sekunden-' | '-status----------------------'
>>-lbccontrol--manager--+-interval--Sekunden-------------------------+->< +-loglevel--Stufe----------------------------+ +-logsize--+-size | unlimited-+--------------+ | '-Bytes------------' | +-quiesce--Server--+-----+-------------------+ | '-now-' | +-reach set--+-interval--Sekunden----------+-+ | +-loglevel--Stufe-------------+ | | '-logsize--Größe | unbegrenzt-' | +-refresh--Aktualisierungszyklus-------------+ +-report--+----------------+-----------------+ | '-Cluster+C2+...-' | +-restart--Nachricht-------------------------+ +-sensitivity--Wertigkeit--------------------+ +-smoothing--Wert----------------------------+ +-start--+---------------------------------+-+ | '-Protokolldateiname--Metric-Port-' | +-status-------------------------------------+ +-stop---------------------------------------+ +-unquiesce--Server--------------------------+ '-version------------------------------------'
Die Standarddatei ist im Verzeichnis logs installiert. Lesen Sie hierzu die Informationen in Anhang F, Beispielkonfigurationsdateien. Informationen zum Ändern des Verzeichnisses, in dem die Protokolldateien gespeichert werden, können Sie dem Abschnitt Pfade für die Protokolldatei ändern entnehmen.
Beispiele
lbccontrol manager interval 5
lbccontrol manager loglevel 0
lbccontrol manager logsize 1000000
lbccontrol manager quiesce 130.40.52.153
lbccontrol manager refresh 3
lbccontrol manager reportDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
lbccontrol>>manager report ---------------------------------------- | HOST-TAB.VERZEI. | STATUS | ---------------------------------------- | Server6| AKTIV | | Server5| AKTIV | | Server4| AKTIV | | Server3| AKTIV | | Server2| AKTIV | | Server1| AKTIV | ---------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.35 | GEWICHT | AKTIV % 49 | NEU % 50 | PORT % 1 | SYSTEM % 0 | ------------------------------------------------------------------------------------------------- | PORT: 80 |JETZT| NEU | GWT | VERB | GWT | VERB | GWT | LAST | GWT | LAST | ------------------------------------------------------------------------------------------------- | Server1 | 4 | 4 | 5 | 0 | 5 | 0 | 3| 301| -9999| -1| | Server2 | 5 | 5 | 5 | 0 | 5 | 0 | 6| 160| -9999| -1| ------------------------------------------------------------------------------------------------- | PORT GESAMT:| 9 | 9 | | 0 | | 0 | | 461 | | -2 | ------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.35 | GEWICHT | AKTIV % 49 | NEU % 50 | PORT % 1 | SYSTEM % 0 | ------------------------------------------------------------------------------------------------- | PORT: 443 |JETZT| NEU | GWT | VERB | GWT | VERB | GWT | LAST | GWT | LAST | ------------------------------------------------------------------------------------------------- | Server3 | 4 | 4 | 5 | 0 | 5 | 0 | | 0| -9999| -1| | Server4 | 5 | 5 | 5 | 0 | 5 | 0 | 0| 0| -9999| -1| ------------------------------------------------------------------------------------------------- | PORT GESAMT:| 9 | 9 | | 0 | | 0 | | 0 | | -2 | ------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.34 | GEWICHT | AKTIV % 49 | NEU % 50 | PORT % 1 | SYSTEM % 0 | ------------------------------------------------------------------------------------------------- | PORT: 80 |JETZT| NEU | GWT | VERB | GWT | VERB | GWT | LAST | GWT | LAST | ------------------------------------------------------------------------------------------------- | Server5 | 5 | 5 | 5 | 0 | 5 | 0 | 5| 160| -9999| -1| | Server6 | 0 | 0 | 5 | 0 | 5 | 0 | -9999| -1| -9999| -1| ------------------------------------------------------------------------------------------------- | PORT GESAMT:| 5 | 5 | | 0 | | 0 | | 159 | | -2 | ------------------------------------------------------------------------------------------------- -------------------------------- | ADVISOR | PORT | ZEITLIMIT| -------------------------------- | http | 80 | unlimited | --------------------------------
lbccontrol manager restart Neustart des Managers für CodeaktualisierungDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
320-14:04:54 Neustart des Managers für Codeaktualisierung
lbccontrol manager sensitivity 10
lbccontrol manager smoothing 2.0
lbccontrol manager start ndmgr.log
lbccontrol manager statusDieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Manager-Status: ============= Metrik-Port ............................................ 10004 Name der Managerprotokolldatei ......................... manager.log Managerprotokollstufe .................................. 1 Max. Managerprotokollgröße (Bytes) ..................... unlimited Sensitivitätsstufe ..................................... 0,05 Glättungsfaktor ........................................ 1,5 Aktualisierungsintervall (Sekunden) .................... 2 Gewichtungsaktualisierungszyklus ....................... 1 Erreichbarkeit - Protokollstufe ........................ 1 Erreichbarkeit - Max. Protokollgröße (Bytes) ........... unlimited Erreichbarkeit - Aktualisierungsintervall (Sekunden) ... 7
lbccontrol manager stop
lbccontrol manager version
>>-lbccontrol--metric--+-add--Cluster+C2+...+CN:Messwert+Messwert1+...+MesswertN--------+->< +-remove--Cluster+C2+...+CN:Messwert+Messwert1+...+MesswertN-----+ +-proportions--Cluster+C2+...+CN:Proportion1 Prop2 Prop3...PropN-+ '-status--Cluster+C2+...+CN:Messwert+Messwert1+...+MesswertN-----'
Anmerkung: Bei Cisco Consultant entspricht die Cluster-Adresse der virtuellen IP-Adresse (VIP-Adresse) in der content-Regel des Eigners in der Konfiguration des Cisco CSS Switch.
Beispiele
lbccontrol metric add 10.10.10.20:Messwert1
lbccontrol metric proportions 10.10.10.20 48 52
lbccontrol metric status 10.10.10.20:Messwert1Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Metrikstatus: ------------ Cluster ....................... 10.10.10.20 Metrikname .................... Messwert1 Metrikproportion .............. 52 Server ......... 9.37.56.100 Metrikdaten .... -1
>>-lbccontrol--port--+-add--Cluster:Port--+-------------------------+-+->< | '-weightbound--Wertigkeit-' | +-set--Cluster:Port--+-------------------------+-+ | '-weightbound--Wertigkeit-' | +-remove--Cluster:Port---------------------------+ '-status--Cluster:Port---------------------------'
Beispiele
lbccontrol port add 130.40.52.153:80+23
lbccontrol port set 130.40.52.153:80 weightbound 10
lbccontrol port remove 130.40.52.153:23
lbccontrol port status 9.67.131.153:80Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Port-Status: ------------ Port-Nummer .................... 80 Cluster-Adresse ................ 9.67.131.153 Anzahl Server .................. 2 Gewichtungsgrenze .............. 10
>>-lbccontrol--server--+-add--Cluster:Port:Server--+-------------------+-+->< | +-weight--Wert------+ | | +-fixedweight--Wert-+ | | '-address--Adresse--' | +-set--Cluster:Port:Server--+-weight--Wert------+-+ | '-fixedweight--Wert-' | +-down--Cluster:Port:Server-----------------------+ +-remove--Cluster:Port:Server---------------------+ +-report--Cluster:Port:Server---------------------+ +-up--Cluster:Port:Server-------------------------+ '-status--Cluster:Port:Server---------------------'
Beispiele
lbccontrol server add 130.40.52.153:80:27.65.89.42
lbccontrol server remove ::27.65.89.42
lbccontrol server set 130.40.52.153:80:27.65.89.42 weight 10
>>-lbccontrol--set--+-loglevel--Stufe----+--------------------->< +-logsize--+-size--+-+ | '-Größe-' | '-logstatus----------'
>>-lbccontrol--status------------------------------------------><
Beispiele
lbccontrol statusDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
Manager wurde gestartet. -------------------------------- | ADVISOR | PORT | ZEITLIMIT| -------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | --------------------------------
Dieser Anhang enthält Beispielkonfigurationsdateien für die Dispatcher-Komponente von Network Dispatcher.
Die Beispieldateien finden Sie im Verzeichnis .../nd/servers/samples/.
#!/bin/ksh
#
# configuration.sample - Beispielkonfigurationsdatei für die
Dispatcher-Komponente
#
#
# Dieses Script muss vom Benutzer "root" ausgeführt werden.
#
# iam=`wer bin ich`
# if [ "$iam" != "root" ]if [ "$iam" != "root" ]
# then
# echo "Zur Ausführung dieses Scripts müssen Sie als root angemeldet sein"
# exit 2
# fi
#
# Starten Sie zunächst den Server
#
# ndserver start
# sleep 5
#
# Starten Sie dann den Executor.
#
# ndcontrol executor start
#
# Der Dispatcher kann vor dem Löschen der Dispatcher-Software
# jederzeit mit den Befehlen "ndcontrol executor stop" und
# "ndserver stop" zum Stoppen von Executor und Server entfernt
# werden.
#
# Der nächste Konfigurationsschritt für den Dispatcher ist das
# Festlegen der NFA und der Cluster-Adresse(n).
#
# Die NFA wird für den Fernzugriff auf die Dispatcher-Maschine
# zu Verwaltungs- oder Konfigurationszwecken verwendet. Diese
# Adresse ist erforderlich, da der Dispatcher Pakete an die
# Cluster-Adresse(n) weiterleitet.
#
# Die CLUSTER-Adresse ist der Host-Name (oder die IP-Adresse)
# zu dem (bzw. zu der) ferne Clients eine Verbindung herstellen.
#
# Host-Namen und IP-Adressen können sind an jeder Stelle dieser
# Datei beliebig gegeneinander austauschbar.
#
# NFA=Host-Name.Domäne.Name
# CLUSTER=www.IhreFirma.com
# echo "NFA wird geladen"
# ndcontrol executor set nfa $NFA
#
# Der nächste Konfigurationsschritt für den Dispatcher ist
# das Erstellen eines Clusters. Der Dispatcher leitet an die
# Cluster-Adresse gesendete Anforderungen an die entsprechenden,
# für diesen Cluster definierten Servermaschinen weiter. Mit
# Dispatcher können Sie mehrere Cluster-Adressen konfigurieren
# und bedienen.
# Verwenden Sie für CLUSTER2, CLUSTER3 usw. eine ähnliche Konfiguration.
#
# echo "Erste CLUSTER-Adresse wird geladen"
# ndcontrol cluster add $CLUSTER
#
# Jetzt müssen die Ports definiert werden, die dieser Cluster
# verwendet. Alle vom Dispatcher an einem definierten Port
# empfangenen Anforderungen werden an den entsprechenden Port
# einer der Servermaschinen weitergeleitet.
#
# echo "Ports für CLUSTER $CLUSTER werden erstellt"
# ndcontrol port add $CLUSTER:20+21+80
#
# Der letzte Schritt ist das Hinzufügen der einzelnen Servermaschinen
# zu den Ports dieses Clusters.
# Auch hier können Sie entweder den Host-Namen oder die IP-Adresse der
# Servermaschinen verwenden.
#
# SERVER1=Servername1.Domäne.Name
# SERVER2=Servername2.Domäne.Name
# SERVER3=Servername3.Domäne.Name
# echo "Servermaschinen werden hinzugefügt"
# ndcontrol server add $CLUSTER:20+21+80:
# $SERVER1+$SERVER2+$SERVER3
#
# Jetzt werden die Lastausgleichskomponenten von Dispatcher
# gestartet. Die Hauptkomponente ist der Manager. Die
# sekundären Komponenten sind die Advisor-Funktionen. Sind
# Manager und Advisor-Funktionen nicht aktiv, sendet der
# Dispatcher Anforderungen in einem RoundRobin-Format.
# Sobald der Manager gestartet ist, werden Wertigkeitsentscheidungen
# auf der Grundlage der Anzahl neuer und aktiver Verbindungen
# getroffen und eingehende Anforderungen an den am besten geeigneten
# Server gesendet. Die Advisor-Funktionen geben dem Manager
# Einblick in die Fähigkeit eines Servers, Anforderungen zu bedienen,
# und können feststellen, ob ein Server aktiv ist. Erkennt eine
# Advisor-Funktion, dass ein Server inaktiv ist, wird dieser
# entsprechend markiert (sofern die Manager-Proportionen
# auf das Einbeziehen von Advisor-Eingaben gesetzt sind) und es
# werden keine weiteren Anforderungen an den Server weitergeleitet.
# Der letzte Schritt beim Konfigurieren der Lastausgleichkomponenten
# ist das Festlegen der Manager-Proportionen. Der Manager aktualisiert
# die Wertigkeit der Server ausgehend von vier verschiedenen Ansätzen:
# 1. Anzahl der aktiven Verbindungen für jeden Server.
# 2. Anzahl der neuen Verbindungen zu jedem Server.
# 3. Eingaben von den Advisor-Funktionen.
# 4. Eingaben von der Advisor-Funktion auf Systemebene.
# Diese Proportionen müssen in der Summe 100 ergeben. Sie können
# die Manager Proportionen beispielsweise wie folgt festlegen:
# ndcontrol manager proportions 48 48 0 0
# Damit fließen die aktiven und neuen Verbindungen mit jeweils 48 %
# in die Gewichtungsentscheidung ein. Die Advisor-Funktionen fließen
# zu 4 % ein und die Systemeingaben werden nicht berücksichtigt.
#
# ANMERKUNG. Standardmäßig sind die Manager-Proportionen auf 50 50 0 0 gesetzt.
#
# echo "Manager wird gestartet..."
# ndcontrol manager start
# echo "FTP-Advisor-Funktion wird an Port 21 gestartet ..."
# ndcontrol advisor start ftp 21
# echo "HTTP-Advisor-Funktion wird an Port 80 gestartet ..."
# ndcontrol advisor start http 80
# echo "Telnet-Advisor-Funktion wird an Port 23 gestartet ..."
# ndcontrol advisor start telnet 23
# echo "SMTP-Advisor-Funktion wird an Port 25 gestartet ..."
# ndcontrol advisor start smtp 25
# echo "POP3-Advisor-Funktion wird an Port 110 gestartet ..."
# ndcontrol advisor start pop3 110
# echo "NNTP-Advisor-Funktion wird an Port 119 gestartet ..."
# ndcontrol advisor start nntp 119
# echo "SSL-Advisor-Funktion wird an Port 443 gestartet ..."
# ndcontrol advisor start ssl 443
#
# echo "Manager-Proportionen werden festgelegt..."
# ndcontrol manager proportions 58 40 2 0
#
# Der letzte Konfigurationsschritt für die Dispatcher-Maschine
# ist das Festlegen eines Aliasnamens für die Netzschnittstellenkarte (NIC).
#
# ANMERKUNG: Verwenden Sie diesen Befehl NICHT in einer Umgebung mit hoher
# Verfügbarkeit. Die NIC und die Loopback-Adresse werden von den
# go*-Scripts konfiguriert.
# ndcontrol cluster configure $CLUSTER
# Wenn die Cluster-Adresse sich auf einer von der NFA abweichenden
NIC oder in einem abweichenden Teilnetz befindet, verwenden Sie für
den Befehl "cluster configure" das folgende Format:
# ndcontrol cluster configure $CLUSTER tr0 0xfffff800
# tr0 ist hier die NIC (tr1 die zweite Token-Ring-Karte, en0
# die erste Ethernet-Karte) und 0xfffff800 ist eine für
# Ihre Site gültige Teilnetzmaske.
#
#
# Die folgenden Befehle aktivieren die Standardwerte.
# Verwenden Sie diese Befehle als Ausgangspunkt für Änderungen der Standardwerte.
# ndcontrol manager loglevel 1
# ndcontrol manager logsize 1048576
# ndcontrol manager sensitivity 5.000000
# ndcontrol manager interval 2
# ndcontrol manager refresh 2
#
# ndcontrol advisor interval ftp 21 5
# ndcontrol advisor loglevel ftp 21 1
# ndcontrol advisor logsize ftp 21 1048576
# ndcontrol advisor timeout ftp 21 unlimited
# ndcontrol advisor interval telnet 23 5
# ndcontrol advisor loglevel telnet 23 1
# ndcontrol advisor logsize telnet 23 1048576
# ndcontrol advisor timeout telnet 23 unlimited
# ndcontrol advisor interval smtp 25 5
# ndcontrol advisor loglevel smtp 25 1
# ndcontrol advisor logsize smtp 25 1048576
# ndcontrol advisor timeout smtp 25 unlimited
# ndcontrol advisor interval http 80 5
# ndcontrol advisor loglevel http 80 1
# ndcontrol advisor logsize http 80 1048576
# ndcontrol advisor timeout http 80 unlimited
# ndcontrol advisor interval pop3 110 5
# ndcontrol advisor loglevel pop3 110 1
# ndcontrol advisor logsize pop3 110 1048576
# ndcontrol advisor timeout pop3 110 unlimited
# ndcontrol advisor interval nntp 119 5
# ndcontrol advisor loglevel nntp 119 1
# ndcontrol advisor logsize nntp 119 1048576
# ndcontrol advisor timeout nntp 119 unlimited
# ndcontrol advisor interval ssl 443 5
# ndcontrol advisor loglevel ssl 443 1
# ndcontrol advisor logsize ssl 443 1048576
# ndcontrol advisor timeout ssl 443 unlimited
#
Die folgende Konfigurationsdatei ist die Network Dispatcher-Beispielkonfigurationsdatei configuration.cmd.sample, die mit Windows verwendet wird.
@echo off rem configuration.cmd.sample - Beispielkonfigurationsdatei für die rem Dispatcher-Komponente. rem rem ndserver muss im Fenster "Dienste" gestartet werden. rem rem rem Starten Sie dann den Executor. rem rem call ndcontrol executor start rem rem Der nächste Konfigurationsschritt für den Dispatcher rem ist das Festlegen der NFA und der Cluster-Adresse(n). rem rem Die NFA wird für den Fernzugriff auf die Dispatcher-Maschine rem zu Verwaltungs- oder Konfigurationszwecken verwendet. Diese rem Adresse ist erforderlich, da der Dispatcher Pakete an die rem Cluster-Adresse(n) weiterleitet. rem rem Die CLUSTER-Adresse ist der Host-Name (oder die IP-Adresse) rem zu dem (bzw. zu der) ferne Clients eine Verbindung herstellen. rem rem Host-Namen und IP-Adressen können sind an jeder Stelle dieser rem Datei beliebig gegeneinander austauschbar. rem NFA=[Non-Forwarding Address] rem CLUSTER=[Cluster-Name] rem rem set NFA=Host-Name.Domäne.Name rem set CLUSTER=www.IhreFirma.com rem echo "NFA wird geladen" rem call ndcontrol executor set nfa %NFA% rem rem Mit den folgenden Befehlen werden die Standardwerte festgelegt. rem Verwenden Sie diese Befehle zum Ändern der Standardwerte. rem call ndcontrol executor set fintimeout 30 rem call ndcontrol executor set fincount 4000 rem rem Der nächste Konfigurationsschritt für den Dispatcher ist rem das Erstellen eines Clusters. Der Dispatcher leitet an die rem Cluster-Adresse gesendete Anforderungen an die entsprechenden, rem für diesen Cluster definierten Servermaschinen weiter. Mit rem Dispatcher können Sie mehrere Cluster-Adressen konfigurieren rem und bedienen. rem Verwenden Sie für CLUSTER2, CLUSTER3 usw. eine ähnliche Konfiguration. rem rem echo "Erste CLUSTER-Adresse wird geladen" rem call ndcontrol cluster add %CLUSTER% rem rem Jetzt müssen die Ports definiert werden, die dieser Cluster rem verwendet. Alle vom Dispatcher an einem definierten Port rem empfangenen Anforderungen werden an den entsprechenden Port rem einer der Servermaschinen weitergeleitet. rem rem echo "Ports für CLUSTER %CLUSTER% werden erstellt" rem call ndcontrol port add %CLUSTER%:20+21+80 rem rem Der letzte Schritt ist das Hinzufügen der einzelnen Servermaschinen rem zu den Ports dieses Clusters. Auch hier können Sie entweder den rem Host-Namen oder die IP-Adresse der Servermaschinen verwenden. rem rem set SERVER1=Servername1.Domäne.Name rem set SERVER2=Servername2.Domäne.Name rem set SERVER3=Servername3.Domäne.Name rem echo "Servermaschinen werden hinzugefügt" rem call ndcontrol server add %CLUSTER%:20+21+80: rem %SERVER1%+%SERVER2%+%SERVER3% rem rem Jetzt werden die Lastausgleichskomponenten von Dispatcher rem gestartet. Die Hauptkomponente ist der Manager. Die rem sekundären Komponenten sind die Advisor-Funktionen. Sind rem Manager und Advisor-Funktionen nicht aktiv, sendet der rem Dispatcher Anforderungen in einem RoundRobin-Format. rem Sobald der Manager gestartet ist, werden Wertigkeitsentscheidungen rem auf der Grundlage der Anzahl neuer und aktiver Verbindungen rem getroffen und eingehende Anforderungen an den am besten geeigneten rem Server gesendet. Die Advisor-Funktionen geben dem Manager rem Einblick in die Fähigkeit eines Servers, Anforderungen zu bedienen, rem und können feststellen, ob ein Server aktiv ist. Erkennt eine rem Advisor-Funktion, dass ein Server inaktiv ist, wird dieser rem entsprechend markiert (sofern die Manager-Proportionen rem auf das Einbeziehen von Advisor-Eingaben gesetzt sind) und es rem werden keine weiteren Anforderungen an den Server weitergeleitet. rem Der letzte Schritt beim Konfigurieren der Lastausgleichkomponenten rem ist das Festlegen der Manager-Proportionen. Der Manager aktualisiert rem die Wertigkeit der Server ausgehend von vier verschiedenen Ansätzen: rem 1. Anzahl der aktiven Verbindungen für jeden Server. rem 2. Anzahl der neuen Verbindungen zu jedem Server. rem 3. Eingaben von den Advisor-Funktionen. rem 4. Eingaben von der Advisor-Funktion auf Systemebene. rem rem Diese Proportionen müssen in der Summe 100 ergeben. Sie können rem die Manager Proportionen beispielsweise wie folgt festlegen: rem ndcontrol cluster set <Cluster> proportions 48 48 4 0 rem Damit fließen die aktiven und neuen Verbindungen mit jeweils 48 % rem in die Gewichtungsentscheidung ein. Die Advisor-Funktionen fließen rem zu 4 % ein und die Systemeingaben werden nicht berücksichtigt. rem rem ANMERKUNG. Standardmäßig sind die Manager-Proportionen auf rem 50 50 0 0 gesetzt. rem echo "Manager wird gestartet..." rem call ndcontrol manager start rem echo "FTP-Advisor-Funktion wird an Port 21 gestartet ..." rem call ndcontrol advisor start ftp 21 rem echo "HTTP-Advisor-Funktion wird an Port 80 gestartet ..." rem call ndcontrol advisor start http 80 rem echo "Telnet-Advisor-Funktion wird an Port 23 gestartet..." rem call ndcontrol advisor start telnet 23 rem echo "SMTP-Advisor-Funktion wird an Port 25 gestartet ..." rem call ndcontrol advisor start smtp 25 rem echo "POP3-Advisor-Funktion wird an Port 110 gestartet..." rem call ndcontrol advisor start pop3 110 rem echo "NNTP-Advisor-Funktion wird an Port 119 gestartet..." rem call ndcontrol advisor start nntp 119 rem echo "SSL-Advisor-Funktion wird an Port 443 gestartet..." rem call ndcontrol advisor start ssl 443 rem rem echo "Cluster-Proportionen werden festgelegt..." rem call ndcontrol cluster set %CLUSTER% proportions 58 40 2 0 rem rem Der letzte Konfigurationsschritt für die Dispatcher-Maschine rem ist das Festlegen eines Aliasnamens für die Netzschnittstellenkarte (NIC). rem rem ANMERKUNG: Verwenden Sie diesen Befehl NICHT in einer Umgebung mit hoher rem Verfügbarkeit. Die NIC und die Loopback-Adresse werden von den rem go*-Scripts konfiguriert. rem rem ndcontrol cluster configure %CLUSTER% rem Wenn die Cluster-Adresse sich auf einer von der NFA abweichenden rem NIC oder in einem abweichenden Teilnetz befindet, verwenden Sie für rem den Befehl "cluster configure" das folgende Format: rem ndcontrol cluster configure %CLUSTER% tr0 0xfffff800 rem tr0 ist hier die NIC (tr1 die zweite Token-Ring-Karte, en0 rem die erste Ethernet-Karte) und 0xfffff800 ist eine für rem Ihre Site gültige Teilnetzmaske. rem rem rem Mit den folgenden Befehlen werden die Standardwerte festgelegt. rem Verwenden Sie diese Befehle als Ausgangspunkt zum Ändern der Standardwerte. rem call ndcontrol manager loglevel 1 rem call ndcontrol manager logsize 1048576 rem call ndcontrol manager sensitivity 5.000000 rem call ndcontrol manager interval 2 rem call ndcontrol manager refresh 2 rem rem call ndcontrol advisor interval ftp 21 5 rem call ndcontrol advisor loglevel ftp 21 1 rem call ndcontrol advisor logsize ftp 21 1048576 rem call ndcontrol advisor timeout ftp 21 unlimited rem call ndcontrol advisor interval telnet 23 5 rem call ndcontrol advisor loglevel telnet 23 1 rem call ndcontrol advisor logsize telnet 23 1048576 rem call ndcontrol advisor timeout telnet 23 unlimited rem call ndcontrol advisor interval smtp 25 5 rem call ndcontrol advisor loglevel smtp 25 1 rem call ndcontrol advisor logsize smtp 25 1048576 rem call ndcontrol advisor timeout smtp 25 unlimited rem call ndcontrol advisor interval http 80 5 rem call ndcontrol advisor loglevel http 80 1 rem call ndcontrol advisor logsize http 80 1048576 rem call ndcontrol advisor timeout http 80 unlimited rem call ndcontrol advisor interval pop3 110 5 rem call ndcontrol advisor loglevel pop3 110 1 rem call ndcontrol advisor logsize pop3 110 1048576 rem call ndcontrol advisor timeout pop3 110 unlimited rem call ndcontrol advisor interval nntp 119 5 rem call ndcontrol advisor loglevel nntp 119 1 rem call ndcontrol advisor logsize nntp 119 1048576 rem call ndcontrol advisor timeout nntp 119 unlimited rem call ndcontrol advisor interval ssl 443 5 rem call ndcontrol advisor loglevel ssl 443 1 rem call ndcontrol advisor logsize ssl 443 1048576 rem call ndcontrol advisor timeout ssl 443 unlimited rem
Nachfolgend ist die Advisor-Beispieldatei ADV_sample wiedergegeben.
/**
* ADV_sample: HTTP-Advisor-Funktion von Network Dispatcher
*
*
* Diese Klasse definiert eine angepasste Beispiel-Advisor-Funktion für Network Dispatcher.
* Diese angepasste Advisor-Funktion erweitert wie alle anderen Advisor-Funktionen den
* Advisor-Basiscode ADV_Base. Es ist der Advisor-Basiscode, der die meisten
* Advisor-Funktionen ausführt. Dazu gehört das Zurückmelden von Belastungen
* an Network Dispatcher für den Wertigkeitsalgorithmus von Network Dispatcher.
* Darüber hinaus stellt der Advisor-Basiscode Socket-Verbindungen her,
* schließt Sockets und stellt Sende- und Empfangsmethoden für die Advisor-
* Funktion bereit. Die Advisor-Funktion 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 Advisor-Basiscodes werden zeitlich
* gesteuert, um die Last zu berechnen. Mit einer Markierung der Methode
* "constructor" in in ADV_base kann bei Bedarf die vorhandene Last
* mit der neuen, von der Advisor-Funktion zurückgegebenen Last
* überschrieben werden.
*
* Anmerkung: Der Advisor-Basiscode stellt in angegebenen Intervallen
* die Last ausgehend von einem in der Methode "constructor" gesetzten
* Wert für den Wertigkeitsalgorithmus bereit. Ist die eigentliche
* Advisor-Funktion noch nicht abgeschlossen, so dass sie keinen gültigen
* Lastwert zurückgegeben kann, verwendet der Advisor-Basiscode die
* bisherige Last.
*
* NAMEN
*
* Es gilt die folgende Namenskonvention:
*
* - Die Datei muss sich in den folgenden Network-Dispatcher-
* Verzeichnissen befinden:
*
* nd/servers/lib/CustomAdvisors/
* (Widows 2000: nd\servers\lib\CustomAdvisors)
*
* - Der Name der Advisor-Funktion muss den Präfix "ADV_" haben. Zum Starten
* der Advisor-Funktion genügt jedoch der Name. Die Advisor-Funktion
* "ADV_sample" kann beispielsweise mit "sample" gestartet werden.
*
* - Der Name der Advisor-Funktion muss in Kleinbuchstaben angegeben werden.
*
* Unter Beachtung dieser Regeln wird auf dieses Beispiel wie folgt verwiesen:
*
* <Basisverzeichnis>/lib/CustomAdvisors/ADV_sample.class
*
*
* Advisor-Funktionen müssen wie für Network Dispatcher generell gültig
* mit der erforderlichen Java-Version kompiliert werden.
* Um den Zugriff auf die Network-Dispatcher-Klassen zu gewährleisten, müssen Sie
* sicherstellen, dass die Datei ibmnd.jar (aus dem Unterverzeichnis "lib" des
* Basisverzeichnisses) im CLASSPATH des Systems enthalten ist.
*
*
* Von ADV_Base bereitgestellte Methoden:
*
* - ADV_Base (Constructor):
*
* - Parameter
* - String sName = Name der Advisor-Funktion
* - String sVersion = Version der Advisor-Funktion
* - int iDefaultPort = Standard-Port-Nummer für die Advisor-Funktion
* - int iInterval = Intervall für die Ausführung der Advisor-Funktion für die Server
* - String sDefaultLogFileName = Nicht verwendet; muss als "" übergeben werden.
* - boolean replace = True - Den vom Advisor-Basiscode berechneten Lastwert
* ersetzen
* False - Zu dem vom Advisor-Basiscode berechneten Lastwert
* addieren
* - Rückgabe
* - constructor-Methoden haben keine Rückgabewerte.
*
* Da der Advisor-Basiscode auf Threads basiert, stehen verschiedene andere
* Methoden für Advisor-Funktionen zur Verfügung. Auf diese kann mit dem von
* getLoad() übergebenen Parameter CALLER verwiesen werden.
*
* Es handelt sich um die folgenden Methoden:
*
* - send - Informationspaket über die eingerichtete Socket-Verbindung
* an den Server am angegebenen Port senden.
* - Parameter
* - String sDataString - Daten werden in Form einer Zeichenfolge
* gesendet
* - Rückgabe
* - int RC - Null gibt unabhängig vom erfolgreichen/gescheiterten Senden
* der Daten an, dass die Daten gesendet wurden. Eine negative
* ganze Zahl zeigt einen Fehler an.
*
* - receive - Empfang von Informationen von der Socket-Verbindung.
* - Parameter
* - StringBuffer sbDataBuffer - Die während des Aufrufs von "receive"
* empfangenen Daten
* - Rückgabe
* - int RC - Null gibt unabhängig vom erfolgreichen/gescheiterten Empfang
* der Daten an, dass die Daten gesendet wurden. Eine negative
* ganze Zahl zeigt einen Fehler an.
*
* Falls die vom Advisor-Basiscode bereitgestellte Funktionalität nicht
* ausreicht, können Sie die gewünschte Funktion innerhalb des Advisors
* erstellen. Die vom Advisor-Basiscode bereitgestellten Methoden werden
* dann ignoriert.
*
* Eine wichtige Frage hinsichtlich der zurückgegebenen Last ist, ob
* sie auf die vom Advisor-Basiscode generierte Last angewendet oder
* ersetzt werden soll. Es gibt gültige Instanzen für beide Situationen.
*
* Dieses Beispiel entspricht im Wesentlichen der HTTP-Advisor-Funktion
* von Network Dispatcher und funktioniert sehr einfach:
* Es wird eine Sendeanforderung (HTTP HEAD) abgesetzt. Bei Empfang einer
* Anwort wird die Methode getLoad beendet und der Advisor-Basiscode
* angewiesen, die Ablaufsteuerung der Anforderung zu stoppen. Die Methode
* ist damit abgeschlossen. Die zurückgegebenen Informationen werden keiner
* Syntaxanalyse unterzogen. Die Last basiert auf der für das Senden und
* und Empfangen benötigten Zeit.
*/
package CustomAdvisors;
import com.ibm.internet.nd.advisors.*;
public class ADV_sample extends ADV_Base implements ADV_MethodInterface
{
String COPYRIGHT = "(C) Copyright IBM Corporation 1997, All Rights Reserved.\n";
static final String ADV_NAME = "Sample";
static final int ADV_DEF_ADV_ON_PORT = 80;
static final int ADV_DEF_INTERVAL = 7;
// Anmerkung: Die meisten Serverprotokolle erfordern am Ende von Nachrichten
// eine Zeilenschaltung ("\r") und einen Zeilenvorschub ("\n"). Sollte dies
// für Sie zutreffen, nehmen Sie sie an dieser Stelle in Ihre Zeichenfolge
// auf.
static final String ADV_SEND_REQUEST =
"HEAD / HTTP/1.0\r\nAccept: */*\r\nUser-Agent: " +
"IBM_Network_Dispatcher_HTTP_Advisor\r\n\r\n";
/**
* Constructor.
*
* Parameter: Keine. An die constructor-Methode für ADV_Base müssen
* jedoch mehrere Parameter übergeben werden.
*
*/
public ADV_sample()
{
super( ADV_NAME,
"2.0.0.0-03.27.98",
ADV_DEF_ADV_ON_PORT,
ADV_DEF_INTERVAL,
"", // not used
false);
super.setAdvisor( this );
}
/**
* ADV_AdvisorInitialize
*
* Eine Advisor-spezifische Initialisierung, die nach dem Start der
* Advisor-Funktion stattfinden muss.
* Diese Methode wird nur einmal aufgerufen und in der Regel nicht verwendet.
*/
public void ADV_AdvisorInitialize()
{
return;
}
/**
* getLoad()
*
* Diese Methode wird vom Advisor-Basiscode aufgerufen, um die Operation der
* Advisor-Funktion auf der Grundlage protokollspezifischer Details zu beenden.
* In diesem Beispiel sind nur eine Sende- und eine Empfangsoperation
* notwendig. Wenn eine komplexere Logik erforderlich ist, können mehrere
* Sende- und Empfangsoperationen ausgeführt werden.
* Es könnte beispielsweise eine Antwort empfangen werden. Die sich aus der
* Syntaxanalyse dieser Antwort ergebenden Informationen könnten eine
* weitere Sende- und Empfangsoperation nach sich ziehen.
*
* Parameter:
*
* - iConnectTime - Derzeitige Last entsprechend der Zeit, die für das Herstellen
* der Verbindung zum Server über den angegebenen Port benötigt
* wurde.
*
* - caller - Verweis auf die Advisor-Basisklasse, wo die von Network
* Dispatcher bereitgestellten Methoden einfache TCP-Anforderungen
* wie Sende- und Empfangsaufrufe durchführen sollen.
*
* Ergebnisse:
*
* - Last: Ein in Millisekunden angegebener Wert, der entsprechend der
* Markierung "replace" der constructor-Methode zur vorhandenen Last
* addiert wird oder die vorhandene Last ersetzt.
*
* Je größer die Last ist, desto länger benötigte der Server für die
* Antwort. Um so höher wird in Network Dispatcher auch die Wertigkeit
* für den Lastausgleich ausfallen.
*
* Wenn der Wert negativ ist, wird von einem Fehler ausgegangen. Ein Fehler
* von einer Advisor-Funktion zeigt an, dass der Server, den die Advisor-Funktion
* zu erreichen versucht, nicht zugänglich und inaktiv ist.
* Network Dispatcher versucht nicht, die Last an einen inaktiven Server
* weiterzuleiten. Der Server wird von Network Dispatcher wieder in den
* Lastausgleich einbezogen, wenn ein positiver Wert empfangen wird.
*
* Der Wert null wird nur sehr selten zurückgegeben und von Network
* Dispatcher als unbekannter Status interpretiert, auf den Network
* Dispatcher reagiert, indem er dem Server eine hohe Wertigkeit
* zuordnet.
*/
public int getLoad(int iConnectTime, ADV_Thread caller)
{
int iRc;
int iLoad = ADV_HOST_INACCESSIBLE; // -1
// Send tcp request
iRc = caller.send(ADV_SEND_REQUEST);
if (iRc >= 0)
{
// Empfang ausführen
StringBuffer sbReceiveData = new StringBuffer("");
iRc = caller.receive(sbReceiveData);
// Bei erfolgreichem Empfang wird als Lastwert null zurückgegeben.
// Dies liegt daran, dass die Markierung "replace" auf "false" gesetzt
// ist und so angibt, dass die von der Basis-Advisor-Funktion generierte
// Last verwendet werden soll.
// Da die zurückgegebenen Daten nicht verarbeitet wurden, ist keine
// zusätzliche Last nötig.
// Anmerkung: Es ist bekannt, dass die Last des Advisor-Basiscodes
// ungleich null sein wird, so dass ein Lastwert von null nicht zur
// Berechnung der Wertigkeit zurückgegeben wird.
if (iRc >= 0)
{
iLoad = 0;
}
}
return iLoad;
}
} // Ende von ADV_sample
Dieser Anhang beschreibt das Einrichten einer Client-/Serverkonfiguration mit hoher Verfügbarkeit, die das Leistungsspektrum der Komponenten von Network Dispatcher (Dispatcher und CBR) mit dem von Caching Proxy verbindet.
Die Servermaschine in Abbildung 30 ist wie folgt konfiguriert:
Abbildung 30 zeigt eine grundlegende Darstellung mehrerer Server (EdgeServer1, EdgeServer2, EdgeServer3), die die Last auf mehrere Back-End-Webserver verteilen. Die CBR-Komponente verwendet Caching Proxy für eine vom Inhalt des URL abhängige Weiterleitung von Anforderungen an die Back-End-Webserver. Die Dispatcher-Komponente verteilt die Last der CBR-Komponenten auf alle Edge-Server. Die Dispatcher-Funktion für hohe Verfügbarkeit stellt sicher, dass Anforderungen an die Back-End-Server auch dann möglich sind, wenn die primäre Maschine mit hoher Verfügbarkeit (EdgeServer1) ausfällt.
Basisrichtlinien für die Konfiguration:
Beispielzeilen für die vorgenannten Schritte 1-4:
Hostname www.firma.com SendRevProxyName yes Caching ON CacheMemory 128000 K Proxy /* http://www.firma.com/* www.firma.com
Beispielkonfigurationsdateien:
Die folgenden Beispielkonfigurationsdateien ähneln den Dateien, die beim Einrichten einer Edge-Server-Konfiguration, wie sie in Abbildung 30 dargestellt ist, erstellt werden. Die Beispielkonfigurationsdateien sind Dateien für die Network-Dispatcher-Komponenten Dispatcher und CBR. In der Beispielkonfiguration wird für jede Edge-Server-Maschine ein Ethernet-Adapter verwendet und alle Adressen befinden sich innerhalb eines privaten Teilnetzes. In den Beispielkonfigurationsdateien sind für die angegebenen Maschinen die folgenden IP-Adressen angegeben:
Beispielkonfigurationsdatei für die Dispatcher-Komponente auf dem primären Edge-Server mit hoher Verfügbarkeit:
ndcontrol executor start ndcontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 ndcontrol port add 192.168.1.11:80 ndcontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 ndcontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 ndcontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 ndcontrol manager start manager.log 10004 ndcontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 ndcontrol highavailability backup add primary auto 4567
Beispielkonfigurationsdatei für die CBR-Komponente auf den Edge-Servern:
cbrcontrol set loglevel 1 cbrcontrol executor start cbrcontrol cluster add 192.168.1.11 cbrcontrol port add 192.168.1.11:80 cbrcontrol server add 192.168.1.11:80:webserverA address 192.168.1.71 cbrcontrol server add 192.168.1.11:80:webserverB address 192.168.1.72 cbrcontrol server add 192.168.1.11:80:webserverC address 192.168.1.73 cbrcontrol rule add 192.168.1.11:80:webA_Regel type content pattern (URI=*WSA*)|(URI=*wsA*) priority 21 cbrcontrol rule useserver 192.168.1.11:80:webA_Regel webserverA cbrcontrol rule add 192.168.1.11:80:webB_Regel type content pattern (URI=/WS_B*) priority 22 cbrcontrol rule useserver 192.168.1.11:80:webB_Regel webserverB cbrcontrol rule add 192.168.1.11:80:webC_Regel type content pattern URI=*webC* priority 23 cbrcontrol rule useserver 192.168.1.21:80:webC_Regel webserverC
In vielen Situationen können Sie Tasten oder Tastenkombinationen verwenden, um Operationen auszuführen, für die auch die Maus benutzt werden kann. Viele Menüaktionen können von der Tastatur aus aufgerufen werden.
Anweisungen für den Einsatz der Tastatur finden Sie in der Dokumentation zum verwendeten Betriebssystem.
Network Dispatcher stellt eine Onlinehilfefunktion bereit, die die Tasks beschreibt, die Sie beim Installieren, Planen, Konfigurieren und Verwenden des Produkts ausführen müssen.
Wenn Sie Hilfe zum aktuellen Fenster benötigen, klicken Sie auf das Fragezeichen (?) in der oberen rechten Ecke des Fensters. Es werden die folgenden Optionen angeboten:
Zusätzliche Informationen zur Verwendung von Network Dispatcher finden Sie an folgenden Stellen:
http://www.ibm.com/software/webservers/edgeserver
http://www.ibm.com/software/webservers/edgeserver/support.html
Geben Sie im Suchfeld "Network Dispatcher" ein und wählen Sie als Suchoption Hints and tips aus.
Hinweise auf IBM Produkte, Programme und Dienstleistungen in dieser Veröffentlichung bedeuten nicht, dass IBM diese in allen Ländern, in denen IBM vertreten ist, anbietet. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Dienstleistungen von IBM verwendet werden können. Anstelle der IBM Produkte, Programme oder Dienstleistungen können auch andere ihnen äquivalente Produkte, Programme oder Dienstleistungen verwendet werden, solange diese keine gewerblichen oder anderen Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb der Produkte, Programme oder Dienstleistungen in Verbindung mit Fremdprodukten und Fremddienstleistungen liegt beim Kunden, soweit solche Verbindungen nicht ausdrücklich von IBM bestätigt sind.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieser Veröffentlichung ist keine Lizenzierung dieser Patente verbunden. Lizenzanfragen sind schriftlich an IBM Europe, Director of Licensing, 92066 Paris La Defense Cedex, France, zu richten. Anfragen an obige Adresse müssen auf englisch formuliert werden.
Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen
mit der Zielsetzung: (i) den Austausch von Informationen zwischen
unabhängigen, erstellten Programmen und anderen Programmen (einschließlich des
vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten
Informationen zu ermöglichen, wenden sich an folgende Adresse:
Site Counsel
IBM Corporation
P.O. Box 12195
3039 Cornwallis Avenue
Research Triangle Park, NC 27709-2195
USA
Die Lieferung des im Handbuch aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt im Rahmen der IBM Kundenvereinbarung.
Die Veröffentlichung dient nicht für Produktionszwecke. IBM übernimmt keine Haftung. Die in dieser Veröffentlichung aufgeführten Beispiele sollen lediglich zur Veranschaulichung und zu keinem anderen Zweck dienen.
Dieses Produkt enthält Computersoftware, die von CERN erstellt oder zur Verfügung gestellt wurde. Ein entsprechender Hinweis ist in allen Produkten enthalten, die CERN-Computersoftware oder Komponenten dieser Software enthalten.
Folgende Namen sind in gewissen Ländern Marken der IBM Corporation:
AIX
IBM
IBMLink
LoadLeveler
OS/2
NetView
WebSphere
Lotus ist in gewissen Ländern eine eingetragene Marke der Lotus Developtment Corporation.
Domino ist in gewissen Ländern eine Marke der Lotus Developtment Corporation.
Tivoli ist in gewissen Ländern eine eingetragene Marke von Tivoli Systems, Inc.
Java und alle Java-basierten Marken und Logos sind in gewissen Ländern Marken oder eingetragene Marken von Sun Microsystems, Inc.
Solaris ist in gewissen Ländern eine Marke von Sun Microsystems, Inc.
Microsoft und Windows 2000 sind in gewissen Ländern Marken oder eingetragene Marken der Microsoft Corporation.
Cisco ist in gewissen Ländern eine eingetragene Marke von Cisco Systems, Inc.
HP ist in gewissen Ländern eine Marke der Hewlett-Packard Company.
Linux ist eine eingetragene Marke von Linus Torvalds.
Red Hat ist eine eingetragene Marke von Red Hat, Inc.
UNIX ist in gewissen Ländern eine eingetragene Marke von The Open Group.
Mit ** gekennzeichnete Namen können Marken oder Dienstleistungsmarken anderer Unternehmen sein.