Grid Computing – Die helle Seite der Macht
Kommentare

Hardwarereduktion durch Grid Computing im Java EE-UHardwarereduktion durch Grid Computing im Java EE-Umfeld (Stufe 1)mfeld (Stufe 1)
Eine typische Java EE-Architektur besteht aus Webservern, Application-Servern

Hardwarereduktion durch Grid Computing im Java EE-UHardwarereduktion durch Grid Computing im Java EE-Umfeld (Stufe 1)mfeld (Stufe 1)

Eine typische Java EE-Architektur besteht aus Webservern, Application-Servern und Datenbank-Servern. Die vorgeschlagene Architektur, die Java EE um das Thema Grid Computing erweitert, ist in Abbildung 3 abgedruckt: Dargestellt werden Nutzer zweier verschiedener Abteilungen, deren Applikationen auf unterschiedlichen Servern betrieben werden. Ohne einen gegenseitigen Ressourcenverleih wäre die Infrastruktur der Applikationen sehr starr aufgebaut. Mit Grid Computing lassen sich keine JSP-Codes, EJB-Aufrufe oder Datenbank-Abfragen spontan auf andere Server verteilen. Webapplikationen, EJBs sowie Datenbank-Logik erfordern spezielle Container (Tomcat, JBoss, Oracle RAC o.Ä.), die ihre Lebenszyklen steuern und kontrollieren. Wird beispielsweise auf den Ressourcen der Gruppe 2/Abteilung B ein WebSphere Application Server betrieben, der aufgrund seines Lastprofils nicht benötigt wird, kann dieser Server automatisch heruntergefahren werden, wenn die WebLogic-Farm der Ressourcengruppe 2/Abteilung A überlastet ist. In diesem Fall wird dieselbe Ressource verwendet, um einen WebLogic Server anzustarten und in die existierende Farm der Abteilung A einzugliedern. Analog wird auf allen übrigen dargestellten Layern verfahren.

In den einzelnen Unternehmen schlummern jedoch noch weitaus mehr Ressourcen vor sich hin, als dies oft offensichtlich ist. Alleine durch die Aufteilung in Entwickler-, Test- und Produktivsysteme sind indentische Ressourcen in großer Zahl vorhanden. Gerade die Entwickler- und Testsysteme weisen Lastprofile auf, die über längere Zeiträume hinweg keine Ausschläge zeigen. Werden diese Ressourcen den Produktivsystemen „spontan“ und bei Bedarf zur Verfügung gestellt, lässt sich so manche Neuanschaffung aufschieben.

Eine solche Verfahrensweise erfordert jedoch ein Umdenken: weg von den „starren“ Ressourcen hin zu „flexiblen“, service­orientierten Ressourcen. Um dies jedoch gewährleisten zu können, wird eine Infrastruktur benötigt, die regelbasiert gesteuert ist, betriebssystemübergreifend lauffähig ist, zuverlässig ist und den Ressourcenbedarf selbstständig erkennt und auf freie Ressourcen verteilt. Eine Infrastruktur, die auf derartige Bedarfe „just in time“ (JIT) reagieren kann, agiert serviceorientiert.

Eine serviceorientierte Infrastruktur (kurz SOI) muss analog zu einer serviceorientierten Architektur orchestriert werden. Da ein Grid mehrere einzelne Ressourcen zu einer großen, virtuellen Ressource verbindet, müssen alle diese Ressourcen überwacht, gesteuert und koordiniert werden. In Anlehnung an eine SOA, die das Wort Orchestrierung hervorgebracht hat, übernimmt im Fall eines unternehmensweiten Grids ein sog. Enterprise Grid Orchestrator (EGO) die intelligente Kontrolle der Infrastruktur, sodass diese serviceorientiert agieren kann.

Indem die Administratoren definieren, wie viele Ressourcen welchen Typs von einer Abteilung an die andere ausgeliehen werden und unter welchen Umständen diese Ausleihe beendet werden kann, kann ein EGO die Ressourcen gezielt nach Bedarf zuweisen. Das Resultat ist eine deutliche Reduktion der Hardware einer Java EE-Architektur, da zeitversetzt auftretende Peaks auf unterschiedlichen Layern durch Ressourcengruppen anderer Applikationen abgefangen werden. Die Ausleihe kann sowohl horizontal als auch vertikal erfolgen.

Abb. 3: Die neue Java EE-Architektur mit Grid-Computing-Einflüssen. Durch eine Virtualisierung der Application Server kann die Anzahl derselbigen nachweislich reduziert werden. Kombiniert wird dieser Effekt durch die Verteilung der Geschäftslogik auf dem echten Grid, welches als eine Art Überdruckventil fungiert.
Performancesteigerung durch Grid Computing im Java EE-Umfeld (Stufe 2)

