WebSphere Load Balancer
             Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows

             Inhaltsverzeichnis und Suchergebnisse personalisieren

Geschäftsszenarios für Load Balancer

In den folgenden Geschäftsszenarios wird WebSphere Application Server Edge Components zusammen mit WebSphere Application Server Proxy verwendet. Diese Geschäftsszenarios sind architektonisch stabile und getestete Lösungen, die eine exzellente Leistung, Verfügbarkeit, Skalierbarkeit und Zuverlässigkeit unterstützen.

Dieser Artikel enthält die folgenden Szenarios:

B2C-Netz

Die Basiswebsite für elektronischen Handel ist ein B2C-Netz. In der ersten Phase des Internetwachstums konzentrieren sich Geschäfte gewöhnlich einfach auf die Erstellung eines Webauftritts. Unternehmensinformationen und Produktkataloge werden werden in digitale Formate konvertiert und auf der Website verfügbar gemacht. Einkauf ist unter Umständen möglich, indem E-Mail-Adresen, Telefon- und Faxnummern oder sogar automatisierte Formulare bereitgestellt werden. Ein echter Onlineeinkauf ist jedoch nicht verfügbar. Alle Transaktionen haben eine inhärente Latenzzeit, weil der Auftrag von Menschen verarbeitet werden muss.

In Phase zwei schaffen Geschäfte diese Latenzzeit ab und rationalisieren ihre Verkaufstätigkeiten, indem sie sichere Einkaufswagen für direkte Onlineeinkäufe implementieren. Die Synchronisation mit Warehouse-Datenbanken und die Integration mit Banksystemen ist für die Durchführung dieser Verkaufstransaktionen von entscheidender Bedeutung. Produkte, die nicht verfügbar sind, können nicht verkauft werden, und es kann kein Kundenkonto für diesen Artikel belastet werden. Ein Produkt kann erst dann aus dem Bestand entnommen und an einen Kunden geliefert werden, bis eine gültige Finanztransaktion stattfindet.

In der dritten Phase entwickelt sich die Unternehmenswebsite zu einer dynamischen Präsentationssite, bei der der Kunde zu einem Client wird, dem personalisierter Inhalt bereitgestellt wird. Das folgende Szenario enthält Load Balancer und WebSphere Application Server Proxy.

Phase 1: Die folgende Abbildung zeigt eine kleine kommerzielle Website für effizientes Katalog-Browsing.


Einzelhandelsnetz (Phase 1)

Alle Clientanforderungen werden über die Firewall an einen Dispatcher übergeben, der die Anforderungen an einen Cluster von Proxy-Servern mit aktiven Caches weiterleitet, die als Ersatzserver für die Webserver dienen. Für die Bereitstellung von Lastausgleichsdaten an den Dispatcher werden den Proxy-Servern Metric Server zur Seite gestellt. Diese Zusammenstellung verringert die Netzlast auf den Webservern und isoliert sie vom direkten Kontakt mit dem Internet.

Phase 2: Die nächste Abbildung zeigt die zweite Phase der Entwicklung einer kommerziellen Website für effizientes Katalog-Browsing, die jetzt schnelle und sichere Einkaufswagen für potenzielle Kunden bereitstellt.


Einzelhandelsnetz (Phase 2)

Alle Kundenanforderungen werden von einem Dispatcher, die Anforderungen auf der Basis des Internetprotokolls trennt, an die entsprechende Netzverzweigung weitergeleitet. HTTP-Anforderungen werden an die statische Website weitergeleitet und HTTPS-Anforderungen an das Einkaufsnetz. Die primäre statische Website wird weiterhin von einem Cluster von Proxy-Servern mit aktiven Caches bedient, die als Ersatzserver für die Webserver dienen. Dieser Teil des Netzes spiegelt das Netz in der ersten Phase wider.

Der Teil der Website, der für den elektronischen Handel zuständig ist, wird ebenfalls von einem Cluster von Proxy-Servern bedient wird. Die Caching-Proxy-Knoten sind jedoch mit mehreren Plug-in-Modulen erweitert. Das SSL-Handshake-Verfahren wird auf eine Verschlüsselungshardwarekarte ausgelagert, und die Authentifizierung wird vom Access-Manager-Plug-in (früher Policy Director) durchgeführt. Ein Plug-in für dynamisches Caching verringert die Arbeitslast des WebSphere Application Server, indem es allgemeine Daten speichert. Ein Plug-in im Anwendungsserver macht Objekte im dynamischen Cache ungültig, wenn dies erforderlich ist.

Alle Einkaufswagenanwendungen sind an die Kundendatenbank gebunden, die für die Authentifizierung des Benutzers verwendet wurde. Auf diese Weise wird verhindert, dass der Benutzer persönliche Informationen doppelt in das System eingeben muss, einmal für die Authentifizierung und einmal für den Einkauf.

In diesem Netz wird der Datenverkehr der Clientnutzung entsprechend aufgeteilt, indem prozessorintensive SSL-Authentifizierung und Einkaufswagen für elektronischen Einkauf von der primären Website entfernt werden. Diese "zweispurige" Website ermöglicht dem Netzadministrator, die verschiedenen Server so zu optimieren, dass die je nach Rolle des Servers im Netz eine exzellente Leistung bieten.

Phase 3: Die letzte Abbildung zeigt die dritte Phase der Entwicklung eines B2C-Netzes mit der Übernahme einer dynamischen Präsentationsmethode in das statische Web. Der Proxy-Servercluster wurde erweitert und unterstützt jetzt das Caching dynamischen Webinhalts und die Assemblierung von Seitenfragmenten, die entsprechend dem Protokoll Edge Side Includes (ESI) geschrieben wurden.


