Clustering in J2EE-Umgebungen

Transkript

1 Clustering in J2EE-Umgebungen Thomas Mattern Produkt Marketing Manager In-Q-My Technologies GmbH

2 Agenda! Cluster-Definition und Background! Cluster-Arten und Implementierungen! Cluster- und Failover-Dienste - HTTPSession-Failover - Single Point Of Failure! Cluster-Topologie! Wartung und Administration! Cluster-Strategien verbreiteter Applikationsserver! Aufsetzen und verwalten von Clustern! Ausblick und Zusammenfassung

3 Cluster Definition und Backround

4 Cluster Definition und Backround Definition Ein Cluster ist eine Gruppe von Maschinen, die transparent für den Benutzer Dienste für Skalierbarkeit und Hochverfügbarkeit zur Verfügung stellen. Bezogen auf J2EE! JNDI (Java Naming & Directory Interface)! EJB (Enterprise Java Beans)! JSP (Java Server Pages)! Servlets Unterschiedliche Implementierungen! Dispatcher Maschinen im Cluster kennen sich untereinander nicht - Verteilung Session abhängig - Dispatcher bindet Benutzeranfrage an einen Server! Eng gekoppelte Maschinen - jede Maschine kennt gesamtes Cluster einschließlich der Anwendungsobjekte

5 Cluster Definition und Backround Cluster mit Dispatcher

6 Cluster Definition und Backround Architektur-Komponenten eines Clusters! Hardware Load Balancer - lenken als Single Point of Entry die Anfragen an einen indivduellen Web- oder Applikationsserver! WebServer! Gateway-Routers - fungieren als Ausgang aus einem internen Netzwerk! Multilayer-Switches - arbeiten als Filter, damit jede Maschine im Cluster nur die Informationen erhält, die benötigt werden! Firewalls - sichern das Cluster durch Filtern von Port-Level Informationen! SAN (Storage Area Network) Switches - verbinden den WebServer, Applikationsserver und die Datenbank mit einem Backend Speichermedium! Datenbanken

7 Cluster Definition und Backround Hauptfunktionalitäten des Clusters Skalierbarkeit Skalierbarkeit im Cluster bezieht sich auf die Unterstützung einer beliebigen Anzahl von Benutzern. Steigt die Benutzerzahl, 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. Web- Clients Zwei Arten von Lastverteilung! Softwarebasierte Lastverteilung! Hardwarebasierte Lastverteilung

8 Cluster Definition und Backround Vor/Nachteile software- und hardware basierter Lastverteilung! Zusätzliche Software auf dem Server reduziert die Systemresourcen und beeinflußt Serverstabilität.! Für Alive-Statusprüfung benutzen die meisten Hersteller ping. Ping testet nur Server/Netzverbindung nicht die einzelnen Dienste und Funktionen auf dem Server.! Lastverteilungssoftware arbeit häufig nur auf der Basis von Round-Robin Mechanismen. 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 zusätzliches Gerät eingesetzt -> Server kommen ohne zusätzliche Software aus.! Administration bei hardwarebasierter Lastverteilung häufig einfacher.! Kontrollierteres Server-Shutdown für Updates durch Hardware-Switch.

9 Cluster Definition und Backround Hauptfunktionalitäten des Clusters Hohe Verfügbarkeit 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. Hohe Verfügbarkeit wird erreicht indem man Komponenten redundant hält.! Häufig Verfügbarkeit nur auf Applikationsserver Ebene Verfügbarkeit [%] > 90 > 99 > 99,9 > 99,99 > 99,999 > 99,9999 Ausfall pro Jahr über 1 Monat unter 4 Tage unter 9 Stunden ca. eine Stunde ca. 5 Minuten ca. ½ Minute Neunen Beispiel Jaguar e-typ Windows 2000 Unix-Cluster Gut verwalteter NT- oder Unix- Cluster Mainframe High-End Unix-Cluster S/390 Sysplex, Telco Switch Flugzeugcomputer Primärer-Server Backup-Server

10 Agenda! Cluster-Definition und Backround! Cluster-Arten und Implementierungen! Cluster- und Failover-Dienste - HTTPSession-Failover - Single Point Of Failure! Cluster-Topologie! Wartung und Administration! Cluster-Strategien verbreiteter Applikationsserver! Aufsetzen und verwalten von Clustern! Ausblick und Zusammenfassung

11 Cluster-Arten und Implementierungen Shared nothing Cluster Server 1 hat keinen Zugriff auf Resourcen von Server 2 DMZ AS 1 Internet AS 2 Server 2 hat keinen Zugriff auf Resourcen von Server 1 Jeder Applikationsserver hat eigenes File-System, mit eigenen Kopien der Anwendungen. Updates und Erweiterungen erfordern Anpassung in jedem Cluster-Knoten! Verwaltungsaufwand sehr hoch

12 Cluster-Arten und Implementierungen Shared Disk Cluster Internet DMZ AS 1 Gleichzeitiger Zugriff mehrerer Server auf die selben Resourcen AS 2 Alle Applikationsserver greifen auf gemeinsamen Speicher zu. Updates und Erweiterungen finden nur an einer Stelle statt und alle Maschinen im Cluster können darauf zugreifen.! Nachteil: Single Point Of Failure. Kann z.b. durch Einsatz eines SANs umgangen werden.! Verwaltungsaufwand geringer als bei shared nothing Cluster

13 Cluster-Arten und Implementierungen Cluster-Kriterien! Cluster-Implementierung! Dienste für Cluster- und Komponenten-Ausfallsicherheit! HTTPSession-Failover! Single Points Of Failure! Cluster-Topology! Wartbarkeit des Clusters

