WebSphere Extended Deployment, Version 6.0.x     Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Möglichkeiten für die Verteilung der EJB-Workload bei Verwendung des Partitionierungs-Feature

[zos platforms] IIOP-gesteuerte (Internet Inter-ORB Protocol) Partitionen werden für z/OS nicht unterstützt.

Der Administrator kann dieses Verhalten nach dem Erststart der Bean anpassen, damit bestimmte betriebsbedingte Voraussetzungen eingehalten werden. Falls im obigen Beispiel die Partitionen Partition2 und Partition4 im Gegensatz zu den Partitionen Partition1 und Partition3 beispielsweise eine hohe Workload haben, könnte der Administrator die Partition2 in den anderen Anwendungsserver im Cluster verschieben. Der Programmierer müsste hier die Implementierung der Stateless Session Bean PSSB1 für die Ausführung einer Methode partitionUnloadEvent(String) und einer Methode partitionLoadEvent(String) codieren. Beim Verschieben der Partition, das vom Administrator eingeleitet wird, empfängt die Partition2 ein Entladeereignis. Alle Referenzen auf die Datenbank und andere J2EE-Anwendungsressourcen werden in allen Caching-Implementierungen bereinigt und entfernt. Anschließend wird die Partition2 umgehend im anderen Anwendungsserver reaktiviert und empfängt ein Ladeereignis, was dem Bean-Entwickler ermöglicht, den Status neu zu initialisieren und die Transaktionsverarbeitung vorzubereiten.

Mit dieser Technologie kann das Routing auf der Clientseite vollständig gesteuert werden, während der Administrator auf der Serverseite davon unabhängig den Zielort festlegen kann. Die Benutzer können zwar nicht direkt auf den HA Manager zugreifen, aber der HA Manager bietet dem Service WPF die Möglichkeit, einen ausgefallenen Server zu erkennen. Außerdem korreliert der HA Manager sehr schnell die Beziehung zwischen den Partitionen auf diesem Server und bestimmt, welche Aktionen ausgeführt werden müssen, um sicherzustellen, dass die Partitionen auf anderen Servern aktiviert werden.

Die folgende Abbildung zeigt ein einfaches Beispiel für das Failover einer Anwendung:

Die vorherige Abbildung zeigt, dass der Anwendungsserver mit den Partitionsendpunkten Partition2 und Partition4 ausfällt. Der HA Manager erkennt den Ausfall und aktiviert zwei unterschiedliche Instanzen von Partition2 und Partition4 auf dem anderen Anwendungsserver. Dies ist nur ein Wiederherstellungsszenario für Anwendungsserver von vielen. Weitere Szenarios sind das Stoppen eines Anwendungsservers für Wartungsarbeiten; das Auftreten eines Ereignisses in einer Netzpartition oder andere Situationen, in denen physische Arbeiten oder Verwaltungsaufgaben durchgeführt werden müssen. In diesem Fall fallen Partition2 und Partition4 für kurze Zeit aus; aber die restlichen Partitionen funktionieren weiter, als wäre nichts passiert. Außerdem können Partition2 und Partition4 während der Wiederherstellung eine Optimierungsstufe implementieren, da diese Implementierung vom Ereignis für die Reaktivierung der Partitionen empfohlen wurde, und prüfen, ob weitere Probleme vorliegen, die während der Transaktionswiederherstellung behoben werden müssen.

Die Verarbeitung am Endpunkt kann je nach verwendeter IT-Architektur auf unterschiedliche Arten durchgeführt werden. Wenn Sie sich dazu entschließen, nur einige zuverlässige und einfach zu verwaltende Server in Ihren Clustern zu verwenden, können einem Anwendungsserver mehr Partitionsendpunkte (LPAR) zugeordnet werden. Falls Sie verteilte Cluster oder Blade-Center verwenden, können Sie eine Partition auf ein anderes eigenständiges System, das gar nicht verwendet wird oder nur wenig Workload hat, verschieben oder andere durch Kollokation zusammengefasste Partitionen, die gar nicht nicht verwendet werden oder keine hohe Workload haben, an eine andere Stelle im Cluster verschieben. Dies gibt dem Anwendungsserver in der stark beanspruchten Partition die Möglichkeit, die Workload besser zu bewältigen. Beide Optionen geben erfahrenen IT-Mitarbeitern eine große Flexibilität im Hinblick auf die Bewältigung betriebsbedingter Anforderungen. Durch die Zusammenführung der vorhandenen Funktionalität mit den Funktionen des WPF-Framework und der zugrunde liegenden HA-Manager-Technologie ist WebSphere Extended Deployment eine leistungsstarke Cluster-Lösung mit einer hohen Leistung und umfangreichen Verwaltungsfunktionen für die Bewältigung typischer Herausforderungen in einem Cluster.

Mit seinen einzigartigen Funktionen bietet sich WPF als Clientanforderungsmodell an, weil der Client explizit auswählen kann, wohin eine Anforderung weitergeleitet werden soll. Der Endpunkt ist nicht nur eindeutig adressierbar, sondern auch hoch verfügbar. Wenn der Anwendungsserver mit dem Partitionsendpunkt ausfällt, erkennt der mit WebSphere Extended Deployment bereitgestellte HA Manager den Ausfall und aktiviert die Partitionsinstanz in einem anderen Anwendungsserver des Cluster. Die vorhandenen Funktionen werden dabei nicht beeinträchtigt.




Related concepts
Partitionierung der EJB-Workload
Einschränkungen in WPF

Related information
Programmiermuster in WebSphere Extended Deployment for z/OS Version 6.0.1

Konzeptartikel    

Nutzungsbedingungen | Feedback Letzte Aktualisierung: Mar 23, 2006 9:57:42 AM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/WPF51/cwpfejbadmin_pdf.html

© Copyright IBM 2005, 2006. Alle Rechte vorbehalten.
Dieses Information Center beruht auf der Eclipse-Technologie. (http://www.eclipse.org)