Clustering in J2EE-Umgebungen

Transkript

1 Clustering in J2EE-Umgebungen Autor: Thomas Mattern Date: /24

2 Der Vortrag diskutiert mögliche Ansätze für das Clustering J2EE basierter Anwendungen. Wie muss ein clusterfähiger Applikationsserver aufgebaut sein? Welche Funktionalitäten sind erforderlich? Dabei wird detailliert auf die Cluster Architektur führender Applikationsserver Hersteller eingegangen. Weiterhin werden Herausforderungen an Anwendungsdesigner und Administratoren bei der Verwaltung einer Clusterlösung dargestellt und anhand eines Beispiels erläutert. Autor Dipl. Ing. Thomas Mattern Thomas Mattern works as Product Marketing Manager at In-Q-My Technologies GmbH, a German based J2EE application server vendor and 100% subsidiary of SAP AG. He has long-standing experience in distributed software architectures and enterprise application development. Prior to joining In-Q-My, Thomas held consulting and technical account management positions at Compuware Corp. and Forté Software Inc. He has been a frequent speaker at conferences and author of various technical articles about middleware technology, EAI and OO development. 2/24

3 Clustering in J2EE-Umgebungen 1 Einleitung 4 Cluster Definition und Backround 4 Cluster-Arten 6 Cluster-Implementierung 7 Cluster und Failover-Dienste 10 HTTPSession-Failover 11 Single Point Of Failure 12 Cluster-Topologie 12 Wartung und Administration 13 BEA WebLogic HP Bluestone Total e-server Sybase Enterprise Application Server Silverstream Application Server SAP Web Application Server Setup und Verwaltung von Clustern 19 Applikationsserver Verteilung 21 Konfigurationsbeispiel mit dem Sybase Enterprise Application Server 22 JSR 117 J2EE APIs for Continuous Availability 23 Quellen 24 3/24

4 Einleitung Enterprise Anwendungen werden heutzutage in Java entwickelt. Der dabei favorisierte Standard ist die Java 2 Enterprise Edition (J2EE). Innerhalb des J2EE Frameworks stellen Cluster-Technologien im Wesentlichen zwei Funktionen zur Verfügung: 1. Hohe Verfügbarkeit des Systems. 2. Maximale Performance für den Benutzer. In der Anforderung, diese beiden Bedingungen so optimal wie möglich zu erfüllen, liegt genau die Herausforderung beim Aufsetzen von Server-Clustern. Um eine möglichst hohe Verfügbarkeit des Systems zu erreichen, müssen Komponenten repliziert werden, was wiederum zur Folge hat, dass die Performance des Systems negativ beeinflusst wird. Um dieses Dilemma zu umgehen, gibt es keine allgemeingültige Regel, die besagt welches die beste Cluster-Architektur ist. Vielmehr richtet sich die Auswahl nach den individuellen Anforderungen des Systems. In der J2EE Spezifikation ist zum heutigen Zeitpunkt keine Cluster-Architektur standardisiert. Dies hat dazu geführt, dass jeder J2EE Applikationsserver-Hersteller ein eigenes Cluster-Konzept entwickelt hat. Im Folgenden werden die wichtigsten Clusters-Funktionalitäten anhand gängiger Cluster- Modelle erläutern und miteinander verglichen. Speziell sollen dabei die Merkmale, die ein clusterfähiger Applikationsserver benötigt, betrachtet werden. Anhand der Cluster- Implementierungen unterschiedliche Hersteller werden diese Funktionen dann diskutiert. Abschließend wird auf die unterschiedlichen Aspekte der Cluster-Konfiguration eingegangen. Cluster Definition und Backround Der Cluster-Gedanke ist keinesfalls neu. Schon in den achtziger Jahren bot DEC ihren Kunden VAX Cluster an, die eine einfach zu verwaltende und erweiterbare Rechnerleistung zur Verfügung stellten. Hersteller von J2EE Applikationsservern definieren ein Cluster als eine Gruppe von Maschinen, die transparent für den Benutzer Dienste zur Verfügung stellen. Das bedeutet beispielsweise Unterstützung für JNDI (Java Naming & Directory Interface), EJB (Enterprise Java Beans), JSP (Java Server Pages), HTTPSessions und Komponenten- Failover. Die Definition ist absichtlich etwas vage formuliert, da jeder Hersteller sein Cluster anders implementiert. Auf der einen Seite gibt es Produkte, die einen Dispatcher für die Verteilung der Anfragen auf die einzelnen Maschinen vorgeschaltet haben. Hier kennen sich die Maschinen im Cluster untereinander nicht, was dazu führt, dass die Verteilung der Anfragen sessionabhängig ist: der Dispatcher erhält die Anfrage eines Benutzers und bindet diesen an einen Server des Clusters. Auf der anderen Seite gibt es Hersteller, die mit ihrem Cluster einen Zusammenschluss von sehr eng gekoppelten Maschinen unterstützen, in der jede Maschine jeweils die anderen, einschließlich der Objekte, die auf der Maschine laufen, kennt (Bild 1). Bild 1: Cluster mit Dispatcher Architektur 4/24

5 Innerhalb eines Clusters gibt es neben den Servern noch weitere Architektur-Komponenten, die teilweise erforderlich und teilweise optional sind. Hardware Load Balancer Lenken als Single Point of Entry die Anfragen an einen individuellen Web- oder Applikationsserver Web Server Gateway Routers Fungieren als Ausgang aus einem internen Netzwerk Multilayer Switches Arbeiten als Filter um sicherzustellen, dass jede Maschine im Cluster nur die Informationen erhält, die benötigt werden Firewalls Sichern das Cluster durch das Filtern von Port-Level Informationen vor Hackerangriffen ab SAN (Storage Area Networking) Switches Verbinden den WebServer, Applikationsserver und die Datenbank mit einem Backend Speichermedium Datenbanken Skalierbarkeit Skalierbarkeit bezieht sich auf die Unterstützung einer beliebigen Anzahl von Benutzern. D.h., wenn die Benutzerzahl ansteigt, muss der Administrator in der Lage sein, weitere Server in das Cluster aufzunehmen. Voraussetzung dafür ist die Möglichkeit, im Cluster die Last auf mehrere Server zu verteilen. Man unterscheidet zwei Arten von Lastverteilung in einem Cluster: 1. Softwarebasierende Lastverteilung 2. Hardwarebasierende Lastverteilung Obwohl softwarebasierte Lastverteilung meist die kostengünstigere Alternative, ist birgt sie auch einige Nachteile: Zusätzliche Software auf dem Server reduziert die System-Resourcen und trägt nicht unbedingt zur Server-Stabilität bei. Für eine Alive-Statusprüfung benutzen die meisten Hersteller ping aus dem Internet Control Message Protocol (ICMP). Ping testet aber nur die Server/Netzverbindung, nicht aber die einzelnen Dienste und Funktionen auf dem Server. Lastverteilungssoftware arbeit häufig nur auf der Basis von Round-Robin Mechanismen. Dabei wird jedem Server der Reihe nach eine Anfrage zugeteilt. Die tatsächliche Auslastung des jeweiligen Systems wird dabei nicht berücksichtigt. Lastverteilungssoftware erfordert Administrationsaufwand. Mit jedem neuen Knoten muss auch die Software installiert werden. Bei Hardwarelösungen wird zwischen Anwendern und Servercluster ein dediziertes Gerät eingesetzt. Vorteilhaft ist, dass die Server ohne zusätzliche Software auskommen und absolute Betriebsystem-Unabhängigkeit gewährleistet ist. Die Administration ist bei hardwarebasierter Lastverteilung wesentlich einfacher. Bei Server-Upgrades oder Systemwartung kann ein Server-Shutdown kontrolliert stattfinden, um Serviceunterbrechungen zu vermeiden. Nachteil hardwarebasierter Clusterlösungen sind die damit verbundenen hohen Kosten. Hohe Verfügbarkeit Hohe Verfügbarkeit wird erreicht, indem Komponenten redundant gehalten werden. Das Cluster benutzt viele Maschinen, um die Anfragen zu verarbeiten. Wenn eine davon ausfällt, muss sichergestellt sein, dass eine andere Maschine transparent die Aufgaben übernimmt. Die Kosten für Rechnerausfälle sind bei bestimmten Anwendungen extrem hoch. Bei einem Cluster spricht man von der Gesamtverfügbarkeit, die typischerweise in der Anzahl der Neunen angegeben wird. Ein einzelner Unix oder Windows-Server liegt in Klasse 2. Professionell gemanagte Einzel-Server, normale Windows- und Unix-Cluster in Klasse 3. 5/24