14 Cluster-Arten und Implementierungen Clustering auf Basis der JNDI Implementierung! einheitliche Schnittstelle zu Namensund Verzeichnisdiensten! einfaches Lokalisierung von Objekten in einer verteilten Umgebung! JNDI ist Basisdienst von J2EE basierten Applikationsservern! Programmierarbeit wird erleichtert, da Objektlokation nicht im Code hinterlegt wird! NS verwaltet ein Set von sogenannten Bindings die in Beziehung zu Objekten stehen! alle Objekte im NS sind nach dem selben System benannt und bei der selben Naming- Convention angemeldet! COS (Common Object Services) Naming! DNS (Domain Name Service)! LDAP (Lightweight Directory Access Protocol)! NIS (Network Information System)

15 Cluster-Arten und Implementierungen Clustering Methode hängt von der JNDI-Implementierung des jeweiligen Applikationsservers ab! Unabhängiger JNDI-Baum! Zentraler JNDI-Baum! Shared global JNDI-Baum Cluster-Konvergenz Zeit die vom Cluster benötigt wird alle Maschinen und ihre assoziierten Objekte im Cluster zu erkennen.

16 Cluster-Arten und Implementierungen Unabhängiger JNDI-Baum! Server kennen nur sich selbst und nicht die anderen Server des Clusters Vorteil! sehr kurze Cluster-Konvergenz - wird erreicht sobald zwei Maschinen gestartet sind! einfache Skalierbarkeit. - Skalierbarkeit bedeutet nur hinzufügen eines weiteren Servers Nachteil! Failover entweder nicht unterstützt oder über Vermittlerdienste (Proxy) gelöst - Ausfallsicherheit liegt in der Verantwortung des Entwicklers - manuelle Implementierung notwendig, da Anfrage immer an den Server gebunden ist auf dem sie gestartet wurde ToDo: verbinden mit Dispatcher -> ermitteln der Adresse eines alternativen Servers -> starten eines weiteren JNDI-Lookup -> fehlgeschlagene Methode erneut aufzurufen! HP Bluestone und Silverstream nutzen unabhängige JNDI Baum Implementierung! Bluestone nutzt kompliziertere Form, in der Anfragen an einen EJB-Proxy Dienst oder an einen Proxy Load Balancing Broker (LBB) gehen! Proxy Dienst stellt sicher, dass jede EJB-Anfrage an eine aktive Server-Instanz geht - erhöht Wartezeit auf Antwort, aber Failover möglich

17 Cluster-Arten und Implementierungen Zentraler JNDI-Baum! CORBAs CosNaming Service wird für JNDI-Baum angewandt - Name-Server kennt den zentralisierten JNDI-Baum für das Cluster und weiß welche Server im Cluster aktiv sind - jeder Server verbindet seine Objekte mit dem JNDI-Baum zum Startzeitpunkt - Name-Server melden sich ebenfalls bei JNDI-Baum an - zwei Schritte notwendig um eine Referenz auf EJB zu bekommen 1. Client sucht nach einem Home-Objekt von Name-Server, und erhält IOR (Interoperable Object Reference) zurück 2. Client wählt den ersten Server im IOR aus und erhält Home- und Remote-Interface der Bean! im Fehlerfall greift der CORBA-Stub auf ein anderes Home- oder Remote-Interface im IOR zu Nachteile! Name-Server ist Schwachstelle des Clusters, da Ausfallsicherheit nur solange gewährleistet wie Name-Server aktiv

18 Cluster-Arten und Implementierungen Zentraler JNDI-Baum! Problem wenn aufgrund eines Fehlers weiterer Name-Server zur Laufzeit in das Cluster gebracht wird, der den eigentlichen Name-Server ersetzen soll -> neuer Name-Server benötigt Daten jeder aktiven Maschine um Objektinformationen in den neuen zentralen JNDI-Baum aufzunehmen -> Binding-Prozess beeinflusst die Wiederherstellungsszeit des Clusters nachteilig! bei jedem JNDI-Aufruf einer Applikation werden zwei Netzwerkaufrufe abgesetzt! erhöhte Konvergenzzeit, wenn das Cluster größer wird - je größer das Cluster umso mehr Name-Server werden benötigt - Verhältnis NS zu Summe aller Server sollte 1:10 sein (min. 2 Name-Server) - Anzahl der Verbindungen NS mit Servern steigt rapide an - jede Verbindung repräsentiert einen Prozess in dem ein Server alle seine Objekte mit dem JNDI-Baum eines Name-Servers verbindet! Sybase Enterprise Application Server implementiert einen zentralen JNDI-Baum Cluster

19 Cluster-Arten und Implementierungen Shared Global JNDI-Baum! Server macht sich zum Startup-Zeitpunkt bei den anderen Servern im Cluster bekannt - JNDI-Baum wird über IP-Multicasting übertragen IP-Multicast! Broadcasting Technologie, die unterschiedlichen Anwendungen ermöglicht, sich zu einer vorgegeben IP-Adresse und Port-Nummer zu subscriben und Nachrichten entgegen zu nehmen.! Jede Maschine im Cluster verbindet seine Objekte mit dem shared global JNDI-Baum und mit seinem lokalen JNDI-Baum - Kombination des globalen und lokalen JNDI-Baums in jedem Server ermöglicht Failover und ein schnelles JNDI-Lookup Verhalten für Home- und Remote-Stubs - jede Maschine kennt 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, welches wiederum die Lokation aller EJB-Objekte mit denen es in Verbindung steht kennt

