Die Meta Group will ermittelt haben, dass heutzutage die Server im Durchschnitt nur zu 20 Prozent oder weniger ausgelastet sind. Die Ursache ist schnell ausgemacht: Sehr viele von ihnen sind bestimmten Anwendungen fest zugeordnet. Dabei müssen sie auf die Spitzenanforderung der Applikationen ausgelegt sein, selbst wenn diese nur an zwei Tagen im Monat benötigt wird. Im Nebeneffekt treibt es auch noch die Lizenzkosten in die Höhe, für eine Anwendung beispielsweise sechs statt der durchschnittlich erforderlichen zwei Prozessoren vorzuhalten. Diese teure Verschwendung ist kaum zu rechtfertigen.
Kostengünstige Alternativen
Deswegen müssen alternative Konzepte her. Der Ansatz besteht in der Maxime, die Server-Ressourcen schnell nach dem jeweiligen Bedarf den Aufgaben zuzuordnen. Damit wandelt sich eine systemgebundene IT zu einer serviceorientierten. In ihr sind die Ressourcen zu einem Pool gebündelt, aus dem sich die Anwendungen nach Bedarf bedienen. Der Begriff dafür lautet Virtualisierung. Die hat wiederum zwei Anforderungen zur Folge: Integration, denn die Systeme müssen nahtlos zusammenarbeiten, und Automatisierung; denn es würde Administratoren überfordern, sollten sie den Anwendungen die Ressourcen manuell zuordnen müssen.
Blades entsprechen diesen Anforderungen buchstäblich auf den ersten Blick. Sie sind nichts anderes als ein geclusterter Pool von Servern. Wird mehr Rechenleistung benötigt, kann man sehr einfach - sogar die Verkabelung ist kein Problem mehr - weitere Blades hinzufügen. Dieses auch als Scale-out bezeichnete Verfahren erfordert weit weniger Zeit und Geld als die Scale-up-Strategie, bei der größere Rechner installiert werden. Außerdem nutzt der Blade-Pool die Netzinfrastruktur und darüber hinaus die Speicher wie weitere Pools. Auch hier lässt sich eine höhere Auslastung erzielen.
Die daraus resultierenden geringeren Gesamtkosten für Hardware in Blade-Umgebungen sind noch nicht einmal das beste Argument. Tatsächlich sind Blades in der Regel - nur Dell ist unter den großen Anbietern eine Ausnahme - etwas teurer als vergleichbare Stand-alone-Server. Erst wenn man Kosten für Verkabelung, Stromverbrauch, Raumbedarf etc. einrechnet, werden die Kompaktrechner günstiger. Doch die Hardware verursacht nur 20 Prozent der Gesamtkosten.
Kostenfaktor Administration
Der größte Teil der IT-Ausgaben fällt für den täglichen Betrieb an. Laut Gartner-Analyst Andy Butler verbraucht die reine Aufrechterhaltung der Systemaktivität drei Viertel der Arbeitszeit der Mitarbeiter im Rechenzentrum. Die Zeit ließe sich nutzen für die Verbesserung der Sicherheit oder Neuentwicklungen. Blades schaffen hier schon eine gewisse Entlastung, weil der Verkabelungsaufwand sinkt, sich neue Server mithin schneller integrieren lassen und die redundante Auslegung ausfallträchtiger Komponenten samt ihrer Austauschbarkeit im laufenden Betrieb die Verfügbarkeit der Systeme erhöht. Doch das ist längst nicht alles.
Die Flexibilität der Blade-Hardware hat ähnlich variable Formen ihrer Nutzung initiiert. Dabei macht es eigentlich keinen Unterschied, ob man 100 klassische Rack-Server ("Pizzaboxen") oder 100 Blades administrieren muss. Doch mit dem Erscheinen der Blades wurde die Zeit reif für Virtualisierung, Integration und Automatisierung. Inzwischen gibt es die erforderlichen ausgefeilten Programme zum Management der Server-Hundertschaften in den Racks.
Ein Dokument von Fujitsu-Siemens Computers (FSC) führt aus: "Im Schnitt gehen die Analysten davon aus, dass die Administrationskosten von Blades gegenüber herkömmlichen Systemen etwa um 50 Prozent sinken." Und der Administrationsaufwand ist mit Abstand der größte Kostenfaktor im Rechenzentrums-Betrieb. Wenn die Vereinfachung der Systemverwaltung diesen reduzieren könnte, hätten Blade-Protagonisten ein starkes Argument zur Hand.
In der Tat lässt sich die Administration der Blades inzwischen weitgehend über mehrere Stufen automatisieren - und zwar sehr viel weiter, als es bei klassischen Rack-Systemen gang und gäbe ist. Es beginnt bei der Konfiguration und Installation neuer Blades. Mit wenigen Mausklicks an einer zentralen Konsole, also remote auch aus anderen Räumen, erhalten sie aus dem angeschlossenen Speichersystem (SAN oder NAS) ein Image, bestehend aus Betriebssystem und gewünschten Anwendungen. Die Administrations-Tools versehen sie automatisch mit IP-Adressen, aktivieren die vorhandene Netzinfrastruktur etc. Der Boot-Vorgang startet automatisch, innerhalb weniger Minuten steht ein neues Blade bereit. Dabei wird auch gleich geprüft, ob seine Komponenten, beispielsweise die Lüfter, mit voller Kraft arbeiten können. Man hört es am Lärm der startenden Ventilatoren.
Darauf folgt die Zuordnung der Blades zu Tasks oder Rechnergruppen per Benutzeroberfläche. Die Datenbank oder ein SAP-Modul brauchen mehr Rechenpower? Drag and drop one more blade! Dabei wird grafisch dargestellt, wie verschiedene Applikationen die Einzel-Server eines Racks belegen. Man kann die Blade-Zuordnungen auch ändern. So ist es sinnvoll, Blades mit zwei oder vier CPUs der Datenbank zuzuordnen, während Internet-orientierte Tasks oder File-and-Print-Server besser auf Ein-Prozessor-Servern laufen. In jede Server-Gruppe und danach in jedes Einzel-Blade kann sich der Administrator hineinklicken, um beispielsweise Informationen über die Auslastung zu bekommen.
Tool warnt bei Problemen
Doch das hat er in der Regel gar nicht nötig. Sein Administrations-Tool wird ihn warnen, wenn Blades oder ganze Gruppen zu heiß werden, weil sie auf Höchstleistung laufen. Und zwar grafisch zum Beispiel über Ampelanzeigen, weil klassische Tabellen bei dermaßen vielen Servern nicht zu überblicken sind. Bestimmte Informationen erscheinen immer, ohne dass ein Systemverantwortlicher zuvor einen Finger hätte bewegen müssen: Ausfall ganzer Server, Ausfall von Blade-Komponenten, drohende Überhitzung und RAM-Überlastung sind einige Beispiele. Den größten Teil dieser Informationen liefern Sensoren auf den Blades nach dem Standard Intelligent Platform Management Interface (IPMI). Leuchtdioden weisen den Weg zu problematischen Hardwarekomponenten.
Für den nächsten Schritt der Automatisierung sind Vorarbeiten erforderlich. Die Verfügbarkeit der Blades für ihre Aufgaben wird ja, selbst wenn sie aktuell nicht gebraucht werden, zum Beispiel durch Pings geprüft. Doch ihre Fähigkeit, die Anwendungen und Anwender zu bedienen, hat Grenzwerte. Man muss einmal maximale Antwortzeiten festgelegt haben - und einen Schwellwert, ab dem eine Warnung erfolgt. Dann kann der Administrator weitere Blades zuschalten oder die Jobs umgruppieren.
Den Eingriff hat er nicht nötig, wenn sein Management-Tool gut ist und er es nach "Policies" eingerichtet hat. Dann nämlich wird ab dem Erreichen eines Schwellwertes automatisch ein Blade aus dem Pool inaktiver Reserve-Server mit dem erforderlichen Image hochgefahren und integriert, sei es für einen einzelnen Dienst oder in einer Rechnergruppe. Das Ganze funktioniert natürlich auch umgekehrt: Unterhalb bestimmter Schwellwerte oder Antwortzeiten werden Blades automatisch wieder "in den einstweiligen Ruhestand versetzt". So spart man Strom für den Rechner und die Kühlung.
Der Weg zur Virtualisierung
Jetzt kommt der nächste Schritt. Üblicherweise werden Rechner vorgehalten, um Aufgaben wie die Bilanzierung oder Lohn- und Gehaltsabrechnung am Monatsende in akzeptabler Zeit erledigen zu können. Mit guten Blade-Admin-Tools lassen sich da einige Server sparen. Denn es ist möglich, ihnen zu bestimmten Wochen- oder Monatstagen bestimmte Aufgaben zuzuweisen. Sie können dann automatisch zuerst nach freier Rechenpower suchen und danach notfalls weitere Blades aktivieren. Es geht sogar noch feiner: Die Zuordnung der Rechnerleistung lässt sich auch über den Tag verteilt einrichten, um etwa das Abrufen von E-Mails zu Arbeitsbeginn nicht in die Länge zu ziehen.
Eine weiter gehende Möglichkeit ist nicht einmal neu: Die komplette Hardwarebasis kann quasi Versteck spielen. Virtualisierungs-Tools wie das von VMware stellen sich der Anwendung gegenüber als exklusiver Rechner dar, verteilen die erforderliche Rechenleistung aber auf alle Hardware, die gerade - und sei es nur partiell - zur Verfügung steht. Ein Blade-Rack ist damit exakt das, was es eigentlich sein soll: ein Cluster frei verwendbarer Rechnerknoten.
Ein weiterer Schritt besteht darin, die Blade-Racks in ein unternehmensweites Konzept der Systemadministration einzubinden. Dies ist noch das geringste Problem. Alle Administrations-Tools für Blades bieten Schnittstellen zu umfassenderen Management-Lösungen wie CA Unicenter, IBMs Tivoli, HP Openview etc.
Der Freiheit sind bei Blades allerdings Grenzen durch die Softwarelizenzierung gesetzt. Wenn wie bei SAP nur die Zahl der User zählt, ist das kein Problem. Oracle aber rechnet nach einer Formel ab, in der die genutzte Prozessor-Power eine entscheidende Größe bildet. In einem sich ständig ändernden Nutzungsmodell, wie es Blades ermöglichen, wird die Protokollierung der Leistung zu einem Problem für das "Billing". In Mainframe-Umgebungen sorgen dafür Management-Tools. Die Blade-Administrationssoftware ist durch die Bank noch nicht so weit.
Lizenzmodelle anpassen!
Microsoft schließlich hat die Virtualisierungskapazität von Blades in seinem Lizenzmodell überhaupt noch nicht berücksichtigt. Für die Redmonder ist ein Server, der einmal Windows geladen hat, immer ein Windows-Server und damit lizenzpflichtig. Ein Blade-Anwender wird also genau das tun, was er eigentlich lassen sollte: Er wird Microsoft-Applikationen den Servern fest zuordnen. Das verspielt die Vorteile von Blades. Microsoft und Firmen mit ähnlichen Lizenzmodellen sind gefordert.