Der zu erwartende weitere Ausbau von Virtualisierung, Cloud, Private Cloud und Hybrid Cloud wird die Situation nicht erleichtern. Die einsetzende „Digitale Transformation“ wird weiter Druck ausüben auf das Rechenzentrum, um immer noch kürzere Bereitstellungszeiten zu ermöglichen. Dauerte die Bereitstellung eines Bare Metal-Systems früher von der ersten Idee bis zur Serviceübergabe gerne mal sechs Monate, werden die meisten Kunden von Cloud-Diensten eine Bereitstellungszeit von sechs Minuten für ein virtuelles System oft schon als zu lang empfingen.
Und die Erwartungen werden noch anspruchsvoller. Die Digitale Transformation bedeutet nicht nur neue Anwendungsszenarien und Geschäftsmodelle, sondern auch neue Methoden und Modelle für erhöhte Agilität, Flexibilität und Geschwindigkeit. Prozesse aus dem RZ-Betrieb vor 20 Jahren sind heute nicht mehr an jeder Stelle sinnvoll. Die Technik hat sich verändert – der Prozess und Verwaltungsstil sollte entsprechend überprüft werden, ob er noch passt. Um sinnvolle Verbesserungen für die Nutzung von IT zu erreichen, heißt es weg von Teilsystemoptimierungen und hin zur Gesamtoptimierung. Klassisches Beispiel für eine Teilsystemoptimierung ist der Einsatz einer USV-Anlage mit besseren PUE-Werten (Power Usage Effectiveness), wobei es richtigerweise pPUE heißen muss. Die Verbesserung im Teilsystem führt leider nicht zwangsläufig zu einer relevanten Verbesserung des Gesamtsystems. Oft sind die Investitionskosten höher als der Nutzen. Wird aber der PUE-Wert einer Anlage verbessert und gleichzeitig steigt die Stromrechnung, ergibt sich oft ein Rechtfertigungsproblem. Die Verbesserung des PUE-Wertes wird so schnell zum Selbstzweck und alle Anstrengungen, die tatsächlichen Kosten zu reduzieren, geraten in den Hintergrund oder werden mit untauglichen Mitteln nicht erreicht.
Ganzheitlicher Ansatz statt Teiloptimierung
Das Muster für eine Teiloptimierung im IT-Umfeld ist der Generationswechsel und die Lieferantenauswahl bei Server-Systemen: Nach „Pizzaboxen“ haben Blade-Systeme Einzug in das Rechenzentrum gehalten, nun steht vielfach der Wechsel zu Converged Systems an; regelmäßige Ausschreibungen von Systemen führen oft zu einem Wechsel des Lieferanten. In der Regel wird dies isoliert betrachtet und lediglich ein Vergleich zur Vorgängergeneration beziehungsweise vorhergehendem Liefertanten vorgenommen. Dazu werden Anschaffungs- und Betriebskosten behandelt, eine kurze Unter-suchung der Technik in Bezug auf Rechenleistung, möglicherweise auf Platzbedarf und Stromeffizienz durchgeführt sowie heute auch schon mal Auswirkungen auf die Lizenzkosten beleuchtet.
Aber schon die detaillierte Betrachtung von veränderter Stromdichte (also Strombedarf pro Höheneinheit im Rack beziehungsweise Flächeneinheit im Raum) und Veränderungen der Wärmeabgabe (Wärmemenge und Ausblastemperatur) beziehungsweise Kühlbedürfnisse (erforderliche Luftmenge, optimales Temperaturband, Luftgeschwindigkeit und Druckunterschiede) werden meist vernachlässigt oder nur exemplarisch überprüft. Doch da lauert ein großes Risiko für die Einführungsphase und den Betrieb. Auch die erfolgreichste Teiloptimierung leidet oft daran, dass die benachbarten Teams oder Nutzer davon nichts wissen und sie womöglich wieder zunichtemachen. Auch die effizientesten Server verbrauchen immer noch zu viel Strom, wenn sie ungenutzt einfach nur eingeschaltet bleiben und sich „idle“ vor sich hin langweilen. Ein Testsystem für einen einfachen Versuchsaufbau muss auch nicht unbedingt in einem Tier 3-Umfeld laufen, wenn eine einfachere Alternative zur Verfügung steht. Ziel muss es sein, die „Gesamtproduktion“ zu optimieren. Dazu ist aber die Betrachtung aller Bereiche des Unternehmens, aller Komponenten des IT- und RZ-Betriebs und eben aller Ebenen des Stacks notwendig. Hier ist die Unternehmensleitung gefragt, sich dieses Vorhabens anzunehmen und es auf die Agenda zu setzen. Statt den Fokus auf einen prestigeträchtigen RZ-Neubau zu setzen, wäre oft eine Restrukturierung oder Prozessoptimierung die nachhaltigere Entscheidung.
Auch ein Umdenken bezüglich Redundanz ist angesichts aktueller Virtualisierungstechnologien und Methoden von NFV (Network Functions Virtualization) gefordert, da künftig die Ausfallsicherheit auf der Applikationsebene berücksichtigt wird und eigentlich geringere Anforderungen an die technische Ausstattung der darunterliegenden Rechenzentren gestellt werden können. Hyperscale-Anbieter von Diensten, die auf Selbstheilung und Auto-Skalierung in der Applikationsschicht setzen, nutzen schon seit längerem die erheblichen Einsparpotenziale, die sich allein daraus ergeben, wenn nicht A- und B-Versorgung über eine USV geführt werden müssen, sondern in dieser Schicht weniger Ausfallsicherheit nötig ist.