20 Cluster-Arten und Implementierungen Shared Global JNDI-Baum Vorteile! einfachere Skalierbarkeit sowie höhere Verfügbarkeit als im zentralen Cluster! Entwickler/Administrator braucht nicht mit CPUs oder RAM auf speziellem Name-Server hantieren! kein Cluster-Tuning der Name-Server notwendig! anstelle von individueller Skalierung reicht es aus eine weitere Maschine hinzuzufügen! Netzwerkbelastung im Betrieb ist geringer als in einem zentralen Cluster, da jeder entfernte Lookup nur einen Netzwerkaufruf benötigt Nachteile! hohe Netzwerkbelastung beim hochfahren der Server und damit verbundene längere Konvergenzzeit (benötigte Zeit für den Aufbau des shared global JNDI-Baums ist linear in Relation zu Anzahl eingebundener Server)! BEA WebLogic implementiert einen shared global JNDI-Baum

21 Cluster-Arten und Implementierungen Übersicht Cluster-Arten verschiedener Hersteller HP Sybase Silverstream BEA SAP Web Application Server Unabhängiger JNDI-Baum x x Zentraler JNDI- Baum x x Shared Global JNDI-Baum x x HTTPSession In-Memory x (zentral) x (beliebig) HTTPSession File/DB x x (+ Drittanbieter Produkt)

22 Agenda! Cluster-Definition und Backround! Cluster-Arten und Implementierungen! Cluster- und Failover Dienste - HTTPSession-Failover - Single Point Of Failure! Cluster-Topologie! Wartung und Administration! Cluster-Strategien verbreiteter Applikationsserver! Aufsetzen und verwalten von Clustern! Ausblick und Zusammenfassung

23 Cluster und Failover-Dienste Übersicht Failover-Dienste! Applikationsserver unterstützen geclusterte Komponenten - gehen aber nicht individuell auf die Komponetenarten (Entity Beans, Stateless und Stateful Session Beans oder JMS)! Lastverteilungs-Mechanismen werden berücksichtigt, Ausfallscenarien nicht, oder nur begrenzt! BEA WL 5.1 unterstützt geclusterte Stateful Session Beans, wenn der Server auf dem die Bean-Instanz läuft ausfällt, geht der gesamte Status verloren -> Client muss Bean neu erzeugen und im Cluster bekannt machen -> ab BEA WL 6.0 Clustering auch für Stateful Session Beans durch In-Memory Replikation Failover möglich! Applikationsserver unterstützen Failover oft nur in bestimmten Fällen - Sybase Enterprise Application Server unterstützt Failover für Stateful Session Beans für den Fall, dass Bean Status von Datenbank oder über Serialisierung geladen wird! JMS wird auch im Clusterbetrieb unterstützt, jedoch keine Unterstützung für Lastverteilung oder Ausfallsicherheit von individuellen Topics und Queues -> spezielle Clusterimplementierung für JMS (z.b. Sonic MQ)

24 Cluster und Failover-Dienste HTTPSession-Failover! ermöglicht Client Session-Information eines anderen Servers im Cluster zu erhalten, wenn eigene Session fehlschlägt > elementare Grundlage für Ausfallsicherheit! Zwei Ansätze: In-Memory basiert und Datenbank basiert In-Memory! es gibt zwei Methoden der In-Memory Speicherung 1. HTTPSession Informationen werden auf zentralen Server zur Statusverwaltung geschrieben 2. jeder Knoten im Cluster kann einen beliebigen Backup-Knoten auswählen um Session Informationen In-Memory zu speichern -> beim Hinzufügen eines Objekts wird nur dieses Objekt serialisiert und im Speicher des Backup-Servers gehalten Application Server 1 HTTP-Session In-Memeory Replikation der HTTPSession Application Server 2 HTTP-Session

25 Cluster und Failover-Dienste HTTPSession-Failover Datenbank/Filesystem basiert! jedes mal wenn ein neues Objekt zur HTTPSession hinzufügt wird, werden alle Objekte der Session serialisiert und in die Datenbank geschrieben -> limitierte Skalierbarkeit wenn große Anzahl Objekte in Session-Informationen gespeichert sind! die meisten Applikationsserver, die mit Datenbank Session Persistenz arbeiten, versuchen den HTTPSession-Store möglichtst wenig zu benutzen -> limitierte Flexibilität der Web-Anwendung und des Designs, besonders wenn Session Speicher benutzt wird um Benutzerdaten zu cachen! Ob Speicherung In-Memory oder in DB hängt von der Größe des Clusters ab - geringe Anzahl Server im Cluster -> zentralen Server, da In-Memory Methode eine höhere CPU-Auslastung bei der Transaktionsverarbeitung und der dynamischen Seitengenerierung hat - große Anzahl Server im Cluster -> In-Memory Replikation auf beliebigen Backup- Server skaliert linear wenn weitere Server hinzukommen (zentraler Session-Server wird zum Flaschenhals)

26 Cluster und Failover-Dienste HTTPSession-Failover! bei steigender Anzahl von Servern im Cluster muss zentraler Session-State-Server permanent angepasst werden (RAM und CPUs)! bei In-Memory Replikation auf beliebigen Server werden einfach weitere Maschinen ins Cluster gehangen und Session-Informationen verteilen sich automatisch auf allen Servern! BEA WL nutzt In-Memory Session-Failover mit beliebigem Server! HP Bluestone greift auf einen zentralen Session-Speicher zu! Silverstream Application Server und Sybase EA benutzen eine zentrale Datenbank oder Filesystem auf das alle Applikationsserver im Cluster lesend und schreibend zugreifen können