6 Klasse 4 beinhaltet High-End-Unix Systeme und Mainframes. 99,999 % Verfügbarkeit erreicht man recht selten. Hier kommen z.b. IBM Parallel Sysplex Cluster zum Einsatz. Häufig bringt ein Cluster die Verfügbarkeit nur auf Applikationserver-Ebene mit, da ein ausfallsicheres Cluster ansonsten alle anderen Komponenten wie WebServer, Gateway Router, Switching Infrastruktur etc. ebenfalls mindestens zweimal vorhalten müsste. Die Analysten von IDC definieren Hochverfügbarkeit auf unterschiedlichen Ebenen. IDC unterscheidet vier Availability Levels AL4, AL3, AL2 und AL1. AL4 als höchste Stufe steht für Verfügbarkeit bis zum Endgerät, was die redundante Auslegung aller Komponenten beinhaltet. Bei AL3 bleibt der Benutzer aufgrund der durchgehenden Redundanz ebenfalls online, allerdings mit der Einschränkung, durch die Umschaltung Leistungseinbussen hinnehmen zu müssen. Denn in diesem Fall wird toleriert, dass einzelne Transaktionen unterbrochen und neu aufgesetzt werden. Im AL2 wird, trotz durchgehender Komponentenund Funktionsredundanz im Fehlerfall, ein Abbruch des gesamten Geschäftsprozesses toleriert, gefolgt von einer Neuanmeldung des Benutzers am System und einem erneuten Start aller Transaktionen. Bei der niedrigsten Stufe AL1darf ein unkontrollierter Stopp vorkommen. Die Verfügbarkeit bezieht sich in AL1 nur auf die Datenintegrität. Cluster-Arten Ein J2EE Cluster gibt es normalerweise in zwei Ausprägungen: Shared nothing Shared disk In einem Shared nothing-cluster hat jeder Applikationsserver sein eigenes Filesystem, mit eigenen Kopien der Anwendungen, die im Cluster laufen (Bild 2). Anwendungs-Updates und Erweiterungen erfordern eine Anpassung in jedem Knoten des Clusters. Unschwer vorzustellen, dass die Verwaltung eines Shared nothing-clusters dadurch mit hohen Aufwänden verbunden ist. Bild 2: Shared nothing Cluster Im Gegensatz dazu, greifen in einem Shared disk-cluster alle Applikationsserver auf einen gemeinsamen Speicher zu (Bild 3). Updates und Erweiterungen finden hier nur an einer Stelle statt und alle Maschinen im Cluster können auf die Änderungen zugreifen. Der große Nachteil eins Shared disk-clusters liegt im auftretenden Single Point Of Failure. Eine Möglichkeit, diesen zu Umgehen, ist der Einsatz eines SANs. 6/24

7 Bild 3: Shared Disk Cluster Cluster und Storage Area Networks SANs finden seit einiger Zeit immer häufiger Verbreitung in der Netzwerktechnologie. Sie verbinden die Server mit einem Speichermedium mit einer sehr hohen Geschwindigkeit im Gigabaud-Bereich. Hauptgrund, ein SAN einzuführen ist eigentlich der steigende Bedarf an Speicherplatz. SANs bieten darüber hinaus eine deutlich bessere Performance und Skalierbarkeit als herkömmliche Speicherstrategien, einen zuverlässigeren Schutz der Daten und niedrige Administrationskosten. Generell bestehen immer zwei Möglichkeiten den Speicherbedarf zu erhöhen es werden mehr Server angeschafft, die den Administrationsaufwand und die Kosten erhöhen effektiver ist die Implementierung eines SAN, da die Speicherkapazität bei steigenden Anforderungen mitwachsen kann und Kosten durch die zentrale Verwaltung sinken. Beim SAN sind die Speichersubsysteme im einem eigenständigen Netzwerk untergebracht. Zentrale Schaltstelle im SAN ist ein Switch oder ein Hub, der Datenanfragen und die Ergebnisse weiterreicht. Ein Hub folgt dem Verbindungsschema eines geschlossenen Kreislaufes, wobei die vorhandene Bandbreite zwischen den verbundenen Geräten geteilt wird. Dagegen bietet der Switch eine Punkt-zu-Punkt Verbindung mit garantierten Übertragungsvolumen (idr 100Mbyte/Sek.). Der SAN-Switch kennt und verwaltet dabei das Speichermedium, auf das die Daten geschrieben werden. Um Ausfallsicherheit zu erreichen, sind SANs mit gespiegelten Platten verbunden. Wenn ein Speichersystem ausfällt, übernimmt das Backup transparent für den Client den weiteren Betrieb. Der Einsatz eines SANs scheitert in der Praxis häufig an den damit verbundenen Kosten, da es nicht selten vorkommt, dass ein SAN fast so teuer wie das Cluster selbst ist. Cluster-Implementierung Werden unterschiedliche J2EE Cluster-Konzepte verglichen, ist es wichtig, folgende Punkte zu betrachten: Cluster-Implementierung Dienste für Cluster und Komponenten Ausfallsicherheit HTTPSession-Ausfallsicherheit Single Points Of Failure Cluster-Topology Wartbarkeit des Clusters Ein J2EE basierter Applikationsserver implementiert Clustering um seine JNDI- Implementierung. JNDI ermöglicht, in Java geschriebenen Anwendungen, eine einheitliche Schnittstelle zu Namens- und Verzeichnisdiensten. In Kombination mit einem Applikationsserver organisiert und lokalisiert JNDI die Komponenten in einer verteilten Umgebung. Obwohl JNDI einer der Basisdienste von J2EE basierten Applikationsservern ist, 7/24

