Der Lastausgleich verbessert die Verfügbarkeit und Skalierbarkeit Ihrer Website, indem Proxyserver und Anwendungsserver transparent zu einem Cluster zusammengefasst werden. Die Skalierbarkeit einer IT-Infrastruktur verbessert sich in hohem Maße, weil Back-End-Verarbeitungsleistung transparent hinzugefügt werden kann.
Wenn Ihr System eine große Anzahl von Anforderungen verarbeiten muss, können Sie den Inhalt auf mehreren Hosts duplizieren. In diesem Fall müssen Sie jedoch dafür sorgen, dass die Arbeitslast gleichmäßig auf die einzelnen Hosts verteilt wird. DNS (Domain Name Service) bietet zwar einen grundlegenden Lastausgleich nach dem Round-Robin-Verfahren, aber es gibt verschiedene Situationen, in denen sich dieses Verfahren nicht eignet.
Eine ausgereiftere Lösung für die Lastverteilung auf mehrere Inhaltshosts bietet die Verwendung der Komponente Dispatcher von Load Balancer, die in Abb. 5 veranschaulicht ist. Bei dieser Konfiguration ist auf allen Inhaltshosts (die mit 5 gekennzeichneten Maschinen) derselbe Inhalt gespeichert. Die Maschinen bilden einen Cluster mit Lastausgleich, und einer der Netzschnittstellen auf der Load-Balancer-Maschine (4) ist ein Hostname und eine IP-Adresse für diesen Cluster zugewiesen. Wenn ein Endbenutzer, der auf einer der Maschinen 1 arbeitet, die Datei X anfordert, wird die Anforderung über das Internet (2) gesendet und erreicht das interne Netz des Unternehmens über das Internet-Gateway (3). Der Dispatcher fängt die Anforderung ab, weil der URL der Anforderung dem Hostnamen und der IP-Adresse des Dispatcher zugeordnet wird. Der Dispatcher ermittelt, welcher der Inhaltshosts im Cluster derzeit am besten geeignet ist, die Anforderung zu bearbeiten, und leitet die Anforderung an diesen Host weiter. Ist die Weiterleitungsmethode MAC konfiguriert, gibt der Host die Datei X direkt an den Client zurück (d. h., die Datei X wird nicht über den Load Balancer weitergeleitet).
Legende: 1—Client 2—Internet 3—Router/Gateway 4—Dispatcher 5—InhaltshostStandardmäßig verwendet der Dispatcher wie DNS den Lastausgleich nach dem Round-Robin-Prinzip. Trotzdem weist der Lastausgleich mit Dispatcher nicht dieselben Unzulänglichkeiten auf wie der Lastausgleich mit DNS. Anders als bei DNS wird protokolliert, ob ein Inhaltshost nicht verfügbar oder nicht zugänglich ist. Es werden keine Clients an einen nicht verfügbaren Inhaltshost weitergeleitet. Darüber hinaus wird die aktuelle Belastung der Inhaltshosts durch Protokollieren neuer, aktiver und beendeter Verbindungen berücksichtigt. Sie können den Lastausgleich weiter optimieren, indem Sie die optionalen Advisor- und Managerkomponenten von Load Balancer aktivieren. Diese Komponenten überwachen den Status der Inhaltshosts noch genauer und bringen zusätzliche Informationen in den Entscheidungsprozess für den Lastausgleich ein. Mit dem Manager können Sie den unterschiedlichen Faktoren, die beim Entscheidungsprozess verwendet werden, verschiedene Wertigkeiten zuweisen und somit den Lastausgleich für Ihre Site weiter anpassen.
Dispatcher von Load Balancer kann auch den Lastausgleich für mehrere Caching-Proxy-Maschinen durchführen. Ist die Website Ihres Unternehmens sehr populär, besteht unter Umständen eine höhere Nachfrage nach Inhalten, als ein einzelner Proxy-Server effektiv verarbeiten kann. Aufgrund einer solchen Situation kann sich die Leistung des Proxyservers verschlechtern.
Sie können mehrere Caching-Proxy-Systeme verwenden, die Proxyfunktionen für einen einzelnen Inhaltshost ausführen (ähnlich wie in der Konfiguration in Abb. 1). Falls Ihre Site jedoch so populär ist, dass Sie mehrere Proxy-Server benötigen, brauchen Sie wahrscheinlich auch mehrere Inhaltshosts, deren Arbeitslast von Load Balancer verteilt werden muss. Diese Konfiguration wird in Abb. 6 dargestellt. Der Dispatcher 4 verteilt die Arbeitslast in einem Cluster mit zwei Proxyservern (5), und der Dispatcher 7 verteilt die Arbeitslast in einem Cluster mit drei Inhaltshosts (8).
Legende: 1—Client 2—Internet 3—Router/Gateway 4—Dispatcher 5—Proxy-Server 6—Cache 7—Dispatcher 8—InhaltshostBeim Cluster-Hostnamen des Dispatcher 4 handelt es sich um den Hostnamen, der in den URLs für Webinhalte des Unternehmens angezeigt wird (d. h., es ist der Name der Website, wie er im Internet sichtbar ist). Der Cluster-Hostname für den Dispatcher 7 ist im Internet nicht sichtbar und kann daher beliebig gewählt werden. Beispiel: Für das Unternehmen ABC wäre www.abc.com ein geeigneter Hostname für den Dispatcher 4, während für den Dispatcher 7 ein Name wie http-balancer.abc.com festgelegt werden könnte.
Angenommen, ein Browser auf einer der Clientmaschinen 1 muss auf die Datei X zugreifen, die auf den Inhaltsservern (8) gespeichert ist. Die HTTP-Anforderung wird über das Internet (2) gesendet und erreicht das interne Unternehmensnetz über das Gateway (3). Der Router leitet die Anforderung an den Dispatcher 4 weiter, der sie an den Proxy-Server (5) übergibt, der gemäß dem Algorithmus für Lastausgleich zum gegebenen Zeitpunkt am besten für die Verarbeitung der Anforderung geeignet ist. Wenn sich die Datei X im Cache (6) des Proxy-Servers befindet, wird sie unter Umgehung des Dispatcher 4 direkt an den Browser zurückgegeben.
Befindet sich im Cache des Proxy-Servers keine Kopie der Datei X, erstellt der Proxyserver eine neue Anforderung mit seinem eigenen Hostnamen im Feld "origin" des Header und sendet diese an den Dispatcher 7. Load Balancer bestimmt, welcher Inhaltshost (8) zur Zeit am besten für die Bearbeitung der Anforderung geeignet ist, und leitet dann die Anforderung an diesen Host weiter. Der Inhaltshost ruft die Datei X aus dem Speicher ab und übergibt sie direkt an den Proxy-Server, wobei er den Dispatcher 7 übergeht. Der Proxy-Server speichert die Datei X gegebenenfalls im Cache und leitet sie dann unter Umgehung des Dispatcher 4 an den Browser weiter.
Wenn Sie einer großen Anzahl von Clients Internet-Zugriffe ermöglichen, generieren diese einen höheren Bedarf an Internet-Zugriffen, als ein einzelner Proxy-Server effizient bewältigen kann. Da Caching Proxy mit Anforderungen überladen wird, können die Clients unter Umständen schlechtere Antwortzeiten erleben als bei einem direkten Internet-Zugriff. Wenn ein Fehler in Caching Proxy auftritt oder Caching Proxy aufgrund eines Netzfehlers vorübergehend ausfällt, sind keine Internet-Zugriffe mehr möglich. Die Lösung besteht in der Installation mehrerer Caching-Proxy-Maschine und der Verwendung der Komponente Dispatcher von Load Balancer, die die Last gleichmäßig auf diese Maschinen verteilt.
Ohne den Dispatcher können Sie einen echten transparenten Proxy-Server mit mehreren Caching-Proxy-Maschinen nur dann bereitstellen, wenn Ihre Router denselben Typ von Datenverkehr an mehrere Caching-Proxy-Server weiterleiten können. Nicht alle Router unterstützen dies. Es ist möglich, einen regulären Forward-Proxy-Service auf mehreren Caching-Proxy-Maschinen ohne den Dispatcher bereitzustellen, aber in diesem Fall müssen Sie eine der Caching-Proxy-Maschinen als primären Proxy explizit in den Client-Browsern konfigurieren. Wenn in diesem Caching Proxy ein Fehler auftritt oder Caching Proxy überlastet oder nicht verfügbar ist, sind die Endbenutzer möglicherweise nicht mehr in der Lage, auf das Internet zuzugreifen. Sie können diese Situation vermeiden, indem Sie eine PAC-Datei (Proxy Automatic Configuration) erstellen (siehe Beschreibung im Abschnitt Transparenter Forward Caching Proxy (nur Linux-Systeme)), die den Browser anweist, auf eine oder mehrere sekundäre Caching-Proxy-Maschinen umzuschalten. Eine PAC-Datei befasst sich nicht mit dem Bedarf nach Lastausgleich zwischen den Caching-Proxy-Maschinen. Wenn jedoch ein Caching Proxy mehr Anforderungen empfängt als ein anderer, lässt seine Leistung wahrscheinlich nach, was längere Antwortzeiten für seine Browser-Clients bedeutet. Damit allen Clients dieselbe Leistung zur Verfügung gestellt wird, müssen Sie für jeden Caching Proxy ungefähr dieselbe Anzahl an Browsern konfigurieren und die Verteilung manuell überwachen, damit die Last auch dann weiter gleichmäßig verteilt wird, wenn Sie Browser hinzufügen oder entfernen.
Abb. 7 zeigt eine Netzkonfiguration, in der der Dispatcher den Lastausgleich für einen Cluster von Caching-Proxy-Maschinen durchführt. Eine der Netzschnittstellen der Dispatcher-Maschine ist mit dem Hostnamen und der IP-Adresse des Cluster konfiguriert. Client-Browser sind so konfiguriert, dass sie ihre Internet-Anforderungen an den Hostnamen des Cluster weiterleiten. Wenn beispielsweise ein Browser auf einer der Clientmaschinen, die mit 1 gekennzeichnet ist, auf die Datei X auf einem Inhaltshost (7) zugreifen muss, leitet er seine Anforderung an den Hostnamen oder die Adresse des Cluster weiter. Dispatcher (2) fängt diese Anforderung ab und leitet sie an den entsprechenden Caching Proxy (3) weiter. Caching Proxy erstellt eine neue Anforderung, übergibt sie über das Unternehmens-Gateway (5) und über das Internet (6) und speichert die zurückgegebene Datei gegebenenfalls in seinem Cache (4). Eine ausführlichere Beschreibung finden Sie im Abschnitt Forward Caching Proxy
Der Dispatcher erkennt, wenn eine der Caching-Proxy-Maschinen nicht verfügbar ist, und leitet die Anforderungen automatisch an die andere weiter. Dies ermöglicht Ihnen, eine Caching-Proxy-Maschine zu Wartungszwecken herunterzufahren, ohne die Internet-Zugriffe zu beeinträchtigen. Der Dispatcher hat zahlreiche Konfigurationsoptionen, mit denen Sie die Faktoren steuern können, die der Dispatcher bei Lastausgleichentscheidungen berücksichtigt. Außerdem können Sie Dispatcher-Hilfsprogramme auf den Caching-Proxy-Maschinen installieren, um ihren Status zu überwachen und die Informationen an den Dispatcher zurückzugeben. Nähere Einzelheiten finden Sie im WebSphere Application Server Load Balancer Administratorhandbuch. Die Verwendung mehrerer Caching-Proxy-Server kann eine potenzielle Ineffizienz mit sich bringen, da mehrere Caching-Proxy-Maschinen dieselbe Datei zwischenspeichern können, wenn unterschiedliche Clients dieselbe Datei über eine jeweils andere Caching-Proxy-Maschine anfordern. Zur Vermeidung von Redundanzen können Sie RCA (Remote Cache Access, ferner Cache-Zugriff) konfigurieren, das allen Proxy-Servern in einer definierten Gruppe ermöglicht, den Inhalt ihres Cache mit den anderen zu teilen. Die Proxy-Server in der RCA-Gruppe verwenden alle denselben Algorithmus, um festzustellen, welcher Caching Proxy für einen bestimmten URL verantwortlich ist. Wenn ein Caching Proxy einen URL abfängt, für den er nicht verantwortlich ist, übergibt er die Anforderung an den verantwortlichen Caching Proxy. Der verantwortliche Caching Proxy führt die erforderlichen Aufgaben zur Bearbeitung der Anforderung aus, d. h. er ruft die Anforderung aus seinem Cache ab oder er leitet die Anforderung an den relevanten Inhaltshost weiter und stellt gegebenenfalls die zurückgegebene Datei in seinen Cache. Der verantwortliche Caching Proxy übergibt anschließend die Datei an den ursprünglichen Caching Proxy, der sie dem anfordernden Endbenutzer bereitstellt.
Wenn in dem für einen bestimmten URL verantwortlichen Caching Proxy in der RCA-Gruppe ein Fehler auftritt, greift der ursprüngliche Caching Proxy, der die Clientanforderung empfangen hat, direkt auf den Inhaltshost (oder den Caching-Proxy-Backup-Server, sofern ein solcher definiert ist) zu. Dies impliziert, dass Benutzer auf Dateien zugreifen können, solange mindestens ein Caching Proxy in einer RCA-Gruppe ordnungsgemäß funktioniert.
Diese Konfiguration erfüllt den hohen Bedarf an Internet-Zugriffen, weil der Dispatcher verwendet wird, um die Anforderungslast auf mehrere Caching-Proxy-Maschinen zu verteilten. Ein potenzielles Problem ist, dass der Dispatcher einen Single Point of Failure darstellt. Wenn im Dispatcher ein Fehler auftritt oder der Dispatcher aufgrund eines Netzfehlers nicht mehr zugänglich ist, können die Browser-Clients die Caching-Proxy-Maschinen oder das Internet nicht erreichen. Die Lösung besteht darin, einen weiteren Dispatcher zu konfigurieren, der als Backup für den primären Dispatcher dient. Diese Lösung ist in Abb. 8 veranschaulicht.
Hier leitet ein Browser, der auf einer der mit 1 gekennzeichneten Maschinen ausgeführt wird, seine Anforderung für eine Datei X gewöhnlich an den primären Dispatcher (2) weiter, der die Anforderung an den Caching Proxy (4) weiterleitet, der auf der Basis der Lastausgleichskriterien des Dispatcher ausgewählt wird. Der Caching Proxy erstellt eine neue Anforderung, leitet sie über das Unternehmens-Gateway (6) über das Internet (7) an den Inhaltshost (8) weiter und speichert gegebenenfalls die zurückgegebene Datei X in seinem Cache (5). Eine ausführlichere Beschreibung dieses Teils des Prozesses finden Sie im Abschnitt Forward Caching Proxy.
In dieser Konfiguration führt der Backup-Dispatcher (3) keinen Lastausgleich durch, solange der primäre Dispatcher funktionsfähig ist. Der primäre und der Backup-Dispatcher überwachen jeweils den Status des anderen durch den regelmäßigen Austausch von Nachrichten. Diese Nachrichten werden als Überwachungssignale bezeichnet. Wenn der Backup-Dispatcher feststellt, dass der primäre Dispatcher ausgefallen ist, übernimmt er automatisch den Lastausgleich, indem er Anforderungen an den Hostnamen oder die IP-Adresse des primären Dispatcher abfängt. Es ist außerdem möglich, zwei Dispatcher für wechselseitige hohe Verfügbarkeit zu konfigurieren. In diesem Fall führt jeder Dispatcher aktiv den Lastausgleich für einen separaten Cluster von Caching-Proxy-Maschinen aus und fungiert gleichzeitig als Backup für den jeweils anderen. Nähere Einzelheiten finden Sie im WebSphere Application Server Load Balancer Administratorhandbuch.
In der Regel verbraucht der Dispatcher nicht sehr viele Verarbeitungs- und Speicherressourcen, und auf der Dispatcher-Maschine können andere Anwendungen aktiv sein. Sollte es erforderlich sein, die Kosten für Geräte so gering wie möglich zu halten, kann der Backup-Dispatcher sogar auf derselben Maschine wie Caching Proxy ausgeführt werden. Abb. 9 zeigt eine solche Konfiguration, in der der Backup-Dispatcher auf derselben Maschine (3) wie Caching Proxy ausgeführt wird.