Kostensenkung und Performancesteigerung von Java EE-Architekturen

Grid Computing – Die helle Seite der Macht
Kommentare

Java EE ist eine schöne Technik. Aus humankapitalistischer Sicht gibt es momentan keinen vergleichbaren Standard, der weltweit mit einer derartig großen Armada an Entwicklern, Architekten und Administratoren aufwartet. Doch Java EE wird auch von der dunklen Seite der Macht angezogen: der hardwarefressenden Seite. Die bisher wenigen bekannte Waffe der hellen Seite der Macht heißt Grid Computing.

In modernen rechenintensiven Arbeitsabläufen steigen die Anforderungen an die Hardware stetig. Gleichzeitig sollen sowohl die Investitions- als auch die Entwicklungskosten sinken. Um diesen Anforderungen gerecht zu werden, ist es wichtig, die vorhandene Hardware optimal auszunutzen, Prozesse sinnvoll über die einzelnen Hardwareressourcen zu verteilen und Leerlaufzeiten zu vermeiden. Für den Betrieb eines 24×7-Servers werden in Deutschland in der Regel drei Administratoren benötigt, die jeweils acht Stunden arbeiten. Das betreute System wird in der Regel nur während einem dieser Zeitfenster oder zwischen diesen Zeitfenstern verwendet. Denn wie viele Bankkunden nutzen das Onlineangebot ihres Bankhauses um drei Uhr morgens wirklich? Um diese Uhrzeit arbeiten andere Systeme, beispielsweise Buchungssysteme.

Aus TCO-Sicht bezahlt die IT-Abteilung jedoch 100 Prozent des Rechners, obwohl die Nutzer (das Business) das System über den Tag verteilt nur zu 20 bis 30 Prozent nutzen. Vorteilhafter wäre es daher, den Server während der Zeit, in der das Business ihn nicht in Anspruch nimmt, für andere Abteilungen zur Verfügung zu stellen. Braucht der eigentliche Nutzer diese Rechenressourcen wieder, muss das „Ausleihen“ der Ressourcen wieder rückgängig gemacht werden. Je höher die Betriebskosten eines einzelnen Servers sind, desto unwirtschaftlicher ist das Gesamtsystem.

Insbesondere in der Finanzdienstleistungsinformatik sind die Architekturen moderner Systeme für Peak-Nutzungen ausgelegt. Doch Peaks treten wie in Abbildung 1 dargestellt nur innerhalb eines kurzen, teils sehr kurzen Zeitfensters auf: Die Lastprofile der Applikationen 1, 2 und 3 zeigen deutlich, dass der Anteil der nicht genutzten CPU-Ressourcen deutlich höher ist als der der in Anspruch genommenen Rechnerkapazitäten.

Abb. 1: Darstellung des Grundproblems der Konsolidierung bei Peak-Auslastungen: Kein einziger der drei Application-Server-Links ist im Tagesdurchschnitt zu 50 Prozent ausgelastet. Alle drei Anwendungen lassen sich auf einem einzigen dieser Server (rechts) zusammenführen.
Eine Lösung bietet sich mit Grid Computing an

Das Problem, mit dem die IT primär konfrontiert wird, ist ein zweischneidiges Schwert: Zum einen muss die IT den Anforderungen ihrer Auftraggeber gerecht werden, indem sie Systeme zur Verfügung stellt, die den Bedarf für Peak-Belastungen gerecht werden. Zum anderen muss die IT die Kosten reduzieren. Die berechtigte Frage, die sich viele IT-Verantwortliche stellen, lautet nun, wie die gewünschten Peak-Belastungen zur Verfügung gestellt und die Kosten für die Anschaffung von Hardware und eventuell damit verbundene Kosten für Lizenzgebühren auf ein Minimum reduziert werden können.

Eine Lösung für dieses Optimierungsproblem liefert das oft missverstandene Grid Computing: Der Begriff Grid Computing umschreibt alle Verfahren, die die Rechenleistung vieler Computer des Low-Cost-Segments innerhalb eines Netzwerks derart zusammenfassen, dass rechenintensive Probleme mittels Datenaustausch und Parallelisierung zu deutlich geringeren Kosten als mit wenigen Rechnern des High-End-Segments gelöst werden können. Aus wettbewerbstechnischen Gründen sind Unternehmen branchenübergreifend mit diesen Problemstellungen konfrontiert. Nur drei Beispiele von vielen für hohe Ansprüche an Rechenkapazitäten sind die Finanzdienstleistungsinformatik (Risk Management), die Automobilindustrie (Crashtests) oder die Ölindustrie (Explorationsgeologie).

Vielen ist Grid Computing „am lebenden Objekt“ lediglich von seiner Teilnahme am Seti-Projekt oder von Forschungsprojekten der praktischen Universitätsinformatik bekannt. Doch ein Blick in die Praxis zeigt, dass Grid Computing lebt! Und das bereits seit geraumer Zeit!

