Heutige Geschäftsprozesse machen einen viel intensiveren Gebrauch von Hardware, als dies noch vor einigen Jahren der Fall war: Immer mehr Daten werden verarbeitet und gespeichert. Der dadurch steigenden Ressourcenbeanspruchung steht jedoch die Forderung nach sinkenden Investitions- und Entwicklungskosten gegenüber. Um dieser Anforderung gerecht zu werden, ist es wichtig, die vorhandene Hardware optimal auszunutzen, Prozesse sinnvoll über die einzelnen Hardwareressourcen zu verteilen und Leerlaufzeiten zu vermeiden.

Nichtstuer neben Malochern

Der Betrieb eines Servers rund um die Uhr erfordert in der Regel täglich drei Administratorschichten. Das von ihnen betreute System wird allerdings nur in einem Teil ihrer Arbeitszeit voll verwendet. So stehen die Server hinter einem Online-Portal nachts um drei Uhr zur vollen Verfügung, denn sie werden nur von wenigen Nachtaktiven in Anspruch genommen. Wie viele Bankkunden nutzen das Online-Angebot ihres Bankhauses nachts wirklich? Diese Systeme haben jetzt wenig bis gar nichts zu tun. Während ihre Arbeitsbelastung gegen Null geht, "schwitzen" andere Systeme, die nachts sehr viel beansprucht werden - beispielsweise Buchungssysteme oder Number-Cruncher von Banken und Automobilherstellern.

Vorsorge schafft Luxus

Wenn Fluggesellschaften viele Dienste über das Internet anbieten, kann eine Marketing-Aktion mit vergünstigten Flügen die Rechner extrem beanspruchen. Während dieser Zeit schwitzen nicht nur die Rechner, sondern auch die IT-Verantwortlichen. Denn falls ein Systemteil ausfällt, kaskadiert das Problem nicht selten schnell. Backup-Systeme müssen für diesen Fall parat stehen. Normalisiert sich der Zugriff auf die Portale wieder, sind die Rechner erneut unterfordert.

Systeme von Investment-Banken oder Automobilherstellern, die weniger mit dem Endkunden zu tun haben als mehr mit aufwändigen Berechnungen wie "Monte-Carlo"-Risikoanalysen beziehungsweise Crash-Simulationen, arbeiten nur dann, wenn die Analysten oder die Ingenieure sie genau für diese Aufgaben brauchen. Doch kontinuierlich wird nie gerechnet, schon gar nicht mit hoher Auslastung. Die teuren Rechner sind während eines Großteils der Zeit weitgehend inaktiv. Im selben Unternehmen gibt es jedoch andere Abteilungen, die genau zu der Zeit, in der diese Server nicht arbeiten, ihre eigenen Systeme beispielsweise für Monatsabschlüsse bis zum Anschlag auslasten und gerne mehr Rechenkapazität hätten. Allerdings fehlt diesen Abteilungen meist das nötige Budget, um sich entsprechend mehr IT-Leistung zu besorgen. Und zu anderen Zeiten nutzen auch sie ihre Rechnerkapazitäten nicht aus.

Dies hat zur Folge, dass Unternehmensabteilungen 100 Prozent einer Rechnerumgebung bezahlen, obwohl sie das System über den Tag verteilt nur zu 20 bis 30 Prozent nutzen. Je höher die Betriebskosten eines einzelnen Servers sind, desto unwirtschaftlicher ist das Gesamtsystem. Aus diesem Grund ist es vorteilhafter, wenn ein Server während der Zeit, in der ihn eine Abteilung nicht in Anspruch nimmt, anderen Abteilungen für andere Applikationen zur Verfügung gestellt wird. Ein Rechner ist eine Ressource und sollte sich von der Abteilung, die momentan einen erhöhten Ressourcenbedarf hat, "ausborgen" lassen. Sobald derjenige, der seine Ressource verliehen hat, sie wieder braucht, muss das Ausleihen rückgängig gemacht werden.

In sehr vielen Unternehmen, insbesondere aber in der Finanzdienstleistungsinformatik, sind die IT-Systeme auf "Peak"-Nutzung ausgelegt. Doch Peaks treten nur innerhalb eines kurzen, manchmal nur sehr kurzen Zeitfensters auf (siehe Grafik "Lastprofile"). Die Lastprofile der verschiedenen Applikationen zeigen, dass der Anteil der nicht genutzten CPU-Ressourcen deutlich höher ist als die in Anspruch genommene Rechnerkapazität. Es ist eine berechtigte Frage, wie sich zum einen die gewünschten Peak-Anforderungen bewältigen lassen und zum anderen die Kosten für die Anschaffung von Hardware auf ein Minimum reduzieren werden.

Grenzen der Virtualisierung

Lösungen für dieses Optimierungsproblem bieten sich mit On-demand Computing oder mit Virtualisierung an. Ersteres bedeutet, dass eine Rechnerkapazität im Moment der Anforderung sehr zeitnah bereitgestellt wird. On-demand-Systeme müssen flexibel sein, häufig Echtzeitforderungen erfüllen und vollen Zugriff auf die zur Leistungserbringung nötigen Ressourcen bieten. Sie werden in der Regel bei speziellen Dienstleistern gemietet und sind nicht unbedingt mehr physischer Bestandteil des eigenen Rechenzentrums. Wie viel Dienstleistung in Anspruch genommen wird, entscheidet in der Regel jede Unternehmensabteilung nach dem eigenen Budgetrahmen selbst.

