In diesem Kapitel wird erklärt, wie die Lastausgleichsparameter konfiguriert werden und Load Balancer für die Verwendung der erweiterten Funktionen eingerichtet wird.
Task | Beschreibung | Referenzinformationen |
---|---|---|
Verknüpfung von Load Balancer mit einer am Lastausgleich beteiligten Maschine | Konfigurieren Sie eine verknüpfte Load-Balancer-Maschine. | 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 Cluster-Port | Clientanforderungen werden immer an denselben Server gerichtet. | Funktionsweise der Affinität für Load Balancer |
Verwendung der portübergreifenden Affinität, um die Affinität an allen Ports zu nutzen | Von verschiedenen Ports empfangene Clientanforderungen werden an einen Server gerichtet. | Portübergreifende 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 WAN-Unterstützung von Dispatcher | Konfigurieren Sie einen fernen Dispatcher für den Lastausgleich in einem Weitverkehrsnetz (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 |
Verwendung eines Platzhalterclusters mit Caching Proxy für transparente Weiterleitung | 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ärprotokollierung 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: 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.
Solaris: Sie können keine WAN-Advisor konfigurieren, wenn der Eingangspunkt-Dispatcher verknüpft ist. Weitere Informationen finden Sie im Abschnitt Ferne Advisor mit der Dispatcher-WAN-Unterstützung verwenden.
Windows: Kollokation ist nicht mehr verfügbar, wenn Sie die Dispatcher-MAC-Weiterleitungsmethode 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.
Damit ein Server als verknüpfter Server konfiguriert werden kann, stellt der Befehl dscontrol server die Option collocated bereit, 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_Aliasname address neuer_Aliasname 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 folgenden Betriebssystemen die 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 ohne zusätzliche Konfiguration unter AIX, HP-UX, Linux und Solaris. Die verwendeten Webserver und der verwendete Caching Proxy müssen jedoch bindungsspezifisch sein.
Site Selector unterstützt die Verknüpfung ohne zusätzliche Konfiguration unter AIX, HP-UX, Linux und Solaris.
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
Ausweichmaschine - highavailability heartbeat add 9.67.186.8 9.67.111.3
Fü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.18
Erreichbarkeitsziele werden empfohlen, sind aber nicht erforderlich. Nähere Informationen enthält der 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 status
Die Maschinen sollten jeweils die korrekte Rolle
(Ausweichmaschine 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
übereinstimmen. dscontrol cluster set ClusterA primaryhost NFAdispatcher1
dscontrol cluster set ClusterB primaryhost NFAdispatcher2
dscontrol cluster set ClusterB primaryhost NFAdispatcher2
dscontrol cluster set ClusterA primaryhost NFAdispatcher1
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 Pingsignal erreichen kann. Wenn der Bereitschafts-Dispatcher mehr Erreichbarkeitsziele mit einem Pingsignal 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 Pingsignale des Advisors 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 Bereitschafts-Dispatcher. Der Bereitschafts-Dispatcher 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 Ausweichmaschine. Wird die primäre Maschine gestartet, leitet sie die gesamten Verbindungsdaten so lange an die Ausweichmaschine weiter, bis die beiden Maschinen synchronisiert sind. Die primäre Maschine wird aktiv, d. h., sie beginnt mit dem Lastausgleich. Die Ausweichmaschine überwacht in der Zwischenzeit den Status der primären Maschine und befindet sich in Bereitschaft.
Stellt die Ausweichmaschine 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 gegenseitiger 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 sind im folgenden Verzeichnis enthalten:
Diese Scripts müssen in das folgende Verzeichnis verschoben werden, damit sie ausgeführt werden:
Die Scripts werden automatisch nur dann ausgeführt, wenn dsserver aktiv ist.
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 "Local Area Connection"
addr=9.37.51.28 mask=255.255.240.0
In den Scripts goStandby und goInOp muss der Aliasname entfernt werden. Beispiel:
call netsh interface ip delete address "Local Area Connection"
addr=9.37.51.28
Wenn die Maschine mehrere NICs enthält, überprüfen Sie zunächst, welche Schnittstelle verwendet werden sollte. Setzen Sie dazu an der Eingabeaufforderung den Befehl netsh interface ip show address ab. Dieser Befehl gibt eine Liste der zur Zeit konfigurierten Schnittstellen zurück und versieht die Angabe "Local Area Connection" mit einer Nummer (z. B. "Local Area Connection 2"), so dass Sie festlegen können, welche Schnittstelle verwendet werden soll.
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.
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 Standardregel konfigurieren, die immer wahr ist, 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. Der Inhaltsregel für die Komponente CBR ist ein Muster eines regulären Ausdrucks für den Abgleich zugeordnet. (Beispiele und Szenarien für die Verwendung der Inhaltsregel sowie eine gültige Mustersyntax 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 Zahl) 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 bestimmte 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.
Option für Regelauswertung 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 hierzu finden Sie im Abschnitt Option für Serverauswertung für Regeln.
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 über die grafische 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 Festlegen 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 genutzt 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 Regel ist, die "immer wahr" (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 Regel des Typs "immer wahr" ("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 Script für Systemmetriken) aus. Site Selector vergleicht die Systemmetrik (der vom Agenten Metric Server 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 aktuelle Systemmetrikwert 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 Script für Systemmetriken) aus. Site Selector vergleicht die Systemmetrik (der vom Agenten Metric Server 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 "Metrik Durchschnitt" 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 von 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 von 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 von 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 Musterwert 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 Mustersyntax 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 Serveroption sticky finden Sie unter 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 Option für Serverauswertung 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.)
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 evaluate 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 portübergreifende Affinität aktiviert, müssen die Werte für stickytime der gemeinsam genutzten Ports identisch (und ungleich null) sein. Weitere Informationen hierzu finden Sie im Abschnitt Portübergreifende 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 portübergreifende Affinität gilt nur für die Dispatcher-Weiterleitungsmethoden MAC und NAT/NATP.
Die portübergreifende 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 portübergreifender 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 einem crossport herstellen. Wenn vom selben Client weitere Verbindungen an demselben Port oder einem gemeinsam genutzten Port ankommen, wird auf denselben Server zugegriffen. Nachfolgend sehen Sie eine Beispielkonfiguration für mehrere Ports mit einer portübergreifenden Affinität für Port 10:
dscontrol port set Cluster:20 crossport 10
dscontrol port set Cluster:30 crossport 10
dscontrol port set Cluster:40 crossport 10
Nachdem Sie die portübergreifende Affinität konfiguriert haben, können Sie den Wert für stickytime des Ports flexibel ändern. Sie sollten stickytime jedoch für alle gemeinsam genutzten Ports auf denselben Wert setzen, da andernfalls unerwartete Ergebnisse auftreten können.
Wenn Sie die portübergreifende Affinität aufheben möchten, setzen Sie den Wert für crossport auf seine eigene Portnummer zurück. Der Abschnitt dscontrol port — Ports konfigurieren enthält ausführliche Informationen zur Befehlssyntax für die Option crossport.
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. Die Angabe von stickymask im Befehl dscontrol port ermöglicht Ihnen, die gemeinsamen höherwertigen Bits der 32-Bit-IP-Adresse zu 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 portübergreifender Affinität: Wenn Sie die portübergreifende Affinität aktivieren, müssen die stickymask-Werte der gemeinsam genutzten Ports identisch sein. Weitere Informationen hierzu finden Sie im Abschnitt Portübergreifende 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.
Der Abschnitt dscontrol port — Ports konfigurieren enthält ausführliche Informationen zur Befehlssyntax für stickymask (Affinitätsadressmaskenfunktion).
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 Client-Browser 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 Content-Based Routing von Dispatcher (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 RoundRobin-Methode ausgewählt.
Gehen Sie zum Konfigurieren der passiven Cookie-Affinität wie folgt vor:
Die Option für passive Cookie-Affinität für den Regelbefehl (rule) kann nur auf passivecookie gesetzt werden, wenn die Haltezeit (stickytime) für den Port gleich null (inaktiviert) ist. Ist die passive Cookie-Affinität für eine Regel aktiviert, kann keine Haltezeit für den Port aktiviert werden.
Die URI-Affinität gilt für die Weiterleitungsmethode cbr von Dispatcher und die Komponente CBR. Informationen zum Konfigurieren der Weiterleitungsmethode cbr finden Sie im Abschnitt Content-Based Routing von Dispatcher (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 Cache-Kapazitä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 Clientarbeitslast, 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 Abb. 32). Eine Clientanforderung wird auf der Dispatcher-Maschine empfangen und an den Server gesendet. Der Server sendet die Antwort direkt zurück an den Client.
Durch das WAN-Feature von Dispatcher werden Server an anderen Standorten, die als ferne Server bezeichnet werden, unterstützt (siehe Abb. 33). 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.
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 WAN-Unterstü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:
Ein Eingangspunkt-Dispatcher behandelt den Dispatcher der zweiten Ebene als Server, überwacht seinen Status als Server und verknüpft die Ergebnisse mit der echten IP des Dispatchers.
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-Systeme, Linux-, Solaris- und Windows-Systeme
Dieses Beispiel bezieht sich auf die in Abb. 34 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 Internet-Protokoll, 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.
Wenn Sie für dieses Beispiel (Abb. 35) 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 nutzen. 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 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. Außerdem müssen Sie die zweite LAN-Karte in einem anderen Teilnetz konfigurieren. Die Dispatcher-Maschine sendet die Clientanforderungen über das private Netz an die TCP-Servermaschinen.
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 Abb. 36 müsste der Befehl für den Server "Apfel" 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.
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 zur 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 Benutzerexits bereit, die Scripts aufrufen. Diese Scripts können so angepasst werden, dass der Administrator per Alert über eine möglichen Denial-of-Service-Attacke (DoS) informiert wird. Dispatcher stellt im folgenden Verzeichnis Beispielscripts bereit:
Die folgenden Scripts sind verfügbar:
Zum Ausführen der Dateien müssen Sie sie in das folgende Verzeichnis verschieben und die Dateierweiterung ".sample" entfernen:
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 die Binärprotokollierung 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 dann in die Protokolle geschrieben, wenn seit dem Schreiben des letzten Protokolleintrags die für das Protokollierungsintervall angegebene Zeit in Sekunden verstrichen ist. Standardmäßig wird das Protokollierungsintervall auf 60 Sekunden gesetzt. Zwischen den Einstellungen für das 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 festgelegt, 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 folgenden Verzeichnis stehen ein Beispiel-Java™-Programm und eine Beispielbefehlsdatei zur Verfügung:
Dieses Beispiel zeigt, wie alle Informationen aus den Protokolldateien abgerufen und angezeigt werden können. Es kann für jede Art von Datenanalyse angepasst werden. Beispiel 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.