27 Cluster und Failover-Dienste HTTPSession-Failover und Stateful Session Beans Application Server 1 HTTP Session In-Memeory Replikation der HTTPSession auf Servlet-Ebene Application Server 2 HTTP Session Handle Handle Application Server 1 Stateful Session Bean In-Memeory Replikation des State der Stateful Session Bean auf EJB-Ebene Application Server 2 Stateful Session Bean! Kriterien für HTTPSession treffen auch für Stateful Session Beans zu! wird eine bestimmte Datengröße überschritten wird, kann es sinnvoll sein Teile der Daten in Stateful Session Bean auszulagern -> notwendigen Daten für Failover-Fall werden in HTTPSession mitgeführt und repliziert -> Rest der Daten wird in nicht replizierter Stateful Session Bean gespeichert! Handle kennt Lokation der HTTPSession Informationen und der Stateful Session Bean! mehrschichtige Architektur: Präsentationsschicht hält Daten in der HTTPSession -> Daten die für interne Kommunikation mit BO benötigt werden können in SSBean verbleiben

28 Cluster und Failover-Dienste Single Point Of Failure! Gibt es von einem Dienst innerhalb eines Clusters kein Backup, so bezeichnet man dies als Single Point Of Failure (SPOF)! Gefahr bei SPOF, dass gesamte Cluster oder Teile der Applikation nicht mehr funktionieren! BEA WL unterstützt bei JMS nur die Möglichkeit ein Topic auf einer Maschine im Cluster laufen zu lassen. Wird das 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.! Überprüfung des Clusters auf SPOFs sehr relevant für Cluster-Strategie und Auswahl

29 Agenda! Cluster-Definition und Backround! Cluster-Arten und Implementierungen! Cluster und Failover-Dienste - HTTPSession-Failover - Single Point Of Failure! Cluster-Topologie! Wartung und Administration! Cluster-Strategien verbreiteter Applikationsserver! Aufsetzen und verwalten von Clustern! Ausblick und Zusammenfassung

30 Cluster-Topologie Cluster-Topologie! Cluster-Topologie definiert die Anordnung der Cluster-Komponenten! Ziel: maximale Flexibilität im Aufbau! Die meisten Applikationsserver können als WebServer eingesetzt werden -> PlugIns für gängige WebServer wie Apache oder Microsoft IIS! Ob separater WebServer oder Web-Services des Applikationsservers, richtet sich danach wie das Verhältnis von statischen zu dynamisch erzeugten Web- Seiten ist! hauptsächlich statische Inhalte -> externen WebServer (geringerer Aufwand und Lizenzkosten)! dynamischen Inhalte -> Web-Dienste des Applikationsserver

31 Cluster-Topologie Cluster-Topologie Verschiedene Möglichkeiten 1. Gemeinsamer Web- und Applikationsserver 2. Separater Web- und Applikationsserver 3. WebServer mit Servlet-Engine getrennt von Applikationsserver (EJB-Container) 4. Separater WebServer, Servlet-Engine und Applikationsserver (EJB-Container) 5. Java-Anwendung greift direkt auf Applikationsserver zu

32 Cluster-Topologie Gemeinsamer Web- und Applikationsserver AppServer 1 Web- Container EJB- Container DMZ Internet Web- Container AppServer n EJB- Container! gesamter Server muss repliziert werden! einfach aufzusetzen aber hohe Hardwareanforderungen! empfehlenswert wenn Lastverteilung nicht sehr kritisch

33 Cluster-Topologie Separater Web- und Applikationsserver AppServer 1 Web- Container Web-Server 1 mit PlugIn EJB- Container DMZ Internet Web-Server n mit PlugIn AppServer n Web- Container EJB- Container! Verarbeitung von statischen und dynamischen Seiten getrennt! Maximale Flexibilität! verbreitetste Architektur

34 Cluster-Topologie WebServer mit Servlet-Engine getrennt von EJB-Container AppServer 1 Web-Server 1 EJB- Container DMZ Servlet- Engine Internet Servlet- Engine Web-Server n EJB- Container AppServer n! Kommunikation zwischen Servlet und AppServer wie direkter Java-Client! höhere Flexibilität wenn WebServer Last stark von AppServer Last abweicht! Performancevergleich mit voriger Arcitektur sollte über Einsatz entscheiden

35 Cluster-Topologie Separater WebServer, Servlet-Engine und EJB-Container AppServer 1 Web-Server mit PlugIn Web-Server 1 Servlet- Engine EJB- Container Servlet- Engine Web-Server mit PlugIn Web-Server n EJB- Container AppServer n! Kombination von Architektur 2 und 3! hoher Administrationsaufwand, daher nur empfehlenswert in speziellen Lastverteilungs-Scenarien

36 Cluster-Topologie Java-Anwendung direkt auf Applikationsserver Java- Applikation AppServer 1 EJB- Container Java- Applikation Java- Applikation EJB- Container AppServer n! klassische C/S-Architektur! WebServer nicht vorhanden! Kommunikation läuft so wie bei getrennter Servlet-Engine und EJB-Container

37 Agenda! Cluster-Definition und Backround! Cluster-Arten und Implementierungen! Cluster und Failover-Dienste - HTTPSession-Failover - Single Point Of Failure! Cluster-Topologie! Wartung und Konfiguration! Cluster Strategien verbreiteter Applikationsserver! Aufsetzen und verwalten von Clustern! Ausblick und Zusammenfassung

38 Wartung und Konfiguration Wartung und Konfiguration! Schwerpunkt der Cluster-Wartung - Cluster am Laufen zu halten - Änderungen/Updates einspielen! Applikationsserver unterstützen Agententechnologie die kritische Dienste im Falle eines Fehler neu starten oder auf einem Backup-Server aktivieren! Einfache Update Möglichkeit um alle Server im Cluster auf den neusten Stand zu bringen und zu synchronisieren sollte gegeben sein! Sybase EA und HP Bluestone unterstützen File- und Konfigurations- Synchronisation! Bei großen Anwendungen und vielen Änderungen kann der Deployment- Prozess bei File- und Konfigurations-Synchronisation relativ lange dauern

39 Wartung und Konfiguration Wartung und Konfiguration Konfigurations-Synchronisation mit eine Storage Aerea Network am besten, da Änderungen nur in einem logischen Speichermedium vorgenommen werden und alle Maschinen im Cluster die Änderungen von einem zentralen Konfigurationsserver erhalten.

40 Agenda! Cluster-Definition und Backround! Cluster-Arten und Implementierungen! Cluster und Failover-Dienste - HTTPSession-Failover - Single Point Of Failure! Cluster-Topologie! Wartung und Administration! Cluster-Strategien verbreiteter Applikationsserver! Aufsetzen und verwalten von Clustern! Ausblick und Zusammenfassung

41 Cluster-Strategien verbreiteter Applikationsserver Applikationsserver Architektur-Übersicht

42 Cluster-Strategien verbreiteter Applikationsserver BEA WebLogic 6.0 Cluster-Implementierung! shared global JNDI-Baum! speziell optimierte Stubs für Client-Aufrufe, um die Anfrage auf den Server zu lenken, auf dem die Anfrage erzeugt wurde! Stubs kennen auch die Lokation aller replizierten Objekte im Cluster -> Ausfallsicherheit durch Stubs gewährleistet! Alleinstellungsmerkmal: In-Memory Replikation von Stateful Session Beans und automatisches Failover für EJB remote Objekte! clusterfähige Komponenten laufen als Service im Cluster, gilt jedeoch nicht für alle Komponentens (JMS-Topic und Queue läuft nur auf single Server) -> keine Lastverteilung und Ausfallsicherheit für JMS-Topics und Queues HTTPSession-Failover! unterstützt durch transparente In-Memory state Replikation auf einen beliebigen Backup-Server! WL Vorteil: Cookie Unabhängigkeit. WL kann im Fehlerfall encryptete Informationen in der URL benutzen um Anfrage auf Backup-Server zu lenken.

43 Cluster-Strategien verbreiteter Applikationsserver BEA WebLogic 6.0 Single Point Of Failure! SPOF durch JMS Cluster-Topologie! Alle wesentlichen Cluster-Topologien sind unterstützt. Es ist möglich externe WebServer zu benutzen. Wartung und Administration! Schwachstelle bei WL! Obwohl BEA sich im Bereich der Konfigurations-Synchronisation weiterentwicklt hat, fehlt die Unterstützung für Monitoring Agents, dynamische Application Launcher oder Dateisynchronisierungs-Dienste. -> Anschaffung einer Third-Party Lösung um SPOF auszuschließen notwendig (z.b. Dateisynchronisierung entfällt beim Einsatz eines SAN)

44 Cluster-Strategien verbreiteter Applikationsserver BEA WebLogic Smart-Stubs! BEA benutzt für komponentenbasierte Lastverteilung sog. WebLogic Smart-Stubs, die den Standard EJB-Stub ersetzen und den Bean-Aufruf übernehmen! bei entferntem Aufruf bekommt der Client eine Liste aller verfügbaren Komponenten vom Naming Service und benutzt dann einen ausgewählten Lastverteilungsmechanismus (Round-Robin, Random, oder gewichtetes Round-Robin) um sich zu einer Komponente zu verbinden! wenn eine Komponente nicht mehr zur Verfügung steht, wählt der Smart-Stub eine andere Instanz aus

45 Clusterstrategien verbreiteter Applikationsserver BEA WebLogic Cluster-Topologie

46 Cluster-Strategien verbreiteter Applikationsserver HP Bluestone Total e-server Cluster-Implementierung! unabhängiger JNDI-Baum! Load Balancing Broker (LBB), als PlugIn im WebServer, unterstützt Load Balancing und Failover! LBB weiß welche Anwendung auf welcher Server-Instanz läuft und kann dem entsprechend die Anfragen verteilen! Ausfallsicherheit für Stateful und Stateless Session und EntityBeans innerhalb von Methodenaufrufen wird über EJB Proxy-Dienst und einen Proxy-LBB unterstützt! Nachteil: EJB Proxy-Dienst benötigt zusätzliche Wartezeit für jede EJB- Anfrage und läuft auf selber Maschine wie die Server-Instanz -> Im Falle eines Softwarefehlers der Server-Instanz wird Failover unterstützt, nicht jedoch im Falle eines Hardwarefehlers

47 Cluster-Strategien verbreiteter Applikationsserver HP Bluestone Total e-server 7.2.1! HW-Fehler werden über die clientseitige Konfiguration der Datei apserver.txt oder der Proxy LBB-Konfiguration in apserver.txt unterstützt! Apserver.txt auf clientseite listet alle Komponenten im Cluster! werden neue Komponenten ins Cluster gebracht müssen die Clients durch den Bluestone Application Manager, oder manuell upgedatet werden! apserver.txt in der Proxy LBB-Instanz ermöglicht ein Update auch ohne Anpassung der Clients -> längere Wartezeiten bei jedem EJB-Aufruf, da wie zentraler NS! Bluestone unterstützt als einer der einzigen AppServer JMS-Clustering voll HTTPSession Failover! HTTPSession Failover wird über In-Memory Replikation auf einem zentralen State-Server oder über eine Datenbank ermöglicht