8 gestaltet sich die JNDI Implementierung innerhalb eines Clusters als schwierig, da es nicht möglich ist, verschiedene Objekte unter einem Namen zu verbinden. In Abhängigkeit der JNDI-Implementierung des jeweiligen Applikationsservers existieren drei generelle Clustering Methoden. Unabhängiger JNDI-Baum Zentraler JNDI-Baum Shared global JNDI-Baum Java Naming & Directory Interface Generell betrachtet, kann ein Namens-Dienst mit einem Katalog verglichen werden, der das Auffinden eines Objektes wesentlich erleichtert. Neben der Assoziation mit der Lokation des jeweiligen Dienstes enthält der Naming Service (NS) noch weitere Informationen. Dem Programmierer nimmt der NS die Notwendigkeit ab, die Lokation im Code zu hinterlegen. JNDI bietet dabei eine standardisierte Schnittstelle zu existierenden Namens-Diensten. Der NS verwaltet ein Set von sogenannten Bindings (Bild 4). Alle Objekte im NS sind nach demselben System benannt und bei derselben Naming-Convention angemeldet. Bild 4: Naming Service Es gibt eine ganze Reihe unterschiedlicher Namensdienste, die alle derselben Definition folgen, in ihren Ausprägungen aber unterschiedlich sind. COS (Common Object Services) Naming NS für CORBA-Anwendungen, ermöglicht Anwendungen die Speicherung und den Zugriff auf CORBA-Objekte. DNS (Domain Name Service) Internet NS, mappt die Web Adresse ( ) auf die IP-Adresse ( ). DNS ist ein verteilter NS, was bedeutet, dass der Service und seine grundeliegende Datenhaltung über mehrere Server verteilt ist. LDAP (Lightweight Directory Access Protocol) Entwickelt von der Universität Michigan ist LDAP eine einfachere Version von DAP (Directory Access Protocol) und Teil des X.500 Standards für Directory Services. NIS (Network Information System) Von Sun entwickelter Netzwerk NS, der den Benutzern erlaubt, auf Dateien und Anwendungen eines beliebigen Host mit einer ID und Password zuzugreifen. Wie oben erwähnt, ist JNDI ein Interface zu verschieden NS und keine eigene NS- Implementierung. Dies setzt beim Umgang mit JNDI voraus, dass der Zugriff auf einen NS vorhanden ist und JNDI erlaubt, sich nahtlos in die bestehende Umgebung zu integrieren. Unabhängiger JNDI-Baum Server, die in einem unabhängigen JNDI-Baum Cluster registriert sind, kennen die anderen Server des Clusters nicht. Failover ist in einer solchen Cluster-Implementierung entweder nicht unterstützt oder über sogenannte Vermittlerdienste gelöst. Diese Vermittlerdienste sind so konfiguriert, dass sie wissen, wo jede Komponente sich im Cluster befindet und wie man eine alternative Komponente im Falle eines Fehlers erhält. Der große Vorteil eines unabhängigen JNDI-Baum-Clusters ist eine sehr kurze Cluster-Konvergenz und eine einfache Skalierbarkeit. Unter Cluster-Konvergenz versteht man die Zeit, die vom Cluster 8/24

9 benötigt wird alle Maschinen und ihre assoziierten Objekte im Cluster zu erkennen. Cluster- Konvergenz ist kein Hindernis in einem unabhängigen JNDI-Baum Cluster, da die Konvergenz erreicht wird, sobald zwei Maschinen gestartet sind. Ein weiterer Vorteil dieser Cluster-Art ist die einfache Skalierbarkeit: Skalierbarkeit bedeutet hier nur das Hinzufügen eines weiteren Servers. Es existieren natürlich auch Nachteile in einem unabhängigen JNDI- Baum-Cluster. Ausfallsicherheit liegt hier in der Verantwortung des Entwicklers, der Ausfall- Scenarien mühevoll von Hand implementieren muss, da durch den unabhängigen JNDI- Baum der Remote-Proxy, der über JNDI gelesen wird, immer an den Server gebunden ist, auf dem die Anfrage gestartet wurde. Wenn die Methode einer EJB fehlschlägt, muss der Entwickler extra Code schreiben, um sich zum Dispatcher zu verbinden, die Adresse eines alternativen Servers zu erfragen, einen weiteren JNDI Lookup zu starten und die fehlgeschlagene Methode erneut aufzurufen. Von den Applikationsserver-Herstellern nutzen HP Bluestone und Silverstream einen unabhängigen JNDI Baum. Wobei Bluestone eine kompliziertere Form des unabhängigen JNDI-Baums implementiert hat, in der jede Anfrage an einen EJB-Proxy-Dienst oder an eine Proxy-Load-Balancing Broker (LBB) geht. Der EJB Proxy-Dienst stellt sicher, dass jede EJB Anfrage an eine aktive Server-Instanz geht. Diese Vorgehensweise erhöht die Wartezeit auf die Antwort, erlaubt aber so ein automatisches Failover zwischen den Methodenaufrufen. Zentraler JNDI-Baum In dieser Konfiguration benutzt das zentralisierte JNDI-Baum-Cluster CORBAs CosNaming- Service für JNDI. Ein Name Server kennt den zentralisierten JNDI Baum für das Cluster und weiß, welche Server im Cluster aktiv sind. Zum Zeitpunkt des Server-Starts verbindet jeder Server im Cluster seine Objekte in den JNDI-Baum. Die Name Server melden sich ebenfalls dort an. Um in einem zentralisierten JNDI-Baum-Cluster eine Referenz auf eine EJB zu bekommen sind zwei Schritte notwendig. Erstens sucht der Client nach einem Home-Objekt von einem Name-Server, das eine IOR (Interoperable Object Reference) zurückgibt. Eine IOR ist ein String, der Informationen enthält, die eine Objekt-Instanz eindeutig identifizieren können. Zweitens wählt der Client den ersten Server im IOR-String aus und erhält so das Home- und Remote-Interface. Tritt ein Fehler zwischen den EJB Methodenaufrufen auf, sorgt der CORBA-Stub dafür, dass ein anderes Home- oder Remote-Interface das im IOR gelistet ist, aufzurufen. Der Name Server an sich stellt eine Schwachstelle des zentralen JNDI-Baum-Clusters dar. In einem Cluster von beispielsweise 50 Servern, von denen 5 als Name Server dienen, ist Ausfallsicherheit nur solange gewährleistet, wie die 5 Name-Server laufen. Sind die 5 Name Server nicht aktiv, kann auch auf den übrigen 45 Maschinen nicht mehr gearbeitet werden. Ein weiteres Problem tritt auf, wenn aufgrund eines Fehlers ein weiterer Name-Server zur Laufzeit in das Cluster gebracht wird, der den eigentlichen Name-Server ersetzen soll. In diesem Fall benötigt der neue Name-Server die Daten jeder aktiven Maschine, um ihre Objektinformationen in den neuen zentralen JNDI-Baum aufzunehmen. Obwohl es möglich ist, weitere Anfragen auf einen Server abzusetzen, während der Binding-Prozess im Gange ist, ist dies nicht empfohlen, da der Binding-Prozess die Wiederherstellungszeit des Clusters nachteilig beeinflusst. Weiterhin werden für jeden JNDI-Aufruf von einem Applet oder einer Applikation nach wie vor zwei Netzwerkaufrufe abgesetzt. Der erste Aufruf erhält die IOR für ein Objekt vom Name-Server und der zweite Aufruf liest das vom Client benötigte Objekt, was in der IOR spezifiziert ist. Der größte Nachteil bei einem zentralisierten JNDI-Baum-Cluster ist die erhöhte Konvergenzzeit: je größer das Cluster wird, umso mehr Name-Server werden benötigt. Generell gilt, dass das Verhältnis von Name-Server zu Summe aller Cluster-Maschinen 1:10 sein sollte mit einem Minimum von zwei Name-Servern. Von daher werden in einem Cluster mit 10 Servern und zwei Name-Servern in Summe 20 Verbindungen zwischen Server und Name Server benötigt. In einem 40 Maschinen-Cluster mit 4 Name Servern sind das schon 160. Jede Verbindung repräsentiert dabei einen Prozess, in dem ein Server alle seine Objekte mit dem JNDI-Baum eines Name Servers verbindet. Von daher kann man 9/24

