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.