48 Cluster-Strategien verbreiteter Applikationsserver HP Bluestone Total e-server Single Point Of Failure! keinen Cluster-Topologie! Alle wesentlichen Cluster-Topologien werden unterstützt Wartung und Administration! umfangreiche Administrationsmöglichkeiten! dynamischer Applikations Launcher (DAL) der vom LBB aufgerufen wird, wenn eine Anwendung oder eine Maschine nicht mehr zur Verfügung steht! DAL kann Anwendung auf Primary oder Backup-Server neu starten! Konfigurations- und Deployment Tool (BAM), mit dem man Packages und die damit verbunden Konfigurationsdateien installieren kann! Einziger Nachteil: Maschinen nur einzeln konfigurierbar -> kann in größeren Clustern zu Problemen führen

49 Cluster-Strategien verbreiteter Applikationsserver HP Bluestone Cluster-Topologie! Benutzer kann über apserver.txt wählen ob Server-Affinität unterstützt wird! LBB benutzt HTTP/HTTPS oder internes Protokol! Proxy LBB wird gebraucht wenn Firewall verwendet wird, es wird dann das interne Protokol benutzt

50 Cluster-Strategien verbreiteter Applikationsserver Sybase Enterprise Application Server 3.6 Cluster-Implementierung! zentraler JNDI-Baum! Lastverteilung und Ausfallsicherheit von HTTP-Anfragen über Hardware-LB! Verarbeitung von JNDI-Anfragen ausschließlich den Name-Servern vorbehalten.! Version 3.6 noch ohne WebServer PlugIns, sollten ab verfügbar sein! Failover für Stateful und Stateless Session und EntityBeans innerhalb von Methodenaufrufen wird unterstützt! keine eigenen Monitoring-Agents oder Application-Launcher! für automatischen Server-Restart, oder zur Vermeidung eines SPOF, ist es erforderlich Drittanbieterlösungen (z.b. Veritas Cluster Server) einzusetzen! keine Unterstützung für JMS

51 Cluster-Strategien verbreiteter Applikationsserver Sybase Enterprise Application Server 3.6 HTTPSession-Failover! über eine zentrale Datenbank möglich, keine Unterstützung für In-Memory Replikation Single Point Of Failure! SPOF ausgeschlossen wenn mehrere Name-Server benutzt werden Cluster-Topologie! eingeschränkt, solange WebServer PlugIns fehlen Wartung und Administration! gute Möglichkeiten für Deployment- über Konfigurations-Synchronisation! Synchronisation auf Komponenten-, Package-, Servlet-, Anwendungs- oder WebApplikations-Level möglich! möglich mehrere Maschinen im Cluster gleichzeitig zu synchronisieren -> kann bei vielen Maschinen oder vielen Dateien Zeit in Anspruch nehmen! Schwachpunkt: fehlender Application-Launcher

52 Cluster-Strategien verbreiteter Applikationsserver Sybase Enterprise Application Server 3.6

53 Cluster-Strategien verbreiteter Applikationsserver Silverstream Application Server 3.7 Cluster-Implementierung! zwei Konfigurationen - Dispatcher basiert - WebServer Integrations Modul (WSI) Dispatcher! Benutzer verbindet sich zum Dispatcher oder einem Hardware basierten Verteiler (z.b. Alteon 80)! Dispatcher leitet die HTTP-Anfrage um, und bindet diese an eine Maschine -> alle weiteren Anfragen innerhalb der laufenden Session sind an selbe Maschine gebunden. -> keinen Unterschied zwischen einzelnem Server und gesamten Cluster (dem Client erscheint das Cluster als ein einzelner Server) -> Nachteil: statische Teile der Anwedung können nicht unabhängig von den dynamischen Teilen skaliert werden

54 Cluster-Strategien verbreiteter Applikationsserver Silverstream Dispatcher-Topologie

55 Cluster-Strategien verbreiteter Applikationsserver Silverstream Application Server 3.7 WebServer Integration Modul (WSI)! Benutzer verbindet sich ebenfalls mit einem Dispatcher der Anfragen an einen WebServer übergibt! jeder WebServer hat PlugIn das auf einen Hardware Load Balancer zeigt! WSI-Cluster benutzt keine Umleitung -> jede Anfrage wird auf alle WebServer verteilt! secondary Load Balancer sorgt für Ausfallsicherheit auf Applikationsserver Ebene! Vorteile WSI-Architektur -> statische und dynamische Inhalte einer Site können unabhängig skaliert werden! Nachteil WSI-Architektur -> externer ArgoPersistence Manger wird für HTTPSession-Failover benötigt! Failover und JMS-Clustering ist in beiden Architekturen nicht unterstützt

56 Cluster-Strategien verbreiteter Applikationsserver Silverstream Application Server 3.7 HTTPSession-Failover! Unterstütztung von HTTPSession-Failover über zentrale Datenbank und Argo Persistence Manager -> Proprietäre Lösung, da anstelle der Standard HTTPSession die Klassen des ArgoPersistence Manager benutzen werden um Session Informationen in der Datenbank zu speichern Single Point Of Failure! keiner Cluster-Topologie! über die beiden Möglichkeiten werden alle Cluster-Topologien unterstützt Wartung und Administration! Cache-Manager und dynamischer ClassLoader bieten einfache Möglichkeit laufende Anwendungen zu deployen und upzudaten! wird eine Anwendung upgedatet -> Update wird in Datenbank geschrieben -> Cache Manager löscht den Cache aller Server -> Server müssen upgedaten Teile beim nächsten Zugriff laden -> Nachteil: Anwendungen aus der Datenbank während des ersten Zugriffs in den aktiven Speicher zu laden benötigt Zeit

57 Cluster-Strategien verbreiteter Applikationsserver Silverstream WebServer Integration