10 sagen, dass das zentrale JNDI-Baum-Cluster die schlechteste Konvergenzzeit der vorgestellten Cluster-Implementierungen hat. Der Sybase Enterprise Application Server implementiert ein zentrales JNDI-Baum-Cluster. Shared Global JNDI-Baum Beim shared global-ansatz macht sich ein Server zur Startup-Zeit bei den anderen Servern im Cluster bekannt, indem er seinen JNDI-Baum über IP Multicast überträgt. IP-Multicast ist eine einfache Broadcasting-Technologie, die unterschiedlichen Anwendungen ermöglicht, sich zu einer vorgegeben IP-Multicast Adresse und Port Nummer zu subscriben und dann Nachrichten entgegen zu nehmen. Jede Maschine im Cluster verbindet seine Objekte mit dem Shared global JNDI-Baum ebenso, wie mit seinem lokalen JNDI-Baum. Durch die Kombination eines globalen und lokalen JNDI Baums in jedem Server erreicht man Failover und ein relativ schnelles JNDI-Lookup-Verhalten für Home- und Remote-Stubs. Da der shared global JNDI-Baum allen Maschinen im Cluster bekannt ist, kennt jede Maschine die Lokation jedes Objekts im Cluster. Ist ein Objekt auf mehr als einem Server im Cluster verfügbar, wird ein spezielles Home Objekt im shared global JNDI-Baum eingebunden. Dieses spezielle Home Objekt kennt wiederum die Lokation aller EJB-Objekte, mit denen es in Verbindung steht und generiert Remote-Objekte, die ebenfalls die Lokation aller damit assoziierten Objekte kennt. Die große Schwachstelle eines shared global-clusters ist die hohe Netzwerkbelastung, die beim Hochfahren der Server entsteht und die damit verbundene längere Konvergenzzeit. In einem shared global-cluster, das IP-Multicast für den Transfer der JNDI-Informationen benutzt, ist die benötigte Zeit für den Aufbau des shared global JNDI-Baums linear in Relation zu der Anzahl der eingebunden Server. Der Vorteil eines shared global Clusters gegenüber eines zentralisierten JNDI Baums liegt in der einfacheren Skalierbarkeit sowie der höheren Verfügbarkeit. Beim shared global Cluster braucht der Entwickler/Administrator nicht mit CPUs oder RAM auf einem speziellen Name- Server hantieren oder Cluster-Tuning über die Name Server betreiben. Bevor man die Anwendung individuell skalieren muss, reicht es in einem shared global-cluster aus, einfach eine weitere Maschine hinzuzufügen. Die Netzwerkbelastung ist in einem shared global Cluster ebenfalls geringer, als in einem zentralen Cluster, da jeder entfernte Lookup nur einen Netzwerkaufruf benötigt, anstatt zwei, wie im zentralen JNDI-Baum-Cluster. Cluster und Failover-Dienste J2EE Dienste auf einer einzelnen Maschine zur Verfügung zu stellen, ist relativ einfach, verglichen dazu, dieselben Dienste in einem Cluster zu verteilen. Aufgrund der angesprochenen Schwierigkeiten beim Clustering, hat jeder Applikationsserver-Hersteller seine eigene Clusterimplementierung. Bevor man sich für eine Cluster-Architektur bzw. einen Hersteller entscheidet, sollte man die unterschiedlichen Implementierungsarten genau betrachten und verstehen, wie die Hersteller Ausfallsicherheit für Entity Beans, Stateless und Stateful Session Beans oder JMS implementieren. Viele Hersteller geben an, geclusterte Komponenten zu unterstützen, aber die Art der Unterstützung wird sehr offen ausgelegt und es wird nicht individuell auf einzelne Komponetenarten und damit verbundene Herausforderungen an Clustering eingegangen. Was bedeutet, dass Lastverteilungsmechanismen beispielsweise berücksichtigt werden, Ausfallszenarien jedoch nicht oder nur begrenzt. Zum Beispiel unterstütz BEA WL 5.1 geclusterte Stateful Session Beans, aber wenn der Server, auf dem die Bean Instanz lebt, ausfällt, geht der gesamte Status der Bean verloren. Der Client muss in diesem Fall die Bean komplett neu erzeugen und im Cluster bekannt machen, was nicht ohne weiteres funktioniert. Mit BEA WL 6.0 ist Clustering auch für Stateful Session Beans durch in-memory Replikation für Failover möglich. 10/24

11 Nahezu alle Applikationsserver unterstützen geclusterte EJBs, aber variieren stark in ihrer Unterstützung für automatisches Failover. Einige Applikationsserver unterstützen Failover nur in bestimmten Fällen. Zum Beispiel unterstützt der Sybase Enterprise Application Server Failover für Stateful Session Beans für den Fall, dass der Status der Bean von einer Datenbank oder über Serialisierung geladen wird. Die meisten Applikationsserver unterstützen JMS auch im Clusterbetrieb, bieten jedoch keine Unterstützung für Lastverteilung oder Ausfallsicherheit von individuellen Topics und Queues. Für einen solchen Fall muss dann auf eine spezielle Cluster-Implementierung für JMS, z.b. Sonic MQ, zurückgegriffen werden, die Lastverteilung für Topics und Queues unterstützt. HTTPSession-Failover HTTPSession-Failover ermöglicht einem Client, Session-Informationen eines anderen Servers im Cluster zu erhalten, wenn seine eigene Session fehlschlägt. Ein solcher Session State kann z.b. der Inhalt eines Warenkorbs in einer Shop-Anwendung sein. HTTPSession- Failover ist damit in Web-Anwendungen eine elementare Grundlage für sessionbasierte Ausfallsicherheit. Hier gibt es auch wieder zwei verschiedene Ansätze, um HTTPSession- Failover zu erreichen: In-Memory Replikation der Session Informationen zentraler Session Server mit einem Backup für Hochverfügbarkeit BEA WL hat In-Memory Session Failover implementiert, wogegen HP Bluestone auf einen zentralen Session Speicher zugreift. Silverstream Application Server und Sybase EA benutzen eine zentrale Datenbank oder Filesystem, auf das alle Applikationsserver im Cluster lesend und schreibend zugreifen können. Der größte Nachteil bei Datenbank/Filesystem basierter Session Persistenz ist die limitierte Skalierbarkeit, wenn eine große Anzahl Objekte in den HTTPSession-Informationen gespeichert sind. Dies liegt darin begründet, dass jedes mal, wenn ein Benutzer ein neues Objekt zu der HTTPSession hinzufügt, alle Objekte in der Session serialisiert und in die Datenbank/Filesystem geschrieben werden. Die meisten Applikationsserver, die mit Datenbank Session-Persistenz arbeiten, versuchen den HTTPSession-Store möglichst wenig zu benutzen, um Objekte zu speichern. Dies wiederum limitiert die Flexibilität der Web-Anwendung und des Designs, besonders wenn der HTTPSession-Speicher dazu benutzt wird, Benutzerdaten zu cachen. Bei der speicherbasierten Session-Persistenz werden die Session-Informationen im Speicher eines Backup Servers gehalten. Hier unterscheidet man wiederum zwei Methoden der in- Memory Speicherung. Im ersten Fall werden die HTTPSession-Informationen auf einen zentralen Server zur Statusverwaltung geschrieben. Im zweiten Fall kann jeder Knoten im Cluster einen beliebigen Backup-Knoten auswählen, um Session Informationen In-Memory zu speichern. Jedes mal, wenn ein Benutzer der HTTPSession ein Objekt hinzufügt, wird nur dieses eine Objekt serialisiert und im Speicher des Backup Servers vorgehalten. Welche der beiden Methoden man den Vorzug gibt, hängt wiederum ganz vom Aufbau des jeweiligen Clusters ab. Ist die Anzahl der Server im Cluster gering, empfiehlt es sich, mit einem zentralen Server zur Session State Speicherung zu arbeiten. Die In-Memory Methode hat hier eine höhere CPU Auslastung bei der Transaktionsverarbeitung und der dynamischen Seitengenerierung. Ist die Anzahl der Knoten im Cluster jedoch hoch, wird ein zentraler Session-Server sehr schnell zum Flaschenhals, da die interne Verwaltungskommunikation extrem hoch wird. In-Memory Replikation auf einem beliebigen Backup Server skaliert dagegen linearer, wenn weitere Server hinzukommen. Weiterhin ist es erforderlich, bei steigender Anzahl von Servern im Cluster einen zentralen Session-State Server permanent anzupassen und mehr RAM und weitere CPUs hinzuzufügen. Wogegen bei der In-Memory Replikation auf einem beliebigen Server-Knoten einfach weitere Maschinen ins Cluster gehangen werden und die Session-Informationen sich automatisch auf allen Servern im Cluster verteilen. Abschließend ist zu sagen, dass In-Memory basierte Session-Persistenz ein weitaus flexibleres Anwendungsdesign, höhere Skalierbarkeit und Ausfallsicherheit mitbringt. 11/24

12 HTTPSession-Failover und Stateful Session Beans Im Wesentlichen treffen die für die HTTPSession beschriebenen Kriterien auch für Stateful Session Beans zu. In einigen Anwendungsfällen, z.b. wenn eine bestimmte Datengröße überschritten wird, kann es sinnvoll sein, einen Teil der Daten in eine Stateful Session Bean auszulagern. Dabei werden die für den Failover-Fall notwendigen Daten in der HTTPSession mitgeführt und repliziert, wogegen der Rest der Daten in einer nicht replizierten Stateful Session Bean gespeichert wird. Ein Handle, der die Lokation der HTTPSession- Informationen und der Stateful Session Bean kennt wird dabei in der HTTPSession gespeichert. Bezieht man diese Vorgehensweise auf eine mehrschichtige Architektur, kann man beispielsweise die Präsentationsschicht relevanten Daten, in der HTTPSession halten. Daten die nur für die interne Kommunikation mit den Business Objekten benötigt werden, können in der Stateful Session Bean verbleiben. Single Point Of Failure Gibt es von einem Dienst innerhalb eines Clusters kein Backup, so bezeichnet man dies als Single Point Of Failure (SPOF). Bei einem SPOF läuft man immer Gefahr, dass das gesamte Cluster oder Teile der Applikation nicht mehr funktionieren. Zum Beispiel unterstützt BEA WL bei JMS nur die Möglichkeit, ein Topic auf einer Maschine im Cluster laufen zu lassen. Wird das JMS Topic von der Anwendung zwingend benötigt, ist das Cluster bei einem Ausfall solange nicht verfügbar, bis eine andere Server-Instanz mit diesem JMS Topic gestartet ist. Von daher kann die Überprüfung des Clusters auf SPOFs sehr relevant bei der Auswahl des Applikationsservers, bzw. der Cluster-Technologie sein. Cluster-Topologie Eine wesentliche Fragestellung beim Konzipieren eines unternehmensweiten Clusters ist die Anordnung der einzelnen Cluster-Komponenten, die sogenannte Cluster-Toplogoie. Hier möchte man selbstverständlich die maximale Flexibilität beim Aufbau haben. Die meisten Applikationsserver können ebenso als WebServer eingesetzt werden, was speziell bei der Benutzung von dynamischen Inhalten Vorteile bringt (Bild 5). Bild 5: Applikationsserver ist gleichzeitig Web Server Applikationsserver bieten PlugIns für gängige WebServer wie Appache oder Microsoft IIS. Ob man jetzt einen separaten WebServer oder die Web Services des Applikationsservers einsetzt, richtet sich im Wesentlichen danach, wie das Verhältnis von statischen Web-Seiten zu dynamisch erzeugten Seiten ist. Enthält eine Site hauptsächlich statische Inhalte, so ist es vom Aufwand und den Lizenzkosten her angebracht, einen externen WebServer zu benutzen. Um die dynamischen Inhalte skalierbar zu machen, bietet es sich an, direkt die Web-Dienste des Applikationsserver zu benutzen (Bild 6). 12/24

13 Bild 6: Applikationsserver und Web Server getrennt Ein Nachteil der Architektur in Bild 6 ist allerdings die erhöhte Wartezeit bei dynamischen Seitenanfragen, da die generierte Page zuerst an den externen WebServer übermittelt werden muss, bevor sie an den Client gesendet wird. Dafür ist aber in jedem Fall die maximale Flexibilität für die Cluster-Topologie gegeben. Wartung und Administration Das Thema Wartung und Administration wird in diesem Vortrag nicht vollständig behandelt. Jeder Applikationsserver bietet in der Regel eine umfangreiche grafische Administrationskonsole an. Da hier schwerpunktmäßig auf die Wartung des Clustersverbundes eingegangen wird, kann es sein, dass ein Applikationsserver im Bereich der generellen Server Verwaltung hervorragende Möglichkeiten bietet, in der Clusterwartung jedoch Lücken aufweist. Bei der Wartung eines Clusters geht es im Wesentlichen darum, das Cluster am Laufen zu halten und Änderungen/Updates einzuspielen. Von daher sollte ein Applikationsserver Agententechnologie unterstützen, die beispielsweise kritische Dienste im Falle eines Fehler automatisch neu startet oder auf einem Backup-Server aktiviert. Im Updatefall sollte der Applikationsserver eine einfache Möglichkeit bieten, alle Server im Cluster auf den neusten Stand zu bringen und zu synchronisieren. Der Sybase EA und HP Bluestone unterstützen File- und Konfigurations-Synchronisation für Cluster. Sybase unterstützt diese auf Host, Gruppen oder Cluster-Level, Bluestone nur auf Host-Level. Bei großen Anwendungen und vielen Änderungen dauert der Deployment- Prozess bei File- und Konfigurations-Synchronisation relativ lange. BEA WL unterstützt nur Konfiguration Synchronisation. Von den beiden Möglichkeiten ist die Konfigurations- Synchronisation mit einem Storage Area Network besser, da Änderungen nur in einem logischen Speichermedium vorgenommen werden und alle Maschinen im Cluster die Änderungen von einem zentralen Konfigurationsserver erhalten. Der Silverstream Applikationsserver benutzt einen dynamic Class Loader, der zur Laufzeit Anwendungsdateien aus einer Datenbank lädt. Im Folgenden soll betrachtet werden, wie die einzelnen Applikationsserver sich in den zuvor diskutierten Features verhalten. BEA WebLogic 6.0 Cluster-Implementierung WL basiert auf einer shared global JNDI-Baum Implementierung. Jeder Server meldet sich beim Start automatisch beim globalen JNDI-Baum an bindet seinen lokalen JNDI-Baum an den globalen. Für die Anfragebearbeitung benutzt der Server eine lokale Kopie des zentralen Baums, um die Lokation aller Objekte im Cluster festzustellen. BEA benutzt für komponentenbasierte Lastverteilung sog. WebLogic Smart Stubs, die den Standard EJB 13/24

