Planung von Integrationstests: die Feinheiten

Steht bei einem Neubaurechenzentrum die Inbetriebnahme und Betriebsübernahme an oder wurde ein bestehendes Rechenzentrum umfassend saniert, ist es mittlerweile zum Stand der Technik geworden, dass vor der Aufnahme des produktiven IT-Betriebes Funktions- und Integrationstests durchgeführt werden. Wer solche Tests plant und konzipiert weiß, dass man sich im realen Testfeld das Leben vereinfachen kann, wenn man die Tests sehr genau vorbereitet und jede Schalthandlung bzw. jeden Eingriff in die Anlagentechnik vordenkt. Ebenso sollte man auch die erwartete Reaktion dokumentieren – so fällt es im realen Test leichter, Abweichungen festzustellen und Korrekturmaßnahmen einzuleiten.

An drei Beispielen wollen wir zeigen, welche Praktiken sich bewährt haben und wo sich, wie die Erfahrung zeigt, einheitliche Methoden durchgesetzt haben:

1. Zuerst soll es um die zeitliche Organisation der Tests gehen. Ein möglicher Ansatz wäre ein Vorgehen nach dem Top-down-Prinzip, sodass man bei den großen Erzeugern und Einspeisungen beginnt und sich dann bist zur kleinsten Einheit durcharbeitet. Ein anderer Ansatz folgt dem Bottom-up-Prinzip, wo man genau umgekehrt bei den kleinsten Einheiten anfängt und sich bis zur Einspeisung vortastet. Eindeutig ist zu empfehlen, den letzteren Ansatz zu wählen, da man so sehr strukturiert über Fehler und Abweichungen in kleineren Einheiten stolpert. Würde man umgekehrt agieren, stünden möglicherweise bereits im ersten Szenario sehr viele Fehler und Ausfälle an, deren Zuordnung zu unterschiedlichen Systemebenen viel Zeit kosten würde. Besser ist es daher, umgekehrt zuerst die einzelnen Abläufe zu erfassen und kleinere Abweichungen direkt zu korrigieren, um dann bei provozierten Ausfällen des Gesamtsystems schon bekannte Reaktionen zu beobachten. Der Erfahrungsschatz, den man mit kleineren Einzeleinheiten sammelt, kommt einem also so beim großen Ausfallszenario zu Gute.
2. Das zweite Beispiel kommt immer dann zum Tragen, wenn man zum Abbilden einer thermischen Last in Rechenzentren Lastbänke installiert. Oft sind diese Lastbänke genau wie die späteren IT-Gerätschaften durch zwei elektrotechnische Pfade zu versorgen. Im Testverlauf sind diese Lastbänke dann entweder komplett mit einem der beiden Systeme oder aufgeteilt auf beide Systeme zu betreiben. Je nachdem, wie kleinteilig die Lastbänke sind und wie die räumliche Situation generell ist, kann das dann erforderliche Umstecken von einem Stromversorgungssystem auf das andere schon mal zeitraubend sein. Es gibt zwar auch Lastbänke, die mit zwei Einspeisungen daherkommen, jedoch bedarf solcherlei Gerät aufwendiger Vorbereitungen bis hin zum Bereitstellen eines temporären Netzwerkes für die Lastbänke, einer Konfiguration des entsprechenden Managementsystems und letztlich einem Test dieser temporären Infrastruktur. Daher hat sich diese aufwendige Lösung in unserer Praxis bislang nicht durchgesetzt. Das Umstecken ist der pragmatischere Weg. Idealerweise staffelt man die Einzeltests also so, dass man möglichst viele Tests mit derselben Lastbankkonfiguration hintereinander plant. Danach wird umgesteckt und der nächste Block wird abgearbeitet: So ganz frei ist man aber im Gestaltungsspielraum hier nicht, da man es nicht so weit kommen lassen sollte, dass man sozusagen mit der unter Punkt 1. genannten Thematik kollidiert.
3. Das letzte Thema trägt dem Rechnung, was bei einem Lasttest mit einer USV-Anlage passiert. Der Testbetrieb eines Rechenzentrums mit Lastbänken ist oft die einzelne Chance, die Leistungsfähigkeit der Batterien von USV-Anlagen nachzuweisen: Man beaufschlagt also die jeweilige USV-Anlage mit ihrer vollen Last und betreibt sie in dieser Konstellation im Inselbetrieb ohne Netzeinspeisung im Batteriebetrieb für den geplanten Zeitraum der Autarkie. In dieser Betriebsart werden die Batterien naturgemäß entladen. Nach diesem Test ist es also erforderlich, ein Zeitfenster zum Aufladen der Batterien vorzusehen. Idealerweise bleibt die zu ladende USV-Anlage in diesem Zeitfenster unbeeinflusst und ist nicht Gegenstand weiterer Szenarien. Manchmal gelingt es, solche Szenarien auf kurz vor der Mittagspause oder vor dem Feierabend anzusetzen, dann bleibt genug Zeit zum Laden und man muss nicht warten, bis die Batterien wieder einigermaßen voll sind.

Fazit

Integrationstests sind immer individuell vorzubereiten und zu konzipieren. Auf diesem Weg gibt es noch sehr viel mehr zu beachten und zu berücksichtigen. Die genannten drei Sachverhalte können aber dabei helfen, dass Integrationstests möglichst störungsfrei durchgeführt werden und man dann gut für einen produktiven IT-Betrieb ohne Ausfälle gerüstet ist.