58 Cluster-Strategien verbreiteter Applikationsserver SAP Web Application Server 6.20 Portal Infrastructure SAP Web Application Server Exchange Infrastructure mysap CRM mysap E-Procurement mysap SCM mysap PLM SAP R/3 Enterprise Legacy... External mysap Technology

59 Cluster-Strategien verbreiteter Applikationsserver SAP Web Application Server 6.20! Kombination aus J2EE und ABAP Umgebung! Internet Communication Manager Verantwortlich für die Kommunikation zwischen dem WAS und den Clients.! APAB-Teil Basiert auf SAPs vorhandener Plattform. Existierende SAP Komponenten laufen darauf ab.! J2EE-Teil Basiert auf dem J2EE zertifizierten In-Q-My Applikationsserver. 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. Web Application Server J2EE ABAP! SAP Java Connector Ermöglicht Methodenaufrufe zwischen SAP Anwendungen und Java-Anwendungen. JCO ist bidirektional 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. Client Internet Communications Manager SAP JCo XML/SOAP RFC HTTP Connectivity

60 Cluster-Strategien verbreiteter Applikationsserver SAP Web Application Server 6.20 Cluster-Implementierung J2EE-Teil! Dispatcher bindet HTTP-Anfragen für Dauer einer Session an eine Maschine! shared global Architektur mit zusätzlichem Primären-Server! Name-Server hält globalen JNDI-Baum und Deployment-Informationen des Deployment-Descriptors (Name-Server weiß so welche Objekte auf welchem Server deployed sind)! im Gegensatz zur zentralen JNDI-Baum Implementierung werden Requests nicht immer über Name-Server verteilt. Ein Server richtet sich beispielsweise an den Name-Server wenn ein Bean-Loookup gemacht wird und die gesuchte Bean nicht auf dem aktuellen Server liegt. -> Server fragt bei Primären-Server nach wo das Objekt liegt und bekommt Objekt- Referenz zurück! NS verwaltet Liste der Object-Locks -> Transaktionssteuerung! zentraler JNDI-Baum wird persistent in interner Server-DB gespeichert! zwei Primäre-Server für Ausfallsicherheit! Lastverteilungs-Algorithmus gewichtetes Round-Robin -> Der Administrator kann relativ zur Größe der Maschinen die Verteilung festlegen

61 Cluster-Strategien verbreiteter Applikationsserver SAP Web Application Server 6.20 HTTPSession-Failover! Failover ist sessionbasiert -> fällt ein Server aus, wird der Client auf einen anderen Server im Cluster umgeleitet und muss Session noch mal starten! Basisinformationen über den Benutzer werden auf einem zweiten Primären Server repliziert Single Point Of Failure! keiner wenn Dispatcher manuell repliziert wurde Cluster-Topologie! Es werden alle gängigen Topologien unterstützt. Bei Benutzung des integrierten WebServers läuft Dispatcher vor dem WebServer und bei Benutzung eines externen WebServers hinter dem WebServer. Wartung und Administration! visuelle Schnittstelle und Command Line Interface für Verwaltung! Administrator kann unterschiedliche Dienste starten, anhalten und konfigurieren während der Server läuft (Konfiguration und Einrichten des Clusters, Security Management, Laufzeitverwaltung, Steuerung der Dienste und Manager, Verwaltung des Log-Systems

62 Cluster-Strategien verbreiteter Applikationsserver SAP Web Application Server - J2EE Server Clustering Client Load Balancer R R R SAP Message Server Server Process Dispatcher R... R Server Process R... Server Process Dispatcher R... R Server Process Host 1 Host n R R R R Database Server Persistent Data! Standalone: n:m Beziehung zwischen dem Dispatcher und Servern möglich! in der Integrierten Form läuft Kommunikation immer über den Dispatcher! Dispatcher auf Server 1 kommuniziert mit Dispatcher auf Server 2 und kann nicht direkt auf die Anwendungen die auf dem Server laufen zugreifen

63 Agenda! Cluster-Definition und Backround! Cluster-Arten und Implementierungen! Cluster und Failover-Dienste - HTTPSession-Failover - Single Point Of Failure! Cluster-Topologie! Wartung und Administration! Cluster-Strategien verbreiteter Applikationsserver! Setup und Verwaltung von Clustern! Ausblick und Zusammenfassung

64 Setup und Verwaltung von Clustern Cluster-Setup Entscheidungen die zu treffen sind 1. Lastverteilungs-Methode festgelegen 2. Server-Affinität berücksichtigen. 3. Deployment-Prozess für die Server-Instanzen definieren Lastverteilungsoptionen Es gibt zwei generelle Optionen für die Lastverteilung in einem Cluster:! DNS Round Robin! Hardware Load Balancers

65 Setup und Verwaltung von Clustern DNS Round Robin! logischer Name wird in IP-Adresse konvertiert! jeder logische Name kann jede IP-Adresse der Maschinen im Cluster zurückliefern Vorteil! einfaches und kostengünstiges Setup Nachteile! 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 -> die Session ist somit verlorenen! Ä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 -> Unterstützung für Hochverfügbarkeit eingeschränkt

66 Setup und Verwaltung von Clustern! Keine Garantie für gleichmäßige Lastverteilung 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 Bearbeitung verwendet -> alle Anfragen werden auf einen Server geleitet 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. Vorteile! Server-Affinität wenn kein SSL-benutzt wird! hohe Verfügbarkeit durch Failover und Monitoring! Messungen z.b der aktiven Sessions, Antwortzeiten etc.

67 Setup und Verwaltung von Clustern! gleichmäßig garantierte Verteilung über das Cluster Nachteile! Sehr hohe Kosten je nach Funktionen bis US Dollar! Komplexes Setup und Konfiguration Server-Affinität Problem: SSL werden ohne WebServer-Proxies benutzt 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. Lösung: Die Benutzung von WebServer-Proxies oder SSL-Accelerators. WebServer-Proxies Hardware Load Balancer verhält sich wie ein DNS Load Balancer. WebServer entschlüsselt SSL Request und übergibt diesen an den WebServer Proxy. Sobald der Proxy den entschlüsselten Request empfangen hat, kann er diesen parsen und über Cookie oder URL-Informationen die Anfrage an den Server schicken auf dem Benutzer-Session läuft.

68 Setup und Verwaltung von Clustern Vorteile durch WebServer-Proxies:! Server-Affinität mir SSL-Verschlüsselung! keine weitere Hardware außer dem Hardware Load Balancer nötig Nachteile durch WebServer-Proxies:! Hardware Load Balancer kann keine Messungen als Grundlage für Request-Weiterleitung benutzen! Benutzung von SSL bedeutet Beschränkung und zusätzliche Ausnutzung für den WebServer! WebServer-Proxy muss Server Affinität unterstützen SSL-Accelerators Der SSL-Accelerator sitzt vor Hardware Load Balancer und ermöglicht so dem Hardware Load Balancer entschlüsselte Informationen in Cookies und URLs zu lesen -> Hardware Load Balancer kann auch Messungen benutzen um Anfragen weiterzuleiten -> auf WebServer-Proxies kann verzichtet werden

69 Setup und Verwaltung von Clustern Vorteile der SSL-Accelerators sind:! flexibles Topologie-Layout (mit oder ohne WebServer-Proxy) das Server- Affinität und SSL ermöglicht! zentrale SSL Zertifikat Verwaltung in einer Box Nachteile der SSL-Accelerators sind:! hohe Kosten -> zusätzliche Hardware-Anschaffung notwendig -> für Hochverfügbarkeit braucht man zwei SSL-Accelerators! Höhere Komplexität bei Setup und Konfiguration

70 Setup und Verwaltung von Clustern Applikationsserver-Verteilung! Sollen einer oder mehrere Applikationsserver auf einer Maschine laufen?! Wie viele Knoten gibt es generell im Cluster? Anzahl Applikationsserver Instanzen auf einer Maschine ist abhängig von! Anzahl CPUs! CPU-Ausnutzung! vorhandenem Speicher einer Maschine Mehre Instanzen auf einer Box können eingesetzt werden! bei drei oder mehr CPUs die unter Last nicht voll ausgelastet sind! Heap-Size ist groß (i.d.r. 64MB maximal) -> schnellere Garbage Collection! Anwendung hat keine Input/Output Beschränkungen

71 Setup und Verwaltung von Clustern Bestimmen der optimalen Anzahl-Knoten (iterativ).! Anwendung optimieren! Einsatz von Last-Testing Software! weitere Knoten für Failover-Fall einplanen! Idealerweise Cluster bereits in Entwicklungsversion testen

72 Setup und Verwaltung von Clustern Konfigurationsbeispiel Sybase EA Server 1. Installation auf allen Serverknoten -> selber Benutzername und Kennwort auf allen Applikationsservern -> alle Benutzer auf jedem Server anlegen (Authentifizierung beim Betriebsystem) 2. Min. ein Name-Server definieren (jeder EA Server kann NS sein) 3. Jeder andere Server (member server) der im Cluster bootet verbindet sich mit dem NS und bindet seine Komponenten an ihn -> NS kennt Lokation aller Komponenten im Cluster, zentraler Verteiler -> führt Client einen Lookup auf ein Objekt aus, gibt NS eine Liste der Server zurück, die Instanz des Objekts halten! Anfragen von Java-Applets können nicht ohne weiteres verteilt werden und benötigt weitere Client-Konfiguration (Java Sandbox Modell verbietet Applets Sockets auf einem anderen Server zu öffnen von dem sie aufgerufen wurden) -> durch Lastverteilung greift Applet auf verschiedene Server zu -> Entwickler muss spezielle Zugriffserlaubnis für Applet vergeben

73 Setup und Verwaltung von Clustern 4. Primary-Server bestimmen -> kennt gesamte Cluster-Konfiguration und ist gleichzeitig NS 5. Zugriff auf alle Server im Cluster sicherstellen -> im Clusterverzeichnis wird neues Cluster mit logischem Namen angelegt 6. Eigenschaften des Clusters definieren -> jeder Server wird in Listbox eingetragen 7. Weitere Server im Cluster konfigurieren -> Cluster-Synchronisation stellt sicher, das jeder Server im Cluster die selben Komponenten, Konfiguration und Security- Informationen hat -> Synchronisation erfolgt automatisch, Primery-Server kopiert seine Konfiguration auf jeden Server im Cluster 8. Benutzername/Password für Connect eingegeben -> Auswahl aller Server die synchronisiert werden über Feld Servers -> Möglichkeit Server zu synchronisieren die nicht im Cluster hängen (Entwicklungs- und Testumgebung)

74 Setup und Verwaltung von Clustern 9. Nach der Synchronisation jeden Server neu starten -> beim hochfahren verbinden mit Primary-Server und überprüfen der Versionsnummer -> Primary-Server muss laufen wenn Member-Server hochfahren -> immer wenn sich Konfiguration des Primary Servers ändert Synchronisation durchführen Konfiguration für Ausfallsicherheit 1. Login auf jedem der als NS zu definierende Maschinen durch enablen der Servereigenschaft Name Server 2. Auf Primary-Server im Eigenschaftsdialog auf dem NS Tab die URL jeder NS Maschine hinzufügen 3. Cluster synchronisieren um Änderungen bekannt zu machen