14 Stub ersetzen und den Aufruf der Bean übernehmen. Die Stubs beinhalten Informationen über das Cluster. Handelt es sich um einen entfernten Aufruf, bekommt der Client eine Liste aller verfügbaren Komponenten eines Typs vom Name Service und benutzt dann einen ausgewählten Lastverteilungsmechanismus (Round Robin, Random oder gewichtetes Round Robin), um eine Komponente auszuwählen. Nur wenn eine Komponente nicht mehr zur Verfügung steht, wählt der Smart Stub eine andere Instanz aus. Ein Alleinstellungsmerkmal des WL Server ist die In-Memory Replikation von Stateful Session Beans sowie automatisches Failover für EJB Remote Objekte. BEA bezeichnet Komponenten als clusterfähig, wenn sie als Service im Cluster laufen. Von daher ist BEAs JMS clusterfähig, allerdings läuft jedes Topic und jede Queue nur auf einem single Server im Cluster. Dies bedeutet, dass es keine Lastverteilung und keine Ausfallsicherheit für JMS Topics und Queues gibt ein wesentlicher Schwachpunkt ist BEAs JMS Implementierung. HTTPSession-Failover BEA unterstützt HTTPSession-Failover durch transparente In-Memory state Replikation auf einen beliebigen Backup oder Datenbank-Server. Jede Maschine im Cluster sucht sich einen anderen Backup-Server. Fällt der Primary-Server aus, wird der Backup automatisch zum Primary und wählt einen neuen Backup Server. Dem Nachteil des bereits erwähnten internen Kommunikations-Overhead bei der Replikation begegnet BEA mit der Empfehlung, dass die Datenmenge in einer HTTP-Session nicht mehr als 50 KB überschreiten sollte. Ein Alleinstellungsmerkmal von BEA ist die Cookie-Unabhängigkeit. HP und Sybase benötigen Cookies für HTTPSession-Failover. WL kann im Fehlerfall encryptete Informationen in der URL benutzen, um einen Client auf einen Backup Server zu lenken. Single Point Of Failure SPOF gibt es im BEA Cluster an den Stellen JMS und Administration. Cluster Topologie Alle wesentlichen Clustertopologien sind unterstützt. Es ist möglich, externe WebServer zu benutzen. Wartung und Administration Eine Schwachstelle bei WL ist die Wartung. Obwohl BEA sich im Bereich der Konfigurations- Synchronisation weiterentwickelt hat, fehlt die Unterstützung für Monitoring Agents, dynamische Application Launcher oder Dateisynchronisierungs-Dienste. Diese Nachteile machen die Anschaffung einer Third Party Lösung, um den SPOF zu umgehen, notwendig. Beispielsweise ist Dateisynchronisierung nicht notwendig beim Einsatz eines SANs. HP Bluestone Total e-server Cluster-Implementierung Bluestone implementiert einen unabhängigen JNDI-Baum. Ein Load Balancing Broker (LBB), der als PlugIn im WebServer läuft, unterstützt dabei Load Balancing und Failover von HTTP- Anfragen. Der LBB weiß, welche Anwendung auf welcher Server-Instanz läuft und kann dementsprechend die Anfragen verteilen. Ausfallsicherheit für Stateful und Stateless Session und EntityBeans innerhalb von Methodenaufrufen ist über einen EJB Proxy Dienst und einen Proxy LBB unterstützt. Der Hauptnachteil des EJB Proxy Dienst ist, dass er zusätzliche Wartezeit für jede EJB Anfrage erfordert und dass er auf der selben Maschine läuft wie die Server Instanz. Im Falle eines Software-Fehlers der UBS (Universal Business Server) Instanz ermöglicht der EJB Proxy und der UBS Stub Failover, nicht jedoch im Falle eines Hardwarefehlers. HW Fehler werden über die clientseitige Konfiguration der Datei apserver.txt oder der Proxy LBB Konfiguration in apserver.txt unterstützt. In Apserver.txt auf Clientseite sind alle Komponenten im Cluster aufgelistet. Werde neue Komponenten ins Cluster gebracht, müssen die Clients durch den Bluestone Application Manager (BAM) oder 14/24

15 manuell upgedatet werden. Die Benutzung der Datei apserver.txt in der Proxy LBB Instanz, ermöglicht ein Update auch ohne Anpassung der Clients. Dabei ist jedoch mit längeren Wartezeiten bei jedem EJB Aufruf zu rechnen. Bluestone ist der einzige Applikationsserver der JMS Clustering voll unterstützt. HTTPSession-Failover HttpSession-Failover wird über In-Memory Replikation auf einem zentralen State Server oder über eine Datenbank ermöglicht. Single Point Of Failure Keinen. Cluster-Topologie Alle Cluster-Topologien werden unterstützt. Wartung und Administration Bluestone bietet umfangreiche Möglichkeiten der Administration. Es gibt einen dynamischen Applikations Launcher (DAL), der vom LBB aufgerufen wird, wenn eine Anwendung oder eine Maschine nicht mehr zur Verfügung steht. Der DAL kann die Anwendung auf dem Primary- oder dem Backup-Server neu starten. Weiterhin bietet Bluestone ein Konfigurations- und Deployment-Tool (BAM) an, mit dem man Packages und die damit verbundenen Konfigurationsdateien einsetzen kann. Einziger Nachteil des Tools: man kann die Maschinen nur einzeln konfigurieren, was in größeren Clustern zu Problemen führen kann. Sybase Enterprise Application Server 3.6 Cluster-Implementierung Der EA Server von Sybase clustert auf Basis eines zentralen JNDI-Baums. Ein Hardware LB ermöglicht Lastverteilung und Ausfallsicherheit für HTTP-Anfragen. Die beiden Name-Server im Cluster, die aufgrund der zentralen JNDI-Baum Struktur benötigt werden, können zwar ebenfalls HTTP-Anfragen verarbeiten, was aus Performance-Gesichtspunkten jedoch nicht empfehlenswert ist. Von daher ist die Verarbeitung von JNDI-Anfragen ausschließlich den Name-Servern vorbehalten. Version 3.6 des EA Server hatte noch keine WebServer PlugIns, diese sind für angedacht. Ebenso wie der Bluestone Server unterstützt der EA Server Failover für Stateful und Stateless Session und Entity Beans innerhalb von Methodenaufrufen. Der EA Server bringt keine eigenen Monitoring-Agents oder Applikations- Launcher mit. Von daher ist es für einen automatischen Server Restart oder zur Vermeidung eines SPOF erforderlich, Drittanbieter-Lösungen (z.b. Veritas Cluster Server) einzusetzen. JMS wird nicht unterstützt. Wie bereits im Kapitel Cluster Implementierungen dargestellt, hängt die Konvergenzzeit des Clusters stark von der Anzahl der Name-Server und der gesamten Server-Anzahl ab. Von den drei Cluster-Arten besitzt die zentrale JNDI-Baum Implementierung die schlechteste Konvergenzzeit. Um die Performance zu verbessern und mehr Kontrolle über die Lastverteilung zu haben, bietet Sybase zwei Möglichkeiten der Lastverteilung an: Implizit und Partitioniert. Bei der impliziten Lastverteilung liefert der NS immer eine Liste aller geclusterten Server, die eine angefragte Komponenten halten. Es ist jedoch auch möglich, Komponenten auf verschiedene Servern aufzuteilen. Beispielsweise können einige Server mit schnelleren CPUs ausgerüstet sein und andere näher an der Datenbank liegen. Der Administrator kann jetzt Komponenten, die viel CPU-Leistung benötigen, auf den schnelleren Maschinen installieren und datenbankintensive Komponenten nahe der Datenbank. Der NS liefert in diesem partitionierten Modus nur die Server an den Client zurück, die angefragte Komponenten halten. 15/24