Das Konzept, welches das Grid Computing zu einem Problemlöser der anfangs angesprochenen Problemstellung macht, ist in Abbildung 2 dargestellt: Die Mehrheit der deutschen Unternehmen ist in Fachbereiche aufgeteilt. Jeder Fachbereich hat einen Chef, dem von seinem Chef wiederum ein gewisses Budget jährlich zugesprochen wird. Ein Fachbereich teilt sich je nach Größe des Unternehmens wiederum in Abteilungen auf, die wiede­rum Abteilungen zusammenfassen. Jeder Abteilungsleiter bekommt von seinem Chef wiederum einen Anteil vom Budgetkuchen des Fachbereichs ab. Und aus diesem Budgetanteil werden die neu anzuschaffenden IT-Systeme finanziert.

Die Auftragsannahme übernimmt entweder die hauseigene IT oder ein externer IT-Dienstleister. Erfordert die zu erstellende Applikation beispielsweise eine Java EE-Vollausstattung (Webserver, Application Server, Datenbank etc.) werden hierfür Lizenzen neu beschafft, sofern sie nicht einem Pool vorhanden sind. Aus diesem Grund versuchen viele Architekten eines Java EE-Systems möglichst viele Applikationen auf einer Application-Server-Farm zu deployen. Dennoch gibt es zwei wesentliche Faktoren, die diese Form der Konsolidierung erschweren:

  • Zum einen besitzt jede der deployten Applikationen ein unterschiedliches Lastprofil. Der mit der Kundenseite vertraglich vereinbarte SLA schreibt jedoch ein spezifisches Antwortzeitverhalten vor. Werden nun auf einem Server zwei Applikationen deployt, deren Peaks zeitlich gleich auftreten und mit jedem Peak den jeweiligen Server extrem beanspruchen, wird sich das Antwortzeitverhalten einer der beiden Applikationen aus Anwendersicht negativ verlängern. Daher versuchen die Architekten, beide Applikationen auf unterschiedlichen Application-Servern zu deployen. Sofern der SLA der beiden Applikationen ein Failover Handling vorschreibt, müssen beide Applikationen auf jeweils zwei Application-Servern bereitgestellt werden.
  • Der zweite Faktor, der die Konsolidierung beeinflusst, ist die Tatsache, dass Java EE-Applikationen enorme Anforderungen an die Hardware stellen. Werden die Application Server z.B. auf High-End-Maschinen der bekannten Hardwarehersteller betrieben, steigen die Betriebskosten unter Umständen jährlich von fünf- auf sechsstellige Beträge. Hinzu kommt, dass insb. kommerzielle Application Server selbst sehr viele der auf einem Server zur Verfügung stehenden Ressourcen beanspruchen. Den deployten Applikationen steht dann meist „nur“ noch der Rest der verbleibenden Ressourcen zur Verfügung.

Und somit schließt sich der eingangs geöffnete Kreis: Da die Budgets vieler Projekte begrenzt sind, zeigen die ersten Prototypen der Java EE-Applikationen bereits, dass so manches Antwortzeitverhalten nur mit sehr viel Hardware realisiert werden kann. In der Finanzdienstleistungsinformatik spielen die Faktoren Business Continuity und Desaster Recovery eine wesentliche Rolle. Fällt einer der (teuren) Knoten aus, muss ein anderer (teurer) Knoten den Prozess wiederaufnehmen. Viele Ressourcen schlummern vor sich hin, während andere schwitzen. Und dies wiederum ist ein Grund dafür, dass viele die teuren IT-Systeme beklagen.

Vergleicht man nun die Systeme mit einem Produktionsbetrieb, bei dem versucht wird, mit möglichst wenigen Ressourcen möglichst viel zu produzieren, so kann die in Abbildung 2 dargestellte Betrachtungsweise der IT eines Unternehmens hieran angelehnt werden: Unternehmen sind in Säulen organisiert. Jede Säule ist eine Abteilung. Jede Abteilung besitzt eine gewisse Zahl an Serverressourcen. Der Ist-Stand bringt in den meisten Fällen hervor, dass die Ressourcen der einen Abteilung nicht von anderen Abteilungen in Anspruch genommen werden. Wäre es jedoch möglich die Ressourcen unternehmensweit von einer zentralen Stelle aus zu verwalten und automatisch an anfragende Applikationen ausgeborgt werden, können die Ressourcen insgesamt wesentlich reduziert werden. Das Ziel dieser Betrachtungsweise des Ausleihens und Borgens von Rechenressourcen auf Basis festgelegter Regeln liefert einen Grid.

Im Folgenden beschreibe ich nun zwei Stufen, in denen Grid Computing einen positiven Beitrag für die Architektur von Java EE-Landschaften leisten kann.

Abb. 2: In den einzelnen Abteilungen eines Unternehmens gibt es genug Server-Kapazitäten, die sich als flexible Ressource bewegen ließen. Das dafür notwendige Grid erfordert aber ein Ende des Denkens in „Abteilungsschachteln“ und erfordert den Blick aufs Ganze.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -