Version 7.0
Erste Ausgabe (Juni 2008)
Diese Ausgabe gilt für:
Außerdem gilt diese Ausgabe für alle nachfolgenden Releases und Bearbeitungen, 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.
(C) Copyright International Business Machines Corporation 2008. Alle Rechte vorbehalten.
Konzepte und Beschreibungen zu Edge Components
Netze mit Edge Components erstellen
Dieses 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, Szenarios für den Einsatz der Edge-Komponenten im Netz, Informationen zur Installation und Erstkonfiguration sowie Beispielnetze.
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 Internetservices vertraut sind. Vorkenntnisse in WebSphere Application Server und 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 7.0 beschrieben:
Diese Dokumentation richtet sich in Bezug auf Typografie und Hervorhebung nach
den folgenden Konventionen.
Tabelle 1. In diesem Handbuch verwendete Konventionen
Konvention | Bedeutung |
---|---|
Fettschrift | Bei Bezugnahme auf grafische Benutzerschnittstellen (GUIs) werden Menüs, Menüpunkte, Bezeichnungen, 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 oder abzusetzen, 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 WebSphere Application Server Edge Components, Caching Proxy und Load Balancer und eine Beschreibung der Integration mit WebSphere Application Server. Außerdem finden Sie hier eine Definition der Komponenten Caching Proxy und Load Balancer. Darüber hinaus werden in diesem Teil andere zugehörige Produkte der WebSphere-Produktfamilie vorgestellt.
Dieser Teil enthält folgende Kapitel:
WebSphere ist eine Internetinfrastruktursoftware, 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 Internetebene zur Verfügung. Folglich müssen Umfang und Leistung der Internetinfrastruktur 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 enthält die Edge-Components-Komponenten Caching Proxy und Load Balancer.
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-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 Proxy-Server 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 Sicherung 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 WAS- 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 Proxy-Server, 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.
Load Balancer umfasst folgende Komponenten:
Die Komponente Dispatcher führt den Lastausgleich für alle Internetservices, 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.
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 Caching Proxy von WebSphere Application Server zusammen.
WICHTIG: Die Komponente Content Based Routing (CBR) ist mit den folgenden Ausnahmen auf allen unterstützten Plattformen verfügbar:
Alternativ können Sie für diesen Typ von Installation die Weiterleitungsmethode "cbr" der Load-Balancer-Komponente Dispatcher verwenden, um das inhaltsbasierte Routing von HTTP- und HTTPS-Anforderungen ohne die Verwendung von Caching Proxy zu unterstützen. Weitere Informationen 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 stellt den Load-Balancer-Komponenten Informationen zur Systembelastung bereit.
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 Webgeschäfts zu integrieren.
Die WebSphere-Familie setzt sich aus WebSphere Application Server, einschließlich Edge Components, und anderer Software der WebSphere-Familie zusammen, die eng mit WebSphere Application Server verbunden ist und dessen Leistungsspektrum erweitert. Eine Übersicht über WebSphere Application Server und die zugehörigen Komponenten finden Sie im Abschnitt 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 WebSphere 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 Internetunterstü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 von 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 Dokumentationen zu WebSphere Application Server sind auf der Bibliotheksseite von WebSphere Application Server verfügbar.
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 WebSphere Application Server finden Sie im Abschnitt 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 wurden, zwischenspeichern. Zur Verbesserung des Caching arbeitet Caching Proxy außerdem mit der Komponente Load Balancer von WebSphere Application Server zusammen. Eine Einführung in diese Systeme finden Sie im Abschnitt Einführung in WebSphere Application Server Edge Components.
WICHTIG: Caching Proxy ist mit den folgenden Ausnahmen in allen Installationen von Edge Components 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 Internetzugriffsprovider 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 Downloadzeiten für Daten, die bereits im Cache gespeichert sind, bedeuten eine bessere Servicequalität für die Kunden. Abbildung 1 stellt diese grundlegende Funktionalität von Caching Proxy dar.
Abbildung 1. Caching Proxy als Reverse Proxy
In dieser Konfiguration fängt der Proxy-Server (4) Anforderungen ab, deren URLs den Hostnamen des Inhaltshosts (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 zurück. Wenn die Datei für Caching geeignet ist, speichert Caching Proxy 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 Internetzugangs 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.
Abbildung 2. Caching Proxy als Forward Proxy
Abbildung 2 zeigt die Forward-Caching-Proxy-Konfiguration. Die Browserprogramme 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 Hauptspeichercache. 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 des Forward Caching Proxy 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 Clientbrowser 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 Abbildung 3 beschrieben. Wie ein regulärer Forward Proxy Server wird der transparente Caching Proxy auf einer Maschine in der Nähe des Gateway installiert, aber die Browserprogramme 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.
Abbildung 3.
Caching Proxy als transparenter Forward Proxy
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 Browserprogrammen, 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 Browserprogrammen, 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.
Abbildung 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 Clusters von Inhaltshosts (7) enthält, in dem Load Balancer (6) für den Lastausgleich zuständig ist.
Abbildung 4. Caching Proxy als Proxy-Server
für einen Cluster mit Lastausgleich
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 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 für dynamisches 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 cachefähig" gekennzeichnet werden, weil die zeitbasierte Standardverfallslogik für Cacheeinträge nicht sicherstellen kann, dass derartige Inhalte in angemessener Zeit aus dem Cache entfernt werden. Die ereignisgesteuerte Verfallslogik des Plug-ins für dynamisches Caching hingegen unterstützt das Caching von Inhalten mit unbestimmter Verfallszeit durch den 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 Webseiten, 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 WebSphere Application Server sind beide Systeme. Beispielsweise kann eine öffentliche Webseite, die von einer Anwendung dynamisch erstellt wurde, die aktuelle Wettervorhersagen meldet, von WebSphere 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 von 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 im Abschnitt Einführung in WebSphere Application Server Edge Components.
Die Leistung von 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, Cachekonfigurationswerten 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 den folgenden Ausnahmen in allen Installationen von Edge Components 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 Speichercache 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 Speichercache erheblich schneller ist als ein Rohplattencache 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 Plattencaches 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 Plattencaches vorgesehen ist. Der Engpass, der aus der Platten-E/A resultiert, kann beispielsweise durch Verwendung mehrerer Festplatten für Cacheroheinheiten (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 Proxy-Servermaschine 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 Proxy-Servers 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 Caching-Proxy-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 Proxy-Server 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 eigenständigen Caching-Proxy-Maschine oder auch eines Clusters von eigenständigen 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 Cachekapazität erzielt, wodurch sich die Cachetrefferquote 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 Cachekapazität insgesamt, aber wahrscheinlich werden jedoch mehrere Proxy-Server 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 Cacheservern 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 eigenständiger 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 Cachekonfiguration 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 Cachegröß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 Caches eher durch einen Speichercache oder eher durch einen Plattencache 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.
Plattencaches 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 Cachetrefferquote von 80 bis 90 % aufweist, dann ist die Verwendung eines Plattencaches zu empfehlen. Allerdings ist bekannt, dass ein Speichercache (RAM) schneller ist, und es gibt viele Szenarios, in denen sich ein Speichercache auch für große Sites eignet. Wenn die Cachetrefferquote von Caching Proxy beispielsweise nicht so wichtig ist oder eine Konfiguration mit gemeinsamem Cache verwendet wird, empfiehlt sich die Verwendung eines Speichercaches.
Caching Proxy kann dynamische Inhalte (JSPs und Servlet-Antworten), die vom dynamischen Cache von WebSphere Application Server generiert werden, zwischenspeichern und ungültig machen (invalidieren) und ermöglicht auf diese Weise eine virtuelle Erweiterung des Caches von WebSphere 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 Internetabfragen erreicht wird, schneller bedient werden können.
Durch die Verwendung der Komponente Load Balancer von WebSphere Application Server zusammen mit Inhaltshosts wie WebSphere Application Server oder mit der Komponente Caching Proxy von WebSphere Application Server können Sie Verfügbarkeit und Skalierbarkeit Ihres Netzes verbessern. (Im Abschnitt Einführung in WebSphere Application Server Edge Components finden Sie eine Einführung in diese Edge-Komponenten.) 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 den folgenden Ausnahmen in allen Installationen von Edge Components verfügbar:
Der Lastausgleich verbessert die Verfügbarkeit und Skalierbarkeit Ihrer Website, indem Proxy-Server 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 Abbildung 5 veranschaulicht ist. In dieser Konfiguration ist auf allen Inhaltshosts (den mit 5 markierten 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 mit 1 markierten Maschinen 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 Dispatchers 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 Load Balancer weitergeleitet).
Abbildung 5.
Lastausgleich für mehrere Inhaltshosts
Standardmäßig verwendet der Dispatcher einen umlaufbasierten Lastausgleich (Round-Robin) wie DNS. 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.
Der 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 Proxy-Servers verschlechtern.
Sie können mehrere Caching-Proxy-Systeme verwenden, die Proxy-Funktionen für einen einzelnen Inhaltshost ausführen (ähnlich wie in der Konfiguration in Abbildung 11). 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. Abbildung 6 zeigt diese Konfiguration. Der mit 4 markierte Dispatcher verteilt die Arbeitslast in einem Cluster mit zwei Proxy-Servern (5), und der mit 7 markierte Dispatcher verteilt die Arbeitslast in einem Cluster mit drei Inhaltshosts (8).
Abbildung 6.
Lastausgleich für mehrere Reverse-Proxy-Server und Inhaltshosts
Beim Clusterhostnamen des mit 4 markierten Dispatchers 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 Clusterhostname für den mit 7 markierten Dispatcher 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 mit 4 markierten Dispatcher, während für den mit 7 markierten Dispatcher 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 mit 4 markierten Dispatcher 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 mit 4 markierten Dispatchers direkt an den Browser zurückgegeben.
Befindet sich im Cache des Proxy-Servers keine Kopie der Datei X, erstellt der Proxy-Server eine neue Anforderung, die seinen eigenen Hostnamen im Header-Feld "origin" enthält und sendet sie an den mit 7 markierten Dispatcher. Load Balancer bestimmt, welcher Inhaltshosts (8) sicher derzeit am besten für die Bearbeitung der Anforderung eignet, und leitet die Anforderung dorthin. Der Inhaltshost ruft die Datei X aus dem Speicher ab und leitet sie unter Umgehung des mit 7 markierten Dispatchers direkt an den Proxy-Server weiter. Der Proxy-Server stellt die Datei X bei Bedarf in den Cache und leitet sie unter Umgehung des mit 4 markierten Dispatchers an den Browser weiter.
Wenn Sie einer großen Anzahl von Clients den Internetzugang ermöglichen, generieren diese einen höheren Bedarf an Internetzugriffen, 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 Internetzugriff. Wenn ein Fehler in Caching Proxy auftritt oder Caching Proxy aufgrund eines Netzfehlers vorübergehend ausfällt, sind keine Internetzugriffe 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 Clientbrowsern 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 Browserclients 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.
Abbildung 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 Clusters konfiguriert. Clientbrowser sind so konfiguriert, dass sie ihre Internetanforderungen an den Hostnamen des Clusters 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 Clusters 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.
Abbildung 7.
Dispatcher für den Lastausgleich für mehrere Caching-Proxy-Server verwenden.
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 Internetzugriffe 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 Cachezugriff) 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-Ausweichserver, 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 Internetzugriffen, 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 Browserclients die Caching-Proxy-Maschinen oder das Internet nicht erreichen. Die Lösung besteht darin, einen weiteren Dispatcher zu konfigurieren, der als Ausweiche-Dispatcher für den primären Dispatcher dient. Diese Lösung ist in Abbildung 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 Ausweich-Dispatcher (3) keinen Lastausgleich durch, solange der primäre Dispatcher funktionsfähig ist. Der primäre Dispatcher und der Ausweich-Dispatcher überwachen jeweils den Status des anderen durch den regelmäßigen Austausch von Nachrichten. Diese Nachrichten werden als Überwachungssignale bezeichnet. Wenn der Ausweich-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 Dispatchers 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 Ausweich-Dispatcher 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 Ausweich-Dispatcher sogar auf derselben Maschine wie Caching Proxy ausgeführt werden. Abbildung 9 zeigt eine solche Konfiguration, in der der Ausweich-Dispatcher auf derselben Maschine (3) wie Caching Proxy ausgeführt wird.
Abbildung 9. Ausweich-Dispatcher auf einer Caching-Proxy-Maschine
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 Sicherung für den primären Load Balancer fungiert (siehe Abbildung 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.
In der Regel sendet ein Browser, der auf einer der mit 1 markierten Maschinen ausgeführt wird, seine Anforderung für die Datei X an den Clusterhostnamen, 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 Ausweich-Dispatcher (5) führt keinen Lastausgleich durch, solange der primäre Dispatcher ordnungsgemäß funktioniert. Der primäre Dispatcher und der Ausweich-Dispatcher überwachen jeweils den Status des anderen durch den regelmäßigen Austausch von Nachrichten. Diese Nachrichten werden als Überwachungssignale bezeichnet. Wenn der Ausweich-Dispatcher feststellt, dass der primäre Dispatcher ausgefallen ist, übernimmt er automatisch den Lastausgleich, indem er Anforderungen an den Clusterhostnamen 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 Ausweich-Dispatcher 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 Ausweich-Dispatcher sogar auf einer der Maschinen im Cluster ausgeführt werden, für die der Lastausgleich durchgeführt wird. Abbildung 11 veranschaulicht eine Konfiguration, in der der Ausweich-Dispatcher auf einem der Inhaltshosts (5) im Cluster ausgeführt wird.
Abbildung 11. Installation eines Ausweich-Load-Balancer auf einem Inhaltshost
WICHTIG: Die Komponente Content Based Routing (CBR) ist mit den folgenden Ausnahmen auf allen unterstützten Plattformen verfügbar:
Alternativ können Sie für diesen Typ von Installation die Weiterleitungsmethode "cbr" der Load-Balancer-Komponente Dispatcher verwenden, um das inhaltsbasierte Routing von HTTP- und HTTPS-Anforderungen ohne die Verwendung von Caching Proxy zu unterstützen. Weitere Informationen 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 Caching Proxy von WebSphere Application Server erlaubt Ihnen die Komponente Load Balancer, die Anforderungen an mehrere Back-End-Server zu verteilen, auf denen unterschiedliche Inhalte gespeichert sind. (Im Abschnitt Einführung in WebSphere Application Server Edge Components finden Sie eine Einführung in diese Edge-Komponenten.)
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 Servercluster und Anforderungen 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.
Abbildung 12 zeigt eine einfache Konfiguration, in der die Komponente CBR von Load Balancer und Caching Proxy zusammen auf der mit 4 markierten Maschine installiert sind und Anforderungen an drei Inhaltshosts (6, 7 und 8) weitergeleitet werden, auf denen unterschiedlicher Inhalt gespeichert ist. Wenn ein Endbenutzer, der auf einer der mit 1 markierten Maschinen 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 Proxy-Server fängt die Anforderung ab und übergibt sie an die Komponente CBR auf derselben Maschine, die den URL in der Anforderung syntaktisch analysiert und feststellt, dass der Inhaltshost 6 die Datei X enthält. Der Proxy-Server generiert eine neue Anforderung für Datei X und stellt bei aktiviertem Caching-Feature fest, ob sich die Datei für das Caching eignet, wenn sie von Host 6 zurückgegeben wird. Wenn die Datei cachefähig ist, speichert der Proxy-Server eine Kopie in seinem Cache (5), bevor er sie 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.
Abbildung 12. HTTP-Anforderungen mit CBR weiterleiten
Abbildung 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 sind zusammen auf der mit 4 markierten Maschine installiert und leiten Anforderungen an zwei Load-Balancer-Maschinen weiter. Die mit 6 markierte Load-Balancer-Maschine führt den Lastausgleich in einem Cluster von Inhaltshosts (8) durch, die den zum größten Teil statischen Inhalt des Katalogs enthalten, wohingegen die mit 7 markierte Load-Balancer-Maschine 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 mit 6 markierte Load-Balancer-Maschine 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 mit 7 markierte Load-Balancer-Maschine 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.
Abbildung 13. Mit CBR weitergeleitete HTTP-Anforderungen verteilen
Die 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 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 den folgenden Ausnahmen in allen Installationen von Edge Components verfügbar:
Abbildung 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.
Abbildung 14. B2C-Netz (Phase 1)
Abbildung 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 Internetprotokolls 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 ihrer jeweiligen Rolle im Netz eine optimale Leistung erzielen.
Abbildung 15. B2C-Netz (Phase 2)
Abbildung 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 Proxy-Servern 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.
Abbildung 16. B2C-Netz (Phase 3)
Abbildung 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 Internetprotokoll verteilt. HTTP-Anforderungen werden an einen Cluster von Proxy-Servern mit aktiven Caches übermittelt, 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 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 Proxy-Servern erlaubt die Skalierbarkeit der Site. Diese Proxy-Server 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 Proxy-Serverhost erheblich verringert. Access Manager (früher Policy Director) steuert die Clientauthentifizierung.
Eine Gruppe von Anwendungsserverclustern 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 den folgenden Ausnahmen in allen Installationen von Edge Components verfügbar:
Abbildung 17. B2C-Banking-Lösung
Abbildung 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 Proxy-Servern mit aktiven Caches verteilt, die stellvertretend für die Webserver fungieren. Den Proxy-Servern 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 Proxy-Server ü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 Proxy-Server 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 den folgenden Ausnahmen in allen Installationen von Edge Components verfügbar:
In diesem Teil werden die Prozeduren für die Installation von Edge Components beschrieben.
Dieser Teil enthält folgende Kapitel:
Voraussetzungen für Edge Components
Edge Components mit dem Setup-Programm installieren
Caching Proxy mit dem Paketverwaltungstools des Systems installieren
Load Balancer mit dem Paketverwaltungstools des Systems installieren
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 Onlinehilfe von Load Balancer.
Informationen zur unterstützten Hardware und zu den Softwarevoraussetzungen für WebSphere Application Server Edge Components Version 7.0 finden Sie unter dem Link zur 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 Versionen 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 Verwaltungsformularen wird möglicherweise vom Browser nicht angezeigt, wenn die Anzahl der eingeblendeten Elemente die Darstellungsmöglichkeiten des Browserfensters überschreitet. In diesem Fall schieben sich die unten in der Liste enthaltenen Elemente aus dem derzeit angezeigten Browserfenster 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 Browserfenster 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 Browserschnittstelle muss allerdings nicht unbedingt dieselbe Sprache verwenden wie die Formulare.
Beispiel: Die chinesische Version des Proxy-Servers 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 Proxy-Server 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 Proxy-Server übermittelten Zeichensatzes konfiguriert sind.)
Wenn eine Windows-Workstation mit Unterstützung der chinesischen Sprache verfügbar ist, die eine ferne Verbindung zum Proxy-Server 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 Verwaltungsformulare ordnungsgemäß angezeigt werden. Gehen Sie zum Aktualisieren des Plug-in wie folgt vor:
Zur Anzeige der Onlinehilfe 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.
Dieser Abschnitt enthält Anweisungen zum Installieren von Edge Components mit dem Setup-Programm.
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 den folgenden Ausnahmen in allen Installationen von Edge Components verfügbar:
Mit dem Setup-Programm 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 Edge Components mit dem Setup-Programm wie folgt auf Ihrem Linux- bzw. UNIX-System installieren:
# ./installDas Fenster "Willkommen" wird geöffnet.
Das Setup-Programm 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.
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.
Weitere Informationen zur Verwendung nativer Befehle finden Sie unter Caching Proxy mit den Paketverwaltungsstools des Systems installieren und Load Balancer mit den Paketverwaltungstools des Systems installieren.
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 den folgenden Ausnahmen in allen Installationen von Edge Components 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
Tabelle 2. Caching-Proxy-Komponenten
Komponente | Installierte Pakete (empfohlene Reihenfolge) |
---|---|
Caching Proxy |
|
Dokumentation zu Edge Components |
doc-en_US
1
|
Anmerkungen:
|
Tabelle 3. Paketdateinamen unter AIX, HP-UX und Solaris
Generischer Paketname | AIX-Dateigruppe | HP-UX-Dateigruppe | Solaris-Dateiname |
---|---|---|---|
admin | wses_admin.rte | WSES-ADMIN | WSESadmin |
cp | wses_cp.base | WSES-CP | WSEScp |
doc | wses_doc.en_US | WSES-DOC-en_US | WSESdocen |
gskit7 | gskkm.rte | gsk7bas | gsk7bas |
icu | wses_icu.rte | WSES-ICU | WSESicu |
msg-cp-Sprache | wses_cp.msg.Sprache 1 .base | WSES-cpmSprache2 | WSEScpmSprache3 |
Anmerkungen:
|
Tabelle 4. Paketdateinamen unter Linux
Generischer Paketname | Linux-Dateiname |
---|---|
admin | WSES_Admin_Runtime-Releaseversion 1.Hardware2.rpm |
cp | WSES_CachingProxy-Releaseversion1.Hardware2.rpm |
doc | WSES_Doc_en_US-Releaseversion1.Hardware2.rpm |
gskit7 | gsk7bas.rpm |
icu | WSES_ICU_Runtime-Releaseversion 1.Hardware2.rpm |
msg-cp-Sprache | WSES_CachingProxy_msg_Sprache3-Releaseversion 1.Hardware2.rpm |
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 Paketname
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.
In diesem Abschnitt wird die Installation von Load Balancer auf AIX-, HP-UX-, Linux- und Solaris-Systemen beschrieben:
Je nach Installationstyp werden unter Umständen nicht alle Load-Balancer-Komponentenpaket, die in diesem Abschnitt aufgelistet sind, bereitgestellt.
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 Scriptdateien 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 |
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.
Vergewissern Sie sich vor der Installation von Load Balancer unter AIX, dass folgende Voraussetzungen erfüllt sind:
installp -u ibmlb
Geben Sie den folgenden Befehl ein, um frühere Versionen zu deinstallieren:
installp -u ibmnd
Wenn 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
Tabelle 6. AIX-Installationsbefehle
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.docibmlb.msg.Sprache.lb
Installationspfade von Load Balancer:
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. Informationen zum Deinstallieren von Load Balancer finden Sie im Abschnitt Anweisungen zum Deinstallieren 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.
Tabelle 7. Einzelheiten zur Installation der Pakete für Load Balancer unter HP-UX
Paketbeschreibung | Name des Pakets unter HP-UX |
Basis | ibmlb.base |
Verwaltung und Nachrichten | ibmlb.admin ibmlb.nlv-Sprache |
Load-Balancer-Lizenz | ibmlb.lic |
Load-Balancer-Komponenten | ibmlb.Komponente |
Dokumentation | ibmlb.doc |
Metric Server | ibmlb.ms |
Anmerkungen:
|
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 Paketname
Quelle 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 ibmlb
Setzen Sie den folgenden Befehl ab, um ein einzelnes Paket (z. B. den Cisco CSS Controller) zu deinstallieren:
swremove ibmlb.cco
Installationspfade von Load Balancer:
In diesem Abschnitt wird erläutert, wie Load Balancer unter Linux von der Edge-Components-CD installiert wird.
Vergewissern Sie sich vor der Installation von Load Balancer, dass folgende Voraussetzungen erfüllt sind:
rpm -e Paketname
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.
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:
Für diese Angaben gilt Folgendes:
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:
Installationspfade von Load Balancer:
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 unter Solaris von der Edge-Components-CD 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 den 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
Installationspfade von Load Balancer:
Das Edge-Components-Fixpack für die Betriebssysteme AIX, HP-UX, Linux, Solaris und Windows wird über die folgenden Medien bereitgestellt:
Informationen zu unterstützten Betriebssystemen finden Sie auf der Webseite mit den detaillierten Systemvoraussetzungen für WebSphere Application Server.
Auf der Unterstützungssite für WebSphere Application Server finden Sie den Link zu den Refresh-Packs oder Fixpacks für Edge Components.
Aktualisierungsinstruktionen finden Sie in den folgenden Abschnitten:
Anweisungen zum Aktualisieren von Load Balancer finden Sie im Load Balancer for IPv4 Administratorhandbuch oder im Load Balancer for IPv4 and IPv6 Administratorhandbuch.
Beachten Sie vor der Fortsetzung der Installation des Refresh- bzw. Fixpacks die folgenden Punkte:
Installieren Sie mit den Paketinstallationstools für Ihr Betriebssystem die Caching-Proxy-Pakete in der richtigen Reihenfolge. Eine Liste aller Edge-Components-Pakete und die Reihenfolge, in der diese Pakete installiert werden müssen, können Sie der Tabelle 4 entnehmen. Nachfolgend werden die Schritte, die Sie in der Regel bei der Installation ausführen müssen, ausführlich beschrieben.
su - root Password: Kennwort
stopsrc -c -s ibmproxy
kill -9 Proxy-PID
Der Begriff Proxy-PID steht für die Prozesskennung des Caching-Proxy-Prozesses. Verwenden Sie den folgenden Befehl, um die PID für Caching Proxy zu bestimmen:
ps -e | grep ibmproxy
/etc/init.d/ibmproxy stop
/etc/rc.d/init.d/ibmproxy stop
kill -9 Proxy-PID
Der Begriff Proxy-PID steht für die Prozesskennung des Caching-Proxy-Prozesses. Verwenden Sie den folgenden Befehl, um die PID für Caching Proxy zu bestimmen:
ps -e | grep ibmproxy
cd Downloadpaketverzeichnis/
Tabelle 8. Systemspezifische Anweisungen für die Installation von Caching Proxy
Systemspezifische Anweisungen für die Installation von Caching Proxy | |
---|---|
Betriebssystem | Befehle |
AIX |
installp -acXd Quelle Paketname Quelle steht hier für das Verzeichnis mit dem Paket und Paketname für den Namen des Pakets. Beispiel:
Gehen Sie wie folgt vor, wenn Sie System Management Interface Tool (SMIT) verwenden:
|
HP-UX |
swinstall -s /Quelle Paketname Quelle steht hier für das Verzeichnis mit dem Paket und Paketname für den Namen des Pakets. Der folgende Befehl installiert beispielsweise das Verwaltungsbefehl für Caching Proxy (WSES-ADMIN), wenn sich das Paket im aktuellen Verzeichnis befindet: swinstall -s /admin WSES-ADMIN Zur Überprüfung der Paketinstallation setzen Sie den Befehl "swlist" ab, um alle installierten Pakete aufzulisten. Setzen Sie beispielsweise die folgenden Befehle ab, um alle Pakete aufzulisten, die für Caching Proxy installiert sind: swlist gsk* swlist WSES* |
Linux |
rpm -iv --replacefiles Paketname Paketname steht für den Namen des Pakets. Verwenden Sie beispielsweise den folgenden Befehl: rpm -iv --replacefiles WSES_Admin_Runtime-6.1.0-1.686.rpm
|
Solaris |
pkgadd -d Quelle Paketname Quelle steht hier für das Verzeichnis mit dem Paket und Paketname für den Namen des Pakets. Beispiel:
Verwenden Sie für eine unbeaufsichtigte Installation die Option "-a", und geben Sie eine Verwaltungsdatei an. Eine Verwaltungsdatei (instadm) wird mit den Paketen bereitgestellt, die Sie installieren. Nach der Installation befinden sich die zuvor installierten Versionen der neuen Pakete immer noch auf der Maschine. Deinstallieren Sie diese nicht. |
In dieser Tabelle sind alle Pakete, die mit Caching Proxy bereitgestellt werden, und die erforderliche Installationsreihenfolge aufgelistet. Installieren Sie die Pakete, die im Refresh- bzw. Fixpack enthalten sind, in der in der folgenden Tabelle aufgelisteten Reihenfolge.
Liste der Pakete | |
Installierte Komponenten | (Generisch aufgelistete) Pakete in dieser Reihenfolge aktualisieren |
Caching Proxy |
|
Dokumentation zu Edge Components | doc-Sprache |
Nach der Installation einer Aktualisierung für Edge Components bleibt die vorherige Konfiguration von Edge Components erhalten. Wenn mit einem Refresh- oder Fixpack neue Funktionen oder Erweiterungen geliefert werden, müssen den Konfigurationsdateien möglicherweise Anweisungen hinzugefügt werden, um die Features zu aktivieren.
Verwenden Sie das Setup-Programm für Caching Proxy wie folgt:
Nach der Installation einer Aktualisierung für Edge Components bleibt die vorherige Konfiguration von Edge Components erhalten. Wenn mit einem Refresh- oder Fixpack neue Funktionen oder Erweiterungen geliefert werden, müssen den Konfigurationsdateien möglicherweise Anweisungen hinzugefügt werden, um die Features zu aktivieren.
Gehen Sie zum Zurückweisen einer Aktualisierung wie folgt vor:
Bei den meisten Komponenten werden die Konfigurationsdateien beim Entfernen des Refresh- bzw. Fixpacks im Verzeichnis "oldfiles/Komponente" gespeichert. Sie können diese Konfigurationsdateien für die reinstallierte Version des Produkts verwenden, um die Konfiguration mit dem Patch-Code in der Version ohne den Patch-Code zu erhalten.
In diesem Teil werden Prozeduren für das Erstellen von Basisdemonetzen mit Edge Components beschrieben. 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:
Abbildung 19 zeigt ein grundlegendes Proxy-Servernetz, in dem drei Computersysteme auf drei Netzknoten verwendet werden. Dieses Netz bindet den Proxy-Server an einen dedizierten Inhaltshost (IBM HTTP Server), der sich auf Server 2 befindet. Der Proxy-Server 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 den folgenden Ausnahmen in allen Installationen von Edge Components verfügbar:
Abbildung 19. Caching-Proxy-Demonetz
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:
Abbildung 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 der 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.
Abbildung 20. Load-Balancer-Demonetz
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.company.com | 9.67.67.101 |
2 | server2.company.com | 9.67.67.102 |
3 | server3.company.com | 9.67.67.103 |
Netzmaske = 255.255.255.0 |
Jede Workstation enthält nur eine Standard-Ethernet-Netzschnittstellenkarte.
Name= www.company.com IP=9.67.67.104
Fügen Sie zur Loopback-Schnittstelle auf server2.company.com und server3.company.com einen Aliasnamen für www.company.com hinzu.
ifconfig lo0 alias www.company.com netmask 255.255.255.0
ifconfig lo0:1 plumb www.company.com netmask 255.255.255.0
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.company.com
dscontrol port add www.company.com:80
dscontrol server add www.company.com:80:server2.company.com
dscontrol server add www.company.com:80:server3.company.com
dscontrol executor configure www.company.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.
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 Clusters, 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