16 HTTPSession-Failover HTTPSession-Failover ist über eine zentrale Datenbank möglich. In-Memory Replikation wird nicht unterstützt. Single Point Of Failure Wenn mehrere Name-Server benutzt werden, ist SPOF ausgeschlossen. Cluster-Topologie Die Flexibilität der Cluster-Topologie ist eingeschränkt, solange WebServer PlugIns fehlen. Wartung und Administration Sybase bietet gute Möglichkeiten für das Deployment über eine Synchronisation der Konfiguration. Das Cluster kann auf Komponenten, Package, Servlet, Anwendungs oder WebApplikations-Level synchronisiert werden. Es ist auch möglich, mehrere Maschinen im Cluster gleichzeitig zu synchronisieren, was jedoch bei vielen Maschinen oder vielen Dateien einige Zeit dauern kann. Ein Schwachstelle ist der bereits erwähnte, fehlende Applikations- Launcher. Silverstream Application Server 3.7 Cluster-Implementierung Beim Aufsetzten des Silverstream Clusters kann der Administrator zwischen zwei Konfigurationen wählen: Dispatcher basiert WebServer Integrations Modul (WSI) In einem Dispatcher basierten Cluster verbindet sich der Benutzer zum Dispatcher oder einem hardware-basierten Verteiler (z.b. Alteon 80). Der Dispatcher leitet die HTTP-Anfrage um und bindet diese an eine Maschine. Von diesem Zeitpunkt an werden alle weiteren Anfragen innerhalb der laufenden Session an diese Maschine gebunden. In der Dispatcher- Konfiguration gibt es keinen Unterschied zwischen einem einzelnen Server und dem gesamten Cluster. Was den Client angeht, erscheint das Cluster als ein einzelner Server. Ein großer Nachteil hierbei ist, dass die statischen Teile der Anwendung nicht unabhängig von den dynamischen Teilen skaliert werden können. Im WSI basierten Cluster verbindet sich der Benutzer ebenfalls mit einem Dispatcher, der Anfragen an einen WebServer übergibt. Jeder WebServer hat dazu ein PlugIn, das auf einen Load Balancer, der vor das Silverstream Cluster geschaltet ist, zeigt. Das WSI Cluster benutzt keine Umleitung, so dass jede Anfrage auf alle WebServer verteilt wird. Ein zweiter Load Balancer sorgt für Ausfallsicherheit auf Applikationsserver-Ebene. Die WSI-Architektur hat Vorteile gegenüber der Dispatcher Variante: statische und dynamische Inhalte einer Site können unabhängig skaliert werden. Ein wesentlicher Nachteil ist, dass der ArgoPersistence Manger für HTTPSession Failover benötigt wird. In beiden Architekturen ist Failover und JMS Clustering nicht unterstützt. HTTPSession-Failover Silverstream unterstützt HTTPSession-Failover über eine zentrale Datenbank und den Argo Persistence Manager. Leider ist diese Lösung proprietär und mit weiteren Kosten verbunden. Anstatt dass die Standard HTTPSession benutzt wird, um Session-Informationen in der Datenbank zu speichern, muss man Klassen des ArgoPersistence Manager nutzen. Single Point Of Failure Keiner. 16/24

17 Cluster Topologie Über die beiden Möglichkeiten werden alle Cluster Topologien unterstützt. Wartung und Administration Ein Cache Manager und ein dynamischer ClassLoader bieten eine einfache Möglichkeit, laufende Anwendungen zu deployen und upzudaten. Wird eine Anwendung auf dem Server upgedatet, so wird das Update in eine Datenbank geschrieben und der Cache Manager löscht den Cache aller Server, so dass diese die upgedaten Teile beim nächsten Zugriff laden müssen. Der einzige Nachteil ist die Zeit, die benötigt wird, Anwendungen aus der Datenbank während des ersten Zugriffs in den aktiven Speicher zu laden. SAP Web Application Server 6.20 Cluster-Implementierung Der SAP Web Application Server 6.20 lässt sich aufgrund seiner hybriden Architektur nicht direkt in eine der zuvor diskutierten Cluster-Kategorien einordnen. Mit der Fokussierung auf neuzeitliche e-business Lösungen hat SAP ihre, bis jetzt in ABAP entwickelte, Basisinfrastruktur um einen J2EE kompatiblen Teil erweitert. Die Technologieplattform mysap Technology besteht dabei im wesentlichen aus drei großen Blöcken: 1. Protal Infrastruktur Plattform für benutzerzentrierte Verarbeitung 2. Web Application Server Plattform für Anwendungskomponenten mit Unterstützung für WebServices 3. Exchange Infrastruktur Integrationsplattform für prozesszentrierte Collaborations Für die Betrachtung des J2EE-Clusters reicht es aus sich auf den SAP Web Application Server zu beschränken. Der große Vorteil des Web Application Servers ist die Kombination aus J2EE und ABAP Umgebung (Bild 7). Bild 7: SAP Web Application Server Technisch gesehen beinhaltet der WAS vier wesentliche Module: 1. Internet Communication Manager Verantwortlich für die Kommunikation zwischen dem WAS und den Clients. 2. APAB-Teil Basiert auf SAPs vorhandener Plattform. Alle existieren SAP Komponenten laufen darauf ab. 3. J2EE-Teil Basiert auf dem J2EE zertifizierten In-Q-My Applikationsserver, der innerhalb des WAS als J2EE-Runtime Umgebung fungiert. Anfragen, die vom ICM kommen, werden verarbeitet und die Antwort wird dynamisch generiert. Anwendungsentwickler sind somit in der Lage Web Applikationen auf Basis des J2EE Standards zu entwickeln. 17/24

18 4. SAP Java Connector Ermöglicht Methodenaufrufe zwischen SAP Anwendungen und Java-Anwendungen. JCO ist bi-direktional und setzt auf der Java Connector Architektur 1.0 auf. Um externe Anwendungen und Drittanbietersoftware zu integrieren unterstützt der WAS gängige Industriestandards wie SOAP und XML. Der J2EE-Teil beinhaltet ein Dispatcher basiertes Cluster, der die HTTP-Anfragen für die Dauer einer Session an eine Maschine bindet. Dem Client erscheint das Cluster als ein einzelner Server. Im Gegensatz zu den bisher beschriebenen Architekturen basiert das Clustering hier auf einer shared global Architektur die zusätzlich einen Primären Server, der als zentraler Name Server läuft, beinhaltet. Dieser Name-Server hält den globalen JNDI- Baum und die Deployment-Informationen des Deployment-Descriptors. Der Name-Server weiß so welche Objekte auf welchem Server deployed sind, es werden jedoch, im Gegensatz zur zentralen JNDI-Baum Implementierung nicht alle Requests über den, Name- Server verteilt. Ein Server richtet sich beispielsweise nur an den Name-Server wenn ein Bean-Loookup gemacht wird und die gesuchte Bean nicht auf dem aktuellen Server liegt. In diesem Fall fragt der Server beim Primären-Server nach wo das Objekt liegt und bekommt, ähnlich der zentralen NS-Architektur, eine Objekt-Referenz, wo sich dieses Objekt befindet, zurück. Weiterhin verwaltet der Primäre-NS eine Liste der Object-Locks und wird somit für die Transaktionssteuerung benutzt. Der zentrale JNDI-Baum wird persistent in der internen Server-DB gespeichert. Um Ausfallsicherheit für den Primären-Server zu gewährleisten kann es zwei Primäre Server geben. Als Lastverteilungs-Algorithmus wird ein gewichtetes Round-Robin benutzt. Der Administrator kann dabei relativ zur Größe der Maschinen die Verteilung festlegen. Beispiel: In einem Cluster mit zwei Servern hat eine Maschine 500MHz und 256MB RAM und eine 1GB und 1GB RAM. Hier wäre eine sinnvolle Verteilungsmöglichkeit 1:3. Generell ist es in der J2EE-Welt nicht ohne weiteres möglich ein reines dynamisches Load Balancing zu erreichen, da man mit Java nicht ohne weiteres an die CPU-Daten gelangt. Hier wäre es notwendig eine DLL/Shared-Library zu schreiben die den Applikations Server mit den CPU- Daten versorgt. HTTPSession-Failover Wird nicht unterstützt. Failover ist in diesem Fall sessionbasiert. Fällt ein Server aus so wird der Client auf einen anderen Server im Cluster umgeleitet, muss hier aber die Session noch mal starten. Basisinformationen über den Benutzer werden auf einem zweiten Primären Server repliziert. SPOF Keiner. Beim Ausfall des Dispatchers muss der Entwickler jedoch manuell dafür sorgen, das ein weiterer Dispatcher die Anfrageverteilung übernimmt. Cluster-Topologie Es werden alle gängigen Topologien unterstützt. Wobei bei der Benutzung des integrierten WebServers der Dispatcher vor dem WebServer läuft und bei Benutzung eines externen WebServers hinter dem WebServer. 18/24

