Version 7.0
Anmerkung |
---|
Vor Verwendung dieser Informationen und des darin beschriebenen Produkts sollten die allgemeinen Informationen in Anhang E: Bemerkungen gelesen werden. |
Erste Ausgabe (Juni 2008)
Diese Ausgabe gilt für:
und, sofern nicht anders angegeben, für alle nachfolgenden Releases und Bearbeitungen.
Veröffentlichungen können über den zuständigen IBM Ansprechpartner oder die zuständige IBM Geschäftsstelle bezogen werden.
(C) Copyright International Business Machines Corporation 2008. Alle Rechte vorbehalten.
Komponente Content Based Routing (CBR)
Kompöonente Cisco CSS Controller
Komponente Nortel Alteon Controller
Funktionen und erweiterte Features von Load Balancer
Verwaltung und Fehlerbehebung in Load Balancer
In diesem Handbuch sind die Planung, Installation, Konfiguration, Verwendung und Fehlerbehebung für IBM WebSphere Application Server für die Betriebssysteme AIX, HP-UX, Linux, Solaris und Windows beschrieben. Zuvor hatte dieses Produkt den Namen Edge Server Network Dispatcher, SecureWay Network Dispatcher, eNetwork Dispatcher und Interactive Network Dispatcher.
Das Administratorhandbuch ist für erfahrene Netz- und Systemadministratoren geschrieben, die sich mit den von ihnen verwendeten Betriebssystemen und dem Bereitstellen von Internetservices auskennen. Vorkenntnisse in Load Balancer sind nicht erforderlich.
Dieses Handbuch bietet keine Unterstützung für frühere Releases von Load Balancer.
Die Website mit dem Edge Components Informationszentrum enthält Links zur aktuellen Version dieses Handbuchs in den Formaten HTML und PDF.
Die letzten Aktualisierungen zu Load Balancer finden Sie auf der Unterstützungsseite der Website. Klicken Sie auf dieser Seite auf den Link zur Technote-Site.
Die URLs dieser und weiterer Webseiten sind im Abschnitt Zugehörige Dokumente und Websites aufgelistet.
Features zur Erleichterung des Zugriffs helfen körperbehinderten Benutzern (mit eingeschränkter Beweglichkeit oder Sehschwäche), Softwareprodukte erfolgreich anzuwenden. Load Balancer bietet im Wesentlichen die folgenden Features für verbesserte Zugriffsmöglichkeiten an:
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 Edge Components abgeben möchten:
Dieser Teil gibt einen Überblick über Load Balancer und die zugehörigen Produktkomponenten. Er enthält außerdem eine kurze Beschreibung der verfügbaren Konfigurationsfunktionen, eine Auflistung der Hardware- und Softwarevoraussetzungen sowie Installationsanweisungen. Zu diesem Teil gehören die folgenden Kapitel:
Dieses Kapitel gibt einen Überblick über Load Balancer und ist in die folgenden Abschnitte gegliedert:
Eine detaillierte Liste der Konfigurationsfunktionen der einzelnen Komponenten von Load Balancer, die Sie zur Planung Ihrer Netzverwaltung heranziehen können, finden Sie im Abschnitt Netz verwalten: Zu verwendende Load-Balancer-Features bestimmen.
Load Balancer ist eine Softwarelösung für die Verteilung eingehender Clientanforderungen auf mehrere Server. Dieses Produkt verbessert die Leistung von Servern erheblich, indem es TCP/IP-Sitzungsanforderungen auf verschiedene Server einer Gruppe verteilt. Dieser Lastausgleich ist für Benutzer und andere Anwendungen transparent. Load Balancer ist vor allem bei Anwendungen wie E-Mail-Servern, WWW-Servern, verteilten Abfragen paralleler Datenbanken und anderen TCP/IP-Anwendungen nützlich.
Beim Einsatz mit Webservern kann Load Balancer 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 Load Balancer automatisch den optimalen Server zur Bearbeitung eingehender Anforderungen suchen.
Load Balancer besteht aus den folgenden 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 (CBR, Content-Based Routing) verwenden, um die Last ausgehend vom Inhalt der Clentanforderung zu verteilen. Der ausgewählte Server ist das Ergebnis des Abgleichs des URL mit einer angegebenen Regel. Für die inhaltsabhängige Weiterleitung von Dispatcher (Weiterleitungsmethode "cbr") ist kein Caching Proxy erforderlich.
Weitere Informationen zu den Komponenten Dispatcher, CBR, Site Selector, Cisco CSS Controller und Nortel Alteon Controller finden Sie im Abschnitt Komponenten von Load Balancer.
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 Sie 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-Round-Robin-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 Load Balancer geführt. Dieses Produkt bietet gegenüber früheren Lösungen und Lösungen anderer Anbieter eine Vielzahl von Vorteilen:
Wenn die Anzahl der Clientanforderungen 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-Round-Robin-Methode häufig auftretenden Spitzenbelastungen auf ein Minimum reduziert werden.
Load Balancer benutzt TCP/IP-Standardprotokolle oder UDP/IP-Protokolle. 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 achtet der Dispatcher nur auf den beim Server eingehenden Datenverkehr vom Client, 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.
Dispatcher, Cisco CSS Controller und Nortel Alteon Controller sind Komponenten mit integrierter hoher Verfügbarkeit, für die eine Partnermaschine benutzt wird, die jederzeit die Weiterleitung von Paketen übernehmen kann, wenn die primäre Servermaschine ausfällt. Sollte einer der Server ausfallen, werden die Anfragen vom anderen Server bedient. Dies bedeutet, dass keiner der Server als Single Point of Failure eingesetzt werden muss. Die Site zeichnet sich somit durch hohe Verfügbarkeit aus.
Weitere Informationen finden Sie im Abschnitt Bereitstellung der hohen Verfügbarkeit durch Load Balancer.
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 Komponente Dispatcher erlaubt auch eine inhaltsabhängige Weiterleitung, erfordert jedoch nicht die Installation von Caching Proxy. Da die inhaltsabhängige Weiterleitung der Komponente Dispatcher beim Empfang von Paketen im Kernel ausgeführt wird, ist sie schneller als die der Komponente CBR. Die Komponente Dispatcher führt das inhaltsbasierte Routing für HTTP (unter Verwendung des Regeltyps "content") und für HTTPS (unter Verwendung der Affinität von SSL-Sitzungs-IDs) durch.
Die Dispatcher-Komponente stellt eine integrierte Funktion für hohe Verfügbarkeit bereit, so dass der Dispatcher nicht mehr als Single Point of Failure in Ihrem Netz eingesetzt werden muss. 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 Komponente Dispatcher gewährleistet außerdem eine wechselseitige hohe Verfügbarkeit, so dass sowohl die primäre als auch die sekundäre Maschine die jeweils andere Maschine als Ausweichmaschine nutzen kann. Weitere Informationen finden Sie im Abschnitt Hohe Verfügbarkeit konfigurieren.
Wenn Sie eine Client/Server-Konfiguration mit einer Dispatcher-Maschine verwenden, bei der der Datenverkehr auf mehrere Server mit CBR verteilt wird, können Sie auch mit der Komponente CBR ein hohes Maß an Verfügbarkeit erreichen.
Die Controller stellen eine Funktion für hohe Verfügbarkeit bereit, so dass der Controller nicht mehr als Single Point of Failure eingesetzt werden muss. Ein Controller auf einer Maschine kann als primärer Controller und ein Controller auf einer anderen Maschine als Ausweichcontroller konfiguriert werden. Der Ausweichcontroller überwacht den primären Controller und ist bereit, bei einem Ausfall des primären Controllers dessen Aufgaben zu übernehmen und den Switches Serverwertigkeiten zur Verfügung zu stellen. Weitere Informationen finden Sie im Abschnitt Hohe Verfügbarkeit.
Dieser Teil enthält einen Überblick über die Komponenten von Load Balancer und ist in die folgenden Abschnitte gegliedert:
Eine detaillierte Liste der Konfigurationsfunktionen der einzelnen Komponenten von Load Balancer, die Sie zur Planung Ihrer Netzverwaltung heranziehen können, finden Sie im Abschnitt Netz verwalten: Zu verwendende Load-Balancer-Features bestimmen.
Die fünf Komponenten von Load Balancer sind Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller und Nortel Alteon Controller. Load Balancer 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 Komponente Dispatcher 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, SIP sowie alle anderen TCP-basierten bzw. kontextlosen UDP-basierten Anwendungen.
Alle an die Dispatcher-Maschine gesendeten Clientanforderungen 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 Komponente Dispatcher ist der Schlüssel für eine stabile, effiziente Verwaltung eines großen skalierbaren Servernetzes. Mit Dispatcher können Sie viele einzelne Server so verbinden, dass sie ein virtueller Server zu sein scheinen. Besucher sehen Ihre Site daher unter einer 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 eine Gruppe von Servern und ermöglicht daher eine stabile und effiziente Verwaltung Ihrer Site.
In Abbildung 1 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 Dispatcher eine Clientanforderung an den optimalen Server übertragen hat, wird die Antwort mit der Weiterleitungsmethode "mac" ohne Eingriff von Dispatcher direkt vom Server an den Client gesendet.
Abbildung 2.
Beispielsite mit Dispatcher und Metric Server für die Verwaltung von Servern
In Abbildung 2 wird eine Site gezeigt, bei 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 Back-End-Servern installiert. Sie können Metric Server zusammen mit der Komponente Dispatcher oder einer beliebigen anderen Komponente von Load Balancer verwenden.
Abbildung 3. Beispielsite 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 3 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 Weiterleitungsmethode "nat" 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 finden Sie in den Abschnitten Dispatcher-Weiterleitungsmethode NAT/NAPT und Unterstützung für GRE (Generic Routing Encapsulation).
CBR arbeitet mit Caching Proxy zusammen, um Clientanforderungen 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 Clientantwortzeit 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 Komponente CBR verwendete Lastausgleichsalgorithmus ist mit dem bewährten Algorithmus identisch, der von der Komponente Dispatcher verwendet wird.
Wenn Caching Proxy eine Anfrage empfängt, wird diese mit den Regeln, die für die Komponente CBR 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 Verfügbarkeit, des SNMP-Subagenten, der Weitverkehrsunterstützung und einiger anderer Konfigurationsbefehle dieselben Funktionen wie der Dispatcher bereit.
CBR kann erst mit dem Lastausgleich für Clientanforderungen beginnen, wenn Caching Proxy aktiv ist.
Abbildung 4. Beispielsite mit
CBR für die Verwaltung lokaler Server
Abbildung 4 zeigt die logische Darstellung einer Site, bei der ein Teil der Inhalte von lokalen Servern mit CBR weitergeleitet wird. Die Komponente CBR leitet mit Caching Proxy Clientanforderungen (HTTP oder HTTPS) ausgehend vom Inhalt des URL an die Server weiter.
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 Clientanforderung 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 Load Balancer, 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 Last ist ein Maß für das Arbeitsaufkommen eines Servers. Durch Anpassung der Scriptdateien für Systemmetriken 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 5 stellt eine Site dar, bei der die Komponente Site Selector Anfragen beantwortet. Server 1, Server 2 und Server 3 sind lokale Server. Server 4, Server 5 und Server 6 sind ferne Server.
Ein Client fordert die Auflösung eines Domänennamens bei einem Clientnamensserver an. Der Clientnamensserver 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 Clientnamensserver zurück. Der Namensserver liefert die IP-Adresse an den Client.
Sobald der Client die IP-Adresse des Servers empfangen hat, leitet er Anwendungsanforderungen direkt an den ausgewählten Server weiter (Pfad 2).
Cisco CSS Controller 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 Load Balancer, um die Ladedaten und die Verfügbarkeit des Service (Anwendung oder Datenbank auf dem Back-End-Server) festzustellen. Cisco CSS Controller verwendet den Algorithmus für Wertigkeitsberechnung, die Standard- und angepassten Advisor-Funktionen sowie den Metric Server von Load Balancer, um die Metriken, den Zustand und die Auslastung des Services zu ermitteln. Aus diesen Informationen generiert der Cisco CSS Controller Servicewertigkeiten, die dann zur Erreichung einer optimalen Serviceauswahl sowie von Lastoptimierung und Fehlertoleranz an den Cisco CSS Switch gesendet werden.
Cisco CSS Controller protokolliert zahlreiche Kriterien. Dazu gehören unter anderem:
Wenn ein Cisco CSS Switch ohne Cisco CSS Controller den Zustand eines Inhalte bereitstellenden Services ermittelt, greift er dabei auf die Antwortzeiten für Inhaltsanfragen und andere Netzmetriken zurück. Wird der Cisco CSS Controller verwendet, gehen diese Aktivitäten vom Cisco CSS Switch auf den Cisco CSS Controller über. Cisco CSS Controller beeinflusst die Fähigkeit des Services, Inhalte bereitzustellen, und aktiviert einen Service als geeigneten Service, wenn dieser verfügbar ist, bzw. stellt ihn als geeigneten Service zurück, wenn er nicht mehr verfügbar ist.
Cisco CSS Controller:
Cisco CSS Controller 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 Serviceauslastung. Cisco CSS Controller ist Bestandteil einer ergänzenden Lösung für den Cisco CSS Switch und IBM WebSphere Application Server Load Balancer.
Nortel Alteon Controller ist in Verbindung mit der Alteon-Web-Switch-Familie von Nortel eine ergänzende Lösung, die die Geschwindigkeit und Kapazität der Switches im Bereich der Paketweiterleitung mit den ausgeklügelten Erkennungsalgorithmen von Load Balancer zur Bestimmung von Serverwertigkeiten verbindet.
Mit Nortel Alteon Controller können Sie angepasste Advisor-Funktionen entwickeln, die eine intelligentere und mehr auf die Anwendung zugeschnittene Bewertung der Verfügbarkeit und Auslastung von Anwendungen für die Implementierung von Services vornehmen können.
Metric Server stellt Informationen zur Systembelastung, z. B. zur Auslastung von CPU und Speicher, sowie ein Gerüst für die Entwicklung benutzerdefinierter Messungen zur Systembelastung bereit.
Nortel Alteon Controller stellt die verschiedensten Arten von Messdaten zusammen, um die Wertigkeit von Servern zu bestimmen, deren Arbeitslast von Nortel Alteon Web Switches verteilt wird. Dazu gehören unter anderem:
Nortel Alteon Controller kommuniziert mit dem Switch über SNMP. Die Komponente ruft Konfigurations-, Status- und Verbindungsdaten vom Switch ab. Wenn der Controller Serverwertigkeiten berechnet hat, werden diese auf dem Switch festgelegt. Der Switch verwendet die vom Controller definierten Wertigkeiten, um den Server auszuwählen, der Clientanforderungen für einen Service am besten bearbeiten kann.
Abbildung 7. Beispielsite mit Nortel Alteon Controller für die Verwaltung lokaler Server
Sie können den Controller von einem Browser, einer fernen GUI oder einer fernen Befehlszeilenschnittstelle aus verwalten.
Nortel Alteon Controller ist in Verbindung mit der Alteon-Web-Switch-Familie von Nortel eine Lösung, die das "Beste aus zwei Welten" auf sich vereint: super schnelle Paketvermittlung und ausgeklügelte Anwendungserkennung, Fehlertoleranz sowie optimale Serverauslastung. Nortel Alteon Controller ist Teil einer ergänzenden Lösung mit den Alteon-Web-Switches von Nortel und IBM WebSphere.
In den folgenden Abschnitten sind die Konfigurationsfunktionen der Komponenten von Load Balancer aufgelistet, so dass Sie bestimmen können, welche Features Sie für die Verwaltung Ihres Netzes benötigen:
Wenn Sie die Last optimal auf mehrere Server verteilen und sicherstellen möchten, dass stets der "richtige" Server ausgewählt wird, lesen Sie die folgenden Abschnitte:
Dispatcher unterstützt den Lastausgleich auf Servern für HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP sowie alle anderen TCP-basierten bzw. kontextlosen UDP-basierten Anwendungen.
_ Wenn Sie Load Balancer nicht von der Maschine aus konfigurieren möchten, auf der Load Balancer installiert ist, lesen Sie den Abschnitt Fernverwaltung von Load Balancer.
_ Falls Sie Dispatcher auf derselben Maschine ausführen möchten wie einen Webserver, dessen Last verteilt werden soll, lesen Sie die Informationen im Abschnitt Verknüpfte Server verwenden.
_ Falls Sie den Dispatcher einsetzen, um die Einschränkungen eines Single Point of Failure für Ihr Netz zu beseitigen, lesen Sie die Informationen in den Abschnitten Einfache hohe Verfügbarkeit und Wechselseitige hohe Verfügbarkeit.
Lastausgleich für SSL-Datenverkehr (HTTPS):
_ Wenn Sie sicherstellen möchten, dass der Client für mehrere Verbindungen denselben SSL-Server verwendet, lesen Sie den Abschnitt Funktionsweise der Affinität für Load Balancer.
_ Wenn Sie sicherstellen möchten, dass der Client für HTTP- und SSL-Datenverkehr denselben SSL-Server verwendet, lesen Sie den Abschnitt Crossport-Affinität.
_ Wenn Sie sicherstellen möchten, dass der Client für mehrere Verbindungen denselben Server verwendet, lesen Sie den Abschnitt Funktionsweise der Affinität für Load Balancer.
_ Wenn Sie sicherstellen möchten, dass eine Gruppe von Clients für mehrere Verbindungen denselben Server verwendet, lesen Sie den Abschnitt Affinitätsadressmaske (stickymask).
_ Wenn Sie einen Server aus der Konfiguration entfernen möchten (z. B. für eine Wartung), ohne den Clientdatenverkehr zu unterbrechen, lesen Sie den Abschnitt Bearbeitung von Serververbindungen stilllegen.
Sie können Clients für dieselbe Webadresse zu verschiedenen Servergruppen dirigieren, indem Sie Regeln zu Ihrer Dispatcher-Konfiguration hinzufügen. Weitere Informationen finden Sie im Abschnitt Regelbasierten Lastausgleich konfigurieren.
_ Falls Sie Clients ausgehend von der Quellen-IP-Adresse des Clients zu verschiedenen Servergruppen dirigieren möchten, lesen Sie den Abschnitt Auf der Client-IP-Adresse basierende Regeln verwenden.
_ Falls Sie Clients ausgehend vom Clientport zu verschiedenen Servergruppen dirigieren möchten, lesen Sie den Abschnitt Auf dem Clientport basierende Regeln verwenden.
_ Falls Sie Clients ausgehend von der Uhrzeit zu verschiedenen Servergruppen dirigieren möchten, lesen Sie den Abschnitt Auf der Uhrzeit basierende Regeln verwenden.
_ Wenn Sie Clients ausgehend von den TOS-Bits (Type of Service) in Netzpaketen zu bestimmten Servern dirigieren möchten, lesen Sie die Informationen im Abschnitt Auf der Serviceart basierende Regeln verwenden.
_ Falls Sie Clients ausgehend vom Datenverkehr der Site an verschiedene Servergruppen weiterleiten möchten, haben Sie die folgenden Möglichkeiten:
_ Wenn Sie die Anzahl der Verbindungen pro Sekunde verwenden möchten, lesen Sie den Abschnitt Regeln auf der Basis der Verbindungen pro Sekunde verwenden.
_ Wenn Sie die Gesamtanzahl der Verbindungen verwenden möchten, lesen Sie den Abschnitt Regeln auf der Basis der Summe aktiver Verbindungen verwenden.
_ Wenn Sie Bandbreite für verschiedene Webadressen reservieren und gemeinsam nutzen möchten, lesen Sie den Abschnitt Regeln auf der Basis reservierter Bandbreite und gemeinsam genutzter Bandbreite verwenden.
_ Wenn Sie sicherstellen möchten, dass Datenverkehr für jede Servergruppe exakt gemessen wird, lesen Sie den Abschnitt Regeloption für Serverauswertung.
_ Falls Sie überlaufenden Datenverkehr zu einer Standardgruppe von Servern dirigieren möchten (z. B. zu Servern, die die Antwort "Site ausgelastet" ausgeben), lesen Sie den Abschnitt Immer gültige Regeln verwenden.
_ Wenn Sie die Clientaffinität außer Kraft setzen möchten, um sicherzustellen, dass ein Client nicht an einen Überlaufserver gebunden bleibt, lesen Sie die Informationen im Abschnitt Portaffinität außer Kraft setzen.
Wenn Sie sicherstellen möchten, dass SSL-Clients ausgehend von der SSL-ID in der Clientanfrage zu demselben SSL-Server zurückkehren, lesen Sie den Abschnitt HTTPS (SSL).
Falls Sie HTTP-Clients mit Regeln, die auf dem URL-Inhalt der Clientanforderung basieren, an verschiedene Servergruppen weiterleiten möchten, lesen Sie die Informationen im Abschnitt Dispatcher-Weiterleitungsmethode "cbr" und im Abschnitt Auf dem Inhalt der Anforderung basierende Regeln verwenden.
_ Wenn Sie zwischen bestimmten URLs und ihren Serviceanwendungen unterscheiden möchten, lesen Sie den Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
_ Wenn Sie durch Cookies von Ihren Webservern sicherstellen möchten, dass Clients zu demselben Server zurückkehren, wenn sie in mehreren Verbindungen ähnliche Inhalte anfragen, lesen Sie die Informationen im Abschnitt Passive Cookie-Affinität.
_ Falls Sie den Webdatenverkehr auf Caching-Proxy-Server verteilen möchten, um das Zwischenspeichern eindeutiger Inhalte auf jedem einzelnen Server zu ermöglichen (und dadurch den Cache Ihrer Site vergrößern, da eine redundante Zwischenspeicherung von Inhalten auf mehreren Maschinen vermieden wird), lesen Sie den Abschnitt URI-Affinität.
Der Vorteil der Dispatcher-Weiterleitungsmethode "cbr" besteht darin, dass sie schneller auf Clientanforderungen reagiert als die Komponente CBR. Die Dispatcher-Weiterleitungsmethode "cbr" erfordert auch nicht die Installation und Verwendung von Caching Proxy.
Bei einem Netz mit sicherem SSL-Datenverkehr vom Client zum Server liegt der Vorteil der Komponente CBR (in Verbindung mit Caching Proxy) darin, dass CBR die für ein inhaltsabhängiges Routing erforderliche Verschlüsselung/Entschlüsselung durchführen kann. Bei vollständig gesicherten Verbindungen kann die Dispatcher-Weiterleitungsmethode "cbr" nur mit SSL-ID-Affinität konfiguriert werden, da sie nicht in der Lage ist, die für ein vom Inhalt des URL abhängiges Routing von Clientanforderungen erforderliche Verschlüsselung/Entschlüsselung vorzunehmen.
Ein Lastausgleich im Weitverkehrsnetz kann mit verschiedenen Methoden erreicht werden.
_ Falls Sie Last mit dem WAN-Feature von Dispatcher auf ferne Server verteilen möchten, lesen Sie die Informationen im Abschnitt Dispatcher-WAN-Unterstützung konfigurieren und Unterstützung für GRE (Generic Routing Encapsulation).
_ Wenn Sie Last mit der Dispatcher-Weiterleitungsmethode "nat" auf ferne Server verteilen möchten, lesen Sie den Abschnitt Dispatcher-Weiterleitungsmethode NAT/NAPT.
_ Wenn Sie die Last einer Webadresse auf mehrere Serverdämonen auf einer Maschine verteilen möchten, die jeweils an einem eindeutigen Port empfangsbereit sind, lesen Sie die Informationen im Abschnitt Dispatcher-Weiterleitungsmethode NAT/NAPT.
_ Falls der Dispatcher-Datenverkehr in einem anderen Netz als der Clientdatenverkehr bearbeitet werden soll (um Konkurrenzsituationen im externen Netz zu reduzieren und so den Durchsatz zu erhöhen), lesen Sie den Abschnitt Konfiguration für ein privates Netz verwenden.
_ Falls Sie mehrere Webadressen in einer Konfiguration kombinieren möchten, lesen Sie den Abschnitt Platzhaltercluster zum Zusammenfassen von Serverkonfigurationen verwenden.
_ Informationen zum Lastausgleich für Firewalls finden Sie im Abschnitt Platzhaltercluster für den Lastausgleich von Firewalls verwenden.
_ Wenn Sie den Datenverkehr für alle Zielports lenken möchten, lesen Sie den Abschnitt Platzhalterport für die Übertragung von Datenverkehr mit nicht konfiguriertem Port verwenden.
_ Informationen zur Erkennung möglicher DoS-Attacken (Denial of Service) finden Sie im Abschnitt Erkennung von DoS-Attacken.
_ Informationen zur Analyse des Serverdatenverkehrs können Sie dem Abschnitt Binäre Protokolle für die Analyse von Serverstatistiken verwenden entnehmen.
_ Falls Alerts generiert werden sollen, wenn Server als aktiv oder inaktiv markiert werden, lesen Sie die Informationen im Abschnitt Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden.
CBR integriert den Lastausgleich in Caching Proxy von WebSphere Application Server, um Clientanforderungen an angegebene HTTP- oder HTTPS-Server (SSL) weiterzuleiten. Für die Verwendung von CBR muss auf derselben Maschine Caching Proxy installiert und konfiguriert sein. Informationen zum Konfigurieren von Caching Proxy für die Verwendung von CBR finden Sie im Abschnitt Schritt 1. Caching Proxy für die Verwendung von CBR konfigurieren.
Bei Verwendung der Komponente CBR (oder der Dispatcher-Weiterleitungsmethode "cbr") ergeben sich für Ihre Clients die folgenden Vorteile:
_ Sie können Clientanforderungen nach verschiedenen Inhalten auf Servergruppen verteilen. (Weitere Informationen finden Sie im Abschnitt Anforderungen nach verschiedenen Inhalten verteilen.)
_ Sie können die Antwortzeit verkürzen, indem Sie den Inhalt der Site optimal auf mehrere Webserver verteilen. (Weitere Informationen finden Sie im Abschnitt Siteinhalt für kürzere Antwortzeiten aufteilen.)
_ Sie können bei einem Serverausfall einen unterbrechungsfreien Clientdatenverkehr gewährleisten, indem Sie jedem Inhaltstyp mehrere Server zuordnen. (Weitere Informationen finden Sie im Abschnitt Webserverinhalt sichern.)
Bei einem Netz mit sicherem SSL-Datenverkehr vom Client zum Server liegt der Vorteil der Komponente CBR (in Verbindung mit Caching Proxy) darin, dass CBR die für ein inhaltsabhängiges Routing erforderliche Verschlüsselung/Entschlüsselung durchführen kann.
Bei vollständig gesicherten SSL-Verbindungen kann die Dispatcher-Weiterleitungsmethode "cbr" nur mit SSL-ID-Affinität konfiguriert werden, da sie nicht in der Lage ist, die für ein vom Inhalt des URL abhängiges Routing von Clientanforderungen erforderliche Verschlüsselung/Entschlüsselung vorzunehmen.
Für HTTP-Datenverkehr besteht der Vorteil der Dispatcher-Weiterleitungsmethode "cbr" darin, dass sie schneller auf Clientanforderungen reagiert als die Komponente CBR. Die Dispatcher-Weiterleitungsmethode "cbr" erfordert auch nicht die Installation und Verwendung von Caching Proxy.
_ Wenn Sie Load Balancer nicht von der Maschine aus konfigurieren möchten, auf der Load Balancer installiert ist, lesen Sie den Abschnitt Fernverwaltung von Load Balancer.
_ CBR kann auf derselben Maschine wie ein am Lastausgleich beteiligter Server ausgeführt werden. Weitere Informationen finden Sie im Abschnitt Verknüpfte Server verwenden.
_ Wie Sie die CPU-Ausnutzung durch mehrere Caching-Proxy-Prozesse verbessern können, erfahren Sie im Abschnitt CPU-Nutzung mit mehreren Caching-Proxy-Prozessen verbessern.
Wenn Sie für SSL-Datenverkehr ein inhaltsabhängiges Routing ermöglichen wollen, können Sie wie folgt vorgehen:
_ Sie können auf beiden Seiten (Client-zu-Proxy und Proxy-zu-Server) sichere Verbindungen verwenden. Lesen Sie dazu den Abschnitt Lastausgleich für sichere Verbindungen (SSL).
_ Wenn Sie sichere Verbindungen nur vom Client zum Proxy verwenden möchten, lesen Sie den Abschnitt Lastausgleich für SSL-Datenverkehr vom Client zum Proxy und HTTP-Datenverkehr vom Proxy zum Server.
_ Wenn Sie zwischen bestimmten URLs und ihren Serviceanwendungen unterscheiden möchten, lesen Sie den Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Sie können Clients für dieselbe Webadresse zu verschiedenen Servergruppen dirigieren, indem Sie Regeln zu Ihrer CBR-Konfiguration hinzufügen. Weitere Informationen finden Sie im Abschnitt Regelbasierten Lastausgleich konfigurieren.
_ Falls Sie Client ausgehend vom Inhalt des angeforderten URLs an verschiedene Servergruppen weiterleiten möchten, lesen Sie den Abschnitt Auf dem Inhalt der Anforderung basierende Regeln verwenden.
_ Falls Sie Clients ausgehend von der Quellen-IP-Adresse des Clients zu verschiedenen Servergruppen dirigieren möchten, lesen Sie den Abschnitt Auf der Client-IP-Adresse basierende Regeln verwenden.
_ Falls Sie Clients ausgehend von der Uhrzeit zu verschiedenen Servergruppen dirigieren möchten, lesen Sie den Abschnitt Auf der Uhrzeit basierende Regeln verwenden.
_ Falls Sie Clients ausgehend vom Datenverkehr der Site an verschiedene Servergruppen weiterleiten möchten, haben Sie die folgenden Möglichkeiten:
Wenn Sie die Anzahl der Verbindungen pro Sekunde verwenden möchten, lesen Sie den Abschnitt Regeln auf der Basis der Verbindungen pro Sekunde verwenden.
Wenn Sie die Gesamtanzahl der Verbindungen verwenden möchten, lesen Sie den Abschnitt Regeln auf der Basis der Summe aktiver Verbindungen verwenden.
_ Wenn Sie überlaufenden Datenverkehr an eine Standardgruppe von Servern weiterleiten möchten (z. B. zu Servern, die die Antwort "Site ausgelastet" ausgeben), lesen Sie den Abschnitt Immer gültige Regeln verwenden.
_ Wenn Sie die Clientaffinität außer Kraft setzen möchten, um sicherzustellen, dass ein Client nicht an einen Überlaufserver gebunden bleibt, lesen Sie die Informationen im Abschnitt Portaffinität außer Kraft setzen.
_ Wenn Sie sicherstellen möchten, dass der Client für mehrere Verbindungen denselben Server verwendet, lesen Sie den Abschnitt Funktionsweise der Affinität für Load Balancer.
_ Wenn Sie einen Server aus der Konfiguration entfernen möchten (z. B. für eine Wartung), ohne den Clientdatenverkehr zu unterbrechen, lesen Sie den Abschnitt Bearbeitung von Serververbindungen stilllegen.
_ Falls Sie unabhängig von der Erstellung von Cookies durch Ihre Webserver sicherstellen möchten, dass Clients zu demselben Server zurückkehren, wenn sie in mehreren Verbindungen ähnliche Inhalte anfragen, lesen Sie die Informationen im Abschnitt Aktive Cookie-Affinität.
_ Wenn Sie durch Cookies von Ihren Webservern sicherstellen möchten, dass Clients zu demselben Server zurückkehren, wenn sie in mehreren Verbindungen ähnliche Inhalte anfragen, lesen Sie die Informationen im Abschnitt Passive Cookie-Affinität.
_ Falls Sie den Webdatenverkehr auf Caching-Proxy-Server verteilen möchten, um das Zwischenspeichern eindeutiger Inhalte auf jedem einzelnen Server zu ermöglichen (und dadurch den Cache Ihrer Site vergrößern, da eine redundante Zwischenspeicherung von Inhalten auf mehreren Maschinen vermieden wird), lesen Sie den Abschnitt URI-Affinität.
_ Falls Sie den Dispatcher in einer Client/Server-Konfiguration mit CBR einsetzen, um die Einschränkungen eines Single Point of Failure für Ihr Netz zu beseitigen, lesen Sie die Informationen im Abschnitt Bereitstellung der hohen Verfügbarkeit durch Load Balancer.
_ Informationen zur Analyse des Serverdatenverkehrs können Sie dem Abschnitt Binäre Protokolle für die Analyse von Serverstatistiken verwenden entnehmen.
_ Falls Alerts generiert werden sollen, wenn Server als aktiv oder inaktiv markiert werden, lesen Sie die Informationen im Abschnitt Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden.
Site Selector verteilt die Last einer Namensserveranforderung auf eine Gruppe von Servern.
_ Wenn Sie Load Balancer nicht von der Maschine aus konfigurieren möchten, auf der Load Balancer installiert ist, lesen Sie den Abschnitt Fernverwaltung von Load Balancer.
_ Site Selector kann auf derselben Maschine wie ein am Lastausgleich beteiligter Server ausgeführt werden. Dazu sind keine zusätzlichen Konfigurationsschritte erforderlich.
_ Die hohe Verfügbarkeit ist bei Verwendung mehrerer redundanter Site-Selector-Komponenten durch DNS-Methoden (Domain Name System) inhärent, sofern der Elternnamensserver korrekt konfiguriert ist und normale DNS-Wiederherstellungsmethoden zur Anwendung kommen. Beispiele für DNS-Wiederherstellungsmethoden sind die erneute Übertragung von Abfragen und die Wiederholung von Zonenübertragungen.
_ Falls Sie den Dispatcher in einer Client/Server-Konfiguration mit Site Selector einsetzen, um die Einschränkungen eines Single Point of Failure für Ihr Netz zu beseitigen, lesen Sie die Informationen im Abschnitt Bereitstellung der hohen Verfügbarkeit durch Load Balancer.
_ Wenn Sie sicherstellen möchten, dass der Client für mehrere Namensserveranforderungen denselben Server verwendet, lesen Sie den Abschnitt Funktionsweise der Affinität für Load Balancer.
_ Falls Sie die Standard-DNS-Methode anwenden und die Lebensdauer (TTL, Time To Live) festlegen möchten, um die Client-Server-Affinität zu gewährleisten, lesen Sie die Informationen im Abschnitt Hinweise zu TTL.
Sie können Clientanforderungen nach einer Domänennamensauflösung zu verschiedenen Servergruppen dirigieren, indem Sie Regeln zu Ihrer Site-Selector-Konfiguration hinzufügen. Weitere Informationen finden Sie im Abschnitt Regelbasierten Lastausgleich konfigurieren.
_ Falls Sie Clients ausgehend von der Quellen-IP-Adresse des Clients zu verschiedenen Servergruppen dirigieren möchten, lesen Sie den Abschnitt Auf der Client-IP-Adresse basierende Regeln verwenden.
_ Falls Sie Clients ausgehend von der Uhrzeit zu verschiedenen Servergruppen dirigieren möchten, lesen Sie den Abschnitt Auf der Uhrzeit basierende Regeln verwenden.
_ Falls Sie Clients ausgehend von den gemessenen Lastwerten zu verschiedenen Servergruppen dirigieren möchten, lesen Sie die folgenden Abschnitte:
_ Wenn Sie überlaufenden Datenverkehr an eine Standardgruppe von Servern weiterleiten möchten (z. B. zu Servern, die die Antwort "Site ausgelastet" ausgeben), lesen Sie den Abschnitt Immer gültige Regeln verwenden.
Site Selector kann in einem lokalen Netz (LAN) oder in einem Weitverkehrsnetz (WAN) ausgeführt werden.
WAN-Umgebung:
_ Falls Sie die Namensserveranforderungen von Clients mit einer gewichteten Round-Robin-Auswahlmethode verteilen möchten, sind keine zusätzlichen Konfigurationsschritte erforderlich.
_ Wenn die Nähe des Clientnamensservers im Netz zu den Servern, die die angeforderte Anwendung bereitstellen (den Zielservern), berücksichtigt werden soll, lesen Sie die Informationen im Abschnitt Netzproximität verwenden.
_ Falls Alerts generiert werden sollen, wenn Server als aktiv oder inaktiv markiert werden, lesen Sie die Informationen im Abschnitt Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden.
Cisco CSS Controller gestaltet den Serverlastausgleich von Cisco-Switches anwendungs- und systemspezifisch. Der Controller verwendet für die dynamische Berechnung von Serverwertigkeiten mehr anwendungs- und systemspezifische Metriken. Die Wertigkeiten werden dem Switch über SNMP bereitgestellt. Der Switch nutzt diese Wertigkeiten für die Verarbeitung von Clientanforderungen. Auf diese Weise wird die Auslastung optimiert und die Fehlertoleranz verbessert.
Wenn Sie die Last optimal auf mehrere Server verteilen und sicherstellen möchten, dass stets der "richtige" Server ausgewählt wird, lesen Sie die folgenden Abschnitte:
_ Lastausgleich mit Load Balancer optimieren
_ Advisor-Funktionen und Angepasste (anpassbare) Advisor-Funktionen erstellen
_ Wenn Sie Load Balancer nicht von der Maschine aus konfigurieren möchten, auf der Load Balancer installiert ist, lesen Sie den Abschnitt Fernverwaltung von Load Balancer.
_ Cisco CSS Controller kann auf derselben Maschine wie ein am Lastausgleich beteiligter Server ausgeführt werden. Dazu sind keine zusätzlichen Konfigurationsschritte erforderlich.
Cisco CSS Switch und Cisco CSS Controller besitzen beide eine Funktion für hohe Verfügbarkeit an, um die Einschränkungen eines Single Point of Failure für Ihr Netz zu beseitigen. Für den Switch können Sie die hohe Verfügbarkeit mit dem CSS-Redundanzprotokoll nutzen. Für Cisco CSS Controller müssen Sie ein internes Protokoll verwenden, das die Konfiguration von zwei Controllern im fehlertoleranten Modus ermöglicht.
Weitere Informationen zum Konfigurieren der hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit.
_ Informationen zur Analyse des Serverdatenverkehrs können Sie dem Abschnitt Binäre Protokolle für die Analyse von Serverstatistiken verwenden entnehmen.
_ Falls Alerts generiert werden sollen, wenn Server als aktiv oder inaktiv markiert werden, lesen Sie die Informationen im Abschnitt Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden.
Nortel Alteon Controller gestaltet den Serverlastausgleich für Alteon-Switches von Nortel anwendungs- und systemspezifisch. Der Controller verwendet für die dynamische Berechnung von Serverwertigkeiten mehr anwendungs- und systemspezifische Metriken. Die Wertigkeiten werden dem Switch über SNMP bereitgestellt. Der Switch nutzt diese Wertigkeiten für die Verarbeitung von Clientanforderungen. Auf diese Weise wird die Auslastung optimiert und die Fehlertoleranz verbessert.
Wenn Sie die Last optimal auf mehrere Server verteilen und sicherstellen möchten, dass stets der "richtige" Server ausgewählt wird, lesen Sie die folgenden Abschnitte:
_ Lastausgleich mit Load Balancer optimieren
_ Advisor-Funktionen und Angepasste (anpassbare) Advisor-Funktionen erstellen
_ Wenn Sie Load Balancer nicht von der Maschine aus konfigurieren möchten, auf der Load Balancer installiert ist, lesen Sie den Abschnitt Fernverwaltung von Load Balancer.
_ Nortel Alteon Controller kann auf derselben Maschine wie ein am Lastausgleich beteiligter Server ausgeführt werden. Dazu sind keine zusätzlichen Konfigurationsschritte erforderlich.
_ Der Nortel Alteon Web Switch und der Alteon Controller von Nortel bieten eine Funktion für hohe Verfügbarkeit an, um die Einschränkungen eines Single Point of Failure für Ihr Netz zu beseitigen. Für den Switch können Sie die hohe Verfügbarkeit nutzen, indem Sie für Verbindungen zu Servern und für Services ein Redundanzprotokoll verwenden. Für die hohe Verfügbarkeit des Nortel Alteon Controller müssen Sie ein internes Protokoll verwenden, das die Konfiguration von zwei Controllern im fehlertoleranten Modus ermöglicht.
Weitere Informationen zum Konfigurieren der hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit.
_ Informationen zur Analyse des Serverdatenverkehrs können Sie dem Abschnitt Binäre Protokolle für die Analyse von Serverstatistiken verwenden entnehmen.
_ Falls Alerts generiert werden sollen, wenn Server als aktiv oder inaktiv markiert werden, lesen Sie die Informationen im Abschnitt Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden.
Dieses Kapitel enthält Informationen zur Installation von Load Balancer mit den System-Tools für Paketinstallation und zu den Voraussetzungen für alle unterstützten Betriebssysteme.
Anweisungen für die Installation mit dem Installationsprogramm des Produkts können Sie dem Dokument Edge Components Konzepte, Planung und Installation entnehmen.
Java 2 SDK wird auf allen Plattformen automatisch mit Load Balancer installiert.
Wenn Sie vor der Installation eine frühere Version von Load Balancer migrieren oder ein Betriebssystem erneut installieren möchten, können Sie Ihre bisherigen Konfigurationsdateien oder Scriptdateien für Load Balancer sichern.
Die in diesem Abschnitt aufgelisteten Pakete mit Load-Balancer-Komponenten stehen nicht für alle Installationsarten zur Verfügung.
Informationen zu den Hardware- und Softwarevoraussetzungen, einschließlich der unterstützten Browser, finden Sie auf der folgenden Webseite: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
In Tabelle1 sind die installp-Images für Load Balancer
in der Reihenfolge aufgelistet, in der sie mit dem System-Tool für Paketinstallation installiert
werden sollten.
Tabelle 1. installp-Images für AIX
Basisprodukt | ibmlb.base.rte |
Administration (mit Nachrichten) |
|
Einheitentreiber | ibmlb.lb.driver |
Lizenz | ibmlb.lb.license |
Load-Balancer-Komponenten (mit Nachrichten) |
|
Dokumentation (mit Nachrichten) |
|
Metric Server | ibmlb.ms.rte |
Komponente kann folgende Werte annehmen: disp (Dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) oder nal (Nortel Alteon Controller). Wählen Sie (optional) die Komponenten aus, die Sie installieren möchten.
Sprache kann folgende Werte annehmen:
Das Dokumentationspaket enthält nur englische Dokumente. Übersetzungen des Load-Balancer-Dokumentationssets finden Sie auf der Website www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Haben Sie eine frühere Version installiert, entfernen Sie die Installation dieser Kopie, bevor Sie die aktuelle Version installieren. Vergewissern Sie sich zunächst, dass alle Steuerprogramme und Server gestoppt wurden. Geben Sie dann installp -u ibmlb (oder den früheren Namen, z. B. intnd) ein, um die Installation des gesamten Produkts zu entfernen. Wenn Sie bestimmte Dateigruppen deinstallieren möchten, listen Sie diese an Stelle des Paketnamens einzeln auf.
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 Load Balancer auf AIX-Systemen 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. Wenn Sie SMITTY verwenden, drücken Sie die Taste F10, um das Programm zu beenden.
Verwendung der Befehlszeile:
Wenn Sie die Installation von einer CD ausführen, müssen Sie die folgenden Befehle eingeben, um die CD anzuhängen:
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 Load Balancer auf AIX-Systemen zu installieren:
Tabelle 2. AIX-Installationsbefehle
Basisprodukt | installp -acXgd Einheit ibmlb.base.rte |
Administration (mit Nachrichten) | installp -acXgd Einheit ibmlb.admin.rte ibmlb.msg.language.admin |
Einheitentreiber | installp -acXgd Einheit ibmlb.lb.driver |
Lizenz | installp -acXgd Einheit ibmlb.lb.license |
Load-Balancer-Komponenten (mit Nachrichten). Dazu gehören Dispatcher, CBR, Site Selector, Cisco CSS Controller und Nortel Alteon Controller. | installp -acXgd Einheit ibmlb.Komponente.rte ibmlb.msg.Sprache.lb |
Dokumentation (mit Nachrichten) | installp -acXgd Einheit ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd Einheit ibmlb.ms.rte |
Einheit steht hier für Folgendes:
Achten Sie darauf, dass die Ergebnisspalte in der Zusammenfassung für alle installierten Komponenten von Load Balancer 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 ibmlb
Wurde das gesamte Produkt installiert, gibt dieser Befehl Folgendes zurück:
ibmlb.base.rte ibmlb.admin.rte ibmlb.lb.driver ibmlb.lb.license ibmlb.<Komponente>.rte ibmlb.doc.rte ibmlb.ms.rte ibmlb.msg.Sprache.admin ibmlb.msg.en_US.doc ibmlb.msg.Sprache.lb
Einige der Installationspfade von Load Balancer sind im Folgenden aufgelistet:
Für die Fernverwaltung von Load Balancer über Remote Method Invocation (RMI) müssen Sie die Verwaltungs-, Basis-, Komponenten- und Lizenzpakete auf dem Client installieren. Informationen zu RMI finden Sie im Abschnitt Remote Method Invocation (RMI).
Informationen zu den Hardware- und Softwarevoraussetzungen, einschließlich der unterstützten Browser, finden Sie auf der folgenden Webseite: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
In den folgenden Abschnitten wird erklärt, wie Load Balancer auf HP-UX-Systemen von der Produkt-CD installiert wird.
Vergewissern Sie sich vor Beginn des Installationsverfahrens, dass Sie die Root-Berechtigung für die Installation der Software haben.
Haben Sie eine frühere Version installiert, sollten Sie die Installation dieser Kopie entfernen, bevor Sie die aktuelle Version installieren. Vergewissern Sie sich zunächst, dass das Steuerprogramm und der Server gestoppt wurden. Verwenden Sie anschließend zum Deinstallieren von Load Balancer den Abschnitt Anweisungen für die Deinstallation der Pakete.
In Tabelle 3 sind die Namen der Installationspakete für
Load Balancer in der Reihenfolge aufgelistet, in der sie mit dem System-Tool für Paketinstallation
installiert werden sollten.
Tabelle 3. Details zur Paketinstallation von Load Balancer unter HP-UX
Paketbeschreibung | Name des HP-UX-Pakets |
Basisprodukt | ibmlb.base |
Verwaltung und Nachrichten | ibmlb.admin ibmlb.nlv-Sprache |
Lizenz für Load Balancer | ibmlb.lic |
Load-Balancer-Komponenten | ibmlb.Komponente |
Dokumentation | ibmlb.doc |
Metric Server | ibmlb.ms |
Anmerkung:
|
Nachfolgend sind die Schritte aufgeführt, die zur vollständigen Ausführung dieser Task erforderlich sind.
su - root Password: Kennwort
swinstall -s /Quelle Paketname
Hier steht Quelle für den absoluten Verzeichnispfad zur Position des Pakets und Paketname für den Namen des Pakets.
Der folgende Befehl installiert nur das Basispaket für Load Balancer (ibmlb.base) vom Ausgangsverzeichnis der CD aus:
swinstall -s /Quelle ibmlb.base
Setzen Sie den folgenden Befehl ab, wenn Sie alle Pakete für Load Balancer vom Ausgangsverzeichnis der CD aus installieren möchten:
swinstall -s /Quelle ibmlb
Setzen Sie den Befehl swlist ab, um alle installierten Pakete aufzulisten. Beispiel:
swlist -l fileset ibmlb
Verwenden Sie zum Deinstallieren der Pakete den Befehl swremove. Entfernen Sie die Pakete in der umgekehrten Reihenfolge, in der sie installiert wurden. Setzen Sie beispielsweise die folgenden Befehle ab:
swremove ibmlb
Für die Deinstallation eines einzelnen Pakets, z. B. der Komponente Dispatcher:
swremove ibmlb.disp
Die Hardware- und Softwarevoraussetzungen, einschließlich der unterstützten Browser, finden Sie auf der folgenden Webseite: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
In den folgenden Abschnitten wird erklärt, wie Load Balancer auf Linux-Systemen von der Produkt-CD installiert wird.
Vergewissern Sie sich vor Beginn des Installationsverfahrens, dass Sie die Root-Berechtigung für die Installation der Software haben.
Falls Sie eine frühere Version installiert haben, sollten Sie diese Kopie vor Installation der aktuellen Version deinstallieren.Deinstallierenunter Linux Vergewissern Sie sich zunächst, dass alle Steuerprogramme und Server gestoppt wurden. Geben Sie anschließend rpm -e Paketname ein, um das gesamte Produkt zu deinstallieren. Bei der Deinstallation ist die Reihenfolge umzukehren, die für die Installation der Pakete verwendet wurde. Damit wird sichergestellt, dass die Administrationspakete zuletzt deinstalliert werden.
Gehen Sie wie folgt vor, um Load Balancer zu installieren:
Das Installations-Image ist eine Datei im Format eLBLX-Version:tar.z.
Die folgende Liste enthält die mit RPM installierbaren Pakete.
Für diese Angaben gilt Folgendes:
Das Dokumentationspaket enthält nur englische Dokumente. Übersetzungen des Load-Balancer-Dokumentationssets finden Sie auf der Website www.ibm.com/software/webservers/appserv/ecinfocenter.html.
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 folgenden Befehl ab: rpm -i Paket.rpm
Red-Hat-Linux-Systeme: Wegen eines bekannten Problems von Red Hat Linux müssen Sie auch die _db*-RPM-Dateien löschen, da andernfalls ein Fehler auftritt.
rpm -qa | grep ibmlb
Wurde das gesamte Produkt installiert, wird eine Liste wie die folgende generiert:
Für die Fernverwaltung von Load Balancer über Remote Method Invocation (RMI) müssen Sie die Verwaltungs-, Basis-, Komponenten- und Lizenzpakete auf dem Client installieren. Informationen zu RMI finden Sie im Abschnitt Remote Method Invocation (RMI).
Informationen zu den Hardware- und Softwarevoraussetzungen, einschließlich der unterstützten Browser, finden Sie auf der folgenden Webseite: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
In den folgenden Abschnitten wird erklärt, wie Load Balancer auf Solaris-Systemen von der Produkt-CD installiert wird.
Vergewissern Sie sich vor Beginn des Installationsverfahrens, dass Sie die Root-Berechtigung für die Installation der Software haben.
Haben Sie eine frühere Version installiert, entfernen Sie die Installation dieser Kopie, bevor Sie die aktuelle Version installieren. Vergewissern Sie sich zunächst, dass alle Steuerprogramme (Executors) und Server gestoppt wurden. Geben Sie anschließend zum Deinstallieren von Load Balancer den Befehl "pkgrm Paketname" ein.
Gehen Sie wie folgt vor, um Load Balancer zu installieren:
Geben Sie an der Eingabeaufforderung pkgadd -d Pfadname" ein. Dabei ist Pfadname der Einheitenname des CD-ROM-Laufwerks oder das Verzeichnis auf dem Festplattenlaufwerk, in dem sich das Paket befindet. Beispiel: pkgadd -d /cdrom/cdrom0/.
Die folgende Liste zeigt die erforderlichen Pakete und die Reihenfolge, in der sie installiert werden sollten.
Das Dokumentationspaket (ibmlbdoc) enthält nur englische Dokumente. Übersetzungen des Load-Balancer-Dokumentationssets finden Sie auf der Website www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Sollen alle Pakete installiert werden, geben Sie einfach "all" ein, und drücken Sie die Eingabetaste. Sollen einzelne Komponenten installiert werden, geben Sie die Namen der zu installierenden Pakete durch ein Leerzeichen oder Komma getrennt ein, und drücken Sie anschließend die Eingabetaste. Möglicherweise werden Sie aufgefordert, Berechtigungen für vorhandene Verzeichnisse oder Dateien zu ändern. Drücken Sie einfach die Eingabetaste, 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 Eingabeaufforderungen mit "yes". Die Installation wird dann erfolgreich ausgeführt.
Wenn Sie beispielsweise nur die Komponente Dispatcher mit der Dokumentation und Metric Server installieren möchten, müssen Sie die Pakete ibmlbbase, ibmlbadm, imblblic, ibmdisp, ibmlbdoc und ibmlbms installieren.
Für die Fernverwaltung von Load Balancer über Remote Method Invocation (RMI) müssen Sie die Verwaltungs-, Basis-, Komponenten- und Lizenzpakete auf dem Client installieren. Informationen zu RMI finden Sie im Abschnitt Remote Method Invocation (RMI).
Für Load Balancer gelten die folgenden Installationspfade:
Informationen zu den Hardware- und Softwarevoraussetzungen, einschließlich der unterstützten Browser, finden Sie auf der folgenden Webseite: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
In den folgenden Abschnitten wird erklärt, wie Load Balancer auf Windows-Systemen von der Produkt-CD installiert wird.
Es wird eine Liste mit Paketen angezeigt, die installiert werden können:
Für die Fernverwaltung von Load Balancer über Remote Method Invocation (RMI) müssen Sie die Verwaltungs-, Lizenz- und Komponentenpakete auf dem Client installieren. Informationen zu RMI finden Sie im Abschnitt Remote Method Invocation (RMI).
Einschränkungen: Die Windows-Version von Load Balancer kann nicht auf derselben Maschine wie IBM Firewall installiert werden.
Vergewissern Sie sich vor Beginn der Installation, 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.Deinstallierenunter Linux Gehen Sie zum Deinstallieren mit der Option Software wie folgt vor:
Gehen Sie wie folgt vor, um Load Balancer zu installieren:
E:\setup
Einige der Installationspfade von Load Balancer sind im Folgenden aufgelistet:
Edge-Components-Fixpacks für die BEtriebssysteme AIX, HP-UX, Linux, Solaris und Microsoft Windows werden über folgende Medien bereitgestellt:
Informationen zu unterstützten Betriebssystemen finden Sie auf der IBM Unterstützungssite mit den detaillierten Systemvoraussetzungen für WebSphere Application Server.
Sie finden den Link zu den Refresh-Packs oder Fixpacks für Edge Components unter den empfohlenen Downloads für WebSphere Application Server der IBM Unterstützungssite.
Bevor Sie das Refresh- bzw. Fixpack installieren, müssen Sie alle vorhandenen Versionen von Load Balancer, die älter sind als die Version, auf die Sie das Upgrade durchführen möchten, stoppen und deinstallieren.
dscontrol executor stop
Die Executor-Funktion von Load Balancer kann aktiv sein, selbst wenn dsserver gestoppt ist. Wenn Sie eine Nachricht empfangen, dass dsserver nicht aktiv ist, starten Sie dsserver, und setzen Sie dann den Befehl erneut ab.
dsserver stop
Tabelle 4. Systemspezifische Befehle für die Deinstallation von Load Balancer
Systemspezifische Befehle für die Deinstallation von Load Balancer | |
---|---|
Plattform | Befehle |
AIX | Deinstallieren Sie
alle Load-Balancer-Produktpakete mit dem folgenden Befehl:
installp -u ibmlb |
HP-UX | Deinstallieren Sie
alle Load-Balancer-Produktpakete mit dem folgenden Befehl:
swremove ibmlb |
Linux |
|
Solaris |
|
Wenn Load Balancer nicht installiert ist, müssen Sie nur die Lizenzdatei für Load Balancer (lb70Full.LIC) installieren, bevor Sie ein Refresh- oder Fixpack installieren. Sie erhalten die Lizenz, indem Sie das Lizenzpaket für Load Balancer installieren.
Gehen Sie zum Installieren eines Fix- oder Refresh-Packs wie folgt vor:
Tabelle 5. Systemspezifische Befehle für die Installation eines Refresh- oder Fixpacks
Systemspezifische Befehle für die Installation eines Refresh- oder Fixpacks | |
---|---|
System | Befehle |
AIX |
|
HP-UX |
swinstall -s /Quelle Paketname Hier steht Quelle für das Verzeichnis zur Position des Pakets und Paketname für den Namen des Pakets. Setzen Sie beispielsweise den folgenden Befehl ab, um das Basispaket aus dem aktuellen Verzeichnis zu installieren: swinstall -s /lb ibmlb.base |
Linux |
rpm -iv Paketname Paketname steht für den Namen des Pakets. Der folgende Befehl installiert beispielsweise alle Pakete für Load Balancer, wenn sich die Pakete im aktuellen Verzeichnis befinden: rpm -iv ibmlb*.rpm
|
Solaris |
pkgadd -d Pfadname Paketname Hier steht Pfadname für das Verzeichnis zur Position des Pakets und Paketname für den Namen des Pakets. Setzen Sie beispielsweise den folgenden Befehl ab, um das Verwaltungspaket aus dem aktuellen Verzeichnis zu installieren: pkgadd -d . ibmlbadm |
In dieser Tabelle sind alle Pakete, die mit Edge Components geliefert werden, in der erforderlichen Installationsreihenfolge aufgelistet. Installieren Sie die Pakete, die im Refresh- bzw. Fixpack enthalten sind, entsprechend der in der folgenden Tabelle angegebenen Reihenfolge.
Liste der Pakete | |
Installierte Komponenten | (Generisch aufgelistete) Pakete in dieser Reihenfolge aktualisieren |
|
|
Dokumentation zu Edge Components | doc-Sprache |
Verwenden Sie das Setup-Programm für Edge Components für das Upgrade wie folgt:
Wenn das Refresh- bzw. Fixpack entfernt wird, werden bei den meisten Komponenten die Konfigurationsdateien im Verzeichnis "oldfiles/Komponente" gespeichert. Sie können diese Konfigurationsdateien mit der reinstallierten Version des Produkts verwenden, um die Konfiguration mit dem Patch-Code in der Version ohne den Patch-Code beizubehalten. Für die Komponente Load Balancer müssen Sie die Konfigurationsdateien manuell speichern, um die Konfiguration mit dem Patch-Code beizubehalten.
Dieser Teil enthält Informationen zu einer schnellen Erstkonfiguration sowie zur Planung und beschreibt die Konfigurationsmethoden für die Komponente Dispatcher von Load Balancer. Zu diesem Teil gehören die folgenden Kapitel:
Dieses Beispiel zeigt die Konfiguration von drei lokal angeschlossenen Workstations, die die Weiterleitungsmethode "mac" der Komponente Dispatcher 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.
Abbildung 8. Einfache lokale Dispatcher-Konfiguration
Die mac-Weiterleitung ist die Standardweiterleitungsmethode, bei der der Dispatcher eingehende Anforderungen auf die Server verteilt und der jeweilige Server die Antwort direkt an den Client zurückgibt. Weitere Informationen zur Dispatcher-Weiterleitungsmethode "mac" finden Sie im Abschnitt Dispatcher-Weiterleitungsmethode MAC.
In dem Beispiel für einen schnellen Start werden drei Workstations und vier IP-Adressen benötigt. Eine Workstation ist die CBR-Maschine, und die beiden anderen Workstations sind die Webserver. Jeder Webserver benötigt eine IP-Adresse. Die Dispatcher-Workstation muss zwei Adressen haben: die NFA (Non-Forwarding Address) und die Clusteradresse (für den Lastausgleich). Beide Adressen werden den Clients für den Zugriff auf Ihre Website zur Verfügung gestellt.
Workstation | Name | IP-Adresse |
---|---|---|
1 | server1.Intersplashx.com | 9.47.47.101 |
2 | server2.Intersplashx.com | 9.47.47.102 |
3 | server3.Intersplashx.com | 9.47.47.103 |
Netzmaske = 255.255.255.0 |
Jede Workstation enthält nur eine Standard-Ethernet-Netzschnittstellenkarte.
Name=www.Intersplashx.com IP=9.47.47.104
Fügen Sie zur Loopback-Schnittstelle von server2.Intersplashx.com und server3.Intersplashx.com einen Aliasnamen für www.Intersplashx.com hinzu.
ifconfig lo0 alias www.Intersplashx.com netmask 255.255.255.255
ifconfig lo0:1 plumb www.Intersplashx.com netmask 255.255.255.0 up
Sie haben jetzt alle für die beiden Webserverworkstations 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:
dscontrol executor start
dscontrol cluster add www.Intersplashx.com
dscontrol port add www.Intersplashx.com:80
dscontrol server add www.Intersplashx.com:80:server2.Intersplashx.com
dscontrol server add www.Intersplashx.com:80:server3.Intersplashx.com
dscontrol executor configure www.Intersplashx.com
dscontrol manager start
Der Dispatcher führt den Lastausgleich jetzt ausgehend von der Serverleistung durch.
dscontrol advisor start http 80
Der Dispatcher stellt jetzt sicher, dass keine Clientanforderungen an einen ausgefallenen Webserver gesendet werden.
Die Basiskonfiguration mit lokal angeschlossenen Servern ist damit vollständig.
Testen Sie wie folgt, ob die Konfiguration korrekt ist:
Informationen zur Verwendung der grafischen Benutzerschnittstelle von Dispatcher finden Sie in den Abschnitten GUI und Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
Informationen zur Verwendung des Konfigurationsassistenten finden Sie im Abschnitt Konfiguration mit dem Konfigurationsassistenten.
Es gibt viele Möglichkeiten, Load Balancer für die Unterstützung Ihrer Site zu konfigurieren. Wenn Sie für Ihre Site nur einen Hostnamen 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 Load Balancer kommuniziert. Sehen Sie sich die Abbildung 9 an.
Abbildung 9. Dispatcher-Beispielkonfiguration mit einem Cluster und zwei Ports
In diesem Beispiel ist für die Komponente Dispatcher 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 Load Balancer 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 10).
Abbildung 10. Dispatcher-Beispielkonfiguration mit zwei Clustern mit jeweils einem Port
In diesem Beispiel für die Komponente Dispatcher 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 Load Balancer 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 11).
Abbildung 11. Dispatcher-Beispielkonfiguration mit zwei Clustern mit jeweils zwei Ports
In diesem Beispiel für die Komponente Dispatcher wurden für die Sites www.productworks.com und www.testworks.com jeweils zwei Cluster mit Port 80 (HTTP) und Port 23 (Telnet) definiert.
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Komponente Dispatcher berücksichtigen muss.
Dieses Kapitel enthält die folgenden Abschnitte:
Der Dispatcher setzt sich aus den folgenden Funktionen zusammen:
Die Benutzung des Managers ist optional. Ohne den Manager wird der Lastausgleich nach einer gewichteten Round-Robin-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 Advisor-Funktion ping, 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 können auch eigene Advisor-Funktionen schreiben. (Lesen Sie hierzu die Informationen im Abschnitt Angepasste (anpassbare) Advisor-Funktionen.)
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 Round-Robin-Zeitplanung auf der Basis der aktuellen Serverwertigkeiten an.
Der Dispatcher stellt drei Weiterleitungsmethoden auf Portebene bereit: MAC-Weiterleitung, NAT/NAPT-Weiterleitung und CBR (inhaltsabhängige Weiterleitung).
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 dscontrol 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 finden Sie im Abschnitt dscontrol port -- Ports konfigurieren.
Einschränkung für Linux: Linux-Systeme nutzen ein hostgestütztes Modell, um Hardwareadressen über ARP für IP-Adressen zugänglich zu machen. Dieses Modell ist nicht mit den Anforderungen der Load-Balancer-Weiterleitungsmethode "mac" an einen Back-End-Server oder einen verknüpften Server mit hoher Verfügbarkeit kompatibel. Der Abschnitt Alternativen für die Festlegung eines Loopback-Aliasnamens unter Linux bei Verwendung der Load-Balancer-Weiterleitungsmethode "mac" beschreibt eine Reihe von Lösungen, wie Sie das Verhaltens des Linux-Systems so ändern können, dass es mit der Load-Balancer-Weiterleitungsmethode "mac" kompatibel ist.
Einschränkung für Linux auf zSeries- oder S/390-Servern: Wenn Sie zSeries- oder S/390-Server mit OSA-Karten (Open System Adapter) verwenden, gibt es Einschränkungen. Informationen zu möglichen Problemumgehungen finden Sie im Abschnitt Problem: Einschränkungen für die Dispatcher-Konfiguration unter Linux auf zSeries- oder S/390-Servern mit OSA-Karten.
Bei Verwendung der Dispatcher-Methode NAT (Konvertierung von Netzadressen) bzw. NAPT (Portumsetzung 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 an Stelle einer GRE/WAN-Kapselungstechnik die Weiterleitungsmethode "nat" 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:
Für die Dispatcher-Maschine benötigen Sie drei IP-Adressen: NFA, Clusteradresse und Rückkehradresse. Sie können NAT/NAPT wie folgt implementieren (vergleichen Sie hierzu auch den Abschnitt Beispielschritte für das Konfigurieren der Dispatcher-Weiterleitungsmethoden nat und cbr):
dscontrol server add Cluster:Port:Server mapport Wert returnaddress Rückkehradresse router Rückkehradresse
Dieser Parameter ordnet die (für den Dispatcher bestimmte) Nummer des Zielports für die Clientanforderung der Nummer des Serverports zu, an dem der Dispatcher die Clientanforderungen verteilt. Mit mapport kann Load Balancer 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 Zielports für die Clientanforderung.
Die Rückkehradresse ist eine eindeutige Adresse oder ein Hostname, die bzw. den Sie auf der Dispatcher-Maschine konfigurieren. Der Dispatcher verwendet die Rückkehradresse beim Lastausgleich für die Clientanforderung 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.
Wenn Sie die Weiterleitungsmethode "nat" oder "cbr" verwenden, müssen Sie eine Rückkehradresse für die Kommunikation zwischen Load Balancer und den Back-End-Servern definieren. Die Anzahl aktiver Verbindungen zwischen Load Balancer und dem Back-End-Server wird durch die Anzahl der Rückkehradressen beschränkt, die definiert sind. Load Balancer verwendet nur Ports, die auf der Rückkehradresse basieren, und keine Ports, die auf der Kombination von Rückkehradresse und Server basieren. Wenn alle verfügbaren Ports im Gebrauch sind, schlagen weitere Verbindungen fehl. Verwenden Sie in einer ausgelasteten Umgebung mehrere Rückkehradressen, um einen Engpass bei den verfügbaren Ports zu vermeiden.
Die Adresse des Routers zum fernen Server. Falls dies ein lokal angeschlossener Server ist, der sich nicht auf derselben Maschine wie Load Balancer befindet, geben Sie die Serveradresse ein. Befindet sich der Server auf derselben Maschine wie Load Balancer, verwenden Sie weiter die reale Router-Adresse.
Mit der Komponente Dispatcher können Sie das inhaltsbasierte 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 inhaltsbasierte Routing der Dispatcher-Weiterleitungsmethode "cbr" schneller als das der Komponente CBR, die Caching Proxy erfordert.
Für HTTP: Die Serverauswahl für das inhaltsbasierte Routing von Dispatcher basiert auf dem Inhalt eines URL oder eines HTTP-Headers. Sie wird mit dem Regeltyp content konfiguriert. Wenn Sie die Inhaltsregel 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 Clientanforderung angegebenen HTTP-Header.
Findet der Dispatcher die Zeichenfolge in der Clientanforderung, 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 Clientanforderung, wählt er keinen der für die Regel definierten Server aus.
Für HTTPS (SSL): Beim inhaltsbasierten Routing von Dispatcher erfolgt der Lastausgleich ausgehend vom Feld für die SSL-Sitzungs-ID in der Clientanforderung. Bei Verwendung von SSL enthält eine Clientanforderung 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. Indem Sie die Neuvereinbarung von SSL-Sicherheitsparametern, wie z. B. gemeinsam genutzten Schlüsseln und Verschlüsselungsalgorithmen, verhindern, werden CPU-Zyklen auf den Servern eingespart, und der Client erhält seine Antwort schneller. Zum Aktivieren der Affinität von SSL-Sitzungs-IDs muss als Protokolltyp für den Port SSL angegeben und der Parameter 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.
Für die Dispatcher-Maschine benötigen Sie drei IP-Adressen: NFA, Clusteradresse und Rückkehradresse. Gehen Sie zum Implementieren des inhaltsbasierten Routings von Dispatcher wie folgt vor (siehe auch Beispielschritte für das Konfigurieren der Dispatcher-Weiterleitungsmethoden nat und cbr):
dscontrol server add Cluster:Port:Server mapport Wert returnaddress Rückkehradresse router Rückkehradresse
dscontrol rule 125.22.22.03:80:contentRule1 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 Auf dem Inhalt der Anforderung basierende Regeln verwenden. Weitere Informationen zu gültigen Ausdrücken für Muster können Sie Anhang B. Syntax für Inhaltsregeln (Muster) entnehmen.
Abbildung 12. Beispiel für die Dispatcher-Weiterleitungsmethoden nat und cbr
Sie benötigen mindestens drei IP-Adressen für die Dispatcher-Maschine. Für das Beispiel in Abbildung 12 sind die folgenden Schritte notwendig, um eine Minimalkonfiguration der Dispatcher-Weiterleitungsmethoden nat und cbr zu erzielen:
1. Starten Sie den Executor. dscontrol executor start 2. Definieren Sie das Client-Gateway. dscontrol executor set clientgateway 1.2.3.5 ANMERKUNG: Wenn es in Ihrem Teilnetz keinen lokalen Router gibt, müssen Sie eine Maschine für die IP-Weiterleitung konfigurieren und diese als Client-Gateway verwenden. Anweisungen für das Aktivieren der IP-Weiterleitung finden Sie in der Dokumentation zum Betriebssystem. 3. Definieren Sie die Clusteradresse. dscontrol cluster add 1.2.3.44 4. Konfigurieren Sie die Clusteradresse. dscontrol executor configure 1.2.3.44 5. Definieren Sie den Port mit der Methode "nat" oder "cbr". dscontrol port add 1.2.3.44:80 method nat oder dscontrol port add 1.2.3.44:80 method cbr protocol http 6. Konfigurieren Sie eine Aliasrückkehradresse für Load Balancer (mit Ethernet-Karte 0). Anmerkung: Auf Linux-Systemen benötigen Sie keine Aliasrückkehradresse, wenn Sie auf einer verknüpften Maschine die Weiterleitungsmethode "nat" verwenden. dscontrol executor configure 10.10.10.99 Sie können auch den Befehl "ifconfig" verwenden (nur für Linux oder UNIX): AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0 HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up 7. Definieren Sie die Back-End-Server. dscontrol server add 1.2.3.4:80:192.10.10.10 router 10.10.10.6 returnaddress 10.10.10.99
Das Client-Gateway (1.2.3.5) ist die Adresse für Router 1 zwischen Load Balancer und dem Client. Der Router (10.10.10.6) ist die Adresse für Router 2 zwischen Load Balancer und dem Back-End-Server. Falls Sie die Adresse für das Client-Gateway und für Router 2 nicht kennen, können Sie ein Routenverfolgungsprogramm (traceroute) mit der Clientadresse (oder Serveradresse) verwenden, um die Router-Adresse zu bestimmen. Die genaue Syntax des Programms richtet sich nach dem von Ihnen verwendeten Betriebssystem. Weitere Informationen zu diesem Programm können Sie der Dokumentation zum Betriebssystem entnehmen.
Wenn sich der Server in demselben Teilnetz wie Load Balancer befindet (so dass traceroute keine Router zurückgibt), geben Sie die Serveradresse als Router-Adresse ein. Befindet sich der Server jedoch auf derselben Maschine wie Load Balancer, sollten Sie im Feld für die Router-ID an Stelle der Serveradresse die Router-Adresse eingeben. Die Router-Adresse ist die in Schritt 7 auf der Load-Balancer-Maschine für den Befehl "server add" verwendete Adresse.
Bei Anwendung der Serverpartitionierung können Sie zwischen URLs und ihren spezifischen Anwendungen unterscheiden. Ein Webserver kann beispielsweise JSPs, HTML-Seiten und GIF-Dateien bereitstellen, Datenbankabfragen bedienen usw. Load Balancer bietet jetzt die Möglichkeit, einen cluster- und portspezifischen 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 Load Balancer 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 detaillierter und dienstspezifisch verteilen und müssen sich nicht auf die Wertigkeit des Gesamtservers verlassen.
Die Serverpartitionierung kann in Verbindung mit der HTTP- und der HTTPS-Advisor-Funktion hilfreich sein. Wenn Sie beispielsweise einen HTML-Server für HTML- und GIF-Seiten sowie JSPs haben und den Server einmal unter Port 80 definieren (hinzufügen), erhalten Sie für den gesamten HTTP-Server nur einen Lastwert. Dies kann irreführend sein, weil es möglich ist, dass der GIF-Service auf dem Server nicht funktioniert. Der Dispatcher leitet GIF-Seiten unverändert an den Server weiter. Der Client sieht jedoch eine Zeitlimitüberschreitung oder einen Ausfall.
Wenn Sie den Server dreimal unter dem Port definieren (ServerHTML, ServerGIF, ServerJSP) und den Serverparameter advisorrequest für jeden logischen Server mit einer anderen Zeichenfolge definieren, können Sie den Zustand des jeweiligen Service auf dem Server abfragen. ServerHTML, ServerGIF und ServerJSP repräsentieren die drei logischen Server, die durch die Partitionierung eines physischen Servers entstanden sind. Für ServerJSP können Sie eine Zeichenfolge für advisorrequest definieren, um auf der Maschine zur Bearbeitung von JSPs den Service abzufragen. Für ServerGIF können Sie die Zeichenfolge "advisorrequest" so definieren, dass der GIF-Service abgefragt wird. Und für ServerHTML können Sie advisorrequest so definieren, das der HTML-Service abgefragt wird. Empfängt der Client keine Antwort von advisorrequest zur Abfrage des GIF-Services, registriert der Dispatcher, dass der logische Server (ServerGIF) inaktiv ist, die beiden anderen logischen Server jedoch weiterhin in gutem Zustand sein können. Der Dispatcher leitet keine weiteren GIFs an den physischen Server weiter, sendet jedoch unverändert JSP- und HTML-Anfragen an den Server.
Weitere Informationen zum Parameter advisorrequest finden Sie im Abschnitt Option "Anforderung/Antwort (URL)" der HTTP- oder HTTPS-Advisor-Funktion konfigurieren.
Innerhalb der 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 im IP-Adressenformat angegeben wird. Wenn Sie den Server als partitionierten Server definieren, müssen Sie den Befehl dscontrol server add mit einer auflösbaren Serveradresse des physischen Servers für den Parameter address angeben. Weitere Informationen finden Sie im Abschnitt dscontrol 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-Adresse 1.1.1.2) HTML-Server Server: B (IP-Adresse 1.1.1.2) GIF-Server Server: C (IP-Adresse 1.1.1.3) HTML-Server Server: D (IP-Adresse 1.1.1.3) JSP-Server Server: E (IP-Adresse 1.1.1.4) GIF-Server Server: F (IP-Adresse 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).
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 Clientdatenverkehr 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 oder die der Ausweichmaschine. 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.
In den Übertragungssitzungen zwischen den beiden Maschinen werden Überwachungssignale ausgetauscht. 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 und identisch konfiguriert sein.
Informationen zum Konfigurieren der hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit.
Abbildung 14. Beispiel für einen Dispatcher mit wechselseitiger hoher Verfügbarkeit
Für die wechselseitige hohe Verfügbarkeit sind zwei Dispatcher-Maschinen erforderlich. Beide Maschinen führen aktiv den Lastausgleich des Clientdatenverkehrs aus und sind gleichzeitig Partnermaschinen. In einer Konfiguration mit einfacher hoher Verfügbarkeit führt nur eine Maschine den Lastausgleich durch. In einer Konfiguration mit wechselseitiger hoher Verfügbarkeit verteilen beide Maschinen einen Teil des Clientdatenverkehrs.
Bei der wechselseitigen hohen Verfügbarkeit wird der Clientdatenverkehr den Dispatcher-Maschinen auf der Basis einer Clusteradresse zugeordnet. Jeder Cluster kann mit der nicht für Weiterleitungszwecke bestimmten Adresse (NFA, Non-Forwarding 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 wechselseitiger hoher Verfügbarkeit, bei der die "Clustergruppe A" und die "Clustergruppe B" gemeinsam genutzt 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 Ausweichcluster.
Informationen zum Konfigurieren der hohen Verfügbarkeit und der gegenseitigen hohen Verfügbarkeit finden Sie im Abschnitt Hohe Verfügbarkeit. .
Lesen Sie vor dem Ausführen der Schritte in diesem Teil den Abschnitt Planung für Dispatcher. Dieses Kapitel erläutert das Erstellen einer Basiskonfiguration für die Komponente Dispatcher von Load Balancer.
Vergewissern Sie sich vor Ausführung der Konfigurationsschritte in dieser
Tabelle, dass die
Dispatcher-Maschine und alle
Servermaschinen mit dem Netz verbunden sind,
gültige IP-Adressen haben und sich gegenseitig mit Ping-Aufrufen erreichen
können.
Tabelle 7. Konfigurations-Tasks für die Funktion Dispatcher
Task | Beschreibung | Referenzinformationen |
---|---|---|
Dispatcher-Maschine konfigurieren. |
Definieren Sie die Lastausgleichskonfiguration.
| Dispatcher-Maschine konfigurieren |
Am Lastausgleich beteiligte Maschinen konfigurieren. | Definieren Sie einen Aliasnamen auf der Loopback-Einheit. Überprüfen Sie, ob eine zusätzliche Route vorhanden ist, und löschen Sie zusätzliche Routen. | Servermaschinen für Lastausgleich konfigurieren |
Es gibt vier grundlegende Methoden für die Konfiguration des Dispatchers:
Die Befehlszeile ist die direkteste Methode für die Konfiguration des Dispatchers. Die Werte der Befehlsparameter müssen in englischen Zeichen eingegeben werden. Die einzige Ausnahme hiervon bilden Hostnamen (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:
Für die Parameter des Befehls "dscontrol" können Sie die Kurzform verwenden. 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 dscontrol he f an Stelle von dscontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl dscontrol ab, um die Eingabeaufforderung dscontrol aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Sie können Befehle zum Konfigurieren des Dispatchers in eine Konfigurationsscriptdatei eingeben und dann zusammen ausführen. Weitere Informationen finden Sie im Abschnitt Load-Balancer-Beispielkonfigurationsdateien.
dscontrol file appendload myscript
dscontrol file newload myscript
Führen Sie den folgenden Befehl aus, um die aktuelle Konfiguration in einer Scriptdatei (z. B. savescript) zu speichern:
dscontrol file save savescript
Dieser Befehl speichert die Konfigurationsscriptdatei im Verzeichnis ...ibm/edge/lb/servers/configurations/dispatcher.
Allgemeine Anweisungen und ein Beispiel zur grafischen Benutzerschnittstelle finden Sie in Abbildung 41.
Gehen Sie zum Starten der grafischen Benutzerschnittstelle wie folgt vor:
dsserver
Zum Konfigurieren der Dispatcher-Komponente über die grafische Benutzerschnittstelle müssen Sie zunächst in der Baumstruktur Dispatcher auswählen. Sie können den Executor und den Manager starten, nachdem 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 grafischen Benutzerschnittstelle können Sie dieselben Tasks wie mit dem Befehl dscontrol ausführen. Wenn Sie beispielsweise einen Cluster über die Befehlszeile definieren möchten, geben Sie den Befehl dscontrol cluster add Clustername ein. 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 Clusteradresse 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 in der grafischen Benutzerschnittstelle befindliche Menü Datei bietet Ihnen die Möglichkeit, die aktuellen Hostverbindungen in einer Datei zu speichern oder Verbindungen aus vorhandenen Dateien für alle Komponenten von Load Balancer wiederherzustellen.
Die Konfigurationsbefehle können auch auf einem fernen System ausgeführt werden. Weitere Informationen finden Sie im Abschnitt Remote Method Invocation (RMI).
Wenn Sie von der GUI aus einen Befehl ausführen möchten, gehen Sie wie folgt vor: Heben Sie in der GUI-Baumstruktur den Hostknoten hervor, und wählen Sie im Popup-Menü "Host" Befehl senden... aus. Geben Sie im Befehlseingabefeld den gewünschten Befehl ein, z. B. executor report. In einem Fenster sehen Sie die Ergebnisse und die Historie der in der aktuellen Sitzung ausgeführten Befehle.
Sie können auf Hilfe zugreifen, indem Sie auf das Fragezeichen in der oberen rechten Ecke des Fensters von Load Balancer klicken.
Weitere Informationen zur Verwendung der grafischen Benutzerschnittstelle finden Sie in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
Führen Sie folgende Schritte aus, wenn Sie den Konfigurationsassistenten verwenden:
dsserver
Der Assistent führt Sie schrittweise durch den Prozess zum Erstellen einer Basiskonfiguration für die Komponente Dispatcher. 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.
Vor dem Konfigurieren der Dispatcher-Maschine müssen Sie (auf AIX-, HP-UX-, Linux- oder Solaris-Systemen) als Root oder (auf Windows-Systemen) als Administrator registriert sein.
Auf allen unterstützten Plattformen kann Load Balancer einen verknüpften Server haben. Dies bedeutet, dass sich Load Balancer physisch auf einer Servermaschine befinden kann, für die er einen Lastausgleich durchführt.
Wenn Sie die Weiterleitungsmethode "mac" anwenden möchten, benötigen Sie für die Dispatcher-Maschine mindestens zwei gültige IP-Adressen. Bei Verwendung der Weiterleitungsmethode "cbr" oder "nat" sind mindestens drei gültige IP-Adressen erforderlich:
Diese IP-Adresse ist die primäre IP-Adresse der Dispatcher-Maschine und wird als NFA (Non-Forwarding 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-Subagenten) 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 Clusteradresse ist eine Adresse, die einem Hostnamen 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.
Der Dispatcher verwendet die Rückkehradresse beim Lastausgleich für die Clientanforderung 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 Anzahl aktiver Verbindungen zwischen Load Balancer und dem Back-End-Server wird durch die Anzahl der Rückkehradressen beschränkt, die definiert sind. Load Balancer verwendet nur Ports, die auf der Rückkehradresse basieren, und keine Ports, die auf der Kombination von Rückkehradresse und Server basieren. Wenn alle verfügbaren Ports im Gebrauch sind, schlagen weitere Verbindungen fehl. Verwenden Sie in einer ausgelasteten Umgebung mehrere Rückkehradressen, um einen Engpass bei den verfügbaren Ports zu vermeiden.
Nur Solaris-Systeme:
Editieren Sie beispielsweise die Datei /opt/ibm/edge/lb/servers/ibmlb.conf wie folgt, um die Standardeinstellung zu ändern:
Sollen mehrere Adaptertypen unterstützt werden, kopieren Sie die Zeile in der Datei "ibmlb.conf", und passen Sie die einzelnen Zeilen an den Einheitentyp an.
Wenn Sie vorhaben, zwei 100-Mbit/s-Ethernet-Adapter zu verwenden, muss die Datei "ibmlb.conf" eine Zeile mit der Einheitenangabe eri enthalten.
Falls Sie einen 10-Mbit/s-Ethernet-Adapter und einen 100-Mbit/s-Ethernet-Adapter verwenden möchten, müssen Sie in der Datei "ibmlb.conf" zwei Zeilen angeben, eine Zeile für die Einheit le und eine für die Einheit eri.
ifconfig -a
Beispiel: Sie erhalten die folgende Ausgabe:
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 9.42.93.208 netmask fffffc00 broadcast 9.42.95.255 ether 0:3:ba:2d:24:45
In diesem Fall bearbeiten Sie die Datei "ibmlb.conf" wie folgt:
eri -1 0 ibmlb
Sind die beiden Cluster X und Y für einen der in ibmlb.conf aufgelisteten Adapter beispielsweise für die Komponente CBR konfiguriert, werden die Cluster X und Y aus der Konfiguration entfernt, sobald der Befehl dscontrol executor start oder dscontrol 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.
Vergewissern Sie sich, dass die IP-Weiterleitung für das TCP/IP-Protokoll nicht aktiviert ist.
Abbildung 15 zeigt eine Beispielkonfiguration für einen Dispatcher mit einem einzigen Cluster, zwei Ports und drei Servern.
Abbildung 15. Beispiel der für die Load-Balancer-Maschine erforderlichen IP-Adressen
Hilfe zu den in dieser Prozedur verwendeten Befehlen finden Sie im Abschnitt Befehlsreferenz für Dispatcher und CBR.
Eine Beispielkonfigurationsdatei finden Sie im Abschnitt Beispielkonfigurationsdateien für Load Balancer.
AIX-, HP-UX-, Linux- oder Solaris-Systeme: Geben Sie zum Starten der Serverfunktion dsserver ein.
Windows-Systeme: Die Serverfunktion wird automatisch als Dienst gestartet.
Geben Sie zum Starten der Executor-Funktion den Befehl dscontrol executor start ein. Sie können jetzt auch verschiedene Executor-Einstellungen ändern. Weitere Informationen finden Sie im Abschnitt Befehlsreferenz für Dispatcher und CBR.
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 Hostname.
Geben Sie zum Definieren der NFA den Befehl dscontrol executor set nfa IP-Adresse ein oder editieren Sie die Beispielkonfigurationsdatei. Die IP-Adresse ist entweder ein symbolischer Name oder die IP-Adresse.
Der Dispatcher verteilt die Last der an die Clusteradresse 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 Platzhaltercluster definiert. Setzen Sie zum Definieren eines Clusters den Befehl dscontrol cluster add ab. Setzen Sie zum Definieren von Clusteroptionen den Befehl dscontrol cluster set ab, oder verwenden Sie die GUI zum Absetzen von Befehlen. Platzhaltercluster können verwendet werden, wenn mehrere IP-Adressen für den Lastausgleich eingehender Pakete in Frage kommen. Weitere Informationen finden Sie in den Abschnitten Platzhaltercluster zum Zusammenfassen von Serverkonfigurationen verwenden, Platzhaltercluster für den Lastausgleich von Firewalls verwenden und Platzhaltercluster mit Caching Proxy für transparente Weiterleitung verwenden.
Nachdem der Cluster definiert wurde, müssen Sie normalerweise die Clusteradresse auf einer der Netzschnittstellenkarten der Dispatcher-Maschine konfigurieren. Setzen Sie dazu den Befehl dscontrol executor configure Clusteradresse ab. Damit wird nach einem Adapter mit einer vorhandenen Adresse gesucht, die zu demselben Teilnetz wie die Clusteradresse gehört. Anschließend wird der Adapterkonfigurationsbefehl des Betriebssystems für die Clusteradresse unter Verwendung des gefundenen Adapters und der Netzmaske für die auf diesem Adapter vorhandene Adresse abgesetzt. Beispiel:
dscontrol executor configure 204.67.172.72
In manchen Fällen soll die Clusteradresse 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 "executor configure" auch nicht ausführen, wenn Sie im Standalone-Modus das Beispielscript goIdle verwenden. Informationen zum Script goIdle finden Sie im Abschnitt Scripts verwenden.
In seltenen Fällen haben Sie möglicherweise eine Clusteradresse, die mit keinem Teilnetz für vorhandene Adressen übereinstimmt. Verwenden Sie in diesem Fall die zweite Form des Befehls "executor configure", und geben Sie explizit den Schnittstellennamen und die Netzmaske an. Verwenden Sie dscontrol executor configure Clusteradresse Schnittstellenname Netzmaske.
Beispiele:
dscontrol executor configure 204.67.172.72 en0 255.255.0.0 (AIX-Systeme) dscontrol executor configure 204.67.172.72 eth0:1 255.255.0.0 (Linux-Systeme) dscontrol executor configure 204.67.172.72 eri0 255.255.0.0 (Solaris-Systeme) dscontrol executor configure 204.67.172.72 en1 255.255.0.0 (Windows-Systeme)
Für die zweite Form des Befehls executor configure müssen Sie auf Windows-Systemen 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:
In der Anzeige erscheint eine Ausgabe. Suchen Sie in den Zeilen, die auf Number of NIC records folgen, nach der IP-Adresse Ihrer Load-Balancer-Maschine, um den für die Load-Balancer-Konfiguration zu verwendenden Schnittstellennamen zu bestimmen.
Die IP-Adresse Ihrer Load-Balancer-Maschine wird wie folgt aufgelistet: ia->ia_addr. Der zugehörige Schnittstellenname wird mit ifp->if_name angegeben.
Die mit dem Befehl executor configure zugewiesenen Schnittstellennamen werden den in diesem Befehl aufgelisteten Schnittstellennamen zugeordnet.
Nachdem Sie diese Zuordnungsinformationen erhalten haben, können auf der Netzschnittstelle einen Aliasnamen für die Clusteradresse festlegen.
Auf Linux- oder UNIX-Systemen führt der Befehl "executor configure" ifconfig-Befehle aus.
Bei der Verwendung von bindungsspezifischen Serveranwendungen, die an eine Liste von IP-Adressen gebunden sind, zu denen die IP-Adresse des Servers nicht gehört, verwenden Sie den Befehl arp publish anstelle von ifconfig, damit auf der Load-Balancer-Maschine dynamisch eine IP-Adresse festgelegt wird. Beispiel:
arp -s <cluster> <MAC-Adresse von Load Balancer> pub
Zum Definieren eines Ports können Sie den Befehl dscontrol port add Cluster:Port eingeben, die Beispielkonfigurationsdatei editieren oder die GUI verwenden. Cluster ist entweder der symbolische Name oder die IP-Adresse. Port ist die Nummer des Ports, den Sie für dieses Protokoll verwenden. Sie können jetzt auch verschiedene Porteinstellungen ändern. Sie müssen alle Server für einen Port definieren und konfigurieren. Weitere Informationen finden Sie im Abschnitt Befehlsreferenz für Dispatcher und CBR.
Mit der Portnummer 0 (null) wird ein Platzhalterport angegeben. Dieser Port akzeptiert Datenverkehr, der nicht für einen der definierten Ports eines Clusters bestimmt ist. Der Platzhalterport 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 Platzhalterports finden Sie im Abschnitt Platzhalterport für die Übertragung von Datenverkehr mit nicht konfiguriertem Port verwenden.
Geben Sie zum Definieren einer am Lastausgleich beteiligten Servermaschine den Befehl dscontrol 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 IP-Adressen. 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 Komponente Dispatcher die Last auf bindungsspezifische Server verteilt, müssen die Server so konfiguriert werden, dass sie an die Clusteradresse gebunden werden. Da der Dispatcher Pakete ohne Änderung der Ziel-IP-Adresse weiterleitet, enthalten die beim Server eingehenden Pakete noch immer die Clusteradresse als Ziel. Wenn ein Server für die Bindung an eine andere IP-Adresse als die Clusteradresse konfiguriert ist, kann der Server für den Cluster bestimmte Anforderungen nicht akzeptieren.
Mit dem Befehl netstat -an können Sie feststellen, ob der Server bindungsspezifisch ist. Achten Sie auf den Server:Port. Wenn der Server nicht bindungsspezifisch ist, gibt der Befehl 0.0.0.0:80 zurück. Andernfalls sehen Sie eine Adresse wie 192.168.15.103:80.
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 Komponente Dispatcher muss die verknüpfte Servermaschine mit dem Befehl dscontrol 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 "dscontrol server" finden Sie im Abschnitt dscontrol server -- Server konfigurieren.
Die Managerfunktion verbessert den Lastausgleich. Soll der Manager gestartet werden, geben Sie den Befehl dscontrol 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:
dscontrol advisor start http PortEine Liste der Advisor-Funktionen mit den zugehörigen Standardports finden Sie im Abschnitt Befehlsreferenz für Dispatcher und CBR. Beschreibungen der einzelnen Advisor-Funktionen finden Sie im Abschnitt Liste der Advisor-Funktionen.
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 Clusterproportionen den Befehl dscontrol cluster set Cluster proportions ab. Weitere Informationen finden Sie im Abschnitt Proportionale Bedeutung von Statusinformationen.
Führen Sie die nachstehenden Schritte aus, wenn eine der folgenden Bedingungen erfüllt ist:
Anmerkungen:
Wird die Weiterleitungsmethode "mac" verwendet, verteilt der Dispatcher die Last nur auf Server, 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 Lastausgleich 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 Clusteradresse setzen (oder bevorzugt einen Aliasnamen für die Clusteradresse angeben). Bei Verwendung der Weiterleitungsmethode "mac" ändert die Komponente Dispatcher nicht die Ziel-IP-Adresse des TCP/IP-Pakets, bevor sie dieses an eine TCP-Servermaschine weiterleitet. Wird die Loopback-Einheit auf die Clusteradresse gesetzt oder diese Adresse als Aliasname der Loopback-Einheit festgelegt, akzeptieren die am Lastausgleich beteiligten Servermaschinen ein an die Clusteradresse gerichtetes Paket.
Falls Ihr Betriebssystem Aliasnamen auf Netzschnittstellen unterstützt (wie es bei AIX-, HP-UX-, Linux-, Solaris- oder Windows-Systemen der Fall ist), sollten Sie auf der der Loopback-Einheit einen Aliasnamen für die Clusteradresse festlegen. Ein Betriebssystem mit Unterstützung für Aliasnamen bringt den Vorteil, dass die am Lastausgleich beteiligten Servermaschinen für mehrere Clusteradressen konfiguriert werden können.
WICHTIG: Informationen zu Linux-Systemen finden Sie im Abschnitt Alternativen für die Festlegung eines Loopback-Aliasnamens unter Linux bei Verwendung der Load-Balancer-Weiterleitungsmethode "mac".
Wenn das Betriebssystem Ihres Servers keine Aliasnamen unterstützt, müssen Sie die Loopback-Einheit auf die Clusteradresse setzen.
Verwenden Sie den in Tabelle 8 angegebenen betriebssystemspezifischen Befehl,
um
die Adresse der Loopback-Einheit oder einen Aliasnamen für die Einheit zu definieren.
Tabelle 8. Befehle zum Festlegen eines Aliasnamens auf der Loopback-Einheit (lo0) für Dispatcher
Unter einigen Betriebssystemen wurde möglicherweise eine Standardroute erstellt, die entfernt werden muss.
route print
WICHTIGER HINWEIS: Unter Windows 2003 müssten alle zusätzlichen Routen ignoriert werden. Falls nach dem Konfigurieren des Aliasnamens Probleme beim Routing auftreten, entfernen Sie den Aliasnamen und fügen Sie ihn dann mit einer anderen Netzmaske wieder hinzu.
netstat -nr
Windows-Beispiel:
Aktive Routen: Netzadresse Netzmaske Gateway-Adresse Schnittstelle Metrik 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 9 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 9. Befehle zum Löschen zusätzlicher Routen 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 Load Balancer 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 ifconfig die Schnittstelle auf die Clusteradresse gesetzt haben. Vergewissern Sie sich, dass keine Maschine einen veröffentlichten Eintrag arp für die Clusteradresse hat.
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
Einige Linux-Versionen setzen für jede auf der Maschine konfigurierte IP-Adresse auf allen Schnittstellen der Maschine eine ARP-Antwort ab. Linux kann außerdem für ARP-Abfragen who-has ausgehend von allen auf der Maschine vorhandenen IP-Adressen eine ARP-Quellen-IP-Adresse auswählen, ohne dabei die Schnittstellen zu berücksichtigen, für die diese Adressen konfiguriert sind. Dies führt dazu, dass der gesamte Clusterdatenverkehr auf unkontrollierte Weise an nur einen Server weitergeleitet wird.
Wenn Sie die Dispatcher-Weiterleitungsmethode "mac" verwenden, müssen Sie durch einen Mechanismus sicherstellen, dass die Stacks der Back-End-Server an den Cluster adressierten Datenverkehr akzeptieren können. Wenn sowohl die hohe Verfügbarkeit als auch die Verknüpfung aktiviert ist, gehört zu diesen Back-End-Servern auch die verknüpfte Bereitschaftsmaschine für hohe Verfügbarkeit.
In den meisten Fällen müssen Sie auf der Loopback-Einheit einen Aliasnamen für die Clusteradresse festlegen. Bei Back-End-Servern muss daher auf der Loopback-Einheit ein Aliasname für den Cluster definiert sein. Falls Sie mit hoher Verfügbarkeit und Verknüpfung arbeiten, müssen Sie auf der Loopback-Einheit der Bereitschaftsserver für Lastausgleich Clusteraliasnamen festlegen.
Um sicherzustellen, dass Linux-Systeme Adressen nicht auf der Loopback-Einheit zugänglich machen, können Sie eine der folgenden vier Lösungen nutzen, die Linux-Systeme mit der Dispatcher-Weiterleitungsmethode "mac" kompatibel machen.
# sysctl -w net.ipv4.conf.all.hidden=1 net.ipv4.conf.lo.hidden=1Anschließend können Sie ganz normal Aliasnamen für Cluster festlegen. Beispiel:
# ifconfig lo:1 $CLUSTER_ADDRESS netmask 255.255.255.255 up
# sysctl -w net.ipv4.conf.all.arp_ignore=3 net.ipv4.conf.all.arp_announce=2Anschließend müssen Sie die Aliasnamen für die Cluster mit folgendem Befehl definieren:
# ip addr add $CLUSTER_ADDRESS/32 scope host dev loIn Konfigurationen mit hoher Verfügbarkeit muss ein ähnlicher Befehl in den go*-Scripts enthalten sein.
# iptables -t nat -A PREROUTING -d $CLUSTER_ADDRESS -j REDIRECTDieser Befehl veranlasst Linux-Systeme, für jedes Paket ein DNAT (Destination NAT) durchzuführen, bei dem die Clusteradressen in die Schnittstellenadressen konvertiert werden. Die Kehrseite dieser Methode ist jedoch, dass bei den Verbindungen pro Sekunde ein Durchsatzrückgang von ca. 6,4 % zu verzeichnen ist. Diese Methode funktioniert nur bei unterstützten Stock Distributionen. Es ist weder ein Kernel-Modul noch ein Patch-Build oder eine Patch-Installation erforderlich.
# modprobe noarp # noarpctl add $CLUSTER_ADDRESS Adresse_der_primären_NICHier steht Adresse_der_primären_NIC für eine Adresse in demselben Teilnetz wie die Clusteradresse. Anschließend können Sie ganz normal Aliasnamen für Cluster festlegen. Beispiel:
# ifconfig lo:1 Clusteradresse netmask 255.255.255.255 up
Dieser Teil enthält Informationen zu einer schnellen Erstkonfiguration sowie zur Planung und beschreibt die Konfigurationsmethoden für die Komponente CBR von Load Balancer. Zu diesem Teil gehören die folgenden Kapitel:
Dieses Beispiel zeigt die Konfiguration von drei lokal angeschlossenen Workstations, die CBR mit Caching Proxy verwenden, um den Webdatenverkehr auf zwei Webserver zu verteilen. (Der Einfachheit halber zeigt dieses Beispiel die Server innerhalb desselben LAN-Segments. Bei der Verwendung von CBR müssen sich die Server jedoch nicht in demselben LAN befinden.)
Abbildung 16. Einfache lokale CBR-Konfiguration
In dem Beispiel für einen schnellen Start werden drei Workstations und vier IP-Adressen benötigt. Eine Workstation wird als CBR-Maschine verwendet; die beiden anderen Workstations werden als Webserver verwendet. Jeder Webserver benötigt eine IP-Adresse. Die CBR-Workstation benötigt eine eigene Adresse und eine Adresse für den Lastausgleich.
Für die Verwendung von CBR muss auf demselben Server Caching Proxy installiert sein. Informationen zum Konfigurieren von Caching Proxy für CBR finden Sie im Abschnitt Schritt 1. Caching Proxy für die Verwendung von CBR konfigurieren.
Workstation | Name | IP-Adresse |
---|---|---|
1 | server1.mywebsite.com | 9.27.27.101 |
2 | server2.mywebsite.com | 9.27.27.102 |
3 | server3.mywebsite.com | 9.27.27.103 |
Netzmaske = 255.255.255.0 |
Jede Workstation enthält nur eine Standard-Ethernet-Netzschnittstellenkarte.
Name= www.mywebsite.com IP=9.27.27.104
Für CBR können Sie eine Konfiguration unter Verwendung der Befehlszeile, des Konfigurationsassistenten oder der grafischen Benutzerschnittstelle (GUI) erstellen. Dieses Beispiel für schnellen Start zeigt die Ausführung der Konfigurationsschritte in der Befehlszeile.
Führen Sie an einer Eingabeaufforderung die folgenden Schritte aus:
cbrcontrol executor start
ibmproxy
cbrcontrol cluster add www.mywebsite.com
cbrcontrol port add www.mywebsite.com:80
cbrcontrol server add www.mywebsite.com:80:server2.mywebsite.com
cbrcontrol server add www.mywebsite.com:80:server3.mywebsite.com
cbrcontrol rule add www.mywebsite.com:80:memberRule type content pattern uri=*/member/*
cbrcontrol rule add www.mywebsite.com:80:guestRule type content pattern uri=*/guest/*
In diesem Beispiel werden Clientanforderungen an die Website "www.mywebsite.com" bei Anwendung der Inhaltsregel ausgehend von einem Verzeichnis in ihrem URI-Anforderungspfad an verschiedene Server gesendet. Weitere Informationen finden Sie in Anhang B. Syntax für Inhaltsregeln (Muster).
cbrcontrol rule useserver www.mywebsite:80:memberRule server2.mywebsite.com
cbrcontrol rule useserver www.mywebsite:80:guestRule server3.mywebsite.com
CBR führt den Lastausgleich jetzt ausgehend von der Inhaltsregel durch. Ein Client mit einer URL-Anforderung, die /member/ enthält, wird an server2.mywebsite.com weitergeleitet. Ein Client mit einer URL-Anforderung, die /guest/ enthält, wird an server3.mywebsite.com weitergeleitet.
cbrcontrol manager start
cbrcontrol advisor start http 80
CBR stellt jetzt sicher, dass keine Clientanforderungen an einen ausgefallenen Webserver gesendet werden.
Die Basiskonfiguration mit lokal angeschlossenen Servern ist damit vollständig.
Testen Sie wie folgt, ob die Konfiguration korrekt ist:
cbrcontrol server report www.mywebsite.com:80:Die Einträge der Spalte "Summe Verbindungen" für beide Server sollten addiert 2 ergeben.
Informationen zur Verwendung der grafischen Benutzerschnittstelle von CBR finden Sie im Abschnitt Grafische Benutzerschnittstelle und in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
Informationen zur Verwendung des CBR-Assistenten finden Sie im Abschnitt Konfigurationsassistent.
Es gibt viele Möglichkeiten, CBR für die Unterstützung Ihrer Site zu konfigurieren. Wenn Sie für Ihre Site nur einen Hostnamen 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 CBR kommuniziert. Sehen Sie sich die Abbildung 9 an.
Abbildung 17. CBR-Beispielkonfiguration mit einem Cluster und zwei Ports
In diesem Beispiel ist für die Komponente CBR 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 CBR 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 10).
Abbildung 18. CBR-Beispielkonfiguration mit zwei Clustern mit jeweils einem Port
In diesem Beispiel für die Komponente CBR 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 CBR 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 11).
Abbildung 19. CBR-Beispielkonfiguration mit zwei Clustern mit jeweils zwei Ports
In diesem Beispiel für die Komponente CBR wurden für die Sites www.productworks.com und www.testworks.com jeweils zwei Cluster mit Port 80 (HTTP) und Port 443 (SSL) definiert.
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Komponente CBR mit Caching Proxy berücksichtigen muss.
Dieses Kapitel enthält die folgenden Abschnitte:
Mit der Komponente CBR können Sie unter Verwendung von Caching Proxy zum Weiterleiten der Anforderung HTTP- und SSL-Datenverkehr verteilen. Mit CBR können Sie einen Lastausgleich für Server durchführen, die Sie in der CBR-Konfigurationsdatei mit cbrcontrol-Befehlen konfiguriert haben.
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 Round-Robin-Zeitplanung und ausgehend von den aktuellen Serverwertigkeiten durchgeführt. Es stehen keine Advisor-Funktionen zur Verfügung.
Die drei wichtigsten Funktionen der Komponente CBR (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 Komponente CBR 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 Clientanforderung 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.
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. Dies 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 bereits registrierten Clients verwendet werden könnten. Außerdem könnten Sie leistungsstärkere Workstation verwenden, um Services für die registrierten Clients zur Verfügung zu stellen.
Sie könnten natürlich die oben genannten Methoden kombinieren, um eine noch größere Flexibilität und einen noch besseren Service zu erreichen.
Da CBR die Angabe mehrerer Server für jede Art von Anforderung zulässt, können die Anforderungen so verteilt werden, dass eine optimale Clientantwortzeit erreicht wird. Aufgrund der Möglichkeit, jedem Inhaltstyp mehrere Server zuzuordnen, sind Sie abgesichert, wenn eine Workstation oder ein Server ausfällt. CBR erkennt den Ausfall und verteilt die Clientanforderungen auf die übrigen Server der Gruppe.
Caching Proxy kommuniziert über die zugehörige Plug-in-Schnittstelle mit einem CBR-Prozess. Voraussetzung dafür ist, dass CBR auf der lokalen Maschine aktiv ist. Da dies zwei separate Prozesse sind, können mehrere Instanzen von Caching Proxy aktiv sein und mit einer Instanz von CBR zusammenarbeiten. Mit dieser Konfiguration können Sie die Adressen oder Funktionen unter den Caching Proxies aufteilen oder die Ressourcennutzung der Maschine Verbessern, weil der Clientdatenverkehr von mehreren Caching Proxies bearbeitet wird. Die Proxy-Instanzen können, je nach den Erfordernissen des Datenverkehrs, an verschiedenen Ports empfangsbereit sein oder an eindeutige IP-Adressen eines Ports gebunden werden.
CBR überprüft zusammen mit Caching Proxy HTTP-Anforderungen anhand angegebener Regeltypen. Wenn Caching Proxy aktiv ist, akzeptiert es Clientanforderungen 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 ("always true") 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.)
Weitere Informationen finden Sie im Abschnitt Regelbasierten Lastausgleich konfigurieren.
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.
Zusätzlich zu den Änderungen an der Datei "ibmproxy.conf" für CBR müssen Sie der Datei "ibmproxy.conf" 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 Clusteradresse (z. B. ClusterA).
Die Komponente CBR 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 eingehende Port ist. Nachfolgend sehen Sie ein Beispiel für das Hinzufügen eines Ports mit dem Schlüsselwort mapport. Der Clientport ist 443 (SSL) und der Serverport 80 (HTTP):
cbrcontrol server add Cluster:443 mapport 80
Die Portnummer für mapport kann eine beliebige positive ganze Zahl sein. Die Standardportnummer ist der Wert des vom Client eingehenden 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 eingehenden) 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 dem Ausführen der Schritte in diesem Teil den Abschnitt Planung für Content Based Routing. In diesem Kapitel wird erklärt, wie eine Basiskonfiguration für die Komponente CBR von Load Balancer erstellt wird.
Vergewissern Sie sich vor Ausführung der Konfigurationsschritte in dieser Tabelle, dass die CBR-Maschine und alle Servermaschinen mit dem Netz verbunden sind, gültige IP-Adressen haben und sich mit Ping-Aufrufen erreichen können.
Tabelle 10. Konfigurations-Tasks für die Komponente CBR
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 Komponente CBR von Load Balancer:
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 Hostnamen (die z. B. in den Befehlen "cluster" und "server" verwendet werden) und Dateinamen.
Starten Sie CBR wie folgt von der Befehlszeile aus:
Auf Windows-Systemen: Klicken Sie auf Start > Einstellungen (für Windows 2000) > Systemsteuerung > Verwaltung > Dienste. Klicken Sie mit der rechten Maustaste auf IBM Content Based Routing, und wählen Sie Starten aus. Zum Stoppen des Service führen Sie dieselben Schritte aus, wählen aber Stoppen 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 an Stelle von cbrcontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl cbrcontrol ab, um die cbrcontrol-Eingabeaufforderung 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 Inhaltsregel 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 uri=/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 "uri=/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 Konfigurationsscriptdatei eingegeben und dann zusammen ausgeführt werden.
cbrcontrol file appendload myscript
cbrcontrol file newload myscript
Führen Sie den folgenden Befehl aus, um die aktuelle Konfiguration in einer Scriptdatei (z. B. savescript) zu speichern:
cbrcontrol file save savescript
Dieser Befehl speichert die Scriptdatei mit der Konfiguration im Verzeichnis ...ibm/edge/lb/servers/configurations/cbr.
Allgemeine Anweisungen und ein Beispiel zur grafischen Benutzerschnittstelle finden Sie in Abbildung 41.
Gehen Sie zum Starten der GUI wie folgt vor:
Zum Konfigurieren der Komponente CBR über die grafische Benutzerschnittstelle müssen Sie zunächst in der Baumstruktur Content Based Routing auswählen. Sie können den Manager starten, nachdem 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.
Über die grafische Benutzerschnittstelle können Sie die gleichen Schritte wie mit dem Befehl cbrcontrol ausführen. Wenn Sie beispielsweise einen Cluster über die Befehlszeile definieren möchten, geben Sie den Befehl cbrcontrol cluster add Clustername ein. 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 im Dialogfenster die Clusteradresse ein, und klicken Sie 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. Das oben in der grafischen Benutzerschnittstelle befindliche Menü Datei bietet Ihnen die Möglichkeit, die aktuellen Hostverbindungen in einer Datei zu speichern oder Verbindungen aus vorhandenen Dateien für alle Komponenten von Load Balancer wiederherzustellen.
Sie können auf Hilfe zugreifen, indem Sie auf das Fragezeichen in der oberen rechten Ecke des Fensters von Load Balancer klicken.
Wenn Sie von der GUI aus einen Befehl ausführen möchten, gehen Sie wie folgt vor: Heben Sie in der GUI-Baumstruktur den Hostknoten hervor, und wählen Sie im Popup-Menü "Host" Befehl senden... aus. Geben Sie im Befehlseingabefeld den gewünschten Befehl ein, z. B. executor report. In einem Fenster sehen Sie die Ergebnisse und die Historie der in der aktuellen Sitzung ausgeführten Befehle.
Weitere Informationen zur Verwendung der grafischen Benutzerschnittstelle finden Sie in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
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.
Auf AIX-, HP-UX-, Linux- oder Solaris-Systemen: Geben Sie zum Starten von Caching Proxy ibmproxy ein.
Für Windows-Systeme: Rufen Sie zum Starten von Caching Proxy die Anzeige "Dienste" auf: Start > Einstellungen (für Windows 2000) > Systemsteuerung > Verwaltung > Dienste.
Der CBR-Assistent führt Sie schrittweise durch den Prozess zum Erstellen einer Basiskonfiguration für die Komponente CBR. 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.
Vor dem Konfigurieren der Maschine mit CBR müssen Sie (auf AIX-, HP-UX-, Linux- oder Solaris-Systemen) als Root oder (auf Windows-Systemen) als Administrator registriert sein.
Sie benötigen für jeden zu konfigurierenden Servercluster eine IP-Adresse. Eine Clusteradresse ist eine Adresse, die einem Hostnamen zugeordnet ist (beispielsweise www.firma.com). Diese IP-Adresse wird von einem Client benutzt, um die Verbindung zu den Servern in einem Cluster herzustellen. Diese Adresse ist in der URL-Anforderung von dem Client enthalten. CBR verteilt alle Anforderungen, die an dieselbe Clusteradresse gerichtet sind.
Nur für Solaris-Systeme: 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:
Vergewissern Sie sich, dass die eingehende URL-Anweisung CacheByIncomingUrl auf off (Standardeinstellung) gesetzt ist.
Fügen Sie in der Konfigurationsdatei für jeden Cluster zum Abschnitt mit den Zuordnungsregel eine ähnliche Zuordnungsregel wie die folgende hinzu:
Proxy /* http://cluster.domain.com/* cluster.domain.com
Für das CBR-Plug-in müssen Sie vier Einträge editieren:
Nachfolgend sehen Sie die spezifischen Zusätze zur Konfigurationsdatei für die einzelnen Betriebssysteme.
Abbildung 20. CBR-Konfigurationsdatei für AIX-, Linux- und Solaris-Systeme
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerTerm
Abbildung 21. CBR-Konfigurationsdatei für HP-UX-Systeme
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerTerm
Abbildung 22. CBR-Konfigurationsdatei für Windows-Systeme
ServerInit C:\Programme\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerInit PostAuth C:\Programme\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostAuth PostExit C:\Programme\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostExit ServerTerm C:\Programme\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerTerm
Geben Sie zum Starten der CBR-Serverfunktion in der Befehlszeile cbrserver ein.
Eine Standardkonfigurationsdatei (default.cfg) wird beim Starten von cbrserver automatisch 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. Weitere Informationen finden Sie im Abschnitt dscontrol executor -- Executor steuern.
CBR verteilt die an den Cluster gesendeten Anforderungen auf die entsprechenden Server, die für die Ports dieses Clusters konfiguriert wurden.
Der Cluster ist der symbolische Name im Hostabschnitt des URL und muss mit dem in der Proxy-Anweisung der Datei "ibmproxy.conf" verwendeten Namen übereinstimmen.
In CBR definierte Cluster sollten so definiert werden, dass sie mit der eingehenden Anforderung übereinstimmen. Ein Cluster muss mit dem Hostnamen oder der IP-Adresse definiert werden, der bzw. die in der eingehenden Anforderung enthalten ist. Wird die Anforderung beispielsweise mit der IP-Adresse eingegeben, muss der Cluster mit der IP-Adresse definiert sein. Falls mehrere Hostnamen in eine IP-Adresse aufgelöst werden (und Anforderungen mit jedem dieser Hostnamen eingehen können), sollten alle Hostnamen als Cluster definiert sein.
Setzen Sie zum Definieren eines Clusters den folgenden Befehl ab:
cbrcontrol cluster add Cluster
Setzen Sie zum Festlegen von Clusteroptionen den folgenden Befehl ab:
cbrcontrol cluster set Wert_der_Clusteroption
Weitere Informationen finden Sie im Abschnitt Befehlsreferenz für Dispatcher und CBR.
Wenn Sie Caching Proxy als Reverse Proxy konfiguriert haben und einen Lastausgleich für mehrere Websites durchführen, müssen Sie die Clusteradresse jeder Website zu mindestens einer Netzschnittstellenkarte der Load-Balancer-Maschine hinzufügen. Andernfalls kann dieser Schritt übergangen werden.
Auf AIX-, HP-UX-, Linux- oder Solaris-Systemen fügen Sie die Clusteradresse mit dem Befehl "ifconfig"
der Netzschnittstellenkarte hinzu. Den Befehl für das von Ihnen verwendete Betriebssystem
können Sie Tabelle 11 entnehmen.
Tabelle 11. Befehle zum Erstellen eines Aliasnamens auf der NIC
AIX | ifconfig Schnittstellenname Alias Clusteradresse Netzmaske Netzmaske |
HP-UX | ifconfig Schnittstellenname Clusteradresse Netzmaske Netzmaske up |
Linux | ifconfig Schnittstellenname Clusteradresse Netzmaske Netzmaske up |
Solaris 8, Solaris 9 und Solaris 10 | ifconfig Schnittstellenname addif Clusteradresse Netzmaske Netzmaske up |
Für Windows 2000: Gehen Sie zum Hinzufügen der Clusteradresse zur Netzschnittstelle wie folgt vor:
Für Windows 2003: Gehen Sie zum Hinzufügen der Clusteradresse zur Netzschnittstelle wie folgt vor:
Die Portnummer 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 Portoptionen den folgenden Befehl ab:
cbrcontrol port set Cluster:Wert_der_Portoption
Weitere Informationen finden Sie im Abschnitt Befehlsreferenz für Dispatcher und CBR.
Die Servermaschinen sind die Maschinen, auf denen die Anwendungen ausgeführt werden, deren Last verteilt werden soll. Für 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 Inhaltsregel 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 Clientanforderungen verglichen wird. Weitere Informationen zum Konfigurieren des Musters finden Sie in Anhang B. Syntax für Inhaltsregeln (Muster).
Einige der anderen in Dispatcher definierten Regeltypen können ebenfalls für CBR verwendet werden. Weitere Informationen finden Sie im Abschnitt Regelbasierten Lastausgleich konfigurieren.
Wenn für eine Clientanforderung 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 Managerfunktion 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 Clusterproportionen den Befehl cbrcontrol cluster set Cluster proportions ab. Weitere Informationen finden Sie im Abschnitt Proportionale Bedeutung von Statusinformationen.
/opt/ibm/edge/lb/servers/lib
/opt/ibm/edge/lb/servers/lib
C:\Programme\IBM\edge\lb\servers\lib
Starten Sie in der neuen Umgebung, indem Sie an der Eingabeaufforderung den Befehl ibmproxy absetzen.
Führen Sie die folgenden Schritte aus, um CBR zu konfigurieren:
Dieser Teil enthält Informationen zu einer schnellen Erstkonfiguration sowie zur Planung und beschreibt die Konfigurationsmethoden für die Komponente Site Selector von Load Balancer. Zu diesem Teil gehören die folgenden Kapitel:
Dieses Beispiel für einen schnellen Start zeigt das Erstellen einer Sitekonfiguration, bei der Site Selector den Datenverkehr ausgehend von dem in einer Clientanforderung verwendeten Domänennamen auf die Server einer Gruppe verteilt.
Abbildung 23. Einfache Site-Selector-Konfiguration
Für dieses Beispiel für schnellen Start benötigen Sie Folgendes:
In diesem Beispiel für schnellen Start ist die Domäne der Firmensite mywebshop.com. Site Selector ist für eine Unterdomäne innerhalb von mywebshop.com verantwortlich. Sie müssen daher eine Unterdomäne von mywebshop.com definieren. Beispiel: apps.mywebshop.com. Site Selector ist kein vollständig implementierter DNS wie BIND und fungiert in einer DNS-Hierarchie als Blattknoten. Site Selector ist für die Unterdomäne apps.mywebshop.com autoritativ. Die Unterdomäne apps.mywebshop.com umfasst die folgenden Sitenamen: marketing.apps.mywebshop.com und developer.apps.mywebshop.com.
apps.mywebshop.com. IN NS siteselector.mywebshop.com
Für Site Selector können Sie eine Konfiguration unter Verwendung der Befehlszeile, des Konfigurationsassistenten oder der grafischen Benutzerschnittstelle (GUI) erstellen. Dieses Beispiel für schnellen Start zeigt die Ausführung der Konfigurationsschritte in der Befehlszeile.
Führen Sie an einer Eingabeaufforderung die folgenden Schritte aus:
sscontrol nameserver start
sscontrol sitename add marketing.apps.mywebshop.com
sscontrol sitename add developer.apps.mywebshop.com
sscontrol server add marketing.apps.mywebshop.com:server1+server2
sscontrol server add developer.apps.mywebshop.com:server3+server4
sscontrol manager start
sscontrol advisor start http marketing.apps.mywebshop.com:80
sscontrol advisor start ftp developer.apps.mywebshop.com:21
Site Selector stellt jetzt sicher, dass keine Clientanforderungen an einen ausgefallenen Server gesendet werden.
Die Basiskonfiguration für Site Selector ist damit vollständig.
Testen Sie wie folgt, ob die Konfiguration korrekt ist:
sscontrol server status marketing.apps.mywebshop.com:
sscontrol server status developer.apps.mywebshop.com:
Der Eintrag unter "Summe Treffer" müsste für jeden Server den abgesetzten ping- und Anwendungsanforderungen entsprechen.
Informationen zur Verwendung der grafischen Benutzerschnittstelle von Site Selector finden Sie im Abschnitt Grafische Benutzerschnittstelle und in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
Informationen zur Verwendung des Site-Selector-Assistenten können Sie dem Abschnitt Konfigurationsassistent entnehmen.
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 Metriken und Wertigkeiten. Sie können eine Sitekonfiguration erstellen, bei der die Last innerhalb einer Servergruppe auf der Grundlage des für eine Clientanforderung verwendeten Domänennamens verteilt wird.
Einschränkungen: Site Selector unterstützt nur DNS-Abfragen des Typs A. Bei allen anderen Abfragetypen erscheint der Rückkehrcode NOTIMPL (nicht implementiert). Falls eine ganze Domäne an Site Selector delegiert wird, stellen Sie sicher, dass die Domäne nur Abfragen des Typs A empfängt.
Abbildung 24. 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 24): 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. Auf AIX-Systemen würde ein solcher Namensservereintrag etwa wie folgt aussehen:
siteload.firma.com. IN NS siteselector.firma.com.
Hier ist siteselector.firma.com der Hostname 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 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. (Site Selector arbeitet als nicht rekursiver Namensserver (Blattknotenserver) und meldet einen Fehler, wenn die Domänennamensanforderung nicht aufgelöst werden kann.)
Abbildung 5 veranschaulicht eine Site, bei der Site Selector zusammen mit einem DNS-System die Last auf lokale und ferne Server verteilt.
Site Selektor umfasst die folgenden Funktionen:
Die Benutzung des Managers ist optional. Ohne den Manager wird der Lastausgleich nach einer gewichteten Round-Robin-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 Servers. 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 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 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 yes gesetzt, sendet Metric Server einen Ping-Befehl 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 Clientnamensserver 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 finden Sie im Abschnitt Befehlsreferenz für Site Selektor.
Lesen Sie vor dem Ausführen der Schritte in diesem Teil den Abschnitt Planung für Site Selector. In diesem Kapitel wird das Erstellen einer Basiskonfiguration für die Komponente Site Selector von Load Balancer erläutert.
Tabelle 12. Konfigurations-Tasks für die Komponente Site Selector
Task | Beschreibung | Referenzinformationen |
---|---|---|
Site-Selector-Maschine konfigurieren. | Stellen Sie fest, welche Voraussetzungen zu erfüllen sind. | Site-Selector-Maschine 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 Load Balancer:
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 Hostnamen (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 an Stelle von sscontrol help file angeben.
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 Konfigurationsscriptdatei eingegeben und dann zusammen ausgeführt werden.
sscontrol file appendload myscript
sscontrol file newload myscript
Führen Sie den folgenden Befehl aus, um die aktuelle Konfiguration in einer Scriptdatei (z. B. savescript) zu speichern:
sscontrol file save savescript
Dieser Befehl speichert die Scriptdatei mit der Konfiguration im Verzeichnis ...ibm/edge/lb/servers/configurations/ss.
Abbildung 41 zeigt ein Beispiel für die GUI mit allgemeinen Anweisungen.
Gehen Sie zum Starten der GUI wie folgt vor:
Zum Konfigurieren von Site Selector über die grafische Benutzerschnittstelle müssen Sie zunächst in der Baumstruktur Site Selector auswählen. Nachdem Sie eine Verbindung zu einem Host hergestellt haben, auf dem ssserver ausgeführt wird, können Sie Sitenamen mit Servern erstellen und den Manager sowie Advisor-Funktionen starten.
Über die grafische Benutzerschnittstelle können Sie die gleichen Schritte wie mit dem Befehl sscontrol ausführen. Wenn Sie beispielsweise einen Sitenamen über die Befehlszeile definieren möchten, müssen Sie den Befehl sscontrol sitename add Sitename eingeben. Zum Definieren eines Sitenamens über die grafische Benutzerschnittstelle müssen Sie mit der rechten Maustaste auf "Namensserver" klicken und anschließend in dem daraufhin angezeigten Popup-Menü mit der auf Sitenamen hinzufügen klicken. 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. Das oben in der grafischen Benutzerschnittstelle befindliche Menü Datei bietet Ihnen die Möglichkeit, die aktuellen Hostverbindungen in einer Datei zu speichern oder Verbindungen aus vorhandenen Dateien für alle Komponenten von Load Balancer wiederherzustellen.
Wenn Sie einen Befehl über die grafische Benutzerschnittstelle ausführen möchten, gehen Sie wie folgt vor: Heben Sie in der GUI-Baumstruktur den Hostknoten hervor, und wählen Sie im Popup-Menü "Host" Befehl senden... aus. Geben Sie im Befehlseingabefeld den gewünschten Befehl ein, z. B. nameserver status. In einem Fenster sehen Sie die Ergebnisse und die Historie der in der aktuellen Sitzung ausgeführten Befehle.
Sie können auf Hilfe zugreifen, indem Sie auf das Fragezeichen in der oberen rechten Ecke des Fensters von Load Balancer klicken.
Weitere Informationen zur Verwendung der grafischen Benutzerschnittstelle finden Sie in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
Führen Sie folgende Schritte aus, wenn Sie den Konfigurationsassistenten verwenden:
ssserver
Sie können den Assistenten von der Eingabeaufforderung aus starten, indem Sie den Befehl sswizard absetzen. Sie können den Konfigurationsassistenten auch über das Menü "Komponente Site Selector" in der grafischen Benutzerschnittstelle 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.
Vor dem Konfigurieren der Site-Selector-Maschine müssen Sie (auf AIX-, HP-UX-, Linux- oder Solaris-Systemen) als Root oder (auf Windows-Systemen) als Administrator registriert sein.
Für eine Gruppe von Servern, die Sie konfigurieren, benötigen Sie einen nicht auflösbaren vollständig qualifizierten Hostnamen 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.
Geben Sie zum Starten der Site-Selector-Serverfunktion in der Befehlszeile 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 Hostname, den der Client anfordert. Der Sitename muss ein vollständig qualifizierter Domänenname sein (z. B. www.dnsdownload.com). Wenn ein Client diesen Sitenamen 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
Setzen Sie zum Festlegen der Optionen für den Sitenamen den folgenden Befehl ab:
sscontrol sitename set Optionswert für Sitename
Weitere Informationen finden Sie im Abschnitt Befehlsreferenz für Site Selector.
Die Servermaschinen sind die Maschinen, auf denen die Anwendungen ausgeführt werden, deren Last verteilt werden soll. Für 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 aus 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 Managerfunktion ergänzt den Lastausgleich. Vergewissern Sie sich vor dem Starten der Managerfunktion, 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. Load Balancer 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 Systemmetriken 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 (Portinformationen) beigemessen wird. Setzen Sie zum Festlegen der Proportionen für den Sitenamen den Befehl sscontrol sitename set Sitename proportions ab. Weitere Informationen finden Sie im Abschnitt Proportionale Bedeutung von Statusinformationen.
Verwenden Sie Metric Server zusammen mit der Komponente Site Selector. Informationen zum Konfigurieren von Metric Server auf allen Maschinen, für die Site Selector einen Lastausgleich durchführt, finden Sie im Abschnitt Metric Server.
Dieser Teil enthält Informationen zu einer schnellen Erstkonfiguration sowie zur Planung und beschreibt die Konfigurationsmethoden für die Komponente Cisco CSS Controller von Load Balancer. Zu diesem Teil gehören die folgenden Kapitel:
Dieses Beispiel für schnellen Start demonstriert das Erstellen einer Konfiguration mit der Komponente Cisco CSS Controller. Cisco CSS Controller stellt Serverwertigkeiten bereit, die dem Cisco CSS Switch helfen, für seine Lastausgleichsentscheidungen eine optimale Serverauswahl zu treffen.
Abbildung 25. Einfache Cisco-CSS-Controller-Konfiguration
Für dieses Beispiel für schnellen Start benötigen Sie Folgendes:
Vergewissern Sie sich vor dem Konfigurieren dieses Beispiels, dass die folgenden Schritte abgeschlossen sind:
Für Cisco CSS Controller können Sie eine Konfiguration unter Verwendung der Befehlszeile oder der grafischen Benutzerschnittstelle (GUI) erstellen. Dieses Beispiel für schnellen Start zeigt die Ausführung der Konfigurationsschritte in der Befehlszeile.
Führen Sie an einer Eingabeaufforderung die folgenden Schritte aus:
ccocontrol consultant add SwConsultant-1 address 9.17.32.50 community public
Damit wird die Konnektivität zum Cisco CSS Switch überprüft und festgestellt, ob der Name der SNMP-Community mit Schreib-/Lesezugriff funktioniert.
ccocontrol ownercontent add SwConsultant-1:OwnerContent-1 ownername OwnerName-1 contentrule ContentRule-1
Diese Werte müssen mit den entsprechenden Attributen des Cisco CSS Switch übereinstimmen.
Cisco CSS Controller kann jetzt über SNMP mit dem Switch kommunizieren und die notwendigen Konfigurationsdaten für den Switch abrufen. Nach diesem Schritt sollte Cisco CSS Controller anzeigen, welche Services für den Cisco CSS Switch und die entsprechenden Eignerangaben konfiguriert sind.
ccocontrol ownercontent metrics SwConsultant-1:OwnerContent-1 activeconn 45 connrate 45 http 10
Dieser Befehl legt fest, welche Metriken mit welcher Proportion von den Services zur Berechnung der Wertigkeit erfasst werden sollen. Die proportionalen Angaben aller Metriken müssen in der Summe 100 ergeben.
ccocontrol consultant start SwConsultant-1
Mit diesem Befehl werden alle Metrik-Collector gestartet, so dass mit dem Berechnen der Servicewertigkeit begonnen werden kann. Cisco CSS Controller teilt dem Cisco CSS Switch über SNMP die berechneten Servicewertigkeiten mit.
Die Basiskonfiguration von Cisco CSS Controller ist damit vollständig.
Testen Sie wie folgt, ob die Konfiguration korrekt ist:
Informationen zur Verwendung der grafischen Benutzerschnittstelle von Cisco CSS Controller finden Sie im Abschnitt Grafische Benutzerschnittstelle und in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Komponente Cisco CSS Controller berücksichtigen muss.
Dieses Kapitel umfasst die folgenden Abschnitte:
Informationen zu den Hardware- und Softwarevoraussetzungen finden Sie auf der folgenden Webseite: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Außerdem benötigen Sie Folgendes:
Cisco CSS Controller verwaltet eine Reihe von Switch-Consultants. Jeder Consultant bestimmt Wertigkeiten für Services, deren Arbeitslast von nur einem Switch verteilt wird. Der Switch, für den der Consultant die Wertigkeiten bereitstellt, ist für die Inhaltsverteilung konfiguriert. Der Consultant sendet die berechneten Wertigkeiten mit dem Protokoll SNMP an den Switch. Wenn der Lastausgleichsalgorithmus mit einer Round-Robin-Methode gewichtet wird, verwendet der Switch die Wertigkeiten, um für die Inhaltsregel des Lastausgleichs einen Service auszuwählen. Für die Bestimmung der Wertigkeiten verwendet der Consultant eine oder mehrere der folgenden Informationen:
Eine Beschreibung der Inhaltsverteilung und ausführliche Informationen zum Konfigurieren des Switch können Sie der Veröffentlichung Cisco Content Services Switch Getting Started Guide entnehmen.
Sie benötigen Folgendes, damit ein Consultant die zur Bestimmung der Servicewertigkeiten erforderlichen Informationen abrufen kann:
Wie in Abbildung 26 gezeigt, kann sich die Verbindung zwischen Consultant und Netz hinter den Switches befinden, für die der Consultant Wertigkeiten bereitstellen soll. Für die Konnektivität zwischen dem Controller, dem Switch und den Services müssen einige Parameter für den Switch und einige für den Controller konfiguriert werden.
Ausführliche Informationen zum Konfigurieren von virtuellen LANs und des IP-Routing auf dem Switch können Sie der Veröffentlichung Cisco Content Services Switch Getting Started Guide entnehmen.
Abbildung 26. Beispiel für einen Consultant, der hinter den Switches mit dem Netz verbunden ist
Für die Verwaltung von Cisco CSS Controller können Sie eine der folgenden Schnittstellen nutzen:
Fernverwaltung (Abbildung 27):
Ausführliche Informationen hierzu können Sie der Veröffentlichung Cisco Content Services Switch Getting Started Guide entnehmen.
Die hohe Controllerverfügbarkeit erweitert die Fähigkeiten von Load Balancer im Bereich der Fehlertoleranz. Die Entwicklung der hohen Controllerverfügbarkeit wurde im Hinblick auf die Verfügbarkeit für die Paketweiterleitung entwickelt und bedeutet die Verfügbarkeit zweier gleichzeitig aktiver Controller, von denen einer der primäre und der andere der sekundäre Controller ist.
Beide Controller werden mit identischen Switch-Daten konfiguriert und es ist immer nur ein Controller zur Zeit aktiv. Entsprechend der Logik der hohen Verfügbarkeit bedeutet dies, dass nur der aktive Controller neue Wertigkeiten für den Switch berechnet und aktualisiert.
Für die hohe Controllerverfügbarkeit kommuniziert der Controller mit seinem Partner über eine von Ihnen konfigurierte Adresse und einen von Ihnen konfigurierten Port unter Verwendung des UDP (User Datagram Protocol). Mit diesen Paketen tauschen die Controller die für hohe Verfügbarkeit wichtigen Daten (Erreichbarkeitsdaten) aus und stellen (mit Überwachungssignalen) fest, ob der Partner verfügbar ist. Wenn der Bereitschaftscontroller erkennt, dass der aktive Controller ausgefallen ist, übernimmt er die Aufgaben des aktiven Controllers. Damit wird der Bereitschaftscontroller zum aktiven Controller und beginnt, neue Wertigkeiten für den Switch zu berechnen und zu aktualisieren.
Neben der Verfügbarkeit des Partners können Sie für die hohe Verfügbarkeit Erreichbarkeitsziele konfigurieren. Bei der hohen Controllerverfügbarkeit werden Erreichbarkeitsdaten verwendet, um festzustellen, welcher der Controller aktiv und welcher der Bereitschaftscontroller ist. Der aktive Controller kann mehr Ziele mit ping erreichen und ist von seinem Partnercontroller aus erreichbar.
Weitere Informationen finden Sie im Abschnitt Hohe Verfügbarkeit.
Wenn der Consultant feststellt, dass ein Service nicht verfügbar ist, setzt er diesen Service auf dem Switch aus, damit der Switch den Service bei der Verteilung von Anforderungen nicht berücksichtigt. Sobald der Service wieder verfügbar ist, aktiviert der Consultant den Service auf dem Switch, so dass er bei Lastausgleichsanforderungen wieder Berücksichtigung findet.
Cisco CSS Controller schreibt Einträge in die folgenden Protokolle:
Diese Protokolle befinden sich in den folgenden Verzeichnissen:
In jedem Protokoll können Sie die Protokollgröße und -stufe festlegen. Weitere Informationen finden Sie im Abschnitt Load-Balancer-Protokolle verwenden.
Lesen Sie vor dem Ausführen der Schritte in diesem Teil den Abschnitt Planung für Cisco CSS Controller. Dieses Kapitel erläutert das Erstellen einer Basiskonfiguration für die Komponente Cisco CSS Controller von Load Balancer.
Vor Ausführung einer der in diesem Kapitel beschriebenen Konfigurationsmethoden müssen Sie die folgenden Schritte ausführen:
Tabelle 13. Konfigurations-Tasks für die Komponente Cisco CSS Controller
Task | Beschreibung | Referenzinformationen |
---|---|---|
Maschine mit Cisco CSS Controller konfigurieren | Ermitteln Sie die Voraussetzungen. | Controller für die Maschine mit dem Cisco CSS Switches konfigurieren |
Konfiguration testen | Überprüfen Sie, ob die Konfiguration funktioniert. | Konfiguration testen |
Es gibt im Wesentlichen drei Methoden für das Erstellen einer Basiskonfiguration für die Load-Balancer-Komponente Cisco CSS Controller:
Dies ist die direkte Methode für die Konfiguration von Cisco CSS Controller. 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 Hostnamen (die z. B. im Befehl consultant add verwendet werden) und Dateinamen.
Starten Sie Cisco CSS Controller wie folgt über die Befehlszeile:
Anmerkungen:
Sie können eine gekürzte Version der Parameter für den Befehl "ccocontrol" 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 ccocontrol he f an Stelle von ccocontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl ccocontrol ab, um die Eingabeaufforderung ccocontrol aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Die soeben definierte Konfiguration kann in einer XML-Datei gespeichert werden. So kann die Konfiguration später schnell erneut geladen werden.
Verwenden Sie zum Ausführen des Inhaltes einer XML-Datei (z. B. myscript.xml) einen der folgenden Befehle:
ccocontrol file save Name_der_XML-Datei
ccocontrol file load Name_der_XML-Datei
Verwenden Sie den Befehl "load" nur, wenn Sie zuvor den Befehl file save abgesetzt haben.
Die XML-Dateien werden im Verzeichnis ...ibm/edge/lb/servers/configurations/cco/ gespeichert.
Allgemeine Anweisungen und ein Beispiel zur grafischen Benutzerschnittstelle finden Sie in Abbildung 41.
Gehen Sie zum Starten der GUI wie folgt vor:
ccoserver.
Gehen Sie zum Konfigurieren von Cisco CSS Controller über die grafische Benutzerschnittstelle wie folgt vor:
Von der GUI aus können Sie alle mit dem Befehl ccocontrol ausführbaren Schritte ausführen. Beispiel:
Gehen Sie wie folgt vor, um von der GUI aus einen Befehl auszuführen:
Im Fenster "Ergebnis" sehen Sie die Ergebnisse und die Historie der in der aktuellen Sitzung ausgeführten Befehle.
Falls Sie Hilfe benötigen, klicken Sie oben rechts im Load-Balancer-Fenster auf das Fragezeichen.
Weitere Informationen zur Verwendung der grafischen Benutzerschnittstelle finden Sie in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
Vor dem Konfigurieren der Maschine mit Cisco CSS Controller müssen Sie (auf AIX-, HP-UX-, Linux- oder Solaris-Systemen) als Root oder (auf Windows-Systemen) als Administrator registriert sein.
Der Consultant muss in der Lage sein, als Administrator des Cisco CSS Switch eine Verbindung zum Cisco CSS Switch herzustellen.
Wenn Sie den Consultant konfigurieren, müssen die Adresse und der Name der SNMP-Community mit den entsprechenden Attributen des Cisco CSS Switch übereinstimmen.
Hilfe zu den in dieser Prozedur verwendeten Befehlen finden Sie im Abschnitt Befehlsreferenz für Cisco CSS Controller.
Wenn ccoserver noch nicht aktiv ist, starten Sie den Dienst jetzt, indem Sie als Root ccoserver eingeben.
Geben Sie ccocontrol ein, um die Befehlszeilenschnittstelle aufzurufen.
Sie müssen die Switch-Adresse und einen Namen für die SNMP-Community konfigurieren. Diese Werte müssen mit den entsprechenden Attributen des Cisco CSS Switch übereinstimmen.
Geben Sie Folgendes ein, um einen Consultant hinzuzufügen:
consultant add ID_des_Switch-Consultants address IP-Adresse_des_Switch community Community-Name
Eignerangaben sind die Darstellung einer Inhaltsregel für einen Eigner, der für den Cisco CSS Switch definiert ist. Der Eignername und der Name der Inhaltsregel müssen mit der entsprechenden Definition auf dem Switch übereinstimmen.
Geben Sie Folgendes ein, um Eignerangaben zu definieren:
ownercontent add ID_des_Switch-Consultants:ID_für_Eignerangaben ownername Eignername contentrule Name_der_Inhaltsregel
Wenn die Eignerangaben definiert sind, schließt der Consultant die Konfiguration ab, indem er die für den Switch konfigurierten Services abruft. Vergleichen Sie die Konfiguration auf dem Switch mit der Konfiguration für den Consultant, um sicherzustellen, dass die Services übereinstimmen.
Anhand von Metriken werden die Wertigkeiten von Services und ihre proportionale Gewichtung (im Vergleich zu anderen Services) bestimmt. Sie können eine beliebige Kombination von Metriken für Verbindungsdaten, für Advisor-Funktionen der Anwendung und für Metric Server verwenden. Die proportionalen Gewichtungen müssen in der Summe stets 100 ergeben.
Wenn Sie die Eignerangaben konfigurieren, werden die Standardmetriken activeconn und connrate definiert. Falls Sie zusätzliche oder gänzlich andere Metriken verwenden möchten, geben Sie Folgendes ein:
ownercontent metrics ID_des_Switch-Consultants:ID_für_Eignerangaben Metrik1 Proportion1 Metrik2 Proportion2...MetrikN ProportionN
Geben Sie zum Starten des Consultants Folgendes ein:
consultant start ID_des_Switch-Consultants
Mit diesem Befehl werden die Metrik-Collector gestartet, und die Berechnung von Wertigkeiten beginnt.
Wenn Sie in Schritt 5 Systemmetriken definiert haben, muss auf den Servicemaschinen Metric Server gestartet werden. Informationen zur Verwendung von Metric Server finden Sie im Abschnitt Metric Server.
Geben Sie Folgendes ein, um die hohe Verfügbarkeit zu konfigurieren:
highavailability add address IP-Adresse partneraddress IP-Adresse port 80 role primary
In einer Umgebung mit hoher Verfügbarkeit können Sie mehrere Switches konfigurieren. Cisco CSS Controller muss so konfiguriert werden, dass er für alle Switches und die entsprechenden Ausweicheinheiten Wertigkeiten bereitstellt, um auch bei der Übernahme der Aufgaben eines Switch durch einen anderen die ständige Verfügbarkeit von Wertigkeitsinformationen zu gewährleisten.
Ausführliche Informationen zur Verwendung und Konfiguration der hohen Verfügbarkeit für den Controller finden Sie im Abschnitt Erweiterte Features für Cisco CSS Controller und Nortel Alteon Controller.
Testen Sie wie folgt, ob die Konfiguration korrekt ist:
Dieser Teil enthält Informationen zu einer schnellen Erstkonfiguration sowie zur Planung und beschreibt die Konfigurationsmethoden für die Komponente Nortel Alteon Controller von Load Balancer. Zu diesem Teil gehören die folgenden Kapitel:
Dieses Beispiel für schnellen Start demonstriert das Erstellen einer Konfiguration mit der Komponente Nortel Alteon Controller. Nortel Alteon Controller stellt dem Nortel Alteon Web Switch Wertigkeiten zur Verfügung. Anhand dieser Wertigkeiten werden Server für Services ausgewählt, für die der Switch einen Lastausgleich durchführt.
Abbildung 28. Einfache Nortel-Alteon-Controller-Konfiguration
Für dieses Beispiel für schnellen Start benötigen Sie Folgendes:
Vergewissern Sie sich vor dem Konfigurieren dieses Beispiels, dass die folgenden Schritte abgeschlossen sind:
Für Nortel Alteon Controller können Sie eine Konfiguration unter Verwendung der Befehlszeile oder der grafischen Benutzerschnittstelle (GUI) erstellen. Dieses Beispiel für schnellen Start zeigt die Ausführung der Konfigurationsschritte in der Befehlszeile.
Führen Sie an einer Eingabeaufforderung die folgenden Schritte aus:
nalcontrol consultant add Consultant-1 address 9.87.32.50
Damit wird die Konnektivität zum Nortel Alteon Web Switch überprüft und festgestellt, ob die Namen der SNMP-Community funktionieren.
nalcontrol service add Consultant-1:Service-1 vsid 1 vport 80
Nortel Alteon Controller kommuniziert über SNMP mit dem Switch und ruft die notwendigen Konfigurationsdaten für den Switch ab. Nach diesem Schritt sollte Nortel Alteon Controller anzeigen, welche Server auf dem Nortel Alteon Web Switch für diesen Service konfiguriert sind.
nalcontrol service metrics Consultant-1:Service-1 http 40 activeconn 30 connrate 30
Dieser Befehl legt fest, welche Metriken von den Servern erfasst und welche relative Bedeutung sie bei der Berechnung der Wertigkeit haben sollen.
nalcontrol consultant start Consultant-1
Mit diesem Befehl werden alle Metrik-Collector gestartet, so dass mit dem Berechnen der Serverwertigkeit begonnen werden kann. Nortel Alteon Controller teilt dem Nortel Alteon Web Switch über SNMP die berechneten Serverwertigkeiten mit.
Die Basiskonfiguration für Nortel Alteon Controller ist damit vollständig.
Testen Sie wie folgt, ob die Konfiguration korrekt ist:
Informationen zur Verwendung der grafischen Benutzerschnittstelle von Nortel Alteon Controller finden Sie im Abschnitt Grafische Benutzerschnittstelle und in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
In diesem Kapitel wird beschrieben, was die für die Planung des Netzes zuständige Person vor der Installation und Konfiguration der Komponente Nortel Alteon Controller berücksichtigen muss.
Dieses Kapitel umfasst die folgenden Abschnitte:
Informationen zu den Hardware- und Softwarevoraussetzungen finden Sie auf der folgenden Webseite: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Außerdem benötigen Sie Folgendes:
Nortel Alteon Controller verwaltet eine Reihe von Switch-Consultants. Jeder Consultant bestimmt Wertigkeiten für Server, deren Arbeitslast von nur einem Switch verteilt wird. Der Switch, für den der Consultant die Wertigkeiten bereitstellt, ist für den Serverlastausgleich konfiguriert. Der Consultant sendet die berechneten Wertigkeiten mit dem Protokoll SNMP an den Switch. Ausgehend von diesen Wertigkeiten wählt der Switch für den Service, dessen Last verteilt werden soll, einen Server aus. Für die Bestimmung der Wertigkeiten verwendet der Consultant eine oder mehrere der folgenden Informationen:
Eine Beschreibung des Serverlastausgleichs und ausführliche Informationen zum Konfigurieren des Switch können Sie dem "Nortel Alteon Web OS Application Guide" entnehmen.
Sie benötigen Folgendes, damit ein Consultant die zur Bestimmung der Serverwertigkeiten erforderlichen Informationen abrufen kann:
Die Verbindung zwischen Consultant und Netz kann sich vor oder hinter den Switches befinden, für die der Consultant Wertigkeiten bereitstellen soll. Für die Konnektivität zwischen dem Controller, dem Switch und den Servern müssen einige Parameter für den Switch und einige für den Controller konfiguriert werden.
Ausführliche Informationen zum Konfigurieren von virtuellen LANs und des IP-Routing auf dem Switch können Sie dem "Nortel Alteon Web OS Application Guide" oder der Veröffentlichung "Command Reference" entnehmen.
Abbildung 29. Beispiel für einen Consultant, der hinter dem Switch mit dem Netz verbunden ist
Für die Verwaltung von Nortel Alteon Controller können Sie eine der folgenden Schnittstellen nutzen:
Wenn ein Consultant Wertigkeiten für Server berechnet, die einen Service bereitstellen, für den ein Switch den Lastausgleich durchführt, inaktiviert der Consultant die normale Überprüfung des Serverzustandes auf dem Switch, um unnötigen Datenverkehr zu den Servern zu vermeiden. Die Zustandsprüfung wird vom Consultant reaktiviert, sobald die Bereitstellung der Wertigkeiten für den Service abgeschlossen ist. Das Intervall für die Überprüfung des Serverzustandes entspricht der MIB-Variablen slbNewCgRealServerPingInterval.
Wenn der Consultant feststellt, dass ein Server nicht verfügbar ist, setzt er die maximale Verbindungsanzahl des Servers auf null, damit der Server bei der Verteilung von Anforderungen nicht berücksichtigt wird. Sobald der Server wieder verfügbar ist, wird der ursprüngliche Wert für die maximale Verbindungsanzahl wiederhergestellt. Die maximale Anzahl von Verbindungen des Servers entspricht der MIB-Variablen slbNewCfgRealServerMaxCons.
Wird eine Wertigkeit für einen realen Server berechnet, wird diese für den Server festgelegt. Die Serverwertigkeit entspricht der MIB-Variablen slbNewCfgRealServerWeight.
Der Switch lässt die Konfiguration von Servern zu, die als Ausweichserver fungieren. Wenn der Switch feststellt, dass ein Server mit verfügbarem Ausweichserver nicht erreichbar ist, kann er Anforderungen an den Ausweichserver senden. Berechnet der Consultant Wertigkeiten für einen Service mit verfügbarem Ausweichservice, werden Wertigkeiten für den Ausweichserver und den primären Server berechnet, damit Wertigkeiten für die Serverauswahl bereit stehen, wenn der Ausweichservice genutzt werden muss.
Die Wertigkeit eines Ausweichservers kann über der eines primären Servers liegen. Der Grund dafür ist, dass keine Anforderungen an den Ausweichserver weitergeleitet werden und dieser somit nicht belastet ist, solange der Switch nicht auf ihn zurückgreift.
Zur Vermeidung ungenutzter Serverressourcen ist es allgemein üblich, dass Server, die einem Service zugeordnet sind, als Ausweichserver für Server verwendet werden, die einem anderen Service zugeordnet sind. Bei der Implementierung einer solchen Konfiguration sollten Sie es vermeiden, dieselben realen Server mehreren gleichzeitig aktiven Services zuzuordnen. Andernfalls überschreibt der Consultant die Wertigkeit des Servers für jeden Service, an dem der Server beteiligt ist.
Jeder reale Server ist durch eine ganze Zahl, eine Wertigkeit und ein IP-Adressattribut gekennzeichnet. Zwei reale Server können dieselbe IP-Adresse haben. In einem solchen Fall sind zwei reale Server derselben physischen Servermaschine zugeordnet. Die als Ausweichserver vorgesehenen Server sollten nur für die Sicherung eines Services konfiguriert werden. Dient eine physische Maschine zur Sicherung von Servern, die mehreren Services zugeordnet sind, müssen Sie für jeden Service einmal konfiguriert werden und eine für jeden Service eindeutige Server-ID erhalten. Dadurch kann den Ausweichservern für jeden Service eine eindeutige Wertigkeit zugeordnet werden.
Abbildung 32. Beispiel für einen Consultant mit Ausweichservern
Die Server eines Switch können als Teil mehrerer Gruppen konfiguriert werden. Ebenso können die Gruppen eines Switch für mehrere Services konfiguriert werden.
Da ein Server für mehrere Services konfiguriert werden kann, wird die Wertigkeit für jeden Service berechnet, den der Server anbietet. Deshalb ist nicht sicher, dass die Wertigkeit korrekt ist, denn es ist unbekannt, auf welchen Service sie sich bezieht.
Bestimmt der Consultant Wertigkeiten für einen Service, für einen anderen jedoch nicht, kann der Fall eintreten, dass der Service, für den keine Wertigkeit berechnet wurde, keine Überprüfung des Serverzustandes übernimmt (weil diese inaktiviert ist). In einem solchen Fall kann der Switch keine ordnungsgemäße Lastverteilung für diesen Service sicherstellen.
In Kenntnis dieser Möglichkeiten müssen Sie gewährleisten, dass ein realer Server nicht mehreren am Lastausgleich beteiligten Services zugeordnet wird. Das bedeutet jedoch nicht, dass eine Servermaschine nicht Anfragen nach verschiedenen Services bedienen kann. Es bedeutet viel mehr, dass ein realer Server auf dem Switch für jeden Service, für den er Anfragen bearbeitet, mit einer eindeutigen Kennung konfiguriert werden muss.
Nortel Alteon Controller und der Nortel Alteon Web Switch besitzen Funktionen für hohe Verfügbarkeit.
Sie können zwei Controller konfigurieren, die auf zwei verschiedenen Systemen in einer fehlertoleranten Konfiguration ausgeführt werden.
Zwei oder mehr Switches können sich gegenseitig sichern, wenn Sie sie als virtuellen IP-Schnittstellen-Router (VIR) oder virtuellen IP-Server-Router (VSR) konfigurieren.
Ein (vom Controller verwalteter) Consultant stellt nur Wertigkeiten für einen Switch bereit. Da es möglich ist, dass ein Ausweich-Switch die Aufgaben des Master-Switch übernimmt, müssen Sie den Controller mit dem Consultant für jeden Switch konfigurieren, der potenziell als Master-Switch eingesetzt werden könnte. Auf diese Weise ist sichergestellt, dass ein Master-Switch immer Wertigkeiten empfängt.
Wenn die Controller mit einem VIR verbunden sind, ist darüber hinaus ihre Kommunikation mit den Servern, den Switches und dem Ausweichcontroller auch bei Verlust der Konnektivität zu einem der Switches gewährleistet.
Informationen zur hohen Verfügbarkeit der Switches können Sie dem "Nortel Alteon Web OS Application Guide" entnehmen.
Die hohe Controllerverfügbarkeit erweitert die Fähigkeiten von Load Balancer im Bereich der Fehlertoleranz. Die Entwicklung der hohen Controllerverfügbarkeit wurde im Hinblick auf die Verfügbarkeit für die klassische Paketweiterleitung entwickelt und bedeutet die Verfügbarkeit zweier gleichzeitig aktiver Controller, von denen einer der primäre und der andere der sekundäre Controller ist.
Beide Controller werden mit identischen Switch-Daten konfiguriert. Ähnlich wie bei der klassischen hohen Verfügbarkeit ist immer nur ein Controller zur Zeit aktiv. Entsprechend der Logik der hohen Verfügbarkeit bedeutet dies, dass nur der aktive Controller neue Wertigkeiten für den Switch berechnet und aktualisiert.
Für die hohe Controllerverfügbarkeit kommuniziert der Controller mit seinem Partner über eine von Ihnen konfigurierte Adresse und einen von Ihnen konfigurierten Port unter Verwendung des UDP (User Datagram Protocol). Mit diesen Paketen tauschen die Controller die für hohe Verfügbarkeit wichtigen Daten (Erreichbarkeitsdaten) aus und stellen (mit Überwachungssignalen) fest, ob der Partner verfügbar ist. Wenn der Bereitschaftscontroller erkennt, dass der aktive Controller ausgefallen ist, übernimmt er die Aufgaben des aktiven Controllers. Damit wird der Bereitschaftscontroller zum aktiven Controller und beginnt, neue Wertigkeiten für den Switch zu berechnen und zu aktualisieren.
Neben der Verfügbarkeit des Partners können Sie für die hohe Verfügbarkeit Erreichbarkeitsziele konfigurieren. Wie bei der klassischen hohen Verfügbarkeit werden die Erreichbarkeitsdaten bei der hohen Controllerverfügbarkeit verwendet, um festzustellen, welcher der Controller aktiv und welcher der Bereitschaftscontroller ist. Der aktive Controller kann mehr Ziele mit ping erreichen und ist von seinem Partnercontroller aus erreichbar.
Weitere Informationen finden Sie im Abschnitt Hohe Verfügbarkeit.
Sie können den Consultant mit einer Sensitivitätsschwelle konfigurieren, damit sich die Wertigkeiten nicht zu oft ändern. Die Sensitivitätsschwelle gibt an, in welchem Maße sich eine Wertigkeit ändern muss, damit die Änderung als relevant angesehen wird. Weitere Informationen finden Sie im Abschnitt Sensitivitätsschwelle.
Wenn der Switch einen zu großen Aufwand mit dem Aktualisieren der Wertigkeiten betreiben muss, können Sie die Inaktivitätszeit des Consultant erhöhen, um den Datenverkehr zwischen dem Controller, den Servern und dem Switch zu reduzieren. Dieser Zeitwert legt die Zeit der Inaktivität zwischen den Definitionszyklen für die Wertigkeit in Sekunden fest.
Wenn die Server zu viele Überwachungsanfragen vom Consultant bearbeiten müssen, können Sie die Inaktivitätszeit der Metrik-Collector ändern. Eine ausführliche Beschreibung dieses Prozesses finden Sie im Abschnitt Ruhezeiten für Wertigkeitsberechnung.
Cisco CSS Controller schreibt Einträge in die folgenden Protokolle:
Diese Protokolle befinden sich in den folgenden Verzeichnissen:
In jedem Protokoll können Sie die Protokollgröße und -stufe festlegen. Weitere Informationen finden Sie im Abschnitt Load-Balancer-Protokolle verwenden.
Lesen Sie vor dem Ausführen der Schritte in diesem Teil den Abschnitt Planung für Nortel Alteon Controller. Dieses Kapitel erläutert das Erstellen einer Basiskonfiguration für die Komponente Nortel Alteon Controller von Load Balancer.
Vor Ausführung einer der in diesem Kapitel beschriebenen Konfigurationsmethoden müssen Sie gewährleisten, dass der Nortel Alteon Web Switch und alle Servermaschinen ordnungsgemäß konfiguriert sind.
Tabelle 14. Konfigurations-Tasks für die Komponente Nortel Alteon Controller
Task | Beschreibung | Referenzinformationen |
---|---|---|
Nortel Alteon Web Switch und die Server konfigurieren | Konfigurieren Sie den Switch. | Switch konfigurieren, (SETSWITCH) |
Maschine mit Nortel Alteon Controller konfigurieren | Konfigurieren Sie den Controller. | Schritt 1. Serverfunktion starten |
Konfiguration testen | Vergewissern Sie sich, dass die Konfiguration funktioniert. | Konfiguration testen |
Es gibt im Wesentlichen drei Methoden für das Erstellen einer Basiskonfiguration für die Load-Balancer-Komponente Nortel Alteon Controller:
Dies ist die direkte Methode für die Konfiguration von Nortel Alteon Controller. Bei den in diesem Handbuch beschriebenen Prozeduren wird von der Verwendung der Befehlszeile ausgegangen.
Starten Sie Nortel Alteon Controller wie folgt über die Befehlszeile:
Anmerkungen:
Für die Parameter des Befehls "nalcontrol" können Sie die abgekürzte Form verwenden. 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 nalcontrol he f an Stelle von nalcontrol help file angeben.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Anmerkungen:
Die soeben definierte Konfiguration kann in einer XML-Datei gespeichert werden. So kann die Konfiguration später schnell erneut geladen werden.
Verwenden Sie zum Ausführen des Inhaltes einer XML-Datei (z. B. myscript.xml) die folgenden Befehle:
nalcontrol file save Name_der_XML-Datei
Verwenden Sie den Befehl "load" nur, wenn Sie zuvor den Befehl file save abgesetzt haben.
nalcontrol file load Name_der_XML-Datei
Verwenden Sie den Befehl "load" nur, wenn Sie zuvor den Befehl file save abgesetzt haben.
Die XML-Dateien werden im Verzeichnis ...ibm/edge/lb/servers/configurations/nal/ gespeichert.
Ein Beispiel für die grafische Benutzerschnittstelle finden Sie in Abbildung 41.
Rufen Sie die grafische Benutzerschnittstelle wie folgt auf:
Gehen Sie zum Konfigurieren von Nortel Alteon Controller über die grafische Benutzerschnittstelle wie folgt vor:
Von der GUI aus können Sie alle mit dem Befehl nalcontrol ausführbaren Schritte ausführen. Beispiel:
Gehen Sie wie folgt vor, um über die grafische Benutzerschnittstelle einen Befehl auszuführen:
Im Fenster "Ergebnis" sehen Sie die Ergebnisse und die Historie der in der aktuellen Sitzung ausgeführten Befehle.
Falls Sie Hilfe benötigen, klicken Sie oben rechts im Load-Balancer-Fenster auf das Fragezeichen.
Weitere Informationen zur Verwendung der grafischen Benutzerschnittstelle finden Sie in Anhang A. Allgemeine Anweisungen zur grafischen Benutzerschnittstelle.
Hilfe zu den in dieser Prozedur verwendeten Befehlen finden Sie im Abschnitt Befehlsreferenz für Nortel Alteon Controller.
Vor dem Konfigurieren der Maschine mit Nortel Alteon Controller müssen Sie die folgenden Schritte ausführen:
Wenn nalserver noch nicht aktiv ist, starten Sie den Dienst jetzt, indem Sie als Root nalserver eingeben.
Geben Sie nalcontrol ein, um die Befehlszeilenschnittstelle aufzurufen.
Geben Sie Folgendes ein, um einen Switch-Consultant hinzuzufügen:
consultant add ID_des_Switch-Consultants address IP-Adresse_des_Switch
Geben Sie Folgendes ein, um einen Service hinzuzufügen:
service add ID_des_Switch-Consultant:Service-ID vsid ID_des_virtuellen_Servers vport Nummer_des_virtuellen_Ports
Ein Service ist durch die ID eines virtuellen Servers (VSID) und die Nummer eines virtuellen Ports (VPORT) gekennzeichnet. Beide Werte sind einem virtuellen Server zugeordnet, der zuvor für den Switch konfiguriert wurde.
Anhand der Metriken wird die Wertigkeit der Server bestimmt. Jeder Metrik wird eine proportionale Bedeutung zugeordnet, um seine Wertigkeit im Verhältnis zu anderen Metriken anzugeben. Sie können beliebige Kombinationen von Metriken konfigurieren: Metriken für Verbindungsdaten, für Advisor-Funktionen der Anwendung und für Metric Server. Die proportionalen Gewichtungen müssen in der Summe stets 100 ergeben.
Wenn Sie einen Service konfigurieren, werden die Standardmetriken activeconn und connrate definiert. Falls Sie zusätzliche oder gänzlich andere Metriken verwenden möchten, geben Sie Folgendes ein:
service metrics ID_de_Switch-Consultants:Service-ID Metrikname 50 Metrikname2 50
Geben Sie zum Starten des Consultant Folgendes ein:
consultant start ID_des_Switch-Consultants
Mit diesem Befehl werden die Metrik-Collector gestartet, und die Berechnung von Wertigkeiten beginnt.
Geben Sie Folgendes ein, um die hohe Verfügbarkeit zu konfigurieren:
highavailability add address IP-Adresse partneraddress IP-Adresse port 80 role primary
Ausführliche Informationen zur Verwendung und Konfiguration der hohen Verfügbarkeit für den Controller finden Sie im Abschnitt Erweiterte Features für Cisco CSS Controller und Nortel Alteon Controller.
Wenn Sie in Schritt 5 Systemmetriken definiert haben, muss auf den Servicemaschinen Metric Server gestartet werden. Informationen zur Verwendung von Metric Server finden Sie im Abschnitt Metric Server.
Wenn Sie die Konfiguration auf dem Nortel Alteon Web Switch ändern, können Sie die Controllerkonfiguration aktualisieren. Geben Sie Folgendes ein:
service refresh
Beenden Sie den Consultant vor dem Aktualisieren der Konfiguration. Starten Sie den Consultant neu, wenn der Befehl "refresh" die Konfiguration aktualisiert hat.
Testen Sie wie folgt, ob die Konfiguration korrekt ist:
Dieser Teil enthält Informationen zu den Funktionen und erweiterten Konfigurationsfeatures, die für Load Balancer verfügbar sind. Zu diesem Teil gehören die folgenden Kapitel:
In diesem Kapitel wird erklärt, wie die Lastausgleichparameter, die Manager, die Advisor-Funktionen und die Funktion Metric Server von Load Balancer konfiguriert werden.
Tabelle 15. Erweiterte Konfigurations-Tasks für Load Balancer
Task | Beschreibung | Referenzinformationen |
---|---|---|
Ändern der Einstellungen für den Lastausgleich (optional) |
Sie können die folgenden Einstellungen für den Lastausgleich ändern:
| Lastausgleich mit Load Balancer optimieren |
Verwendung von Scripts, um einen Alert zu generieren oder Serverausfälle zu protokollieren, wenn der Manager Server als inaktiv oder aktiv markiert | Load Balancer stellt Benutzer-Exits bereit, die Scripts aktivieren, wenn der Manager Server als inaktiv oder aktiv markiert. | Scripts zum Generieren eines Alerts oder Protokollieren eines Serverausfalls verwenden |
Advisor-Funktionen verwenden | Beschreibt die Advisor-Funktionen, die Berichte zu spezifischen Status Ihrer Server ausgeben. | Advisor-Funktionen |
Option "Anforderung/Antwort (URL)" der HTTP- oder HTTPS-Advisor-Funktion verwenden | 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- oder HTTPS-Advisor-Funktion konfigurieren |
Advisor-Funktion self verwenden | Stellt den Auslastungsstatus von Back-End-Servern für Load Balancer in einer Client/Server-WAN-Konfiguration bereit. | Advisor-Funktion "self" in einer Client/Server-WAN-Konfiguration |
Angepasste Advisor-Funktionen erstellen | Erklärt das Schreiben eigener angepasster Advisor-Funktionen. | Angepasste (anpassbare) Advisor-Funktion erstellen |
Verwendung des Agenten Metric Server | Metric Server stellt Informationen zur Systembelastung für Load Balancer bereit. | Metric Server |
Verwendung der WLM-Advisor-Funktion (Workload Manager) | Die WLM-Advisor-Funktion stellt Informationen zur Systembelastung für Load Balancer bereit. | WLM-Advisor-Funktion |
Die Managerfunktion von Load Balancer führt den Lastausgleich ausgehend von den folgenden Einstellungen durch:
Zur Optimierung des Lastausgleichs für Ihr Netz können Sie diese Einstellungen ändern.
Der Manager kann in seine Gewichtungsentscheidung alle oder einige der nachfolgend genannten externen Faktoren einfließen lassen:
Oder --
CPU: Prozentsatz der auf jeder am Lastausgleich beteiligten Servermaschine genutzten CPU (Vorgabe vom Agenten Metric Server). Für Site Selector wird diese Proportion an Stelle der Spalte für aktive Verbindungen angezeigt.
Oder --
Speicher: Prozentsatz des auf jeder am Lastausgleich beteiligten Servermaschine genutzten Speichers (Vorgabe vom Metric Server Agent). Für Site Selector wird diese Proportion an Stelle der Spalte für neue Verbindungen angezeigt.
Der Manager erhält die beiden ersten Werte (aktive und neue Verbindungen) neben der aktuellen Wertigkeit jedes Servers und anderen für die Berechnungen erforderlichen Informationen vom Executor. Diese Werte basieren auf Informationen, die intern vom Executor generiert und gespeichert werden.
Sie können die relative 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 Systemmetriken 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 Clientverbindungen schnell (wie bei kleinen Webseiten, die mit HTTP GET bedient werden), ist die Anzahl aktiver Verbindungen ziemlich klein. Wenn die Clientverbindungen langsamer sind (z. B. bei einer Datenbankabfrage), wird die Anzahl aktiver Verbindungen höher sein.
Sie sollten eine zu niedrige Proportionseinstellung für aktive und neue Verbindungen vermeiden. Wenn Sie diese beiden ersten Werte nicht jeweils auf mindestens 20 gesetzt haben, werden der Lastausgleich und die Glättungsfunktion inaktiviert.
Verwenden Sie zum Festlegen der proportionalen Bedeutung den Befehl dscontrol cluster set Cluster proportions . Weitere Informationen finden Sie im Abschnitt dscontrol cluster -- Cluster konfigurieren.
Die Managerfunktion 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 "dscontrol server" mit der Option "fixedweight" an. Eine Beschreibung der Option "fixedweight" finden Sie im Abschnitt Feste Wertigkeiten des Managers.
Wertigkeiten gelten für alle Server an einem Port. An einem bestimmten Port werden die Anfragen ausgehend von einem Vergleich der Wertigkeiten der einzelnen Server verteilt. Hat beispielsweise ein Server die Wertigkeit 10 und der andere Server die Wertigkeit 5, erhält der Server mit der Wertigkeit 10 doppelt so viele Anforderungen wie der Server mit der Wertigkeit 5.
Für die Wertigkeit, die ein Server haben kann, können Sie einen oberen Grenzwert angeben. Verwenden Sie dazu den Befehl dscontrol port set Port weightbound Wertigkeit. Mit diesem Befehl wird die Differenz festgelegt, die für die einzelnen Server hinsichtlich der Anzahl der Anforderungen gelten soll. Wird die Wertigkeitsobergrenze auf 1 gesetzt, können alle Server die Wertigkeit 1 haben. Stillgelegte Server haben die Wertigkeit 0 und inaktive Server die Wertigkeit -1. Wenn Sie diese Zahl erhöhen, vergrößern sich die Unterschiede bei der Gewichtung von Servern. Bei einer Wertigkeitsobergrenze von 2 kann ein Server doppelt so viele Anforderungen wie ein anderer Server erhalten. Bei einer Wertigkeitsobergrenze von 10 kann ein Server zehn Mal so viele Anforderungen wie ein anderer Server erhalten. Die maximale Standardgewichtungsgrenze 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.
Wenn alle Server inaktiv sind, setzt der Manager die Wertigkeit auf die Hälfte der Gewichtungsgrenze.
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 "dscontrol server" mit der Option fixedweight. Beispiel:
dscontrol server set Cluster:Port:Server fixedweight yes
Nachdem Sie fixedweight auf yes gesetzt haben, können Sie die Wertigkeit mit dem Befehl dscontrol server set weight auf den gewünschten Wert setzen. Der Wert für die Serverwertigkeit bleibt während der Ausführung des Managers unverändert erhalten, bis Sie einen weiteren Befehl "dscontrol server" absetzen, bei dem "fixedweight" auf "no" gesetzt ist. Weitere Informationen hierzu finden Sie im Abschnitt dscontrol server -- Server konfigurieren.
Wenn TCP-Rücksetzanforderungen (reset) aktiviert sind, sendet der Dispatcher eine TCP-Rücksetzanforderung an den Client, sofern dieser eine Verbindung zu einem Server mit der Wertigkeit 0 hat. Die Wertigkeit eines Servers kann 0 sein, weil sie mit dem Wert 0 konfiguriert wurde oder weil der Server von einer Advisor-Funktion als inaktiv markiert wurde. Eine TCP-Rücksetzanforderung bewirkt eine sofortige Beendigung der Verbindung. Dieses Feature ist hilfreich für lang andauernde Verbindungen, denn sie gibt dem Client die Möglichkeit, eine unterbrochene Verbindung schnell neu auszuhandeln. Verwenden Sie zum Aktivieren von TCP-Rücksetzanforderungen den Befehl dscontrol port add|set Port reset yes. Der Standardwert für "reset" ist "no".
In Verbindung mit TCP-Rücksetzanforderungen kann es sinnvoll sein, das Feature advisor retry zu konfigurieren. Dieses Feature gibt einer Advisor-Funktion die Möglichkeit, einen erneuten Verbindungsversuch zu starten, bevor ein Server als inaktiv markiert wird. Auf diese Weise wird verhindert, dass die Advisor-Funktion den Server vorschnell als inaktiv markiert, was zu Problemen beim Zurücksetzen der Verbindung führen könnte. Ein erster gescheiterter Verbindungsversuch der Advisor-Funktion muss nicht zwingend bedeuten, dass die vorhandenen Verbindungen ebenfalls unterbrochen sind. Weitere Informationen finden Sie im Abschnitt Wiederholungsversuche der Advisor-Funktion.
Um den Gesamtdurchsatz zu optimieren, wird die Interaktion von Manager und Executor in ihrer Häufigkeit eingeschränkt. Sie können dieses Intervall mit den Befehlen dscontrol manager interval und dscontrol manager refresh ändern.
Mit dem Managerintervall wird angegeben, wie oft der Manager die Serverwertigkeiten aktualisiert, die der Executor für die Weiterleitung von Verbindungen benutzt. Ein zu niedriges Managerintervall kann sich negativ auf die Leistung auswirken, da der Manager den Executor permanent unterbricht. Ein zu hohes Managerintervall kann bedeuten, dass die Weiterleitung von Anforderungen durch den Executor nicht auf genauen, auf dem neuesten Stand befindlichen Informationen basiert.
Wollen Sie beispielsweise das Managerintervall auf 1 Sekunde setzen, geben Sie den folgenden Befehl ein:
dscontrol manager interval 1
Der Manageraktualisierungszyklus (Refresh) gibt an, wie oft der Manager Statusinformationen vom Executor anfordert. Der Aktualisierungszyklus basiert auf der Intervallzeit.
Wollen Sie beispielsweise den Manageraktualisierungszyklus auf 3 setzen, geben Sie den folgenden Befehl ein:
dscontrol manager refresh 3
In diesem Fall wartet der Manager 3 Intervalle ab, bevor er Statusinformationen vom Executor anfordert.
Zur Optimierung des Lastausgleichs für Ihre Server stehen weitere Methoden zur Verfügung. Im Interesse einer hohen Übertragungsgeschwindigkeit werden die Wertigkeiten der Server nur aktualisiert, wenn sich signifikante Änderungen der Wertigkeit ergeben. Das permanente Aktualisieren der Wertigkeiten bei geringfügigen oder nicht vorhandenen Änderungen des Serverstatus würde zu einem unnötigen Systemaufwand führen. Wenn die prozentuale Änderung der Wertigkeit innerhalb der summierten Wertigkeit für alle Server an einem Port über der Sensitivitätsschwelle liegt, aktualisiert der Manager die vom Executor für die Verteilung der Verbindungen verwendeten Wertigkeiten. Nehmen wir beispielsweise an, die Gesamtwertigkeit ändert sich von 100 % auf 105 %. Die Änderung beträgt also 5 %. Beim standardmäß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:
dscontrol manager sensitivity 6
In den meisten Fällen müssen Sie diesen Wert nicht ändern.
Der Manager berechnet die Serverwertigkeiten dynamisch. Daher kann eine aktualisierte Wertigkeit erheblich von der vorherigen Wertigkeit abweichen. In den meisten Fällen stellt dies kein Problem dar. Gelegentlich kann dies jedoch zu erheblichen Schwankungen bei der Verteilung von Anforderungen führen. So kann beispielsweise ein Server aufgrund seiner hohen Wertigkeit den größten Teil der Anforderungen erhalten. Der Manager stellt fest, dass der Server über eine hohe Anzahl von aktiven Verbindungen verfügt und sehr langsam antwortet. Der Manager verschiebt die Wertigkeit dann auf die freien Server, so dass dort derselbe Effekt auftritt und Ressourcen folglich ineffizient genutzt werden.
Um die Auswirkungen dieses Problems zu verringern, benutzt der Manager einen Glättungsfaktor. 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:
dscontrol manager smoothing 4
In den meisten Fällen müssen Sie diesen Wert nicht ändern.
Load Balancer 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 ...ibm/edge/lb/servers/samples. Zum Ausführen der Dateien müssen Sie sie in das Verzeichnis ...ibm/edge/lb/servers/bin verschieben und die Erweiterung "sample" löschen. Es stehen die folgenden Beispielscripts bereit:
Wenn alle Server eines Clusters (vom Benutzer oder von den Advisor-Funktionen) als inaktiv markiert wurden, wird managerAlert gestartet (sofern konfiguriert), und Load Balancer versucht, den Datenverkehr mit einer Round-Robin-Technik an die Server weiterzuleiten. Das Script serverDown wird nicht gestartet, wenn festgestellt wird, dass der letzte Server des Clusters offline ist.
Load Balancer ist so konzipiert, dass die Weiterleitungsversuche fortgesetzt werden, falls ein Server wieder online geht und auf die Anforderung reagiert. Würde Load Balancer dagegen den gesamten Datenverkehr übergehen, würde der Client keine Antwort empfangen.
Stellt Load Balancer fest, dass der erste Server eines Clusters wieder online ist, wird das Script managerClear gestartet (sofern konfiguriert). Das Script serverUp (sofern konfiguriert) wird erst ausgeführt, wenn ein weiterer Server wieder online ist.
Hinweise zur Verwendung der Scripts serverUp und serverDown:
Advisor-Funktionen sind Agenten in Load Balancer. 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 Load Balancer zu verwenden. (Die Telnet-Advisor-Funktion wird beispielsweise nicht mit der Komponente CBR verwendet.) Load Balancer unterstützt auch das Konzept angepasster Advisor-Funktionen, so dass Benutzer eigene Advisor-Funktionen schreiben können.
Einschränkung bei der Verwendung bindungsspezifischer Serveranwendungen: Wenn Sie Advisor-Funktionen für einen bindungsspezifischen Server verwenden möchten, müssen Sie zwei Instanzen des Servers starten, eine Instanz, die an den Cluster:Port gebunden wird, und eine, die an den Server:Port gebunden wird. Mit dem Befehl netstat -an können Sie feststellen, ob der Server bindungsspezifisch ist. Achten Sie auf den Server:Port. Wenn der Server nicht bindungsspezifisch ist, gibt der Befehl 0.0.0.0:80 zurück. Andernfalls sehen Sie eine Adresse wie 192.168.15.103:80.
Einschränkung bei der Verwendung bindungsspezifischer Serveranwendungen auf HP-UX- und Solaris-Systemen: Wenn an Stelle des Befehls "ifconfig alias" der Befehl "arp publish" verwendet wird, unterstützt Load Balancer die Verwendung von Advisor-Funktionen beim Lastausgleich für Server mit bindungsspezifischen Serveranwendungen (einschließlich anderer Komponenten von Load Balancer wie CBR oder Site Selector), wenn die Bindung an die Cluster-IP-Adresse erfolgt. Bei Verwendung von Advisor-Funktionen für eine bindungsspezifische Anwendung sollten Sie Load Balancer jedoch nicht mit der Serveranwendung auf derselben Maschine verknüpfen.
-DLB_ADV_SRC_ADDR=IP-Adresse
Advisor-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 Managerfunktion, die ihn im Managerbericht in der Spalte "Port" angibt. Der Manager addiert anschließend die Wertigkeiten für alle Quellen entsprechend ihren Proportionen und übergibt diese Werte an die Executor-Funktion. Der Executor benutzt diese Wertigkeiten dann für den Lastausgleich neuer ankommender Clientverbindungen.
Stellt 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 daraufhin keine Verbindungen an diesen Server weiter, solange dieser inaktiv ist.
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 Load Balancer beispielsweise mit drei Clustern (ClusterA, ClusterB, ClusterC), jeweils mit Port 80, konfiguriert haben, können Sie folgende Schritte ausführen:
dscontrol advisor start http ClusterA: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.
dscontrol advisor start angepasster_Advisor 80Dieser Befehl startet die Advisor-Funktion angepasster_Advisor am Port 80 von ClusterB und ClusterB. 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 Angepasste (anpassbare) Advisor-Funktionen.)
Wenn Sie das vorherige 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.
dscontrol advisor stop angepasster_Advisor ClusterB:80
dscontrol 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 die Advisor-Funktion 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:
dscontrol advisor interval http 80 3
Es ist nicht sinnvoll, ein Advisor-Intervall anzugeben, das kleiner als das Managerintervall 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:
dscontrol advisor timeout http 80 30
Weitere Informationen zum Festlegen des Berichtszeitlimits für die Advisor-Funktion finden Sie im Abschnitt dscontrol advisor -- Advisor-Funktion steuern.
Für Load Balancer können Sie die Zeitlimits der Advisor-Funktion festlegen, innerhalb derer der Ausfall eines bestimmten Server- oder Serviceports 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 die das Intervall 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:
dscontrol advisor connecttimeout http 80 9 dscontrol advisor receivetimeout http 80 9
Der Standardwert für das Verbindungs- und Empfangszeitlimit liegt beim Dreifachen des Wertes, der für das Intervall der Advisor-Funktion angegeben wurde.
Advisor-Funktionen können wiederholt versuchen, eine Verbindung herzustellen, bevor sie einen Server als inaktiv markieren. Die Advisor-Funktion markiert einen Server erst als inaktiv, wenn die Abfrage nach der festgelegten Anzahl Wiederholungen und einem weiteren Versuch nicht beantwortet wird. Der Wert für retry sollte nicht über 3 liegen. Mit dem folgenden Befehl wird "retry" für die LDAP-Advisor-Funktion am Port 389 auf "2" gesetzt:
dscontrol advisor retry ldap 389 2
Die URL-Option der HTTP- oder HTTPS-Advisor-Funktion ist für die Komponenten Dispatcher und CBR verfügbar.
Nach dem Starten einer HTTP- oder HTTPS-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 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 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- oder HTTPS-Advisor-Funktion verwendet die Zeichenfolge advisorrequest, um den Status der Server abzufragen. Der Standardwert ist HEAD / HTTP/1.0. Die advisorresponse-Zeichenfolge ist die Antwort, nach der die Advisor-Funktion die HTTP-Antwort durchsucht. Die Advisor-Funktion vergleicht die advisorresponse-Zeichenfolge mit der tatsächlich vom Server empfangenen Antwort. Der Standardwert ist null.
Wichtiger Hinweis: Wenn die HTTP-URL-Zeichenfolge ein Leerzeichen enthält, gilt Folgendes:
server set cluster:port:server advisorrequest "head / http/1.0" server set Cluster:Port:Server advisorresponse "HTTP 200 OK"
dscontrol server set Cluster:Port:Server advisorrequest "\"head / http/1.0\"" dscontrol server set Cluster:Port:Server advisorresponse "\"HTTP 200 OK\""
Wenn Sie die Anforderung erstellen, die die HTTP- oder HTTPS-Advisor-Funktion an Back-End-Server sendet, um deren Funktionstüchtigkeit zu überprüfen, geben Sie nur den Anfang der HTTP-Anforderung ein. Load Balancer vervollständigt die Anforderung mit folgenden Angaben:
\r\nAccept: */*\r\nUser-Agent:IBM_Network_Dispatcher_HTTP_Advisor\r\n\r\n
Falls Sie weitere HTTP-Header-Felder hinzufügen möchten, bevor Load Balancer diese Zeichenfolge an das Ende der Anforderung anfügt, können Sie eine eigene \r\n-Zeichenfolge in die Anforderung aufnehmen. Nachfolgend sehen Sie eine Beispieleingabe für das Hinzufügen des HTTP-Header-Feldes "Host" zur Anforderung:
GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHost: www.w3.org
Weitere Informationen finden Sie im Abschnitt dscontrol server -- Server konfigurieren.
Die Advisor-Funktion self ist für die Komponente Dispatcher verfügbar.
Wenn Load Balancer in einer Client/Server-WAN-Konfiguration (Weitverkehrsnetz) installiert ist, stellt der Dispatcher eine Advisor-Funktion self bereit, die Informationen zum Auslastungsstatus von Back-End-Servern sammelt.
Abbildung 34. Beispiel für eine Client/Server-WAN-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 Load Balancer 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 dsloadstat-Datei. Load Balancer stellt außerdem die externe Metrik "dsload" bereit. Der Metric-Server-Agent auf jeder Dispatcher-Maschine führt sein Konfigurationsprogramm aus, das die externe Metrik "dsload" aufruft. Das dsload-Script extrahiert eine Zeichenfolge aus der Datei "dsloadstat" und gibt sie an den Agenten Metric Server zurück. Anschließend geben die Metric-Server-Agenten (von den einzelnen Dispatcher-Maschinen) den Wert für den Auslastungsstatus an den übergeordneten Load Balancer zurück, damit dieser bestimmen kann, welcher Dispatcher Clientanforderungen weiterleiten soll.
Die ausführbare dsload-Datei befindet sich im Load-Balancer-Verzeichnis ...ibm/edge/lb/ms/script.
Weitere Informationen zur Verwendung von Dispatcher in WAN-Konfigurationen finden Sie im Abschnitt Dispatcher-WAN-Unterstützung konfigurieren. Weitere Informationen zu Metric Server können Sie dem Abschnitt Metric Server entnehmen.
Die angepasste (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 Managerfunktion. 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 das Flag "replace" der Methode "constructor" auf "false" 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 das Flag "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 Load Balancer wird ein Beispiel für eine angepasste Advisor-Funktion,
ADV_sample.java, geliefert. Nach der Installation von Load Balancer finden Sie den Beispielcode
im folgenden Installationsverzeichnis:
...<Installationsverzeichnis>/servers/samples/CustomAdvisors.
Die Standardwerte für Installationsverzeichnis sind im Folgenden aufgelistet:
Wenn die angepasste Advisor-Funktion auf zusätzliche Java-Klassen verweist, muss der Klassenpfad (classpath) in der Startscriptdatei von Load Balancer (dsserver, cbrserver, ssserver) mit dem Verzeichnis dieser Klassen aktualisiert werden.
Das Installationsverzeichnis von Load Balancer enthält Beispieldateien für angepasste Advisor-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_eigenerAdvisor.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. Verwenden Sie den Java-Compiler, der zusammen mit Load Balancer installiert wird. Während der Kompilierung wird auf die folgenden Dateien Bezug genommen:
Der Klassenpfad muss während der Kompilierung auf die Datei der angepassten Advisor-Funktion und die Datei mit den Basisklassen zeigen.
Beispielkompilierungsbefehl für Windows-Systeme:
Installationsverzeichnis/java/bin/javac -classpath Installationsverzeichnis\lb\servers\lib\ibmlb.jar ADV_fred.java
Für diese Angaben 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 Installationsverzeichnis ...ibm/edge/lb/servers/lib/CustomAdvisors.
Für AIX-, HP-UX-, Linux- und Solaris-Systeme ist die Syntax ähnlich.
Bevor Sie die angepasste Advisor-Funktion ausführen, müssen Sie die Klassendatei in das richtige Unterverzeichnis des Installationsverzeichnisses kopieren:
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_fred.class
Konfigurieren Sie die Komponente, starten Sie die zugehörige Managerfunktion und setzen Sie wie folgt den Befehl zum Starten der angepassten Advisor-Funktion ab:
dscontrol advisor start fred 123
Für diese Angaben gilt Folgendes:
Wenn die angepasste Advisor-Funktion auf zusätzliche Java-Klassen verweist, muss der Klassenpfad (classpath) in der Startscriptdatei von Load Balancer (dsserver, cbrserver, ssserver) mit dem Verzeichnis dieser Klassen aktualisiert werden.
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 einem Flag 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:
Load Balancer durchsucht zunächst die Liste der eigenen Advisor-Funktionen. Wenn eine bestimmte Advisor-Funktion dort nicht aufgeführt ist, durchsucht Load Balancer die Kundenliste der angepassten Advisor-Funktionen.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Programme\IBM\edge\lb\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 ...ibm/edge/lb/servers/samples/CustomAdvisors.
Diese Funktion ist für alle Komponenten von Load Balancer verfügbar.
Metric Server stellt Load Balancer Informationen zur Serverauslastung bereit. Diese Informationen werden in Form systemspezifischer Metriken für den Serverzustand bereitgestellt. Der Load-Balancer-Manager richtet Anfragen an den Metric-Server-Agenten, der sich auf jedem der Server befindet, und legt anhand der Metriken, die er von den Agenten erhalten hat, Wertigkeiten für den Lastausgleich fest. Die Ergebnisse werden auch in den Managerbericht gestellt.
Informationen zur Verwendung (zum Starten und Stoppen) von Metric Server und zur Verwendung von Metric-Server-Protokollen finden Sie im Abschnitt Komponente Metric Server verwenden.
Ein Konfigurationsbeispiel sehen Sie in Abbildung 5.
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 Managerberichts. Deshalb wird die gleichzeitige Ausführung der Advisor-Funktionen WLM und Metric Server nicht unterstützt.
Der Metric-Server-Agent muss auf allen Servern installiert und ausgeführt werden, die am Lastausgleich teilnehmen.
Nachfolgend sind die Schritte aufgeführt, mit denen Sie Metric Server für den Dispatcher konfigurieren. Wenn Sie Metric Server für andere Komponenten von Load Balancer konfigurieren möchten, sind ähnliche Schritte auszuführen.
Port ist hier der ausgewählte RMI-Port für alle Metric-Server-Agenten. Der in der Datei "metricserver.cmd" festgelegte Standard-RMI-Port ist 10004.
Systemmetrik ist hier der Name des Scripts (auf dem Back-End-Server), das für jeden Server, der unter dem angegebenen Cluster (oder Sitenamen) in der Konfiguration enthalten ist, ausgeführt werden soll. Für den Kunden stehen die beiden Scripts cpuload und memload bereit. Sie können auch angepasste Systemmetrikscripts erstellen. Das Script enthält einen Befehl, der einen numerischen Wert im Bereich von 0-100 oder, bei inaktivem Server, den Wert -1 zurückgeben sollte. Dieser numerische Wert sollte eine Lastmessung und keinen Verfügbarkeitswert darstellen.
Einschränkung: Wenn der Name Ihres Systemmetrikscripts auf der Windows-Plattform eine andere Erweiterung als ".exe" hat, müssen Sie den vollständigen Namen der Datei (z. B. "mysystemscript.bat") angeben. Dies ist auf eine Java-Einschränkung zurückzuführen.
Optional können Kunden ihre eigenen angepassten Systemmetrikscriptdateien 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 ...ibm/edge/lb/ms/script befinden. Angepasste Scripts müssen einen numerischen Lastwert zwischen 0 und 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.
Auf der Windows-Plattform müssen Sie außerdem in Microsoft Stack auf der Metric-Server-Maschine den Aliasnamen für andere_Adresse angeben. Beispiel:
call netsh interface ip add address "LAN-Verbindung" addr=9.37.51.28 mask=255.255.240.0
Wenn Sie Metriken domänenübergreifend erfassen, müssen Sie java.rmi.server.hostname im Serverscript (dsserver, cbrserver usw.) auf den vollständig qualifizierten Domänennamen (FQDN) der Maschine setzen, die die Metriken anfordert. Dies ist notwendig, weil InetAddress.getLocalHost.getHostName() nicht für jede Konfiguration und unter jedem Betriebssystem den FQDN zurückgibt.
WLM ist Code, der auf MVS-Großrechnern ausgeführt wird. Er kann abgefragt werden, um die 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-Hosttabelle und akzeptiert die zurückgegebenen ganzzahligen Kapazitätswerte. Da diese ganzen Zahlen die noch verfügbare Kapazität darstellen und Dispatcher Werte erwarten, die die Belastung auf jeder Maschine angeben, werden die ganzzahligen Kapazitätswerte vom Advisor in Lastwerte umgekehrt und normalisiert. (Ein hoher ganzzahliger Kapazitätswert und ein niedriger Lastwert geben beide einen akzeptablen Zustand eines Servers an). Die daraus resultierenden Belastungen werden in die Spalte "System" des Managerberichts gestellt.
Es gibt mehrere wichtige Unterschiede zwischen dem WLM-Advisor und anderen Advisor-Funktionen des Dispatchers:
Der WLM-Agent gibt wie der Metric-Server-Agent Berichte zu kompletten Serversystemen aus und nicht zu einzelnen protokollspezifischen Serverdämonen. Metric Server und WLM stellen ihre Ergebnisse in die Spalte "System" des Managerberichts. Deshalb wird die gleichzeitige Ausführung der Advisor-Funktionen WLM und Metric Server nicht unterstützt.
In diesem Kapitel wird erklärt, wie die Lastausgleichparameter konfiguriert werden und Load Balancer für die Verwendung der erweiterten Funktionen eingerichtet wird.
Tabelle 16. Erweiterte Konfigurations-Tasks für Load Balancer
Task | Beschreibung | Referenzinformationen |
---|---|---|
Verknüpfung von Load Balancer mit einer am Lastausgleich beteiligten Maschine | Verknüpfte Load-Balancer-Maschine konfigurieren | Verknüpfte Server verwenden |
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 |
Außerkraftsetzung der Portaffinität für Server | Ermöglicht einem Server, die Einstellung für stickytime an seinem Port zu überschreiben. | Portaffinität außer Kraft setzen |
Verwendung der Affinitätsfunktion zum Konfigurieren einer Haltezeit für einen Clusterport | Clientanforderungen werden immer an denselben Server gerichtet. | Funktionsweise der Affinität für Load Balancer |
Verwendung der Crossport-Affinität, um die Affinität an allen Ports zu nutzen | Von verschiedenen Ports empfangene Clientanforderungen werden an einen Server gerichtet. | Crossport-Affinität |
Verwendung der Affinitätsadressmaske zum Festlegen einer gemeinsamen IP-Teilnetzadresse | Aus einem Teilnetz empfangene Clientanforderungen werden an denselben Server gerichtet. | Affinitätsadressmaske (stickymask) |
Verwendung der aktiven Cookie-Affinität für den Serverlastausgleich mit CBR | Diese Regeloption ermöglicht die Bindung einer Sitzung an einen bestimmten Server. | Aktive Cookie-Affinität |
Verwendung der passiven Cookie-Affinität für den Serverlastausgleich mit der inhaltsabhängige Weiterleitung des Dispatchers und mit CBR | 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 |
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 |
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 Platzhaltercluster | Adressen, die nicht explizit konfiguriert sind, verwenden den Platzhaltercluster für die Verteilung des Datenverkehrs. | Platzhaltercluster zum Zusammenfassen von Serverkonfigurationen verwenden |
Verwendung eines Platzhalterclusters für den Lastausgleich bei Firewalls | Der gesamte Datenverkehr für Firewalls wird verteilt. | Platzhaltercluster für den Lastausgleich von Firewalls verwenden |
Platzhaltercluster mit Caching Proxy für transparente Weiterleitung verwenden | Der Dispatcher kann zum Aktivieren einer transparenten Weiterleitung verwendet werden. | Platzhaltercluster mit Caching Proxy für transparente Weiterleitung verwenden |
Verwendung eines Platzhalterports für die Übertragung von Datenverkehr mit nicht konfiguriertem Port | Ermöglicht die Bearbeitung von Datenverkehr, der für keinen bestimmten Port konfiguriert ist. | Platzhalterport für die Übertragung von Datenverkehr mit nicht konfiguriertem Port verwenden |
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äre Protokolle für die Analyse von Serverstatistiken verwenden |
Verwendung einer verknüpften Clientkonfiguration | Load Balancer kann sich auf derselben Maschine wie ein Client befinden. | Verknüpften Client verwenden |
Load Balancer 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 und Site Selector. Für CBR wird die Verknüpfung auch unterstützt. Dies gilt jedoch nur bei Verwendung bindungsspezifischer Webserver und Caching-Proxy-Server.
Linux-Systeme: Wenn Sie bei Ausführung der Komponente Dispatcher mit der Weiterleitungsmethode "mac" sowohl die Verknüpfung als auch die hohe Verfügbarkeit konfigurieren möchten, lesen Sie die Informationen im Abschnitt Alternativen für die Festlegung eines Loopback-Aliasnamens unter Linux bei Verwendung der Load-Balancer-Weiterleitungsmethode "mac".
Windows-Systeme: Wenn Sie bei Ausführung der Komponente Dispatcher mit der Weiterleitungsmethode "mac" sowohl die Verknüpfung als auch die hohe Verfügbarkeit konfigurieren möchten, lesen Sie die Informationen im Abschnitt Verknüpfung und hohe Verfügbarkeit konfigurieren (Windows-Systeme).
Solaris-Systeme: Sie können keine WAN-Advisor-Funktionen konfigurieren, wenn der Eingangspunkt-Dispatcher verknüpft ist. Weitere Informationen finden Sie im Abschnitt Ferne Advisor-Funktionen mit der Dispatcher-WAN-Unterstü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 dscontrol 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. Der Parameter "collocated" sollte nicht für Server gesetzt werden, die mittels der Dispatcher-Weiterleitungsmethode "nat" oder "cbr" verknüpft wurden.
Einen verknüpften Server können Sie auf eine der folgenden Arten konfigurieren:
Bei der Dispatcher-Weiterleitungsmethode "nat" oder "cbr" müssen Sie für die NFA eine nicht verwendete Adapteradresse konfigurieren (bzw. einen Aliasnamen festlegen). Der Server sollte so konfiguriert werden, dass er an dieser Adresse empfangsbereit ist. Konfigurieren Sie den Server mit der folgenden Befehlssyntax:
dscontrol server add Cluster:Port:neuer_Alias address neuer_Alias router Router-IP returnaddress Rückkehradresse
Wird der Server nicht wie angegeben konfiguriert, können Systemfehler auftreten und/oder Antworten vom Server ausbleiben.
Wenn Sie einen verknüpften Server mit der Weiterleitungsmethode "nat" von Dispatcher konfigurieren, müssen Sie im Befehl dscontrol server add für den Router eine reale Router-Adresse und nicht die Server-IP-Adresse angeben.
Beim Konfigurieren der Dispatcher-Weiterleitungsmethode "nat" kann jetzt unter allen Betriebssystemen Unterstützung für die Verknüpfung konfiguriert werden. Dazu müssen auf der Dispatcher-Maschine die folgenden Schritte ausgeführt werden:
arp -s hostname ether_addr pub
Verwenden Sie für ether_addr die lokale MAC-Adresse. Dies ermöglicht der lokalen Anwendung, Datenverkehr an die Rückkehradresse im Kernel zu senden.
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.
Site Selector unterstützt die Verknüpfung auf allen Plattformen, ohne zusätzliche Konfigurationsschritte zu erfordern.
Die hohe Verfügbarkeit (die mit dem Befehl dscontrol highavailability konfiguriert wird) ist für die Komponente Dispatcher verfügbar (jedoch nicht für die Komponenten CBR und Site Selector).
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 Clusterdatenverkehr 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 dscontrol highavailability können Sie dem Abschnitt dscontrol highavailability -- Hohe Verfügbarkeit steuern entnehmen.
Im Abschnitt Dispatcher-Maschine konfigurieren sind die meisten der nachfolgend aufgeführten Tasks genauer beschrieben.
dscontrol 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 Clusterdatenverkehr 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.
Legt die Zeit in Sekunden fest, die der Executor als Zeitlimit für die Überwachungssignale für hohe Verfügbarkeit verwendet. Beispiel:
dscontrol executor set hatimeout 3
Der Standardwert sind 2 Sekunden.
dscontrol highavailability reach add 9.67.125.18Erreichbarkeitsziele werden empfohlen, sind aber nicht erforderlich. Weitere Informationen finden Sie im Abschnitt Fehlererkennung mit Hilfe von Überwachungssignal und Erreichbarkeitsziel.
dscontrol highavailability backup add primary [auto | manual] Port
dscontrol highavailability backup add backup [auto | manual] Port
dscontrol highavailability backup add both [auto | manual] Port
dscontrol 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. Die Strategien müssen identisch sein.
dscontrol cluster set ClusterA primaryhost NFA-Dispatcher1 dscontrol cluster set ClusterB primaryhost NFA-Dispatcher2
dscontrol cluster set ClusterB primaryhost NFA-Dispatcher2 dscontrol cluster set ClusterA primaryhost NFA-Dispatcher1
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. Die beiden Partner für hohe Verfügbarkeit tauschen ständig Überwachungssignale und Informationen darüber aus, wie viele Erreichbarkeitsziele jeder von ihnen mit einem ping-Signal erreichen kann. Wenn der Bereitschafts-Dispatcher mehr Erreichbarkeitsziele mit einem ping-Signal erreichen kann, übernimmt er die Aufgaben des primären Dispatchers.
Der aktive Dispatcher sendet jede halbe Sekunde ein Überwachungssignal, das normalerweise vom Bereitschafts-Dispatcher empfangen wird. Sollte der Bereitschafts-Dispatcher zwei Sekunden kein Überwachungssignal empfangen, beginnt er mit der Funktionsübernahme. Die Funktionsübernahme durch den Bereitschafts-Dispatcher findet jedoch nur statt, wenn alle Überwachungssignale ausfallen. Wenn zwei Überwachungssignalpaare konfiguriert sind, müssen demnach beide ausfallen. Konfigurieren Sie zur Stabilisierung einer Umgebung mit hoher Verfügbarkeit mehr als ein Überwachungssignalpaar, damit ständige Funktionsübernahmen vermieden werden.
Als Erreichbarkeitsziele sollten Sie 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 der Advisor-Funktion reach abgefragt. Es findet eine Funktionsübernahme statt, wenn keine Überwachungssignalnachrichten durchkommen oder die Erreichbarkeitskriterien vom Bereitschafts-Dispatcher eher erfüllt werden als vom 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 Strategiearten:
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 wechselseitiger hoher Verfügbarkeit gibt es keinen Fehler auf Clusterbasis. 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, muss ein Aliasname für jede Clusteradresse auf einer Netzschnittstelleneinheit angegeben werden.
Informationen zur Festlegung eines Aliasnamens auf der Netzschnittstellenkarte finden Sie im Abschnitt Schritt 5. Aliasnamen auf der Netzschnittstellenkarte erstellen.
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. Beispielscripts finden Sie im Verzeichnis ...ibm/edge/lb/servers/samples. Zum Ausführen müssen Sie diese in das Verzeichnis ...ibm/edge/lb/servers/bin verschieben. Die Scripts werden automatisch nur ausgeführt, wenn dsserver aktiv ist.
Anmerkungen:
Sie können die folgenden Beispielscripts verwenden:
Auf Windows-Systemen: Wenn Sie Ihre Konfiguration so eingerichtet haben, dass Site Selector den Lastausgleich für zwei Dispatcher-Maschinen in einer Umgebung mit hoher Verfügbarkeit durchführt, müssen Sie im Microsoft Stack einen Aliasnamen für die Metric Server hinzufügen. Dieser Aliasname sollte auch zum Script goActive hinzugefügt werden. Beispiel:
call netsh interface ip add address "LAN-Verbindung" 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 "LAN-Verbindung" 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 "LAN-Verbindung" mit einer Nummer (z. B. "LAN-Verbindung 2"), so dass Sie bestimmen, welche Schnittstelle Sie verwenden sollten.
Unter Linux für S/390: Der Dispatcher setzt unaufgefordert ein ARP ab (gratuitous ARP), um IP-Adressen von einem Dispatcher auf einen anderen Dispatcher zu versetzen. Dieser Mechanismus ist somit an den Typ des zugrundeliegenden Netzes gebunden. Wenn Sie Linux für S/390 verwenden, kann der Dispatcher seine native Funktion für eine vollständig Funktionsübernahme für hohe Verfügbarkeit (mit Verschiebung der IP-Adressen) nur für Schnittstellen ausführen, die unaufgefordert ein ARP absetzen und die Adresse auf der lokalen Schnittstelle konfigurieren können. Auf Punkt-zu-Punkt-Schnittstellen wie IUCV und CTC sowie in bestimmten Konfigurationen von qeth/QDIO kann dieser Mechanismus nicht ordnungsgemäß funktionieren.
Für Schnittstellen und Konfigurationen, bei denen die native Dispatcher-Funktion der IP-Übernahme nicht ordnungsgemäß ausgeführt werden kann, kann der Kunde entsprechende Befehle in die go-Scripts aufnehmen, um die Adressen manuell zu versetzen. Auf diese Weise wird sichergestellt, dass auch diese Netztopologien von der hohen Verfügbarkeit profitieren können.
Auf Windows-Servern können Sie die Load-Balancer-Features "Hohe Verfügbarkeit" und "Verknüpfung" zusammen konfigurieren. Hierfür sind allerdings einige zusätzliche Schritte erforderlich.
Wenn Sie auf Windows-Systemen die Verknüpfung zusammen mit der hohen Verfügbarkeit nutzen möchten, benötigen Sie eine zusätzliche IP-Adresse. Dies ist eine Art Pseudoadresse, die zum Loopback-Adapter des Windows-Systems hinzugefügt werden kann. Der Loopback-Adapter muss auf der primären Maschine und der Ausweichmaschine installiert sein. Die Schritte für die Installation der Loopback-Einheit auf Windows-Systemen sind im Abschnitt Servermaschinen für Lastausgleich konfigurieren aufgelistet.
Wenn Sie in diesen Schritten aufgefordert werden, die Cluster-IP-Adresse zur Loopback-Einheit hinzuzufügen, müssen Sie an Stelle der Clusteradresse eine Pseudo-IP-Adresse hinzufügen. Dies liegt daran, dass die go*-Scripts für hohe Verfügbarkeit für Windows die Clusteradresse für die Loopback-Einheit löschen oder zur Loopback-Einheit hinzufügen müssen, je nachdem, ob die Load-Balancer-Maschine aktiv oder in Bereitschaft ist.
Die letzte konfigurierte IP-Adresse für die Loopback-Einheit kann auf Windows-Systemen nicht entfernt werden, weil die Loopback-Einheit nicht im DHCP-Modus funktioniert. Durch die Pseudoadresse kann Load Balancer seine Clusteradresse jederzeit entfernen. Die Pseudo-IP-Adresse wird für keine Art von Datenverkehr verwendet und kann sowohl auf der aktiven Maschine als auch auf der Ausweichmaschine verwendet werden.
Aktualisieren Sie die go*-Scripts von Load Balancer und verschieben Sie sie auf die aktive Maschine und die Ausweichmaschine. Starten Sie dann Dispatcher. Die Clusteradresse wird zu den entsprechenden Zeiten zur Netzschnittstelle und zur Loopback-Einheit hinzugefügt oder von der Netzschnittstelle und der Loopback-Einheit entfernt.
Mit einem auf Regeln basierenden Lastausgleich kann genau abgestimmt werden, wann und warum Pakete an welche Server gesendet werden. Load Balancer ü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 verteilt dann die Last auf alle Server, die der Regel zugeordnet sind. Load Balancer verteilt die Last bereits ausgehend von Ziel und Port. Mit der Anwendung von Regeln haben Sie jedoch erweiterte Möglichkeiten für die Verteilung von Verbindungen.
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. Diese Standardregel 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 Clientanforderung 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 Komponente CBR müssen Sie in jedem Fall Regeln verwenden.
Es sind folgende Arten von Regeln verfügbar:
Erstellen Sie einen Plan der Logik, 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 Bereichsanfang und ein Bereichsende haben. Dem Regeltyp content für die Komponente CBR ist ein regulärer Ausdruck (pattern) für den Abgleich zugeordnet. (Beispiele und Szenarien für die Verwendung der Inhaltsregel sowie eine gültige pattern-Syntax für die Inhaltsregel finden Sie in Anhang B. Syntax für Inhaltsregeln (Muster).)
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.
Sie können Regeln auf der Basis der Client-IP-Adresse verwenden, wenn die Herkunft das Kriterium für die Auswahl von Kunden und die Ressourcenzuordnung sein soll.
Stellen Sie sich vor, dass in Ihrem Netz in großem Umfang ein unbezahlter und deshalb unerwünschter Datenaustausch von Clients mit bestimmten IP-Adressen stattfindet. In diesem Fall könnten Sie mit dem Befehl dscontrol rule eine Regel erstellen. Beispiel:
dscontrol 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 unerwünschte Clients aus. Anschließend fügen Sie die Server zur Regel hinzu, die zugänglich sein 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 nur für die Komponente Dispatcher 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 Clientports verwenden.
Sie könnten beispielsweise eine Regel erstellen, die angibt, dass für alle Anforderungen mit einem Clientport von 10002 eine Gruppe besonders schneller Server bereitgestellt wird, da bekannt ist, dass alle Clientanforderungen mit diesem Port von einer besonders wichtigen Kundengruppe stammen.
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 während der Spitzenzeit fünf zusätzliche 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 können Sie eine Regel erstellen, mit der die Server während der benötigten Wartungszeit ausgeschlossen werden.
Dieser Regeltyp ist nur für die Komponente Dispatcher 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 Clientanforderung mit einem TOS-Wert empfangen, der einen normalen Service angibt, kann die Anforderung an eine Servergruppe weitergeleitet werden. Wird eine andere Clientanforderung 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 dscontrol 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:
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
Dieser Regeltyp ist für die Komponenten Dispatcher und CBR verfügbar.
Vielleicht möchten Sie Regeln verwenden, die auf den Verbindungen pro Sekunde 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 zwei Ihrer fünf Server für Telnet reservieren, es sei denn, die Verbindungen pro Sekunde überschreiten eine bestimmte Zahl. In diesem Fall würde der Dispatcher zu Spitzenzeiten die Last auf alle fünf Server verteilen.
Regelauswertungsoption "upserversonrule" in Verbindung mit Regeln des Typs connection setzen: Wenn Sie Regeln des Typs connection verwenden und die Option upserversonrule setzen, können Sie sicherstellen, dass die übrigen Server nicht überlastet werden, falls einige Server der Gruppe heruntergefahren sind. Weitere Informationen finden Sie im Abschnitt Regeloption für Serverauswertung.
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 dscontrol rule oder mit dem Befehl cbrcontrol rule erstellen. Beispiel:
dscontrol rule add 130.40.52.153:80:pool2 type active 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.
Regeln für reservierte und gemeinsam genutzte Bandbreite sind nur für die Komponente Dispatcher verfügbar.
Für die Bandbreitenregeln errechnet der Dispatcher die Bandbreite als Geschwindigkeit, mit der die Daten von einer bestimmten Servergruppe an Clients geliefert werden. Der Dispatcher protokolliert die Kapazität auf Server-, Regel-, Port-, Cluster- und Executor-Ebene. Für jede dieser Ebenen gibt es ein Feld "Bytezähler", das übertragene Kilobytes pro Sekunde angibt. Der Dispatcher berechnet diese Geschwindigkeiten über einen Zeitraum von 60 Sekunden. Sie können diese Geschwindigkeitswerte auf der grafischen Benutzerschnittstelle (GUI) oder in der Ausgabe eines Befehlszeilenberichts anzeigen.
Mit der Regel "Reservierte Bandbreite" können Sie die von einer Servergruppe gelieferte Datenmenge in Kilobytes pro Sekunde steuern. 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:
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
Bereichsanfang und -ende werden in Kilobytes pro Sekunde angegeben.
Vor dem Konfigurieren der Regel "Gemeinsame Bandbreite" müssen Sie die maximale Bandbreite (Kilobytes pro Sekunde) angeben, die auf Executor- oder Clusterebene gemeinsam genutzt werden kann, indem Sie den Befehl dscontrol executor oder dscontrol cluster mit der Option "sharedbandwidth" verwenden. Der Wert für sharebandwidth sollte die insgesamt verfügbare Bandbreite (gesamte Netzkapazität) nicht überschreiten. Das Setzen der gemeinsam genutzten Bandbreite mit dem Befehl dscontrol gibt nur eine Obergrenze für die Regel an.
Nachfolgend sind Beispiele für die Befehlssyntax aufgeführt:
dscontrol executor set sharedbandwidth Größe dscontrol 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.
Bei gemeinsamer Nutzung von Bandbreite auf Clusterebene steht dem Cluster eine angegebene maximale Bandbreite zur Nutzung zur Verfügung. Solange die vom Cluster genutzte Bandbreite unter dem angegebenen Wert liegt, ist das Ergebnis der Auswertung für diese Regel true. Liegt die insgesamt genutzte Bandbreite über dem angegebenen Wert, ist das Ergebnis der Regelauswertung false.
Bei gemeinsamer Nutzung der Bandbreite auf Executor-Ebene kann die gesamte Dispatcher-Konfiguration eine maximale Bandbreite nutzen. Solange die auf Executor-Ebene genutzte Bandbreite unter dem angegebenen Wert liegt, ist das Ergebnis der Auswertung für diese Regel true. Liegt die insgesamt genutzte Bandbreite über der definierten Bandbreite, ist das Ergebnis der Regelauswertung false.
Nachfolgend einige Beispiele für das Hinzufügen oder Definieren einer sharedbandwidth-Regel:
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel Wert dscontrol 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.
Dispatcher gibt Ihnen die Möglichkeit, mit der Regel Reservierte Bandbreite Gruppen von Servern in Ihrer Konfiguration eine angegebene Bandbreite zuzuordnen. Durch Angabe von Bereichsanfang und -ende können Sie steuern, wie viele Kilobytes eine Servergruppe an Clients senden kann. Wenn die Regelauswertung nicht mehr das Ergebnis true ergibt (das Bereichsende überschritten wird), wird die Regel mit der nächst niedrigeren Priorität ausgewertet. Falls die Regel mit der nächst niedrigeren Priorität eine immer gültige Regel (always true) ist, könnte ein Server ausgewählt werden, der Clients eine Antwort vom Typ "Site ausgelastet" sendet.
Beispiel: Gehen wir von einer Gruppe mit drei Servern am Port 2222 aus. Wenn die reservierte Bandbreite auf 300 gesetzt ist, werden über einen Zeitraum von 60 Sekunden maximal 300 Kilobytes pro Sekunden übertragen. Wird diese Geschwindigkeit überschritten, ist das Ergebnis der Regelauswertung nicht mehr true. Falls dies die einzige Regel ist, würde der Dispatcher einen der drei Server zur Bearbeitung der Anfrage auswählen. Wenn es eine Regel mit niedrigerer Priorität ("always true") gibt, könnte die Anfrage an einen anderen Server umgeleitet und mit "Site ausgelastet" beantwortet werden.
Die Regel für gemeinsam genutzte Bandbreite erweitert den Serverzugriff für Clients. Wenn diese Regel als Regel niedrigerer Priorität nach einer Regel für reservierte Bandbreite verwendet wird, kann ein Client auch dann noch auf einen Server zugreifen, wenn die reservierte Bandbreite überschritten wurde.
Beispiel: Durch Verwendung einer Regel für gemeinsam genutzte Bandbreite nach einer Regel für reservierte Bandbreite können Sie Clients kontrolliert den Zugriff auf die drei Server gewähren. Solange gemeinsam genutzte Bandbreite verfügbar ist, wird die Regel mit dem Ergebnis true ausgewertet und der Zugriff gewährleistet. Ist die gemeinsam genutzte Bandbreite erschöpft, ist die Regel nicht true und es wird die nächste Regel ausgewertet. Folgt eine immer gültige Regel ("always true"), kann die Anfrage bei Bedarf umgeleitet werden.
Wenn Sie die reservierte und die gemeinsam genutzte Bandbreite wie im obigen Beispiel beschrieben verwenden, können Sie den Zugriff auf die Server geregelter und flexibler gewähren (oder verweigern). Für Server an einem spezifischen Port können Sie die nutzbare Bandbreite einschränken, während andere Server zusätzliche Bandbreite (im Rahmen der Verfügbarkeit) nutzen können.
Dieser Regeltyp ist nur für die Komponente Site Selector verfügbar.
Für die Regel "Metrik gesamt" wählen Sie eine Systemmetrik (cpuload, memload oder ein eigenes angepasstes Systemmetricscript) aus. Site Selector vergleicht die Systemmetrik (die vom Metric-Server-Agenten auf jedem Server mit Lastausgleich zurückgegeben wird) mit dem von Ihnen für die Regel festgelegten Bereichsanfang und -ende. Die Regel wird erst angewendet, wenn die aktuelle Metrik 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 "Metrik gesamt" zu Ihrer Konfiguration:
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
Dieser Regeltyp ist nur für die Komponente Site Selector verfügbar.
Für die Regel "Metrik Durchschnitt" wählen Sie eine Systemmetrik (cpuload, memload oder ein eigenes angepasstes Systemmetrikscript) aus. Site Selector vergleicht die Systemmetrik die vom Metric-Server-Agenten auf jedem Server mit Lastausgleich zurückgegeben wird) mit dem von Ihnen für die Regel festgelegten Bereichsanfang und -ende. Die Regel wird erst angewendet, wenn der Durchschnitt der aktuellen Metriken 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 "Metrikdurchschnitt" 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 diese vier 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, dass eingehende Clients keinen Service erhalten, wenn sie nicht den festgelegten Regeln entsprechen. Mit Hilfe des Befehls dscontrol rule würden Sie die folgende Regel erstellen:
dscontrol rule add 130.40.52.153:80:jamais type true priority 100
Wenn Sie anschließend keine Server zur Regel hinzufügen, werden die Clientpakete ohne Antwort gelöscht.
Sie können mehrere Regeln definieren, die immer wahr sind, und dann durch Ändern der Prioritätsebene festlegen, welche Regel angewendet werden soll.
Dieser Regeltyp ist in den Komponenten CBR und Dispatcher (bei Verwendung der Dispatcher-Weiterleitungsmethode "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 Inhaltsregel sowie eine gültige pattern-Syntax für die Inhaltsregel finden Sie in Anhang B. Syntax für Inhaltsregeln (Muster).
Mit der Außerkraftsetzung der Portaffinität können Sie die 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 Portaffinität können Sie bewirken, dass der Überlaufserver die diesem Port normalerweise zugeordnete 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.
Ausführliche Informationen zur Befehlssyntax für die Außerkraftsetzung der Portaffinität mit der Option sticky finden Sie im Abschnitt dscontrol server -- Server konfigurieren.
Zum Hinzufügen von Regeln können Sie den Befehl dscontrol 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. Er ordnet jedem Unternehmensbereich IP-Adressen zu. Er erstellt die erste Gruppe mit Regeln auf der Basis der Client-IP-Adressen, um zwischen den Lasten der einzelnen Unternehmensbereiche unterscheiden zu können.
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
Anschließend fügt der Systemadministrator zu jeder Regel einen anderen Server hinzu und misst dann die Last auf jedem der Server, um dem Unternehmensbereich die verwendeten Services korrekt in Rechnung zu stellen. Beispiel:
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
Die Option für Serverauswertung ist nur für die Komponente Dispatcher verfügbar.
Der Befehl dscontrol 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 Load Balancer konnten nur die Regelbedingungen für alle Server an einem Port erfasst werden.)
Anmerkungen:
Nachfolgend einige Beispiele für das Hinzufügen oder Definieren der Auswertungsoption für eine Regel "Reservierte Bandbreite":
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate Ebene dscontrol rule set 9.22.21.3:80:rbweval evaluate Ebene
Die Ebene für die Option Ebene kann auf port, rule oder upserversonrule 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.
Für die Komponenten Dispatcher und CBR: 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 Clientanforderungen an denselben Server übertragen werden. Dies geschieht, indem für die Option stickytime auf Executor-, Cluster- oder Portebene eine Haltezeit von einigen Sekunden angegeben wird. Sie können die Funktion inaktivieren, indem Sie stickytime auf null setzen.
Wird die Crossport-Affinität aktiviert, müssen die Werte für "stickytime" der gemeinsam benutzten Ports identisch (und ungleich null) sein. Weitere Informationen finden Sie im Abschnitt Crossport-Affinität.
Für die Komponente Site Selector: Wenn Sie einen Sitenamen als "sticky" konfigurieren, aktivieren Sie die Affinitätsfunktion. Bei einem als sticky konfigurierten Sitenamen kann der Client für mehrere Namensserviceanforderungen denselben Server verwenden. Geben Sie dazu als stickytime für den Sitenamen eine Haltezeit von einigen Sekunden an. Sie können die Funktion inaktivieren, indem Sie stickytime auf null setzen.
Die Haltezeit (stickytime) für einen Server ist das Intervall zwischen dem Schließen einer Verbindung und dem Öffnen einer neuen Verbindung. Innerhalb dieses Intervalls wird der Client an denselben Server wie bei der ersten Verbindung vermittelt. Nach Ablauf der Haltezeit kann der Client an einen anderen Server vermittelt werden. Die Haltezeit für einen Server wird mit den Befehlen "dscontrol" "executor", "port" oder "cluster" konfiguriert.
Wird bei inaktivierter Affinität eine neue TCP-Verbindung von einem Client empfangen, verwendet Load Balancer den zu diesem Zeitpunkt richtigen Server und leitet die Pakete an diesen Server weiter. Wird eine weitere Verbindung von demselben Client empfangen, behandelt Load Balancer diese Verbindung als eine neue Verbindung und wählt wieder den zu diesem Zeitpunkt richtigen Server aus.
Bei Aktivierung der Affinität wird eine nachfolgende Anforderung von demselben Client an denselben Server gerichtet.
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.
Ein Server wird mit dem Befehl "server down" (dscontrol server down) offline gesetzt, allerdings erst heruntergefahren, wenn das stickytime-Intervall abgelaufen ist.
Die Crossport-Affinität gilt nur für die Dispatcher-Weiterleitungsmethoden MAC und NAT/NATP.
Die Crossport-Affinität ist die Ausdehnung der Haltefunktion auf mehrere Ports. Wird beispielsweise eine Clientanforderung zuerst an einem Port und die nächste Anforderung an einem anderen Port empfangen, kann der Dispatcher die Clientanforderungen bei Crossport-Affinität an denselben Server senden. Die Ports müssen die folgenden Bedingungen erfüllen, um diese Funktion verwenden zu können:
Mehrere Ports können eine Verbindung zu demselben 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 Crossport-Affinität für Port 10:
dscontrol port set Cluster:20 crossport 10 dscontrol port set Cluster:30 crossport 10 dscontrol port set Cluster:40 crossport 10
Nachdem Sie die Crossport-Affinität konfiguriert haben, können Sie den Wert für die Haltezeit 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 Crossport-Affinität aufheben möchten, setzen Sie den Wert für "crossport" auf seine eigene Portnummer zurück. Ausführliche Informationen zur Befehlssyntax für die Option crossport finden Sie im Abschnitt dscontrol port -- Ports konfigurieren.
Die Affinitätsadressmaske gilt nur für die Komponente Dispatcher.
Die Affinitätsadressmaske ist eine Erweiterung der Sticky-Funktion, mit der Clients auf der Basis gemeinsamer Teilnetzadressen zusammengefasst werden. Wenn Sie stickymask mit dem Befehl dscontrol port angeben, können Sie die gemeinsamen höherwertigen Bits der 32-Bit-IP-Adresse maskieren. Wenn diese Funktion konfiguriert ist und eine Clientanforderung 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 Clientanforderungen 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 Clientanforderungen mit derselben Netzadresse der Klasse B zusammengefasst werden, setzen Sie den Wert für stickymask auf 16 (Bits). Sollen Clientanforderungen 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 Load Balancer definieren. Wird der Wert für stickymask dynamisch geändert, können unvorhersehbare Ergebnisse auftreten.
Interaktion mit Crossport-Affinität: Wenn Sie die Crossport-Affinität aktivieren, müssen die stickymask-Werte der gemeinsam genutzten Ports identisch sein. Weitere Informationen finden Sie im Abschnitt Crossport-Affinität.
Um die Affinitätsadressmaske zu aktivieren, setzen Sie einen ähnlichen Befehl dscontrol port wie den folgenden ab:
dscontrol port set Cluster:Port stickytime 10 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.
Ausführliche Informationen zur Befehlssyntax von stickymask (Feature für Affinitätsadressmaske) finden Sie im Abschnitt dscontrol port -- Ports konfigurieren.
Die Stilllegung gilt für die Komponenten Dispatcher und CBR.
Wenn Sie aus bestimmten Gründen (Aktualisierungen, Upgrades, Wartung usw.) einen Server aus der Load-Balancer-Konfiguration entfernen müssen, können Sie den Befehl dscontrol 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 die Option "quiesce now", 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:
dscontrol 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 Datenverkehrsaufkommens warten (vielleicht am frühen Morgen), um den Server vollständig aus der Konfiguration zu entfernen.
Mit dem Befehl dscontrol rule können Sie die folgenden Arten der Affinität angeben:
Die aktive Cookie-Affinität gilt nur für die Komponente CBR.
Die passive Cookie-Affinität gilt für die Komponente CBR sowie für die Weiterleitungsmethode "cbr" der Komponente Dispatcher.
Die URI-Affinität gilt für die Komponente CBR sowie für die Weiterleitungsmethode "cbr" der Komponente Dispatcher.
Der Standardwert für die Option "affinity" ist "none". Die Option stickytime für den Portbefehl (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.
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 dscontrol rule -- Regeln konfigurieren.
Wenn eine Regel für aktive Cookie-Affinität aktiviert wurde, wird der Lastausgleich für neue Clientanforderungen 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 Clientbrowser gespeichert wird. Das Cookie enthält die für die Entscheidungsfindung verwendete Angabe Cluster:Port:Regel, den Server, an den die Arbeitslast weitergeleitet wurde, und eine Zeitmarke für das Zeitlimit, bei dessen Erreichung die Affinität ungültig wird. Das Cookie hat das folgende Format: IBMCBR=Cluster:Port:Regel+Server-Zeit!. Die Angaben Cluster:Port:Regel und Server sind codiert, so das die CBR-Konfiguration nicht erkennbar ist.
Bei Erfüllung einer Regel mit gesetzter aktiver Cookie-Affinität wird das vom Client gesendete Cookie überprüft.
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 an diese Adresse zurück.
Jede Affinitätsinstanz im Cookie ist 65 Bytes lang und endet mit dem Ausrufezeichen. Ein 4096-Byte-Cookie kann demzufolge ungefähr 60 individuelle aktive Cookie-Regeln pro Domäne enthalten. Wenn das Cookie komplett gefüllt ist, werden alle abgelaufenen Affinitätsinstanzen gelöscht. Sollten noch alle Instanzen gültig sein, wird die älteste gelöscht und dafür die neue Instanz für die aktuelle Regel hinzugefügt.
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 Clientstatus auf dem Server speichern. Der Status wird durch eine Cookie-ID identifiziert (dies sind Server-Cookies). Der Clientstatus 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 aktive Cookie-Affinität verfällt standardmäßig nach der Zeit, die sich aus der Summe der aktuellen Serverzeit, der Haltezeit (stickytime) und 24 Stunden ergibt. Wenn Ihre Clients (die Anfragen an Ihre CBR-Maschine senden) auf ihren Systemen eine falsche Zeit eingestellt haben (so dass sie z. B. der Serverzeit mehr als einen Tag voraus sind), ignorieren die Systeme dieser Clients die Cookies von CBR, weil sie davon ausgehen, dass die Cookies schon verfallen sind. Zum Einstellen einer längeren Verfallszeit müssen Sie das Script cbrserver modifizieren. Editieren Sie die Zeile javaw in der Scriptdatei. Fügen Sie nach LB_SERVER_KEYS den folgenden Parameter ein: -DCOOKIEEXPIREINTERVAL=X. X steht hier für die Anzahl der Tage, die zur Verfallszeit addiert werden sollen.
Auf AIX-, Solaris- und Linux-Systemen finden Sie die Datei "cbrserver" im Verzeichnis /usr/bin.
Auf Windows-Systemen finden Sie die Datei "cbrserver" im Verzeichnis \winnt\system32.
Die passive Cookie-Affinität gilt für die inhaltsabhängige Weiterleitung (cbr) durch die Komponente Dispatcher und die Komponente CBR. Informationen zum Konfigurieren der Dispatcher-Weiterleitungsmethode "cbr" finden Sie im Abschnitt Dispatcher-Weiterleitungsmethode "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 Load Balancer den Server ausgehend von dem im HTTP-Header der Clientanforderung enthaltenen Cookie-Namen aus. Load Balancer vergleicht den Cookie-Namen aus dem HTTP-Header des Clients mit den für die einzelnen Server konfigurierten Cookie-Werten.
Findet Load Balancer einen Server, in dessen Cookie-Wert der Cookie-Name des Clients enthalten ist, wählt Load Balancer diesen Server für die Anforderung aus.
Wenn in der Clientanforderung kein Cookie-Name gefunden wird oder dieser in keinem der Server-Cookie-Werte enthalten ist, wird der Server mit Hilfe der vorhandenen Serverauswahlmethoden oder der gewichteten Round-Robin-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 Komponente CBR. Informationen zum Konfigurieren der Weiterleitungsmethode "cbr" finden Sie im Abschnitt Dispatcher-Weiterleitungsmethode "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 die Cachekapazität 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 Load Balancer neue eingehende Clientanforderungen mit demselben URI an einen Server weiter.
Normalerweise verteilt Load Balancer Anforderungen auf mehrere Server, die identische Inhalte bereitstellen. Wenn Sie Load Balancer 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 Clientbelastung, 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 Clientdatenvolumen 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 Load Balancer die Anforderungen nur an den Caching Server mit den entsprechenden Inhalten weiterleitet.
Bei Verwendung der URI-Affinität können Sie mit Load Balancer 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 Komponente Dispatcher 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 35). Eine Clientanforderung wird auf der Dispatcher-Maschine empfangen und an den Server gesendet. Der Server sendet die Antwort direkt zurück an den Client.
Abbildung 35. Beispiel einer Konfiguration mit einem LAN-Segment
Durch das WAN-Feature von Dispatcher werden Server an anderen Standorten, die als ferne Server bezeichnet werden, unterstützt (siehe Abbildung 36). 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. Ein Clientpaket wird vom Internet an die erste Dispatcher-Maschine und anschließend von dieser Maschine an eine Dispatcher-Maschine an einem anderen geografischen Standort sowie an einen der dort lokal angeschlossenen Server gesendet.
Für WAN-Konfigurationen müssen alle Dispatcher-Maschinen (lokale und ferne) ein Betriebssystem desselben Typs ausführen und eine gemeinsame Plattform haben.
Abbildung 36. Beispiel einer Konfiguration mit lokalen und fernen Servern
Damit kann eine Clusteradresse weltweit alle Clientanforderungen unterstützen und die Last auf Server auf der ganzen Welt verteilen.
An die Dispatcher-Maschine, die das Paket zunächst 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.
Führen Sie folgende Schritte aus, um die Weitverkehrsunterstützung zu konfigurieren:
dscontrol server add Cluster:Port:Server router Adresse
Weitere Informationen zum Schlüsselwort "router" finden Sie im Abschnitt dscontrol server -- Server konfigurieren.
Eingangspunkt-Dispatcher:
Eingangspunkt-Dispatcher, die auf der Plattform AIX, LINUX (mit GRE) oder Solaris ausgeführt werden, zeigen die Advisor-Last korrekt an. Andere Plattformen sind in Ermangelung eines Weitverkehrsnetzes auf einen Round-Robin-Lastausgleich bzw. auf die Dispatcher-Weiterleitungsmethode "nat" oder "cbr" angewiesen.
AIX-Systeme
HP-UX-Systeme
Linux-Systeme
Solaris-Systeme
arp -s meine_Clusteradresse meine_MAC-Adresse pub
Windows-Systeme
Ferne Dispatcher: Führen Sie für jede ferne Clusteradresse die folgenden Konfigurationsschritte aus. Für eine Konfiguration mit hoher Verfügbarkeit am fernen Dispatcher-Standort müssen Sie diese Schritte auf beiden Maschinen ausführen.
AIX-Systeme
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
HP-UX-, Linux-, Solaris- und Windows-Systeme
Abbildung 37. WAN-Beispielkonfiguration mit fernen Load-Balancer-Maschinen
Dieses Beispiel bezieht sich auf die in Abbildung 37 gezeigte Konfiguration.
Nachfolgend wird beschrieben, wie die Dispatcher-Maschinen für die Unterstützung der Clusteradresse xebec am Port 80 konfiguriert werden. LB1 ist als Eingangspunkt-Load-Balancer definiert. Es wird eine Ethernet-Verbindung vorausgesetzt. Für LB1 sind fünf Server definiert, drei lokale (ServerA, ServerB, ServerC) und zwei ferne (LB2 und LB3). Für die fernen Load Balancer LB2 und LB3 sind jeweils drei lokale Server definiert.
Führen Sie an der Konsole des ersten Dispatchers (LB1) die folgenden Schritte aus:
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
An der Konsole des zweiten Dispatchers (LB2):
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
An der Konsole des dritten Dispatchers (LB3):
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
Generic Routing Encapsulation (GRE) ist ein Internetprotokoll, das in RFC 1701 und RFC 1702 spezifiziert ist. Bei Verwendung von GRE kann Load Balancer 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 Komponente Dispatcher die Arbeitslast von Paketen auf mehrere Serveradressen verteilen, die einer MAC-Adresse zugeordnet sind.
Load Balancer implementiert GRE im Rahmen der WAN-Funktion. Auf diese Weise stellt Load Balancer WAN-Lastausgleich direkt für alle Serversysteme zur Verfügung, die GRE-Pakete entpacken können. Load Balancer muss nicht auf einem fernen System installiert sein, wenn die fernen Server eingebundene GRE-Pakete unterstützen. Load Balancer integriert WAN-Pakete, deren GRE-Feld auf den Dezimalwert 3735928559 gesetzt ist.
Abbildung 38. WAN-Beispielkonfiguration mit einer Serverplattform, die GRE unterstützt
Wenn Sie für dieses Beispiel (Abbildung 38) einen fernen ServerD mit GRE-Unterstützung hinzufügen möchten, müssen Sie ihn in Ihrer Load-Balancer-Konfiguration definieren, wie Sie einen WAN-Server in der Hierarchie Cluster:Port:Server definieren würden:
dscontrol server add Cluster:Port:ServerD router Router1
Linux-Systeme haben native GRE-Fähigkeiten, so dass Load Balancer für Serverimages von Linux für S/390 einen Lastausgleich durchführen kann, wenn mehrere Serverimages eine MAC-Adresse gemeinsam benutzen. Der Eingangspunkt-Load-Balancer kann somit die Last direkt auf Linux-WAN-Server verteilen und ist nicht auf einen Load Balancer am fernen Standort angewiesen. Die Advisor-Funktionen des Eingangspunkt-Load-Balancer können ebenfalls direkt mit jedem der fernen Server zusammenarbeiten.
Erstellen Sie auf dem Eingangspunkt-Load-Balancer wie beschrieben eine Konfiguration für WAN.
Zum Konfigurieren der einzelnen Linux-Back-End-Server müssen Sie als Root die folgenden Befehle absetzen. (Diese Befehle können zum Tool für Systemstart hinzugefügt werden, so dass die Änderungen für alle folgenden Bootvorgänge erhalten bleiben.)
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add Clusteradresse dev gre-nd
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. Benutzen Sie aus diesem Grund für alle Links Ihrer Seiten immer die Adresse des Dispatchers. Berücksichtigen Sie, dass die Art der verwendeten 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 im öffentlichen oder externen Netz, die sich auf die Leistung auswirken, verringert werden.
Auf AIX-Systemen 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.
Zum Einrichten eines privaten Netzes muss jede Maschine mindestens zwei LAN-Karten enthalten, von denen eine mit dem privaten Netz verbunden ist. Die zweite LAN-Karte muss für ein anderes Teilnetz konfiguriert werden, damit die Dispatcher-Maschine die Clientanforderungen über das private Netz an die TCP-Servermaschinen sendet.
Windows-Systeme: Konfigurieren Sie die NFA (nicht für Weiterleitung bestimmte Adresse) mit dem Befehl "executor configure".
Die über den Befehl dscontrol server add hinzugefügten Server müssen mit den Adressen des privaten Netzes hinzugefügt werden. Für das Beispiel in Abbildung 39 müsste der Befehl für den Server "Apple" wie folgt codiert sein:
dscontrol server add Clusteradresse:80:10.0.0.1
Er darf nicht wie folgt aussehen:
dscontrol server add Clusteradresse:80:9.67.131.18
Wenn Sie 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 39. Beispiel für ein privates Netz mit dem Dispatcher
Die Verwendung der Konfiguration für ein privates Netz gilt nur für die Komponente Dispatcher.
Die Verwendung eines Platzhalterclusters für die Zusammenfassung von Serverkonfigurationen gilt nur für die Komponente Dispatcher.
Das Wort "Platzhalter" bezieht sich auf die Fähigkeit des Clusters, mit mehreren IP-Adressen übereinzustimmen. Die Clusteradresse 0.0.0.0 wird verwendet, um einen Platzhaltercluster anzugeben.
Wenn Sie für viele Clusteradressen einen Lastausgleich durchführen müssen und die Port/Server-Konfigurationen für alle Cluster identisch sind, können Sie die Cluster in einer Platzhalterclusterkonfiguration zusammenfassen.
Sie müssen dennoch jede Clusteradresse explizit für einen der Netzwerkadapter Ihrer Dispatcher-Workstation konfigurieren. Sie sollten jedoch keine der Clusteradressen mit dem Befehl "dscontrol cluster add" der Dispatcher-Konfiguration hinzufügen.
Fügen Sie nur den Platzhaltercluster (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 Platzhalterclusterkonfiguration.
Ein Vorteil dieser Methode besteht darin, dass der Datenverkehr an alle Clusteradressen 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 Clusteradressen ein Lastausgleich unter Verwendung dieser Informationen statt.
Sie können den Platzhaltercluster mit tatsächlichen Clustern kombinieren, wenn Sie einige Clusteradressen mit eindeutiger Port/Server-Konfiguration und einige Clusteradressen mit gemeinsamer Konfigurationen haben. Die eindeutigen Konfigurationen müssen jeweils einer tatsächlichen Clusteradresse zugeordnet werden. Alle gemeinsamen Konfigurationen können dem Platzhaltercluster zugeordnet werden.
Die Verwendung eines Platzhalterclusters für den Lastausgleich von Firewalls gilt nur für die Komponente Dispatcher. Die Clusteradresse 0.0.0.0 wird verwendet, um einen Platzhaltercluster anzugeben.
Der Platzhaltercluster kann für den Lastausgleich von Datenverkehr an Adressen verwendet werden, die nicht explizit für einen 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 für einen ihrer Netzwerkadapter konfiguriert wurden. Eine Ausnahme hiervon bilden Adressen, die für bestimmten Datenverkehr als Standardroute konfiguriert sind.
Wurde der Dispatcher als Standardroute konfiguriert, erfolgt der Lastausgleich für den TCP- oder UDP-Datenverkehr, der über die Dispatcher-Maschine transportiert wird, unter Verwendung der Platzhalterclusterkonfiguration.
Diese Methode kann für den Lastausgleich von Firewalls verwendet werden. Da Firewalls Pakete für jede Zieladresse und jeden Zielport verarbeiten können, müssen Sie den Lastausgleich für den Datenverkehr unabhängig von der Zieladresse und dem Zielport durchführen können.
Firewalls werden für die Bearbeitung des Datenverkehrs von nicht gesicherten Clients zu gesicherten Servern und die Antworten von den gesicherten Servern sowie den Datenverkehr von Clients auf der gesicherten Seite zu Servern auf der nicht gesicherten Seite mit den entsprechenden Antworten verwendet.
Sie müssen zwei Dispatcher-Maschinen konfigurieren, eine für die Verteilung des nicht gesicherten Datenverkehrs an die nicht gesicherten Firewall-Adressen und eine für die Verteilung des gesicherten Datenverkehrs an die gesicherten Firewall-Adressen. Da beide Dispatcher den Platzhaltercluster und den Platzhalterport mit verschiedenen Gruppen von Serveradressen verwenden müssen, ist es erforderlich, dass sich die beiden Dispatcher auf zwei separaten Workstations befinden.
Die Verwendung eines Platzhalterclusters mit Caching Proxy für transparente Weiterleitung ist nur für die Komponente Dispatcher. Die Clusteradresse 0.0.0.0 wird verwendet, um einen Platzhaltercluster anzugeben.
Bei Verwendung der Platzhalterclusterfunktion kann der Dispatcher eine transparente Proxy-Funktion 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 Komponente Dispatcher und der TCP-Komponente des Betriebssystems eine Kommunikation stattfinden muss.
Zum Aktivieren dieses Features müssen Sie Caching Proxy für den Empfang von Clientanforderungen am Port 80 starten. Anschließend konfigurieren Sie einen Platzhaltercluster (0.0.0.0). Konfigurieren Sie im Platzhaltercluster den Port 80. Für Port 80 konfigurieren Sie die NFA der Dispatcher-Maschine als einzigen Server. Der gesamte Clientdatenverkehr an Adressen des Ports 80 wird nun an den Caching-Proxy-Server auf der Dispatcher-Workstation gesendet. Anschließend wird die Clientanforderung wie üblich weitergeleitet. Die Antwort wird von Caching Proxy an den Client zurückgesendet. In diesem Modus führt die Komponente Dispatcher keinen Lastausgleich durch.
Der Platzhalterport 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 Platzhalterport sichergestellt werden, dass an einen nicht konfigurierten Port gerichteter Datenverkehr entsprechend bearbeitet wird. Durch Definieren eines Platzhalterports ohne Server stellen Sie sicher, dass alle Anforderungen an einen nicht konfigurierten Port gelöscht und nicht an das Betriebssystem zurückgesendet werden. Ein Platzhalterport wird mit der Portnummer 0 (null) angegeben. Beispiel:
dscontrol port add Cluster:0
Wenn Sie einen Cluster für passives FTP und den Platzhalterport konfigurieren, verwendet das passive FTP für Datenverbindungen standardmäßig den gesamten Bereich der nicht reservierten TCP-Ports. Für einen Client, der über einen Lastausgleichscluster eine Datenverbindung zu einem FTP-Steuerport aufgebaut hat, bedeutet dies, dass Load Balancer nachfolgende Steuerverbindungen zu diesem Cluster und Verbindungen zu Ports mit höheren Nummern als 1023 in diesem Cluster automatisch an denselben Server weiterleitet wie die FTP-Steuerverbindung.
Wenn für den Platzhalterport und den FTP-Port in einem Cluster nicht derselbe Server definiert ist, können Anwendungen an Ports mit hohen Nummern (höher als 1023) scheitern, wenn ein Client bereits eine FTP-Steuerverbindung hat. Das Definieren verschiedener Servergruppen für den FTP-Port und den Platzhalterport in einem Cluster wird daher nicht empfohlen. Falls ein solches Szenario gewünscht wird, muss in der Konfiguration von Load Balancer der Bereich passiver Ports für den FTP-Dämon festgelegt werden.
Diese Funktion ist nur für die Komponente Dispatcher 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 Quellenportnummern. 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.
Load Balancer stellt Benutzer-Exits bereit, 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 ...ibm/edge/lb/servers/samples das folgende Beispielscript bereit:
Zum Ausführen der Dateien müssen Sie sie in das Verzeichnis ...ibm/edge/lb/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 dscontrol port setzen:
dscontrol 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 dscontrol 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 Clientadressen (maximal 8000 Adresspaare), deren Serverzugriff halboffene Verbindungen zur Folge hatten, Einträge im Protokoll (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log).
Back-End-Server können Sie zusätzlich vor DoS-Attacken schützen, indem Sie Platzhaltercluster und -ports konfigurieren. Fügen Sie unter jedem konfigurierten Cluster einen Platzhalterport ohne Server hinzu. Fügen Sie außerdem einen Platzhaltercluster mit einem Platzhalterport und ohne Server hinzu. Dies hat zur Folge, dass alle Pakete, die an einen Platzhaltercluster oder -port gesendet werden, gelöscht werden. Informationen zu Platzhalterclustern und -ports finden Sie in den Abschnitten Platzhaltercluster zum Zusammenfassen von Serverkonfigurationen verwenden und Platzhalterport für die Übertragung von Datenverkehr mit nicht konfiguriertem Port verwenden.
Mit dem Feature für Binärprotokollierung können Serverinformationen in Binärdateien gespeichert werden. Diese Dateien können dann verarbeitet werden, um die Serverinformationen zu analysieren, die über einen bestimmten Zeitraum gesammelt wurden.
Die folgenden Informationen werden für jeden in der Konfiguration definierten Server in dem binären Protokoll gespeichert:
Einige dieser Informationen werden im Rahmen des Managerzyklus vom Executor abgerufen. Der Manager muss daher aktiv sein, damit die Informationen in den binären Protokollen aufgezeichnet werden können.
Verwenden Sie den Befehlssatz dscontrol binlog, 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. Standardmäßig ist der Protokolldienst gestoppt.
Mit der Option "set interval" wird gesteuert, wie oft Informationen in die Protokolle geschrieben werden. Der Manager sendet in jedem Managerintervall 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 Managerintervall und das Protokollierungsintervall gibt es eine gewisse Interaktion. Da dem Protokollserver Informationen nicht schneller zur Verfügung gestellt werden, als dies im Managerintervall (in Sekunden) angegeben ist, wird durch Angabe eines Protokollierungsintervalls, das kleiner als das Managerintervall ist, das Protokollierungsintervall de facto auf denselben Wert wie das Managerintervall gesetzt. Mit dieser Protokollierungstechnik können Sie Serverinformationen detaillierter 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 ...ibm/edge/lb/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:
dslogreport 2001/05/01 8:00 2001/05/01 17:00
Dieser Befehl liefert einen Bericht mit den Serverdaten der Komponente Dispatcher vom 1. Mai 2001 in der Zeit von 8.00 Uhr bis 17.00 Uhr. (Verwenden Sie für CBR cbrlogreport.)
Konfigurationen mit einem Client auf derselben Maschine wie Load Balancer werden nur auf Linux-Systemen unterstützt.
Konfigurationen mit verknüpftem Client funktionieren auf anderen Plattformen möglicherweise nicht ordnungsgemäß, weil Load Balancer die ankommenden Pakete unter den vielen unterstützten Betriebssystemen mit verschiedenen Techniken untersucht. In den meisten Fällen empfängt Load Balancer nur unter Linux Pakete von der lokalen Maschine. Unter anderen Betriebssystemen werden nur die Pakete aus dem Netz empfangen. Aus diesem Grund empfängt Load Balancer keine Anforderungen, die von der lokalen Maschine an die Clusteradresse gesendet werden, und kann diese nicht erfüllen.
Dieses Kapitel enthält die folgenden Abschnitte:
Cisco CSS Controller oder Nortel Alteon Controller kann sich auf derselben Maschine befinden wie ein Server, dessen Anforderungen verteilt werden. Dies wird als das Verknüpfen eines Servers bezeichnet. Es sind keine zusätzlichen Konfigurationsschritte erforderlich.
Die Funktion der hohen Verfügbarkeit ist jetzt für Cisco CSS Controller und Nortel Alteon Controller verfügbar.
Zur Verbesserung der Fehlertoleranz des Controllers stellt die Funktion für hohe Verfügbarkeit Folgendes bereit:
Die vollständige Syntax des Befehls xxxcontrol highavailability können Sie den Abschnitten ccocontrol highavailability -- Hohe Verfügbarkeit steuern und nalcontrol highavailability -- Hohe Verfügbarkeit steuern entnehmen.
Gehen Sie wie folgt vor, um die hohe Verfügbarkeit für den Controller zu konfigurieren:
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 Port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role secondary
Die Parameter "address" und "partneraddress" sind auf der primären und der sekundären Maschine jeweils ausgetauscht.
xxxcontrol highavailability set beatinterval 1000
xxxcontrol highavailability usereach 10.20.20.20
Auf dem lokalen und dem Partnercontroller muss dieselbe Anzahl von Erreichbarkeitszielen konfiguriert werden.
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeover
Dies ist nur für Wartungszwecke erforderlich.
Anmerkungen:
Neben dem Verlust der Konnektivität zwischen aktivem Controller und Bereitschaftscontroller, der durch die Überwachungssignale festgestellt wird, kann jetzt auch die Erreichbarkeit erkannt werden.
Wenn Sie die hohe Verfügbarkeit für Controller konfigurieren, können Sie eine Liste von Hosts angeben, die für jeden der Controller erreichbar sein müssen. Für jedes Teilnetz, das Ihre Controllermaschine benutzt, muss mindestens ein Host angegeben sein. Die Hosts können Router, IP-Server oder andere Arten von Hosts sein.
Die Erreichbarkeit von Hosts wird über Ping-Aufrufe der Advisor-Funktion reach abgefragt. Es findet eine Übernahme statt, wenn keine Überwachungssignalnachrichten durchkommen oder wenn die Erreichbarkeitskriterien eher vom Bereitschaftscontroller als vom primären Controller erfüllt werden. Damit die Entscheidung anhand aller verfügbaren Informationen getroffen wird, tauschen der aktive Controller und der Bereitschaftscontroller regelmäßig Informationen über ihre Erreichbarkeit aus. Die Controller vergleichen dann ihre Erreichbarkeitsdaten mit denen des Partners und entscheiden, welcher Controller der aktive Controller sein soll.
Die beiden Controllermaschinen werden nach ihrer Rolle als primärer und sekundärer Controller konfiguriert. Beim Systemstart tauschen die Controller Informationen aus, bis beide Maschinen synchronisiert sind. Anschließend wechselt der primäre Controller in den aktiven Status und beginnt mit der Berechnung von Wertigkeiten und dem Aktualisieren des Switch. Die sekundäre Maschine wechselt in den Bereitschaftsstatus und überwacht die Verfügbarkeit der primären Maschine.
Stellt die Bereitschaftsmaschine an einem beliebigen Punkt fest, dass die aktive Maschine ausgefallen ist, übernimmt sie die Lastausgleichsfunktionen der (ausgefallenen) aktiven Maschine und wird selbst zur aktiven Maschine. Ist die primäre Maschine wieder betriebsbereit, ermitteln die beiden Maschinen anhand der konfigurierten Wiederherstellungsstrategie, welcher Controller der aktive Controller sein soll.
Es gibt zwei Arten von Wiederherstellungsstrategien:
Sobald der primäre Controller wieder betriebsbereit ist, wechselt er in den aktiven Status, berechnet und aktualisiert Wertigkeiten etc. Die sekundäre Maschine wechselt in den Bereitschaftsstatus, wenn die primäre Maschine wieder aktiv ist.
Der aktive sekundäre Controller bleibt aktiv, wenn der primäre Controller wieder betriebsbereit ist.
Der primäre Controller wechselt in den Bereitschaftsstatus und kann nur manuell in den aktiven Status versetzt werden.
Der Parameter für die Strategie muss für beide Maschinen auf denselben Wert gesetzt werden.
Konfigurationsbeispiele für die hohe Verfügbarkeit von Cisco CSS Controller finden Sie im Abschnitt Beispiele.
Konfigurationsbeispiele für die hohe Verfügbarkeit von Nortel Alteon Controller finden Sie im Abschnitt Beispiele.
Die Controllerfunktion von Load Balancer führt den Lastausgleich ausgehend von den folgenden Einstellungen durch:
Zur Optimierung des Lastausgleichs für Ihr Netz können Sie diese Einstellungen ändern.
Der Controller kann in seine Gewichtungsentscheidung alle oder einige der nachfolgend genannten summierten Metriken einfließen lassen:
Die Standardmetriken sind activeconn und connrate.
Sie können die relative Gewichtung der Metriken ändern. Die Proportionen sind vergleichbar mit Prozentsätzen. Die Summe der relativen Proportionen muss 100 % ergeben. Standardmäßig werden die Metriken "Aktive Verbindungen" und "Neue Verbindungen" in der Gewichtung 50:50 verwendet. In Ihrer Umgebung sollten Sie andere Metrikproportionen ausprobieren, um die Kombination mit der besten Leistung zu finden.
Gehen Sie wie folgt vor, um die Proportionswerte festzulegen:
Die Wertigkeiten werden ausgehend von Reaktionszeit und Verfügbarkeit der Anwendung, vom Feedback der Advisor-Funktionen und vom Feedback eines Systemüberwachungsprogramms wie Metric Server festgelegt. Falls Sie Wertigkeiten manuell festlegen möchten, geben Sie für den Server die Option "fixedweight" an. Eine Beschreibung der Option "fixedweight" finden Sie im Abschnitt Feste Wertigkeiten des Controllers.
Wertigkeiten gelten für alle Server, die einen Service anbieten. Für jeden einzelnen Service werden die Anforderungen entsprechend ihrer relativen Wertigkeit auf die Server verteilt. Hat beispielsweise ein Server die Wertigkeit 10 und der andere Server die Wertigkeit 5, erhält der Server mit der Wertigkeit 10 doppelt so viele Anforderungen wie der Server mit der Wertigkeit 5.
Stellt eine Advisor-Funktion fest, dass ein Server heruntergefahren wurde, wird seine Wertigkeit auf -1 gesetzt. Für Cisco CSS Controller and Nortel Alteon Controller: Der Switch wird informiert, dass der Server nicht verfügbar ist, und hört auf, dem Server Verbindungen zuzuordnen.
Ohne den Controller können Advisor-Funktionen nicht ausgeführt werden und nicht erkennen, ob ein Server inaktiv ist. Wenn Sie die Advisor-Funktionen ausführen möchten, der Controller jedoch nicht die von Ihnen für einen bestimmten Server festgelegte Wertigkeit aktualisieren soll, verwenden Sie für Cisco CSS Controller den Befehl ccocontrol service und für Nortel Alteon Controller den Befehl nalcontrol server mit der Option fixedweight.
Mit dem Befehl fixedweight können Sie die Wertigkeit auf den gewünschten Wert setzen. Der Wert für die Serverwertigkeit bleibt während der Ausführung des Controllers unverändert erhalten, bis Sie einen weiteren Befehl absetzen, bei dem "fixedweight" auf "no" gesetzt ist.
Zur Optimierung der Gesamtleistung können Sie festlegen, wie oft Metriken zusammengestellt werden sollen.
Die Consultant-Ruhezeit gibt an, wie oft der Consultant die Serverwertigkeiten aktualisiert. Eine zu kurze Consultant-Ruhezeit kann sich negativ auf den Durchsatz auswirken, da der Consultant den Switch permanent unterbricht. Eine zu lange Consultant-Ruhezeit kann bedeuten, dass der Lastausgleich des Switch nicht auf genauen, auf dem neuesten Stand befindlichen Informationen basiert.
Eine Consultant-Ruhezeit von 1 Sekunde könnten Sie wie folgt festlegen:
xxxcontrol consultant set Consultant-ID sleeptime Intervall
Zur Optimierung des Lastausgleichs für Ihre Server stehen weitere Methoden zur Verfügung. Im Interesse einer hohen Übertragungsgeschwindigkeit werden die Wertigkeiten der Server nur aktualisiert, wenn sich signifikante Änderungen der Wertigkeit ergeben. Das permanente Aktualisieren der Wertigkeiten bei geringfügigen oder nicht vorhandenen Änderungen des Serverstatus würde zu einem unnötigen Systemaufwand führen. Wenn die prozentuale Änderung der Wertigkeit innerhalb der summierten Wertigkeit für alle Server, die einen Service anbieten, über der Sensitivitätsschwelle liegt, werden die von Load Balancer für die Verteilung der Verbindungen verwendeten Wertigkeiten aktualisiert. Nehmen wir beispielsweise an, die Gesamtwertigkeit ändert sich von 100 % auf 105 %. Die Änderung beträgt also 5 %. Beim standardmäßigen Sensitivitätsschwellenwert von 5 werden die von Load Balancer verwendeten Wertigkeiten nicht aktualisiert, da die prozentuale Änderung nicht über dem Schwellenwert liegt. Ändert sich die Gesamtwertigkeit jedoch von 100 % auf 106 %, werden die Wertigkeiten aktualisiert. Wenn Sie die Consultant-Sensitivitätsschwelle auf einen anderen Wert als den Standardwert setzen möchten, geben Sie den folgenden Befehl ein:
xxxcontrol consultant set Consultant-ID sensitivity geänderterProzentsatz
In den meisten Fällen müssen Sie diesen Wert nicht ändern.
Advisor-Funktionen sind Agenten in Load Balancer. 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-Funktionen können als transportable Clients der Anwendungsserver betrachtet werden.
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 Consultant-Funktion, die ihn im Consultant-Bericht angibt. Der Consultant addiert anschließend die Wertigkeiten für alle Quellen entsprechend ihren Proportionen und sendet diese Werte an den Switch. Der Switch benutzt diese Wertigkeiten dann für den Lastausgleich neuer ankommender Clientverbindungen.
Stellt die Advisor-Funktion fest, dass ein Server aktiv ist und ordnungsgemäß arbeitet, meldet er einen positiven Lastwert ungleich null an den Consultant. Stellt die Advisor-Funktion fest, dass ein Server inaktiv ist, gibt sie den speziellen Lastwert -1 zurück, um dem Switch mitzuteilen, dass der Server heruntergefahren ist. Der Switch leitet daraufhin keine Verbindungen an diesen Server weiter, solange dieser inaktiv ist.
Die Advisor-Ruhezeit legt fest, wie oft eine Advisor-Funktion den Status der Server an dem von ihr überwachten Port abfragt und die Ergebnisse dann an den Consultant übergibt. Eine zu kurze Advisor-Ruhezeit kann sich negativ auf den Durchsatz auswirken, da die Advisor-Funktion die Server permanent unterbricht. Eine zu lange Advisor-Ruhezeit kann bedeuten, dass die Gewichtungsentscheidungen des Consultant nicht auf genauen, auf dem neuesten Stand befindlichen Informationen basieren.
Wenn Sie das Intervall der HTTP-Advisor-Funktion beispielsweise auf 3 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:
xxxcontrol metriccollector set Consultant-ID:HTTP sleeptime 3
Sie können festlegen, in welcher Zeit eine Advisor-Funktion feststellen soll, dass ein bestimmter Port auf einem Server oder für einen Service ausgefallen ist. Die Zeitlimits für ausgefallene Server connecttimeout und receivetimeout bestimmen, wie lange 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 die Ruhezeit für Advisor-Funktion und Consultant auf den kleinsten Wert (eine Sekunde) setzen.
Wenn Sie timeoutconnect für die HTTP-Advisor-Funktion beispielsweise auf 9 Sekunden setzen möchten, geben Sie den folgenden Befehl ein:
xxxcontrol metriccollector set Consultant-ID:HTTP timeoutconnect 9
Der Standardwert für das Verbindungs- und Empfangszeitlimit liegt beim Dreifachen des Wertes, der für die Ruhezeit der Advisor-Funktion angegeben wurde.
Advisor-Funktionen können wiederholt versuchen, eine Verbindung herzustellen, bevor sie einen Server als inaktiv markieren. Die Advisor-Funktion markiert einen Server erst als inaktiv, wenn die Abfrage nach der festgelegten Anzahl Wiederholungen und einem weiteren Versuch nicht beantwortet wird. Ist keine Anzahl Wiederholungen festgelegt, wird standardmäßig von null Wiederholungen ausgegangen.
Für den Cisco CSS Controller können Sie den retry-Wert mit dem Befehl ccocontrol ownercontent set setzen. Weitere Informationen finden Sie im Abschnitt ccocontrol ownercontent -- Eignernamen und Inhaltsregel steuern.
Für den Nortel Alteon Controller können Sie den retry-Wert mit dem Befehl nalcontrol service set setzen. Weitere Informationen finden Sie im Abschnitt nalcontrol service -- Service konfigurieren.
Die angepasste (anpassbare) Advisor-Funktion ist ein kurzer Java-Code, den Sie als Klassendatei bereitstellen, die vom Basiscode aufgerufen wird. Der Basiscode stellt alle Verwaltungsservices bereit. Dazu gehören unter anderem:
Er übergibt auch die Ergebnisse an den Consultant. Der Basiscode führt regelmäßig einen 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 sie 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 Consultant.
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 Consultant. Die angepasste Advisor-Funktion muss nur null (bei Erfolg) oder -1 (bei einem Fehler) zurückgeben. Zur Angabe des normalen Modus wird das Flag "replace" der Methode "constructor" auf "false" 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 Consultant. Um bestmögliche Ergebnisse zu erzielen, sollten Sie den Lastwert zwischen 10 und 1000 normalisieren, wobei 10 einen schnellen Server und 1000 einen langsamen Server angibt. Zur Angabe des Ersetzungsmodus muss das Flag "replace" der Methode "constructor" auf "true" gesetzt werden.
Auf diese Weise können Sie eigene Advisor-Funktionen schreiben, die die benötigten präzisen Informationen über Server zur Verfügung stellen. Für die Controller wird ein Beispiel für eine angepasste Advisor-Funktion, ADV_ctlrsample.java, geliefert. Nach der Installation von Load Balancer finden Sie den Beispielcode im Installationsverzeichnis ...ibm/edge/lb/servers/samples/CustomAdvisors.
Die Standardinstallationsverzeichnisse sind:
Der Dateiname für Ihre angepasste Advisor-Funktion muss das Format "ADV_eigenerAdvisor.java" haben. Er muss mit dem Präfix ADV_ in Großbuchstaben beginnen. Alle nachfolgenden Zeichen müssen Kleinbuchstaben sein.
Aufgrund von Java-Konventionen muss der Name der in der Datei definierten Klasse mit dem Namen der Datei übereinstimmen. Wenn Sie den Beispielcode kopieren, stellen Sie sicher, dass alle Exemplare von ADV_ctrlsample in der Datei in den neuen Klassennamen geändert werden.
Angepasste Advisor-Funktionen werden in der Sprache Java geschrieben. Verwenden Sie den Java-Compiler, der zusammen mit Load Balancer installiert wird. Während der Kompilierung wird auf die folgenden Dateien Bezug genommen:
Der Klassenpfad muss während der Kompilierung auf die Datei der angepassten Advisor-Funktion und die Datei mit den Basisklassen zeigen.
Ein Kompilierungsbefehl für die Windows-Plattform könnte wie folgt aussehen:
Installationsverzeichnis/java/bin/javac -classpath Installationsverzeichnis\lb\servers\lib\ibmlb.jar ADV_pam.java
Für diese Angaben gilt Folgendes:
Die Ausgabe der Kompilierung ist eine Klassendatei, zum Beispiel:
ADV_pam.class
Kopieren Sie vor dem Starten der Advisor-Funktion die Klassendatei in das Installationsverzeichnis ...ibm/edge/lb/servers/lib/CustomAdvisors.
Für AIX-, HP-UX-, Linux- und Solaris-Systeme ist die Syntax ähnlich.
Bevor Sie die angepasste Advisor-Funktion ausführen, müssen Sie die Klassendatei in das richtige Unterverzeichnis des Installationsverzeichnisses kopieren:
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_pam.class
Starten Sie den Consultant und setzen Sie dann zum Starten der angepassten Advisor-Funktion den folgenden Befehl ab:
Für diese Angaben 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 Consultant, die für den Wertigkeitsalgorithmus des Consultant 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 einem Flag 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:
Die Controller suchen zunächst in der bereitgestellten Liste nach nativen Advisor-Funktionen. Können Sie dort eine gegebene Advisor-Funktion nicht finden, durchsuchen Sie die Liste der angepassten Advisor-Funktionen.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Programme\IBM\edge\lb\servers\lib\CustomAdvisors
Die Programmliste für eine Beispiel-Advisor-Funktion für den Controller finden Sie im Abschnitt Beispiel-Advisor-Funktion. Nach der Installation befindet sich diese Beispiel-Advisor-Funktion im Verzeichnis ...ibm/edge/lb/servers/samples/CustomAdvisors.
Metric Server stellt Load Balancer Informationen zur Serverauslastung bereit. Diese Informationen werden in Form systemspezifischer Metriken für den Serverzustand bereitgestellt. Der Load-Balancer-Consultant richtet Anfragen an den Metric-Server-Agenten, der sich auf jedem der Server befindet, und legt anhand der Metriken, die er von den Agenten erhalten hat, Wertigkeiten für den Lastausgleich fest. Die Ergebnisse werden für Cisco CSS Controller auch in den Servicebericht und für Nortel Alteon Controller in den Serverbericht gestellt.
Der Metric-Server-Agent muss auf allen Servern installiert und ausgeführt werden, die am Lastausgleich teilnehmen.
Nachfolgend sind die Schritte aufgeführt, mit denen Sie Metric Server für die Controller konfigurieren.
Fügen Sie für Nortel Alteon Controller einen Switch-Consultant und dann einen Service hinzu.
Metrikname steht hier für den Namen des Metric-Server-Scripts.
Das Systemmetrikscript befindet sich auf dem Back-End-Server und wird für jeden Server, der unter den aufgeführten Eignerangaben oder dem angegebenen Service in der Konfiguration enthalten ist, ausgeführt. Die beiden Scripts cpuload und memload stehen für Sie bereit. Sie können aber auch angepasste Systemmetrikscripts erstellen. Das Script enthält einen Befehl, der einen numerischen Wert zurückgeben muss. Dieser numerische Wert stellt eine Lastmessung und keinen Verfügbarkeitswert dar.
Einschränkung: Wenn der Name Ihres Systemmetrikscripts auf Windows-Systemen eine andere Erweiterung als .exe hat, müssen Sie den vollständigen Namen der Datei (z. B. mysystemscript.bat) angeben. Dies ist eine Java-Codeeinschränkung.
Optional können Sie Ihre eigenen angepassten Systemmetrikscriptdateien 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 ...ibm/edge/lb/ms/script befinden. Angepasste Scripts müssen einen numerischen Lastwert zurückgeben.
Wenn Metric Server für eine vom lokalen Host abweichende Adresse ausgeführt werden soll, editieren Sie die Datei metricserver auf der am Lastausgleich beteiligten Servermaschine. Fügen Sie in der Datei metricserver nach dem Eintrag java Folgendes ein:
-Djava.rmi.server.hostname=andere_Adresse
Fügen Sie außerdem vor den Anweisungen if Folgendes zur Datei metricserver hinzu: hostname andere_Adresse.
Auf Windows-Systemen: Geben Sie in Microsoft Stack einen Aliasnamen für andere_Adresse an. Informationen zum Angeben eines Aliasnamens für eine Adresse in Microsoft Stack finden Sie auf Seite ***.
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, können die Controller die Kapazitätsinformationen von WLM akzeptieren und die Informationen für den Lastausgleich verwenden. Mit der Advisor-Funktion WLM öffnen die Controller regelmäßig Verbindungen über den WLM-Port der einzelnen Server in der Consultant-Hosttabelle und akzeptiert die zurückgegebenen ganzzahligen Kapazitätswerte. Da diese ganzen Zahlen die noch verfügbare Kapazität darstellen und die Controller Werte erwarten, die die Belastung auf jeder Maschine angeben, werden die ganzzahligen Kapazitätswerte vom Advisor in Lastwerte umgekehrt und normalisiert. (Ein hoher ganzzahliger Kapazitätswert und ein niedriger Lastwert geben beispielsweise beide einen akzeptablen Zustand eines Servers an). Es gibt mehrere wichtige Unterschiede zwischen dem WLM-Advisor und anderen Advisor-Funktionen des Controllers:
Mit dem Feature für Binärprotokollierung können Serverinformationen in Binärdateien gespeichert werden. Diese Dateien können dann verarbeitet werden, um die Serverinformationen zu analysieren, die über einen bestimmten Zeitraum gesammelt wurden.
Die folgenden Informationen werden für jeden in der Konfiguration definierten Server in dem binären Protokoll gespeichert:
Zum Protokollieren von Informationen in den binären Protokollen muss der Consultant aktiv sein.
Verwenden Sie zum Konfigurieren der binären Protokollierung den Befehlssatz xxxcontrol consultant binarylog.
Mit der Option "start" wird die Protokollierung von Serverinformationen in binären Protokollen im Protokollverzeichnis gestartet. Ein Protokoll wird zu Beginn jeder Stunde mit dem Datum und der Uhrzeit als Name der Datei erstellt.
Mit der Option "stop" wird die Protokollierung von Serverinformationen in binären Protokollen gestoppt. Standardmäßig ist der Protokolldienst gestoppt.
Mit der Option "set interval" wird gesteuert, wie oft Informationen in die Protokolle geschrieben werden. Der Consultant sendet in jedem Consultant-Intervall Serverdaten an den Protokollserver. Die Daten werden nur 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 Consultant-Intervall und das Protokollierungsintervall gibt es eine gewisse Interaktion. Da dem Protokollserver Informationen nicht schneller zur Verfügung gestellt werden, als dies im Consultant-Intervall (in Sekunden) angegeben ist, wird durch Angabe eines Protokollierungsintervalls, das kleiner als das Consultant-Intervall ist, das Protokollierungsintervall de facto auf denselben Wert wie das Consultant-Intervall gesetzt.
Mit dieser Protokollierungstechnik können Sie Serverinformationen detaillierter erfassen. Sie können alle vom Consultant festgestellten Änderungen der Serverinformationen für die Berechnung von Serverwertigkeiten erfassen. Dieser Informationsumfang ist jedoch wahrscheinlich nicht erforderlich, um die Serverauslastung und Trends zu analysieren. Werden Serverinformationen alle 60 Sekunden protokolliert, erhalten Sie Momentaufnahmen von Serverinformationen in Abhängigkeit vom zeitlichen Verlauf. Wird das Protokollierungsintervall auf einen sehr niedrigen Wert gesetzt, kann dies zu großen Datenmengen führen.
Mit der Option "set retention" wird gesteuert, wie lange Protokolldateien aufbewahrt werden. Protokolldateien, die älter als die angegebene Verweildauer (Stunden) sind, werden von dem Protokollserver gelöscht. Die geschieht nur, wenn der Protokollserver vom Consultant aufgerufen wird. Wenn Sie den Consultant stoppen, werden alte Protokolldateien demzufolge nicht gelöscht.
Im Verzeichnis ...ibm/edge/lb/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 für die Verwendung des bereitgestellten Scripts und Programms:
xxxlogreport 2002/05/01 8:00 2002/05/01 17:00
Dieser Befehl liefert einen Bericht mit den Serverdaten des Controllers vom 1. Mai 2002 in der Zeit von 8.00 bis 17.00 Uhr.
Load Balancer stellt 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 ...ibm/edge/lb/servers/samples. Zum Ausführen müssen Sie die Dateien in das Verzeichnis ...ibm/edge/lb/servers/bin kopieren und dann entsprechend den Anweisungen im Script umbenennen.
Die folgenden Beispielscripts werden bereitgestellt, bei denen die Angabe xxx durch cco für Cisco CSS Controller und durch nal für Nortel Alteon Controller ersetzt wird:
Dieser Teil enthält Informationen zur Verwaltung von Load Balancer und zur Fehlerbehebung. Zu diesem Teil gehören die folgenden Kapitel:
Das vorliegende Kapitel erläutert die Verwendung und Verwaltung von Load Balancer und ist in folgende Abschnitte untergliedert:
Load Balancer bietet zwei Möglichkeiten an, die Konfigurationsprogramme auf einer anderen Maschine als der Maschine mit Load Balancer auszuführen. Für die Kommunikation zwischen den Konfigurationsprogrammen (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) und dem Server (dsserver, cbrserver usw.) bestehen die beiden folgenden Möglichkeiten:
Der Vorteil der Fernverwaltung mit RMI besteht darin, dass sie schneller als die webgestützte Verwaltung ist.
Die webgestützte Verwaltung hat den Vorteil, dass sie eine sichere Fernverwaltung mit Authentifizierung ist und auch bei Vorhandensein einer Firewall die Kommunikation mit der Load-Balancer-Maschine gewährleistet ist. Diese Verwaltungsmethode erfordert außerdem nicht die Installation und Verwendung von Authentifizierungsschlüsseln (lbkeys) auf der fernen Clientmaschine, die mit der Load-Balancer-Maschine kommuniziert.
Bei Verwendung von RMI lautet der Befehl zum Herstellen einer Verbindung zu einer Load-Balancer-Maschine für die Fernverwaltung dscontrol host:ferner_Host.
Stammt der RMI-Aufruf von einer anderen Maschine als der lokalen Maschine, muss eine Authentifizierung mit öffentlichem/privatem Schlüssel stattfinden, bevor der Konfigurationsbefehl akzeptiert wird.
Die Kommunikation zwischen den Steuerprogrammen, die auf derselben Maschine wie die Komponentenserver ausgeführt werden, wird nicht authentifiziert.
Verwenden Sie den folgenden Befehl, um öffentliche und private Schlüssel für die ferne Authentifizierung zu generieren:
Dieser Befehl muss auf derselben Maschine wie Load Balancer ausgeführt werden.
Bei Verwendung der Option create wird im Schlüsselverzeichnis des Servers (...ibm/edge/lb/servers/key/) ein privater Schlüssel erstellt. Im Verwaltungsverzeichnis für Schlüssel (...ibm/edge/lb/admin/keys/) der einzelnen Komponenten von Load Balancer werden öffentliche Schlüssel erstellt. Der Dateiname für den öffentlichen Schlüssel ist Komponente-Serveradresse-RMI-Port. Diese öffentlichen Schlüssel müssen anschließend zu den fernen Clients transportiert und in das Verwaltungsverzeichnis für Schlüssel gestellt werden.
Auf einer Load-Balancer-Maschine mit dem Hostnamen bzw. der Adresse 10.0.0.25, die für jede Komponente den Standard-RMI-Port verwendet, generiert der Befehl lbkeys create die folgenden Dateien:
Die Verwaltungsdateigruppe wurde auf einer anderen Maschine installiert. Die Dateien der öffentlichen Schlüssel müssen auf der fernen Clientmaschine in das Verzeichnis ...ibm/edge/lb/admin/keys gestellt werden.
Jetzt ist der ferne Client berechtigt, Load Balancer auf der Maschine 10.0.0.25 zu konfigurieren.
Dieselben Schlüssel müssen Sie auf allen fernen Clients verwenden, die berechtigt sein sollen, Load Balancer auf der Maschine 10.0.0.25 zu konfigurieren.
Würde der Befehl lbkeys create erneut ausgeführt, hätte dies die Generierung einer neuen Gruppe von öffentlichen/privaten Schlüsseln zur Folge. Dies würde bedeuten, dass alle fernen Clients, die unter Verwendung der vorherigen Schlüssel die Herstellung einer Verbindung versuchen, nicht berechtigt wären. Der neue Schlüssel müsste in das korrekte Verzeichnis auf den Clients gestellt werden, die erneut berechtigt werden sollen.
Mit dem Befehl lbkeys delete werden die privaten und öffentlichen Schlüssel von der Servermaschine gelöscht. Werden diese Schlüssel gelöscht, sind keine fernen Clients mehr berechtigt, eine Verbindung zu den Servern herzustellen.
Für lbkeys create und lbkeys delete gibt es die Option force. Die Option "force" unterdrückt die Eingabeaufforderungen, die von Ihnen eine Bestätigung für das Überschreiben oder Löschen der vorhandenen Schlüssel anfordern.
Wenn Sie eine RMI-Verbindung hergestellt haben, können Sie von einer Eingabeaufforderung aus über die Befehle "dscontrol", "cbrcontrol", "sscontrol", "ccocontrol", "nalcontrol", "dswizard", "cbrwizard" und "sswizard" mit den Konfigurationsprogrammen kommunizieren. Sie können Load Balancer auch auf der GUI konfigurieren. Geben Sie dazu an einer lbadmin-Eingabeaufforderung ein.
Für die webgestützte Verwaltung ist auf der Clientmaschine, die die Fernverwaltung durchführt, Folgendes erforderlich:
Auf der Hostmaschine, auf die Sie zugreifen, um die webgestützte Fernverwaltung durchzuführen, ist Folgendes erforderlich:
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\PROGRA~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\PROGRA~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\PROGRA~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\PROGRA~1\IBM\edge\lb\admin\* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\Sprache\*Sprache steht hier für das Sprachenunterverzeichnis (z. B. en_US).
Für Linux- und UNIX-Systeme --
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/lang/* /opt/ibm/edge/lb/documentation/Sprache/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Wenn Sie die webgestützte Verwaltung ausführen möchten, müssen Sie sie auf der Hostmaschine mit Load Balancer starten. Setzen Sie dazu an der Eingabeaufforderung der Hostmaschine den Befehl lbwebaccess ab.
Sie benötigen die Benutzer-ID und das Kennwort für die Hostmaschine, auf die Sie fern zugreifen. Diese Angaben stimmen mit der Benutzer-ID und dem Kennwort für die Verwaltung von Caching Proxy überein.
Greifen Sie im Webbrowser auf den folgenden URL des fernen Standortes zu, um die webgestützte Verwaltung von Load Balancer aufzurufen:
http://Hostname/lb-admin/lbadmin.html
Hostname ist der Name der Maschine, auf die Sie zugreifen, um mit Load Balancer zu kommunizieren.
Wenn die Webseite geladen ist, erscheint im Browserfenster die GUI von Load Balancer, so dass Sie die webgestützte Fernverwaltung durchführen können.
Von der Load-Balancer-GUI aus können Sie auch Steuerbefehle für die Konfiguration absetzen. Gehen Sie dazu wie folgt vor:
Konfiguration fern aktualisieren
Wenn bei der fernen webgestützten Verwaltung mehrere Administratoren die Load-Balancer-Konfiguration von verschiedenen Standorten aus aktualisieren, müssen Sie die Konfiguration aktualisieren, um (z. B.) den von einem anderen Administrator hinzugefügten (oder gelöschten) Cluster, Port oder Server zu sehen. Die GUI für die webgestützte Fernverwaltung bietet die Funktionen Konfiguration aktualisieren und Alle Konfigurationen aktualisieren an.
Gehen Sie zum Aktualisieren der Konfiguration auf der webgestützten GUI wie folgt vor:
Load Balancer sendet Einträge an ein Serverprotokoll, ein Managerprotokoll, an das Protokoll eines Metriküberwachungsprogramms (protokollbezogene Kommunikation mit Metric-Server-Agenten) und an das Protokoll 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. Load Balancer protokolliert außerdem Header und Datensätze von Ereignissen, die nur einmal eintreten. (Beim Starten einer Advisor-Funktion wird beispielsweise eine Nachricht in das Managerprotokoll geschrieben.) Bei Stufe 1 werden weitere Informationen aufgenommen. Bis Stufe 5 nimmt die Ausführlichkeit kontinuierlich zu. Bei Stufe 5 werden alle generierten Nachrichten aufgenommen, damit sie im Falle eines Fehlers für das Debugging verwendet werden können. Die Standardeinstellung für das Managerprotokoll, das Protokoll der Advisor-Funktionen, das Serverprotokoll sowie das Protokoll der Subagenten ist 1.
Zudem können Sie die maximale Größe eines Protokolls festlegen. Wenn Sie eine maximale Größe für die Protokolldatei festlegen, findet ein Dateiumlauf 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 Load Balancer generierten Protokolle werden standardmäßig im Unterverzeichnis "logs" des Installationsverzeichnisses von Load Balancer gespeichert. Wenn Sie diesen Pfad ändern möchten, setzen Sie die Variable lb_logdir im dsserver-Script entsprechend.
AIX-, HP-UX-, Linux- und Solaris-Systeme: Sie finden das dsserver-Script im Verzeichnis "/usr/bin". In diesem Script ist die Variable LB-Protokollverzeichnis auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
LB_LOGDIR=/Pfad/zu/eigenen/Protokollen/
Windows-Systeme: Sie finden die dsserver-Datei im Windows-Systemverzeichnis (C:\WINNT\SYSTEM32 für Windows 2003). In der dsserver-Datei ist die Variable LB-Protokollverzeichnis auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
set LB_LOGDIR=c:\Pfad\zu\eigenen\Protokollen\
Für alle Betriebssysteme ist sicherzustellen, dass sich rechts und links vom Gleichheitszeichen keine Leerzeichen befinden und dass der Pfad mit einem Schrägstrich endet ("/" bzw. "\").
Für die binäre Protokollierung von Load Balancer wird dasselbe Verzeichnis (log) wie für die übrigen Protokolldateien verwendet. Weitere Informationen finden Sie im Abschnitt Binäre Protokolle für die Analyse von Serverstatistiken verwenden.
Sie können die Protokollstufe festlegen, um den Umfang der Nachrichten zu definieren, die in das Protokoll geschrieben werden. Bei Stufe 0 werden Fehler protokolliert. Load Balancer protokolliert außerdem Header und Datensätze von Ereignissen, die nur einmal eintreten. (Beim Starten einer Advisor-Funktion wird beispielsweise eine Nachricht in das Consultant-Protokoll geschrieben.) Bei Stufe 1 werden weitere Informationen aufgenommen. Bis Stufe 5 nimmt die Ausführlichkeit kontinuierlich zu. Bei Stufe 5 werden alle generierten Nachrichten aufgenommen, damit sie im Falle eines Fehlers für das Debugging verwendet werden können. Der Standardwert für die Protokolle ist 1.
Zudem können Sie die maximale Größe eines Protokolls festlegen. Wenn Sie eine maximale Größe für die Protokolldatei festlegen, findet ein Dateiumlauf 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.
Cisco CSS Controller und Nortel Alteon Controller gibt es die folgenden Protokolle:
Das folgende Beispiel zeigt, wie Sie für das Protokoll der Metriküberwachung, in dem die Kommunikation mit den Metric-Server-Agenten protokolliert wird, die Protokollstufe und die maximale Größe konfigurieren können:
xxxcontrol metriccollector set Consultant-ID:Service-ID:Metrikname loglevel x Protokollgröße y
Die von den Controllern generierten Protokolle werden standardmäßig im Unterverzeichnis "logs" des Installationsverzeichnisses der Controller gespeichert. Wenn Sie diesen Pfad ändern möchten, setzen Sie die Variable xxx_logdir im xxxserver-Script entsprechend.
AIX-, HP-UX-, Linux- und Solaris-Systeme: Sie finden das xxxserver-Script im Verzeichnis "/usr/bin". In diesem Script ist die Variable xxx_logdir auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
xxx_LOGDIR=/Pfad/zu/eigenen/Protokollen/
Windows-Systeme: Sie finden die xxxserver-Datei im Windows-Systemverzeichnis (in der Regel C:\WINNT\SYSTEM32). In der xxxserver-Datei ist die Variable xxx_logdir auf das Standardverzeichnis gesetzt. Sie können diese Variable ändern, um Ihr Protokollverzeichnis anzugeben. Beispiel:
set xxx_LOGDIR=c:\Pfad\zu\eigenen\Protokollen\
Für alle Betriebssysteme ist sicherzustellen, dass sich rechts und links vom Gleichheitszeichen keine Leerzeichen befinden und dass der Pfad mit einem Schrägstrich endet ("/" bzw. "\").
Für die binäre Protokollierung von Load Balancer wird dasselbe Verzeichnis (log) wie für die übrigen Protokolldateien verwendet. Weitere Informationen finden Sie im Abschnitt Binäre Protokolle für die Analyse von Serverstatistiken verwenden.
Die folgenden Abschnitte erläutern die Verwendung und Verwaltung der Komponente Dispatcher.
Load Balancer betrachtet Verbindungen als veraltet, wenn sie die durch das Inaktivitätszeitlimit angegebene Zeit (Sekunden) lang inaktiv waren. Wird das Inaktivitätszeitlimit überschritten, entfernt Load Balancer den Eintrag für diese Verbindung aus seinen Tabellen und löscht den nachfolgenden Datenverkehr für diese Verbindung.
Auf Portebene können Sie das Inaktivitätszeitlimit beispielsweise mit dem Befehl dscontrol port set staletimeout angeben.
Das Inaktivitätszeitlimit kann auf Executor-, Cluster- und Portebene gesetzt werden. Auf Executor- und Clusterebene liegt der Standardwert bei 300 Sekunden. Es wird bis hinunter zum Port gefiltert. Auf Portebene ist der Standardwert vom jeweiligen Port abhängig. Einige herkömmliche Ports haben unterschiedliche Inaktivitätszeitlimits. Der Telnet-Port 23 hat beispielsweise ein Standardlimit von 259.200 Sekunden.
Dienste können auch eigene Inaktivitätszeitlimits haben. Für LDAP (Lightweight Directory Access Protocol) gibt es z. B. den Konfigurationsparameter "idletimeout". Bei Überschreitung der von "idletimeout" angegebenen Zeit in Sekunden wird die Beendigung einer inaktiven Clientverbindung erzwungen. Das Inaktivitätszeitlimit (idletimeout) kann auch auf 0 gesetzt werden, so dass Verbindungen nicht zwangsweise beendet werden können.
Wenn das Inaktivitätszeitlimit von Load Balancer kleiner als das des Dienstes ist, können Konnektivitätsprobleme auftreten. Im Falle von LDAP liegt das Inaktivitätslimit von Load Balancer (staletimeout) standardmäßig bei 300 Sekunden. Ist die Verbindung 300 Sekunden inaktiv, entfernt Load Balancer den Eintrag für die Verbindung aus seinen Tabellen. Wenn das Inaktivitätszeitlimit (idletimeout) über 300 Sekunden liegt (oder auf 0 gesetzt ist), könnte der Client davon ausgehen, dass er weiterhin mit dem Server verbunden ist. Wenn der Client Pakete sendet, werden diese von Load Balancer gelöscht. Das hat zur Folge, dass LDAP blockiert, wenn eine Anfrage an den Server gesendet wird. Sie können dieses Problem vermeiden, indem Sie das Inaktivitätszeitlimit von LDAP (idletimeout) auf einen Wert ungleich null setzen, der genauso groß wie das Inaktivitätszeitlimit von Load Balancer (staletimeout) oder kleiner als dieses ist.
Ein Client sendet ein FIN-Paket, nachdem er alle Pakete gesendet hat, um dem Server mitzuteilen, dass die Transaktion beendet ist. Wenn der Dispatcher das FIN-Paket erhält, kennzeichnet er die Transaktion nicht mehr als AKTIV, sondern als BEENDET. Wenn eine Transaktion als BEENDET gekennzeichnet ist, kann der für die Verbindung reservierte Speicher bereinigt werden.
Sie können den Durchsatz bei der Reservierung und Wiederverwendung von Verbindungssätzen verbessern, indem Sie mit dem Befehl executor set fintimeout steuern, wie lange der Dispatcher Verbindungen im Status BEENDET in den Dispatcher-Tabellen als aktiv und empfangsbereit speichern soll. Sobald eine Verbindung im Status BEENDET den mit fintimeout festgelegten Zeitraum überschreitet, wird sie aus den Dispatcher-Tabellen entfernt und kann wiederverwendet werden. Das Zeitlimit für die Beendigung inaktiver Verbindungen können Sie mit dem Befehl dscontrol executor set fincount ändern.
Mit dem Befehl dscontrol executor set staletimeout können Sie steuern, wie lange der Dispatcher Verbindungen im Status HERGESTELLT in den Dispatcher-Tabellen als aktiv und empfangsbereit speichern soll, wenn kein aktiver Datenverkehr festgestellt werden kann. Weitere Informationen finden Sie im Abschnitt Inaktivitätszeitlimit verwenden.
Ausgehend von den Informationen des Executors können mehrere Diagramme angezeigt und an den Manager übergeben werden. (Die Menüoption "Überwachen" der GUI erfordert, dass die Managerfunktion aktiviert ist):
Ein Netzverwaltungssystem ist ein Programm, das ständig ausgeführt und verwendet wird, um ein Netz zu überwachen, den Status eines Netzes wiederzugeben und ein Netz zu steuern. Simple Network Management Protocol (SNMP), ein häufig verwendetes Protokoll für die Kommunikation mit Einheiten in einem Netz, ist der aktuelle Netzverwaltungsstandard. Die Netzeinheiten verfügen normalerweise über einen SNMP-Agenten und einen oder mehrere Subagenten. Der SNMP-Agent kommuniziert mit der Netzverwaltungsstation oder antwortet auf SNMP-Befehlszeilenanforderungen. Der SNMP- Subagent ruft Daten ab und aktualisiert die Daten und übergibt diese Daten an den SNMP-Agenten, der sie an den Requester weiterleitet.
Der Dispatcher stellt eine SNMP Management Information Base (ibmNetDispatcherMIB) und einen SNMP-Subagenten zur Verfügung. Damit wird Ihnen die Verwendung jedes Netzverwaltungssystems ermöglicht, wie beispielsweise Tivoli NetView, Tivoli Distributed Monitoring oder HP OpenView, um den Zustand, die Leistung und die Aktivität des s zu überwachen. Die MIB-Daten beschreiben den Dispatcher, der verwaltet wird, und geben den aktuellen Status des Dispatchers wieder. Die MIB wird im Unterverzeichnis ..lb/admin/MIB installiert.
Das Netzverwaltungssystem verwendet SNMP-Befehle GET, um MIB-Werte auf anderen Maschinen zu überprüfen. Es kann dann den Benutzer benachrichtigen, wenn angegebene Schwellenwerte überschritten werden. Sie können anschließend die Leistung des Dispatchers beeinflussen, indem Sie Konfigurationsdaten für den Dispatcher so ändern, dass Dispatcher-Probleme im voraus bestimmt oder berichtigt werden, bevor sie den Ausfall des Dispatchers oder Webservers zur Folge haben.
Das System stellt normalerweise einen SNMP-Agenten für jede Netzverwaltungsstation zur Verfügung. Der Benutzer sendet einen Befehl GET an den SNMP-Agenten. Dieser SNMP-Agent sendet dann einen Befehl GET, um die angegebenen MIB-Variablenwerte von einem Subagenten abzurufen, der für diese MIB-Variablen zuständig ist.
Der Dispatcher stellt einen Subagenten zur Verfügung, der MIB-Daten aktualisiert und abruft. Der Subagent antwortet mit den entsprechenden MIB-Daten, wenn der SNMP-Agent einen Befehl GET sendet. Der SNMP-Agent überträgt die Daten an die Netzverwaltungsstation. Die Netzverwaltungsstation kann Sie benachrichtigen, wenn angegebene Schwellenwerte überschritten werden.
Die Dispatcher-SNMP-Unterstützung beinhaltet einen SNMP-Subagenten, der DPI-Funktionalität verwendet (DPI = Distributed Program Interface). DPI ist eine Schnittstelle zwischen einem SNMP-Agenten und seinen Subagenten. Das Betriebssystem Windows verwendet den Windows-Erweiterungsagenten als Schnittstelle zwischen einem SNMP-Agenten und seinen Subagenten.
Abbildung 40. SNMP-Befehle für Linux- und UNIX-Systeme
AIX-Systeme stellen einen SNMP-Agenten bereit, der das SNMP-Multiplexer-Protokoll (SMUX) verwendet und die zusätzliche ausführbare DPID2-Datei anbietet, die als Umsetzer zwischen DPI und SMUX fungiert.
Für HP-UX-Systeme müssen Sie einen SMUX-fähigen SNMP-Agenten erwerben, da HP-UX keinen solchen bereitstellt. Load Balancer stellt DPID2 für HP-UX-Systeme bereit.
Linux-Systeme stellen einen SNMP-Agenten bereit, der SMUX verwendet. Im Lieferumfang der meisten Linux-Versionen (z. B. Red Hat) ist ein UCD-SNMP-Paket enthalten. UCD SNMP enthält ab Version 4.1 SMUX-fähige Agenten. Load Balancer stellt DPID2 für Linux-Systeme bereit.
Für Solaris-Systeme müssen Sie einen SMUX-fähigen SNMP-Agenten erwerben, da dieses Betriebssystem keinen solchen bereitstellt. Load Balancer stellt DPID2 für Solaris-Systeme im Verzeichnis "/opt/ibm/edge/lb/servers/samples/SNMP" bereit.
Den DPI-Agenten müssen Sie Root ausführen. Bevor Sie den DPID2-Dämon ausführen, aktualisieren Sie die Dateien /etc/snmpd.peers und /etc/snmpd.conf wie folgt:
Für AIX- und Solaris-Systeme:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
Für Linux-Systeme:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
In der Datei "snmpd.conf" müssen Sie außerdem alle Zeilen auf Kommentar setzen, die mit den folgenden Wörter beginnen: com2sec, group, view oder access.
Führen Sie zum Installieren der SNMP-Unterstützung von HP-UX die folgenden Schritte aus:
Um das Load-Balancer-SNMP auf Systemen mit SuSE Linux verwenden zu können, müssen Sie die folgenden Schritte ausführen:
Aktualisieren Sie wie folgt snmpd (sofern der Dämon bereits aktiv ist), damit die Datei "snmpd.conf" neu gelesen wird:
refresh -s snmpd
Starten Sie den DPID-SMUX-Peer:
dpid2
Die Dämonen müssen in der folgenden Reihenfolge gestartet werden:
Führen Sie zum Installieren der Solaris-SNMP-Unterstützung die folgenden Schritte aus:
/etc/rc3.d/S76snmpdx in /etc/rc3.d/K76snmpdx
/etc/rc3.d/S77dmi in /etc/rc3.d/K77dmi
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: /usr/local/lib:/usr/local/ssl/lib:/usr/lib
export PATH=/usr/local/sbin:/usr/local/bin:$PATH
export SNMPCONFPATH =/etc/snmp
export MIBDIRS=/usr/local/share/snmp/mibs
cp /opt/ibm/edge/lb/servers/samples/SNMP/dpid2 /usr/local/sbin/dpid2
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Anmerkungen:
Auf der Website http://sunfreeware.com/ haben die Namen die Erweiterung .gz und können deshalb nicht wie ZIP- oder TAR-Dateien entpackt werden. Verwenden Sie stattdessen pkgadd Paketname.
Führen Sie zum Installieren der Windows-SNMP-Unterstützung die folgenden Schritte aus:
Verwenden Sie bei aktivem Executor den Befehl dscontrol subagent start [Community-Name], um den Namen der Community zu definieren, der zwischen dem Windows-Erweiterungsagenten und dem SNMP-Agenten verwendet wird.
Wichtiger Hinweis: Unter Windows 2003 reagiert SNMP standardmäßig nicht auf angegebene Namen von Communitys. Der SNMP-Subagent antwortet demzufolge nicht auf SNMP-Anforderungen. Um sicherzustellen, dass der SNMP-Subagent auf den Namen der Community reagiert, müssen Sie die SNMP-Serviceeigenschaften mit dem entsprechenden Namen der Community und den entsprechenden Zielhosts konfigurieren. Konfigurieren Sie die SNMP-Sicherheitseigenschaften wie folgt:
Die Kommunikation von SNMP erfolgt über das Senden und Empfangen von Nachrichten, die von verwalteten Einheiten gesendet werden, um Ausnahmebedingungen oder das Auftreten besonderer Ereignisse, wie beispielsweise das Erreichen eines Schwellenwerts, zu melden.
Der Subagent verwendet die folgenden Alarmnachrichten:
Die Nachricht indHighAvailStatus gibt an, dass sich der Wert der Statusvariablen (hasState) für hohe Verfügbarkeit geändert hat. Die gültigen Werte von hasState sind:
Die Alarmnachricht indSrvrGoneDown gibt an, dass die Wertigkeit des vom Abschnitt csID (Cluster-ID), psNum (Portnummer) und ssID (Server-ID) der Objektkennung angegebenen Servers gleich null ist. Die letzte bekannte Anzahl aktiver Verbindungen für den Server wird in der Nachricht gesendet. Diese Alarmnachricht gibt an, dass der angegebene Server inaktiviert ist, soweit der Dispatcher dies feststellen konnte.
Die Alarmnachricht indDOSAttack gibt an, dass der Wert für numhalfopen (die Anzahl halboffener Verbindungen, die nur SYN-Pakete enthalten) an dem vom Abschnitt csID (Cluster-ID) und psNum (Portnummer) der Objektkennung angegebenen Port den Schwellenwert maxhalfopen überschritten hat. Die Anzahl der für den Port konfigurierten Server wird in der Alarmnachricht gesendet. Diese Alarmnachricht zeigt an, dass bei Load Balancer möglicherweise eine DoS-Attacke aufgetreten ist.
Die Alarmnachricht indDOSAttackDone gibt an, dass der Wert für numhalfopen (die Anzahl halboffener Verbindungen, die nur SYN-Pakete enthalten) an dem vom Abschnitt csID und psNum der Objektkennung angegebenen Port unter den Schwellenwert maxhalfopen gefallen ist. Die Anzahl der für den Port konfigurierten Server wird in der Alarmnachricht gesendet. Wenn Load Balancer nach dem Senden einer indDOSAttack-Alarmnachricht feststellt, dass die mögliche DoS-Attacke vorüber ist, wird diese Alarmnachricht gesendet.
Auf Linux- und UNIX-Systemen kann es sich aufgrund einer Einschränkung in der SMUX-API bei der Unternehmenskennung, die in Nachrichten von dem ibmNetDispatcher-Subagenten gemeldet wird, um die Unternehmenskennung von dpid2 und nicht um die Unternehmenskennung von ibmNetDispatcher, 1.3.6.1.4.1.2.6.144, handeln. Die SNMP-Verwaltungsdienstprogramme können jedoch die Quelle der Nachricht bestimmen, da die Daten eine Objektkennung aus der ibmNetDispatcher-MIB enthalten.
Mit dem Befehl dscontrol subagent start wird die SNMP-Unterstützung aktiviert. Mit dem Befehl dscontrol subagent stop wird die SNMP-Unterstützung inaktiviert.
Weitere Informationen zum Befehl "dscontrol" finden Sie im Abschnitt dscontrol subagent -- SNMP-Subagenten konfigurieren.
In den Linux-Kernel ist das Firewall-Tool ipchains integriert. Wenn Load Balancer und ipchains gleichzeitig ausgeführt werden, sieht Load Balancer die Pakete zuerst. Erst danach werden sie von ipchains gesehen. Deshalb kann ipchains verwendet werden, um die Sicherheit einer Linux-Maschine mit Load Balancer zu erhöhen. Bei einer solchen Maschine könnte es sich beispielsweise um einen Rechner mit Load Balancer handeln, der einen Lastausgleich für Firewalls durchführt.
Wenn ipchains oder iptables für eine vollständige Einschränkung konfiguriert ist (so dass kein ein- oder ausgehender Datenverkehr zulässig ist), arbeitet die Paketweiterleitungsfunktion von Load Balancer normal weiter.
ipchains und iptables können nicht zum Filtern von eingehendem Datenverkehr verwendet werden, für den noch kein Lastausgleich durchgeführt wurde.
Ein gewisses Maß an Datenverkehr muss erlaubt sein, da Load Balancer sonst nicht fehlerfrei arbeiten kann. Nachfolgend sind einige Beispiele für eine solche Kommunikation aufgelistet:
Eine angemessene ipchains-Strategie für die Load-Balancer-Maschinen wäre, den gesamten Datenverkehr mit Ausnahme des Verkehrs von oder zu den Back-End-Servern, den Partnermaschinen für hohe Verfügbarkeit, allen Erreichbarkeitszielen oder Konfigurationshosts zu unterbinden.
Sie sollten iptables nicht aktivieren, wenn Sie Load Balancer mit einem Linux-Kernel der Version 2.4.10.x ausführen. Eine Aktivierung unter diesem Linux-Kernel kann im Laufe der Zeit zur Beeinträchtigung des Durchsatzes führen.
Wenn Sie iptables inaktivieren möchten, listen Sie die Module auf (lsmod), um festzustellen, welche Module ip_tables und ip_conntrack verwenden. Entfernen Sie sie anschließend mit den Befehlen rmmod ip_tables und rmmod ip_conntrack. Nach einem Warmstart der Maschine werden diese Module wieder hinzugefügt. Sie müssen diesen Schritt deshalb nach jedem Warmstart wiederholen.
Weitere Informationen finden Sie im Abschnitt Problem: Mögliche Störung der Paketweiterleitung durch iptables unter Linux.
Die folgenden Abschnitte erläutern die Verwendung und Verwaltung der Komponente CBR von Load Balancer.
CBR und Caching Proxy kooperieren über die API des Caching-Proxy-Plug-in bei der Bearbeitung von HTTP- und HTTPS-Anfragen (SSL). CBR kann erst mit dem Lastausgleich für die Server beginnen, wenn Caching Proxy auf derselben Maschine ausgeführt wird. Konfigurieren Sie CBR und Caching Proxy wie im Abschnitt CBR-Konfigurationsbeispiel beschrieben.
Nachdem Sie CBR gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von CBR verwendeten Protokolle ähneln den Protokollen, die im Dispatcher verwendet werden. Weitere Informationen finden Sie im Abschnitt Load-Balancer-Protokolle 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 finden Sie im Abschnitt Load-Balancer-Protokolle verwenden.
Nachdem Sie Cisco CSS Controller gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von Cisco CSS Controller verwendeten Protokolle ähneln den Protokollen des Dispatchers. Weitere Informationen finden Sie im Abschnitt Load-Balancer-Protokolle verwenden.
Nachdem Sie Nortel Alteon Controller gestartet haben, können Sie die Komponente mit einer der folgenden Methoden steuern:
Die von Nortel Alteon Controller verwendeten Protokolle ähneln den Protokollen des Dispatchers. Weitere Informationen finden Sie im Abschnitt Load-Balancer-Protokolle verwenden.
Metric Server stellt Informationen zur Serverauslastung für Load Balancer bereit. Metric Server befindet sich auf jedem Server, der in den Lastausgleich einbezogen ist.
Linux- und UNIX-Systeme:
Windows-Systeme:
Klicken Sie nacheinander auf Start > Einstellungen (für Windows 2000)> Systemsteuerung > Verwaltung > Dienste. Klicken Sie mit der rechten Maustaste auf "IBM Metric Server", und wählen Sie "Starten" aus. Zum Stoppen des Services müssen Sie dieselben Schritte ausführen und "Beenden" auswählen.
Ändern Sie die Protokollstufe im Startscript für Metric Server. Der gültige Wertebereich für die Protokollierungsstufe ist wie bei den Load-Balancer-Protokollen 0 bis 5. 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 Load Balancer beziehen.
Stellen Sie wie in diesem Abschnitt beschrieben die vom IBM Kundendienst geforderten Daten zusammen. Die Informationen sind wie folgt thematisch geordnet:
Für die Komponente Dispatcher gibt es ein Fehlerbestimmungs-Tool, das automatisch betriebssystemspezifische Daten und komponentenspezifische Konfigurationsdateien erfasst. Geben Sie zum Ausführen dieses Tools im entsprechenden Verzeichnis lbpd ein:
Für Linux- und UNIX-Systeme: /opt/ibm/edge/lb/servers/bin/
Für Windows-Systeme: C:\Programme\IBM\edge\lb\servers\bin
Dieses Fehlerbestimmungs-Tool packt die Daten wie folgt in Dateien:
Für Linux- und UNIX-Systeme: /opt/ibm/edge/lb/lbpmr.tar.Z
Für Windows-Systeme: C:\Programme\IBM\edge\lb\lbpmr.zip
Bevor Sie den IBM Kundendienst anrufen, sollten Sie die folgenden Informationen zur Hand haben.
dscontrol file save primary.cfg
Dieser Befehl stellt die Konfigurationsdatei in das Verzeichnis .../ibm/edge/lb/servers/configuration/Komponente/.
java -fullversion
Auf AIX-, HP-UX-, Linux- und Solaris-Systemen: netstat -ni
Auf Windows-Systemen: ipconfig /all
Dies ist für alle Server und für Load Balancer erforderlich.
Auf AIX-, HP-UX- Linux- und Solaris-Systemen: netstat -nr
Auf Windows-Systemen: route print
Dies ist für alle Server und für Load Balancer erforderlich.
Stellen Sie bei Problemen in einer Umgebung mit hoher Verfügbarkeit die folgenden erforderlichen Informationen zusammen:
AIX-, HP-UX-, Linux- und Solaris-Systeme: /opt/ibm/edge/lb/servers/bin
Windows-Systeme: C:\Programme\ibm\edge\lb\servers\bin
Die Scriptnamen lauten wie folgt:
goActive
goStandby
goIdle (sofern vorhanden)
goInOp (sofern vorhanden)
Fügen Sie die Konfigurationsdateien hinzu. Weitere Informationen finden Sie im Abschnitt Allgemeine Informationen (immer erforderlich).
Stellen Sie bei Advisor-Fehlern (z. B., wenn Advisor-Funktionen Server fälschlicherweise als inaktiv markieren) die folgenden erforderlichen Informationen zusammen.
dscontrol advisor loglevel http 80 5
oder
dscontrol advisor loglevel Advisor-Name Port Protokollstufe
oder
dscontrol advisor loglevel Advisor-Name Cluster:Port Protokollstufe
oder
nalcontrol metriccollector set Consultant-ID:Service-ID:Metrikname loglevel Wert
Dieser Befehl erstellt ein Protokoll mit dem Namen "ADV_Advisor-Name.log, z. B. ADV_http.log. Dieses Protokoll finden Sie in den folgenden Verzeichnissen:
AIX-, HP-UX-, Linux- und Solaris-Plattformen: /opt/ibm/edge/lb/servers/logs/Komponente
Windows-Plattformen: C:\Programme\ibm\edge\lb\servers\logs\Komponente
Komponente steht hier für Folgendes:
dispatcher = Dispatcher
cbr = Content Based Routing
cco = Cisco CSS Controller
nal = Nortel Alteon Controller
ss = Site Selector
Der Aufruf von ADVLOG gibt Anweisungen in der Protokolldatei der Advisor-Funktionen aus, wenn die Stufe niedriger als die den Advisor-Funktionen zugeordnete Protokollstufe ist. Bei der Protokollstufe 0 wird die Anweisung immer geschrieben. Sie können ADVLOG nicht vom Konstruktor aus verwenden. Die Protokolldatei wird erst unmittelbar nach Beendigung des Konstruktors für die benutzerdefinierte Advisor-Funktion erstellt, weil der Name der Protokolldatei von Angaben abhängt, die im Konstruktor definiert werden.
Sie können Ihre eigene Advisor-Funktion aber auch auf andere Weise testen und dabei die obige Einschränkung umgehen. Mit den Anweisungen System.out.println(Nachricht) können Sie Nachrichten in einem Fenster ausgeben. Editieren Sie das Script dsserver und ändern Sie javaw in java, damit die print-Anweisungen im Fenster erscheinen. Die Nachrichten können nur angezeigt werden, wenn das zum Starten von dsserver verwendete Fenster geöffnet bleibt. Auf Windows-Plattformen müssen Sie den als Dienst ausgeführten Dispatcher stoppen und ihn manuell in einem Fenster starten, um die Nachrichten anzuzeigen.
Weitere Informationen zu ADVLOG finden Sie im Programming Guide for Edge Components.
Stellen Sie bei Problemen mit dem Content Based Routing die folgenden erforderlichen Informationen zusammen:
Linux- und UNIX-Systeme: /etc/
Windows-Systeme: C:\Programme\IBM\edge\cp\etc\en_US\
Linux- und UNIX-Systeme: /opt/ibm/edge/lb/servers/configurations/cbr
Windows-Systeme: C:\Programme\IBM\edge\lb\servers\configurations\cbr
Wenn Sie den Cluster nicht erreichen können, wurde möglicherweise auf einer der Load-Balancer-Maschinen oder auf beiden kein Aliasname für den Cluster definiert. Sie können wie folgt feststellen, welche Maschine Eigner des Clusters ist:
ping Cluster arp -aFalls Sie die Dispatcher-Weiterleitungsmethode "nat" oder "cbr" verwenden, rufen Sie mit Ping auch die Rückkehradresse ab.
AIX- und HP-UX-Systeme: netstat -ni
Linux- und Solaris-Systeme: ifconfig -a
Auf Windows-Systemen: ipconfig /all
Wenn Sie von ping keine Antwort erhalten und nicht mit ULB arbeiten, wurde möglicherweise auf den Schnittstellen beider Maschinen (z. B. en0, tr0 usw.) kein Aliasname für die Cluster-IP-Adresse definiert.
Wenn alle Versuche, Routing-Fehler zu beheben, gescheitert sind, setzen Sie den folgenden Befehl ab, um einen Trace für den Datenverkehr im Netz durchzuführen:
iptrace -a -s fragliche_Client-IP-Adresse -d Cluster-IP-Adresse -b iptrace.trc
Führen Sie den Trace durch, reproduzieren Sie den Fehler und beenden Sie dann den Prozess mit kill.
tcpdump -i lan0 host Cluster und host Client
Unter Umständen müssen Sie tcpdump von einer der GNU-Softwarearchivsites zu HP-UX herunterladen.
tcpdump -i eth0 host Cluster and host Client
Führen Sie den Trace durch, reproduzieren Sie den Fehler und beenden Sie dann den Prozess mit kill.
snoop -v Client-IP-Adresse Ziel-IP-Adresse > snooptrace.out
Sie können auch die Protokollstufe verschiedener Protokolle (z. B. des Manager- oder des Advisor-Protokolls) erhöhen und die Protokollausgaben auswerten.
Überprüfen Sie, ob Upgrades verfügbar sind, da ein vorliegender Fehler möglicherweise in einem neuen Servicerelease oder Patch-Code bereits behoben ist. Eine Liste der behobenen Fehler für Edge Components finden Sie auf der Unterstützungsseite der Website zu WebSphere Application Server unter der folgenden Adresse: http://www.ibm.com/software/webservers/appserv/was/support/. Klicken Sie auf der Unterstützungsseite auf den Link zur Downloadsite für Fehlerberichtigungen.
Die richtige Java-Version wird im Rahmen der Installation von Load Balancer installiert.
Im Abschnitt Referenzliteratur finden Sie Links zu Webseiten für Unterstützung und Bibliotheken. Die Webseite für Unterstützung enthält einen Link zu technischen Hinweisen, die Ihnen bei Fragen weiterhelfen können.
In den genannten Tabellen finden Sie Informationen zu folgenden Themen:
Tabelle 17. Fehlerbehebungstabelle für Dispatcher
Symptom | Mögliche Ursache | Siehe Abschnitt ... |
---|---|---|
Dispatcher wird nicht korrekt ausgeführt. | In Konflikt stehende Portnummern | Portnummern für Dispatcher überprüfen |
Ein auf der Dispatcher-Maschine konfigurierter Server antwortet nicht auf Lastausgleichsanforderungen. | Falsche oder einen Konflikt verursachende Adresse | Problem: Dispatcher und Server antworten nicht |
Kein Service für Verbindungen von Clientmaschinen oder Zeitlimitüberschreitung bei Verbindungen |
| Problem: Dispatcher-Anforderungen werden nicht verteilt |
Clientmaschinen erhalten keinen Service oder überschreiten das Zeitlimit. | Funktion für hohe Verfügbarkeit arbeitet nicht | Problem: Die Dispatcher-Funktion für hohe Verfügbarkeit kann nicht ausgeführt werden |
Es kann kein Überwachungssignal hinzugefügt werden (Windows-Plattform). | Die Quellenadresse ist auf keinem Adapter konfiguriert. | Problem: Es kann kein Überwachungssignal hinzugefügt werden (Windows-Plattform) |
Server verarbeitet keine Anforderungen (Windows-Plattform) | Es wurde eine zusätzliche Route in der Routentabelle erstellt. | Problem: Zusätzliche Routen (Windows 2000) |
Advisor-Funktionen arbeiten nicht korrekt mit der Weitverkehrsunterstützung. | Advisor-Funktionen werden auf fernen Maschinen nicht ausgeführt. | Problem: Advisor-Funktionen arbeiten nicht korrekt |
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-Plattform) |
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 "dscontrol "oder "lbadmin" scheitert mit der Nachricht "Server antwortet nicht" oder "Zugriff auf RMI-Server nicht möglich". |
| Problem: Der Befehl "dscontrol" oder "lbadmin" scheitert |
Wenn Netscape als Standardbrowser zum Anzeigen der Onlinehilfe verwendet wird, erscheint die Fehlernachricht "Datei ... nicht gefunden" (Windows-Plattform). | Falsche Einstellung für die HTML-Dateizuordnung | Problem: Fehlernachricht "Datei nicht gefunden..." beim Anzeigen der Onlinehilfe (Windows-Plattform) |
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 | Dateiabhängigkeit von Caching Proxy | 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: Auf der Windows-Plattform sind die Hilfefenster manchmal von anderen offenen Fenstern verdeckt |
Load Balancer kann Rahmen nicht verarbeiten und weiterleiten | Für jede NIC ist eine eindeutige MAC-Adresse erforderlich. | Problem: Load Balancer kann Rahmen nicht verarbeiten und weiterleiten |
Die Anzeige ist blau. | Es ist keine Netzwerkkarte installiert/konfiguriert. | Problem: Beim Starten des Executors von Load Balancer erscheint eine blaue Anzeige |
Automatische Pfaderkennung verhindert Datenrückfluss. | Auf der Loopback-Einheit wird ein Aliasname für den Cluster verwendet. | Problem: Automatische Pfaderkennung verhindert Datenrückfluss mit Load Balancer |
Keine hohe Verfügbarkeit im Weitverkehrsmodus von Load Balancer | Der ferne Dispatcher muss auf dem lokalen Dispatcher als Server eines Clusters definiert werden. | Problem: Keine hohe Verfügbarkeit im Weitverkehrsmodus von Load Balancer |
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äß |
IP-Adressen werden über die Fernverbindung nicht richtig aufgelöst. | Wenn Sie einen fernen Client mit einer gesicherten Socks-Implementierung verwenden, ist nicht sichergestellt, dass vollständig qualifizierte Domänen- oder Hostnamen in die richtige IP-Adresse aufgelöst werden. | Problem: IP-Adressen werden über die Fernverbindung nicht richtig aufgelöst |
Auf der koreanischen Schnittstelle von Load Balancer werden bei AIX- und Linux-Systemen überlappende oder unpassende Schriftarten angezeigt | Ändern Sie die Standardschriftarten. | Problem: Auf der koreanischen Schnittstelle von Load Balancer werden bei AIX- und Linux-Systemen überlappende oder unpassende Schriftarten angezeigt |
Wenn Sie auf Windows-Systemen einen Aliasnamen auf dem MS Loopback-Adapter definiert haben und bestimmte Befehle absetzen (z. B. hostname), reagiert das Betriebssystem falsch und gibt die Aliasadresse zurück. | In der Liste der Netzwerkverbindungen darf der neu hinzugefügte Aliasname nicht oberhalb der lokalen Adresse aufgeführt sein. | Problem: Auf Windows-Systemen wird beim Absetzen von Befehlen wie hostname an Stelle der lokalen Adresse die Aliasadresse zurückgegeben |
Bei Verwendung einer Matrox-AGP-Videokarte auf einer Windows-Plattform kommt es zu unerwartetem GUI-Verhalten. | Der Fehler tritt auf, wenn Matrox-AGP-Videokarten während der Ausführung der Load-Balancer-GUI verwendet werden. | Problem: Unerwartetes GUI-Verhalten auf der Windows-Plattform bei Verwendung von Matrox-AGP-Videokarten |
Bei Ausführung von rmmod ibmlb auf Linux-Systemen kommt es zu einem unerwarteten Verhalten (z. B. zu einer Blockierung des Systems). | Der Fehler tritt auf, wenn das Kernel-Modul von Load Balancer (ibmlb) manuell entfernt wird. | Problem: Unerwartetes Verhalten bei Ausführung von "rmmod ibmlb" (Linux-Systeme) |
Bei Ausführung von Befehlen auf der Dispatcher-Maschine sind die Antwortzeiten sehr lang. | Lange Antwortzeiten können auf eine Überlastung der Maschine durch ein hohes Clientdatenverkehrsaufkommen zurückzuführen sein. | Problem: Lange Antwortzeiten beim Ausführen von Befehlen auf der Dispatcher-Maschine |
Bei Verwendung der Dispatcher-Weiterleitungsmethode "mac" registriert die SSL- oder HTTPS-Advisor-Funktion keine Serverbelastungen. | Dieser Fehler tritt auf, wenn die SSL-Serveranwendung nicht mit der Cluster-IP-Adresse konfiguriert ist. | Problem: Bei Verwendung der Weiterleitungsmethode "mac" registriert die Advisor-Funktion SSL oder HTTPS keine Serverlast |
Bei der fernen Webverwaltung mit Netscape wird die Verbindung zum Host getrennt. | Die Verbindung zum Host wird getrennt, wenn Sie die Größe des Browserfensters ändern. | Problem: Trennen der Hostverbindung bei Änderung des Netscape-Browserfensters in der Webverwaltung |
Bei aktiviertem Socket-Pooling wird der Webserver an 0.0.0.0 gebunden. | Konfigurieren Sie den Microsoft IIS bindungsspezifisch. | Problem: Bei aktiviertem Socket-Pooling wird der Webserver an 0.0.0.0 gebunden |
Auf der Windows-Plattform erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1). | Ändern Sie die Schriftarteigenschaften des Fensters mit der Eingabeaufforderung. | Problem: Auf Windows-Systemen erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1) |
Auf der HP-UX-Plattform wird die folgende Nachricht angezeigt: java.lang.OutOfMemoryError unable to create new native thread | Einige HP-UX-Installationen lassen standardmäßig 64 Threads pro Prozess zu. Dies ist unzureichend. | Problem: Java-Fehler unter HP-UX wegen unzureichender Speicherkapazität/Threads |
Unter Windows markieren Advisor-Funktionen und Erreichbarkeitsziele alle Server als inaktiv. | Das Feature Task Offload ist nicht inaktiviert oder Sie müssen unter Umständen ICMP aktivieren. | Problem: Auf Windows-Systemen markieren Advisor-Funktionen und Erreichbarkeitsziele alle Server als inaktiv |
Auf der Windows-Plattform tritt ein Problem bei der Auflösung von IP-Adressen in Hostnamen auf, wenn für einen Adapter mehrere Adressen konfiguriert sind | Die IP-Adresse, die als Hostname verwendet werden soll, muss in der Registrierungsdatenbank als erste Adresse angegeben sein. | Problem: Auflösung von IP-Adressen in Hostnamen auf Windows-Systemen, wenn für einen Adapter mehrere Adressen konfiguriert sind |
Auf der Windows-Plattform können die Advisor-Funktionen in einer Konfiguration für hohe Verfügbarkeit nach einem Netzwerkausfall nicht ausgeführt werden. | Wenn das System einen Netzwerkausfall erkennt, löscht es seinen ARP-Cache (Address Resolution Protocol). | Problem: Advisor-Funktionen können auf Windows-Systemen in einer Konfiguration für hohe Verfügbarkeit nach einem Netzwerkausfall nicht ausgeführt werden |
Auf Linux-Systemen ist der Befehl "IP address add" nicht mit mehreren Clusteraliasnamen auf der Loopback-Einheit kompatibel. | Wenn Sie auf der Loopback-Einheit Aliasnamen für mehrere Adressen festlegen möchten, sollten Sie den Befehl ifconfig und nicht ip address add verwenden. | Problem: Beim Festlegen von Aliasnamen für mehrere Cluster auf der Loopback-Einheit von Linux-Systemen nicht den Befehl "IP address add" verwenden |
Bei dem Versuch, einen Server hinzuzufügen, erscheint die Fehlernachricht: "Router-Adresse nicht angegeben oder nicht gültig für die Portmethode". | Stellen Sie anhand der Informationen in der Prüfliste fest, welches Problem bei Hinzufügen eines Servers aufgetreten ist. | Problem: Fehlernachricht "Router-Adresse nicht angegeben oder nicht gültig für Portmethode" erscheint |
Auf Solaris-Systemen werden die Load-Balancer-Prozesse beendet, wenn Sie das Fenster mit der Terminalsitzung verlassen, in dem die Prozesse gestartet wurden. | Verwenden Sie den Befehl nohup, um zu verhindern, dass die gestarteten Prozesse beim Verlassen der Terminalsitzung ein Stoppsignal empfangen. | Problem: Auf Solaris-Systemen werden Load-Balancer-Prozesse beim Verlassen des Terminalfensters, in dem die Prozesse gestartet wurden, beendet |
Beim Laden von Load-Balancer-Konfigurationen geht der Durchsatz zurück. | Die Verzögerung kann auf DNS-Aufrufe (Domain Name System) zurückzuführen sein, die abgesetzt werden, um die Serveradresse aufzulösen und zu prüfen. | Problem: Verzögerung beim Laden einer Load-Balancer-Konfiguration |
Auf Windows-Systemen erscheint die Fehlernachricht, dass ein IP-Adressenkonflikt mit einem anderen System im Netz vorliegt. | Wenn die hohe Verfügbarkeit konfiguriert ist, können für einen kurzen Zeitraum Clusteradressen auf beiden Maschinen konfiguriert sein, was zu dieser Fehlernachricht führt. | Problem: Fehlernachricht zu einem IP-Adressenkonflikt auf Windows-Systemen |
In einer Konfiguration mit hoher Verfügbarkeit sind sowohl primäre Maschinen als auch Ausweichmaschinen aktiv. | Dieses Problem kann auftreten, wenn die go-Scripts weder auf der primären Maschine noch auf der Ausweichmaschine ausgeführt werden. | Problem: In einer Konfiguration mit hoher Verfügbarkeit sind sowohl primäre Maschinen als auch Ausweichmaschinen aktiv |
Clientanforderungen scheitern, wenn der Dispatcher versucht, Antworten in Form großer Seiten zurückzugeben. | Clientanforderungen, die zu Antworten in Form großer Seiten führen, überschreiten das Zeitlimit, wenn die maximale Übertragungseinheit (MTU, Maximum Transmit Unit) auf der Dispatcher-Maschine bei Verwendung der Weiterleitungsmethode "nat" oder "cbr" nicht ordnungsgemäß gesetzt ist. | Problem: Clientanforderungen scheitern, wenn die Rückgabe von Antworten in Form großer Seiten versucht wird |
Auf Windows-Systemen wird beim Absetzen eines Befehls dscontrol oder lbadmin der Fehler "Der Server antwortet nicht" angezeigt. | Dieser Fehler tritt auf, wenn es auf einem Windows-System mehr als eine IP-Adresse gibt und die Hostdatei nicht angibt, welche Adresse dem Hostnamen zugeordnet werden soll. | Auf Windows-Systemen wird beim Absetzen eines Befehls dscontrol oder lbadmin der Fehler "Der Server antwortet nicht" angezeigt |
Dispatcher-Maschinen mit hoher Verfügbarkeit können unter Linux auf S/390 mit qeth-Treibern möglicherweise nicht synchronisiert werden. | Wenn Sie unter Linux für S/390 mit dem qeth-Netztreiber die hohe Verfügbarkeit verwenden, können der aktive Dispatcher und der Bereitschafts-Dispatcher unter Umständen nicht synchronisiert werden. | Problem: Dispatcher-Maschinen mit hoher Verfügbarkeit können unter Linux auf S/390 mit qeth-Treibern möglicherweise nicht synchronisiert werden |
Tipps für das Konfigurieren der hohen Verfügbarkeit für Load Balancer | Die Tipps werden Ihnen helfen, die Auswirkungen von Problemen mit der hohen Verfügbarkeit zu verringern. Es können unter anderem folgende Probleme auftreten:
| Problem: Konfigurationstipps für hohe Verfügbarkeit |
Einschränkungen für die Konfiguration der Dispatcher-Weiterleitungsmethode MAC auf zSeries- und S/390-Plattformen | Unter Linux gibt es Einschränkungen, wenn Sie zSeries- oder S/390-Server mit OSA-Karten (Open System Adapter) verwenden. Strategien zur Lösung von Problemen stehen zur Verfügung. | Problem: Einschränkungen für die Dispatcher-Konfiguration unter Linux auf zSeries- oder S/390-Servern mit OSA-Karten |
Speicherverlust unter einigen Red-Hat-Linux-Versionen bei Ausführung von Load Balancer mit Manager und Advisor-Funktionen | Die JVM-Versionen des IBM Java SDK und die im Lieferumfang einiger Linux-Distributionen (z. B. Red Hat Enterprise Linux 3.0) enthaltene NPTL (Native POSIX Thread Library) können einen Speicherverlust verursachen. | Problem: Speicherverlust unter einigen Linux-Versionen bei Ausführung von Dispatcher mit Manager und Advisor-Funktionen |
Hinweis auf weitergeleitete Pakete (steigende Paketanzahl) im Dispatcher-Bericht unter SUSE Linux Enterprise Server 9, obwohl die Pakete den Back-End-Server nie wirklich erreichen | Das NAT-Modul von iptables wird geladen. In dieser Version von iptables gibt es möglicherweise einen (noch nicht nachgewiesenen) Fehler, der bei der Interaktion mit Dispatcher ein seltsames Verhalten auslöst. | Problem: Unter SUSE Linux Enterprise Server 9 leitet Dispatcher Pakete weiter, die den Back-End-Server jedoch nicht erreichen |
Mögliche Probleme bei der Funktionsübernahme auf Windows-Systemen, wenn das Dispatcher-Feature für hohe Verfügbarkeit verwendet wird | Wenn das goScript, das die Cluster-IP-Adresse auf der aktiven Maschine konfiguriert, vor dem goScript ausgeführt wird, das die Cluster-IP-Adresse der Ausweichmaschine aus der Konfiguration entfernt, kann es zu Problemen kommen. | Problem: Fehlernachricht zu einem IP-Adressenkonflikt auf Windows-Systemen während der Funktionsübernahme bei hoher Verfügbarkeit |
Mögliche Störung der Paketweiterleitung durch iptables auf Linux-Systemen | Unter Linux kann iptables den Lastausgleich für den Datenverkehr stören und muss auf der Load-Balancer-Maschine inaktiviert werden. | Problem: Mögliche Störung der Paketweiterleitung durch iptables unter Linux |
Warnung zu Java-Dateigruppen bei der Installation von Servicekorrekturen oder bei einer Installation mit den nativen System-Tools für Paketinstallation | Die Produktinstallation umfasst mehrere Pakete, die nicht auf derselben Maschine installiert werden müssen. Jedes dieser Pakete installiert daher eine Java-Dateigruppe. Werden die Pakete auf derselben Maschine installiert, erscheint eine Warnung, dass eine andere Dateigruppe auch Eigner der Java-Dateigruppe ist. | Java-Warnung bei Installation von Servicekorrekturen |
Upgrade der Java-Dateigruppe von Load-Balancer-Installationen | Falls ein Problem mit der Java-Dateigruppe auftritt, melden Sie es dem IBM Service. Sie erhalten dann ein Upgrade für die Java-Dateigruppe, die für die Load-Balancer-Installation bereitgestellt wurde. | Upgrade der Java-Dateigruppe einer Load-Balancer-Installation |
Persistente Verbindungen können auf einer Windows-Plattform bei der Übernahme für hohe Verfügbarkeit unterbrochen werden | Unter dem Betriebssystem Microsoft Windows können persistente Verbindungen bei der Übernahme für hohe Verfügbarkeit unterbrochen werden. Dieses Problem tritt nur auf, wenn Sie einen kollokierten Server haben, der die Weiterleitungsmethode MAC verwendet. | Problem: Persistente Verbindungen können bei der Übernahme für hohe Verfügbarkeit unterbrochen werden |
Installationsprogramm wird unter dem 32-Bit-Betriebssystem Linux für zSeries nicht ausgeführt |
Bei der Installation von WebSphere Edge Server mit ./install unter dem 32-Bit-Betriebssystem Linux für zSeries wird die Nachricht "JVM nicht gefunden" ausgegeben. | Problem: Bei der Installation von WebSphere Edge Server mit ./install unter dem 32-Bit-Betriebssystem Linux für zSeries wird die Nachricht "JVM nicht gefunden" ausgegeben |
Der Deinstallationsprozess wird unter dem Betriebssystem Linux nicht ordnungsgemäß ausgeführt. |
Der Deinstallationsprozess für WebSphere Edge
Server blockiert unter dem Betriebssystem Linux. | Problem: Der Deinstallationsprozess für WebSphere Edge Server blockiert unter dem Betriebssystem Linux |
Tabelle 18. Fehlerbehebungstabelle für CBR
Symptom | Mögliche Ursache | Siehe Abschnitt... |
CBR wird nicht korrekt ausgeführt. | In Konflikt stehende Portnummern | Portnummern für CBR überprüfen |
Der Befehl "cbrcontrol" oder "lbadmin" 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 "lbadmin" 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. Es ist auch möglich, dass die Verknüpfung mit der Bibliothek nicht korrekt angegeben ist. | Problem: Auf Solaris-Systemen scheitert der Befehl "cbrcontrol executor start" |
URL-Regel arbeitet nicht. | Syntax- oder Konfigurationsfehler | Problem: Syntax- oder Konfigurationsfehler |
Bei Verwendung einer Matrox-AGP-Videokarte in Windows-Systemen kommt es zu unerwartetem GUI-Verhalten. | Der Fehler tritt auf, wenn Matrox-AGP-Videokarten während der Ausführung der Load-Balancer-GUI verwendet werden. | Problem: Unerwartetes GUI-Verhalten auf der Windows-Plattform bei Verwendung von Matrox-AGP-Videokarten |
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äß |
Bei der fernen Webverwaltung mit Netscape wird die Verbindung zum Host getrennt. | Die Verbindung zum Host wird getrennt, wenn Sie die Größe des Browserfensters ändern. | Problem: Trennen der Hostverbindung bei Änderung des Netscape-Browserfensters in der Webverwaltung |
Auf der Windows-Plattform erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1). | Ändern Sie die Schriftarteigenschaften des Fensters mit der Eingabeaufforderung. | Problem: Auf der Windows-Plattform erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1) |
Auf der HP-UX-Plattform wird die folgende Nachricht angezeigt: java.lang.OutOfMemoryError unable to create new native thread | Einige HP-UX-Installationen lassen standardmäßig 64 Threads pro Prozess zu. Dies ist unzureichend. | Problem: Java-Fehler unter HP-UX wegen unzureichender Speicherkapazität/Threads |
Unter Windows markieren Advisor-Funktionen und Erreichbarkeitsziele alle Server als inaktiv. | Das Feature Task Offload ist nicht inaktiviert oder Sie müssen unter Umständen ICMP aktivieren. | Problem: Auf Windows-Systemen markieren Advisor-Funktionen und Erreichbarkeitsziele alle Server als inaktiv |
Auf der Windows-Plattform tritt ein Problem bei der Auflösung von IP-Adressen in Hostnamen auf, wenn für einen Adapter mehrere Adressen konfiguriert sind. | Die IP-Adresse, die als Hostname verwendet werden soll, muss in der Registrierungsdatenbank als erste Adresse angegeben sein. | Problem: Auflösung von IP-Adressen in Hostnamen auf Windows-Systemen, wenn für einen Adapter mehrere Adressen konfiguriert sind |
Auf Solaris-Systemen werden die Load-Balancer-Prozesse beendet, wenn Sie das Fenster mit der Terminalsitzung verlassen, in dem die Prozesse gestartet wurden. | Verwenden Sie den Befehl nohup, um zu verhindern, dass die gestarteten Prozesse beim Verlassen der Terminalsitzung ein Stoppsignal empfangen. | Problem: Auf Solaris-Systemen werden Load-Balancer-Prozesse beim Verlassen des Terminalfensters, in dem die Prozesse gestartet wurden, beendet |
Tabelle 19. Fehlerbehebungstabelle zu Site Selector
Symptom | Mögliche Ursache | Siehe Abschnitt ... |
---|---|---|
Site Selector wird nicht korrekt ausgeführt. | Konflikt verursachende Portnummer | Portnummern für Site Selector überprüfen |
Site Selector gewichtet vom Solaris-Client eingehende Anforderungen nicht nach der Round-Robin-Methode. | Solaris-Systeme führen einen Namensservice-Cache-Dämon aus. | Problem: Site Selector verteilt den Datenverkehr von Solaris-Clients nicht nach der Round-Robin-Methode |
Der Befehl "sscontrol" oder "lbadmin" 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 "lbadmin" scheitert |
ssserver kann auf der Windows-Plattform nicht gestartet werden. | Auf Windows-Systemen muss der Hostname nicht im DNS enthalten sein. | Problem: ssserver wird auf der Windows-Plattform nicht gestartet |
Für eine Maschine mit duplizierten Routen 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 Routen den Lastausgleich nicht korrekt durch |
Bei Verwendung einer Matrox-AGP-Videokarte auf einer Windows-Plattform kommt es zu unerwartetem GUI-Verhalten. | Der Fehler tritt auf, wenn Matrox-AGP-Videokarten während der Ausführung der Load-Balancer-GUI verwendet werden. | Problem: Unerwartetes GUI-Verhalten auf der Windows-Plattform bei Verwendung von Matrox-AGP-Videokarten |
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äß |
Bei der fernen Webverwaltung mit Netscape wird die Verbindung zum Host getrennt. | Die Verbindung zum Host wird getrennt, wenn Sie die Größe des Browserfensters ändern. | Problem: Trennen der Hostverbindung bei Änderung des Netscape-Browserfensters in der Webverwaltung |
Auf der Windows-Plattform erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1). | Ändern Sie die Schriftarteigenschaften des Fensters mit der Eingabeaufforderung. | Problem: Auf der Windows-Plattform erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1) |
Auf der HP-UX-Plattform wird die folgende Nachricht angezeigt: java.lang.OutOfMemoryError unable to create new native thread | Einige HP-UX-Installationen lassen standardmäßig 64 Threads pro Prozess zu. Dies ist unzureichend. | Problem: Java-Fehler unter HP-UX wegen unzureichender Speicherkapazität/Threads |
Unter Windows markieren Advisor-Funktionen und Erreichbarkeitsziele alle Server als inaktiv. | Das Feature Task Offload ist nicht inaktiviert oder Sie müssen unter Umständen ICMP aktivieren. | Problem: Auf Windows-Systemen markieren Advisor-Funktionen und Erreichbarkeitsziele alle Server als inaktiv |
Auf Solaris-Systemen werden die Load-Balancer-Prozesse beendet, wenn Sie das Fenster mit der Terminalsitzung verlassen, in dem die Prozesse gestartet wurden. | Verwenden Sie den Befehl nohup, um zu verhindern, dass die gestarteten Prozesse beim Verlassen der Terminalsitzung ein Stoppsignal empfangen. | Problem: Auf Solaris-Systemen werden Load-Balancer-Prozesse beim Verlassen des Terminalfensters, in dem die Prozesse gestartet wurden, beendet |
Tabelle 20. Fehlerbehebungstabelle für Cisco CSS Switches
Symptom | Mögliche Ursache | Siehe Abschnitt ... |
---|---|---|
ccoserver wird nicht gestartet | In Konflikt stehende Portnummern | Portnummern für Cisco CSS Controller überprüfen |
Der Befehl "ccocontrol" oder "lbadmin" 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 ccoserver nicht gestartet wurde. | Problem: Der Befehl "ccocontrol" oder "lbadmin" scheitert |
Empfangener Fehler: Für Port 13099 kann kein Eintrag in der Registrierungsdatenbank erstellt werden. | Abgelaufene Produktlizenz | Problem: Für Port 13099 kann kein Eintrag in der Registrierungsdatenbank erstellt werden |
Bei Verwendung einer Matrox-AGP-Videokarte auf einer Windows-Plattform kommt es zu unerwartetem GUI-Verhalten. | Der Fehler tritt auf, wenn Matrox-AGP-Videokarten während der Ausführung der Load-Balancer-GUI verwendet werden. | Problem: Unerwartetes GUI-Verhalten auf der Windows-Plattform bei Verwendung von Matrox-AGP-Videokarten |
Empfang eines Verbindungsfehlers, wenn ein Consultant hinzugefügt wird. | Die Konfigurationseinstellungen für den Switch oder den Controller stimmen nicht. | Problem: Beim Hinzufügen eines Consultant wird ein Verbindungsfehler empfangen |
Die Wertigkeiten werden auf dem Switch nicht aktualisiert. | Die Kommunikation zwischen Controller und Switch ist nicht möglich oder unterbrochen. | Problem: Auf dem Switch werden die Wertigkeiten nicht aktualisiert |
Der Aktualisierungsbefehl (refresh) aktualisiert die Consultant-Konfiguration nicht. | Die Kommunikation zwischen Switch und Controller ist nicht möglich oder unterbrochen. | Problem: Befehl "refresh" aktualisiert die Consultant-Konfiguration nicht |
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äß |
Bei der fernen Webverwaltung mit Netscape wird die Verbindung zum Host getrennt. | Die Verbindung zum Host wird getrennt, wenn Sie die Größe des Browserfensters ändern. | Problem: Trennen der Hostverbindung bei Änderung des Netscape-Browserfensters in der Webverwaltung |
Auf der Windows-Plattform erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1). | Ändern Sie die Schriftarteigenschaften des Fensters mit der Eingabeaufforderung. | Problem: Auf der Windows-Plattform erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1) |
Auf der HP-UX-Plattform wird die folgende Nachricht angezeigt: java.lang.OutOfMemoryError unable to create new native thread | Einige HP-UX-Installationen lassen standardmäßig 64 Threads pro Prozess zu. Dies ist unzureichend. | Problem: Java-Fehler unter HP-UX wegen unzureichender Speicherkapazität/Threads |
Auf Solaris-Systemen werden die Load-Balancer-Prozesse beendet, wenn Sie das Fenster mit der Terminalsitzung verlassen, in dem die Prozesse gestartet wurden. | Verwenden Sie den Befehl nohup, um zu verhindern, dass die gestarteten Prozesse beim Verlassen der Terminalsitzung ein Stoppsignal empfangen. | Problem: Auf Solaris-Systemen werden Load-Balancer-Prozesse beim Verlassen des Terminalfensters, in dem die Prozesse gestartet wurden, beendet |
Tabelle 21. Fehlerbehebungstabelle für Nortel Alteon Controller
Symptom | Mögliche Ursache | Siehe Abschnitt ... |
---|---|---|
nalserver wird nicht gestartet | In Konflikt stehende Portnummern | Portnummern für Nortel Alteon Controller überprüfen |
Der Befehl "nalcontrol" oder "lbadmin" 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 nalserver nicht gestartet wurde. | Problem: Der Befehl "nalcontrol" oder "lbadmin" 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 |
Bei Verwendung einer Matrox-AGP-Videokarte auf einer Windows-Plattform kommt es zu unerwartetem GUI-Verhalten. | Der Fehler tritt auf, wenn Matrox-AGP-Videokarten während der Ausführung der Load-Balancer-GUI verwendet werden. | Problem: Unerwartetes GUI-Verhalten auf der Windows-Plattform bei Verwendung von Matrox-AGP-Videokarten |
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äß |
Bei der fernen Webverwaltung mit Netscape wird die Verbindung zum Host getrennt. | Die Verbindung zum Host wird getrennt, wenn Sie die Größe des Browserfensters ändern. | Problem: Trennen der Hostverbindung bei Änderung des Netscape-Browserfensters in der Webverwaltung |
Empfang eines Verbindungsfehlers, wenn ein Consultant hinzugefügt wird. | Die Konfigurationseinstellungen für den Switch oder den Controller stimmen nicht. | Problem: Beim Hinzufügen eines Consultant wird ein Verbindungsfehler empfangen |
Die Wertigkeiten werden auf dem Switch nicht aktualisiert. | Die Kommunikation zwischen Controller und Switch ist nicht möglich oder unterbrochen. | Problem: Auf dem Switch werden die Wertigkeiten nicht aktualisiert |
Der Aktualisierungsbefehl (refresh) aktualisiert die Consultant-Konfiguration nicht. | Die Kommunikation zwischen Switch und Controller ist nicht möglich oder unterbrochen. | Problem: Befehl "refresh" aktualisiert die Consultant-Konfiguration nicht |
Auf der Windows-Plattform erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1). | Ändern Sie die Schriftarteigenschaften des Fensters mit der Eingabeaufforderung. | Problem: Auf Windows-Systemen erscheint die Eingabeaufforderung mit beschädigten nationalen Sonderzeichen (Latin-1) |
Auf der HP-UX-Plattform wird die folgende Nachricht angezeigt: java.lang.OutOfMemoryError unable to create new native thread | Einige HP-UX-Installationen lassen standardmäßig 64 Threads pro Prozess zu. Dies ist unzureichend. | Problem: Java-Fehler unter HP-UX wegen unzureichender Speicherkapazität/Threads |
Auf Solaris-Systemen werden die Load-Balancer-Prozesse beendet, wenn Sie das Fenster mit der Terminalsitzung verlassen, in dem die Prozesse gestartet wurden. | Verwenden Sie den Befehl nohup, um zu verhindern, dass die gestarteten Prozesse beim Verlassen der Terminalsitzung ein Stoppsignal empfangen. | Problem: Auf Solaris-Systemen werden Load-Balancer-Prozesse beim Verlassen des Terminalfensters, in dem die Prozesse gestartet wurden, beendet |
Tabelle 22. Fehlerbehebungstabelle für Metric Server
Symptom | Mögliche Ursache | Siehe Abschnitt ... |
---|---|---|
IOException für Metric Server auf der Windows-Plattform bei Ausführung von benutzerdefinierten Metrikdateien mit der Erweiterung .bat oder .cmd | Es ist ein vollständiger Metrikname erforderlich. | Problem: IOException für Metric Server auf der Windows-Plattform bei Ausführung von benutzerdefinierten Metrikdateien mit der Erweiterung .bat oder .cmd |
Metric Server meldet die Lastinformationen nicht an die Load-Balancer-Maschine. | Mögliche Ursachen sind unter anderem:
| Problem: Metric Server meldet die Last nicht an die Load-Balancer-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 |
Wenn Metric Server auf einem AIX-Multiprozessorsystem (AIX 4.3.3 oder AIX 5.1) mit starker Belastung ausgeführt wird, kann die Ausgabe des Befehls ps -vg beschädigt werden. | Dieses bekannte AIX-Problem wird von APAR IY33804 korrigiert. | Problem: Bei Ausführung von Metric Server auf AIX-Systemen kann die Ausgabe des Befehls "ps -vg" beschädigt werden |
Konfigurieren von Metric Server in einer zweistufigen Konfiguration mit Site Selector zur Lastverteilung auf Dispatcher mit hoher Verfügbarkeit | Metric Server (zweite Stufe) ist nicht für Empfangsbereitschaft an einer neuen IP-Adresse konfiguriert. | Problem: Konfigurieren von Metric Server in einer zweistufigen Konfiguration mit Site Selector für die Lastverteilung auf Dispatcher mit hoher Verfügbarkeit |
Scripts (metricserver, cpuload, memload), die auf Solaris-Maschinen mit mehreren CPUs ausgeführt werden, erzeugen unerwünschte Konsolnachrichten. | Dieses Verhalten ist auf die Verwendung des VMSTAT-Systembefehls zum Abrufen von CPU- und Speicherstatistiken vom Kernel zurückzuführen. | Problem: Unerwünschte Konsolnachrichten bei Ausführung von Scripts auf Solaris-Maschinen mit mehreren CPUs |
Auf Solaris-Systemen werden die Load-Balancer-Prozesse beendet, wenn Sie das Fenster mit der Terminalsitzung verlassen, in dem die Prozesse gestartet wurden. | Verwenden Sie den Befehl nohup, um zu verhindern, dass die gestarteten Prozesse beim Verlassen der Terminalsitzung ein Stoppsignal empfangen. | Problem: Auf Solaris-Systemen werden Load-Balancer-Prozesse beim Verlassen des Terminalfensters, in dem die Prozesse gestartet wurden, beendet |
Metrik gibt nach dem Start von Metric Server -1 zurück. | Dieses Problem kann dadurch entstehen, dass die Schlüsseldateien bei der Übertragung zum Client ihre Integrität verlieren. | Problem: Nach dem Start von Metric Server wird der Wert -1 zurückgegeben |
Falls beim Ausführen des Dispatchers Probleme auftreten, verwendet unter Umständen eine Ihrer Anwendungen eine Portnummer, die normalerweise vom Dispatcher benutzt wird. Der Dispatcher-Server benutzt die folgenden Portnummern:
Wenn eine andere Anwendung eine der Portnummern des Dispatchers verwendet, können Sie die Portnummern des Dispatchers oder die Portnummer der Anwendung ändern.
Gehen Sie zum Ändern der Portnummern des Dispatchers wie folgt vor:
Gehen Sie zum Ändern der RMI-Portnummer der Anwendung wie folgt vor:
Wenn beim Ausführen von CBR Fehler auftreten, verwendet unter Umständen eine Ihrer Anwendungen eine Portnummer, die normalerweise von CBR benutzt wird. CBR benutzt die folgenden Portnummern:
Wenn eine andere Anwendung eine der Portnummern für CBR verwendet, können Sie die Portnummern für CBR oder die Portnummer der Anwendung ändern.
Gehen Sie zum Ändern der Portnummern für CBR wie folgt vor:
Gehen Sie zum Ändern der RMI-Portnummer der Anwendung wie folgt vor:
Wenn bei Ausführung der Komponente Site Selector Fehler auftreten, verwendet unter Umständen eine Ihrer Anwendungen eine Portnummer, die normalerweise von Site Selector benutzt wird. Site Selector benutzt die folgenden Portnummern:
Wenn eine andere Anwendung eine der Portnummern von Site Selector verwendet, können Sie die Portnummern von Site Selector oder die Portnummer der Anwendung ändern.
Gehen Sie zum Ändern der Portnummern für Site Selector wie folgt vor:
Gehen Sie zum Ändern der RMI-Portnummer der Anwendung wie folgt vor:
Wenn bei Ausführung der Komponente Cisco CSS Controller Fehler auftreten, verwendet unter Umständen eine andere Anwendung eine Portnummer, die normalerweise vom ccoserver der Komponente Cisco CSS Controller benutzt wird. Cisco CSS Controller benutzt die folgenden Portnummern:
13099 zum Empfangen der Befehle von ccocontrol
10004 zum Senden von Metrikabfragen an Metric Server
13199 für den RMI-Serverport
Wenn eine andere Anwendung eine der Portnummern von Cisco CSS Controller verwendet, können Sie die Portnummern von Cisco CSS Controller oder die Portnummer der Anwendung ändern.
Gehen Sie zum Ändern der Portnummern für Cisco CSS Controller wie folgt vor:
Gehen Sie zum Ändern der RMI-Portnummer der Anwendung wie folgt vor:
Wenn bei Ausführung der Komponente Nortel Alteon Controller Fehler auftreten, verwendet unter Umständen eine andere Anwendung eine Portnummer, die normalerweise vom nalserver der Komponente Nortel Alteon Controller benutzt wird. Nortel Alteon Controller benutzt die folgenden Portnummern:
14099 zum Empfang der Befehle von nalcontrol
10004 zum Senden von Metrikabfragen an Metric Server
14199 für den RMI-Serverport
Wenn eine andere Anwendung eine der Portnummern von Nortel Alteon Controller verwendet, können Sie die Portnummern von Nortel Alteon Controller oder die Portnummern der Anwendung ändern.
Gehen Sie zum Ändern der Portnummern von Nortel Alteon Controller wie folgt vor:
Gehen Sie zum Ändern der RMI-Portnummer der Anwendung wie folgt vor:
Dieses Problem kann auftreten, wenn eine andere Anwendung einen der Ports benutzt, die normalerweise vom Dispatcher verwendet werden. Weitere Informationen finden Sie im Abschnitt Portnummern für Dispatcher überprüfen.
Dieses Problem tritt auf, wenn eine andere als die angegebene Adresse verwendet wird. Stellen Sie bei Verknüpfung von Dispatcher und Server sicher, dass die in der Konfiguration verwendete Serveradresse die NFA ist oder als verknüpft konfiguriert ist. Überprüfen Sie außerdem die Adresse der Hostdatei.
Symptome für dieses Problem sind: Verbindungen von Clientmaschinen werden nicht bedient oder Verbindungen überschreiten ein Zeitlimit. Überprüfen Sie Folgendes, um diesen Fehler zu bestimmen:
Beachten Sie für Windows und andere Plattformen auch die Informationen im Abschnitt Servermaschinen für Lastausgleich konfigurieren.
Dieses Problem tritt auf, wenn eine Dispatcher-Umgebung mit hoher Verfügbarkeit konfiguriert ist und Verbindungen von Clientmaschinen nicht bedient werden oder Zeitlimits überschreiten. Überprüfen Sie Folgendes, um den Fehler zu korrigieren oder zu bestimmen:
Mit den folgenden Schritten kann effektiv getestet werden, ob Scripts für hohe Verfügbarkeit fehlerfrei funktionieren:
Die beiden Berichte sind identisch, wenn die Scripts richtig konfiguriert sind.
Dieser Fehler tritt auf der Windows-Plattform auf, wenn die Quellenadresse auf keinem Adapter konfiguriert ist. Überprüfen Sie Folgendes, um den Fehler zu korrigieren oder zu bestimmen:
dscontrol executor configure <IP-Adresse>
Nach dem Konfigurieren von Servermaschinen stellen Sie unter Umständen fest, dass Sie unbeabsichtigt eine oder mehrere zusätzliche Route(n) erstellt haben. Werden diese zusätzlichen Routen nicht entfernt, kann der Dispatcher nicht ordnungsgemäß arbeiten. Informationen zum Feststellen und Löschen zusätzlicher Routen finden Sie im Abschnitt Servermaschinen für Lastausgleich konfigurieren.
Wenn Sie die Weitverkehrsunterstützung verwenden und die Advisor-Funktionen nicht ordnungsgemäß zu arbeiten scheinen, müssen Sie sicherstellen, dass sie sowohl auf den lokalen als auch auf den fernen Dispatchern gestartet wurden.
Vor der Advisor-Anforderung wurde ein ICMP ping an die Server abgesetzt. Falls es zwischen Load Balancer und den Servern eine Firewall gibt, stellen Sie sicher, dass pings über die Firewall unterstützt werden. Stellt eine solche Konfiguration ein Sicherheitsrisiko für Netz dar, modifizieren Sie die Anweisung java in dsserver, um alle Ping-Befehle an die Server zu inaktivieren. Fügen Sie dazu wie folgt die Eigenschaft java hinzu:
LB_ADV_NO_PING="true" java -DLB_ADV_NO_PING="true"
Weitere Informationen finden Sie im Abschnitt Ferne Advisor-Funktionen mit der Dispatcher-WAN-Unterstützung verwenden.
Wenn Sie Dispatcher, Microsoft IIS und SSL verwenden und diese Komponenten nicht zusammenarbeiten, 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 Dokumentation Microsoft Information and Peer Web Services.
Der Dispatcher verwendet Schlüssel, die 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 javaw
Diese Definition kann Fehler verursachen, wenn eine der Verwaltungskonsolen auf derselben Maschine als Firewall oder über eine Firewall ausgeführt wird. Wird beispielsweise Load Balancer auf derselben Maschine als Firewall ausgeführt, können beim Absetzen von dscontrol-Befehlen Fehler wie der folgende angezeigt werden: Fehler: Server antwortet nicht.
Sie können diesen Fehler vermeiden, indem Sie die dsserver-Scriptdatei editieren und den von RMI für die Firewall (oder eine andere Anwendung) verwendeten Port festlegen. Ändern Sie die Zeile LB_RMISERVERPORT=10199 to LB_RMISERVERPORT=Ihr_Port. Ihr_Port ist ein anderer Port.
Starten Sie anschließend erneut dsserver und öffnen Sie den Datenverkehr für die Ports 10099, 10004, 10199 und 10100 oder für den Port, den Sie für die Hostadresse, an der die Verwaltungskonsole ausgeführt wird, ausgewählt haben.
Beispiel: java -Djava.rmi.server.hostname="10.1.1.1"
Wenn Sie auf Windows-Plattformen Netscape als Standardbrowser verwenden, kann bei diesem Fehler die folgende Nachricht erscheinen: "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:
Die grafische Benutzerschnittstelle lbadmin erfordert für eine einwandfreie Funktion einen ausreichenden Paging-Bereich. Wenn der Paging-Bereich nicht ausreicht, wird die GUI möglicherweise nicht vollständig gestartet. Überprüfen Sie in einem solchen Fall den Paging-Bereich und vergrößern Sie ihn gegebenenfalls.
Wenn Sie Load Balancer deinstallieren, um eine andere Version zu installieren, und bei dem Versuch, die Komponente Dispatcher zu starten, eine Fehlernachricht empfangen, überprüfen Sie, ob 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 grafische Benutzerschnittstelle (GUI, Graphical User Interface) von Load Balancer 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 auf der Windows-Plattform 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 ibmlb.conf nicht alle Netzschnittstellen für Load Balancer konfiguriert sind und die nicht in ibmlb.conf definierte NIC einen Rahmen empfängt, kann Load Balancer 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 folgenden Befehl:
ifconfig Schnittstelle ether MAC-Adresse
Beispiel:
ifconfig eri0 ether 01:02:03:04:05:06
Auf der Windows-Plattform müssen Sie vor dem Starten des Executors eine Netzwerkkarte installiert und konfiguriert haben.
Unter AIX gibt es einen Netzwerkparameter 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 auf der Loopback-Einheit ein Aliasname für den Cluster verwendet wird. Wenn die Gateway-Adresse für die Route in das Teilnetz des Clusters / der Netzmaske fällt, erstellen AIX-Systeme die Route zur Loopback-Adresse. Der Grund hierfür ist, dass dies die letzte Schnittstelle war, deren Aliasname dieses Teilnetz enthielt.
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, verwenden AIX-Systeme 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:
Wenn Sie Load Balancer für ein WAN 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, verwendet er auf seinem Adapter diese Adresse als Aliasnamen, so dass er 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 mit lbadmin oder der Webverwaltung (lbwaccess) eine große Konfigurationsdatei (im Schnitt mit mehr als 200 add-Befehlen) 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 Konfiguration 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 "64M". Für Solaris 8 gilt ein Maximalwert von "4000M".
Zum Hinzufügen dieser Option müssten Sie die lbadmin-Scriptdatei editieren und wie folgt "javaw" in "javaw -Xmxn" ändern. (Bei AIX-Systemen müssen Sie "java" in "java -Xmxn" ändern):
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH% %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
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.
Wenn das Verwaltungsprogramm von Load Balancer (lbadmin) nach dem Aktualisieren der Konfiguration die Verbindung zum Server trennt, überprüfen Sie auf dem Server, den Sie konfigurieren möchten, die Version von dsserver. Stellen Sie sicher, dass diese mit der Version von lbadmin oder dscontrol identisch ist.
Wenn Sie einen fernen Client mit einer gesicherten Socks-Implementierung verwenden, ist nicht sichergestellt, dass vollständig qualifizierte Domänen- oder Hostnamen in die richtige IP-Adresse im IP-Adressenformat aufgelöst werden. Möglicherweise fügt die Socks-Implementierung spezifische Socks-bezogene Daten zur DNS-Auflösung hinzu.
Wenn die IP-Adressen über die Fernverbindung nicht richtig aufgelöst werden, geben Sie die IP-Adressen im IP-Adressenformat an.
Überlappende und unpassende Schriftarten auf der koreanischen Load-Balancer-Schnittstelle können Sie wie folgt korrigieren:
Auf AIX-Systemen
-Monotype-TimesNewRomanWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
Auf Linux-Systemen
-monotype-timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
Wenn Sie auf Windows-Systemen einen Aliasnamen auf dem MS Loopback-Adapter definiert haben und bestimmte Befehle absetzen (z. B. hostname), reagiert das Betriebssystem falsch und gibt an Stelle der lokalen Adresse die Aliasadresse zurück. Dieser Fehler tritt nicht mehr auf, wenn der neu hinzugefügte Aliasname in der Liste der Netzwerkverbindungen unterhalb der lokalen Adresse aufgeführt ist. Dadurch ist sichergestellt, dass vor der Loopback-Aliasadresse auf die lokale Adresse zugegriffen wird.
Gehen Sie wie folgt vor, um die Liste der Netzwerkverbindungen zu überprüfen:
Wenn Sie auf der Windows-Plattform eine Matrox-AGP-Karte verwenden, kann es in der grafischen Benutzerschnittstelle von Load Balancer zu unerwartetem Verhalten kommen. Beim Klicken mit der Maus kann ein Block etwa von der Größe des Mauszeigers beschädigt werden und zur Umkehrung von Hervorhebungen oder zur Verschiebung von Abbildungen führen. Bei älteren Matrox-Karten wurde dieses Verhalten nicht beobachtet. Für Matrox-AGP-Karten gibt es keine bekannte Korrektur.
Wenn dsserver beim manuellen Entfernen des Kernel-Moduls von Load Balancer noch aktiv ist, kann es auf Linux-Systemen zu einem unerwarteten Verhalten kommen. Das System könnte beispielsweise blockieren oder es könnten javacores geschrieben werden. Wenn Sie das Kernel-Modul manuell entfernen möchten, stoppen Sie vorher den dsserver.
Falls dsserver stop nicht funktioniert, stoppen Sie den Java-Prozess mit "SRV_KNDConfigServer". Stoppen Sie dem Prozess. Stellen Sie dazu mit dem Befehl ps -ef | grep SRV_KNDConfigServer die Prozesskennung des Dienstes fest. Beenden Sie dann den Prozess mit dem Befehl kill Prozess-ID.
Sie können den Befehl "rmmod ibmlb" sicher ausführen, um das Load-Balancer-Modul aus dem Kernel zu entfernen.
Wenn Sie die Komponente Dispatcher für den Lastausgleich einsetzen, kann der Computer mit Clientdatenverkehr überlastet werden. Das Kernel-Modul von Load Balancer hat die höchste Priorität. Wenn dieses Modul ständig mit der Bearbeitung von Clientpaketen beschäftigt ist, kann der Rest des Systems möglicherweise nicht mehr reagieren. Die Ausführung von Befehlen im Benutzerbereich kann dann sehr lange dauern. Unter Umständen werden die Befehle gar nicht vollständig ausgeführt.
In einer solchen Situation sollten Sie Ihre Konfiguration neu strukturieren, um eine Überlastung der Load-Balancer-Maschine zu vermeiden. Mögliche Alternativen wären die Verteilung der Last auf mehrere Load-Balancer-Maschinen oder das Ersetzen der Maschine durch einen leistungsstärkeren und schnelleren Computer.
Wenn Sie untersuchen möchten, ob die langen Antwortzeiten auf ein hohes Clientdatenverkehrsaufkommen zurückzuführen ist, überlegen Sie, ob dieser Zustand auftritt, wenn viel Clientdatenverkehr generiert wird. Dieselben Symptome können durch schlecht konfigurierte Systeme hervorgerufen werden, die Routenschleifen produzieren. Stellen Sie vor dem Ändern der Load-Balancer-Konfiguration fest, ob die Symptome durch eine hohe Clientlast verursacht werden.
Bei Verwendung der Weiterleitungsmethode "mac" sendet Load Balancer Pakete an die Server und verwendet dabei die Clusteradresse, für die auf der Loopback-Einheit ein Aliasname definiert ist. Einige Serveranwendungen (z. B. SSL) erfordern, dass Konfigurationsdaten (wie Zertifikate) auf den IP-Adressen basieren. Die IP-Adresse muss die Clusteradresse sein, die an der Loopback-Adresse definiert ist. Nur in diesem Fall stimmt sie mit dem Inhalt eingehender Pakete überein. Wird beim Konfigurieren der Serveranwendung nicht die IP-Adresse des Clusters verwendet, kann die Clientanforderung nicht ordnungsgemäß zum Server weitergeleitet werden.
Wenn Sie Load Balancer mit der fernen Webverwaltung konfigurieren, dürfen Sie nicht die Größe des Netscape-Browserfensters ändern, in dem die Load-Balancer-GUI angezeigt wird. Das heißt, Sie dürfen das Fenster nicht minimieren, maximieren, wiederherstellen usw. Da Netscape bei jeder Größenänderung des Browserfensters die Seite neu lädt, kommt es zu einer Trennung der Hostverbindung, die nach einer solchen Änderung demzufolge neu hergestellt werden muss. Wenn Sie die ferne Webverwaltung auf einer Windows-Plattform ausführen, verwenden Sie Internet Explorer.
Wenn Sie Microsoft IIS Version 5.0 auf Back-End-Servern mit Windows ausführen, müssen Sie Microsoft IIS bindungsspezifisch konfigurieren. Andernfalls ist das Socket-Pooling standardmäßig aktiviert, so dass der Webserver nicht an die virtuellen IP-Adressen gebunden wird, die als mehrere Identitäten der Site konfiguriert wurden, sondern an 0.0.0.0, und somit den gesamten Datenverkehr empfangen kann. Wenn eine Anwendung auf dem lokalen Host bei aktiviertem Socket-Pooling inaktiviert wird, können die Advisor-Funktionen dies auf AIX- oder Windows-ND-Servern erkennen. Wird jedoch eine Anwendung auf einem virtuellen Host inaktiviert, während der lokale Host aktiv bleibt, erkennen die Advisor-Funktionen den Ausfall der Anwendung nicht, so dass Microsoft IIS weiterhin auf den gesamten Datenverkehr reagiert, auch auf den der inaktivierten Anwendung.
Wenn Sie feststellen möchten, ob das Socket-Pooling aktiviert ist und der Webserver an 0.0.0.0 gebunden wird, setzen Sie den folgenden Befehl ab:
netstat -an
Anweisungen für das bindungsspezifische Konfigurieren von Microsoft IIS (Inaktivieren des Socket-Pooling) finden Sie auf der Microsoft-Website für Produktunterstützung. Bei Anzeige der folgenden Informationen können Sie auch den jeweils genannten URL aufrufen:
Unter Windows können im Fenster mit der Eingabeaufforderung einige nationale Sonderzeichen der Zeichensatzfamilie Latin-1 beschädigt angezeigt werden. Der Buchstabe "a" mit Tilde kann beispielsweise als Pi-Symbol erscheinen. Zum Korrigieren dieses Fehlers müssen Sie die Schriftarteigenschaften für das Fenster mit der Eingabeaufforderung ändern. Gehen Sie zum Ändern der Schriftart wie folgt vor:
Einige Installationen von HP-UX 11i sind so vorkonfiguriert, dass nur 64 Threads pro Prozess zulässig sind. Manche Load-Balancer-Konfigurationen erfordern jedoch mehr Threads. Setzen Sie die Anzahl der Threads pro Prozess auf HP-UX-Systemen auf mindestens 256. Verwenden Sie zum Erhöhen dieses Wertes das Dienstprogramm "sam", und definieren Sie den Kernel-Parameter "max_thread_proc" neu. Bei einer erwarteten starken Auslastung, müssen Sie "max_thread_proc" möglicherweise auf einen noch höheren Wert als 256 setzen.
Gehen Sie zum Erhöhen von max_thread_proc wie folgt vor:
Wenn Sie Ihren Adapter in einer Load-Balancer-Maschine konfigurieren, müssen Sie für eine fehlerfreie Ausführung der Advisor-Funktion sicherstellen, dass die beiden folgenden Einstellungen richtig definiert sind:
Wenn Sie auf der Windows-Plattform einen Adapter mit mehreren IP-Adressen konfigurieren, muss die IP-Adresse, die mit dem Hostnamen verbunden werden soll, als erste Adresse in der Registrierungsdatenbank konfiguriert werden.
Da Load Balancer in vielen Instanzen (z. B. lbkeys create) von InetAddress.getLocalHost() abhängig ist, können mehrere IP-Adressen, die per Aliasname an einen Adapter gebunden sind, zu Fehlern führen. Zur Vermeidung dieses Problems sollten die IP-Adressen, in die der Hostname aufgelöst werden soll, als erste Adressen in der Registrierungsdatenbank aufgelistet sein. Beispiel:
Wenn das Betriebssystem Windows einen Netzwerkausfall erkennt, löscht es standardmäßig seinen ARP-Cache (Address Resolution Protocol) einschließlich aller statischen Einträge. Ist das Netzwerk wieder verfügbar, wird der ARP-Cache durch die im Netzwerk gesendeten ARP-Anforderungen wieder gefüllt.
In einer Konfiguration für hohe Verfügbarkeit übernehmen beide Server primäre Operationen, wenn einer der Server oder beide von einem Verlust der Netzkonnektivität betroffen ist/sind. Wird dann die ARP-Anforderung zur erneuten Füllung des ARP-Cache gesendet, antworten beide Server. Deshalb markiert der ARP-Cache den Eintrag als ungültig. Die Advisor-Funktionen können aus diesem Grund keinen Socket zu den Ausweichservern erstellen.
Dieses Problem lässt sich dadurch lösen, dass das Betriebssystem Windows daran gehindert wird, den ARP-Cache bei einem Konnektivitätsverlust zu löschen. Microsoft hat einen Artikel veröffentlicht, in dem die Ausführung dieser Task erklärt wird. Sie finden diesen Artikel auf der Website von Microsoft unter "Knowledge Base". Der Artikel hat die Nummer 239924 und die Webadresse http://support.microsoft.com/default.aspx?scid=kb;de;239924.
Hier finden Sie eine Zusammenfassung der im Artikel von Microsoft beschriebenen Schritte, die das System daran hindern sollen, den ARP-Cache zu löschen:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Bei Verwendung von Servern mit dem Linux-Kernel 2.4.x und der Dispatcher-Weiterleitungsmethode "mac" sind mehrere Punkte zu beachten. Wenn der Server mit dem Befehl ip address add eine Clusteradresse auf der Loopback-Einheit konfiguriert hat, kann nur für eine Clusteradresse ein Aliasname festgelegt werden.
Wenn Sie auf der Loopback-Einheit Aliasnamen für mehrere Cluster festlegen möchten, verwenden den Befehl ifconfig. Beispiel:
ifconfig lo:Nummer Clusteradresse netmask 255.255.255.255 up
Zusätzlich ist zu beachten, dass die Konfigurationsmethode "ifconfig" für Schnittstellen nicht vollständig mit der Konfigurationsmethode ip für Schnittstellen kompatibel ist. Deshalb sollte für einen Standort eine Methode ausgewählt und dann ausschließlich angewendet werden.
Wenn Sie Server zu Ihrer Dispatcher-Konfiguration hinzufügen, kann die Fehlernachricht "Fehler: Router-Adresse nicht angegeben oder nicht gültig für Portmethode" angezeigt werden.
Bestimmen Sie den Fehler anhand der Prüfliste.
Der Standardwert für den Parameter "router" ist 0. Dieser Wert gibt an, dass der Server lokal ist. Wenn Sie die Router-Adresse des Servers auf einen Wert ungleich 0 setzen, gibt dieser Wert an, dass es sich um einen fernen Server in einem anderen Teilnetz handelt. Weitere Informationen zum Parameter "router" des Befehls "server add" finden Sie im Abschnitt dscontrol server -- Server konfigurieren.
Befindet sich der Server, den Sie hinzufügen, in einem anderen Teilnetz, sollte der Parameter "router" auf die Adresse des Routers gesetzt werden, der im lokalen Teilnetz für die Kommunikation mit dem fernen Server verwendet wird.
Wenn Sie auf Solaris-Systemen Load-Balancer-Scripts (wie dsserver oder lbadmin) in einem Terminalfenster starten, endet der Load-Balancer-Prozess beim Verlassen dieses Fensters.
Sie können dieses Problem lösen, indem Sie die Load-Balancer-Scripts mit dem Befehl nohup starten. Beispiel: nohup dsserver. Dieser Befehl verhindert, dass die in der Terminalsitzung gestarteten Prozesse beim Beenden des Terminals ein Stoppsignal empfangen, so dass die Prozesse nach Beendigung der Terminalsitzung weiter ausgeführt werden können. Geben Sie den Befehl nohup vor allen Load-Balancer-Scripts an, die nach dem Ende einer Terminalsitzung weiter verarbeitet werden sollen.
Das Laden einer Load-Balancer-Konfiguration kann aufgrund von DNS-Aufrufen (Domain Name System), die abgesetzt werden, um die Serveradresse aufzulösen und zu prüfen, sehr lange dauern.
Falls der DNS der Load-Balancer-Maschine falsch konfiguriert ist oder DNS generell viel Zeit benötigt, verlangsamt sich das Laden der Konfiguration, weil Java DNS-Anforderungen im Netz sendet.
Sie können dieses Problem umgehen, indem Sie die Serveradressen und Hostnamen zu Ihrer lokalen Datei /etc/hosts hinzufügen.
Wenn die hohe Verfügbarkeit konfiguriert ist, können für einen kurzen Zeitraum Clusteradressen auf beiden Maschinen konfiguriert sein. Dies führt zu der Fehlernachricht, dass ein IP-Adressenkonflikt mit einem anderem System im Netz vorliegt. Sie können diese Nachricht ignorieren. Es ist möglich, dass eine Clusteradresse für kurze Zeit gleichzeitig auf beiden Maschinen mit hoher Verfügbarkeit konfiguriert ist. Dies gilt insbesondere während des Starts einer der Maschinen oder bei Einleitung einer Aufgabenübernahme.
Überprüfen Sie, ob die Clusteradressen in den go*-Scripts korrekt konfiguriert bzw. dekonfiguriert sind. Wenn Sie eine Konfigurationsdatei aufgerufen und go*-Scripts installiert haben, vergewissern Sie sich, dass Ihre Konfigurationsdatei für Clusteradressen keinen Befehl "executor configure" enthält, da dies zu Konflikten mit den Befehlen "configure" und "unconfigure" in den go*-Scripts führt.
Weitere Informationen zu go*-Scripts beim Konfigurieren der hohen Verfügbarkeit finden Sie im Abschnitt Scripts verwenden.
Dieses Problem kann auftreten, wenn die go-Scripts weder auf der primären Maschine noch auf der Ausweichmaschine ausgeführt werden. Die go-Scripts können nicht ausgeführt werden, wenn dsserver nicht auf beiden Maschinen gestartet wurde. Überprüfen Sie beide Maschinen und vergewissern Sie sich, dass dsserver aktiv ist.
Clientanforderungen, die zu Antworten in Form großer Seiten führen, überschreiten das Zeitlimit, wenn die maximale Übertragungseinheit (MTU, Maximum Transmit Unit) auf der Dispatcher-Maschine nicht ordnungsgemäß gesetzt ist. Dieser Fehler kann bei den Weiterleitungsmethoden cbr und nat der Dispatcher-Komponente auftreten, wenn der Dispatcher den MTU-Wert nicht aushandelt, sonder den Standardwert für die MTU verwendet.
Die MTU wird unter jedem Betriebssystem ausgehend vom Typ des Übertragungsmediums (z. B. Ethernet oder Token-Ring) festgelegt. Für Router des lokalen Segments kann eine kleinere MTU definiert sein, wenn sie eine Verbindung zu einem Übertragungsmedium eines anderen Typs herstellen. Bei normalem TCP-Datenverkehr wird die MTU beim Aufbau der Verbindung ausgehandelt. Für die Übertragung der Daten zwischen den Maschinen wird dann die kleinste MTU verwendet.
Der Dispatcher unterstützt das Aushandeln der MTU nicht für die Weiterleitungsmethoden cbr und nat, weil er an TCP-Verbindungen aktiv als Endpunkt beteiligt ist. Für die Weiterleitungsmethoden cbr und nat verwendet der Dispatcher standardmäßig den MTU-Wert 1500. Dieser Wert ist die typische MTU-Größe für Standard-Ethernet und muss daher von den meisten Kunden nicht angepasst werden.
Wenn Sie mit der Dispatcher-Weiterleitungsmethode "cbr" oder "nat" arbeiten und zum lokalen Segment einen Router mit einer kleineren MTU verwenden, müssen Sie die MTU auf der Dispatcher-Maschine auf diesen niedrigeren MTU-Wert setzen.
Verwenden Sie zur Lösung dieses Problems den folgenden Befehl, um die maximale Segmentgröße (mss) zu setzen: dscontrol executor set mss neuer_Wert
Beispiel:
dscontrol executor set mss 1400
Der Standardwert für mss ist 1460.
Die Einstellung mss gilt nicht für die Dispatcher-Weiterleitungsmethode "mac" oder für eine andere Komponente von Load Balancer. Sie wird nur auf die Komponente Dispatcher angewendet.
Wenn es auf einem Windows-System mehrere IP-Adressen gibt und die Datei hosts nicht angibt, welche Adresse dem Hostnamen zugeordnet werden soll, wählt das Betriebssystem die kleinste Adresse aus und ordnet sie dem Hostnamen zu.
Sie können dieses Problem lösen, indem Sie die Datei c:\Windows\system32\drivers\etc\hosts aktualisieren. Geben Sie den Hostnamen Ihrer Maschine an und die IP-Adresse, die Sie dem Hostnamen zuordnen möchten.
Wichtiger Hinweis: Die IP-Adresse darf keine Clusteradresse sein.
Wenn Sie unter Linux für S/390 mit dem qeth-Netztreiber die hohe Verfügbarkeit verwenden, können der aktive Dispatcher und der Bereitschafts-Dispatcher unter Umständen nicht synchronisiert werden. Dieses Problem könnte auf den Linux-Kernel 2.6 beschränkt sein.
Sollte dieses Problem auftreten, können Sie wie folgt vorgehen:
Definieren Sie zwischen den Images des aktiven Dispatchers und des Bereitschafts-Dispatchers ein CTC-Netz (Channel-to-Channel) und fügen Sie zwischen den IP-Adressen der beiden CTC-Endpunkte ein Überwachungssignal hinzu.
Wenn Sie die Load-Balancer-Funktion für hohe Verfügbarkeit verwenden, kann eine Partnermaschine den Lastausgleich übernehmen, falls der primäre Partner ausfällt oder heruntergefahren wird. Für die Aufrechterhaltung der Verbindungen zwischen den Partnern mit hoher Verfügbarkeit werden zwischen den beiden Maschinen Verbindungssätze übergeben. Wenn der Ausweichpartner die Lastausgleichsfunktion übernimmt, wird die Cluster-IP-Adresse von der Ausweichmaschine entfernt und zur neuen primären Maschine hinzugefügt. Diese Übernahmeoperation kann durch diverse Aspekte der Ablaufsteuerung und der Konfiguration beeinflusst werden.
Mit den in diesem Abschnitt aufgeführten Tipps können Sie die Auswirkungen von Problemen mindern, die sich aus der Konfiguration der hohen Verfügbarkeit ergeben. Es kann sich unter anderem um folgende Probleme handeln:
Die folgenden Tipps sind hilfreich für eine erfolgreiche Konfiguration der hohen Verfügbarkeit auf Ihren Load-Balancer-Maschinen.
Beispielbefehle für hohe Verfügbarkeit:
dscontrol highavailability heartbeat add ... dscontrol highavailability backup add ... dscontrol highavailability reach add ...
In den meisten Fällen müssen Sie die Definitionen für hohe Verfügbarkeit an das Ende der Datei stellen. Die Anweisungen "cluster", "port" und "server" müssen vor den highavailability-Anweisungen stehen. Dies ist notwendig, weil die hohe Verfügbarkeit nach den Cluster-, Port- und Serverdefinitionen sucht, wenn bei der Synchronisation ein Verbindungssatz empfangen wird.
Sind Cluster, Port und Server nicht vorhanden, wird der Verbindungssatz gelöscht. Wenn eine Übernahme stattfinden soll und der Verbindungssatz nicht auf der Partnermaschine repliziert wurde, scheitert die Verbindung.
Eine Ausnahme von dieser Regel bilden verknüpfte Server, die mit der Weiterleitungsmethode MAC konfiguriert sind. Bei diesen Servern müssen die highavailability-Anweisungen vor den Anweisungen für verknüpfte Server stehen. Falls die highavailability-Anweisungen nicht vor den Anweisungen für verknüpfte Server stehen, kann Load Balancer eine Anforderung an den verknüpften Server empfangen, interpretiert diese jedoch wie eine ankommende Anforderung für den Cluster und unterzieht sie dem Lastausgleich. Auf diese Weise können die Pakete in einer Schleife im Netz gesendet werden und unnötigen Datenverkehr verursachen. Wenn die highavailability-Anweisungen vor dem verknüpften Server angegeben sind, weiß Load Balancer, dass ankommender Datenverkehr nur weitergeleitet werden muss, wenn er den Status AKTIV hat.
Korrigieren Sie dieses Verhalten, indem Sie zum goActive-Script eine sleep-Verzögerung hinzufügen. Die jeweilige Verzögerungszeit ist vom Deployment abhängig. Beginnen Sie zunächst mit einer Verzögerungszeit von 10.
Die Maschinen versuchen standardmäßig, jede halbe Sekunde miteinander zu kommunizieren. Nach vier fehlgeschlagenen Versuchen wird ein Ausfall festgestellt. Bei einer ausgelasteten Maschine kann dies eine Funktionsübernahme zur Folge haben, obwohl das System noch ordnungsgemäß arbeitet. Setzen Sie den folgenden Befehl ab, um die Anzahl der Versuche bis zur Feststellung des Ausfalls zu erhöhen:
dscontrol executor set hatimeout <Wert>
Alte Verbindungen dürfen daher nicht längere Zeit im Speicher verbleiben. Probleme hat es insbesondere mit LDAP-Ports und großen staletimeout-Zeiträumen (länger als ein Tag) gegeben. Wird ein großer staletimeout-Zeitraum festgelegt, bleiben alte Verbindungen im Speicher. Dies hat zur Folge, dass bei der Synchronisation mehr Verbindungssätze übergeben werden und die Speicherauslastung auf beiden Maschinen steigt.
Falls die Synchronisation bei einem vernünftigen staletimeout-Zeitraum scheitert, können Sie das Synchronisationszeitlimit mit folgendem Befehl erhöhen:
e xm 33 5 new_timeoutDieser Befehl wird nicht gespeichert, wenn Sie die Konfigurationsdatei speichern. Falls Sie diese Einstellung weiter verwenden möchten, müssen Sie sie nach jedem Systemabschluss manuell zur Konfigurationsdatei hinzufügen.
Das Zeitlimit wird in halben Sekunden gespeichert. Der Standardwert für neues_Zeitlimit liegt daher bei 100 (50 Sekunden).
Wenn Sie die Weiterleitungsmethode "mac" verwenden, müssen sich die Server der Load-Balancer-Konfiguration generell und unabhängig von der Plattform in einem Netzsegment befinden. Aktive Netzeinheiten wie Router, Brücken und Firewalls behindern Load Balancer. Dies liegt daran, dass Load Balancer wie ein spezialisierter Router funktioniert, der nur die Header der Verbindungsschicht für seinen nächsten und letzten Hop modifiziert. Jede Netztopologie, bei der der nächste Hop nicht der letzte Hop ist, ist für Load Balancer nicht gültig.
Für zSeries- und S/390-Server, die die OSA-Karte gemeinsam nutzen, gibt es eine Einschränkung, weil dieser Adapter anders als die meisten Netzkarten funktioniert. Die OSA-Karte hat eine eigene virtuelle Implementierung der Verbindungsschicht, die nichts mit dem Ethernet zu tun hat, das sich den Linux- und z/OS-Hosts präsentiert. Die Verbindung über eine OSA-Karte sieht tatsächlich wie eine Verbindung zwischen Ethernet-Hosts (und nicht wie eine Verbindung zu OSA-Hosts) aus, und die Hosts, die eine solche Karte verwenden, behandeln sie wie eine Ethernet-Karte.
Die OSA-Karte führt auch einige Funktionen mit direktem Bezug zur IP-Schicht aus. Eine ihrer Funktionen ist beispielsweise die Beantwortung von ARP-Anforderungen (Address Resolution Protocol). Außerdem leitet die gemeinsam genutzte OSA-Karte IP-Pakete ausgehend von der Ziel-IP-Adresse weiter und nicht wie ein Switch der Schicht 2 ausgehend von der Ethernet-Adresse. Eigentlich ist die OSA-Karte ein Netzsegment mit einer Brücke zu sich selbst.
Wird Load Balancer auf einem S/390- oder zSeries-Host mit Linux ausgeführt, können Pakete an Hosts mit derselben OSA-Karte oder an Hosts im Ethernet weitergeleitet werden. Alle Hosts, die dieselbe OSA-Karte gemeinsam benutzen, befinden sich effektiv im selben Segment.
Die Natur der OSA-Brücke versetzt Load Balancer in die Lage, Pakete aus dem Bereich der gemeinsam benutzten OSA-Karte hinaus weiterzuleiten. Der Brücke ist der OSA-Port bekannt, der Eigner der Cluster-IP-Adresse ist. Außerdem kennt die Brücke die MAC-Adresse von Hosts, die direkt mit dem Ethernet-Segment verbunden sind. Deshalb kann Load Balancer über eine OSA-Brücke Datenpakete mit der Weiterleitungsmethode "mac" weiterleiten.
In den Bereich einer gemeinsam genutzten OSA-Karte hinein kann Load Balancer jedoch keine Daten weiterleiten. Dies gilt auch für Load Balancer auf einem S/390 mit Linux, wenn der Back-End-Server eine andere OSA-Karte als Load Balancer verwendet. Die OSA-Karte für den Back-End-Server macht die OSA-MAC-Adresse für die Server-IP-Adresse zugänglich. Wenn jedoch ein Paket mit der Ethernet-Zieladresse der Server-OSA-Karte und der IP-Adresse des Clusters ankommt, weiß die OSA-Karte des Servers nicht, welche Hosts das Paket ggf. empfangen sollten. Die Prinzipien, die zwischen OSA und Ethernet eine Weiterleitung mit der Methode "mac" bei einer gemeinsam benutzten OSA-Karte möglich machen, gelten nicht, wenn versucht wird, Daten in den Bereich einer gemeinsam genutzten OSA-Karte hinein weiterzuleiten.
Problemumgehung:
In Load-Balancer-Konfigurationen mit zSeries- oder S/390-Servern, die OSA-Karten enthalten, gibt es zwei Möglichkeiten, das oben beschriebene Problem zu umgehen.
Falls die Server der Load-Balancer-Konfiguration denselben zSeries- oder S/390-Plattformtyp haben, können Sie zwischen Load Balancer und den einzelnen Servern Punkt-zu-Punkt-Verbindungen (CTC oder IUCV) definieren. Konfigurieren Sie die Endpunkte mit privaten IP-Adressen. Die Punkt-zu-Punkt-Verbindung wird nur für den Datenverkehr zwischen Load Balancer und dem jeweiligen Server verwendet. Fügen Sie dann die Server mit der IP-Adresse des Serverendpunkts für den Tunnel hinzu. Bei dieser Konfiguration fließt der Clusterdatenverkehr über die OSA-Karte von Load Balancer und wird über die Punkt-zu-Punkt-Verbindung weitergeleitet. Der Server antwortet dann über seine eigene Standardroute. Die Antwort wird über die OSA-Karte des Servers abgesetzt. Dabei muss es sich nicht um dieselbe Karte handeln.
Falls die Server der Load-Balancer-Konfiguration nicht denselben zSeries- oder S/390-Plattformtyp haben oder keine Punkt-zu-Punkt-Verbindung zwischen Load Balancer und den einzelnen Servern definiert werden kann, sollten Sie das Load-Balancer-Feature Generic Routing Encapsulation (GRE) verwenden. GRE ist ein Protokoll, mit dem Load Balancer Daten über Router weiterleiten kann.
Wenn Sie GRE verwenden, wird das vom Client an die Cluster-IP-Adresse von Load Balancer gekapselt empfangen und an den Server gesendet. Auf dem Server wird das ursprüngliche Paket von Client an die Cluster-IP-Adresse entkapselt, und der Server antwortet dem Client direkt. Der Vorteil der Verwendung von GRE besteht darin, dass Load Balancer nur den Datenverkehr vom Client zum Server sieht, nicht aber den Datenverkehr vom Server zum Client. Der Nachteil ist, dass GRE durch den Kapselungsaufwand die maximale Segmentgröße der TCP-Verbindung herabsetzt.
Wenn Sie die Load-Balancer-Weiterleitung mit GRE konfigurieren möchten, fügen Sie die Server mit dem folgenden Befehl hinzu:
dscontrol server add Clusteradresse:Port:Back-End-Server router Back-End-Server
Die Angabe "router Back-End-Server" ist gültig, wenn sich Load Balancer und der Back-End-Server in demselben IP-Teilnetz befinden. Geben Sie andernfalls die gültige IP-Adresse des nächsten Hop als Router an.
Wenn Sie Linux-Systeme für natives GRE konfigurieren möchten, setzen Sie für jeden Back-End-Server die folgenden Befehle ab:
modprobe ip_gre ip tunnel add grelb0 mode gre ikey 3735928559 ip link set grelb0 up ip addr add Clusteradresse dev grelb0
Wenn Sie Load Balancer konfiguriert mit Manager und Advisor-Funktionen ausführen, kann es bei einigen Read-Hat-Linux-Versionen zu großen Speicherverlusten kommen. Der Java-Speicherverlust nimmt noch zu, wenn Sie für die Advisor-Funktion ein kleines Zeitintervall konfigurieren.
Die JVM-Versionen des IBM Java SDK und die im Lieferumfang einiger Linux-Distributionen (z. B. Red Hat Enterprise Linux 3.0) enthaltene NPTL (Native POSIX Thread Library) können den Speicherverlust verursachen.
Die aktuellsten Informationen zu Linux-Systemen und zu dem mitgelieferten IBM Java SDK finden Sie unter http://www.ibm.com/developerworks/java/jdk/linux/tested.html.
Zur Fehlerbestimmung können Sie den Befehl vmstat oder ps verwenden, mit dem Speicherverluste festgestellt werden können.
Zum Korrigieren des Speicherverlustes müssen Sie den folgenden Befehl zum Inaktivieren der NPTL absetzen, bevor die Load-Balancer-Maschine aktiv ist:
export LD_ASSUME_KERNEL=2.4.10
Wenn Sie unter Suse Linux Enterprise Server 9 die Weiterleitungsmethode "mac" verwenden, kann der Dispatcher-Bericht angeben, dass das Paket weitergeleitet wurde (steigende Paketanzahl), obwohl das Paket den Back-End-Server nie erreicht.
Wenn dieses Problem auftritt, lässt sich unter Umständen Folgendes beobachten:
ip_finish_output2: No header cache and no neighbour!
ICMP Destination unreachable: Fragmentation Needed
Dieses Problem kann wegen des geladenen NAT-Moduls von iptables auftreten. Unter SLES 9 gibt es in dieser Version von iptables möglicherweise einen (noch nicht nachgewiesenen) Fehler, der bei der Interaktion mit Dispatcher ein seltsames Verhalten auslöst.
Lösung:
Entladen Sie das NAT-Modul und das Connection-Tracking-Modul von iptables.
Beispiel:
# lsmod | grep ip iptable_filter 3072 0 iptable_nat 22060 0 ip_conntrack 32560 1 iptable_nat ip_tables 17280 2 iptable_filter,iptable_nat ipv6 236800 19 # rmmod iptable_nat # rmmod ip_conntrack
Entfernen Sie die Module in der Reihenfolge, in der sie verwendet werden. Ein Modul kann nur dann entfernt werden, wenn die Referenzanzahl (letzte Spalte der lsmod-Ausgabe) null ist. Falls Sie in iptables Regeln konfiguriert haben, müssen Sie diese entfernen. Beispiel: iptables -t nat -F
Das Modul iptable_nat verwendet ip_conntrack. Sie müssen demzufolge erst das Modul iptable_nat und dann das Modul ip_conntrack entfernen.
Wenn Sie auf Windows-Systemen das Load-Balancer-Feature für hohe Verfügbarkeit ausführen, werden goScripts verwendet, um bei einer Funktionsübernahme die Cluster-IP-Adresse des aktiven Load Balancer zu konfigurieren und die Cluster-IP-Adresse des Ausweichsystems aus der Konfiguration zu entfernen. Wenn das goScript, das die Cluster-IP-Adresse auf der aktiven Maschine konfiguriert, vor dem goScript ausgeführt wird, das die Cluster-IP-Adresse der Ausweichmaschine aus der Konfiguration entfernt, kann es zu Problemen kommen. Unter Umständen erscheint ein Dialogfenster mit einer Nachricht, dass das System einen IP-Adressenkonflikt festgestellt hat. Wenn Sie den Befehl ipconfig \all ausführen, kann auch eine IP-Adresse 0.0.0.0 auf der Maschine angezeigt werden.
Lösung:
Setzen Sie den folgenden Befehl ab, um die Cluster-IP-Adresse der primären Maschine manuell aus der Konfiguration zu entfernen:
dscontrol executor unconfigure Cluster-IP-Adresse
Dieser Befehl entfernt die Adresse 0.0.0.0 aus dem Windows-IP-Stack.
Nachdem der Partner für hohe Verfügbarkeit die Cluster-IP-Adresse abgegeben hat, setzen Sie den folgenden Befehl ab, um die Cluster-IP-Adresse erneut hinzuzufügen:
dscontrol executor configure Cluster-IP-Adresse
Überprüfen Sie nach dem Absetzen dieses Befehls erneut die Cluster-IP-Adressen im Windows-IP-Stack. Setzen Sie dazu folgenden Befehl ab:
ipconfig /all
Unter Linux kann iptables den Lastausgleich für den Datenverkehr stören und muss auf der Dispatcher-Maschine inaktiviert werden.
Setzen Sie den folgenden Befehl ab, um festzustellen, ob iptables geladen werden:
lsmod | grep ip_tables
Die Ausgabe dieses Befehls kann so ähnlich wie die folgende aussehen:
ip_tables 22400 3 iptable_mangle,iptable_nat,iptable_filter
Setzen Sie für jede in der Ausgabe aufgelistete iptable den folgenden Befehl ab, um die Regeln für die Tabellen anzuzeigen:
iptables -t <Kurzname> -L
Beispiel:
iptables -t mangle -L iptables -t nat -L iptables -t filter -L
Wenn die Tabelle iptable_nat geladen ist, muss sie entladen werden. Da iptable_nat von iptable_conntrack abhängig ist, muss iptable_conntrack ebenfalls entfernt werden. Setzen Sie zum Entladen dieser beiden iptables den folgenden Befehl ab:
rmmod iptable_nat iptable_conntrack
Bei der Produktinstallation von Load Balancer wird auch eine Java-Dateigruppe installiert. Die Produktinstallation umfasst mehrere Pakete, die nicht auf derselben Maschine installiert werden müssen. Dazu gehören unter anderem das Paket mit Metric Server, das Administrationspaket und das Basispaket. Alle diese Codepakete, die auf gesonderten Maschinen installiert werden können, erfordern eine Java-Dateigruppe. Deshalb wird zusammen mit jedem dieser Pakete eine Java-Dateigruppe installiert. Werden die Pakete auf derselben Maschine installiert, ist jede dieser Dateigruppen Eigner der Java-Dateigruppe. Wenn Sie die zweite und dritte Java-Dateigruppe installieren, empfangen Sie eine Warnung, dass noch eine weitere Dateigruppe Eigner der Java-Dateigruppe ist.
Wenn Sie Code mit den nativen Installationsmethoden installieren (unter AIX beispielsweise mit installp), sollten Sie diese Warnung ignorieren.
Während der Installation von Load Balancer wird auch eine Java-Dateigruppe installiert. Load Balancer ist die einzige Anwendung, die die zusammen mit dem Produkt installierte Java-Version verwendet. Sie sollten diese Version der Java-Dateigruppe nicht selbst aktualisieren. Falls ein Problem auftritt, das ein Upgrade der Java-Dateigruppe erforderlich macht, sollten Sie es dem IBM Service melden, damit für die im Lieferumfang von Load Balancer enthaltene Java-Dateigruppe eine offizielle Fixversion mit einem Upgrade bereitgestellt werden kann.
Unter dem Betriebssystem Microsoft Windows können persistente Verbindungen bei der Übernahme für hohe Verfügbarkeit unterbrochen werden. Dieses Problem tritt nur auf, wenn Sie einen kollokierten Server haben, der die Weiterleitungsmethode MAC verwendet.
Wenn die Cluster-IP-Adresse gelöscht wird (über die Ethernet- oder die Loopback-Schnittstelle), werden alle Verbindungen an dieser IP-Adresse freigegeben. Wenn das Betriebssystem ein Paket in einer Verbindung empfängt, die freigegeben wurde, sendet es eine RST-Antwort an den Client zurück, und die Verbindung wird beendet.
Wenn die Unterbrechung von Verbindungen während der Übernahme für hohe Verfügbarkeit nicht tolerierbar ist, dürfen Sie unter dem Betriebssystem Windows keinen kollokierten Server verwenden, wenn Sie die Weiterleitungsmethode MAC verwenden.
Dieses Problem ist auf eine Einschränkung des Edge-Installationsprogramms unter dem 32-Bit-Betriebssystem Linux für zSeries zurückzuführen.
Sie können dieses Problem umgehen, indem Sie unter dem 32-Bit-Betriebssystem Linux für zSeries eine manuelle Installation durchführen. Weitere Informationen finden Sie im Abschnitt Installation auf Linux-Systemen.
Dieses Problem ist auf eine Einschränkung des Edge-Installationsprogramms unter dem Betriebssystem Linux zurückzuführen.
Wenn Sie WebSphere Edge Server unter dem Betriebssystem Linux deinstallieren möchten, müssen Sie das Produkt manuell deinstallieren. Zum Deinstallieren des vollständigen Produkts geben Sie den Befehl rpm -e "rpm -qa | grep ibmlb" ein.
Zum Deinstallieren eines einzelnen Pakets geben Sie den Befehl rpm -e <Paketname> ein. Die Paketnamen sind im Abschnitt Installation auf Linux-Systemen aufgelistet. Sie müssen die Pakete in der umgekehrten Reihenfolge, in der sie installiert wurden, deinstallieren.
Dieses Problem kann auftreten, wenn eine andere Anwendung einen der Ports benutzt, die von CBR verwendet werden. Weitere Informationen finden Sie im Abschnitt Portnummern für CBR überprüfen.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Diese Definition kann Fehler verursachen, wenn eine der Verwaltungskonsolen auf derselben Maschine als Firewall oder über eine Firewall ausgeführt wird. Wird beispielsweise Load Balancer auf derselben Maschine als Firewall ausgeführt, können beim Absetzen von cbrcontrol-Befehlen Fehler wie der folgende angezeigt werden: Fehler: Server antwortet nicht.
Sie können diesen Fehler vermeiden, indem Sie die cbrserver-Scriptdatei editieren und den von RMI für die Firewall (oder eine andere Anwendung) verwendeten Port festlegen. Ändern Sie die Zeile LB_RMISERVERPORT=11199 in LB_RMISERVERPORT=Ihr_Port. Ihr_Port ist ein anderer Port.
Starten Sie anschließend erneut cbrserver und öffnen Sie den Datenverkehr für die Ports 11099, 10004, 11199 und 11100 oder für den Port, den Sie für die Hostadresse, an der die Verwaltungskonsole ausgeführt wird, ausgewählt 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.
Auf Solaris-Systemen 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 zur Konfiguration dieser Datei finden Sie unter ***.
Wenn der URL nicht funktioniert, kann dies an einem Syntax- oder Konfigurationsfehler liegen. Überprüfen Sie bei diesem Problem Folgendes:
Wenn Sie auf der Windows-Plattform eine Matrox-AGP-Karte verwenden, kann es in der grafischen Benutzerschnittstelle von Load Balancer zu unerwartetem Verhalten kommen. Beim Klicken mit der Maus kann ein Block etwa von der Größe des Mauszeigers beschädigt werden und zur Umkehrung von Hervorhebungen oder zur Verschiebung von Abbildungen führen. Bei älteren Matrox-Karten wurde dieses Verhalten nicht beobachtet. Für Matrox-AGP-Karten gibt es keine bekannte Korrektur.
Wenn Sie Load Balancer mit der fernen Webverwaltung konfigurieren, dürfen Sie nicht die Größe des Netscape-Browserfensters ändern, in dem die Load-Balancer-GUI angezeigt wird. Das heißt, Sie dürfen das Fenster nicht minimieren, maximieren, wiederherstellen usw. Da Netscape bei jeder Größenänderung des Browserfensters die Seite neu lädt, kommt es zu einer Trennung der Hostverbindung, die nach einer solchen Änderung demzufolge neu hergestellt werden muss. Wenn Sie die ferne Webverwaltung auf einer Windows-Plattform ausführen, verwenden Sie Internet Explorer.
Unter Windows können im Fenster mit der Eingabeaufforderung einige nationale Sonderzeichen der Zeichensatzfamilie Latin-1 beschädigt angezeigt werden. Der Buchstabe "a" mit Tilde kann beispielsweise als Pi-Symbol erscheinen. Zum Korrigieren dieses Fehlers müssen Sie die Schriftarteigenschaften für das Fenster mit der Eingabeaufforderung ändern. Gehen Sie zum Ändern der Schriftart wie folgt vor:
Einige Installationen von HP-UX 11i sind so vorkonfiguriert, dass nur 64 Threads pro Prozess zulässig sind. Manche Load-Balancer-Konfigurationen erfordern jedoch mehr Threads. Setzen Sie die Anzahl der Threads pro Prozess auf HP-UX-Systemen auf mindestens 256. Verwenden Sie zum Erhöhen dieses Wertes das Dienstprogramm "sam", und definieren Sie den Kernel-Parameter "max_thread_proc" neu. Bei einer erwarteten starken Auslastung, müssen Sie "max_thread_proc" möglicherweise auf einen noch höheren Wert als 256 setzen.
Führen Sie zum Erhöhen von max_thread_proc die Schritte auf Seite *** aus.
Wenn Sie Ihren Adapter in einer Load-Balancer-Maschine konfigurieren, müssen Sie für eine fehlerfreie Ausführung der Advisor-Funktion sicherstellen, dass die beiden folgenden Einstellungen richtig definiert sind:
Anweisungen für das Konfigurieren dieser Einstellung finden Sie auf Seite ***.
Wenn Sie auf der Windows-Plattform einen Adapter mit mehreren IP-Adressen konfigurieren, muss die IP-Adresse, die mit dem Hostnamen verbunden werden soll, als erste Adresse in der Registrierungsdatenbank konfiguriert werden.
Da Load Balancer in vielen Instanzen (z. B. lbkeys create) von InetAddress.getLocalHost() abhängig ist, können mehrere IP-Adressen, die per Aliasname an einen Adapter gebunden sind, zu Fehlern führen. Zur Vermeidung dieses Problems sollten die IP-Adressen, in die der Hostname aufgelöst werden soll, als erste Adressen in der Registrierungsdatenbank aufgelistet sein.
Die Schritte für das Konfigurieren des Hostnamens als ersten Eintrag in der Registrierungsdatenbank sind auf Seite *** beschrieben.
Dieses Problem kann auftreten, wenn eine andere Anwendung einen der Ports benutzt, die von Site Selector verwendet werden. Weitere Informationen finden Sie im Abschnitt Portnummern für Site Selector überprüfen.
Symptom: Site Selector gewichtet von Solaris-Clients eingehende Anforderungen nicht nach der Round-Robin-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: Inaktivieren Sie den Namensserver-Cache-Dämon auf der Solaris-Maschine.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Diese Definition kann Fehler verursachen, wenn eine der Verwaltungskonsolen auf derselben Maschine als Firewall oder über eine Firewall ausgeführt wird. Wird beispielsweise Load Balancer auf derselben Maschine als Firewall ausgeführt, können beim Absetzen von sscontrol-Befehlen Fehler wie der folgende angezeigt werden: Fehler: Server antwortet nicht.
Sie können diesen Fehler vermeiden, indem Sie die ssserver-Scriptdatei editieren und den von RMI für die Firewall (oder eine andere Anwendung) verwendeten Port festlegen. Ändern Sie die Zeile LB_RMISERVERPORT=10199 to LB_RMISERVERPORT=Ihr_Port. Ihr_Port ist ein anderer Port.
Starten Sie anschließend erneut ssserver und öffnen Sie den Datenverkehr für die Ports 12099, 10004, 12199 und 12100 oder für den Port, den Sie für die Hostadresse, an der die Verwaltungskonsole ausgeführt wird, ausgewählt haben.
Site Selector muss an einem DNS teilhaben können. Alle zur Konfiguration gehörenden Maschinen sollten ebenfalls an diesem System teilhaben. Auf Windows-Systemen muss nicht immer der konfigurierte Hostname im DNS enthalten sein. Site Selector wird nur ordnungsgemäß gestartet, wenn der Hostname 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 Fehlerinformationen.
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 Antwort 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 nicht von der Adresse, an die der Client seine Anfrage gesendet hat. Einige Clientanwendungen akzeptieren nur Antworten, die sie von der Adresse empfangen, an die sie die Anfrage gesendet haben. Das erweckt den Anschein, als würde die Namensauflösung nicht funktionieren.
Wenn Sie auf der Windows-Plattform eine Matrox-AGP-Karte verwenden, kann es in der grafischen Benutzerschnittstelle von Load Balancer zu unerwartetem Verhalten kommen. Beim Klicken mit der Maus kann ein Block etwa von der Größe des Mauszeigers beschädigt werden und zur Umkehrung von Hervorhebungen oder zur Verschiebung von Abbildungen führen. Bei älteren Matrox-Karten wurde dieses Verhalten nicht beobachtet. Für Matrox-AGP-Karten gibt es keine bekannte Korrektur.
Wenn Sie Load Balancer mit der fernen Webverwaltung konfigurieren, dürfen Sie nicht die Größe des Netscape-Browserfensters ändern, in dem die Load-Balancer-GUI angezeigt wird. Das heißt, Sie dürfen das Fenster nicht minimieren, maximieren, wiederherstellen usw. Da Netscape bei jeder Größenänderung des Browserfensters die Seite neu lädt, kommt es zu einer Trennung der Hostverbindung, die nach einer solchen Änderung demzufolge neu hergestellt werden muss. Wenn Sie die ferne Webverwaltung auf einer Windows-Plattform ausführen, verwenden Sie Internet Explorer.
Unter Windows können im Fenster mit der Eingabeaufforderung einige nationale Sonderzeichen der Zeichensatzfamilie Latin-1 beschädigt angezeigt werden. Der Buchstabe "a" mit Tilde kann beispielsweise als Pi-Symbol erscheinen. Zum Korrigieren dieses Fehlers müssen Sie die Schriftarteigenschaften für das Fenster mit der Eingabeaufforderung ändern. Gehen Sie zum Ändern der Schriftart wie folgt vor:
Einige Installationen von HP-UX 11i sind so vorkonfiguriert, dass nur 64 Threads pro Prozess zulässig sind. Manche Load-Balancer-Konfigurationen erfordern jedoch mehr Threads. Setzen Sie die Anzahl der Threads pro Prozess auf HP-UX-Systemen auf mindestens 256. Verwenden Sie zum Erhöhen dieses Wertes das Dienstprogramm "sam", und definieren Sie den Kernel-Parameter "max_thread_proc" neu. Bei einer erwarteten starken Auslastung, müssen Sie "max_thread_proc" möglicherweise auf einen noch höheren Wert als 256 setzen.
Führen Sie zum Erhöhen von max_thread_proc die Schritte auf Seite *** aus.
Wenn Sie Ihren Adapter in einer Load-Balancer-Maschine konfigurieren, müssen Sie für eine fehlerfreie Ausführung der Advisor-Funktion sicherstellen, dass die beiden folgenden Einstellungen richtig definiert sind:
Anweisungen für das Konfigurieren dieser Einstellung finden Sie auf Seite ***.
Dieser Fehler kann auftreten, wenn eine andere Anwendung einen Port verwendet, der vom ccoserver von Cisco CSS Controller verwendet wird. Weitere Informationen finden Sie im Abschnitt Portnummern für Cisco CSS Controller überprüfen.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Diese Definition kann Fehler verursachen, wenn eine der Verwaltungskonsolen auf derselben Maschine als Firewall oder über eine Firewall ausgeführt wird. Wird beispielsweise Load Balancer auf derselben Maschine als Firewall ausgeführt, können beim Absetzen von ccocontrol-Befehlen Fehler wie der folgende angezeigt werden: Fehler: Server antwortet nicht.
Sie können diesen Fehler vermeiden, indem Sie die ccoserver-Scriptdatei editieren und den von RMI für die Firewall (oder eine andere Anwendung) verwendeten Port festlegen. Ändern Sie die Zeile CCO_RMISERVERPORT=14199 in CCO_RMISERVERPORT=Ihr_Port. Ihr_Port ist ein anderer Port.
Starten Sie anschließend erneut ccoserver und öffnen Sie den Datenverkehr für die Ports 13099, 10004, 13199 und 13100 oder für den Port, den Sie für die Hostadresse, an der die Verwaltungskonsole ausgeführt wird, ausgewählt haben.
Dieses Problem kann auftreten, wenn eine gültige Produktlizenz fehlt. Wenn Sie versuchen, ccoserver zu starten, empfangen Sie die folgende Nachricht:
Die Lizenz ist abgelaufen. IBM Ansprechpartner oder autorisierten IBM Händler kontaktieren.
Sie können dieses Problem wie folgt lösen:
Wenn Sie auf der Windows-Plattform eine Matrox-AGP-Karte verwenden, kann es in der grafischen Benutzerschnittstelle von Load Balancer zu unerwartetem Verhalten kommen. Beim Klicken mit der Maus kann ein Block etwa von der Größe des Mauszeigers beschädigt werden und zur Umkehrung von Hervorhebungen oder zur Verschiebung von Abbildungen führen. Bei älteren Matrox-Karten wurde dieses Verhalten nicht beobachtet. Für Matrox-AGP-Karten gibt es keine bekannte Korrektur.
Beim Hinzufügen eines Consultant kann es aufgrund falscher Konfigurationseinstellungen zu einem Verbindungsfehler kommen. Beheben Sie diesen Fehler wie folgt:
Beheben Sie diesen Fehler wie folgt:
Erhöhen Sie die Protokollstufe für den Consultant, und wiederholen Sie den Befehl. Sollte er erneut scheitern, suchen Sie im Protokoll nach SNMP-Zeitlimitüberschreitungen oder SNMP-Übertragungsfehlern.
Wenn Sie Load Balancer mit der fernen Webverwaltung konfigurieren, dürfen Sie nicht die Größe des Netscape-Browserfensters ändern, in dem die Load-Balancer-GUI angezeigt wird. Das heißt, Sie dürfen das Fenster nicht minimieren, maximieren, wiederherstellen usw. Da Netscape bei jeder Größenänderung des Browserfensters die Seite neu lädt, kommt es zu einer Trennung der Hostverbindung, die nach einer solchen Änderung demzufolge neu hergestellt werden muss. Wenn Sie die ferne Webverwaltung auf einer Windows-Plattform ausführen, verwenden Sie Internet Explorer.
Unter Windows können im Fenster mit der Eingabeaufforderung einige nationale Sonderzeichen der Zeichensatzfamilie Latin-1 beschädigt angezeigt werden. Der Buchstabe "a" mit Tilde kann beispielsweise als Pi-Symbol erscheinen. Zum Korrigieren dieses Fehlers müssen Sie die Schriftarteigenschaften für das Fenster mit der Eingabeaufforderung ändern. Gehen Sie zum Ändern der Schriftart wie folgt vor:
Einige Installationen von HP-UX 11i sind so vorkonfiguriert, dass nur 64 Threads pro Prozess zulässig sind. Manche Load-Balancer-Konfigurationen erfordern jedoch mehr Threads. Setzen Sie die Anzahl der Threads pro Prozess auf HP-UX-Systemen auf mindestens 256. Verwenden Sie zum Erhöhen dieses Wertes das Dienstprogramm "sam", und definieren Sie den Kernel-Parameter "max_thread_proc" neu. Bei einer erwarteten starken Auslastung, müssen Sie "max_thread_proc" möglicherweise auf einen noch höheren Wert als 256 setzen.
Führen Sie zum Erhöhen von max_thread_proc die Schritte auf Seite *** aus.
Dieser Fehler kann auftreten, wenn eine andere Anwendung einen Port verwendet, der vom nalserver von Nortel Alteon Controller verwendet wird. Weitere Informationen finden Sie im Abschnitt Portnummern für Nortel Alteon Controller überprüfen.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Diese Definition kann Fehler verursachen, wenn eine der Verwaltungskonsolen auf derselben Maschine als Firewall oder über eine Firewall ausgeführt wird. Wird beispielsweise Load Balancer auf derselben Maschine als Firewall ausgeführt, können beim Absetzen von nalcontrol-Befehlen Fehler wie der folgende angezeigt werden: Fehler: Server antwortet nicht.
Sie können diesen Fehler vermeiden, indem Sie die nalserver-Scriptdatei editieren und den von RMI für die Firewall (oder eine andere Anwendung) verwendeten Port festlegen. Ändern Sie die Zeile NAL_RMISERVERPORT=14199 in NAL_RMISERVERPORT=Ihr_Port. Ihr_Port ist ein anderer Port.
Starten Sie anschließend erneut nalserver und öffnen Sie den Datenverkehr für die Ports 14099, 10004, 14199 und 14100 oder für den Port, den Sie für die Hostadresse, an der die Verwaltungskonsole ausgeführt wird, ausgewählt haben.
Dieses Problem kann auftreten, wenn eine gültige Produktlizenz fehlt. Wenn Sie versuchen, nalserver zu starten, empfangen Sie die folgende Nachricht:
Die Lizenz ist abgelaufen. IBM Ansprechpartner oder autorisierten IBM Händler kontaktieren.
Sie können dieses Problem wie folgt lösen:
Wenn Sie auf der Windows-Plattform eine Matrox-AGP-Karte verwenden, kann es in der grafischen Benutzerschnittstelle von Load Balancer zu unerwartetem Verhalten kommen. Beim Klicken mit der Maus kann ein Block etwa von der Größe des Mauszeigers beschädigt werden und zur Umkehrung von Hervorhebungen oder zur Verschiebung von Abbildungen führen. Bei älteren Matrox-Karten wurde dieses Verhalten nicht beobachtet. Für Matrox-AGP-Karten gibt es keine bekannte Korrektur.
Wenn Sie Load Balancer mit der fernen Webverwaltung konfigurieren, dürfen Sie nicht die Größe des Netscape-Browserfensters ändern, in dem die Load-Balancer-GUI angezeigt wird. Das heißt, Sie dürfen das Fenster nicht minimieren, maximieren, wiederherstellen usw. Da Netscape bei jeder Größenänderung des Browserfensters die Seite neu lädt, kommt es zu einer Trennung der Hostverbindung, die nach einer solchen Änderung demzufolge neu hergestellt werden muss. Wenn Sie die ferne Webverwaltung auf einer Windows-Plattform ausführen, verwenden Sie Internet Explorer.
Beim Hinzufügen eines Consultant kann es aufgrund falscher Konfigurationseinstellungen zu einem Verbindungsfehler kommen. Beheben Sie diesen Fehler wie folgt:
Beheben Sie diesen Fehler wie folgt:
Erhöhen Sie die Protokollstufe für den Consultant, und wiederholen Sie den Befehl. Sollte er erneut scheitern, suchen Sie im Protokoll nach SNMP-Zeitlimitüberschreitungen oder SNMP-Übertragungsfehlern.
Unter Windows können im Fenster mit der Eingabeaufforderung einige nationale Sonderzeichen der Zeichensatzfamilie Latin-1 beschädigt angezeigt werden. Der Buchstabe "a" mit Tilde kann beispielsweise als Pi-Symbol erscheinen. Zum Korrigieren dieses Fehlers müssen Sie die Schriftarteigenschaften für das Fenster mit der Eingabeaufforderung ändern. Gehen Sie zum Ändern der Schriftart wie folgt vor:
Einige Installationen von HP-UX 11i sind so vorkonfiguriert, dass nur 64 Threads pro Prozess zulässig sind. Manche Load-Balancer-Konfigurationen erfordern jedoch mehr Threads. Setzen Sie die Anzahl der Threads pro Prozess auf HP-UX-Systemen auf mindestens 256. Verwenden Sie zum Erhöhen dieses Wertes das Dienstprogramm "sam", und definieren Sie den Kernel-Parameter "max_thread_proc" neu. Bei einer erwarteten starken Auslastung, müssen Sie "max_thread_proc" möglicherweise auf einen noch höheren Wert als 256 setzen.
Führen Sie zum Erhöhen von max_thread_proc die Schritte auf Seite *** aus.
Für Metric Server auf der Windows-Plattform müssen Sie für benutzerdefinierte Metriken den vollständigen Namen angeben. An Stelle von benutzermetrik müssten Sie beispielsweise benutzermetrik.bat angeben. Der Name benutzermetrik ist in der Befehlszeile gültig, funktioniert jedoch nicht bei Ausführung in einer Laufzeitumgebung. Wenn Sie nicht den vollständigen Namen der Metrik verwenden, empfangen Sie eine Ausnahme des Typs IOException von Metric Server. 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 Load Balancer meldet, kann es mehrere Gründe geben. Überprüfen Sie Folgendes, um die Ursache zu ermitteln:
Sie können dieses Problem auch lösen, indem Sie im Script "metricserver" den Hostnamen mit der Java-Eigenschaft java.rmi.server.hostname angeben.
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:
Wenn Metric Server auf einer AIX-Multiprozessorplattform (4.3.3, 5.1 32-Bit oder 64-Bit) mit starker Belastung ausgeführt wird, kann die Ausgabe des Befehls "ps -vg" beschädigt sein. Beispiel:
55742 - A 88:19 42 18014398509449680 6396 32768 22 36 2.8 1.0 java -Xms
Das Feld SIZE und/oder RSS des Befehls "ps" kann die Verwendung einer zu großen Speicherkapazität anzeigen.
Dies ist ein bekanntes Problem des AIX-Kernels. Dieses Problem wird mit APAR IY33804 behoben. Sie können die Korrektur von der AIX-Unterstützungssite http://techsupport.services.ibm.com/server/fixes, herunterladen oder sich an Ihr lokales AIX-Unterstützungsteam wenden.
Wenn Site Selector (erste Stufe) in einer zweistufigen Load-Balancer-Konfiguration die Last auf ein Paar von Dispatcher-Partnern mit hoher Verfügbarkeit (zweite Stufe) verteilt, sind für die Komponente Metric Server bestimmte Konfigurationsschritte erforderlich. Sie müssen Metric Server für die Empfangsbereitschaft an einer neuen IP-Adresse konfigurieren, die speziell für Metric Server bestimmt ist. Auf den beiden Dispatcher-Maschinen mit hoher Verfügbarkeit ist Metric Server nur auf dem aktiven Dispatcher aktiv.
Führen Sie die folgenden Schritte aus, um diese Konfiguration korrekt zu definieren:
Beispiel:
ifconfig en0 delete 9.27.23.61 ifconfig lo0 alias 9.27.23.61 netmask 255.255.255.0 route add 9.27.23.61 127.0.0.1 metricserver stop # Inaktivität von maximal 60 Sekunden oder bis zum Stoppen von Metric Server let loopcount=0 while [[ "$loopcount" -lt "60" && "ps -ef | grep AgentStop| grep -c -v gr ep" -eq "1"]] do sleep 1 let loopcount=$loopcount+1 done route delete 9.27.23.61
Beispiel:
call netsh interface ip delete address "LAN-Verbindung" addr=9.27.23.61 call netsh interface ip add address "LAN-Verbindung 2" addr=9.27.2.3.61 mask = 255.255.255.0 sleep 3 metricserver stop
Die Scripts metricserver, cpuload und memload können bei Ausführung auf Solaris-Maschinen mit mehreren CPUs unerwünschte Konsolnachrichten erzeugen. Dieses Verhalten ist auf die Verwendung des VMSTAT-Systembefehls zum Abrufen von CPU- und Speicherstatistiken vom Kernel zurückzuführen. Einige von VMSTAT zurückgegebene Nachrichten geben an, dass sich der Status des Kernels geändert hat. Die Scripts können diese Nachrichten nicht bearbeiten, was zu unnötigen Konsolnachrichten von der Shell führt.
Beispiele für solche Konsolnachrichten:
/opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=: syntax error /opt/ibm/edge/lb/ms/script/memload[31]: LOAD=4*100/0: divide by zero /opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=659664+: more tokens expected
Sie können diese Nachrichten ignorieren.
Dieses Problem kann auftreten, wenn die Integrität der Schlüsseldateien bei der Übertragung zum Client verloren geht.
Wenn Sie Ihre Schlüsseldateien von der Load-Balancer-Maschine mit FTP zum Back-End-Server übertragen, müssen Sie den Befehl put oder get im Binärmodus verwenden, um die Schlüsseldateien auf den FTP-Server zu stellen oder vom FTP-Server abzurufen.
Dieser Teil enthält Referenzinformationen zu den Befehlen aller Komponenten von Load Balancer. Zu diesem Teil gehören die folgenden Kapitel:
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.
>>-required_keyword--------------------------------------------><
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.
>>-+-required_parameter_1-+------------------------------------>< '-required_parameter_2-'
Optionale Werte: Optionale Schlüsselwörter und Variablen stehen unter dem Hauptpfad.
>>-+---------+------------------------------------------------->< '-keyword-'
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------------------------------------------------><
Dieses Kapitel beschreibt die Verwendung der dscontrol-Befehle von Dispatcher. Sie können dieses Kapitel auch als Befehlsreferenz für CBR verwenden.
Frühere Versionen dieses Produkts liefen unter dem Namen Network Dispatcher. In diesen Versionen war der Dispatcher-Steuerbefehl "ndcontrol". Jetzt ist der Dispatcher-Steuerbefehl dscontrol. Stellen Sie sicher, dass alle bisherigen Scriptdateien so aktualisiert werden, dass dscontrol (und nicht ndcontrol) zum Konfigurieren von Dispatcher verwendet wird.
CBR verwendet eine Untergruppe der in dieser Befehlsreferenz aufgeführten Dispatcher-Befehle. Wenn Sie diese Syntaxdiagramme für CBR verwenden, ersetzen Sie dscontrol durch cbrcontrol. Weitere Informationen finden Sie im Abschnitt Konfigurationsunterschiede bei CBR und Dispatcher.
Nachfolgend sind die in diesem Kapitel beschriebenen Befehle aufgelistet:
Sie können eine Minimalversion der Parameter für den Befehl "dscontrol" 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 dscontrol he f an Stelle von dscontrol help file angeben.
Wenn Sie die Befehlszeilenschnittstelle starten möchten, setzen Sie den Befehl dscontrol ab, um die Eingabeaufforderung dscontrol aufzurufen.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
Die Werte der Befehlsparameter müssen in englischen Zeichen eingegeben werden. Die einzige Ausnahme hiervon bilden Hostnamen (die in den Befehlen "cluster", "server" und "highavailability" verwendet werden) und (die in Dateibefehlen verwendeten) Dateinamen.
Die Befehlszeilenschnittstelle von CBR umfasst einen Teil der Befehlszeilenschnittstelle von Dispatcher. Verwenden Sie für CBR an Stelle des Befehls "dscontrol" den Befehl cbrcontrol, um die Komponente zu konfigurieren.
Nachfolgend sind einige der Befehle aufgelistet, die in CBR ignoriert werden.
>>-dscontrol--advisor--+-connecttimeout--Name--+-Port--+--Zeitlimit_in_Sekunden-+->< | '-Cluster:Port-' | +-interval--Name--+-Port---------+--Sekunden-------------+ | '-Cluster:Port-' | +-list---------------------------------------------------+ +-loglevel--Name--+-Port---------+--Stufe----------------+ | '-Cluster:Port-' | +-logsize--Name--+-Port---------+--+-unlimited---------+-+ | '-Cluster:Port-' '-Anzahl_Datensätze-' | +-receivetimeout--Name--+-Port--+--Zeitlimit_in_Sekunden-+ | '-Cluster:Port-' | +-report--Name--+-Port---------+-------------------------+ | '-Cluster:Port-' | +-retries--Name--+-Port--+--Anzahl_Wiederholungen--------+ | '-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-'
Weitere Informationen zu den von Load Balancer bereitgestellten Advisor-Funktionen finden Sie im Abschnitt Liste der Advisor-Funktionen.
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 finden Sie im Abschnitt Angepasste (anpassbare) Advisor-Funktion erstellen.
Der Cluster kann als Adresse im IP-Adressenformat 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 |
---|---|---|
cachingproxy | HTTP (über Caching Proxy) | 80 |
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | private | 12345 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 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 im Abschnitt Pfade für die Protokolldatei ändern. Die Standardprotokolldateien für cluster- oder sitespezifische Advisor-Funktionen werden mit der Clusteradresse erstellt, z. B. http_127.40.50.1_80.log.
Beispiele
dscontrol advisor start http 127.40.50.1:80
dscontrol advisor start http 88
dscontrol advisor stop http 127.40.50.1:80
dscontrol advisor connecttimeout http 80 30
dscontrol advisor connecttimeout http 127.40.50.1:80 20
dscontrol advisor interval ftp 21 6
dscontrol advisor listDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
--------------------------------------- | ADVISOR | CLUSTER:PORT | ZEITLIMIT| --------------------------------------- | http |127.40.50.1:80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
dscontrol advisor loglevel http 80 0
dscontrol advisor logsize ftp 21 5000
dscontrol advisor receivetimeout http 80 60
dscontrol advisor report ftp 21Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Advisor-Bericht: --------------- Advisor-Name ............. Ftp Portnummer ,.............. 21 Clusteradresse .......... 9.67.131.18 Serveradresse ............ 9.67.129.230 Last ..................... 8 Clusteradresse .......... 9.67.131.18 Serveradresse ............ 9.67.131.215 Last ..................... -1
dscontrol 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 Anzahl Wiederholungen ................... 0
dscontrol advisor timeout ftp 21 5
dscontrol 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
>>-dscontrol--binlog--+-start----------------------+----------->< +-stop-----------------------+ +-set--+-retention--Stunden--+-+ | '-interval--Sekunden-' | '-status---------------------'
>>-dscontrol--cluster--+-add--Cluster+c2+...--+----------------------------------------+-+->< | +-address--Adresse-----------------------+ | | +-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+...--+-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-----------------' | +-remove--Cluster-------------------------------------------------+ +-report--Cluster-------------------------------------------------+ '-status--Cluster-------------------------------------------------'
Generell können Sie einen Doppelpunkt (:) als Platzhalter verwenden. Die einzige Ausnahme hiervon bildet der Befehl "dscontrol cluster add". Der Befehl dscontrol 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 die Partnermaschine gestartet wurden, und ist die wechselseitige hohe Verfü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 finden Sie im Abschnitt Wechselseitige hohe Verfügbarkeit.
Beispiele
dscontrol cluster add 130.40.52.153
dscontrol cluster remove 130.40.52.153
dscontrol cluster set 9.6.54.12 proportions 60 35 5 0
dscontrol cluster add 0.0.0.0
dscontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
dscontrol cluster status 9.67.131.167Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Clusterstatus: ---------------- Cluster ................................. 9.67.131.167 Adresse ................................. 9.67.131.167 Anzahl Zielports ........................ 3 Standardhaltezeit ....................... 0 Strd.-Zeitlimit für Inaktivität ......... 30 Strd.-Gewichtungsgrenze für Port ........ 20 Max. Anzahl Ports ....................... 8 Strd.-Portprotokoll ..................... tcp/udp Strd. max. Anzahl Server ................ 32 Proportion für aktive Verbindungen ...... 0.5 Proportion für neue Verbindungen ........ 0.5 Portsspezifische Proportion .............. 0 Proportion für Systemmetrik ............. 0 Gemeinsame Bandbreite (KBytes) .......... 0 Adresse des primären Hosts .............. 9.67.131.167
>>-dscontrol--executor--+-report-----------------------------------------------------------+->< +-set--+-nfa--IP-Adresse----------------------+--------------------+ | +-maxclusters--Größe-------------------+ | | +-maxports--Größe----------------------+ | | +-fintimeout--FIN-Zeitlimit------------+ | | +-hatimeout--Zeit----------------------+ | | +-hasynctimeout--Zeit------------------+ | | +-maxservers--Größe--------------------+ | | +-mss--Größe---------------------------+ | | +-staletimeout--Inaktivitätszeitlimit--+ | | +-stickytime--Zeit---------------------+ | | +-clientgateway--Adresse---------------+ | | +-weightbound--Wertigkeit--------------+ | | +-porttype--Typ------------------------+ | | +-wideportnumber--Port-----------------+ | | '-sharedbandwidth--Größe---------------' | +-configure--Schnittstellenadresse+i2+...--+---------------------+-+ | '-Schnittstellenname--Netzmaske-' | +-unconfigure--Schnittstellenadresse-------------------------------+ +-start------------------------------------------------------------+ +-status-----------------------------------------------------------+ '-stop-------------------------------------------------------------'
Mit diesem Zeitgeber wird sichergestellt, dass die primäre Maschine und die Ausweichmaschine versuchen, ihre Daten zu synchronisieren. Wenn jedoch zu viele Verbindungen vorhanden sind und die aktive Maschine weiterhin einer signifikante Belastung durch ankommenden Datenverkehr ausgesetzt ist, wird die Synchronisation möglicherweise nicht vor Ablauf des Zeitgebers beendet. Load Balancer würde in einem solchen Fall endlos versuchen, eine Synchronisation durchzuführen, ohne dass die Daten der beiden Maschinen tatsächlich synchronisiert werden. Setzen Sie hasynctimeout in dieser Situation auf einen höheren Wert als den Standardwert, damit die Maschinen genug Zeit haben, Informationen über vorhandene Verbindungen auszutauschen. Zum Setzen dieses Zeitgebers müssen Sie den Befehl "hasynctimeout" nach dem Befehl dscontrol executor start, aber vor den Befehlen für hohe Verfügbarkeit (dscontrol highavailability) absetzen.
Beispiele
dscontrol executor status Executor-Status: ---------------- Non-Forwarding Address .............. 9.67.131.151 Client-Gateway-Adresse .............. 0.0.0.0 FIN-Zeitlimit ....................... 60 WAN-Portnummer ...................... 0 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 Inaktivität ..... 300 Standardhaltezeit ................... 0 Strd.-Gewichtungsgrenze ............. 20 Standardporttyp ..................... tcp/udp
dscontrol executor set nfa 130.40.52.167
dscontrol executor set maxclusters 4096
dscontrol executor start
dscontrol executor stop
>>-dscontrol--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.
Beispiele
dscontrol file delete Datei3 Datei (Datei3) wurde gelöscht.
dscontrol file newload file1.sv Datei "file1.sv" wurde in den Dispatcher geladen.
dscontrol file appendload file2.sv Datei "file2.sv" wurde an die aktuelle Konfiguration angehängt und geladen.
dscontrol file report FILE REPORT: file1.save file2.sv file3
dscontrol file save file3 Die Konfiguration wurde in Datei "file3" gesichert.
>>-dscontrol--help--+-advisor----------+----------------------->< +-binlog-----------+ +-cluster----------+ +-executor---------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-host-------------+ +-logstatus--------+ +-manager----------+ +-metric-----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-set--------------+ +-status-----------+ '-subagent---------'
Beispiele
dscontrol 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 binlog - Hilfe zum Befehl binlog 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 logstatus - Hilfe zum Befehl logstatus subagent - Hilfe zum Befehl subagent highavailability - Hilfe zum Befehl highavailabilityIn <> eingeschlossene Parameter sind Variablen.
fintimeout <Clusteradresse>|all <Zeit> - Zeitlimit für beendete inaktive Verbindungen ändern (Verwenden Sie "all", um alle Cluster zu ändern)
>>-dscontrol--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 gegenseitiger hoher Verfügbarkeit (Rolle jeder Dispatcher-Maschine ist beide):
Anmerkungen:
Beispiele
dscontrol 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 Überwachungssignalstatus: ----------------- Anzahl ........................ 1 Quelle/Ziel ................... 9.67.131.151/9.67.134.223 Erreichbarkeitsstatus: -------------------- Anzahl ............... 1 Adresse .............. 9.67.131.1 erreichbar
dscontrol highavailability backup add primary auto 80
dscontrol 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
dscontrol highavailability takeover
>>-dscontrol--host:--ferner_Host-------------------------------><
dscontrol host:ferner_Host
Nachdem dieser Befehl in der Eingabeaufforderung ausgegeben wurde, geben Sie einen beliebigen gültigen Befehl "dscontrol" ein, der für die ferne Load-Balancer-Maschine abgesetzt werden soll.
>>-dscontrol--logstatus----------------------------------------><
Beispiele
Geben Sie den folgenden Befehl ein, um den Protokollstatus anzuzeigen:
dscontrol logstatus
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Protokollstatus von Dispatcher: ------------------------------ Name der Protokolldatei ........... C:\PROGRA~1\IBM\edge\lb\servers\logs\dispatcher\server.log Protokollstufe .................... 1 Maximale Protokollgröße (Bytes) ... 1048576
>>-dscontrol--manager--+-interval--Sekunden----------------------+->< +-loglevel--Stufe------------------------+ +-logsize--+-unlimited-+-----------------+ | '-Bytes-----' | +-metric set--+-loglevel--Stufe--------+-+ | '-logsize--+-unlimited-+-' | | '-Bytes-----' | +-quiesce--Server--+-----+---------------+ | '-now-' | +-reach set--+-interval--Sekunden------+--+ | +-loglevel--Stufe--------+ | | '-logsize--+-unlimited-+-' | | '-Bytes-----' | +-refresh--Aktualisierungszyklus-----------------+ +-report--+----------------+-------------+ | '-Cluster+c2+...-' | +-restart--Nachricht-----------------------+ +-sensitivity--Wertigkeit--------------------+ +-smoothing--Glättungsfaktor-------------+ +-start--+-----------------------+-------+ | '-Protokolldatei--Metrikport-' | +-status---------------------------------+ +-stop-----------------------------------+ +-unquiesce--server----------------------+ '-version--------------------------------'
Wenn Sie die Serverpartitionierung verwenden, geben Sie den eindeutigen Namen des logischen Servers an. Weitere Informationen finden Sie im Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Die Standarddatei ist im Verzeichnis logs installiert. Weitere Informationen finden Sie in Anhang C. Beispielkonfigurationsdateien. Wollen Sie das Verzeichnis ändern, in dem die Protokolldateien gespeichert werden, lesen Sie die Informationen im Abschnitt Pfade für die Protokolldatei ändern.
Beispiele
dscontrol manager interval 5
dscontrol manager loglevel 0
dscontrol manager logsize 1000000
dscontrol manager quiesce 130.40.52.153
dscontrol manager refresh 3
dscontrol manager reportDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
-------------------------------------------------------------------- | SERVER | IP-ADRESSE | STATUS | -------------------------------------------------------------------- | mach14.dmz.com | 10.6.21.14 | AKTIV | | mach15.dmz.com | 10.6.21.15 | AKTIV | -------------------------------------------------------------------- ----------------------------- |LEGENDE ZUM MANAGERBERICHT | ----------------------------- | AKTV | Aktive Verbindungen| | NEUV | Neue Verbindungen | | SYS | Systemmetrik | |JETZT | Aktuelle Gewichtung| | NEU | Neue Gewichtung | |GWT | Gewichtung | | VERB | Verbindungen | ----------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | GEWICHTUNG | AKTIV | NEU | PORT | SYS | | PORT: 21 | JETZT NEU | 49 % | 50 % | 1 % | 0 % | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | -1 | 0 | | mach15.dmz.com | 10 10 | 0 | 0 | -1 | 0 | ------------------------------------------------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | GEWICHTUNG | AKTIV | NEU | PORT | SYS | | PORT: 80 | JETZT NEU | 49 % | 50 % | 1 % | 0 % | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | 23 | 0 | | mach15.dmz.com | 9 9 | 0 | 0 | 30 | 0 | ------------------------------------------------------------------- --------------------------------------------------- | ADVISOR | CLUSTER:PORT | ZEITLIMIT| --------------------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------------------
dscontrol 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
dscontrol manager sensitivity 10
dscontrol manager smoothing 2.0
dscontrol manager start ndmgr.log
dscontrol manager statusDieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Managerstatus: =============== Metrikport ............................................. 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 ........................ 2 Erreichbarkeit - Protokollstufe ......................... 1 Erreichbarkeit - Max. Protokollgröße (Bytes) ............ unlimited Erreichbarkeit - Aktualisierungsintervall (Sekunden) .... 7 Name der Protokolldatei für Metriküberwachung ........... MetricMonitor.log Protokollstufe für Metriküberwachung .................... 1 Maximale Protokollgröße für Metriküberwachung (Bytes) ... 1048576
dscontrol manager stop
dscontrol manager quiesce 130.40.52.153 now
dscontrol manager quiesce 130.40.52.153
dscontrol manager unquiesce 130.40.52.153
dscontrol manager version
>>-dscontrol--metric--+-add--Cluster+c2+...+cN:Metrik+Metrik1+...+MetrikN--------------+->< +-remove--Cluster+c2+...+cN:Metrik+Metrik1+...+MetrikN-----------+ +-proportions--Cluster+c2+...+cN Proportion1 Prop2 Prop3...PropN-+ '-status--Cluster+c2+...+cN:Metrik+Metrik1+...+MetrikN-----------'
Beispiele
dscontrol metric add Site1:Metrik1
dscontrol metric proportions Site1 0 100
dscontrol metric status Site1:Metrik1Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Metrikstatus: ------------ Cluster ....................... 10.10.10.20 Metrikname .................... Metrik1 Metrikproportion .............. 50 Server .................... plm3 Metrikdaten ............... -1
>>-dscontrol--port--+-add--Cluster:Port--+----------------------+-+->< | +-crossport--anderer_Port-+ | | +-maxservers--Größe-----+ | | +-stickymask--Wert----+ | | +-stickytime--Zeit-----+ | | +-method--Typ---------+ | | +-staletimeout--Wert--+ | | +-weightbound--Wertigkeit--+| | +-porttype--Typ-------+ | | +-protocol--Typ-------+ | | '-reset--Wert---------' | +-set--Cluster:Port--+-crossport--anderer_Port-+-+ | +-maxservers--Größe-----+ | | +-stickymask--Wert----+ | | +-stickytime--Zeit-----+ | | +-staletimeout--Wert--+ | | +-weightbound--Wertigkeit--+| | +-porttype--Typ-------+ | | +-maxhalfopen--Wert---+ | | '-reset--Wert---------' | +-remove--Cluster:Port------------------------+ +-report--Cluster:Port------------------------+ +-status--Cluster:Port------------------------+ '-halfopenaddressreport--Cluster:Port---------'
Wenn Sie die Crossport-Affinität aufheben möchten, setzen Sie den Wert für "crossport" auf seine eigene Portnummer zurück. Weitere Informationen zum Feature "Crossport-Affinität" finden Sie im Abschnitt Crossport-Affinität.
Für die Dispatcher-Komponente:
Für die Komponente CBR: 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.
Anmerkungen:
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
dscontrol port add 130.40.52.153:80+23
dscontrol port set 130.40.52.153:0
dscontrol port set 130.40.52.153:80 weightbound 10
dscontrol port set 130.40.52.153:80+23 stickytime 60
dscontrol port set 130.40.52.153:80 crossport 23
dscontrol port remove 130.40.52.153:23
dscontrol port status 9.67.131.153:80Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Portstatus: ------------ Portnummer ......................... 80 Cluster ............................ 9.67.131.153 Zeitlimit für Inaktivität .......... 300 Gewichtungsgrenze .................. 20 Max. Anzahl Server ................. 32 Haltezeit .......................... 0 Porttyp ............................ tcp/udp Crossport-Affinität ................ 80 StickyBits der Maske ............... 32 Max. Anz. halb geöffneter Verb. ... 0 TCP-Rücksetzanforderungen senden ... no
dscontrol port report 9.62.130.157:80Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Portbericht: ------------ Clusteradresse ....................... 9.62.130.157 Portnummer ........................... 80 Anzahl Server ........................ 5 Max. Servergewichtung ................ 10 Summe aktiver Verbindungen ........... 55 Verbindungen pro Sekunde ............. 12 KBytes pro Sekunde ................... 298 Anzahl halbgeöffneter Verbindungen ... 0 Gesendete TCP-Rücksetzanforderungen .. 0 Weiterleitungsmethode ................ MAC-gestützte Weiterleitung
dscontrol 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
>>-dscontrol--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--unterer_Grenzwert--endrange--oberer_Grenzwert-+ +-priority--Stufe-----------------+ +-pattern--Muster-----------------+ +-tos--Wert-----------------------+ +-stickytime--Zeit----------------+ +-affinity--Affinitätstyp---------+ +-cookiename--Wert----------------+ +-evaluate--Stufe-----------------+ '-sharelevel--Stufe---------------'
Weitere Informationen 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 Load Balancer 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 finden Sie in den Abschnitten Aktive Cookie-Affinität, Passive Cookie-Affinität und URI-Affinität.
Weitere Informationen finden Sie im Abschnitt Passive Cookie-Affinität.
Für Regeln des Typs connection können Sie auch eine Auswertungsoption (upserversonrule) angeben. Durch Angabe von upserversonrule können Sie sicherstellen, dass die übrigen Server, die dieser Regel unterliegen, nicht überlastet werden, wenn einige Server der Gruppe inaktiv sind.
Wenn Sie die Serverpartitionierung verwenden, geben Sie den eindeutigen Namen des logischen Servers an. Weitere Informationen finden Sie im Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Beispiele
dscontrol rule add 9.37.67.100:80:trule type true priority 100
dscontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
dscontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 dscontrol rule useserver cluster1:80:timerule server05
dscontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
dscontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
dscontrol cluster set 9.67.131.153 sharedbandwidth 200 dscontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-dscontrol--server--+-add--Cluster:Port:Server--+-------------------------+-+->< | +-address--Adresse--------+ | | +-collocated--Wert--------+ | | +-sticky--Wert------------+ | | +-weight--Wert------------+ | | +-fixedweight--Wert-------+ | | +-cookievalue--Wert-------+ | | +-mapport--Portwert-------+ | | +-protocol--Wert----------+ | | +-router--Adresse---------+ | | +-returnaddress--Adresse--+ | | +-advisorrequest--String--+ | | '-advisorresponse--String-' | +-set--Cluster:Port:Server--+-collocated--Wert--------+-+ | +-sticky--Wert------------+ | | +-weight--Wert------------+ | | +-fixedweight--Wert-------+ | | +-cookievalue--Wert-------+ | | +-protocol--Wert----------+ | | +-router--Adresse---------+ | | +-advisorrequest--String--+ | | '-advisorresponse--String-' | +-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 dscontrol server add mit dem Serverparameter address verwenden. Weitere Informationen finden Sie im Abschnitt Serverpartitionierung - Konfigurieren logischer Server für einen physischen Server (IP-Adresse).
Wenn Sie einen Server mit dem Befehl "server down" offline setzen und der stickytime-Wert für diesen Server ungleich null ist, werden vorhandene Clients weiter von diesem Server bedient, bis das stickytime-Intervall abläuft. Der Server wird erst nach Ablauf des stickytime-Invervalls heruntergefahren.
Beispiele
dscontrol server add 130.40.52.153:80:27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 sticky no
dscontrol server down 130.40.52.153:80:27.65.89.42
dscontrol server remove ::27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
dscontrol server set 130.40.52.153:80:27.65.89.42 weight 10
dscontrol server up 130.40.52.153:80:27.65.89.42
dscontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
dscontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/1.0\""
dscontrol server status 9.67.131.167:80:9.67.143.154Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Serverstatus: -------------- Server ......................... 9.67.143.154 Portnummer ..................... 80 Cluster ........................ 9.67.131.167 Clusteradresse ................. 9.67.131.167 Stillgelegt .................... N Server aktiv ................... J Gewichtung ..................... 10 Feste Gewichtung ............... N Haltemodus für Regel ........... J Ferner Server .................. N Netz-Router-Adresse ............ 0.0.0.0 Zusammengelegt ................. N Advisor-Anforderung ............ HEAD / HTTP/1.0 Advisor-Antwort ................ Cookie-Wert .................... nicht anwendbar Klon-ID ........................ nicht anwendbar
>>-dscontrol--set--+-loglevel--Stufe--------+------------------>< '-logsize--+-unlimited-+-' '-Größe------'
>>-dscontrol--status-------------------------------------------><
Beispiele
dscontrol statusDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
Executor wurde gestartet. Manager wurde gestartet. ---------------------------------------- | ADVISOR | CLUSTER:PORT | ZEITLIMIT| ---------------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | ----------------------------------------
>>-dscontrol--subagent--+-loglevel--Stufe---------------------------+->< +-logsize--+-Bytes-----+--------------------+ | '-unlimited-' | +-report------------------------------------+ +-start--+--------------------------------+-+ | '-Community-Name--Protokolldatei-' | +-status------------------------------------+ +-stop--------------------------------------+ '-version-----------------------------------'
Für Windows-Plattformen: Es wird der Name der Benutzergemeinschaft für das Betriebssystem verwendet.
Beispiele
dscontrol subagent start bigguy bigguy.log
Dieses Kapitel beschreibt die Verwendung der folgenden sscontrol-Befehle für sscontrol:
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 an Stelle von sscontrol help file angeben.
>>-sscontrol--advisor--+-connecttimeout--Name--+-Port----------+--Sekunden------+->< | '-Sitename:Port-' | +-interval--Name--+-Port----------+--Sekunden------------+ | '-Sitename:Port-' | +-list---------------------------------------------------+ +-loglevel--Name--+-Port----------+--Stufe---------------+ | '-Sitename:Port-' | +-logsize--Name--+-Port---------+--+-Größe | unlimited-+-+ | '-Sitename:Port-' '-Bytes------------' | +-receivetimeout--Name--+-Port----------+--Sekunden------+ | '-Sitename:Port-' | +-report--Name--+-Port----------+------------------------+ | '-Sitename:Port-' | +-retries--Name--+-Port----------+--Wiederholungen-------+ | '-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 zutreffend | benutzerdefiniert |
db2 | private | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
PING | PING | nicht zutreffend |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
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 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 mysite:80 0
sscontrol advisor logsize ftp mysite: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 Portnummer ............... 80 Sitename ................. mySite 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 Anzahl Wiederholungen ................... 0
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.
Beispiele
sscontrol file delete Datei3 Datei (Datei3) wurde gelöscht.
sscontrol file newload file1.sv Datei "file1.sv" wurde in den Dispatcher geladen.
sscontrol file appendload file2.sv Datei "file2.sv" wurde an die aktuelle Konfiguration angehängt und geladen.
sscontrol file report FILE REPORT: file1.save file2.sv file3
sscontrol file save file3 Die Konfiguration wurde in Datei "file3" gesichert.
>>-sscontrol--help--+-advisor----+----------------------------->< +-file-------+ +-help-------+ +-host-------+ +-logstatus--+ +-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 status logstatus - Hilfe zum Befehl logstatusIn < > eingeschlossene Parameter sind Variablen.
logsize <Bytezahl | unlimited> - Maximale Anzahl Bytes für Protokolldatei festlegen
>>-sscontrol--logstatus----------------------------------------><
>>-sscontrol--manager--+-interval--Sekunden---------------------+->< +-loglevel--Stufe------------------------+ +-logsize--+-unlimited-+-----------------+ | '-Bytes-----' | +-metric set--+-loglevel--Stufe--------+-+ | '-logsize--+-unlimited-+-' | | '-Bytes-----' | +-reach set--+-interval--Sekunden-----+--+ | +-loglevel--Stufe--------+ | | '-logsize--+-unlimited-+-' | | '-Bytes-----' | +-report--Sitename+sn2+...+snN-----------+ +-restart--Nachricht---------------------+ +-sensitivity--Wertigkeit----------------+ +-smoothing--Glättungsfaktor-------------+ +-start--+----------------------+--------+ | '-Protokolldatei--Metrikport-' | +-status---------------------------------+ +-stop-----------------------------------+ '-version--------------------------------'
Die Standarddatei ist im Verzeichnis logs installiert. Weitere Informationen finden Sie in Anhang C. Beispielkonfigurationsdateien. Wollen Sie das Verzeichnis ändern, in dem die Protokolldateien gespeichert werden, lesen Sie die Informationen im Abschnitt 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 | -------------------------- ------------------------------------------------------------------------ | mySite | 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:
Managerstatus: ============= Metrikport ............................................. 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:Metrik+Metrik1+...+MetricN--------------+->< +-remove--Sitename+sn2+...+snN:Metrik+Metrik1+...+MetrikN-----------+ +-proportions--Sitename+sn2+...+snN:Proportion1 Prop2 Prop3...PropN-+ '-status--Sitename+sn2+...+snN Metrik+Metrik1+...+MetrikN-----------'
Beispiele
sscontrol metric add Site1:Metrik1
sscontrol metric proportions Site1 0 100
sscontrol metric status Site1:Metrik1Dieser Befehl erzeugt eine Ausgabe, die ungefähr wie folgt aussieht:
Metrikstatus: ------------ Sitename ..................... Site1 Metrikname .................... Metrik1 Metrikproportion .............. 50 Server ......... 9.37.56.100 Metrikdaten .... -1
>>-sscontrol--nameserver--+-start--+----------------------+-+-->< | '-bindaddress--Adresse-' | +-stop----------------------------+ '-status--------------------------'
>>-sscontrol--rule--+-add--Sitename+sn2+...+snN:Regel+r2+...+rN--type--Wert--| value |--| Optionen |-+->< +-dropserver--Sitename+sn2+...+snN:Regel+r2+...+rN--Server+s2+...+snN---------+ +-remove--Sitename+sn2+...+snN:Regel+r2+...+rN--------------------------------+ +-set--Sitename+sn2+...+snN:Regel+r2+...+rN--| value |--| opts |--------------+ +-status--Sitename+sn2+...+snN:Regel+r2+...+rN--------------------------------+ '-useserver--Sitename+sn2+...+snN:Regel+r2+...+rN--Server+s2+...+snN----------' Optionen: |--+---------------------------------+--------------------------| +-beginrange--unterer_Grenzwert--endrange--oberer_Grenzwert-+ +-priority--Wert-----------------+ '-metricname--Wert---------------'
Beispiele
sscontrol rule add Sitename:Regelname type true priority 100
sscontrol rule add sitename:rulename type ip b 9.0.0.0 e 9.255.255.255
sscontrol rule add sitename:rulename type time beginrange 11 endrange 14 sscontrol rule useserver sitename:rulename server05
>>-sscontrol--server--+-add--Sitename+sn2+...+snN:Server+s2+...+sN--+------------------------+-+->< | +-metricaddress--Adresse-+ | | '-weight--Wert-----------' | +-down--Sitename+sn2+...+snN:Server+s2+...+sN----------------------------+ +-remove--Sitename+sn2+...+snN:Server+s2+...+sN--------------------------+ +-set--Sitename+sn2+...+snN:Server+s2+...+sN--+------------------------+-+ | +-metricaddress--Adresse-+ | | '-weight--Wert-----------' | +-status--Sitename+sn2+...+snN:Server+s2+...+sN--------------------------+ '-up--Sitename+sn2+...+snN:Server+s2+...+sN------------------------------'
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------'
>>-sscontrol--sitename--+-add--Sitename+sn2+...+snN--+----------------------------------------+-+->< | +-cachelife--Wert------------------------+ | | +-networkproximity--yes | no-------------+ | | +-proportions--CPU--Speicher-Port-Metrik-+ | | +-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-Metrik-+ | | +-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 mySite networkproximity yes
sscontrol sitename set mySite cachelife 1900000
sscontrol sitename set mySite proximitypercentage 45
sscontrol sitename set mySite waitforallresponses no
sscontrol sitename set mySite ttl 7
sscontrol sitename set mySite proportions 50 48 1 1
sscontrol sitename remove 130.40.52.153
sscontrol sitename status mySiteDie Ausgabe dieses Befehls sieht etwa wie folgt aus:
Status des Sitenamens: --------------- Sitename ........................... mySite 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 | -----------------------------------------
Dieses Kapitel beschreibt die Verwendung der folgenden ccocontrol-Befehle für Cisco CSS Controller:
Für die Parameter des Befehls "ccocontrol" können Sie die abgekürzte Form verwenden. 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 ccocontrol he f an Stelle von ccocontrol help file angeben.
Geben Sie zum Aufrufen der ccocontrol-Eingabeaufforderung ccocontrol ein.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
>>-ccocontrol--consultant--+-add--scID--address--swIPAddr--community--CommName-+->< +-binarylog--scID+scID2...--+-report-------------+--+ | +-set--+-Intervall-+-+ | | | '-Sicherung-' | | | +-start--------------+ | | '-stop---------------' | +-remove--scID+scID2...-----------------------------+ +-report--scID+scID2...-----------------------------+ +-set--+-loglevel--Stufe----------------+-----------+ | +-logsize--+-Größe------+---------+ | | | '-unlimited-' | | | +-sensitivity-Wertigkeit_Prozent-+ | | '-sleeptime--Sek-----------------' | +-start--scID+scID2...------------------------------+ '-stop--scID+scID2...-------------------------------'
0 = Keine
1 = Minimal
2 = Grundlegend
3 = Mäßig
4 = Erweitert
5 = Ausführlich
Beispiele
ccocontrol consultant add SC1 address 9.37.50.17 community Comm1
ccocontrol consultant binarylog SC1 start
ccocontrol consultant report SC1
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Die Verbindung zwischen Consultant SC1 und Switch 9.37.50.1:Comm1 wurde hergestellt Der Consultant wurde gestartet. Ruhezeit = 7 Sensitivität = 5 Protokollstufe = 5 Protokollgröße = 1.048.576 Eignerangaben: Eignerangaben EA1
ccocontrol consultant set SC1 sleeptime 10
ccocontrol consultant start SC1
>>-ccocontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--Stufe--------+ '-logsize--+-Größe-----+-' '-unlimited-'
0 = Keine
1 = Minimal
2 = Grundlegend
3 = Mäßig
4 = Erweitert
5 = Ausführlich
Beispiele
ccocontrol controller report
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Controller-Bericht: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Protokollstufe . . . . . 1 Protokollgröße . . . . . 1048576 Konfigurationsdatei . . . config1.xml Consultants: Consultant consult1 - Gestartet
ccocontrol set loglevel 0
ccocontrol controller set logsize 1000000
>>-ccocontrol--file--+-delete--Dateiname---------+------------->< +-load--Dateiname-----------+ +-report--------------------+ '-save--Dateiname--+------+-' '-force-'
(Standard-)Installationsverzeichnis: C:\Programme\ibm\edge\lb\servers\configurations\cco
Beispiele
ccocontrol file delete file1
ccocontrol file load config2
ccocontrol file report
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
DATEIBERICHT: ------------ file1.xml file2.xml file3.xml
ccocontrol file save config2
>>-ccocontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metriccollector--+ +-ownercontent-----+ '-service----------'
Beispiele
ccocontrol help
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Die folgenden Befehle sind verfügbar: controller - für den Controller consultant - für Switch-Consultants file - für Konfigurationsdateien help - für Hilfetexte highavailability - für Hochverfügbarkeit metriccollector - für die Metrik-Erfassungsprogramme ownerContent - für Eignerangaben service - für Services
>>-ccocontrol--highavailability--+-add--+-address--Adresse---------------+-+->< | +-partneraddress--Partneradresse-+ | | +-port--Port---------------------+ | | '-role--+-primary---+------------' | | '-secondary-' | +-dropreach--Adresse----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--Zeit-----+---------+ | +-takeoverinterval--Zeit-+ | | +-loglevel--Stufe--------+ | | '-logsize--+-Größe-----+-' | | '-unlimited-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--Adresse-----------------------'
0 = Keine
1 = Minimal
2 = Grundlegend
3 = Mäßig
4 = Erweitert
5 = Ausführlich
ccocontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
ccocontrol highavailability usereach 9.37.50.9
ccocontrol highavailability dropreach 9.37.50.9
ccocontrol highavailability start manual
ccocontrol highavailability report
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Hochverfügbarkeitsstatus: ------------------------- Knoten . . . . . . . . . . . . . . . . primär Knotenadresse . . . . . . . . . . . . 9.37.50.17 Port . . . . . . . . . . . . . . . . . 12345 Partneradresse . . . . . . . . . . . . 9.37.50.14 Wiederherstellungsstrategie . . . . . manuell Intervall für Überwachungssignal . . . 500 Übernahmeintervall . . . . . . . . . . 2000 Status . . . . . . . . . . . . . . . . inaktiv Teilstatus . . . . . . . . . . . . . . nicht synchronisiert Erreichbarkeitsstatus: Knoten/Partner --------------------------------------- Keine Erreichbarkeitsziele konfiguriert.
>>-ccocontrol--metriccollector--+-report--scID+scID2+...:mN+mN2...--------------------------+->< '-set--scID+scID2+...:mN+mN2...--+-timeoutconnect--Sek----+-' +-loglevel--Stufe--------+ +-logsize--+-Größe-----+-+ | '-unlimited-' | +-timeoutreceive--Sek----+ '-sleeptime--Sek---------'
0 = Keine
1 = Minimal
2 = Grundlegend
3 = Mäßig
4 = Erweitert
5 = Ausführlich
Beispiele
ccocontrol metriccollector report SC1:http
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
MetricCollector SC1:http Erfasste Metrik .................... http Protokollstufe ..................... 5 Protokollgröße ..................... 1048576 Ruhezeit in Sekunden ............... 7 Verbindungszeitlimit in Sekunden ... 21 Empfangszeitlimit in Sekunden ...... 21
ccocontrol metriccollector set SC1:http timeoutconnect 15 logsize unlimited
>>-ccocontrol--ownerContent--+-add--scID:ocN--ownername--oN--contentrule--cN------------------------------+->< +-metrics--scID+scID2...:ocN+ocN2...--mN--Bedeutung---mN2--i2----------------+ +-refresh--scID+scID2...:ocN+ocN2...-----------------------------------------+ +-remove--scID+scID2...:ocN+ocN2...------------------------------------------+ +-report--scID+scID2...:ocN+ocN2...------------------------------------------+ '-set--scID+scID2...:ocN+ocN2...----metric--mN--+------------------------+---' +-requeststring--String--+ +-responsestring--String-+ '-retry--Wiederholungen--'
Nachfolgend sehen Sie eine Liste gültiger Metriknamen mit den zugehörigen
Ports.
Advisor-Name | Protokoll | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (über Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10007 |
activeconn | nicht anwendbar | nicht anwendbar |
connrate | nicht anwendbar | nicht anwendbar |
cpuload | nicht anwendbar | nicht anwendbar |
memload | nicht anwendbar | nicht anwendbar |
Beispiele
ccocontrol ownerContent add SC1:EA1 ownername Eigner1 contentrule content1
ccocontrol ownerContent metrics SC1:EA1 activeconn 50 http 50
ccocontrol ownerContent report SC1:EA1
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
ownerContent SC1:EA1 Gewichtungsgrenze = 10 Metrik activeconn hat die Proportion 25 Antwortzeichenfolge... nicht anwendbar Anforderungszeichenfolge... nicht anwendbar Metrik http hat die Proportion 50 Antwortzeichenfolge... nicht anwendbar Anforderungszeichenfolge... nicht anwendbar Metrik connrate hat die Proportion 25 Antwortzeichenfolge... nicht anwendbar Anforderungszeichenfolge... nicht anwendbar Enthält Service t3 Enthält Service t2 Enthält Service t1
ccocontrol ownerContent set SC1:EA1 metric http requeststring getCookie
>>-ccocontrol--service--+-report--scID+scID2...:ocN+ocN2...:svc+svc2...---------------------------------+->< '---set--scID+scID2...:ocN+ocN2...:svc+svc2...--+---------------------------+---' +-fixedweight--+-Integer-+--+ | '-off-----' | +-requestsourceip--IPAd-----+ +-metricserveraddress--IPAd-+ '-metricserverport--portN---'
Beispiele
ccocontrol service report sc1:oc1:t1
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Service SC1:EA1:t1 hat die Gewichtung 10 Feste Gewichtung ist off IP der Anforderungsquelle ...... 9.27.24.156 Port der Anwendung ............. 80 Adresse des MetricServer ....... 1.0.0.1 Port des MetricServer .......... 10004 Metrik activeconn hat den Wert -99 Metrik http hat den Wert -99 Metrik connrate hat den Wert -99
ccocontrol service set SC1:EA1:t2 metricserveraddress 9.37.50.17
Dieses Kapitel beschreibt die Verwendung der folgenden nalcontrol-Befehle für Nortel Alteon Controller:
Für die Parameter des Befehls "nalcontrol" können Sie die abgekürzte Form verwenden. 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 nalcontrol he f an Stelle von nalcontrol help file angeben.
Geben Sie zum Aufrufen der nalcontrol-Eingabeaufforderung nalcontrol ein.
Sie können die Befehlszeilenschnittstelle verlassen, indem Sie den Befehl exit oder quit absetzen.
>>-nalcontrol--consultant--+-add--scID--address--swIPAddr--+---------------------------+-+->< | +-rcommunity--readCommName--+ | | '-wcommunity--writeCommName-' | +-binarylog--scID+scID2...--+-report------------------------+-+ | +-set--+-interval--Intervall--+-+ | | | '-retention--Sicherung-' | | | +-start-------------------------+ | | '-stop--------------------------' | +-remove--scID+scID2...---------------------------------------+ +-report--scID+scID2...---------------------------------------+ +-set--+--------------------------------+---------------------+ | +-loglevel--Stufe----------------+ | | +-logsize--+-Größe-----+---------+ | | | '-unlimited-' | | | +-sensitivity-Wertigkeit_Prozent-+ | | '-sleeptime--Sek-----------------' | +-start--scID+scID2...----------------------------------------+ '-stop--scID+scID2...-----------------------------------------'
0 = Keine
1 = Minimal
2 = Grundlegend
3 = Mäßig
4 = Erweitert
5 = Ausführlich
Beispiele
nalcontrol consultant add SC1 address 9.37.50.17
nalcontrol consultant binarylog SC1 start
nalcontrol consultant report SC1
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Consultant-ID: SC1 IP-Adresse des Switch: 9.37.50.1 Community mit Lesezugriff: public Community mit Schreibzugriff: private Der Consultant wurde gestartet. Ruhezeit = 7 Sensitivität = 5 Protokollstufe = 5 Protokollgröße = 1.048.576 Services: Service Svc1
nalcontrol consultant set SC1 sleeptime 10
nalcontrol consultant start sc1
>>-nalcontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--Stufe--------+ '-logsize--+-Größe------+-' '-unlimited-'
0 = Keine
1 = Minimal
2 = Grundlegend
3 = Mäßig
4 = Erweitert
5 = Ausführlich
Beispiele
nalcontrol controller report
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Controller-Bericht: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Protokollstufe . . . . . 1 Protokollgröße . . . . . 1048576 Konfigurationsdatei . . . config1.xml Consultants: Consultant consult1 -Started
nalcontrol set loglevel 0
nalcontrol controller set logsize 1000000
>>-nalcontrol--file--+-delete--Dateiname-+---------------------->< +-load--Dateiname---+ +-report-----------+ '-save--Dateiname---'
Allgemeiner Installationsverzeichnispfad -- C:\Programme\ibm\edge\lb\servers\configurations\nal
Nativer Installationsverzeichnispfad -- C:\Programme\ibm\lb\servers\configurations\nal
Beispiele
nalcontrol file delete file1
nalcontrol file load config2
nalcontrol file report
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
DATEIBERICHT: ------------ file1.xml file2.xml file3.xml
nalcontrol file save config2
>>-nalcontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metrinalllector--+ +-ownercontent-----+ '-service----------'
Beispiele
nalcontrol help
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Die folgenden Befehle sind verfügbar: controller - für den Controller consultant - für Switch-Consultants file - für Konfigurationsdateien help - für Hilfetexte highavailability - für Hochverfügbarkeit metriccollector - für die Metrik-Erfassungsprogramme server - für Server service - für Services
>>-nalcontrol--highavailability--+-add--+-address--Adresse---------------+-+->< | +-partneraddress--Partneradresse-+ | | +-port--Port---------------------+ | | '-role--+-primary---+------------' | | '-secondary-' | +-dropreach--Adresse----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--Zeit-----+---------+ | +-takeoverinterval--Zeit-+ | | +-loglevel--Stufe--------+ | | '-logsize--+-Größe------+-' | | '-unlimited-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--Adresse-----------------------'
0 = Keine
1 = Minimal
2 = Grundlegend
3 = Mäßig
4 = Erweitert
5 = Ausführlich
nalcontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
nalcontrol highavailability usereach 9.37.50.9
nalcontrol highavailability dropreach 9.37.50.9
nalcontrol highavailability start manual
nalcontrol highavailability report
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Hochverfügbarkeitsstatus: ------------------------- Knoten . . . . . . . . . . . . . . . . primär Knotenadresse . . . . . . . . . . . . 9.37.50.17 Port . . . . . . . . . . . . . . . . . 12345 Partneradresse . . . . . . . . . . . . 9.37.50.14 Wiederherstellungsstrategie . . . . . manuell Intervall für Überwachungssignal . . . 500 Übernahmeintervall . . . . . . . . . . 2000 Gestartet . . . . . . . . . . . . . . N Status . . . . . . . . . . . . . . . . inaktiv Teilstatus . . . . . . . . . . . . . . nicht synchronisiert Erreichbarkeitsstatus: Knoten/Partner ---------------------------------------
>>-nalcontrol--metricollector--+-report--scID+scID2+...:mN+mN2...--------------------------+->< '-set--scID+scID2+...:mN+mN2...--+-connecttimeout--Sek----+-' +-loglevel--Stufe--------+ +-logsize--+-Größe-----+-+ | '-unlimited-' | +-receivetimeout--Sek----+ '-sleeptime--Sek---------'
0 = Keine
1 = Minimal
2 = Grundlegend
3 = Mäßig
4 = Erweitert
5 = Ausführlich
Beispiele
nalcontrol metrinalllector report sc1:http
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Metrinalllector sc1:http Erfasste Metrik .................... http Protokollstufe ..................... 5 Protokollgröße ..................... 1048576 Ruhezeit in Sekunden ............... 7 Verbindungszeitlimit in Sekunden ... 21 Empfangszeitlimit in Sekunden ...... 21
nalcontrol metrinalllector set SC1:http connecttimeout 15 logsize unlimited
>>-nalcontrol--serer--+-report--scID+scID2...:svcID+svcID2...:serverID+svrID2...-----------------------------------+->< '---set--scID+scID2...:svcID+svcID2...:serverID+svrID2--+--------------------------------+---' +-fixedweight--+-Integer-+-------+ | '-off-----' | +-requestsourceip--IP-Adresse----+ +-metricserveraddress--IP-Adresse+ '-metricserverport--Portnummer---'
Beispiele
nalcontrol server report sc1:svc1:1
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Server SC1:Svc1:1 hat die Gewichtung -99 Feste Gewichtung ist off IP der Anforderungsquelle ...... 9.27.24.156 Port der Anwendung ............. 99 Adresse des MetricServer ....... 9.99.99.98 Port des MetricServer .......... 10004 Metrik activeconn hat den Wert -99 Metrik connrate hat den Wert -99
nalcontrol server set SC1:Svc1:2 metricserveraddress 9.37.50.17
>>-nalcontrol--service--+-add--scID+scID2...:serviceID+svcID2...--vsid--virSvrID--vport--virPortNum------+->< +-metrics--scID+scID2...:svcID+svcID2...--mN--Bedeutung--mCN2--i2----------------+ +-refresh--scID+scID2...:svcID+svcID2...-----------------------------------------+ +-remove--scID+scID2...:svcID+svcID2...------------------------------------------+ +-report--scID+scID2...:svcID+svcID2...------------------------------------------+ '-set--scID+scID2...:svcID+svcID2...----metric--mN----+-requeststring--String--+-' +-responsestring--String-+ '-retry--Wiederholungen--'
Nachfolgend sehen Sie eine Liste gültiger Metriknamen mit den zugehörigen
Ports.
Advisor-Name | Protokoll | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (über Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10007 |
activeconn | nicht anwendbar | nicht anwendbar |
connrate | nicht anwendbar | nicht anwendbar |
cpuload | nicht anwendbar | nicht anwendbar |
memload | nicht anwendbar | nicht anwendbar |
Beispiele
nalcontrol service add SC1:Svc1 vsid 1 vport 80
nalcontrol service metrics SC1:Svc1 activeconn 50 http 50
nalcontrol service report SC1:Svc1
Die Ausgabe dieses Befehls sieht etwa wie folgt aus:
Service SC1:Svc1 Gewichtungsgrenze = 48 Metrik activeconn hat die Proportion 50 Metrik connrate hat die Proportion 50 Enthält Server 4 Enthält Server 3 Enthält Server 2 Enthält Server 1
nalcontrol service set SC1:Svc1 metric http requeststring getLastErrorCode
Auf der grafischen Benutzerschnittstelle (GUI) von Load Balancer erscheint auf der linken Seite der Anzeige eine Baumstruktur mit Load Balancer als Ausgangsebene und Dispatcher, Content Based Routing (CBR), Site Selektor, Cisco CSS Controller und Nortel Alteon Controller als Komponenten.
Abbildung 41. GUI mit der erweiterten Anzeige der Baumstruktur für die Komponente Dispatcher
Abbildung 42. GUI mit der erweiterten Anzeige der Baumstruktur für die Komponente CBR
Abbildung 43. GUI mit der erweiterten Anzeige der Baumstruktur für die Komponente Site Selector
Alle Komponenten können auf der 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.
Wenn Sie einen Befehl über die grafische Benutzerschnittstelle ausführen möchten, gehen Sie wie folgt vor: Heben Sie in der GUI-Baumstruktur den Hostknoten hervor, und wählen Sie im Popup-Menü "Host" Befehl senden... aus. Geben Sie im Befehlseingabefeld den gewünschten Befehl ein, z. B. executor report. In einem Fenster sehen Sie die Ergebnisse und die Historie der in der aktuellen Sitzung ausgeführten Befehle.
Auf der rechten Seite der Anzeige erscheinen Registerkarten mit Statusanzeigen für das derzeit ausgewählte Element.
Falls Sie Hilfe benötigen, klicken Sie oben rechts im Load-Balancer-Fenster auf das Fragezeichen (?).
Dieser Anhang beschreibt die Syntax der Inhaltsregel (des Musters) für die Komponente CBR und die Weiterleitungsmethode "cbr" der Komponente Dispatcher 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 nur gültig, wenn Sie die cbrcontrol>>-Eingabeaufforderung oder eine Konfigurationsdatei verwenden:
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Wenn Sie Sonderzeichen verwenden und derselbe Befehl über die Eingabeaufforderung des Betriebssystems funktionieren soll, müssen Sie den vollständigen Befehl in doppelte Anführungszeichen setzen:
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*"
Fehlen die Anführungszeichen, könnte beim Speichern der Regel in CBR ein Teil des Musters abgeschnitten werden.
Nachfolgend finden Sie eine Zusammenstellung möglicher Szenarien und Beispiele für die Mustersyntax.
Szenario 1:
Zur Konfiguration für einen Clusternamen 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 Clientdaten 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 Load Balancer 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 Clientdaten werden auf Server3 und Server4 verteilt.
Szenario 2
Ein weiteres allgemeines Szenario ist die Steuerung unterschiedlicher interner Gruppen durch die Hauptwebsite. www.firma.com/software bezieht beispielsweise verschiedene Server und Inhalte aus dem Bereich www.firma.com/hardware ein. Da alle Anforderungen vom Root-Cluster www.company.com ausgehen, sind Inhaltsregeln 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:div1 type content pattern "uri=/software/*" priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2 >>rule uses cluster1:80:div2 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.company.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 empfiehlt es sich, die Regeln durch eine Regel zu ersetzen, die immer wahr ist (always true) und damit für alles gilt, was nicht unter die übrigen Regeln fällt. In Szenarios, 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 enthält Beispielkonfigurationsdateien für die Komponente Dispatcher von Load Balancer.
Die Beispieldateien finden Sie im Verzeichnis "...ibm/edge/lb/servers/samples/".
#!/bin/bash
#
# configuration.sample - Beispielkonfigurationsdatei für die
# Komponente Dispatcher
#
#
# Dieses Script muss von Root ausgeführt werden.
#
# iam=`wer bin ich`
# if [ "$iam" != "root" ]if [ "$iam" != "root" ]
# then
# echo "Sie müssen sich zum Ausführen dieses Scripts als Root anmelden"
# exit 2
# fi
#
# Starten Sie zunächst den Server
#
# dsserver start
# sleep 5
#
# Starten Sie dann den Executor.
#
# dscontrol executor start
#
# Der Dispatcher kann vor dem Löschen der Dispatcher-Software
# jederzeit mit den Befehlen "dscontrol executor stop" und
# "dsserver stop" zum Stoppen von Executor und Server entfernt
# werden.
#
# Der nächste Konfigurationsschritt für den Dispatcher ist das
# Festlegen der NFA und der Clusteradresse(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
# Clusteradresse(n) weiterleitet.
#
# Die CLUSTER-Adresse ist der Hostname (oder die IP-Adresse)
# zu dem (bzw. zu der) ferne Clients eine Verbindung herstellen.
#
# Hostnamen und IP-Adressen sind an jeder Stelle dieser
# Datei beliebig gegeneinander austauschbar.
#
# NFA=Hostname.Domäne.Name
# CLUSTER=www.IhreFirma.com
# echo "NFA wird geladen"
# dscontrol executor set nfa $NFA
#
# Der nächste Konfigurationsschritt für den Dispatcher ist
# das Erstellen eines Clusters. Der Dispatcher leitet an die
# Clusteradresse gesendete Anforderungen an die entsprechenden,
# für diesen Cluster definierten Servermaschinen weiter. Mit
# Dispatcher können Sie mehrere Clusteradressen konfigurieren
# und bedienen.
# Verwenden Sie für CLUSTER2, CLUSTER3 usw. eine ähnliche Konfiguration.
#
# echo "Erste Clusteradresse wird geladen"
# dscontrol 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"
# dscontrol 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 Hostnamen 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"
# dscontrol 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 Round-Robin-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 Managerproportionen
# auf das Einbeziehen von Advisor-Eingaben gesetzt sind) und es
# werden keine weiteren Anforderungen an den Server weitergeleitet.
# Der letzte Schritt beim Konfigurieren der Lastausgleichskomponenten
# ist das Festlegen der Managerproportionen. Der Manager aktualisiert
# die Wertigkeit der Server ausgehend von vier verschiedenen Ansätzen:
# 1. Anzahl aktiver Verbindungen auf jedem Server.
# 2. Anzahl neuer Verbindungen zu jedem Server.
# 3. Eingabe von den Advisor-Funktionen.
# 4. Eingabe von der System-Advisor-Funktion.
# Diese Proportionen müssen in der Summe 100 ergeben. Sie können
# die Managerproportionen beispielsweise wie folgt festlegen:
# dscontrol manager proportions 48 48 4 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 Managerproportionen auf 50 50 0 0 gesetzt.
#
# echo "Manager wird gestartet..."
# dscontrol manager start
# echo "FTP-Advisor-Funktion wird an Port 21 gestartet ..."
# dscontrol advisor start ftp 21
# echo "HTTP-Advisor-Funktion wird an Port 80 gestartet ..."
# dscontrol advisor start http 80
# echo "Telnet-Advisor-Funktion wird an Port 23 gestartet ..."
# dscontrol advisor start telnet 23
# echo "SMTP-Advisor-Funktion wird an Port 25 gestartet ..."
# dscontrol advisor start smtp 25
# echo "POP3-Advisor-Funktion wird an Port 110 gestartet ..."
# dscontrol advisor start pop3 110
# echo "NNTP-Advisor-Funktion wird an Port 119 gestartet ..."
# dscontrol advisor start nntp 119
# echo "SSL-Advisor-Funktion wird an Port 443 gestartet ..."
# dscontrol advisor start ssl 443
#
# echo "Managerproportionen werden festgelegt..."
# dscontrol manager proportions 58 40 2 0
#
# Der letzte Konfigurationsschritt für die Dispatcher-Maschine
# ist das Festlegen eines Aliasnamens auf der 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.
# dscontrol executor configure $CLUSTER
# Wenn die Clusteradresse 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:
# dscontrol executor 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.
# dscontrol manager loglevel 1
# dscontrol manager logsize 1048576
# dscontrol manager sensitivity 5
# dscontrol manager interval 2
# dscontrol manager refresh 2
#
# dscontrol advisor interval ftp 21 5
# dscontrol advisor loglevel ftp 21 1
# dscontrol advisor logsize ftp 21 1048576
# dscontrol advisor timeout ftp 21 unlimited
# dscontrol advisor interval telnet 23 5
# dscontrol advisor loglevel telnet 23 1
# dscontrol advisor logsize telnet 23 1048576
# dscontrol advisor timeout telnet 23 unlimited
# dscontrol advisor interval smtp 25 5
# dscontrol advisor loglevel smtp 25 1
# dscontrol advisor logsize smtp 25 1048576
# dscontrol advisor timeout smtp 25 unlimited
# dscontrol advisor interval http 80 5
# dscontrol advisor loglevel http 80 1
# dscontrol advisor logsize http 80 1048576
# dscontrol advisor timeout http 80 unlimited
# dscontrol advisor interval pop3 110 5
# dscontrol advisor loglevel pop3 110 1
# dscontrol advisor logsize pop3 110 1048576
# dscontrol advisor timeout pop3 110 unlimited
# dscontrol advisor interval nntp 119 5
# dscontrol advisor loglevel nntp 119 1
# dscontrol advisor logsize nntp 119 1048576
# dscontrol advisor timeout nntp 119 unlimited
# dscontrol advisor interval ssl 443 5
# dscontrol advisor loglevel ssl 443 1
# dscontrol advisor logsize ssl 443 1048576
# dscontrol advisor timeout ssl 443 unlimited
#
Die folgende Load-Balancer-Beispielkonfigurationsdatei mit dem Namen configuration.cmd.sample ist für die Verwendung auf Windows-Maschinen bestimmt.
@echo off rem configuration.cmd.sample - Beispielkonfigurationsdatei für die rem Komponente Dispatcher. rem rem dsserver muss im Fenster "Dienste" gestartet werden. rem rem rem Starten Sie dann den Executor. rem rem call dscontrol executor start rem rem Der nächste Konfigurationsschritt für den Dispatcher rem ist das Festlegen der NFA und der Clusteradresse(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 Clusteradresse(n) weiterleitet. rem rem Die CLUSTER-Adresse ist der Hostname (oder die IP-Adresse) rem zu dem (bzw. zu der) ferne Clients eine Verbindung herstellen. rem rem Hostnamen und IP-Adressen sind an jeder Stelle dieser rem Datei beliebig gegeneinander austauschbar. rem NFA=[Non-Forwarding Address] rem CLUSTER=[Clustername] rem rem set NFA=Hostname.Domäne.Name rem set CLUSTER=www.IhreFirma.com rem echo "NFA wird geladen" rem call dscontrol executor set nfa %NFA% rem rem Die folgenden Befehle aktivieren die Standardwerte. rem Verwenden Sie diese Befehle zum Ändern der Standardwerte. rem call dscontrol executor set fintimeout 30 rem rem Der nächste Konfigurationsschritt für den Dispatcher ist rem das Erstellen eines Clusters. Der Dispatcher leitet an die rem Clusteradresse gesendete Anforderungen an die entsprechenden, rem für diesen Cluster definierten Servermaschinen weiter. Mit rem Dispatcher können Sie mehrere Clusteradressen konfigurieren rem und bedienen. rem Verwenden Sie für CLUSTER2, CLUSTER3 usw. eine ähnliche Konfiguration. rem rem echo "Erste Clusteradresse wird geladen" rem call dscontrol 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 dscontrol 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 Hostnamen 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 dscontrol 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 Round-Robin-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 Managerproportionen 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 Lastausgleichskomponenten rem ist das Festlegen der Managerproportionen. 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 rem Diese Proportionen müssen in der Summe 100 ergeben. Sie können rem die Managerproportionen beispielsweise wie folgt festlegen: rem dscontrol 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 Managerproportionen auf rem 50 50 0 0 gesetzt. rem echo "Manager wird gestartet..." rem call dscontrol manager start rem echo "FTP-Advisor-Funktion wird an Port 21 gestartet ..." rem call dscontrol advisor start ftp 21 rem echo "HTTP-Advisor-Funktion wird an Port 80 gestartet ..." rem call dscontrol advisor start http 80 rem echo "Telnet-Advisor-Funktion wird an Port 23 gestartet ..." rem call dscontrol advisor start telnet 23 rem echo "SMTP-Advisor-Funktion wird an Port 25 gestartet ..." rem call dscontrol advisor start smtp 25 rem echo "POP3-Advisor-Funktion wird an Port 110 gestartet ..." rem call dscontrol advisor start pop3 110 rem echo "NNTP-Advisor-Funktion wird an Port 119 gestartet ..." rem call dscontrol advisor start nntp 119 rem echo "SSL-Advisor-Funktion wird an Port 443 gestartet ..." rem call dscontrol advisor start ssl 443 rem rem echo "Clusterproportionen werden festgelegt..." rem call dscontrol cluster set %CLUSTER% proportions 58 40 2 0 rem rem Der letzte Konfigurationsschritt für die Dispatcher-Maschine rem ist das Festlegen eines Aliasnamens auf der 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 dscontrol executor configure %CLUSTER% rem Wenn die Clusteradresse 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 dscontrol executor 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 dscontrol manager loglevel 1 rem call dscontrol manager logsize 1048576 rem call dscontrol manager sensitivity 5 rem call dscontrol manager interval 2 rem call dscontrol manager refresh 2 rem rem call dscontrol advisor interval ftp 21 5 rem call dscontrol advisor loglevel ftp 21 1 rem call dscontrol advisor logsize ftp 21 1048576 rem call dscontrol advisor timeout ftp 21 unlimited rem call dscontrol advisor interval telnet 23 5 rem call dscontrol advisor loglevel telnet 23 1 rem call dscontrol advisor logsize telnet 23 1048576 rem call dscontrol advisor timeout telnet 23 unlimited rem call dscontrol advisor interval smtp 25 5 rem call dscontrol advisor loglevel smtp 25 1 rem call dscontrol advisor logsize smtp 25 1048576 rem call dscontrol advisor timeout smtp 25 unlimited rem call dscontrol advisor interval http 80 5 rem call dscontrol advisor loglevel http 80 1 rem call dscontrol advisor logsize http 80 1048576 rem call dscontrol advisor timeout http 80 unlimited rem call dscontrol advisor interval pop3 110 5 rem call dscontrol advisor loglevel pop3 110 1 rem call dscontrol advisor logsize pop3 110 1048576 rem call dscontrol advisor timeout pop3 110 unlimited rem call dscontrol advisor interval nntp 119 5 rem call dscontrol advisor loglevel nntp 119 1 rem call dscontrol advisor logsize nntp 119 1048576 rem call dscontrol advisor timeout nntp 119 unlimited rem call dscontrol advisor interval ssl 443 5 rem call dscontrol advisor loglevel ssl 443 1 rem call dscontrol advisor logsize ssl 443 1048576 rem call dscontrol advisor timeout ssl 443 unlimited rem
Nachfolgend ist die Advisor-Beispieldatei ADV_sample wiedergegeben.
/**
* ADV_sample: HTTP-Advisor-Funktion von Load Balancer
*
*
* Diese Klasse definiert eine angepasste Beispiel-Advisor-Funktion für Load
* Balancer. Wie alle Advisor-Funktionen erweitert diese angepasste Advisor-Funktion
* die Funktionalität des Advisor-Basiscodes (ADV_Base). Der Advisor-Basiscode führt die
* meisten Advisor-Funktionen aus, z. B. die Rückmeldung der Arbeitslasten an
* Load Balancer, die dann für den Gewichtungsalgorithmus von Load Balancer
* verwendet werden. Der Advisor-Basiscode öffnet und schließt Sockets und stellt
* Sende- und Empfangsmethoden für die Advisor-Funktion bereit. Die Advisor-Funktion
* selbst wird nur für das Senden und Empfangen von Daten über den Port des empfohlenen
* Servers verwendet. TCP-Methoden innerhalb des Advisor-Basiscodes sind zeitlich gesteuert,
* um die Last zu berechnen. Mit einem Flag der Methode "constructor" in
* "ADV_base" kann bei Bedarf die vorhandene Last mit der neuen, 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.
*
* NAMING
*
* Es gilt die folgende Namenskonvention:
*
* - Die Datei muss sich in den folgenden Load-Balancer-Verzeichnissen befinden:
*
* lb/servers/lib/CustomAdvisors/ (Windows: lb\servers\lib\CustomAdvisors)
*
* - Der Name der Advisor-Funktion muss das 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 Load Balancer generell gültig,
* mit der erforderlichen Java-Version kompiliert werden. Um den Zugriff auf
* die Load-Balancer-Klassen zu gewährleisten, müssen Sie sicherstellen, dass die
* Datei "ibmlb.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 = Standardportnummer für die Advisor-Funktion
* - int iInterval = Intervall für die Ausführung der Advisor-Funktion
* auf den Servern
* - String sDefaultName = 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
* diese ersetzen soll. Es gibt gültige Instanzen für beide Situationen.
*
* Dieses sehr einfache Beispiel entspricht im Wesentlichen der
* HTTP-Advisor-Funktion von Load Balancer.
* Es wird eine Sendeanforderung (HTTP HEAD) abgesetzt. Beim Empfang einer
* Antwort 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
* 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. Alle Rechte vorbehalten.
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_Load_Balancer_HTTP_Advisor\r\n\r\n";
/**
* Constructor.
*
* Parameter: Keine. An die Methode "constructor" in "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 Load
* Balancer bereitgestellten Methoden einfache TCP-Anforderungen
* wie Sende- und Empfangsaufrufe durchführen sollen.
*
* Ergebnisse:
*
* - Last: Ein in Millisekunden angegebener Wert, der entsprechend dem
* Flag "replace" der Methode "constructor" 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 geringer wird auch die Wertigkeit in Load Balancer
* 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.
* versucht nicht, einen inaktiven Server am Lastausgleich zu
* beteiligen. Der Server wird erst wieder in den Lastausgleich einbezogen,
* wenn ein positiver Wert empfangen wird.
*
*/
public int getLoad(int iConnectTime, ADV_Thread caller)
{
int iRc;
int iLoad = ADV_HOST_INACCESSIBLE; // -1
// TCP-Anforderung senden
iRc = caller.send(ADV_SEND_REQUEST);
if (iRc >= 0)
{
// Empfang ausführen
StringBuffer sbReceiveData = new StringBuffer("");
iRc = caller.receive(sbReceiveData);
/**
* Im normalen Advisor-Modus (Flag "replace" ist auf "false" gesetzt),
* wird der Lastwert 0 oder 1 zurückgegeben, um anzugeben, ob der Server
* aktiv oder inaktiv ist.
* Bei erfolgreichem Empfang wird als Lastwert null zurückgegeben, um
* anzuzeigen, dass der von der Basis-Advisor-Funktion ermittelte
* Lastwert verwendet werden soll.
*
* Andernfalls (Flag "replace" ist auf "true" gesetzt) müssen Sie
* den gewünschten Lastwert zurückgeben.
*/
if (iRc >= 0)
{
iLoad = 0;
}
}
return iLoad;
}
} // Ende von ADV_sample
Dieser Anhang beschreibt das Einrichten einer Client/Server-Konfiguration mit hoher Verfügbarkeit, die das Leistungsspektrum der Komponenten von Load Balancer (Dispatcher und CBR) mit dem von Caching Proxy verbindet.
Die Servermaschine in Abbildung 46 ist wie folgt konfiguriert:
Abbildung 46 zeigt eine grundlegende Darstellung mehrerer Server (EdgeServer1, EdgeServer2, EdgeServer3), die die Last auf mehrere Back-End-Webserver verteilen. Die Komponente CBR verwendet Caching Proxy für eine vom Inhalt des URL abhängige Weiterleitung von Anforderungen an die Back-End-Webserver. Die Komponente Dispatcher 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:
Caching ON CacheMemory 128000 K ReversePass /* http://websrvA.firma.com/* http://www.firma.com/*
Beispielkonfigurationsdateien:
Die folgenden Beispielkonfigurationsdateien gleichen den Dateien, die beim Einrichten einer Edge-Components-Konfiguration, wie sie in Abbildung 46 dargestellt ist, erstellt werden. Die Beispielkonfigurationsdateien sind Dateien für die Load-Balancer-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 Komponente Dispatcher auf dem primären Edge-Server mit hoher Verfügbarkeit:
dscontrol executor start dscontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 dscontrol port add 192.168.1.11:80 dscontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 dscontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 dscontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 dscontrol manager start manager.log 10004 dscontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 dscontrol highavailability backup add primary auto 4567
Beispielkonfigurationsdatei für die Komponente CBR 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_rule 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_rule 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_rule type content pattern URI=*webC* priority 23 cbrcontrol rule useserver 192.168.1.21:80:webC_Regel webserverC
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden.
Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim zuständigen IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Services von IBM verwendet werden können. An Stelle der Produkte, Programme oder Services können auch andere, ihnen äquivalente Produkte, Programme oder Services verwendet werden, solange diese keine gewerblichen oder anderen Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb von Produkten, Programmen und Services anderer Anbieter liegt beim Kunden.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren
kann es IBM Patente oder Patentanmeldungen geben.
Mit der Auslieferung dieses Handbuchs ist keine Lizenzierung dieser Patente
verbunden. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten
(Anfragen an diese Adresse müssen auf Englisch formuliert werden):
IBM Director of Licensing
IBM Europe, Middle East & Africa
Tour Descartes 2, avenue Gambetta
92066 Paris La Defense
France
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen oder in Technical News Letters (TNLs) bekannt gegeben. IBM kann jederzeit Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.
Verweise in diesen Informationen auf Websites anderer Anbieter werden lediglich als Service für den Kunden bereitgestellt und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.
Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.
Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen
mit der Zielsetzung: (i) den Austausch von Informationen zwischen
unabhängig voneinander 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:
IBM Corporation
Attn.: G7IA./503.
P.O. Box 12195
3039 Cornwallis Rd.
Research Triangle Park, N.C. 27709-2195
U.S.A.
Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.
Die Lieferung des im Dokument aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt auf der Basis der Allgemeinen Geschäftsbedingungen von IBM, der IBM Internationalen Nutzungsbedingungen für Programmpakete oder einer äquivalenten Vereinbarung.
Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer kontrollierten Umgebung. Die Ergebnisse, die in anderen Betriebsumgebungen erzielt werden, können daher erheblich von den hier erzielten Ergebnissen abweichen. Einige Daten stammen möglicherweise von Systemen, deren Entwicklung noch nicht abgeschlossen ist. Eine Gewährleistung, dass diese Daten auch in allgemein verfügbaren Systemen erzielt werden, kann nicht gegeben werden. Darüber hinaus wurden einige Daten unter Umständen durch Extrapolation berechnet. Die tatsächlichen Ergebnisse können davon abweichen. Benutzer dieses Dokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
Die oben genannten Erklärungen bezüglich der Produktstrategien und Absichtserklärungen von IBM stellen die gegenwärtige Absicht von IBM dar, unterliegen Änderungen oder können zurückgenommen werden und repräsentieren nur die Ziele von IBM.
Diese Veröffentlichung enthält Beispiele für Daten und Berichte des alltäglichen Geschäftsablaufes. Sie sollen nur die Funktionen des Lizenzprogrammes illustrieren; sie können Namen von Personen, Firmen, Marken oder Produkten enthalten. Alle diese Namen sind frei erfunden; Ähnlichkeiten mit tatsächlichen Namen und Adressen sind rein zufällig.
Wird dieses Buch als Softcopy (Book) angezeigt, erscheinen keine Fotografien oder Farbabbildungen.
Folgende Namen sind eingetragene Marken oder Marken der IBM Corporation in den USA und/oder anderen Ländern:
AFS
AIX
DFS
IBM
iSeries(TM)
NetView
OS/2
Redbooks(TM)
RS/6000(R)
SecureWay
ViaVoice
WebSphere
zSeries(R)
Java und alle auf Java basierenden Marken und Logos sind Marken von Sun Microsystems, Inc. in den USA und/oder anderen Ländern.
Microsoft, Windows, Windows NT und das Windows-Logo sind Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
Intel, Intel Inside (Logos), MMX und Pentium sind Marken der Intel Corporation in den USA oder anderen Ländern.
UNIX ist eine eingetragene Marke von The Open Group in den USA und anderen Ländern.
Linux ist eine Marke von Linus Torvalds in den USA und/oder anderen Ländern.
Weitere Unternehmens-, Produkt- oder Servicenamen können Marken anderer Hersteller sein.