Doch Grid Computing im Java EE-Umfeld kann noch mehr leisten: Wie zuvor bereits erwähnt wurde, sind manche Application Server wahre „Ressourcenfresser“. Dennoch repräsentieren sie den wichtigsten Bestandteil der Gesamtarchitektur, indem sie die Geschäftlogik möglichst interoperabel via SOAP, IIOP etc. dem vorgelagerten Layer in Form von Schnittstellen anbieten. Da die Ressourcenansprüche der Java EE Server nicht wesentlich reduziert werden können, kann jedes weitere Deployment neuer Geschäftlogik in Form von EJBs auf der Application-Server-Farm mehr Hardware bedeuten. Handelt es sich bei dieser Hardware um Maschinen des High-End-Preissegments, treibt dies die Kosten neu zu implementierender Geschäftslogik in die Höhe.

Dass die Ressourcenanforderungen von Java EE-Application-Servern ein Problem darstellen, zeigen die Bemühungen einiger Entwicklerteams im Rahmen der sog. Lightweight Container. Statt mit einem LKW den Einkauf im Supermarkt zu erledigen, kann man je nach Bedarf auch einen Kleinwagen verwenden. Um die Last von der (teuren) Application-Server-Farm zu nehmen, empfiehlt sich, große Teile der Last an einen günstigeren Layer weiterzureichen. Dieser wird in der Regel mit vielen Maschinen des Low-End-Preissegments betrieben.

In Abbildung 3 ist dieser Layer mit „Job Execution Servers“ gekennzeichnet. Abbildung 4 detailliert diesen Layer: Die EJBs senden Aufträge für die Ausführung von Geschäftslogik in Form einzelner Jobs an einen intelligenten Verteilungsmechanismus – der im Folgenden als Job Schedulerbezeichnet wird. Der Job Scheduler muss mit dem EGO kommunizieren und wissen, wie stark jede Ressource beansprucht ist. Im Gegensatz zu einem Round-Robin-Verfahren muss der Job Scheduler eine echte Grid-Logik zur Verfügung stellen. Welche Geschäftslogik von den einzelnen Jobs ausgeführt wird, ist nicht vorgeschrieben. Es kann sich um Datenbank-Zugriffe handeln oder um algorithmische Berechnungen, wie sie im Risk Management verwendet werden.

Abb. 4: Zoom in den neu eingezogenen Grid Layer, der die EJB-Jobs intelligent und lastbezogen verteilt.
Realisierungsbeispiel

Das zuvor beschriebene Konzept der Hardwarereduktion und Performancesteigerung durch Grid Computing wurde zuletzt bei der zweitgrößten amerikanischen Bank erfolgreich umgesetzt. Am Beispiel der als „Stufe 2“ bezeichneten Optimierung der Java EE-Landschaften wird im Folgenden erläutert, wie das in dem genannten Projekt eingesetzte Produkt Platform Symphony als Job Scheduler zum Einsatz kommen kann.

Symphony stellt ein SDK zur Verfügung, mit dem programmiersprachen­übergreifend Geschäftslogik implementiert werden kann. Das Prinzip der Implementierung ist relativ einfach und wird im Folgenden an einem Beispiel erläutert: Angenommen, die Entwickler eines weltweit agierenden Konzerns müssen eine Funktion implementieren, die die Gewinne unterschiedlicher Regionen (Europa, Asien etc.) berechnet. Getreu dem EJB-Standard könnten die Entwickler die Geschäftslogik in Form der zustandslosen Session Bean BalanceSheetSer­viceBean implementieren, welche aus Performancegründen direkt die Datenbank kontaktiert und SQL-Befehle ausführt. Alternativ könnten sie auch Hibernate verwenden, um programmiererfreundlicheren Code zu produzieren. Je mehr Nutzer diese Funktion jedoch gleichzeitig aufrufen, desto größer wird die Last auf dem Application Server Layer. Um die Last von diesem Layer wegzunehmen und sie an den nachfolgenden Grid Layer weiterzureichen, müssen die Jobs, die für die Last verantwortlich sind, an Symphony übertragen werden. In welcher Form der Job letztendlich übertragen wird, ist eine Performancefrage. Ist die Netzwerklast zu hoch (unter Umständen ab 3.000 Servern), empfiehlt sich, lediglich die Jobparameter wie im nachfolgenden Beispiel zu übertragen.

Ein Job (Listing 1) enthält diejenige Geschäftslogik, die auf dem Grid verteilt werden soll. Ein Job muss in einem JobContainer ausgeführt werden. Ein Job wird über JobParameter initialisiert. Wird ein Job durch den Aufruf der execute-Methode ausgeführt, wird das Ergebnis in Form eines JobResult an den Auftraggeber zurückgesendet. Im Fehlerfall wird eine RemoteException geworfen.

Listing 1
---------------------------------------------------------------------
package grid.jobs;

import java.io.Serializable;
import java.rmi.RemoteException;

public interface Job extends Serializable {

     JobResult execute(JobContainer container) throws RemoteException;
     void setJobParameter(JobParameter params);
     JobParameter getJobParameter();
     
}
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -