Diese Ausgabe gilt für:
Außerdem gilt diese Ausgabe für alle nachfolgenden Releases und Änderungen, sofern in den neuen Ausgaben keine anderen Hinweise enthalten sind.
Veröffentlichungen können über den zuständigen IBM Ansprechpartner oder die zuständige IBM Geschäftsstelle bezogen werden.
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
IBM WebSphere Application Server Edge Components Concepts,
Planning, and Installation, Version 6.1,
IBM Form GC31-6918-00,
herausgegeben von International Business Machines Corporation, USA
(C) Copyright International Business Machines Corporation 2006
(C) Copyright IBM Deutschland GmbH 2006
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
Das Handbuch WebSphere Application Server Edge Components Konzepte, Planung und Installation dient als Einführung in WebSphere Application Server Edge Components. Es enthält Produktübersichten, detaillierte Erläuterungen der Funktionalität von Schlüsselkomponenten, Szenarien für den Einsatz der Edge-Komponenten im Netz, Informationen zur Installation und Erstkonfiguration sowie Beispielnetze.
Das Handbuch WebSphere Application Server Edge Components Konzepte, Planung und Installation wurde für erfahrene Netz- und Systemadministratoren geschrieben, die mit ihrem Betriebssystem und dem Bereitstellen von Internet-Services vertraut sind. Vorkenntnisse bezüglich WebSphere Application Server oder WebSphere Application Server Edge Components sind nicht erforderlich.
Eingabehilfen unterstützen Benutzer mit körperlichen Behinderungen wie eingeschränkter Motorik oder eingeschränktem Sehvermögen bei der Arbeit mit Softwareprodukten. Im Folgenden sind die wichtigsten Eingabehilfen von WebSphere Application Server Version 6.1 beschrieben:
Diese Dokumentation richtet sich in Bezug auf Typografie und Hervorhebung nach den folgenden Konventionen.
Konvention | Bedeutung |
---|---|
Fettschrift | Bei Bezugnahme auf grafische Benutzerschnittstellen (GUIs) werden Menüs, Menüpunkte, Titel, Knöpfe (Schaltflächen), Symbole und Ordner in Fettschrift dargestellt. Die Fettschrift kann auch zum Hervorheben von Befehlsnamen verwendet werden, die sonst mit dem Begleittext verwechselt werden könnten. |
Monospace-Schrift | Kennzeichnet Text, der an der Eingabeaufforderung eingegeben werden muss. In Monospace-Schrift werden auch Anzeigetexte, Codebeispiele und Dateiauszüge hervorgehoben. |
Kursivschrift | Kennzeichnet Variablenwerte, die eingegeben werden müssen (z. B. müssen Sie Dateiname durch den Namen einer Datei ersetzen). Kursivschrift wird außerdem für Hervorhebungen und Handbuchtitel verwendet. |
Strg-x | Diese Angabe kennzeichnet eine Tastenkombination mit der Steuerungstaste. x steht hier für eine Tastenbezeichnung. Beispielsweise bedeutet die Angabe <Strg-c>, dass Sie die Taste Strg gedrückt halten und gleichzeitig die Taste c drücken sollen. |
Eingabetaste | Bei dieser Angabe müssen Sie die Eingabetaste drücken. |
% | Steht in der Linux- und UNIX-Befehlsumgebung für die Aufforderung zur Eingabe eines Befehls, der keine Root-Berechtigung erfordert. |
# | Steht in der Linux- und UNIX-Befehlsumgebung für die Aufforderung zur Eingabe eines Befehls, der Root-Berechtigung erfordert. |
C:\ | Steht für die Eingabeaufforderung in der Windows-Umgebung. |
Befehlseingabe | Wenn Sie aufgefordert werden, einen Befehl einzugeben, geben Sie den Befehl ein und drücken Sie dann die Eingabetaste. Beispiel: Die Anweisung "Geben Sie den Befehl ls ein" bedeutet, dass Sie an der Eingabeaufforderung ls eingeben und anschließend die Eingabetaste drücken müssen. |
[ ] | In eckigen Klammern werden optionale Elemente in Syntaxbeschreibungen angegeben. |
{ } | In geschweiften Klammern werden Listen in Syntaxbeschreibungen angegeben, aus denen Sie einen Eintrag auswählen können. |
| | Dieses Zeichen trennt in Syntaxbeschreibungen die Einträge in einer Auswahlliste, die in geschweiften Klammern ({ }) angegeben ist. |
... | Drei Punkte in Syntaxbeschreibungen bedeuten, dass der vorherige Eintrag einmal oder mehrmals wiederholt werden kann. Drei Punkte in Beispielen bedeuten, dass Informationen weggelassen wurden, um die Darstellung zu vereinfachen. |
Dieser Teil enthält eine Einführung in die Komponenten Caching Proxy und Load Balancer von WebSphere Application Server Edge Components und erläutert ihre Verwendung zusammen mit Application Server. Darüber hinaus werden in diesem Teil andere zugehörige Produkte der WebSphere-Produktfamilie vorgestellt.
Dieser Teil enthält folgende Kapitel:
WebSphere ist eine Internet-Infrastruktursoftware, mit deren Unterstützung Unternehmen e-business-Anwendungen der nächsten Generation, z. B. Anwendungen für B2B-E-Commerce, entwickeln, einsetzen und integrieren können. WebSphere-Middleware unterstützt Geschäftsanwendungen vom einfachen Web-Publishing bis hin zur unternehmensweiten Transaktionsverarbeitung.
Als Grundlage der WebSphere-Plattform stellt WebSphere Application Server umfassende Middleware bereit, mit deren Hilfe die Benutzer Geschäftsanwendungen entwerfen, implementieren, einsetzen und verwalten können. Diese Anwendungen können vom einfachen virtuellen Schaufenster auf einer Website bis hin zur vollständigen Überarbeitung der Datenverarbeitungsinfrastruktur eines Unternehmens reichen.
Prozessorintensive Funktionen wie Personalisierung bringen jedem e-business einen Wettbewerbsvorteil. Weil diese Funktionen jedoch für gewöhnlich an zentrale Server übertragen werden, stehen wertvolle Funktionen nicht auf Internet-Ebene zur Verfügung. Folglich müssen Umfang und Leistung der Internet-Infrastruktur eines Unternehmens zusammen mit der Zahl der neuen Webanwendungen wachsen. Außerdem sind für ein e-business die Zuverlässigkeit und die Sicherheit zwei Aspekte von außerordentlicher Bedeutung. Selbst die geringste Serviceunterbrechung kann Geschäftsverluste zur Folge haben.
Edge Components (früher Edge Server) ist jetzt im Produktumfang von WebSphere Application Server enthalten. Edge Components kann zusammen mit WebSphere Application Server eingesetzt werden, um den Clientzugriff auf die Webserver zu steuern. Außerdem ermöglicht es den Unternehmen, Benutzern, die über das Internet oder ein Unternehmens-Intranet auf webbasierte Inhalte zugreifen, einen besseren Service zu bieten. Durch den Einsatz von Edge Components kann die Last auf den Webservern verringert, die Verfügbarkeit der Inhalte erhöht und die Leistung der Webserver verbessert werden. Wie der Name bereits andeutet, wird Edge Components normalerweise auf Maschinen eingesetzt, die sich (in Bezug auf die Netzkonfiguration) nahe der Grenze (Edge) zwischen dem Unternehmens-Intranet und dem Internet befinden.
WebSphere Application Server umfasst die Edge-Komponenten Caching Proxy und Load Balancer.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Caching Proxy verringert die Belastung des Netzes und verbessert Geschwindigkeit und Zuverlässigkeit einer Website durch die Bereitstellung eines POP-Knotens (Point-of-Presence, Zugangspunkt) für einen oder mehrere Back-End-Inhaltsserver. Caching Proxy kann statische Inhalte und Inhalte, die von WebSphere Application Server dynamisch generiert wurden, zwischenspeichern und bereitstellen.
Caching Proxy kann als Reverse-Proxy-Server (Standardkonfiguration) oder als Forward-Proxy-Server konfiguriert werden und damit entweder einen so genannten Point-of-Presence für ein Netz oder einen internen Netzserver darstellen, dessen Aufgabe es ist, Anforderungs- und Antwortzeiten zu verbessern. Weitere Informationen zu Reverse- und Forward-Proxy-Konfigurationen finden Sie im Abschnitt Caching-Proxy-Basiskonfigurationen.
Der Proxy-Server fängt Datenanforderungen von Clients ab, ruft die angeforderten Informationen von den Maschinen ab, auf denen Inhalte bereitgestellt werden, und liefert sie an die Clients. Im Allgemeinen handelt es sich bei den Anforderungen um Anforderungen für Dokumente, die auf Webserver-Maschinen (auch Ursprungsserver oder Inhaltshosts genannt) gespeichert sind und die über das Protokoll HTTP (Hypertext Transfer Protocol) zugestellt werden. Sie können den Proxy-Server jedoch auch für die Verwendung anderer Protokolle wie File Transfer Protocol (FTP) und Gopher konfigurieren.
Der Proxy-Server legt Inhalte, die zwischengespeichert werden können, in einem lokalen Cache ab, bevor er sie an den Requester liefert. Beispiele für solche Inhalte, die im Cache zwischengespeichert werden können, sind statische Webseiten und JSP-Dateien (JavaServer Pages) mit Fragmenten, die dynamisch generiert werden, sich aber nur selten ändern. Durch die Zwischenspeicherung (Caching) ist der Proxy-Server in der Lage, nachfolgende Anforderungen für denselben Inhalt direkt aus dem Cache abzurufen. Das ist sehr viel schneller als ein erneuter Abruf des Inhalts vom Inhaltshost.
Die Plug-ins für Caching Proxy erweitern die Funktionalität des Proxy-Servers.
Darüber hinaus können Sie die Funktionen von Caching Proxy erweitern, indem Sie eigene Plug-in-Module für eine API (Application Programming Interface) schreiben. Die API ist flexibel, einfach zu verwenden und plattformunabhängig. Der Proxyserver führt für jede von ihm verarbeitete Clientanforderung eine Reihe von Schritten aus. Eine Plug-in-Anwendung ändert oder ersetzt einen Schritt der Anforderungsverarbeitung, z. B. die Clientauthentifizierung oder das Filtern der Anforderungen. Die leistungsfähige Schnittstelle Transmogrify unterstützt beispielsweise den Zugriff auf HTTP-Daten und das Ersetzen oder Umwandeln von URLs und Webinhalten. Plug-ins können bestimmte Verarbeitungsschritte ändern oder ersetzen. Außerdem können für einen bestimmten Schritt mehrere Plug-ins aufgerufen werden.
Mit Load Balancer werden Systeme an der Grenze (Edge) des Netzes erstellt, die die Datenübertragungen auf dem Netz steuern. Auf diese Weise kann eine Überlastung des Netzes weitgehend vermieden und die Arbeitslast auf verschiedene andere Services und Systeme verteilt werden. Load Balancer unterstützt Site-Auswahl, Laststeuerung (WLM, Workload Management), Sitzungsaffinität und transparente Übernahme von Arbeitslasten.
Load Balancer wird zwischen dem Internet und den Back-End-Servern des Unternehmens installiert, bei denen es sich um Inhaltshosts oder Caching-Proxy-Maschinen handeln kann. Load Balancer fungiert als zentraler POP-Knoten (Point-of-Presence, Zugangspunkt) des Unternehmens im Internet, selbst wenn das Unternehmen auf Grund hoher Nachfrage oder großer Inhaltsmengen mehrere Back-End-Server verwendet. Eine hohe Verfügbarkeit ist garantiert, wenn Sie einen Load Balancer als Backup installieren, der bei temporärem Ausfall des primären Load Balancer dessen Aufgaben übernimmt.
Load Balancer fängt Datenanforderungen von Clients ab und leitet jede Anforderung an den Server weiter, der zum gegebenen Zeitpunkt am besten für die Bearbeitung der Anforderung geeignet ist. Anders ausgedrückt, die Last eingehender Anforderungen wird auf eine definierte Menge von Maschinen aufgeteilt, die dieselbe Art von Anforderungen bearbeiten. Load Balancer kann Anforderungen auf viele Servertypen verteilen, darunter WebSphere Application Server und Caching-Proxy-Maschinen. Der Lastausgleich kann für eine bestimmte Anwendung oder Plattform mit benutzerdefinierten Advisor-Funktionen angepasst werden. Es werden spezielle Advisor-Funktionen bereitgestellt, mit denen Informationen für den Lastausgleich in WebSphere Application Server abgerufen werden können.
Wird die Komponente Content Based Routing zusammen mit Caching Proxy installiert, können HTTP- und HTTPS-Anforderungen sogar auf der Grundlage der URLs oder anderer, vom Administrator festgelegter Merkmale verteilt werden. Dadurch entfällt das Speichern identischer Inhalte auf allen Back-End-Servern. Die Komponente Dispatcher kann dieselbe Funktion auch für HTTP-Anforderungen bereitstellen.
Der Lastausgleich verbessert die Verfügbarkeit und Skalierbarkeit Ihrer Website, indem Inhaltsserver, einschließlich HTTP-Server, Anwendungsserver und Proxyserver, die stellvertretend für die Inhaltsserver auftreten, transparent zusammengefasst werden. Durch Parallelschaltung, Lastausgleich und Lastübernahme wird eine hohe Verfügbarkeit sichergestellt. Der Ausfall eines Servers hat keine Unterbrechung von Geschäftsaktivitäten zur Folge. Die Skalierbarkeit einer Infrastruktur verbessert sich erheblich, weil Back-End-Verarbeitungsleistung transparent hinzugefügt werden kann.
Unterstützung für IPv6: Die Unterstützung für das erweiterte IP-Adressierungsschema IPv6 ist in "Load Balancer for IPv4 and IPv6" verfügbar. Load Balancer for IPv4 and IPv6 ist ein gesondertes Installations-Image, das nur die Komponente Dispatcher enthält. Dieser Installationstyp unterstützt den Lastausgleich für IPv4- und IPv6-Datenverkehr mit Servern, die im Netz konfiguriert sind, unter Verwendung der MAC-basierten Paketweiterleitung der Komponente Dispatcher. Alle früheren Versionen von Load Balancer müssen unbedingt deinstalliert werden, bevor Load Balancer for IPv4 and IPv6 installiert wird. Es ist nicht möglich, zwei Versionen von Load Balancer auf einer Maschine zu installieren. (Der Abschnitt Dispatcher enthält eine Kurzübersicht über die Komponente Dispatcher.)
Load Balancer umfasst folgende Komponenten:
Die Komponente Dispatcher führt den Lastausgleich für alle Internet-Services, wie z. B. HTTP, FTP, HTTPS und Telnet, auf den Servern eines lokalen Netzes (LAN) oder eines Weitverkehrsnetzes (WAN) durch. Für HTTP-Services kann Dispatcher den Lastausgleich zwischen den Servern basierend auf dem URL-Inhalt der Clientanforderung durchführen.
Die Komponente Dispatcher erlaubt eine stabile, effiziente Verwaltung eines großen skalierbaren Servernetzes. Mit Hilfe von Dispatcher können Sie viele einzelne Server so miteinander verknüpfen, dass sie als einzelner virtueller Server erscheinen. Den Besuchern stellt sich Ihre Site daher als eine einzelne IP-Adresse dar.
Wenn Sie eine Installation von Load Balancer for IPv4 and IPv6 verwenden, lesen Sie das Kapitel zur Implementierung von Dispatcher in Load Balancer for IPv4 and IPv6 im WebSphere Application Server Load Balancer Administratorhandbuch, das Informationen zu den Einschränkungen und Konfigurationsunterschieden enthält.
Die Komponente Content Based Routing führt den Lastausgleich zwischen den Servern für die Services HTTP und HTTPS basierend auf dem Inhalt der Clientanforderung durch. Die Komponente Content Based Routing arbeitet mit der Komponente Application Server Caching Proxy zusammen.
Wichtig: Die Komponente Content Based Routing (CBR) ist mit folgenden Ausnahmen auf allen unterstützten Plattformen verfügbar:
Für diese Art von Installation können Sie alternativ die Weiterleitungsmethode cbr der Load-Balancer-Komponente Dispatcher verwenden, um das inhaltsbasierte Routing von HTTP- und HTTPS-Anforderungen ohne Verwendung von Caching Proxy zu unterstützen. Nähere Informationen hierzu finden Sie im WebSphere Application Server Load Balancer Administratorhandbuch.
Load Balancer for IPv4 and IPv6 unterstützt nur die Weiterleitungsmethode mac der Komponente Dispatcher. Die Weiterleitungsmethoden nat und cbr werden nicht unterstützt.
Die Komponente Site Selector erweitert ein Lastausgleichsystem, indem sie ihm erlaubt, als POP-Knoten (Point-of-Presence, Zugangspunkt) für ein Netz zu fungieren und ankommende Anforderungen durch Zuordnung von DNS-Namen zu IP-Adressen zu verteilen. Zusammen mit Metric Server kann Site Selector die Aktivitäten eines Servers überwachen, den Server mit der geringsten Auslastung herausfinden und einen Server, der ausgefallen ist, erkennen.
Diese Komponente wird mit folgender Ausnahme in allen Edge-Components-Installationen unterstützt:
Die Komponente Cisco CSS Controller generiert Metrikangaben für die Servergewichtung, die zwecks Serverauswahl, Lastoptimierung und Fehlertoleranz an einen Cisco CSS Switch weitergeleitet werden.
Diese Komponente wird mit folgender Ausnahme in allen Edge-Components-Installationen unterstützt:
Die Komponente Nortel Alteon Controller generiert Metrikangaben für die Servergewichtung, die zwecks Serverauswahl, Lastoptimierung und Fehlertoleranz an einen Nortel Alteon Switch weitergeleitet werden.
Diese Komponente wird mit folgender Ausnahme in allen Edge-Components-Installationen unterstützt:
Die Komponente Metric Server wird als Dämon auf einem Server mit Lastausgleich ausgeführt und liefert der Komponente Load Balancer Informationen über die Systembelastung.
Die IBM WebSphere-Produktfamilie unterstützt Benutzer bei der Realisierung eines eigenen e-business. Es handelt sich bei dieser Produktfamilie um eine Gruppe von Softwareprodukten, die den Benutzer dabei unterstützen, extrem leistungsfähige Websites zu entwickeln und zu verwalten sowie Websites in neue oder vorhandene Informationssysteme außerhalb des Web-Business zu integrieren.
Die WebSphere-Produktfamilie setzt sich zusammen aus WebSphere Application Server mit Edge Components und anderer WebSphere-Software, die eng mit WebSphere Application Server verbunden ist und dessen Leistungsspektrum erweitert. Eine Übersicht über WebSphere Application Server und seine Komponenten enthält Einführung in WebSphere Application Server Edge Components.
Tivoli Access Manager (früher Tivoli Policy Director) ist ein eigenständig verfügbares Produkt. Dieses Produkt ermöglicht die Zugriffssteuerung und zentrale Sicherheitsverwaltung in vorhandenen Webanwendungen und den Zugriff auf mehrere Webressourcen nach einmaliger Authentifizierung. Ein Caching-Proxy-Plug-in nutzt die Sicherheitsfunktionen von Access Manager und erlaubt dadurch dem Proxy-Server, die integrierten Berechtigungs- und Authentifizierungsservices von Access Manager zu verwenden.
WebSphere Portal Server ist ein eigenständig verfügbares Produkt, das ein Gerüst für die Präsentation, Sicherheit, Skalierbarkeit und Verfügbarkeit von Portalen bietet. Mit Hilfe von Portal Server können Unternehmen eigene angepasste Portal-Websites erstellen, um den Anforderungen ihrer Angestellten, Geschäftspartner und Kunden gerecht zu werden. Benutzer können sich am Portal anmelden und erhalten personalisierte Webseiten, die ihnen den Zugang zu den gewünschten Informationen, Personen und Anwendungen liefern. Durch diesen personalisierten, zentralen Zugangspunkt zu allen erforderlichen Ressourcen wird eine Informationsüberflutung verringert, die Produktivität verbessert und die Nutzung der Website erhöht.
WebSphere Portal Server wird zur Gewährleistung von Skalierbarkeit und Zuverlässigkeit in einem WebSphere-Application-Server-Cluster ausgeführt. Ein besserer Lastausgleich und eine noch höhere Verfügbarkeit können durch die zusätzliche Verwendung der Komponente Load Balancer von Application Server erreicht werden.
WebSphere Site Analyzer ist ein eigenständig verfügbares Produkt, das Unternehmen bei der frühzeitigen Erkennung von Kapazitäts- und Leistungsproblemen unterstützt. Mit Site Analyzer können die Protokolle von Caching Proxy und Load Balancer sowie weitere Verwaltungshilfen dazu herangezogen werden, den Bedarf an zusätzlichen Ressourcen festzustellen, indem die Auslastung der Website überwacht, analysiert und in Berichten gespeichert wird. Außerdem unterstützen die Verwaltungskomponenten von Site Analyzer den Benutzer bei Installation und Upgrade von Edge Components, beim Verwalten und Speichern von Konfigurationen, bei der fernen Ausführung von Edge Components sowie beim Anzeigen und Berichten von Ereignissen.
WebSphere Transcoding Publisher ist ein eigenständig verfügbares Produkt, das eine Website so konvertieren kann, dass sie auf einer mobilen Einheit, z. B. auf einem Telefon mit Internet-Unterstützung, anzeigbar ist, Webinhalte (durch Aufruf von WebSphere Translation Server) in die gewünschte Landessprache des Benutzers übersetzen und Markup-Sprachen konvertieren kann. Durch die Möglichkeit, Inhalte für verschiedene Einheiten und Benutzer bereitzustellen, erweitert Transcoding Publisher das Leistungsspektrum von Caching Proxy. Nach dem Zugriff auf die Inhalte eines Webservers kann die Schnittstelle Transmogrify Caching Proxy so konfiguriert werden, dass Transcoding Publisher aufgerufen wird, um die Daten umzuwandeln und für Caching und mögliche Wiederverwendung zu kennzeichnen. An der Schnittstelle von Caching Proxy, die nach der Authentifizierung aufgerufen wird, prüft Transcoding Publisher anschließend den Proxy-Server auf Inhalte, die mit den Benutzer- und Einheitenvoraussetzungen übereinstimmen, und stellt bei Übereinstimmung die Inhalte aus dem Cache des Proxy-Servers bereit.
Im Information Center von Edge Components finden Sie die folgenden Veröffentlichungen zu WebSphere Application Server Edge Components:
Weitere Veröffentlichungen zu WebSphere Application Server finden Sie auf der Bibliotheksseite von WebSphere Application Server.
Technische Unterstützungsinformationen zu Edge Components finden Sie auf der Unterstützungsseite von WebSphere Application Server.
In der folgenden Liste sind die Websites aufgeführt, die Informationen zu Edge Components oder zugehörige Informationen enthalten:
In den detaillierten Erläuterungen in diesem Teil werden einige Funktionen von Edge Components besonders hervorgehoben. Eine Übersicht über die Komponente Caching Proxy von Application Server finden Sie in Einführung in WebSphere Application Server Edge Components.
Dieser Teil enthält folgende Kapitel:
Mit den Caching-Funktionen von Caching Proxy können Sie die Belastung des Netzes verringern und den Endbenutzern einen schnelleren und zuverlässigeren Service gewährleisten. Dies erfolgt durch Entlastung der Back-End-Server und Peer-Links durch das vom Proxy-Server durchgeführte Caching. Caching Proxy kann statische Inhalte und Inhalte, die von WebSphere Application Server dynamisch generiert werden, zwischenspeichern. Zur Verbesserung des Caching arbeitet Caching Proxy außerdem mit der Komponente Application Server Load Balancer zusammen. Eine Einführung in diese Systeme finden Sie in Einführung in WebSphere Application Server Edge Components.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Caching Proxy kann als Reverse-Caching-Proxy-Server (Standardkonfiguration) oder als Forward-Caching-Proxy-Server konfiguriert werden. Für die Verwendung durch Inhaltshosts wird Caching Proxy als Reverse-Caching-Proxy-Server zwischen dem Internet und den Inhaltshosts des Unternehmens konfiguriert. Für die Verwendung durch Internet-Zugriffsprovider wird Caching Proxy als Forward-Caching-Proxy-Server zwischen einem Client und dem Internet konfiguriert.
Wenn Sie eine Reverse-Proxy-Konfiguration verwenden, befinden sich die Caching-Proxy-Maschinen zwischen dem Internet und den Inhaltshosts des Unternehmens. Der Proxy-Server fängt stellvertretend die aus dem Internet ankommenden Benutzeranforderungen ab, leitet diese an den geeigneten Inhaltshost weiter, speichert die zurückgegebenen Daten im Cache und übermittelt sie dann über das Internet an die Benutzer. Durch das Caching ist Caching Proxy in der Lage, nachfolgende Anforderungen für denselben Inhalt direkt aus dem Cache abzurufen. Das ist sehr viel schneller als ein erneuter Abruf des Inhalts vom Inhaltshost. Entscheidungsfaktoren für das Caching von Daten können das Verfallsdatum der Daten, die Größe des Cache und der erforderliche Aktualisierungszeitpunkt für die Daten sein. Schnellere Download-Zeiten für Daten, die bereits im Cache gespeichert sind, bedeuten eine bessere Servicequalität für die Kunden. Abb. 1 stellt diese grundlegende Funktionalität von Caching Proxy dar.
Legende: 1--Client 2--Internet 3--Router/Gateway 4--Caching Proxy 5--Cache 6--InhaltshostIn dieser Konfiguration fängt der Proxy-Server (4) die Anforderungen ab, deren URL den Hostnamen des Inhaltshost (6) enthalten. Wenn ein Client (1) die Datei X anfordert, wird die Anforderung über das Internet (2) gesendet und erreicht das interne Unternehmensnetz über das Internet-Gateway (3) des Unternehmens. Der Proxy-Server fängt die Anforderung ab, generiert eine neue Anforderung mit seiner eigenen IP-Adresse als Ursprungsadresse und sendet die neue Anforderung an den Inhaltshost (6).
Der Inhaltshost gibt die Datei X nicht direkt an den Endbenutzer, sondern an den Proxy-Server zurück. Wenn die Datei für Caching geeignet ist, speichert der Caching-Proxy-Server eine Kopie der Datei in seinem Cache (5), bevor er die Datei an den Endbenutzer übergibt. Statische Webseiten sind das bekannteste Beispiel für Inhalte, die für Caching geeignet sind. Allerdings erlaubt Caching Proxy auch das Caching und Bereitstellen von Inhalten, die WebSphere Application Server dynamisch generiert.
Die Bereitstellung eines direkten Internet-Zugangs für Endbenutzer kann sehr ineffizient sein. Jeder Benutzer, der eine bestimmte Datei von einem Webserver abruft, generiert dasselbe Datenverkehrsvolumen in Ihrem Netz und über das Internet-Gateway wie der erste Benutzer, der die Datei abgerufen hat, selbst wenn diese Datei nicht geändert wurde. Die Lösung ist die Installation eines Forward Caching Proxy in der Nähe des Gateway.
Wenn Sie eine Forward-Proxy-Konfiguration verwenden, befinden sich die Caching-Proxy-Maschinen zwischen dem Client und dem Internet. Caching Proxy leitet eine Clientanforderung an Inhaltshosts im Internet weiter, stellt die abgerufenen Daten in den Cache und stellt die abgerufenen Daten dem Client zu.
Abb. 2 zeigt die Forward-Caching-Proxy-Konfiguration. Die Browser-Programme des Clients (auf den mit 1 gekennzeichneten Maschinen) sind so konfiguriert, dass sie Anforderungen an den Forward Caching Proxy (2) weiterleiten, der die Anforderungen abfängt. Wenn ein Endbenutzer Datei X anfordert, die auf dem Inhaltshost (6) gespeichert ist, fängt der Forward Caching Proxy die Anforderung ab, generiert eine neue Anforderung mit seiner eigenen IP-Adresse als Ursprungsadresse und sendet die neue Anforderung über den Router (4) des Unternehmens über das Internet (5).
Der Ursprungsserver gibt die Datei X an den Forward Caching Proxy und nicht direkt an den Endbenutzer zurück. Wenn die Caching-Funktion des Forward Caching Proxy aktiviert ist, ermittelt Caching Proxy, ob die Datei X zwischengespeichert werden kann, indem er die Einstellungen im zurückgegebenen Header, z. B. das Verfallsdatum und etwaige Angaben zur dynamischen Generierung der Datei, prüft. Wenn die Datei zwischenspeicherbar ist, speichert Caching Proxy eine Kopie der Datei in seinem Cache (3), bevor die Datei an den Endbenutzer übergeben wird. Standardmäßig ist das Caching aktiviert, und der Forward Caching Proxy verwendet einen Hauptspeicher-Cache. Sie können jedoch auch andere Typen von Caching konfigurieren.
Für die erste Anforderung der Datei X bietet der Forward Caching Proxy keinen wesentlich effizienteren Zugang zum Internet. In der Tat ist die Antwortzeit für den ersten Benutzer, der auf die Datei X zugreift, wahrscheinlich länger als ohne den Forward Caching Proxy, weil es geringfügig länger dauert, bis der Forward Caching Proxy das ursprüngliche Anforderungspaket verarbeitet und den empfangenen Header der Datei X nach Caching-Informationen durchsucht hat. Die Verwendung des Forward Caching Proxy bringt dann Vorteile, wenn weitere Benutzer die Datei X anfordern. Der Forward Caching Proxy prüft, ob seine zwischengespeicherte Kopie der Datei X noch gültig ist (nicht verfallen ist), und stellt bei positivem Ergebnis dieser Prüfung die Datei X direkt aus dem Cache bereit, ohne die Anforderung über das Internet an den Inhaltshost weiterzuleiten.
Selbst wenn der Forward Caching Proxy feststellt, dass eine angeforderte Datei verfallen ist, ruft er die Datei nicht zwingenderweise erneut vom Inhaltshost ab. Stattdessen sendet er eine spezielle Statusprüfnachricht an den Inhaltshost. Wenn der Inhaltshost anzeigt, dass die Datei nicht geändert wurde, kann der Forward Caching Proxy die zwischengespeicherte Version dem anfordernden Benutzer bereitstellen.
Eine solche Konfiguration von Caching Proxy wird als Forward Proxy bezeichnet, weil Caching Proxy für die Browser auftritt und ihre Anforderungen über das Internet an Inhaltshosts weiterleitet. Die Vorteile eines Forward Proxy sind im Folgenden aufgeführt:
Caching Proxy kann mehrere Netzübertragungsprotokolle unterstützen, z. B. HTTP (Hypertext Transfer Protocol, FTP (File Transfer Protocol) und Gopher.
Eine Variante von Caching Proxy als Forward-Proxy-Server ist ein transparenter Caching Proxy. In dieser Rolle führt Caching Proxy dieselbe Funktion wie ein Basis-Forward-Caching-Proxy aus, aber der Client ist sich seiner Präsenz nicht bewusst. Die transparente Caching-Proxy-Konfiguration wird nur auf Linux-Systemen unterstützt.
In der im Abschnitt Forward Caching Proxy beschriebenen Konfiguration wird jeder Client-Browser separat konfiguriert, um Anforderungen an einen bestimmten Forward Caching Proxy weiterzuleiten. Die Pflege einer solchen Konfiguration kann aufwendig werden, insbesondere wenn viele Clientmaschinen beteiligt sind. Caching Proxy unterstützt mehrere Alternativen, die die Verwaltung vereinfachen. Eine Möglichkeit ist die Konfiguration von Caching Proxy als transparenter Proxy, wie in Abb. 3 gezeigt wird. Wie ein regulärer Forward Caching Proxy wird der transparente Caching Proxy auf einer Maschine in der Nähe des Gateway installiert, aber die Browser-Programme der Clients werden nicht so konfiguriert, dass sie Anforderungen an einen Forward Caching Proxy weiterleiten. Die Clients sind sich nicht bewusst, dass ein Proxy-Server in der Konfiguration vorhanden ist. Stattdessen wird ein Router konfiguriert, der die Clientanforderungen abfängt und an den transparenten Caching Proxy weiterleitet. Wenn ein Client, der auf einer der mit 1 gekennzeichneten Maschinen arbeitet, die Datei X anfordert, die auf einem Inhaltshost (6) gespeichert ist, übergibt der Router (2) die Anforderung an Caching Proxy. Caching Proxy generiert eine neue Anforderung mit seiner eigenen IP-Adresse als Ursprungsadresse und sendet die neue Anforderung über den Router (2) über das Internet (5). Wenn die Datei X ankommt, stellt Caching Proxy die Datei in den Cache (sofern die im Abschnitt Forward Caching Proxy beschriebenen Bedingungen zutreffen) und übergibt die Datei anschließend an den anfordernden Client.
Für HTTP-Anforderungen ist eine weitere mögliche Alternative für die Pflege der Proxy-Konfigurationsdaten in jedem Browser die Verwendung der Funktion für automatische Proxy-Konfiguration, die in mehreren Browser-Programmen, einschließlich Netscape Navigator ab Version 2.0 und Microsoft Internet Explorer ab Version 4.0 verfügbar ist. In diesem Fall erstellen Sie eine oder mehrere zentrale PAC-Dateien (Proxy Automatic Configuration) und zeigen in den Browsern auf eine dieser Dateien anstatt auf die lokalen Proxy-Konfigurationsdaten. Der Browser erkennt Änderungen an der PAC-Datei automatisch und passt die Proxy-Verwendung entsprechend an. Diese Methode macht nicht nur die Verwaltung separater Konfigurationsdaten in jedem Browser überflüssig, sondern vereinfacht auch die Weiterleitung von Anforderungen, wenn ein Proxy-Server nicht verfügbar ist.
Eine dritte Alternative ist die Verwendung des Mechanismus Web Proxy Auto Discovery (WPAD), der in einigen Browser-Programmen, z. B. Internet Explorer ab Version 5.0 verfügbar ist. Wenn Sie diese Funktion im Browser aktivieren, sucht der Browser automatisch einen WPAD-kompatiblen Proxy-Server in seinem Netz und leitet seine Webanforderungen dorthin weiter. In diesem Fall müssen Sie keine zentralen Proxy-Konfigurationsdateien verwalten. Caching Proxy ist WPAD-kompatibel.
Eine erweiterte Caching-Funktionalität erhalten Sie, wenn Sie Caching Proxy als Reverse Proxy zusammen mit der Komponente Load Balancer verwenden. Durch die Kombination von Caching- und Lastausgleichsfunktionen erhalten Sie eine effiziente und einfach zu handhabende Infrastruktur für Webauftritte.
Abb. 4 zeigt, wie Sie Caching Proxy mit Load Balancer kombinieren können, um Webinhalte selbst bei hohem Bedarf effizient bereitzustellen. In dieser Konfiguration ist der Proxy-Server (4) so konfiguriert, dass er die Anforderungen abfängt, deren URL den Hostnamen eines Cluster von Inhaltshosts (7) enthält, in dem Load Balancer (6) für den Lastausgleich zuständig ist.
Legende: 1--Client 2--Internet 3--Router/Gateway 4--Caching Proxy 5--Cache 6--Load Balancer 7--InhaltshostWenn ein Client (1) die Datei X anfordert, wird die Anforderung über das Internet (2) gesendet und erreicht das interne Unternehmensnetz über das Internet-Gateway (3) des Unternehmens. Der Proxy-Server fängt die Anforderung ab, generiert eine neue Anforderung mit seiner eigenen IP-Adresse als Ursprungsadresse und sendet die neue Anforderung an den Load Balancer an die Adresse des Clusters. Load Balancer verwendet seinen Algorithmus für Lastausgleich, um den Inhaltshost zu ermitteln, der zum gegebenen Zeitpunkt am besten für die Verarbeitung der Anforderung von Datei X geeignet ist. Der Inhaltshost gibt die Datei X an den Proxy-Server zurück, anstatt sie über Load Balancer weiterzuleiten. Der Proxy-Server bestimmt, ob die Datei im Cache gespeichert wird, und liefert die Datei wie zuvor beschrieben an den Endbenutzer.
Erweiterte Caching-Funktionen werden auch vom Plug-in Dynamic Caching von Caching Proxy bereitgestellt. Zusammen mit WebSphere Application Server verwendet, kann Caching Proxy dynamische Inhalte in Form von JSPs (JavaServer Pages) und Servlet-Antworten, die von einem WebSphere Application Server generiert werden, im Cache speichern, bereitstellen und ungültig machen (invalidieren).
Im Allgemeinen müssen dynamische Inhalte mit unbegrenzter Verfallszeit als "nicht Cache-fähig" gekennzeichnet werden, weil die zeitbasierte Standardverfallslogik für Cache-Einträge nicht sicherstellen kann, dass derartige Inhalte in angemessener Zeit aus dem Cache entfernt werden. Die ereignisgesteuerte Verfallslogik des Plug-in Dynamic Caching hingegen unterstützt das Caching von Inhalten mit unbestimmter Verfallszeit durch Proxy-Server. Das Caching solcher Inhalte an den Grenzen (Edge) des Netzes entlastet die Inhaltshosts insofern, dass Application Server nicht wiederholt abgefragt werden müssen, um Clientanforderungen zu bedienen. Dies kann folgende Vorteile haben:
Das Caching von Servlet-Antworten eignet sich ideal für dynamisch erstellte Web-seiten, deren Verfallszeit auf der Anwendungslogik oder auf einem Ereignis, z. B. der Nachricht von einer Datenbank, basiert. Obwohl die Lebensdauer einer solchen Seite begrenzt ist, kann der Wert für die Lebensdauer (TTL, Time-to-Live) zum Zeitpunkt der Erstellung nicht festgelegt werden, weil der Auslöser für den Verfall nicht im Vorhinein bekannt ist. Wird die Lebensdauer für solche Seiten auf null gesetzt, wirkt sich das Bereitstellen dynamischer Inhalte extrem nachteilig auf die Inhaltshosts aus.
Zuständig für die Synchronisation des dynamischen Cache von Caching Proxy und Application Server sind beide Systeme. Beispielsweise kann eine öffentliche Web- seite, die von einer Anwendung dynamisch erstellt wurde, die aktuelle Wettervorhersagen meldet, von Application Server exportiert und von Caching Proxy im Cache gespeichert werden. Caching Proxy kann anschließend die Ausführungsergebnisse der Anwendung so oft an viele verschiedene Benutzer liefern, bis er darüber benachrichtigt wird, dass die Seite ungültig ist. Der Inhalt im Caching-Proxy-Cache für Servlet-Antworten bleibt so lange gültig, bis der Proxy-Server einen Eintrag löscht, weil der Cache überlastet ist, bis das von der Anweisung ExternalCacheManager in der Konfigurationsdatei von Caching Proxy gesetzte Standardzeitlimit abläuft oder Caching Proxy eine Invalidierungsnachricht empfängt, in der er zum Löschen des Inhalts aus dem Cache angewiesen wird. Invalidierungsnachrichten stammen immer vom WebSphere Application Server, der Eigner des Inhalts ist, und werden an jeden konfigurierten Caching Proxy weitergegeben.
Caching Proxy stellt weitere wichtige Funktionen für erweitertes Caching bereit:
Die Einführung der Caching-Proxy-Funktionalität wirkt sich auf die Netzleistung aus. Sie können die Leistung Ihres Netzes verbessern, indem Sie Caching Proxy allein oder zusammen mit Load Balancer verwenden. Eine Einführung in diese Systeme finden Sie in Einführung in WebSphere Application Server Edge Components.
Die Leistung der Software Caching Proxy in Ihrem Unternehmen ist jedoch direkt abhängig von der Hardware, auf der sie ausgeführt wird, und von der Gesamtarchitektur des Systems, in dem sie eingesetzt wird. Zur Optimierung der Netzleistung sollten Sie die Hardware- und Gesamtnetzarchitektur gemäß den Anforderungen der Proxy-Server gestalten.
Die Basiskonfiguration und -verwaltung der Software Caching Proxy sowie die Optimierung auf Betriebssystemebene können in erheblichem Maße zur Leistung von Caching Proxy beitragen. Sie können zahlreiche Softwarekonfigurationsänderungen vornehmen, die eine bessere Leistung zur Folge haben. Dazu gehören unter anderem das Anpassen von Protokollanweisungen, Zuordnungsregeln, Plug-ins, Zeitlimitwerten, Cache-Konfigurationswerten und Werten für aktive Threads. Detaillierte Angaben zur Konfiguration der Caching-Proxy-Software enthält das Caching Proxy Administratorhandbuch.
Viele Änderungen an der Konfiguration des Betriebssystems können die Leistung ebenfalls verbessern. Dazu gehören unter anderem die Optimierung von TCP und ARP, höhere Grenzwerte für Dateideskriptoren, Synchronisation der Systemuhren, Optimierung der Network Interface Cards (NICs) und Befolgen der empfohlenen Praktiken zur Ausführung von Systemverwaltungs-Tasks.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
In diesem Abschnitt werden Aspekte der Netzhardware beschrieben, die Sie bei Einführung der Caching-Proxy-Funktionalität in Ihr Netz beachten müssen.
Dem Proxy-Server muss eine große Menge an Speicher zugeordnet werden. Caching Proxy kann 2 GB virtuellen Adressraum belegen, wenn ein großer Speicher-Cache konfiguriert wird. Außerdem wird Speicherplatz für den Kernel, gemeinsam benutzte Bibliotheken und Netzpuffer benötigt. Daher ist ein physischer Speicherbedarf von 3 oder 4 GB für einen Proxy-Server nicht ungewöhnlich. Beachten Sie, dass ein Speicher-Cache erheblich schneller ist als ein Rohplatten-Cache und eine solche Konfigurationsänderung allein schon eine Leistungsverbesserung darstellt.
Auf der Maschine, auf der Caching Proxy installiert wird, muss viel Plattenspeicherplatz verfügbar sein. Dies gilt insbesondere dann, wenn Platten-Caches verwendet werden. Das Lesen von einer und Schreiben auf eine Festplatte sind für einen Computer rechenintensive Prozesse. Obwohl Caching Proxy effiziente E/A-Prozeduren verwendet, können die mechanischen Grenzen von Festplatten die Leistung beeinträchtigen, wenn in der Konfiguration von Caching Proxy die Verwendung eines Platten-Cache vorgesehen ist. Der Engpass, der aus der Platten-E/A resultiert, kann beispielsweise durch Verwendung mehrerer Festplatten für Cache-Roheinheiten (Raw Cache Devices) und durch Protokolldateien sowie durch Verwendung von Plattenlaufwerken mit kurzen Suchzeiten, hohen Umdrehungsgeschwindigkeiten und hohen Übertragungsgeschwindigkeiten beseitigt werden.
Die Anforderungen des Netzes wie Geschwindigkeit, Art und Zahl der NICs und Geschwindigkeit der Netzverbindung zum Proxy-Server beeinflussen die Leistung von Caching Proxy. Im Allgemeinen ist es der Leistung dienlich, wenn auf einer Proxyservermaschine zwei NICs verwendet werden: eine für ankommende Datenübertragungen und eine für abgehende Datenübertragungen. Eine einzelne NIC erreicht ihr Limit wahrscheinlich bereits allein durch die HTTP-Anforderungen und -Antworten. Außerdem sollten NICs mindestens eine Kapazität von 100 MB besitzen und immer für Vollduplexbetrieb konfiguriert sein, weil bei einer automatischen Vereinbarung zwischen Routing- und Switching-Einheiten Fehler auftreten können, die sich negativ auf den Durchsatz auswirken. Schließlich ist die Übertragungsgeschwindigkeit in der Netzverbindung von großer Bedeutung. Sie können beispielsweise nicht erwarten, eine hohe Anforderungslast zu verarbeiten und gleichzeitig einen optimalen Durchsatz zu erzielen, wenn die Verbindung zur Caching-Proxy-Maschine über einen ausgelasteten T1-Träger erfolgt.
Die Zentraleinheit (Central Processing Unit, CPU) einer Caching-Proxy-Maschine kann eventuell zu einem einschränkenden Faktor für die Leistung werden. Die CPU-Leistung wirkt sich aus auf die Zeit, die zur Verarbeitung von Anforderungen benötigt wird, und die Anzahl der CPUs im Netz hat Auswirkungen auf die Skalierbarkeit. Es ist von großer Bedeutung, dass Sie die CPU-Anforderungen des Proxyservers an die Umgebung anpassen, wobei Sie insbesondere die Spitzenauslastung berücksichtigen müssen, die vom Proxy-Server bewältigt werden soll.
Für die Gesamtleistung ist es im Allgemeinen vorteilhaft, die Architektur als Ganzes zu skalieren und nicht nur einzelne Hardwarekomponenten. Unabhängig davon, wie viel Hardware Sie einer einzelnen Maschine hinzufügen, diese Hardware hat trotzdem eine maximale Leistungsgrenze.
In diesem Abschnitt werden Aspekte der Netzarchitektur beschrieben, die Sie bei Einführung der Caching-Proxy-Funktionalität in Ihr Netz beachten müssen.
Ist die Website Ihres Unternehmens sehr populär, besteht unter Umständen eine höhere Nachfrage nach Inhalten, als ein einzelner Proxy-Server verarbeiten kann, was lange Antwortzeiten zur Folge haben kann. Zur Optimierung der Netzleistung sollten Sie in Erwägung ziehen, Cluster von Proxyserver-Maschinen mit Lastausgleich oder eine Architektur mit gemeinsamem Cache und RCA (Remote Cache Access) in Ihrer Gesamtnetzarchitektur einzusetzen.
Eine Möglichkeit zum Skalieren der Architektur besteht darin, dass Sie Cluster von Proxy-Servern bilden und die Komponente Load Balancer für die Verteilung der Arbeitslast auf diese Proxyserver verwenden. Das Clustering von Proxy-Servern ist eine nützliche Designmaßnahme, die sich nicht nur auf Leistung und Skalierbarkeit vorteilhaft auswirkt, sondern auch Redundanzen vermeidet und die Zuverlässigkeit erhöht. Ein einzelner Proxy-Server stellt einen Single Point of Failure dar. Falls er ausfällt oder aufgrund eines Netzfehlers nicht mehr zugänglich ist, können die Benutzer nicht mehr auf die Website zugreifen.
Sie sollten auch eine Architektur mit gemeinsamem Cache und RCA in Erwägung ziehen. In einer Architektur mit gemeinsamem Cache wird der gesamte virtuelle Cache auf mehrere Caching-Proxy-Server verteilt. Diese Server verwenden in der Regel ein Intercache-Protokoll wie Internet Cache Protocol (ICP) oder Cache Array Routing Protocol (CARP). RCA dient dazu, die Trefferquoten im Cache eines Clusters zu erhöhen, indem ein großer virtueller Cache bereitgestellt wird.
Leistungsverbesserungen werden erzielt, indem anstelle einer einzelnen Stand-alone-Caching-Proxy-Maschine oder auch eines Clusters von Standalone-Caching-Proxy-Maschinen eine RCA-Gruppe von Proxy-Servern verwendet wird. In der Regel werden die Leistungsverbesserungen durch die höhere insgesamt verfügbare virtuelle Cache-Kapazität erzielt, wodurch sich die Cache-Trefferquote erhöht und Abweichungen und Verzögerungen im Cache auf ein Minimum reduziert werden. Bei Verwendung von RCA wird nur eine Kopie eines gegebenen Dokuments im Cache gespeichert. Bei einem Cluster von Proxy-Servern erhöht sich zwar die Cache-Kapazität insgesamt, aber wahrscheinlich werden jedoch mehrere Proxyserver dieselben Informationen abrufen und zwischenspeichern. Die Gesamttrefferquote im Cache erhöht sich folglich nicht.
RCA wird in der Regel in großen Unternehmen eingesetzt, die Inhaltshosts verwenden. Allerdings sind die Vorteile von RCA nicht nur auf den Einsatz in sehr großen Unternehmen beschränkt. Sie können RCA beispielsweise auch dann einsetzen, wenn die Arbeitslast im Netz die Verwendung eines Clusters von Cache-Servern erfordert und die Mehrzahl der Anforderungen sich auf im Cache gespeicherte Informationen beziehen. In bestimmten Netzkonfigurationen führt der Einsatz von RCA jedoch nicht zu einer besseren Leistung im Unternehmen. Dies hängt mit der größeren Zahl von TCP-Verbindungen zusammen, die ein Client verwendet, wenn RCA konfiguriert wird. Ein RCA-Member ist nämlich nicht nur dafür verantwortlich, die URLs bereitzustellen, für die es selbst die höchste Trefferquote aufweist, sondern es muss auch Anforderungen an andere Member oder Cluster weiterleiten, wenn es eine URL-Anforderung erhält, für die es selbst nicht die höchste Trefferquote hat. Dies bedeutet, dass ein bestimmtes Member einer RCA-Gruppe mehr offene TCP-Verbindungen haben kann, als dies der Fall wäre, wenn es als Standalone-Server arbeiten würde.
Einen großen Beitrag zur Leistungsverbesserung leisten die Caching-Funktionen von Caching Proxy. Der Cache des Proxy-Servers kann jedoch einen Engpass darstellen, wenn er nicht ordnungsgemäß konfiguriert ist. Um die beste Cache-Konfiguration zu bestimmen, ist es notwendig, einen größeren Aufwand zu betreiben und die Merkmale des Datenverkehrs genau zu analysieren. Art, Größe, Menge und Attribute des Inhalts haben Auswirkungen auf die Leistung des Proxy-Servers, was sich in der Zeit, die zum Abrufen eines Dokuments von den Ursprungsservern benötigt wird, und in der Arbeitslast des Servers bemerkbar macht. Wenn Sie die Art des Datenverkehrs bestimmen können, den Caching Proxy weiterleitet oder aus seinem Cache bedient, dann können Sie diese Merkmale bei der Konfiguration des Proxy-Servers berücksichtigen. Wenn Sie beispielsweise wissen, dass 80 % der im Cache gespeicherten Objekte Bilder sind (*.gif oder *.jpg) und ungefähr eine Größe von 200 KB aufweisen, dann ist diese Information für Sie sicher nützlich bei der Optimierung der Caching-Parameter und beim Festlegen der Cache-Größe. Wenn Sie darüber hinaus wissen, dass die meisten Inhalte angepasste dynamische Seiten sind, die nicht im Cache gespeichert werden, dann kann Ihnen dies ebenfalls bei der Optimierung von Caching Proxy helfen.
Indem Sie die Merkmale des Datenverkehrs analysieren, können Sie bestimmen, ob Sie die Leistung des Cache eher durch einen Speicher-Cache oder eher durch einen Platten-Cache optimieren können. Außerdem hilft Ihnen die Kenntnis der Merkmale des Netzverkehrs bei der Entscheidung, ob durch das dynamische Caching von Caching Proxy eine Leistungsverbesserung erzielt werden könnte.
Platten-Caches eignen sich für Sites, für die große Datenmengen zwischengespeichert werden müssen. Wenn der Inhalt der Site umfangreich (mehr als 5 GB) ist und eine Cache-Trefferquote von 80 bis 90 % aufweist, dann ist die Verwendung eines Platten-Cache zu empfehlen. Allerdings ist bekannt, dass ein Speicher-(RAM)-Cache schneller ist, und es gibt viele Szenarios, in denen sich ein Speicher-Cache auch für große Sites eignet. Wenn die Cache-Trefferquote von Caching Proxy beispielsweise nicht so wichtig ist oder eine Konfiguration mit gemeinsamem Cache verwendet wird, empfiehlt sich die Verwendung eines Speicher-Cache.
Caching Proxy kann dynamische Inhalte (JSPs und Servlet-Antworten), die vom dynamischen Cache des WebSphere Application Server generiert werden, zwischenspeichern und ungültig machen (invalidieren) und ermöglicht auf diese Weise eine virtuelle Erweiterung des Cache von Application Server auf netzgestützte Caches. Das Caching von dynamisch generierten Inhalten verbessert die Netzleistung in einer Umgebung, in der viele Anforderungen nach dynamisch generierten öffentlichen Webseiten gestellt werden, wobei diese Webseiten auf der Basis der Anwendungslogik oder auf der Basis eines Ereignisses, z. B. einer Nachricht von einer Datenbank, verfallen. Die Lebensdauer der Seite ist zwar begrenzt, aber zum Zeitpunkt ihrer Erstellung kann kein Verfallsauslöser definiert werden. Aus diesem Grund müssen Hosts ohne dynamisches Caching und Invalidierungsfunktion einer solchen Seite eine Lebensdauer von null zuweisen.
Wird eine solche dynamisch generierte Seite während ihrer Lebensdauer von einem oder mehreren Benutzern häufiger angefordert, dann bietet das dynamische Caching eine wertvolle Entlastung und verringert die Arbeitslast der Inhaltshosts im Netz. Mit dynamischem Caching verbessert sich auch die Netzleistung, weil Benutzer aufgrund der geringeren Netzverzögerungen und der geringeren Arbeitslast im Netz, die durch weniger Internet-Abfragen erreicht wird, schneller bedient werden können.
Durch die Verwendung der Komponente Load Balancer von Application Server zusammen mit Inhaltshosts wie WebSphere Application Server oder mit der Komponente Caching Proxy von Application Server können Sie Verfügbarkeit und Skalierbarkeit Ihres Netzes verbessern. (Eine Einführung in diese Komponenten von Edge Components finden Sie in Einführung in WebSphere Application Server Edge Components.) Load Balancer wird in Unternehmensnetzen verwendet und zwischen dem Internet und den Back-End-Servern des Unternehmens installiert. Load Balancer fungiert als Zugangspunkt (POP, Point-of-Presence) des Unternehmens im Internet, selbst wenn das Unternehmen auf Grund des hohen Bedarfs oder großer Inhaltsmengen mehrere Back-End-Server verwendet.
Die Verfügbarkeit wird durch Lastausgleich und Übernahme der Arbeitslast bei Ausfall eines Servers (Failover) erzielt.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
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 MAC-gestützte Weiterleitung 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 Gewichtungen 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) zurzeit 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.
Load Balancer tritt als zentraler Zugangspunkt (POP, Point-of-Presence) für die Inhaltshosts Ihres Unternehmens auf. Ein zentraler Zugangspunkt erweist sich als vorteilhaft, weil Sie den Hostnamen und die Adresse des Clusters im DNS veröffentlichen und nicht die Hostnamen und Adressen der einzelnen Inhaltshosts. Dies bietet einen gewissen Schutz vor unbefugten Zugriffen und die Möglichkeit einer einheitlichen Darstellung der Website Ihres Unternehmens. Um die Verfügbarkeit der Website zu verbessern, sollten Sie einen weiteren Load Balancer konfigurieren, der als Backup für den primären Load Balancer fungiert (siehe Abb. 10). Falls ein Load Balancer ausfällt oder aufgrund eines Netzfehlers nicht mehr zugänglich ist, können die Endbenutzer trotzdem auf die Inhaltshosts zugreifen.
Legende: 1--Client 2--Internet 3--Router/Gateway 4--Primärer Dispatcher 5--Backup-Dispatcher 6--InhaltshostIn der Regel sendet ein Browser, der auf einer der Maschinen 1 ausgeführt wird, seine Anforderung für die Datei X an den Cluster-Hostnamen, der dem primären Load Balancer (4) zugeordnet ist. Der Dispatcher leitet die Anforderung an den Inhaltshost (6) weiter, der auf der Grundlage der Kriterien für Lastausgleich vom Dispatcher ausgewählt wurde. Der Inhaltshost sendet die Datei X über das Gateway des Unternehmens (3) durch das Internet (2) direkt an den Browser weiter, wobei Load Balancer übergangen wird.
Der Backup-Dispatcher (5) führt keinen Lastausgleich durch, solange der primäre Dispatcher ordnungsgemäß funktioniert. 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 Cluster-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 Inhaltshosts aus und fungiert gleichzeitig als Backup für den jeweils anderen.(In Installationen von Load Balancer for IPv4 and IPv6 wird die einfache hohe Verfügbarkeit unterstützt, die gegenseitige hohe Verfügbarkeit jedoch nicht.)
In der Regel verbraucht der Dispatcher nicht sehr viele Verarbeitungs- und Speicherressourcen, und auf der Load-Balancer-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 einer der Maschinen im Cluster ausgeführt werden, für die der Lastausgleich durchgeführt wird. Abb. 11 veranschaulicht eine Konfiguration, in der der Backup-Dispatcher auf einem der Inhaltshosts (5) im Cluster ausgeführt wird.
Legende: 1--Client 2--Internet 3--Router/Gateway 4--Primärer Dispatcher 5--Backup-Dispatcher und Inhaltshost 6--InhaltshostWichtig: Die Komponente Content Based Routing (CBR) ist mit folgenden Ausnahmen auf allen unterstützten Plattformen verfügbar:
Für diese Art von Installation können Sie alternativ die Weiterleitungsmethode cbr der Load-Balancer-Komponente Dispatcher verwenden, um das inhaltsbasierte Routing von HTTP- und HTTPS-Anforderungen ohne Verwendung von Caching Proxy zu unterstützen. Nähere Informationen hierzu finden Sie im WebSphere Application Server Load Balancer Administratorhandbuch.
Load Balancer for IPv4 and IPv6 unterstützt nur die Weiterleitungsmethode mac der Komponente Dispatcher. Die Weiterleitungsmethoden nat und cbr werden nicht unterstützt.
Bei Verwendung zusammen mit der Komponente Application Server Caching Proxy erlaubt Ihnen die Komponente Application Server Load Balancer, die Anforderungen an mehrere Back-End-Server zu verteilen, auf denen unterschiedliche Inhalte gespeichert sind. (Eine Einführung in diese Komponenten von Edge Components finden Sie in Einführung in WebSphere Application Server Edge Components.)
Wenn die Komponente CBR (Content Based Routing) von Load Balancer zusammen mit Caching Proxy installiert wird, können HTTP-Anforderungen auf der Basis des URL oder auf der Basis von anderen vom Administrator festgelegten Merkmalen verteilt werden, wodurch das Speichern identischer Inhalte auf allen Back-End-Servern entfällt.
Die Verwendung von CBR ist insbesondere dann zu empfehlen, wenn Ihre Webserver unterschiedliche Funktionen ausführen oder verschiedene Arten von Services anbieten. So muss z. B. die Website eines Onlinehändlers sowohl den Katalog anzeigen, der zum großen Teil statisch ist, als auch Aufträge annehmen, was bedeutet, dass eine interaktive Anwendung, z. B. ein CGI-Script (CGI = Common Gateway Interface), ausgeführt werden muss, die Artikelnummern und Kundendaten bearbeitet. Häufig ist es effektiver, zwei Gruppen von Maschinen für die Durchführung unterschiedlicher Funktionen einzusetzen und CBR für die Weiterleitung der unterschiedlichen Arten von Datenverkehr an die Maschinen zu verwenden. In ähnlicher Weise kann ein Unternehmen CBR verwenden, um zahlenden Kunden einen besseren Service zu bieten als Gelegenheitsbesuchern, indem die "bezahlten" Anforderungen an leistungsfähigere Webserver geleitet werden.
CBR leitet Anforderungen auf der Grundlage von Regeln weiter, die Sie festlegen. Die bekannteste Regelart ist die Inhaltsregel, die Anforderungen abhängig vom Pfadnamen im URL weiterleitet. Beispielsweise kann das Unternehmen ABC Regeln schreiben, die Anforderungen für den URL http://www.abc.com/catalog_index.html an einen Server-Cluster und Anforde-rungen für den URL http://www.abc.com/orders.html an einen anderen Cluster leiten. Es gibt außerdem Regeln, die Anforderungen abhängig von der IP-Adresse des sendenden Clients oder auf der Grundlage anderer Merkmale weiterleiten. Eine Beschreibung dieser Regeln finden Sie im WebSphere Application Server Load Balancer Administratorhandbuch in den Kapiteln über die Konfiguration von CBR und über die komplexeren Funktionen von Load Balancer und CBR. Die Syntaxdefinitionen für die Regeln finden Sie im WebSphere Application Server Load Balancer Administratorhandbuch im Anhang über die Arten von CBR-Regeln.
Abb. 12 zeigt eine einfache Konfiguration, in der die Komponente CBR von Load Balancer und Caching Proxy zusammen auf der Maschine 4 installiert sind und Anforderungen an die drei Inhaltshosts (6, 7 und 8) weiterleiten, wobei auf jedem Inhaltshost andere Inhalte gespeichert sind. Wenn ein Endbenutzer an einer der mit 1 markierten Maschinen die Datei X anfordert, wird die Anforderung über das Internet (2) gesendet. Die Anforderung erreicht das interne Unternehmensnetz über das Internet-Gateway (3) des Unternehmens. Der Proxy-Server fängt die Anforderung ab und übergibt sie an die Komponente CBR auf derselben Maschine. Dort wird der URL in der Anforderung syntaktisch analysiert, und es wird ermittelt, dass der Inhaltshost 6 die Datei X enthält. Anschließend generiert der Proxy-Server eine neue Anforderung für die Datei X und stellt, sofern die Caching-Funktion aktiviert ist, fest, ob sich die Datei für die Speicherung im Cache eignet, sobald sie von Host 6 zurückgegeben wird. Wenn eine Speicherung der Datei im Cache möglich ist, speichert der Proxyserver eine Kopie der Datei in seinem Cache (5), bevor er die Datei an den Endbenutzer übergibt. Das Routing für andere Dateien erfolgt auf dieselbe Weise: Anforderungen für die Datei Y werden an den Inhaltshost 7 weitergeleitet, und Anforderungen für Datei Z werden an den Inhaltshost 8 weitergeleitet.
Legende: 1--Client 2--Internet 3--Router/Gateway 4--Caching Proxy und die Komponente CBR von Load Balancer 5--Cache 6, 7, 8--InhaltshostAbb. 13 veranschaulicht eine komplexere Konfiguration, die sich unter Umständen für Onlinehändler eignet. Die Komponente CBR von Load Balancer und der Proxy-Server werden gemeinsam auf der Maschine 4 installiert und leiten Anforderungen an zwei Load-Balancer-Maschinen weiter. Die Load-Balancer-Maschine 6 führt den Lastausgleich in einem Cluster von Inhaltshosts (8) durch, die den zum größten Teil statischen Inhalt des Katalogs enthalten, wohingegen die Load-Balancer-Maschine 7 den Lastausgleich für einen Cluster von Webservern durchführt, die für die Auftragsabwicklung (9) verantwortlich sind.
Wenn ein Endbenutzer, der an einer der beiden mit 1 markierten Maschinen arbeitet, auf den URL des Händlerkatalogs zugreift, wird die Anforderung über das Internet (2) gesendet und erreicht das interne Unternehmensnetz über das Internet-Gateway (3) des Unternehmens. Der Proxy-Server fängt die Anforderung ab und leitet sie an die Komponente CBR auf derselben Maschine weiter. CBR führt eine Syntaxanalyse des URL aus und bestimmt, dass die Load-Balancer-Maschine 6 den URL verarbeiten soll. Der Proxy-Server erstellt eine neue Zugriffsanforderung und sendet sie an Load Balancer, der (auf der Grundlage der von Ihnen definierten Kriterien) ermittelt, welcher der Inhaltshosts (8) derzeit am besten geeignet ist, die Anforderung zu verarbeiten. Der Inhaltshost übergibt den Kataloginhalt unter Umgehung von Load Balancer direkt an den Proxy-Server. Wie im vorherigen Beispiel ermittelt der Proxy-Server, ob der Inhalt im Cache gespeichert werden kann, und speichert ihn ggf. in seinem Cache (5).
Der Endbenutzer sendet seine Bestellung, indem er auf den Bestell-URL des Händlers zugreift, in der Regel über einen Hyperlink im Katalog. Die Anforderung wird über dieselbe Route geleitet wie die Anforderung für Katalogzugriff. Allerdings leitet die Komponente CBR auf der Maschine 4 die Anforderung jetzt an die Load-Balancer-Maschine 7 weiter. Load Balancer wiederum leitet die Anforderung an den am besten geeigneten Server weiter, hier Webserver 9, der seine Antwort direkt an den Proxy-Server sendet. Weil Bestellinformationen in der Regel dynamisch generiert werden, speichert der Proxy-Server die Daten wahrscheinlich nicht im Cache.
Legende: 1--Client 2--Internet 3--Router/Gateway 4--Caching Proxy und die Komponente CBR von Load Balancer 5--Cache 6, 7--Load Balancer 8--Inhaltshost 9--WebserverDie Funktion CBR von Load Balancer unterstützt Cookie-Affinität. Dies bedeutet, dass die Identität des Servers, der die erste Anforderung eines Endbenutzers verarbeitet, in einem speziellen Datenpaket (einem so genannten Cookie) aufgezeichnet wird, das in die Antwort des Servers aufgenommen wird. Wenn der Endbenutzer innerhalb eines von Ihnen festgelegten Zeitraums erneut auf denselben URL zugreift und die Anforderung das Cookie enthält, leitet CBR die Anforderung an den ursprünglichen Server weiter und wendet seine Standardregeln nicht erneut an. Im Allgemeinen verkürzen sich die Antwortzeiten, wenn auf dem Server Informationen über den Endbenutzer gespeichert sind, die nicht erneut ermittelt werden müssen (z. B. die Kreditkartennummer).
In diesem Teil werden Geschäftsszenarios beschrieben, in denen IBM WebSphere Application Server Edge Components verwendet wird. Es handelt sich um Lösungen mit stabiler und geprüfter Architektur, die eine hervorragende Leistung, Verfügbarkeit, Skalierbarkeit und Zuverlässigkeit bieten.
Dieser Teil enthält folgende Kapitel:
Die Basis-Website für E-Commerce ist ein B2C-Netz (B2C = Business-to-Consumer). In der ersten Phase ihres Wachstums im Internet konzentrieren sich die Unternehmen in der Regel darauf, lediglich eine Präsenz im Web aufzubauen. Informationen zum Unternehmen und Produktkataloge werden in digitale Formate konvertiert und auf der Website verfügbar gemacht. Das Einkaufen wird durch Angabe von E-Mail-Adressen, Telefon und Faxnummern oder sogar von automatisierten Formularen ermöglicht. Ein echtes Online-Shopping ist jedoch nicht verfügbar. Alle Transaktionen erfolgen mit einer zeitlichen Verzögerung, weil die Bestellungen von Personen verarbeitet werden müssen.
In Phase zwei wird diese Verzögerungszeit beseitigt. Die Verkaufsoperationen werden rationalisiert, indem sichere elektronische Warenkörbe für direkte Onlinekäufe implementiert werden. Entscheidend für die Ausführung dieser Verkaufstransaktionen sind die Synchronisation mit Warehouse-Datenbanken und die Einführung von Zahlungssystemen. Ein Produkt, das nicht verfügbar ist, kann nicht verkauft werden, und das Konto des Kunden kann für diesen Artikel nicht belastet werden. Genauso wenig kann ein Produkt aus dem Inventar entnommen und an einen Kunden geliefert werden, bevor eine gültige finanzielle Transaktion stattgefunden hat.
In der dritten Phase entwickelt sich die Website des Unternehmens zu einer Site mit dynamischer Präsentation, in der der Kunde allmählich als Client behandelt wird, indem ihm Inhalte angezeigt werden, die speziell für ihn angepasst wurden.
Das folgende Szenario umfasst Load Balancer und Caching Proxy.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Abb. 14 zeigt eine kleine kommerzielle Website, die für eine effiziente Katalogsuche aufgebaut wurde. Alle Clientanforderungen werden über die Firewall an einen Dispatcher übergeben, der die Anforderungen an einen Cluster von Proxy-Servern mit aktiven Caches weiterleitet, die stellvertretend für die Webserver auftreten. Den Proxy-Servern sind Metrikserver zugeordnet, die Lastausgleichsdaten für den Dispatcher bereitstellen. Diese Anordnung verringert die Netzlast auf den Webservern und isoliert sie vom direkten Kontakt mit dem Internet.
Abb. 15 zeigt die zweite Phase der Entwicklung einer E-Commerce-Website, die ihren potenziellen Kunden eine effektive Katalogsuche ermöglicht sowie schnelle und sichere elektronische Warenkörbe zur Verfügung stellt. Alle Anforderungen von Kunden werden durch einen Dispatcher, der die Anforderungen auf der Grundlage eines Internet-Protokolls aufteilt, an den geeigneten Zweig des Netzes weitergeleitet. HTTP-Anforderungen werden an die statische Website, HTTPS-Anforderungen an das Einkaufsnetz übermittelt. Die primäre, statische Website wird weiterhin von einem Cluster von Proxy-Servern mit aktiven Caches bedient, die stellvertretend für die Webserver auftreten. Dieser Teil des Netzes spiegelt das Netz in der ersten Phase wider.
Der E-Commerce-Teil der Website wird ebenfalls von einem Cluster von Proxy-Servern bedient. Allerdings werden die Caching-Proxy-Knoten durch mehrere Plug-in-Module ergänzt. Das SSL-Handshaking wird an eine Verschlüsselungskarte ("Cryptocard" in der folgenden Abbildung) ausgelagert. Die Authentifizierung erfolgt über das Plug-in Access Manager (früher Policy Director). Das Plug-in Dynamic Caching verringert die Arbeitslast im WebSphere Application Server, weil häufig benötigte Daten gespeichert werden. Ein Plug-in im Anwendungsserver macht Objekte im dynamischen Cache ungültig, wenn dies erforderlich ist.
Alle Anwendungen mit elektronischen Warenkörben sind in die Kundendatenbank eingebunden, die zur Authentifizierung des Benutzers verwendet wird. Dies verhindert, dass der Benutzer mehrmals persönliche Informationen eingeben muss, einmal zur Authentifizierung und einmal zum Einkaufen.
In diesem Netz wird der Datenverkehr entsprechend der Clientnutzung verteilt. Die primäre Website wird von der prozessorintensiven SSL-Authentifizierung und den E-Commerce-Warenkörben befreit. Diese zweigleisige Website ermöglicht es dem Netzadministrator, die verschiedenen Server so einzustellen, dass sie in Abhängigkeit von ihrem jeweiligen Aufgabenbereich im Netz eine optimale Leistung erzielen.
Abb. 16 zeigt die dritte Phase in der Entstehung eines B2C-Netzes, in der die statische Website eine Methode für dynamische Präsentation verwendet. Der Cluster aus Proxyservern wurde in der Weise erweitert, dass er das Caching dynamischer Webhinhalte unterstützt sowie die Assemblierung von Seitenfragmenten, die gemäß den Regeln des Protokolls ESI (Edge Side Includes) geschrieben wurden. Anstatt mit Server-Side Includes Webseiten auf den Inhaltsservern zu erstellen und diese clientspezifischen, unveränderlichen Seiten dann im gesamten Netz weiterzugeben, können mit dem Protokoll ESI Seiten aus zwischengespeicherten Inhalten an den Grenzen (Edge) des Netzes assembliert werden, wodurch sich die Belastung des Netzes und die Antwortzeiten verringern.
Das Protokoll ESI ist in dieser dritten Phase von entscheidender Bedeutung, in der jeder Client von der Website eine personalisierte Homepage erhält. Die Bausteine für diese Seiten werden von einer Reihe von WebSphere Application Servern abgerufen. Anwendungsserver, die kritische Geschäftslogik und Verknüpfungen mit geschützten Datenbanken enthalten, werden hinter einer Firewall isoliert.
Abb. 17 zeigt eine effiziente Lösung für Online-Banking, die ähnlich aufgebaut ist wie das in B2C-Netz beschriebene B2C-Netz. Alle Clientanforderungen werden durch die Firewall an einen Dispatcher übertragen, der die Übertragungen gemäß dem Internet-Protokoll verteilt. HTTP-Anforderungen werden an einen Cluster von Proxyservern mit aktiven Caches übermittelt, die stellvertretend für die Webserver auftreten. Den Proxyservern sind Metrikserver zugeordnet, die Lastausgleichsdaten für den Dispatcher bereitstellen. Diese Anordnung verringert die Netzlast auf den Webservern und erstellt einen zusätzlichen Puffer zwischen ihnen und dem Internet.
HTTPS-Anforderungen werden an ein sicheres Netz weitergeleitet, das für die Clients persönliche Finanzinformationen bereitstellt und die Ausführung von Online-Banking-Transaktionen erlaubt. Ein Cluster von erweiterten Proxyservern erlaubt die Skalierbarkeit der Site. Diese Proxyserver unterstützen das Caching von dynamischen Webinhalten und das Assemblieren von Seitenfragmenten, die gemäß den Regeln des Protokolls ESI (Edge Side Includes) geschrieben wurden. Eine Verschlüsselungskarte (Cryptocard in der folgenden Abbildung) verwaltet die SSL-Handshakes, wodurch sich der Verarbeitungsaufwand für den Proxyserver-Host erheblich verringert. Access Manager (früher Policy Director) steuert die Clientauthentifizierung.
Eine Gruppe von Anwendungsserver-Clustern verteilt die Verarbeitung von Anforderungen, indem die in den EJB-Komponenten enthaltene Geschäftslogik von der in Servlets und JSP-Dateien enthaltenen Präsentationsschicht getrennt wird. Jeder dieser Cluster wird von einem eigenen Sitzungsserver verwaltet.
Das folgende Szenario umfasst Load Balancer und Caching Proxy.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Abb. 18 zeigt ein Web-Portal-Netz, das zur Unterstützung eines hohen Datenübertragungsaufkommens dient und gleichzeitig jedem Client personalisierte Inhalte bereitstellt. Damit die Verarbeitungslast auf den verschiedenen Servern verringert wird, werden in keinem Teil des Netzes SSL-Datenübertragungen durchgeführt. Weil das Portal keine sensiblen Daten bereitstellt, ist die Sicherheit hierbei kein wichtiger Aspekt. Es ist wichtig, dass die Datenbank, in der die Client-IDs, -Kennwörter und -Einstellungen gespeichert sind, sicher und unbeschädigt bleibt. Diese Voraussetzung beeinträchtigt jedoch nicht die Leistung der restlichen Website.
Alle Clientanforderungen werden durch die Firewall an einen Dispatcher übermittelt, der die Netzlast auf einen Cluster von Proxyservern mit aktiven Caches verteilt, die stellvertretend für die Webserver fungieren. Den Proxyservern sind Metrikserver zugeordnet, die Lastausgleichsdaten für den Dispatcher bereitstellen.
Die eigentliche dynamische Website ist ein Cluster von Anwendungsservern, die ESI-Fragmente generieren, die zur Assemblierung an die Proxyserver übermittelt werden. Aufgrund der Tatsache, dass die Sicherheit eine untergeordnete Rolle spielt, kann jeder Anwendungsserver alle erforderlichen Funktionen zur Konstruktion der Website ausführen. Alle Anwendungsserver sind identisch. Fällt ein Anwendungsserver aus, kann der Sitzungsserver die Anforderungen an andere Server weiterleiten und auf diese Weise für die gesamte Site eine hohe Verfügbarkeit gewährleisten. Diese Konfiguration erlaubt auch eine schnelle Eskalation der Website, falls eine unerwartet hohe Menge an Datenübertragungen zu bewältigen ist, z. B. das Hosting eines speziellen Ereignisses durch das Portal. In diesem Fall können zusätzliche Proxyserver und Anwendungsserver schnell für die Site konfiguriert werden.
Alle statischen Inhalte, z. B. Bilddateien und Standardtexte, werden auf separaten Webservern gespeichert, so dass diese aktualisiert werden können, ohne zu riskieren, dass einer der komplexeren Anwendungsserver beschädigt wird.
Das folgende Szenario umfasst Load Balancer und Caching Proxy.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Dieser Teil beschreibt die Prozeduren für die Installation von Edge Components.
Dieser Teil enthält folgende Kapitel:
Voraussetzungen für Edge Components
Installation von Edge Components mit dem Installationsprogramm
Installation von Caching Proxy mit den Paketverwaltungstools des Betriebssystems
Installation von Load Balancer mit den Paketverwaltungstools des Betriebssystems
Dieses Kapitel enthält einen Link zu den Hardware- und Softwarevoraussetzungen für Edge Components sowie Richtlinien für die Verwendung von Webbrowsern mit den Konfigurations- und Verwaltungsformularen von Caching Proxy und mit der Online-Hilfe von Load Balancer.
Informationen zur unterstützten Hardware und zu den Softwarevoraussetzungen für WebSphere Application Server Version 6.1 Edge Components finden Sie auf der folgenden Webseite: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
SDK-Installation: Das Java 2 SDK wird auf allen Plattformen automatisch mit Load Balancer installiert.
Mindestvoraussetzungen für Browser
Zum Konfigurieren von Caching Proxy mit den Konfigurations- und Verwaltungsformularen muss der Browser folgende Voraussetzungen erfüllen:
Für Linux- und UNIX-Systeme: Informationen zu den empfohlenen Versionen der Browser Mozilla und Firefox finden Sie auf der folgenden Website. Folgen Sie auf dieser Website den Links zur Webseite mit Informationen zur unterstützten Software: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Für Windows-Systeme: Informationen zu den empfohlenen Versions der Browser Internet Explorer, Mozilla und Firefox finden Sie auf der folgenden Website. Folgen Sie auf dieser Website den Links zur Website mit Informationen zur unterstützten Software: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Einschränkung: Die vertikale Schiebeleiste links in den Administrationsformularen wird möglicherweise vom Browser nicht angezeigt, wenn die Anzahl der eingeblendeten Elemente die Darstellungsmöglichkeiten des Browser-Fensters überschreitet. In diesem Fall schieben sich die unten in der Liste enthaltenen Elemente aus dem derzeit angezeigten Browser-Fenster und können nicht ausgewählt werden. Sie können dieses Problem beheben, indem Sie die Anzahl der einzublendenden Elemente im linken Menü einschränken. Wenn die Anzahl der eingeblendeten Elemente zu groß ist, müssen Sie so viele Elemente ausblenden, bis die Elemente unten in der Liste im Browser-Fenster sichtbar werden.
Damit die Formulare ordnungsgemäß angezeigt werden, muss das Betriebssystem, unter dem die Formulare angezeigt werden (d. h. das Betriebssystem, auf dem der Browser installiert ist), die erforderlichen Schriftarten für die Sprache besitzen, in der die Formulare geschrieben sind. Die Browser-Schnittstelle muss allerdings nicht unbedingt dieselbe Sprache verwenden wie die Formulare.
Beispiel: Die chinesische Version des Proxyservers läuft auf einem Solaris-9-System. Ein Mozilla-Browser mit englischer Schnittstelle wird auf den Solaris-Host geladen. Der Browser kann dazu verwendet werden, die Konfigurations- und Verwaltungsformulare lokal zu editieren. (Die Formulare werden dem Browser in dem Zeichensatz übermittelt, der vom Proxyserver verwendet wird - in diesem Beispiel Chinesisch. Allerdings werden die Formulare möglichweise nicht korrekt angezeigt, wenn der Browser und das verwendete Betriebssystem nicht ordnungsgemäß für die Darstellung des vom Proxyserver übermittelten Zeichensatzes konfiguriert sind.)
Wenn eine Windows-Workstation mit Unterstützung der chinesischen Sprache verfügbar ist, die eine ferne Verbindung zum Proxyserver herstellen kann, wäre es auch möglich, die chinesische Version eines Netscape-Browsers auf die Windows-Workstation zu laden und die Formulare in diesem Browser zu bearbeiten. Diese zweite Lösung hat den Vorteil, dass sich dem Administrator eine einheitliche Sprachenschnittstelle bietet.
Die betriebssystemspezifischen Schriftarten haben einen großen Einfluss auf die Darstellung der verschiedenen Sprachen in den Browsern, insbesondere bei Sprachen mit Doppelbytezeichen. Beispielsweise sieht eine chinesische Schriftart unter AIX nicht genauso aus wie auf Windows-Plattformen. Dies verursacht einige Unregelmäßigkeiten in der Darstellung von HTML-Text und Java-Applets in den Konfigurations- und Verwaltungsformularen. Daher werden für eine optimale Darstellung nur Browser empfohlen, die unter dem Betriebssystem Windows ausgeführt werden.
Anmerkung zum Browser Mozilla 1.4 auf Systemen des Typs S/390 und PowerPC
Das mit Mozilla 1.4 installierte Java-Plug-in muss auf Version 1.4.2 oder höher aktualisiert werden, damit die Administrationsformulare ordnungsgemäß angezeigt werden. Gehen Sie zum Aktualisieren des Plug-in wie folgt vor:
Zur Anzeige der Online-Hilfe von Load Balancer muss der Browser Folgendes unterstützen:
Bei Verwendung eines Browsers, der diese Voraussetzungen nicht erfüllt, werden möglicherweise falsch formatierte Seiten angezeigt und Funktionen nicht richtig ausgeführt.
Dieses Kapitel enthält Anweisungen für die Installation von Edge Components mit dem Installationsprogramm.
Das Java 2 SDK wird auf allen Plattformen automatisch mit Load Balancer installiert.
Nach der Installation versuchen Scripts aus dem Caching-Proxy-Paket, den Proxy-Server mit der Standardkonfiguration zu starten. Ist Port 80 belegt, beispielsweise von einem anderen Webserver, schlägt das Starten des Proxy-Servers fehl.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Mit dem Installationsprogramm können Sie Edge Components wie folgt auf Ihrem Windows-System installieren:
Sind bereits Komponenten von Edge Components installiert, wird vor dem Fenster "Komponentenauswahl" das Fenster "Verwaltungsoptionen" angezeigt. Wählen Sie den Radioknopf Ändern aus und klicken Sie dann auf Weiter. Das Fenster "Komponentenauswahl" wird geöffnet.
Einschränkung: Wenn Sie im Fenster mit der Lizenzvereinbarung die Tabulatortaste verwenden, wechselt der Fokus zwischen den Optionen Ich akzeptiere und Ich akzeptiere nicht. Mit der Tabulatortaste können Sie jedoch nicht die Navigationsoptionen Zurück, Weiter und Abbrechen erreichen. Verwenden Sie die Ausweichtastenkombination Umschalttaste+Tab, um diese Navigationsoptionen zu erreichen. Außerdem funktioniert die Eingabetaste nur bei den Navigationsschaltflächen. Zur Auswahl der Option Ich akzeptiere oder Ich akzeptiere nicht müssen Sie deshalb die Leertaste verwenden.
Wenn Sie die Installation von CD durchführen, können Sie mit dem Installationsprogramm Edge Components wie folgt auf Ihrem Linux- bzw. UNIX-System installieren:
# ./installDas Fenster "Willkommen" wird geöffnet.
Das Installationsprogramm beginnt mit der Installation der ausgewählten Komponenten von Edge Components und der erforderlichen Pakete.
Einschränkung: Wenn Sie im Fenster mit der Lizenzvereinbarung die Tabulatortaste verwenden, wechselt der Fokus zwischen den Optionen Ich akzeptiere und Ich akzeptiere nicht. Mit der Tabulatortaste können Sie jedoch nicht die Navigationsoptionen Zurück, Weiter und Abbrechen erreichen. Verwenden Sie die Ausweichtastenkombination Umschalttaste+Tab, um diese Navigationsoptionen zu erreichen. Außerdem funktioniert die Eingabetaste nur bei den Navigationsschaltflächen. Zur Auswahl der Option Ich akzeptiere oder Ich akzeptiere nicht müssen Sie deshalb die Leertaste verwenden.
Hinweis zu Red Hat Linux 3.0 Update 3: Wenn Sie das Installationsprogramm für Edge Components ausführen, funktionieren die Schaltflächen nicht, wenn die GUI-Anzeige auf Maximalgröße eingestellt und anschließend in Originalgröße wiederhergestellt wird. Sie können dieses Problem wie folgt beheben:
Auf Linux- und UNIX-Systemen: Wenn das Programm setup zum Installieren von Edge Components verwendet wird, kann das Deinstallationsprogramm der GUI für die Deinstallation von Edge Components verwendet werden. Mit dem Deinstallationsprogramm der GUI von Edge Components können jedoch keine Aktualisierungspakete deinstalliert werden, die mit nativen Befehlen installiert wurden. In diesem Fall müssen Sie das Aktualisierungspaket zuerst mit den nativen Befehlen (Befehle des Betriebssystems) deinstallieren, damit Sie Edge Components mit dem Deinstallationsprogramm der GUI deinstallieren können.
Informationen zur Verwendung nativer Befehle finden Sie in Installation von Caching Proxy mit den Paketverwaltungstools des Betriebssystems und Installation von Load Balancer mit den Paketverwaltungstools des Betriebssystems.
Dieses Kapitel enthält Anweisungen für die Installation von Caching Proxy mit den Paketverwaltungstools des Systems.
Nach der Installation versuchen Scripts aus dem Caching-Proxy-Paket, den Proxy-Server mit der Standardkonfiguration zu starten. Ist Port 80 belegt, beispielsweise von einem anderen Webserver, schlägt das Starten des Proxy-Servers fehl.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Wenn Sie das Installationssystem für Softwarepakete des Betriebssystems verwenden, müssen Sie die Pakete in der Reihenfolge installieren, die in Tabelle 2 vorgegeben ist. Nachfolgend werden die Schritte, die Sie in der Regel bei der Installation ausführen müssen, ausführlich beschrieben.
su - root Password: Kennwort
cd Mount-Punkt/Paketverzeichnis/
Unter AIX:
installp -acXd ./Paketname
Unter HP-UX:
swinstall -s source/ Paketname
Unter Linux:
rpm -i ./Paketname
Unter Solaris:
pkgadd -d ./Paketname
Komponente | Installierte Pakete (empfohlene Reihenfolge) |
---|---|
Caching Proxy |
|
Dokumentation zu Edge Components |
doc-en_US1 |
Anmerkungen:
|
Das Dokumentationspaket enthält nur englische Dateien. Die übersetzten Versionen der Dokumentation zu Edge Components finden Sie auf der folgenden Website: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Geben Sie zum Deinstallieren der Pakete Folgendes ein:
Unter AIX:
installp -u Paketname
Verwenden Sie zum Deinstallieren aller Caching-Proxy-Pakete den folgenden Befehl:
installp -u wses
Unter HP-UX:
swremove Paketname
Verwenden Sie zum Abfragen der installierten Pakete für Caching Proxy folgenden Befehl:
swlist | grep WSES
Die Pakete müssen in umgekehrter Installationsreihenfolge deinstalliert werden.
Unter Linux:
rpm -e Paketname
Verwenden Sie zum Abfragen der installierten Pakete für Caching Proxy folgenden Befehl:
rpm -qa |grep -i wses
Die Pakete müssen in umgekehrter Installationsreihenfolge deinstalliert werden.
Unter Solaris:
pkgrm Paketnam
Verwenden Sie zum Abfragen der installierten Pakete für Caching Proxy folgenden Befehl:
pkginfo | grep WSES
Die Pakete müssen in umgekehrter Installationsreihenfolge deinstalliert werden.
Dieses Abschnitt beschreibt die Installation von Load Balancer auf AIX-, HP-UX-, Linux- und Solaris-Systemen:
Je nach Installationstyp werden unter Umständen nicht alle Load-Balancer-Komponentenpaket, die in diesem Abschnitt aufgelistet sind, bereitgestellt.
Die empfohlene Reihenfolge für die Installation der Pakete ist für Installationen von Load Balancer for IPv4 and IPv6 geringfügig anders. Das Paket für die Verwaltungskomponente muss unbedingt nach dem Paket für die Dispatcher-Komponente installiert werden. Die empfohlene Reihenfolge für die Installation der Pakete für Load Balancer for IPv4 and IPv6 mit den Systemtools ist Basis, Lizenz, Dispatcher, Verwaltung, Dokumentation, Metric Server.
Wenn Sie eine frühere Version von Load Balancer auf die neue Version migrieren oder ein Betriebssystem erneut installieren, können Sie vor der Installation die früheren Konfigurationsdateien oder Script-Dateien für Load Balancer sichern.
Wenn Sie sich nach der Installation von Load Balancer von einer Maschine abmelden, müssen Sie nach einer erneuten Anmeldung alle Load-Balancer-Dienste neu starten.
Tabelle 5 enthält eine Liste der AIX-Dateigruppen für Load Balancer und die empfohlene Installationsreihenfolge unter Verwendung des Paketinstallationstools des Systems auf.
Load-Balancer-Komponenten | AIX-Dateigruppen |
---|---|
Basis | ibmlb.base.rte |
Verwaltung (mit Nachrichten) |
|
Einheitentreiber | ibmlb.lb.driver |
Lizenz | ibmlb.lb.license |
Load-Balancer-Komponenten (mit Nachrichten) |
|
Dokumentation (mit Nachrichten) |
|
Metric Server | ibmlb.ms.rte |
Das Dokumentationspaket enthält nur englische Dateien. Die übersetzten Versionen der Dokumentation zu Edge Components finden Sie auf der folgenden Website: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Vergewissern Sie sich vor der Installation von Load Balancer unter AIX, dass folgende Voraussetzungen erfüllt sind:
installp -u ibmlbGeben Sie den folgenden Befehl ein, um frühere Versionen zu deinstallieren:
installp -u ibmndWenn Sie bestimmte Dateigruppen deinstallieren möchten, listen Sie diese anstelle des Paketnamens ibmlb einzeln auf.
Bei der Installation des Produkts können Sie auswählen, ob Sie nur bestimmte oder alle in der folgenden Liste aufgeführten Komponenten installieren möchten:
Es wird empfohlen, Load Balancer unter AIX mit SMIT zu installieren, da in diesem Fall alle Nachrichten automatisch installiert werden.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Pakete | Befehle |
---|---|
Basis | installp -acXgd Einheit ibmlb.base.rte |
Verwaltung (mit Nachrichten) | installp -acXgd Einheit ibmlb.admin.rte ibmlb.msg.Sprache.admin |
Einheitentreiber | installp -acXgd Einheit ibmlb.lb.driver |
Lizenz | installp -acXgd Einheit ibmlb.lb.license |
Load-Balancer-Komponenten (mit Nachrichten): Dispatcher, CBR, Site Selector, Cisco CSS Controller und Nortel Alteon Controller |
installp -acXgd Einheit ibmlb.Komponente.rte ibmlb.msg.Sprache.lb |
Dokumentation (mit Nachrichten) | installp -acXgd Einheit ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd Einheit ibmlb.ms.rte |
installp -ld Einheit
Wenn Sie die Installation von CD durchführen, geben Sie den folgenden Befehl ein, um das CD-ROM-Laufwerk abzuhängen:
unmount /cdrom
Überprüfen Sie, ob das Produkt installiert wurde. Geben Sie dazu folgenden Befehl ein:
lslpp -h | grep ibmlb
Wenn Sie das vollständige Produkt installiert haben, gibt der Befehl Folgendes zurück:
ibmlb.base.rte
ibmlb.admin.rte
ibmlb.lb.driver
ibmlb.lb.license
ibmlb.Komponente.rte
ibmlb.doc.rte
ibmlb.ms.rte
ibmlb.msg.Sprache.admin
ibmlb.msg.en_US.doc
ibmlb.msg.Sprache.lb
Load Balancer verwendet folgende Installationspfade:
In diesem Abschnitt wird erläutert, wie Load Balancer unter HP-UX von der Produkt-CD installiert wird.
Vergewissern Sie sich vor Beginn der Installation, dass Sie die zum Installieren der Software erforderliche Root-Berechtigung besitzen.
Sollte bereits eine frühere Version des Produkts installiert sein, müssen Sie diese Kopie vor der Installation der aktuellen Version deinstallieren. Stellen Sie zuerst sicher, dass das Steuerprogramm (Executor) und der Server gestoppt sind. Deinstallieren Sie anschließend Load Balancer gemäß den Anweisungen im Abschnitt Anweisungen für die Deinstallation der Pakete.
Die Tabelle 7 enthält eine Liste der Installationspakete für Load Balancer und die empfohlene Reihenfolge, in der diese Pakete mit dem Paketinstallationstool des Systems installiert werden sollten.
HP-UX bietet keine Unterstützung für die Locale Brasilianisches Portugiesisch (pt_BR). Die folgenden Locales werden unter HP-UX unterstützt:
Im Folgenden sind die Schritte, die Sie zum Installieren des Produkts ausführen müssen, ausführlich beschrieben.
su - root Password: Kennwort
Setzen Sie den folgenden Installationsbefehl ab:
swinstall -s /Quelle PaketnameQuelle
steht hier für den absoluten Verzeichnispfad zum Paket und Paketname für den Namen des Pakets.
Der folgende Befehl installiert beispielsweise das Basispaket für Load Balancer (ibmlb.base), wenn Sie die Installation aus dem Stammverzeichnis der CD heraus durchführen:
swinstall -s /Quelle ibmlb.base
Setzen Sie zum Installieren aller Pakete für Load Balancer den folgenden Befehl abm wenn Sie die Installation aus dem Stammverzeichnis der CD heraus ausführen:
swinstall -s /Quelle ibmlb
Führen Sie den Befehl swlist aus, um alle Pakete aufzulisten, die Sie installiert haben. Beispiel:
swlist -l fileset ibmlb
Verwenden Sie den Befehl swremove, um die Pakete zu deinstallieren. Die Pakete müssen in umgekehrter Installationsreihenfolge deinstalliert werden. Beispiel:
swremove ibmlbSetzen Sie den folgenden Befehl ab, um ein einzelnes Paket (z. B. den Cisco CSS Controller) zu deinstallieren:
swremove ibmlb.cco
Load Balancer verwendet folgende Installationspfade:
In diesem Abschnitt wird erläutert, wie Load Balancer von der Edge-Components-CD unter Linux installiert wird.
Vergewissern Sie sich vor der Installation von Load Balancer, dass folgende Voraussetzungen erfüllt sind:
rpm -e PaketnameBei der Deinstallation müssen Sie die Reihenfolge, in der die Pakete installiert wurden, umkehren und auf diese Weise sicherstellen, dass die Verwaltungspakete zuletzt deinstalliert werden.
Das Installations-Image ist eine Datei im Format lblinux-Version.tar.
tar -xf lblinux-Version.tarFolgende Gruppe von Dateien mit der Erweiterung .rpm wird entpackt:
Die Parameter sind im Folgenden erläutert:
Das Dokumentationspaket enthält nur englische Dateien. Die übersetzten Versionen der Dokumentation zu Edge Components finden Sie auf der folgenden Website: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
rpm -i Paket.rpm
Systeme mit Red Hat Linux: Aufgrund eines bekannten Problems in Red Hat Linux müssen Sie außerdem die RPM-Dateien _db* löschen. Andernfalls tritt ein Fehler auf.
Die Pakete müssen in der folgenden Reihenfolge installiert werden:
rpm -i --nodeps Paket.rpm
rpm -qa | grep ibmlb
Wenn Sie das vollständige Produkt installiert haben, wird folgende Ausgabe angezeigt:
Load Balancer verwendet folgende Installationspfade:
Bei der Deinstallation müssen Sie die Reihenfolge, in der die Pakete installiert wurden, umkehren und auf diese Weise sicherstellen, dass die Verwaltungspakete zuletzt deinstalliert werden.
In diesem Abschnitt wird erläutert, wie Load Balancer von der Edge-Components-CD unter Solaris installiert wird.
Vergewissern Sie sich vor Beginn der Installation, dass Sie als "root" angemeldet sind und dass alle früheren Versionen des Produkts deinstalliert wurden.
Stellen Sie vor der Deinstallation sicher, dass alle Steuerprogramme (Executor) und Server gestoppt wurden. Geben Sie anschließend folgenden Befehl ein:
pkgrm Paketname
pkgadd -d Pfadname-d Pfadname steht für den Einheitennamen des CD-ROM-Laufwerks oder das Verzeichnis auf dem Festplattenlaufwerk, in dem sich das Paket befindet. Beispiel: -d /cdrom/cdrom0/.
Die folgende Liste enthält die angezeigten Pakete und die empfohlene Reihenfolge für ihre Installation.
Das Dokumentationspaket (ibmlbdoc) enthält nur englische Dateien. Die übersetzten Versionen der Dokumentation zu Edge Components finden Sie auf der folgenden Website: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Wenn Sie alle Pakete installieren möchten, geben Sie einfach all ein und drücken Sie die Eingabetaste. Möchten Sie nur bestimmte Komponenten installieren, geben Sie die Namen der zu installierenden Pakete, durch ein Leerzeichen oder Komma getrennt, ein und drücken Sie die Eingabetaste. Möglicherweise werden Sie dazu aufgefordert, Berechtigungen für vorhandene Verzeichnisse oder Dateien zu ändern. Drücken Sie die Eingabetaste oder bestätigen Sie die Aufforderung mit Ja. Sie müssen die erforderlichen Pakete selbst installieren (weil die Installation der Pakete in alphabetischer Reihenfolge erfolgt und nicht in der vorausgesetzten Reihenfolge). Bei Eingabe von all können Sie alle Aufforderungen mit Ja beantworten, und die Installation wird erfolgreich ausgeführt.
Wenn Sie nur die Komponente Dispatcher mit der Dokumentation und Metric Server installieren möchten, müssen Sie die folgenden Pakete installieren: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc und ibmlbms.
pkginfo | grep ibm
Load Balancer verwendet folgende Installationspfade:
Dieser Teil beschreibt, wie Sie grundlegende Beispielnetze mit Edge Components aufbauen können. Diese Netze sind nicht für den Einsatz in Produktionsumgebungen bestimmt. Die Erstkonfiguration eines Netzes kann einem Administrator, der mit dem Produkt noch nicht vertraut ist, zahlreiche Konzepte der Edge-Technologie im Netz verdeutlichen. Eine umfassende Beschreibung aller Komponentenfunktionen und ausführliche Informationen zur Konfiguration finden Sie im Caching Proxy Administratorhandbuch und im Load Balancer Administratorhandbuch.
Mit Hilfe dieser Prozeduren kann jedes von der Komponente unterstützte Computersystem auf jedem Knoten verwendet werden.
Dieser Teil enthält folgende Kapitel:
Aufbau eines Caching-Proxy-Netzes.
Aufbau eines Load-Balancer-Netzes.
Abb. 19 zeigt ein grundlegendes Proxyservernetz, in dem drei Computersysteme auf drei Netzknoten verwendet werden. Dieses Netz bindet den Proxyserver an einen dedizierten Inhaltshost (IBM HTTP Server), der sich auf Server 2 befindet. Der Proxyserver bedient den Host. In der Abbildung wird diese Zuordnung durch das zwischen der Workstation und dem Server 1 liegende Internet veranschaulicht.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Zum Erstellen eines Caching-Proxy-Netzes führen Sie nacheinander folgende Arbeitsschritte aus:
Folgende Computersysteme und Zusatzsoftware werden benötigt:
Installieren und konfigurieren Sie Caching Proxy wie folgt:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
Geben Sie auf Anforderung den Benutzernamen, das Kennwort und den echten Namen des Administrators für das Programm htadm ein.
Installieren und konfigurieren Sie Caching Proxy wie folgt:
cd "Programme\IBM\edge\cp\server_root\protect" htadm -adduser webadmin.passwd"
Geben Sie auf Anforderung den Benutzernamen, das Kennwort und den echten Namen des Administrators für das Programm htadm ein.
Führen Sie auf der Workstation folgende Aktionen aus:
Führen Sie auf der Workstation folgende Aktionen aus:
Abb. 20 zeigt ein grundlegendes Load-Balancer-Netz mit drei lokal angeschlossenen Workstations, die die MAC-gestützte Weiterleitung der Komponente Dispatcher verwenden, um die Last des Webdatenverkehrs auf zwei Webserver zu verteilen. Wird ein Lastausgleich für eine TCP-Anwendung oder eine Anwendung mit UDP ohne Statusverfolgung (stateless) ausgeführt, sieht die Konfiguration ähnlich aus.
Zum Aufbau eines Load-Balancer-Netzes führen Sie nacheinander die folgenden Arbeitsschritte aus:
Folgende Computersysteme und Zusatzsoftware werden benötigt:
Workstation | Name | IP-Adresse |
---|---|---|
1 | server1.unternehmen.com | 9.67.67.101 |
2 | server2.unternehmen.com | 9.67.67.102 |
3 | server3.unternehmen.com | 9.67.67.103 |
Netzmaske = 255.255.255.0 |
Name= www.unternehmen.com IP=9.67.67.104
Fügen Sie zur Loopback-Schnittstelle auf server2.unternehmen.com und server3.unternehmen.com einen Aliasnamen für www.unternehmen.com hinzu.
ifconfig lo0 alias www.unternehmen.com netmask 255.255.255.0
ifconfig lo0:1 www.unternehmen.com 127.0.0.1 up
Sie haben jetzt alle für die beiden Webserver-Workstations erforderlichen Konfigurationsschritte ausgeführt.
Die Konfiguration des Dispatcher können Sie über die Befehlszeile, den Konfigurationsassistenten oder die grafische Benutzerschnittstelle (GUI) erstellen.
Gehen Sie zum Konfigurieren des Dispatcher über die Befehlszeile wie folgt vor:
dscontrol executor start
dscontrol cluster add www.unternehmen.com
dscontrol port add www.unternehmen.com:80
dscontrol server add www.unternehmen.com:80:server2.unternehmen.com
dscontrol server add www.unternehmen.com:80:server3.unternehmen.com
dscontrol executor configure www.unternehmen.com
dscontrol manager start
Der Dispatcher führt den Lastausgleich jetzt basierend auf der Serverleistung durch.
dscontrol advisor start http 80
Der Dispatcher stellt jetzt sicher, dass keine Clientanforderungen an einen ausgefallenen Webserver gesendet werden.
Die Basiskonfiguration mit lokal angeschlossenen Servern ist damit abgeschlossen.
Wichtig: Bei der Installation von Load Balancer for IPv4 and IPv6 ist die Syntax für den Dispatcher-Befehl (dscontrol) mit einer wichtigen Ausnahme identisch. Der Begrenzer für dscontrol-Befehle ist das kommerzielle A (@) und nicht der Doppelpunkt (:). (Es muss ein anderer Begrenzer als der Doppelpunkt definiert werden, weil das Format IPv6 den Doppelpunkt im Adressierungsschema verwendet.)
Erläuterung am Beispiel der vorherigen Dispatcher-Konfiguration
dscontrol port add www.unternehmen.com@80
dscontrol server add www.unternehmen.com@80@server2.unternehmen.com
dscontrol server add www.unternehmen.com@80@server3.5unternehmen.com
Nähere Informationen zur Installation von Load Balancer for IPv4 and IPv6 finden Sie im Kapitel zur Implementierung von Dispatcher in Load Balancer for IPv4 and IPv6 im WebSphere Application Server Load Balancer Administratorhandbuch, das die Einschränkungen und Konfigurationsunterschiede beschreibt.
Gehen Sie zum Konfigurieren des Dispatcher mit dem Konfigurationsassistenten wie folgt vor:
dsserver
Der Assistent führt Sie schrittweise durch das Erstellen einer Basiskonfiguration für die Komponente Dispatcher. Der Assistent stellt Ihnen Fragen bezüglich Ihres Netzes und führt Sie durch die Konfiguration eines Cluster, in dem der Dispatcher den Datenverkehr auf eine Gruppe von Servern verteilt.
Der Konfigurationsassistent enthält folgende Anzeigen:
Gehen Sie zum Starten der GUI wie folgt vor:
dsserver