Edge Components for IPv4 Konzepte, Planung und Installation

WebSphere Application Server
Edge Components Konzepte, Planung und Installation

Version 7.0

Erste Ausgabe (Juni 2008)

Diese Ausgabe gilt für:

WebSphere Edge Components Version 7.0

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.


Inhalt

  • Abbildungen

  • Zu diesem Handbuch
  • Zielgruppe
  • Eingabehilfen
  • Konventionen und Terminologie in diesem Handbuch

  • Übersicht

  • Einführung in WebSphere Application Server Edge Components
  • Caching Proxy
  • Load Balancer
  • Dispatcher
  • Content Based Routing
  • Site Selector
  • Cisco CSS Controller
  • Nortel Alteon Controller
  • Metric Server
  • Edge Components und die WebSphere-Familie
  • Tivoli Access Manager
  • WebSphere Portal Server
  • WebSphere Site Analyzer
  • WebSphere Transcoding Publisher
  • Weitere Informationen zu Application Server und Edge Components

  • Konzepte und Beschreibungen zu Edge Components

  • Caching
  • Caching-Proxy-Basiskonfigurationen
  • Reverse Caching Proxy (Standardkonfiguration)
  • Forward Caching Proxy
  • Erweitertes Caching
  • Caching-Proxy-Cluster mit Lastausgleich
  • Dynamischen Inhalt zwischenspeichern
  • Zusätzliche Caching-Funktionen
  • Netzleistung
  • Netzhardware
  • Überlegungen zum Speicher
  • Überlegungen zur Festplatte
  • Überlegungen zum Netz
  • Überlegungen zur CPU
  • Netzarchitektur
  • Überlegungen zur Popularität der Website und zur Arbeitslast des Proxy-Servers
  • Überlegungen zur Art des Datenverkehrs
  • Verfügbarkeit
  • Lastausgleich
  • Lastausgleich für mehrere Inhaltshosts
  • Lastausgleich für mehrere Reverse-Proxy-Server
  • Load Balancer mit mehreren Forward-Proxy-Servern
  • Unterstützung der Lastübernahme
  • Content Based Routing

  • Szenarios

  • B2C-Netz
  • Phase 1
  • Phase 2
  • Phase 3
  • Online-Banking-Lösung

  • Web-Portal-Netz

  • Edge Components installieren

  • Voraussetzungen für Edge Components
  • Hardware- und Softwarevoraussetzungen
  • Verwendung der Konfigurations- und Verwaltungsformulare von Caching Proxy in Browsern
  • Verwendung von Browsern für die Anzeige der Onlinehilfe von Load Balancer
  • Edge Components mit dem Setup-Programm installieren
  • Setup-Programm für Windows verwenden
  • Setup-Programm für Linux und UNIX verwenden
  • Caching Proxy mit dem Paketverwaltungstools des Systems installieren
  • Caching Proxy mit Systemtools deinstallieren
  • Load Balancer mit dem Paketverwaltungstools des Systems installieren
  • Installation unter AIX
  • Installationsvorbereitung
  • Installationsverfahren
  • Installation unter HP-UX
  • Installationsvorbereitung
  • Installationsverfahren
  • Installation unter Linux
  • Installationsvorbereitung
  • Installationsschritte
  • Installation unter Solaris
  • Installationsvorbereitung
  • Installationsschritte

  • Edge Components aktualisieren

  • Caching Proxy für die Betriebssysteme AIX, HP-UX, Linux und Solaris aktualisieren
  • Vorbereitungen
  • Pakete für Caching Proxy unter den Betriebssystemen AIX, HP-UX, Linux und Solaris installieren
  • Caching Proxy für das Betriebssystem Windows aktualisieren

  • Aktualisierung zurückweisen

  • Netze mit Edge Components erstellen

  • Caching-Proxy-Netz erstellen
  • Arbeitsablauf
  • Erforderliche Computersysteme und Software überprüfen
  • Server 1 erstellen (Linux- und UNIX-Systeme)
  • Server 1 erstellen (Windows-System)
  • Server 1 konfigurieren
  • Caching-Proxy-Netz testen
  • Load-Balancer-Netz erstellen
  • Arbeitsablauf
  • Erforderliche Computersysteme und Software überprüfen
  • Das Netz konfigurieren
  • Dispatcher konfigurieren
  • Konfiguration über die Befehlszeile
  • Konfiguration mit dem Konfigurationsassistenten
  • Konfiguration über die grafische Benutzerschnittstelle (GUI)
  • Load-Balancer-Netz testen

  • Abbildungen

    1. Caching Proxy als Reverse Proxy
    2. Caching Proxy als Forward Proxy
    3. Caching Proxy als transparenter Forward Proxy
    4. Caching Proxy als Proxy-Server für einen Cluster mit Lastausgleich
    5. Lastausgleich mit mehreren Inhaltshosts
    6. Lastausgleich mit mehreren Reverse-Proxy-Servern und Inhaltshosts
    7. Dispatcher für den Lastausgleich für mehrere Caching-Proxy-Server verwenden
    8. Verwendung eines primären und eines Ausweich-Dispatchers zur Unterstützung eines Internetzugangs mit hoher Verfügbarkeit
    9. Ausweich-Dispatcher auf einer Caching-Proxy-Maschine
    10. Verwendung eines primären und eines Ausweich-Load-Balancer, um die Verfügbarkeit von Webinhalten zu erhöhen
    11. Installation eines Ausweich-Load-Balancer auf einem Inhaltshost
    12. Routing von HTTP-Anforderungen mit CBR
    13. Mit CBR weitergeleitete HTTP-Anforderungen verteilen
    14. B2C-Netz (Phase 1)
    15. B2C-Netz (Phase 2)
    16. B2C-Netz (Phase 3)
    17. B2C-Banking-Lösung
    18. Webportal
    19. Caching-Proxy-Demonetz
    20. Load-Balancer-Demonetz

    Zu diesem Handbuch

    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.


    Zielgruppe

    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

    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:


    Konventionen und Terminologie in diesem Handbuch

    Diese Dokumentation richtet sich in Bezug auf Typografie und Hervorhebung nach den folgenden Konventionen.

    Tabelle 1. In diesem Handbuch verwendete Konventionen

    KonventionBedeutung
    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.
    EingabetasteBei 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.
    BefehlseingabeWenn 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.

    Übersicht

    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:


    Einführung in WebSphere Application Server Edge Components

    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

    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.


    Load Balancer

    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:

    Dispatcher

    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.

    Content Based Routing

    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:

    Site Selector

    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:

    Cisco CSS Controller

    Anmerkung:
    Die Komponente Cisco CSS Controller wird mit Version 7.0 von Load Balancer for IPv4 geliefert, aber diese Komponente unterstützt möglicherweise keine neuere Hardware. Informationen zur unterstützten Hardware finden Sie auf der folgenden Seite, auf der die Voraussetzungen beschrieben sind: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

    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:

    Nortel Alteon Controller

    Anmerkung:
    Die Komponente Nortel Alteon Controller wird mit Version 7.0 von Load Balancer for IPv4 geliefert, aber diese Komponente unterstützt möglicherweise keine neuere Hardware. Informationen zur unterstützten Hardware finden Sie auf der folgenden Seite, auf der die Voraussetzungen beschrieben sind: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

    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:

    Metric Server

    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.


    Edge Components und die WebSphere-Familie

    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

    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

    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

    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

    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.


    Weitere Informationen zu Application Server und Edge Components

    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:


    Konzepte und Beschreibungen zu Edge Components

    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:

    Caching

    Netzleistung

    Verfügbarkeit

    Content Based Routing


    Caching

    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-Basiskonfigurationen

    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.

    Reverse Caching Proxy (Standardkonfiguration)

    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

    Diese Abbildung zeigt die grundlegende Reverse-Proxy-Konfiguration.

    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.

    Forward Caching Proxy

    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

    Diese Abbildung zeigt die grundlegende Forward-Proxy-Konfiguration.

    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.

    Transparenter Forward Caching Proxy (nur Linux-Systeme)

    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

    Diese Abbildung zeigt die grundlegende Forward-Proxy-Konfiguration.

    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.


    Erweitertes Caching

    Caching-Proxy-Cluster mit Lastausgleich

    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

    Die hier präsentierte Abbildung zeigt einen Proxy-Server, der als Ersatz für einen Cluster mit Lastausgleich dient.

    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.

    Dynamischen Inhalt zwischenspeichern

    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.

    Anmerkung:
    Dynamisch generierte private Seiten (beispielsweise eine Seite, die den Inhalt des elektronischen Warenkorbs eines Benutzers anzeigt) können und sollten im Allgemeinen von Caching Proxy nicht im Cache gespeichert werden. Caching Proxy kann private Seiten nur dann im Cache speichern und bereitstellen, wenn er für die Übernahme von Authentifizierungs- und Berechtigungsaufgaben konfiguriert ist und auf diese Weise sicherstellen kann, dass die privaten Seiten nur den vorgesehenen Benutzern bereitgestellt werden.

    Zusätzliche Caching-Funktionen

    Caching Proxy stellt weitere wichtige Funktionen für erweitertes Caching bereit:


    Netzleistung

    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:


    Netzhardware

    In diesem Abschnitt werden Aspekte der Netzhardware beschrieben, die Sie bei Einführung der Caching-Proxy-Funktionalität in Ihr Netz beachten müssen.

    Überlegungen zum Speicher

    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.

    Überlegungen zur Festplatte

    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.

    Überlegungen zum Netz

    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.

    Überlegungen zur CPU

    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.


    Netzarchitektur

    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.

    Überlegungen zur Popularität der Website und zur Arbeitslast des Proxy-Servers

    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.

    Überlegungen zur Art des Datenverkehrs

    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.


    Verfügbarkeit

    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:


    Lastausgleich

    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.

    Lastausgleich für mehrere Inhaltshosts

    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

    Die hier präsentierte Abbildung zeigt den Lastausgleich für mehrere Inhaltshosts.

    Anmerkung:
    Der Dispatcher unterstützt drei Weiterleitungsmethoden:

    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.

    Lastausgleich für mehrere Reverse-Proxy-Server

    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

    Die hier präsentierte Grafik veranschaulicht den Lastausgleich für mehrere 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.

    Load Balancer mit mehreren Forward-Proxy-Servern

    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.

    Anmerkung:
    Das Feature für transparente Proxy-Server ist nur auf Linux-Systemen verfügbar.

    Abbildung 7. Dispatcher für den Lastausgleich für mehrere Caching-Proxy-Server verwenden.

    Diese Abbildung veranschaulicht den Lastausgleich für mehrere Proxy-Server.

    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.

    Verwendung eines primären und eines Ausweich-Dispatcher zur Unterstützung eines Internetzugangs mit hoher Verfügbarkeit

    Diese Abbildung zeigt die Verwendung eines primären Dispatchers und einen Ausweich-Dispatchers für den Lastausgleich für mehrere Proxy-Server.

    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

    Diese Abbildung zeigt die Verwendung eines primären Dispatchers und eines Ausweich-Dispatchers für den Lastausgleich für mehrere Proxy-Server.


    Unterstützung der Lastübernahme

    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.

    Abbildung 10. Verwendung eines primären und eines Ausweich-Load-Balancer, um die Verfügbarkeit von Webinhalten zu erhöhen

    Die hier präsentierte Abbildung zeigt die Verwendung eines primären Dispatchers und eines Ausweich-Dispatchers für die hohe Verfügbarkeit von Webinhalten.

    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

    Die hier präsentierte Abbildung zeigt den Ausweich-Dispatcher, der auf einem Inhaltshost ausgeführt wird.


    Content Based Routing

    WICHTIG: Die Komponente Content Based Routing (CBR) ist mit den folgenden Ausnahmen auf allen unterstützten Plattformen verfügbar:

    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

    Die hier präsentierte Abbildung veranschaulicht die Weiterleitung von HTTP-Anforderungen mit CBR.

    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 hier präsentierte Abbildung veranschaulicht die Verteilung von HTTP-Anforderungen, die mit CBR weitergeleitet wurden.

    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).


    Szenarios

    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:

    B2C-Netz

    Online-Banking-Lösung

    Web-Portal-Netz


    B2C-Netz

    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:


    Phase 1

    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)

    Diese Abbildung veranschaulicht ein B2C-Beispielbasisnetz.


    Phase 2

    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)

    Diese Abbildung veranschaulicht ein B2C-Beispielnetz.


    Phase 3

    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)

    Diese Abbildung veranschaulicht ein B2C-Beispielnetz.


    Online-Banking-Lösung

    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

    Diese Abbildung veranschaulicht eine B2C-Beispiel-Banking-Lösung.


    Web-Portal-Netz

    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:

    Abbildung 18. Webportal

    Diese Abbildung veranschaulicht ein Beispielwebportal.


    Edge Components installieren

    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


    Voraussetzungen für Edge Components

    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.


    Hardware- und Softwarevoraussetzungen

    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.


    Verwendung der Konfigurations- und Verwaltungsformulare von Caching Proxy in Browsern

    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.

    Anmerkung:
    Auf Linux-Systemen des Typs 64-Bit-PowerPC ist es nicht möglich, mit dem Browser Mozilla auf die Konfigurations- und Verwaltungsformulare zuzugreifen, weil kein SDK für diese Architektur verfügbar ist. Sie können jedoch von einer anderen Maschine mit einem unterstützten Webbrowser auf die Konfigurations- und Verwaltungsformulare zugreifen.

    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:

    1. Rufen Sie die Webseite http://plugindoc.mozdev.org
    2. auf.Wählen Sie im Abschnitt "Documentation" die gewünschte Plattform aus.
    3. Folgen Sie den Anweisungen im Abschnitt "Java Runtime Environment", um das Plug-in zu aktualisieren.

    Verwendung von Browsern für die Anzeige der Onlinehilfe von Load Balancer

    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.


    Edge Components mit dem Setup-Programm installieren

    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:


    Setup-Programm für Windows verwenden

    Mit dem Setup-Programm können Sie Edge Components wie folgt auf Ihrem Windows-System installieren:

    1. Vergewissern Sie sich, dass das Windows-System alle unter Voraussetzungen für Edge Components beschriebenen Hardware- und Softwarevoraussetzungen erfüllt.
    2. Melden Sie sich als Benutzer mit Administratorrechten an.
    3. Legen Sie die Edge-Components-CD in das CD-ROM-Laufwerk ein. Daraufhin wird das LaunchPad automatisch gestartet.
    4. Klicken Sie auf Installationsassistenten für WebSphere Application Server Edge Components starten. Das Setup-Programm wird automatisch gestartet. Es bereitet den InstallShield-Assistenten vor und öffnet das Fenster "Willkommen".
      Anmerkung:
      Wenn Ihre Maschine die Autoplay-Funktion nicht unterstützt oder diese Funktion inaktiviert ist, starten Sie das Setup-Programm manuell. Führen Sie dazu das Programm setup.exe im Ausgangsverzeichnis der CD aus.
    5. Klicken Sie auf Weiter, um die Installation fortzusetzen. Das Fenster "Softwarelizenzvereinbarung" wird geöffnet.
    6. Lesen Sie die Lizenzvereinbarung, und klicken Sie auf Ja, wenn Sie alle Bedingungen akzeptieren. Das Fenster "Komponentenauswahl" wird geöffnet.

      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.

    7. Wählen Sie die zu installierenden Komponenten aus.
    8. Wenn Sie für eine Komponente die Auswahl zu installierender Teilkomponenten ändern wollen, klicken Sie auf den Namen der Komponente. Klicken Sie anschließend auf Teilkomponenten ändern. Daraufhin wird ein weiteres Fenster "Komponentenauswahl" geöffnet, in dem die Teilkomponenten der aktiven Komponente angezeigt werden. Wählen Sie jetzt gemäß der zuvor beschriebenen Vorgehensweise die zu installierenden Teilkomponenten, die Sprache der Komponenten und das Installationsverzeichnis aus.
    9. Wählen Sie in den Menüs Aktuelle Sprache die Sprache bzw. die Sprachen aus, in denen Edge Components installiert werden soll. Im linken Menü werden die verfügbaren Sprachen aufgelistet. Die ausgewählten Sprachen werden im rechten Menü aufgelistet.
    10. Überprüfen Sie im Fenster "Komponentenauswahl" den Installationspfad für Edge Components. Sie können entweder die Standardeinstellung übernehmen oder einen anderen Ordner angeben, indem Sie auf Ordner ändern klicken.
      Anmerkung:
      Wenn Sie einen anderen Installationspfad angeben, verwenden Sie im Pfadnamen keine Leerzeichen. Vermeiden Sie Pfadnamen wie C:\Meine Dateien\Edgeserver\.
    11. Überprüfen Sie im Komponentenauswahlfenster, ob im ausgewählten Installationspfad genügend Speicherplatz verfügbar ist. Ist dies nicht der Fall, klicken Sie auf Ordner ändern, und geben Sie einen anderen Installationspfad an.
    12. Nachdem Sie die Komponenten von Edge Components, den Installationspfad und die Sprachen ausgewählt haben, klicken Sie auf Weiter. Überprüfen Sie die Angaben, die im Fenster "Installationsbestätigung" angezeigt werden. Wenn Sie eine oder mehrere Angaben ändern möchten, klicken Sie auf Zurück, um zum Komponentenauswahlfenster zurückzukehren, in dem Sie Ihre Änderungen vornehmen können. Nachdem Sie die Richtigkeit Ihrer Angaben sichergestellt haben, klicken Sie auf Fertig stellen.
    13. Das Setup-Programm beginnt damit, die ausgewählten Komponenten von Edge Components und gegebenenfalls das GSK in dem angegebenen Installationspfad zu installieren.
    14. Das Fenster "Installation beendet" wird angezeigt. Wenn Sie die Readme-Datei von Edge Components lesen möchten, achten Sie darauf, dass das Kontrollkästchen Ja, die Readme-Datei anzeigen ausgewählt ist. Die Readme-Datei wird im Standardbrowser geöffnet.
    15. Vergewissern Sie sich, dass das Kontrollkästchen Ja, den Computer jetzt neu starten ausgewählt ist, und klicken Sie dann auf Fertig stellen. Wenn Sie die Option zum Anzeigen der Readme-Datei ausgewählt haben, wird die Maschine neu gestartet, sobald Sie das Browserfenster mit der Readme-Datei schließen. Andernfalls wird das Setup-Programm des Produkts Edge Components sofort beendet, und die Maschine wird neu gestartet. Damit Sie eine der neu installierten Komponenten von Edge Components verwenden können, müssen Sie die Maschine neu starten.

    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.


    Setup-Programm für Linux und UNIX 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:

    1. Vergewissern Sie sich, dass der Server alle in Voraussetzungen für Edge Components beschriebenen Hardware- und Softwarevoraussetzungen erfüllt.
    2. Melden Sie sich als lokaler Superuser (normalerweise "root") an.
    3. Legen Sie die Edge-Components-CD in das CD-ROM-Laufwerk der Maschine ein. Hängen Sie das CD-ROM-Laufwerk gegebenenfalls per Mount an.
    4. Wechseln Sie aus Ihrem Arbeitsverzeichnis in das Basisverzeichnis der CD.
    5. Rufen Sie das Setup-Programm mit dem folgenden Befehl auf:
      # ./install
      
      Das Fenster "Willkommen" wird geöffnet.
    6. Klicken Sie auf Weiter, um die Installation fortzusetzen. Das Fenster "Softwarelizenzvereinbarung" wird geöffnet.
    7. Lesen Sie die Lizenzvereinbarung, und klicken Sie auf Ja, wenn Sie alle Bedingungen akzeptieren. Das Fenster "Sprachauswahl" wird geöffnet.
    8. Wählen Sie die Sprachen aus, die in dieser Installation von Edge Components unterstützt werden sollen. Klicken Sie auf Weiter. Das Fenster "Komponentenauswahl" wird geöffnet.
    9. Wählen Sie die zu installierenden Komponenten aus.
    10. Klicken Sie auf Weiter. Das Fenster "Installation beendet" wird geöffnet.
    11. Überprüfen Sie die Informationen in diesem Fenster. Wenn Sie eine Einstellung ändern möchten, klicken Sie auf Zurück. Daraufhin wird das Komponentenauswahlfenster wieder angezeigt, in dem Sie Ihre Änderungen vornehmen können. Nachdem Sie die Richtigkeit Ihrer Angaben sichergestellt haben, klicken Sie auf Weiter.

      Das Setup-Programm beginnt mit der Installation der ausgewählten Komponenten von Edge Components und der erforderlichen Pakete.

    12. Das Fenster "Installationsergebnisse" wird angezeigt. Überprüfen Sie die Ergebnisse, und klicken Sie dann auf Fertig stellen.

    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.


    Caching Proxy 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.

    1. Legen Sie die Edge-Components-CD in das CD-ROM-Laufwerk ein und hängen Sie das Laufwerk gegebenenfalls per Mount an.
    2. Melden Sie sich als lokaler Superuser "root" an:
      su - root
      Password: Kennwort
      
    3. Wechseln Sie in das gewünschte Verzeichnis der CD:
      cd Mount-Punkt/Paketverzeichnis/
      
    4. Installieren Sie die Pakete:

      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

    KomponenteInstallierte Pakete (empfohlene Reihenfolge)
    Caching Proxy
    1. gskit7
    2. icu
    3. admin
    4. msg-cp-Sprache
    5. cp

    Dokumentation zu Edge Components

    doc-en_US 1

    Anmerkungen:

    1. Die Dokumentation zu Load Balancer wird in zwei Paketen bereitgestellt. Das Paket 'doc-en_US' enthält die gesamte Dokumentation zu Edge Components, einschließlich der Dokumente zu Load Balancer, die im Verzeichnis '../edge/doc/' abgelegt werden. Das Dokumentationspaket für Load-Balancer-Installationen ((Load Balancer mit den Paketverwaltungstools des Systems installieren) installiert nur die Dokumente zu Load Balancer in einem Unterverzeichnis des Verzeichnisses '../edge/lb/'.


    Tabelle 3. Paketdateinamen unter AIX, HP-UX und Solaris

    Generischer PaketnameAIX-Dateigruppe HP-UX-DateigruppeSolaris-Dateiname
    adminwses_admin.rteWSES-ADMINWSESadmin
    cpwses_cp.baseWSES-CPWSEScp
    docwses_doc.en_US WSES-DOC-en_US WSESdocen
    gskit7gskkm.rtegsk7basgsk7bas
    icuwses_icu.rteWSES-ICUWSESicu
    msg-cp-Sprache wses_cp.msg.Sprache 1 .baseWSES-cpmSprache2 WSEScpmSprache3

    Anmerkungen:

    1. Unter AIX muss die Variable Sprache durch einen der folgenden sprachspezifischen Codes ersetzt werden: en_US, de_CH, de_DE, es_ES, fr_CA, fr_CH, fr_FR, it_CH, it_IT, ja_JP, Ja_JP, ko_KR, pt_BR, zh_CN, ZH_CN, zh_TW, Zh_TW.

    2. Unter HP-UX muss die Variable Sprache durch einen der folgenden sprachspezifischen Codes ersetzt werden: de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW. (HP-UX bietet keine Unterstützung für brasilianisches Portugiesisch (pt_BR).)

    3. Unter Solaris muss die Variable Sprache durch einen der folgenden sprachspezifischen Codes ersetzt werden: br, cn, cw, de, en, es, fr, it, ja, kr.


    Tabelle 4. Paketdateinamen unter Linux

    Generischer PaketnameLinux-Dateiname
    adminWSES_Admin_Runtime-Releaseversion 1.Hardware2.rpm
    cpWSES_CachingProxy-Releaseversion1.Hardware2.rpm
    docWSES_Doc_en_US-Releaseversion1.Hardware2.rpm
    gskit7gsk7bas.rpm
    icuWSES_ICU_Runtime-Releaseversion 1.Hardware2.rpm
    msg-cp-Sprache WSES_CachingProxy_msg_Sprache3-Releaseversion 1.Hardware2.rpm

    Anmerkungen:

    1. Releaseversion steht für das aktuelle Release, z. B. 6.1.0-0.

    2. Die Variable Hardware muss durch einen der folgenden Werte ersetzt werden: i686, s390, ppc64.

    3. Die Variable Sprache muss durch einen der folgenden sprachspezifischen Codes ersetzt werden: de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, pt_BR, zh_CN, zh_TW.

    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.


    Caching Proxy mit Systemtools deinstallieren

    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.


    Load Balancer mit den Paketverwaltungstools des Systems installieren

    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.


    Installation unter AIX

    Tabelle 5 enthält eine Liste der AIX-Dateigruppen für Load Balancer und die empfohlene Installationsreihenfolge unter Verwendung des Paketinstallationstools des Systems auf.

    Tabelle 5. AIX-Dateigruppen

    Load-Balancer-KomponentenAIX-Dateigruppen
    Basis ibmlb.base.rte
    Verwaltung (mit Nachrichten)
    • ibmlb.admin.rte
    • ibmlb.msg.Sprache.admin

    Einheitentreiberibmlb.lb.driver
    Lizenzibmlb.lb.license
    Load-Balancer-Komponenten (mit Nachrichten)
    • ibmlb.Komponente.rte
    • ibmlb.msg.Sprache.lb

    Dokumentation (mit Nachrichten)
    • ibmlb.doc.rte
    • ibmlb.msg.en_US.doc

    Metric Server ibmlb.ms.rte

    Anmerkungen:

    1. Die Variable Komponente kann durch eines der folgenden Komponentenkürzel ersetzt werden: disp (Dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) oder nal (Nortel Alteon Controller).

    2. Die Variable Sprache kann durch einen der folgenden sprachspezifischen Codes ersetzt werden: en_US, de_CH, de_DE, es_ES, fr_CA, fr_CH, fr_FR, it_CH, it_IT, ja_JP, Ja_JP, ko_KR, pt_BR, zh_CN, ZH_CN, zh_TW, Zh_TW.

    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.

    Installationsvorbereitung

    Vergewissern Sie sich vor der Installation von Load Balancer unter AIX, dass folgende Voraussetzungen erfüllt sind:

    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:

    Installationsverfahren

    Es wird empfohlen, Load Balancer unter AIX mit SMIT zu installieren, da in diesem Fall alle Nachrichten automatisch installiert werden.

    Load Balancer unter AIX mit SMIT installieren

    1. Wählen Sie Softwareinstallation und -wartung aus.
    2. Wählen Sie Software installieren und aktualisieren aus.
    3. Wählen Sie Installation und Aktualisierung der zuletzt verfügbaren Software aus.
    4. Geben Sie die Einheit oder das Verzeichnis mit den Dateigruppen ein.
    5. Geben Sie im Feld Zu installierende Software die gewünschten Komponenten an (oder wählen Sie "Liste" aus).
    6. Klicken Sie auf OK.
    7. Nach Ausführung des Befehls klicken Sie auf Fertig.
    8. Beenden Sie SMIT, indem Sie im Menü Beenden die Option SMIT beenden auswählen oder die Taste F12 drücken. Falls Sie SMITTY verwenden, drücken Sie die Taste F10, um das Programm zu beenden.

    Load Balancer über die Befehlszeile installieren

    1. Falls Sie das Produkt von einer CD installieren, geben Sie die folgenden Befehle ein, um das CD-ROM-Laufwerk per Mount anzuhängen:
      mkdir /cdrom
      mount -v cdrfs -p -r /dev/cd0 /cdrom
    2. In der folgenden Tabelle sind die Befehle aufgeführt, die Sie eingeben müssen, um die gewünschten Pakete von Load Balancer unter AIX zu installieren:

      Tabelle 6. AIX-Installationsbefehle

      PaketeBefehle
      Basis installp -acXgd Einheit ibmlb.base.rte
      Verwaltung (mit Nachrichten)installp -acXgd Einheit ibmlb.admin.rte ibmlb.msg.Sprache.admin
      Einheitentreiberinstallp -acXgd Einheit ibmlb.lb.driver
      Lizenzinstallp -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
      Einheit kann durch Folgendes ersetzt werden:
    3. Vergewissern Sie sich, dass die Ergebnisspalte in der Zusammenfassung für alle installierten Komponenten von Load Balancer die Angabe ERFOLGREICH enthält. Fahren Sie erst fort, wenn alle zu installierenden Komponenten erfolgreich installiert wurden.
      Anmerkung:
      Wenn Sie für eine ausgewählte Einheit eine Liste der Dateigruppen einschließlich aller verfügbaren Nachrichtenkataloge generieren möchten, geben Sie Folgendes ein:
      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:


    Installation unter HP-UX

    In diesem Abschnitt wird erläutert, wie Load Balancer unter HP-UX von der Produkt-CD installiert wird.

    Installationsvorbereitung

    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.

    Installationsverfahren

    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-Lizenzibmlb.lic
    Load-Balancer-Komponentenibmlb.Komponente
    Dokumentationibmlb.doc
    Metric Server ibmlb.ms

    Anmerkungen:

    1. Die Variable Sprache muss durch einen der folgenden sprachspezifischen Codes ersetzt werden: de_DE, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW.

    2. Die Variable Komponente muss durch einen der folgenden Werte ersetzt werden: disp (Dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) oder nal (Nortel Alteon Controller).

    3. Das Dokumentationspaket (ibmlb.doc) 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.

    HP-UX bietet keine Unterstützung für die Locale Brasilianisches Portugiesisch (pt_BR). Die folgenden Locales werden unter HP-UX unterstützt:

    Anweisungen für die Installation der Pakete

    Im Folgenden sind die Schritte, die Sie zum Installieren des Produkts ausführen müssen, ausführlich beschrieben.

    1. Melden Sie sich als lokaler Superuser "root" an:
      su - root
      Password: Kennwort
      
    2. Führen Sie den Installationsbefehl zum Installieren der Pakete aus.

      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
    3. Überprüfen Sie die Installation der Load-Balancer-Pakete.

      Führen Sie den Befehl swlist aus, um alle Pakete aufzulisten, die Sie installiert haben. Beispiel:

      swlist -l fileset ibmlb
       
      

    Anweisungen für die Deinstallation der Pakete

    Verwenden Sie den Befehl swremove, um die Pakete zu deinstallieren. Die Pakete müssen in umgekehrter Installationsreihenfolge deinstalliert werden. Beispiel:

    Installationspfade von Load Balancer:


    Installation unter Linux

    In diesem Abschnitt wird erläutert, wie Load Balancer unter Linux von der Edge-Components-CD installiert wird.

    Installationsvorbereitung

    Vergewissern Sie sich vor der Installation von Load Balancer, dass folgende Voraussetzungen erfüllt sind:

    Installationsschritte

    1. Legen Sie die Edge-Components-CD in das CD-ROM-Laufwerk ein oder laden Sie das Produkt von der Website herunter und installieren Sie das Installations-Image mit RPM (Red Hat Packaging Manager).

      Das Installations-Image ist eine Datei im Format lblinux-Version.tar.

    2. Entpacken Sie die tar-Datei mit dem folgenden Befehl in einem temporären Verzeichnis:
      tar -xf lblinux-Version.tar
      Folgende 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.

    3. Führen Sie im Verzeichnis mit den RPM-Dateien folgenden Befehl aus, um die einzelnen Pakete zu installieren. Beispiel:
      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:

      Anmerkung:
      Mindestens eine RPM-Datei erfordert, dass Java installiert und in der RPM-Datenbank registriert ist. Ist Java installiert, aber nicht in der RPM-Datenbank registriert, verwenden Sie den Installationsbefehl mit der Option "nodeps" (no dependencies, keine Abhängigkeiten) wie folgt:
      rpm -i --nodeps Paket.rpm 
      
    4. Überprüfen Sie, ob das Produkt installiert ist. Geben Sie dazu folgenden Befehl ein:
      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.


    Installation unter Solaris

    In diesem Abschnitt wird erläutert, wie Load Balancer unter Solaris von der Edge-Components-CD installiert wird.

    Installationsvorbereitung

    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
    

    Installationsschritte

    1. Legen Sie die CD-ROM mit der Load-Balancer-Software in das CD-ROM-Laufwerk ein.
    2. Geben Sie an der Eingabeaufforderung folgenden Befehl ein:
      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.

    3. Überprüfen Sie, ob das Produkt installiert ist. Geben Sie dazu folgenden Befehl ein:
      pkginfo | grep ibm

    Installationspfade von Load Balancer:


    Edge Components aktualisieren

    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.

    1. Suchen Sie das Fehlerberichtigungsrelease, auf das Sie das Upgrade durchführen möchten, und folgen Sie dann dem Link zur Downloadsite.
    2. Folgen Sie den Anweisungen auf der Site, um das Edge-Components-Refresh-Pack herunterzuladen.
    Anmerkung:
    Sie können die aktuellen Fixpacks für Edge Components auch vom FTP-Server für Edge Components herunterladen.

    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.


    Caching Proxy für die Betriebssysteme AIX, HP-UX, Linux und Solaris aktualisieren


    Vorbereitungen

    Beachten Sie vor der Fortsetzung der Installation des Refresh- bzw. Fixpacks die folgenden Punkte:


    Pakete für Caching Proxy unter den Betriebssystemen AIX, HP-UX, Linux und Solaris installieren

    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.

    1. Melden Sie sich als lokaler Superuser Root an.
      su - root
      Password: Kennwort
      
    2. Stoppen Sie den Prozess von Caching Proxy.
    3. Wechseln Sie in das Verzeichnis, das die Installationsdateien enthält. Geben Sie beispielsweise Folgendes an der Eingabeaufforderung ein:
      cd Downloadpaketverzeichnis/
      
    4. Installieren Sie die Pakete mit den in der folgenden Tabelle aufgelisteten Installationsbefehlen. Die Installationsreihenfolge für die Pakete des Refresh- bzw. Fixpacks ist wie folgt:
      1. gskit - Global Security Kit
      2. icu - ICU-Laufzeitumgebung
      3. admin - Verwaltungslaufzeitumgebung
      4. cp messages - Caching-Proxy-Nachrichten
      5. cp - Caching Proxy
      6. documentation - optional

      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:

      1. Der folgende Befehl installiert das Verwaltungspaket (wses_admin.rte), wenn sich die Pakete im aktuellen Verzeichnis befinden:
        installp -acXd . wses_admin.rte
        
      2. Der folgende Befehl installiert das Verwaltungsbefehl, wenn sich die Pakete im Verzeichnis "/tmp" befinden.
        installp -acXd /tmp wses_admin.rte
        

      Gehen Sie wie folgt vor, wenn Sie System Management Interface Tool (SMIT) verwenden:

      1. Wählen Sie die Option install_latest aus.
      2. Setzen Sie den Wert im Feld "Softwareaktualisierungen festschreiben" auf ja.
      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
      
      Anmerkung:
      Verwenden Sie nicht die Option "-U". Die Option "--replacefiles" ist für die meisten Pakete erforderlich. Die Verwendung dieser Option für Pakete, die diese Option nicht erfordern, hat keine Auswirkung auf ihre Installation. Nach der Installation befinden sich die zuvor installierten Versionen der neuen Pakete immer noch auf der Maschine. Deinstallieren Sie diese nicht.
      Solaris
      pkgadd -d Quelle Paketname
      

      Quelle steht hier für das Verzeichnis mit dem Paket und Paketname für den Namen des Pakets.

      Beispiel:

      • Der folgende Befehl installiert das Verwaltungspaket (WSESadmin), wenn sich die Pakete im aktuellen Verzeichnis befinden:
        pkgadd -d . WSESadmin
        
      • Der folgende Befehl installiert das Verwaltungsbefehl, wenn sich die Pakete im Verzeichnis "/tmp" befinden:
        pkgadd -d /tmp WSESadmin
        
      • Bei der Installation von GSKit installiert der folgende Befehl das Paket über eine vorherige Version:
        pkgadd -a ./admin -d . gsk7bas
        

      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.

    Anmerkung:
    Nicht alle hier aufgelisteten Pakete werden mit dem Refresh- bzw. Fixpack bereitgestellt. Aktualisieren Sie nur die Pakete, die mit dem Refresh- bzw. Fixpack bereitgestellt werden und zuvor auf dem System installiert waren.

    Tabelle 9. Liste der Pakete

    Liste der Pakete
    Installierte Komponenten (Generisch aufgelistete) Pakete in dieser Reihenfolge aktualisieren
    Caching Proxy
    1. gskit7 -- Global Security Kit
    2. icu -- ICU-Laufzeitumgebung
    3. admin -- Verwaltungslaufzeitumgebung
    4. msg-cp-Sprache -- Nachrichten
    5. cp -- 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.


    Caching Proxy für das Betriebssystem Windows aktualisieren

    Verwenden Sie das Setup-Programm für Caching Proxy wie folgt:

    1. Wenn Sie verhindern möchten, dass die derzeit installierte Version von Load Balancer gestartet wird, müssen Sie alle Startscripts bearbeiten, die Sie erstellt haben, und vorübergehend alle Befehle unterdrücken, die bewirken, dass Load Balancer nach einem Warmstart gestartet wird.
    2. Stellen Sie sicher, dass der Load-Balancer-Dienst auf "Manuell" eingestellt ist.
    3. Starten Sie Ihre Windows-Maschine erneut.
    4. Laden Sie das Refresh- oder Fixpack für Edge Components herunter.
    5. Verwenden Sie das Programm "Software", um die aktuelle Komponente Load Balancer zu deinstallieren, sofern vorhanden.
    6. Führen Sie das Installationsprogramm mit einer der folgenden Aktionen aus:
    7. Geben Sie die vom Installationsprogramm angeforderten Informationen ein.

    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.


    Aktualisierung zurückweisen

    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.


    Netze mit Edge Components erstellen

    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:

    Caching-Proxy-Netz erstellen

    Load-Balancer-Netz erstellen


    Caching-Proxy-Netz erstellen

    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

    Caching-Proxy-Demonetz


    Arbeitsablauf

    Zum Erstellen eines Caching-Proxy-Netzes führen Sie nacheinander folgende Arbeitsschritte aus:

    1. Erforderliche Computersysteme und Software überprüfen
    2. Server 1 erstellen (Linux- und UNIX-Systeme) oder Server 1 erstellen (Windows-System)
    3. Server 1 konfigurieren
    4. Caching-Proxy-Netz testen

    Erforderliche Computersysteme und Software überprüfen

    Folgende Computersysteme und Zusatzsoftware werden benötigt:


    Server 1 erstellen (Linux- und UNIX-Systeme)

    Installieren und konfigurieren Sie Caching Proxy wie folgt:

    1. Vergewissern Sie sich, dass der Server alle Hardware- und Softwarevoraussetzungen erfüllt.
    2. Melden Sie sich als lokaler Superuser (normalerweise "root") an.
    3. Installieren Sie die Komponente Caching Proxy.
    4. Geben Sie zum Erstellen einer Administrator-ID und eines Kennworts für den Zugriff auf die Konfigurations- und Verwaltungsformulare folgenden Befehl ein:
      # 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.

    5. Fahren Sie mit der Konfiguration von Server 1 fort.

    Server 1 erstellen (Windows-System)

    Installieren und konfigurieren Sie Caching Proxy wie folgt:

    1. Vergewissern Sie sich, dass die Betriebssysteme Windows 2000 und Windows 2003 alle Hardware- und Softwarevoraussetzungen erfüllen.
    2. Melden Sie sich als Benutzer mit Administratorrechten an.
    3. Installieren Sie die Komponente Caching Proxy.
    4. Geben Sie zum Erstellen einer Administrator-ID und eines Kennworts für den Zugriff auf die Konfigurations- und Verwaltungsformulare folgenden Befehl ein:
      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.

    5. Fahren Sie mit der Konfiguration von Server 1 fort.

    Server 1 konfigurieren

    Führen Sie auf der Workstation folgende Aktionen aus:

    1. Starten Sie einen Webbrowser.
    2. Geben Sie im Feld Adresse Ihres Browsers http://server_1 ein, wobei server_1 für den tatsächlichen Hostnamen oder die IP-Adresse der Maschine steht, die als Server 1 bestimmt wurde.
    3. Klicken Sie auf Konfigurations- und Verwaltungsformulare.
    4. Geben Sie Administratornamen und Kennwort ein. Die Konfigurations- und Verwaltungsformulare werden in Ihrem Browser angezeigt.
    5. Klicken Sie auf Serverkonfiguration-->Anforderungsverarbeitung-->Anforderungs-Routing.
    6. Fügen Sie vor der vorhandenen Ausweichzuordnungsregel eine neue ein, indem Sie den Radioknopf Einfügen vor und den Indexwert der vorhandenen Ausweichzuordnungsregel auswählen.
    7. Wählen Sie in der Dropdown-Liste Aktion die Option Proxy aus.
    8. Geben Sie im Feld URL-Anforderungsschablone die Zeichen /* ein.
    9. Geben Sie im Feld IP-Adresse oder Hostname des Servers den Hostnamen der Site ein, an die HTTP-Anforderungen weitergeleitet werden sollen. Stellen Sie diesem Wert die Angabe http:// voran.
    10. Klicken Sie auf Übergeben.
    11. Fügen Sie eine Zuordnungsregel ein, die den Zugriff auf die Konfigurations- und Verwaltungsformulare ermöglicht. Wählen Sie dazu den Radioknopf Einfügen vor und den Indexwert der Zuordnungsregel von Schritt 6 aus.
    12. Wählen Sie in der Dropdown-Liste Aktion die Option Pass aus.
    13. Geben Sie im Feld URL-Anforderungsschablone den Wert /pub/* ein.
    14. Geben Sie die Position der Konfigurations- und Verwaltungsformulare an:
    15. Klicken Sie auf Übergeben.
    16. Klicken Sie oben im Konfigurationsformular auf das Symbol Server erneut starten.
    17. Fahren Sie mit dem Testen des Caching-Proxy-Netzes fort.

    Caching-Proxy-Netz testen

    Führen Sie auf der Workstation folgende Aktionen aus:

    1. Starten Sie einen Webbrowser.
    2. Geben Sie im Browser im Feld Adresse den Befehl http://Server_1 ein. HTML-Seiten von Server 2 werden über Server 1 als Proxy-Server an den Webbrowser übermittelt.
    3. Geben Sie für den Zugriff auf die Konfigurations- und Verwaltungsformulare http://server_1/pub/ im Feld Adresse Ihres Browsers ein. Daraufhin wird die Homepage der Konfigurations- und Verwaltungsformulare angezeigt.

    Load-Balancer-Netz erstellen

    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

    Eine Abbildung, die einen Client, eine Internetwolke, eine Load-Balancer-Maschine und zwei lokal angeschlossene Server mit angegebenen Adressen zeigt.

    Anmerkung:
    Für diese Konfiguration würden zwei Workstations reichen. Der Dispatcher würde sich dabei auf einer der Webserver-Workstations befinden. Dies wäre dann eine Konfiguration, in der Server und Dispatcher zusammengelegt wurden.

    Arbeitsablauf

    Zum Aufbau eines Load-Balancer-Netzes führen Sie nacheinander die folgenden Arbeitsschritte aus:

    1. Erforderliche Computersysteme und Software überprüfen
    2. Netz konfigurieren
    3. Dispatcher konfigurieren
    4. Load-Balancer-Netz testen

    Erforderliche Computersysteme und Software überprüfen

    Folgende Computersysteme und Zusatzsoftware werden benötigt:


    Das Netz konfigurieren

    1. Konfigurieren Sie Ihre Workstations so, dass sie sich innerhalb eines LAN-Segments befinden. Stellen Sie sicher, dass der Datenaustausch im Netz zwischen den drei Maschinen nicht über Router oder Bridges erfolgen muss.
    2. Konfigurieren Sie die Netzwerkadapter der drei Workstations. In diesem Beispiel wird die folgende Netzkonfiguration angenommen:
      WorkstationNameIP-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.

    3. Stellen Sie sicher, dass server1.company.com Ping-Aufrufe sowohl an server2.company.com als auch an server3.company.com senden kann.
    4. Stellen Sie sicher, dass server2.company.com und server3.company.com Ping-Aufrufe an server1.company.com senden können.
    5. Stellen Sie sicher, dass der Inhalt auf den beiden Webservern (Server 2 und 3) identisch ist. Dazu können die Daten auf den beiden Workstations repliziert werden, indem ein gemeinsames Dateisystem wie AFS oder DFS oder eine andere für Ihre Site geeignete Methode verwendet wird.
    6. Stellen Sie sicher, dass die Webserver auf server2.company.com und server3.company.com betriebsbereit sind. Rufen Sie die Seiten in einem Webbrowser direkt von http://server2.company.com und http://server3.company.com ab.
    7. Definieren Sie eine andere gültige IP-Adresse für dieses LAN-Segment. Dies ist die Adresse, die Sie den Clients mitteilen, die auf Ihre Site zugreifen möchten. In diesem Beispiel handelt es sich um folgende Angabe:
      Name= www.company.com
      IP=9.67.67.104 
      
    8. Konfigurieren Sie die beiden Webserver-Workstations in der Weise, dass sie Datenübertragungen für www.company.com akzeptieren.

      Fügen Sie zur Loopback-Schnittstelle auf server2.company.com und server3.company.com einen Aliasnamen für www.company.com hinzu.

    9. Löschen Sie alle zusätzlichen Routes, die eventuell infolge der Zuweisung eines Aliasnamens für die Loopback-Schnittstelle erstellt wurde.

      Sie haben jetzt alle für die beiden Webserver-Workstations erforderlichen Konfigurationsschritte ausgeführt.


    Den Dispatcher konfigurieren

    Die Konfiguration des Dispatcher können Sie über die Befehlszeile, den Konfigurationsassistenten oder die grafische Benutzerschnittstelle (GUI) erstellen.

    Anmerkung:
    Die Parameterwerte müssen mit Ausnahme der Parameterwerte für Hostnamen und Dateinamen aus dem englischen Zeichensatz stammen.

    Konfiguration über die Befehlszeile

    Gehen Sie zum Konfigurieren des Dispatcher über die Befehlszeile wie folgt vor:

    1. Starten Sie dsserver auf dem Dispatcher wie folgt:

    2. Starten Sie die Executor-Funktion von Dispatcher:
      dscontrol executor start
      
    3. Fügen Sie die Clusteradresse der Dispatcher-Konfiguration hinzu:
      dscontrol cluster add www.company.com
      
    4. Fügen Sie der Dispatcher-Konfiguration wie folgt den Port für das Protokoll HTTP hinzu:
      dscontrol port add www.company.com:80
      
    5. Fügen Sie jeden der Webserver der Dispatcher-Konfiguration hinzu:
      dscontrol server add www.company.com:80:server2.company.com
      
      dscontrol server add www.company.com:80:server3.company.com
      
    6. Konfigurieren Sie wie folgt die Workstation, so dass sie den Datenverkehr für die Clusteradresse akzeptiert:

      dscontrol executor configure www.company.com
      
    7. Starten Sie die Managerfunktion des Dispatchers.
      dscontrol manager start
      

      Der Dispatcher führt den Lastausgleich jetzt basierend auf der Serverleistung durch.

    8. Starten Sie wie folgt die Advisor-Funktion des Dispatchers:
      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.

    Konfiguration mit dem Konfigurationsassistenten

    Gehen Sie zum Konfigurieren des Dispatcher mit dem Konfigurationsassistenten wie folgt vor:

    1. Starten Sie dsserver auf dem Dispatcher wie folgt:

    2. Starten Sie den Assistenten des Dispatcher, dswizard.

    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:

    Konfiguration über die grafische Benutzerschnittstelle (GUI)

    Gehen Sie zum Starten der GUI wie folgt vor:

    1. Stellen Sie sicher, dass der dsserver-Prozess aktiv ist:
    2. Führen Sie anschließend einen der folgenden Schritte aus:

    Load-Balancer-Netz testen

    1. Rufen Sie in einem Webbrowser die Adresse http://www.company.com auf, um zu überprüfen, ob eine Seite angezeigt wird.
    2. Laden Sie die Seite erneut in den Webbrowser.
    3. Setzen Sie den folgenden Befehl ab: dscontrol server report www.company.com:80:. Überprüfen Sie, ob die Summe der Spalten "Summe Verbindungen" der beiden Server 2 ergibt.