Virtualisierung hingegen teilt eine einzelne, physische Ressource in mehrere virtuelle, nicht-physische ein. Jedoch ist die Zuteilung der virtuellen Ressourcen eine aufwändige manuelle Tätigkeit. Je größer die virtuellen Umgebungen werden, desto schneller nimmt die Administrationsarbeit zu, weil es erforderlich ist, jeden einzelnen virtuellen Server zu steuern. Daran ändern auch die heute verfügbaren Administrations-Tools für virtuelle Umgebungen letztlich nicht viel. In der Folge ist die Mehrheit der heute im produktiven Bereich existenten virtuellen Ressour- cen wieder fix konfiguriert. Die Wirkung der Virtualisierung schmilzt in großen Umgebungen dahin, und sie endet üblicherweise an den Grenzen der IT einer Unternehmensabteilung.

Jenseits aller Grenzen

Eine Lösung für dieses Optimierungsproblem liefert das oft missverstandene Grid Computing: Dieser Begriff umschreibt alle Verfahren, welche die Rechenleistung vieler Low-Cost-Computer in einem Netzwerk so zusammenfassen, dass sich rechenintensive Aufgaben mittels Datenaustausch und Parallelisierung zu deutlich geringeren Kosten als mit wenigen Highend-Rechnern erfüllen lassen. Ein Grid geht dabei a priori über die Grenzen von Unternehmensabteilungen hinaus.

Grids setzen daher eine andere Denk- und Herangehensweise voraus, als man sie in Unternehmen normalerweise gewohnt ist. Unternehmen sind in Säulen organisiert. Jede Säule ist eine Abteilung. Jede Abteilung besitzt eine gewisse Zahl an Server-Ressourcen. Dieser Aufbau führt in den meisten Fällen dazu, dass die Ressourcen einer Abteilung nicht von anderen Abteilungen in Anspruch genommen werden. Löst man diese "Verdrahtung" zwischen Ressourcen und Abteilungen auf, kann eine Konsolidierung mit weniger Hardware erfolgen.

Manch ein Administrator, der Lastprofile in den Rechenzentren betrachtet, würde gerne dynamisch Ressourcen zwischen einzelnen Applikationen hin- und herschieben. Doch manuell ist dies nicht handhab- und bezahlbar. Und ein Administrator kann nicht so schnell reagieren, wie sich die Leistungsanforderungen verschiedener Anwendungen verändern.

Ein Grid schließt Systeme - in der einfachsten Ausprägung identische nach der x86-Architektur - verschiedener Abteilungen als eine Ressourcenbatterie zusammen. Diese Hardware ist vorhanden; nur ihre ungenutzte Rechen-Power nimmt ein Grid in Dienst.

Aus technischer Sicht gibt es nur wenige Hürden. Um jedoch eine Server-Ressource, die zuvor ausschließlich beispielsweise einem SAP-System zur Verfügung stand, während der "Ruhephase" für eine J2EE-Applikationslandschaft zu verwenden, müssen erst die organisatorischen Hürden genommen werden.

Die Kommandozentrale

Bei der weiteren Umsetzung steht eine Aufgabe im Vordergrund: Ein Grid benötigt eine Infrastruktur, die regelbasierend gesteuert, Betriebssystem-übergreifend lauffähig und zuverlässig ist sowie die Ressourcenbedarfe selbständig erkennt und auf freie Ressourcen verteilt. Eine Infrastruktur, die das kann, agiert Service-orientiert.

Eine Service-orientierte Infrastruktur muss 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 die Service-orientierten Architekturen, die das Wort Orchestrierung hervorgebracht haben, übernimmt ein "Grid Orchestrator" die intelligente Kontrolle der Infrastruktur, so dass diese Service-orientiert agieren kann.

Automatisch Kosten drücken

Ein Grid Orchestrator ist die Grundlage für jegliche Konsolidierung und intelligente Verteilung von Lasten auf Ressourcen (siehe Grafik "Leihen und Verleihen"): Theoretisch und praktisch können auf einer Ressource unterschiedliche Applikationen zeitversetzt und bedarfsabhängig laufen. Hierzu muss ein Grid Orchestrator den Administratoren ermöglichen, definieren zu können, wie viele Ressourcen welchen Typs von einer Applikation an eine andere ausgeliehen werden und unter welchen Umständen diese Ausleihe beendet werden kann.

Der Grid Orchestrator bildet somit die Grundlage, welche die Flexibilität des Grid ausmacht. Auf Basis der definierten Regeln können somit die Ressourcenansprüche einzelner Applikationen kostengünstig und automatisch gedeckt werden. Das Resultat ist eine deutliche Reduktion der Hardware, da zeitversetzt auftretende Peaks durch Ressourcengruppen anderer Applikationen abgefangen werden.

Während Service-orientierte Architekturen noch implementiert werden müssen - und sie auf Grund der notwendigen großen Investitionen vielerorts auf unbestimmte Zeit verschoben werden - kann eine Service-orientierte Infrastruktur bereits heute die IT-Kosten drastisch senken. Mit einem Grid Orchestrator ist alles möglich: Das Spektrum beginnt bei der gewohnten fixen Bindung zwischen Ressource und Anwendung, was für bestimmte IT-Szenarien durchaus angemessen sein kann. Es reicht darüber hinaus bis hin zu einer äußerst flexiblen Bereitstellung der irgendwo im Unternehmen verfügbaren Computerpower nach Bedarf. (ls)