Einzelhandelsnetz (Phase 3)

Anstatt SSI-Mechanismen (Server Side Includes) für die Erstellung von Webseiten auf den Inhaltsservern und die anschließende Weitergabe dieser clientspezifischen, nicht cachefähigen Seiten über das gesamte Netz zu verwenden, können Sie die ESI-Mechanismen verwenden, die Ihnen ermöglichen, Seiten aus zwischengespeichertem Inhalt am Rande des Netzes zu assemblieren und damit die Auslastung der Bandbreite zu reduzieren und die Antwortzeit zu verbessern.

ESI-Mechanismen sind in dieser dritten Phase entscheidend, in der jeder Client eine personalisierte Homepage von der Website empfängt. Die Bausteine dieser Seiten werden von einer Reihe von WebSphere Application Servern abgerufen. Anwendungsserver, die sensible Geschäftslogik und Bindungen zu sicheren Datenbank enthalten, sind hinter einer Firewall isoliert.

Banklösung für Einzelhandel

Dieses Szenario enthält Load Balancer und WebSphere Application Server Proxy.

Die folgende Abbildung zeigt eine effiziente Online-Banking-Lösung, die dem unter B2C-Netz beschriebenen B2C-Netz gleicht. Alle Clientanforderungen werden über die Firewall an einen Dispatcher übergeben, der den Datenverkehr auf der Basis des Internetprotokolls aufteilt. HTTP-Anforderungen werden an einen Cluster von Proxy-Servern mit aktiven Caches übergeben, die als Ersatzserver für die Webserver dienen. Für die Bereitstellung von Lastausgleichsdaten an den Dispatcher werden den Proxy-Servern Metric Server zur Seite gestellt. Diese Zusammenstellung verringert die Netzlast auf den Webservern und erstellt einen zusätzlichen Puffer zwischen ihnen und dem Internet.


Banklösung für den Einzelhandel

HTTPS-Anforderungen werden an ein sicheres Netz übergeben, das Clients persönliche Finanzinformationen bereitstellt und Online-Banking-Transaktionen ermöglicht. Ein Cluster erweiterter Proxy-Server unterstützt die Skalierbarkeit der Site. Diese Proxy-Server unterstützen das Caching dynamischen Webinhalts und die Assemblierung von Seitenfragmenten, die entsprechend dem Protokoll Edge Side Includes (ESI) geschrieben wurden. Eine Verschlüsselungshardwarekarte verwaltet SSL-Handshakes, was den erforderlichen Verarbeitungsaufwand des Proxy-Serverhosts erheblich reduziert. Access Manager (früher Policy Director) steuert die Clientauthentifizierung.

Eine Sammlung von Anwendungsserverclustern verteilt die Verarbeitung von Anforderungen, indem die Geschäftslogik, die in EJB-Komponenten enthalten ist, von dieser Präsentationsschicht, die in Servlets und JSP-Dateien enthalten ist, getrennt werden. Jeder dieser Cluster wird von einem anderen Sitzungsserver verwaltet.

Webportalnetz

Dieses Szenario enthält Load Balancer und WebSphere Application Server Proxy.

Die folgende Abbildung zeigt ein Webportalnetz, das für die Unterstützung eines hohen Datenverkehrsaufkommens konzipiert ist und jedem Client personalisierten Inhalt bereitstellt. Um die Verarbeitungslast der verschiedenen Server zu minimieren, wird kein SSL-Datenverkehr über das Netz übertragen. Da das Portal keine sensiblen Daten bereitstellt, ist die Sicherheit kein großes Problem. Es ist wichtig, dass die Datenbanken, die Client-IDs, Kennwörter und Einstellungen enthalten, eine angemessene Sicherheit bieten und unbeschädigt sind, aber die Anforderung hat keine Auswirkung auf die Leistung der restlichen Website.


Webportal

Alle Clientanforderungen werden über die Firewall an einen Dispatcher übergeben, der die Netzlast gleichmäßig auf einen Cluster von Proxy-Servern mit aktiven Caches verteilt, die als Ersatzserver für die Webserver dienen. Für die Bereitstellung von Lastausgleichsdaten an den Dispatcher werden den Proxy-Servern Metric Server zur Seite gestellt.

Die tatsächliche dynamische Website ist ein Cluster von Anwendungsservern, die ESI-Fragmente generieren, die zur Assemblierung an die Proxy-Server übergeben werden. Wegen der verminderten Sicherheitsbedenken führt jeder Anwendungsserver alle erforderlichen Funktionen für die Erstellung der Website aus. Alle Anwendungsserver sind identisch. Wenn ein Anwendungsserver außer Betrieb genommen wird, kann der Sitzungsserver Anforderungen an die anderen Server weiterleiten und damit die hohe Verfügbarkeit für die gesamte Site gewährleisten. Diese Konfiguration ermöglicht auch eine schnelle Eskalation der Website, wenn der Datenverkehr extrem ansteigt, z. B. beim Hosting eines speziellen Ereignisses durch das Portal. Zusätzliche Proxy-Server und Anwendungsserver können schnell in der Site konfiguriert werden.

Alle statischen Inhalte, wie z. B. Grafikdateien und Standardtexte, sind auf separaten Webservern gespeichert, wo sie bei Bedarf aktualisiert werden können, ohne eine Beschädigung der komplexeren Anwendungsserver zu riskieren.




Zugehörige Tasks
Load Balancer installieren
Konzept    

Nutzungsbedingungen | Feedback

Letzte Aktualisierung: 16. Mai 2008 1:45:54 PM EDT
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.lb70kf.doc/info/ae/covr_scenarios.html