19 Bild 8: SAP Web Application Server J2EE-Cluster Wartung und Administration Die Administrationskonsole stellt sowohl eine visuelle Schnittstelle als auch ein Command Line Interface für die Verwaltung des J2EE-Servers zur Verfügung. Der Administrator kann unterschiedliche Dienste starten, anhalten und konfigurieren während der Server läuft. Die Administrationskonsole wird für folgende Aufgaben eingesetzt: Konfiguration und Einrichten des Clusters Security Management Laufzeitverwaltung sowie Steuerung der Dienste und Manager Verwaltung des Log-Systems Im Cluster-Tab werden alle laufenden Server und Dispatcher-Knoten angezeigt sowie Informationen über den Port, Host und die ID. Setup und Verwaltung von Clustern Um schwerwiegende Fehler beim Aufsetzen eines Clusters zu vermeiden, ist es empfehlenswert, sich bereits in der Design-Phase mit clusterrelevanten Eigenheiten, wie Setup und Konfiguration, zu beschäftigen. Zu guter Letzt spielt die Verwaltungsstrategie im Failover-Fall eine wesentliche Rolle. Cluster Setup Während des Cluster-Setup müssen einige signifikante Entscheidungen getroffen werden. Erstens wird die Lastverteilungs-Methode festgelegt. Zweitens muss man die Server-Affinität berücksichtigen (Server-Affinität lenkt die Benutzeranfrage, für die Dauer der Session, auf einen spezifischen Server im Cluster). Abschließend muss der Deployment-Prozess für die Server-Instanzen definiert werden. Lastverteilungsoptionen Es gibt zwei generelle Optionen für die Lastverteilung in einem Cluster: DNS Round Robin oder Hardware Load Balancers. Die Unterschiede der beiden Ansätze wirken sich erheblich auf die Design- und Verwaltungsstrategie aus. Je nach Art der Cluster-Implementierung ist die Kommunikation auf Softwarebasis erheblich langsamer als bei hardwarebasierten Hochgeschwindigkeits-Verbindungen. DNS Round Robin Im DNS Prozess wird ein logischer Name in eine IP-Adresse konvertiert. Bei DNS Round Robin Lastverteilung im Cluster kann ein logischer Name jede IP Adresse der Maschinen im Cluster zurückliefern. Der große Vorteil beim DNS Round Robin ist das einfache und kostengünstige Setup. Nachteile sind keine Server-Affinität Erhält ein Benutzer eine IP-Adresse, so wird diese im Browser gecached. Steht der Cache nicht mehr zur Verfügung, weil er abgelaufen oder überschrieben wurde, muss der Benutzer eine neue Anfrage stellen. Ohne Server-Affinität kann die zweite 19/24

20 Anfrage eine IP-Adresse einer anderen Maschine zurückliefern. Die Session ist somit verlorenen. keine Unterstützung für Hochverfügbarkeit In einem Cluster mit n Servern fällt ein Server aus: Jede n te Anfrage an den DNS Server wird auf den ausgefallen Server gelenkt und kann nicht beantwortet werden. Änderungen im Cluster benötigen Zeit, um sich im gesamten Cluster zu verbreiten Viele Unternehmen cachen die DNS Lookups der Clients. Auch wenn die DNS Liste im Cluster dynamisch änderbar ist, benötigt es eine gewisse Zeit, die gecachten Einträge zu entfernen. Dies kann dann dazu führen, dass Anfragen auf einen Server geschickt werden, der physikalisch nicht mehr im Netz ist. keine Garantie einer gleichmäßigen Lastverteilung über alle Server Werden die DNS Server nicht extra zur Zusammenarbeit für Lastverteilung konfiguriert, wird immer die erste IP-Adresse, die der DNS Server zurückliefert, zur Anfragebearbeitung verwendet. Dies hat zur Folge, dass alle Anfragen auf einen Server geleitet werden. Hardware Load Balancer Im Gegensatz zu DNS Round Robin lösen Hardware Load Balancer die meisten der oben beschriebenen Probleme über eine virtuelle IP-Adresse. Ein Hardware Load Balancer stellt eine IP-Adresse für das gesamte Cluster zur Verfügung. Der Load Balancer bekommt den Request und leitet diesen an einen Server im Cluster weiter. Wird eine Maschine entfernt, ist die Änderung direkt wirksam. Vorteile des Hardware Load Balancers sind Server-Affinität wenn kein SSL benutzt wird hohe Verfügbarkeit durch Failover und Monitoring Messungen z.b der aktiven Sessions, Antwortzeiten etc. gleichmäßig garantierte Verteilung über das Cluster Die Nachteile von Hardware Load Balancern sind sehr hohe Kosten je nach Funktionen bis US Dollar komplexes Setup und Konfiguration Server-Affinität Server Affinität wird zu einem Problem, wenn SSL ohne Web Server Proxies benutzt werden. Hardware Load Balancer basieren auf Cookies oder URL-Parametern, um festzustellen, wohin die Anfragen weitergeleitet werden. Wenn eine Anfrage SSL verschlüsselt ist, kann der Harware Load Balancer keine Cookie oder URL-Informationen lesen. Um diese Problem zu umgehen, gibt es zwei Möglichkeiten: Die Benutzung von Web Server Proxies oder SSL Accelerators. Web Server Proxies In diesem Szenario verhält sich der Hardware Load Balancer wie ein DNS Load Balancer für den Web Server Proxy. Der Web Server entschlüsselt den SSL-Request und übergibt diesen an das Web Server Plug-In (Web Server Proxy). Sobald der Proxy den entschlüsselten Request empfangen hat, kann er diesen parsen und über die Cookie- oder URL-Informationen die Anfrage an den Server schicken, auf dem die Benutzer-Session läuft. Die hauptsächlichen Vorteile durch Web Server Proxies sind Server-Affinität mit SSL Verschlüsselung es wird keine weitere Hardware außer dem Hardware Load Balancer benötigt Nachteile durch Web Server Proxies sind: der Hardware Load Balancer kann keine Messungen als Grundlage für die Request Weiterleitung benutzen; 20/24