Automation im RZ – Wunsch und Wirklichkeit
Das Ziel vor Augen
Heute ist die Automatisierung des Rechenzentrums ein Schlüsselfaktor und entscheidet über Erfolg und Misserfolg. Wunsch und Wirklichkeit unterscheiden sich oft aber radikal.
Wer, wie der Autor, vor fast 20 Jahren in Sachen Rechenzentrum und Serverbetrieb sozialisiert wurde, der erinnert sich noch an Systeme und Workarounds, mit denen junge Administratoren heute gar nichts mehr anfangen können. Wer 2007 etwa einen Hochverfügbarkeitscluster auf Basis von Heartbeat und DRBD konstruierte, musste sich noch Gedanken darüber machen, wie es die DRBD-Konfiguration von einem Clusterknoten auf den anderen schafft. SSH war eine Möglichkeit, doch allzu oft vergaß man das Synchronisieren der Dateien und ärgerte sich später über sich selbst: Ging beim Einrichten etwas schief, ging wegen solcher Divergenzen der Failover in die Hose und gestaltete die Rufbereitschaft anstrengender als nötig.
Der Administrator von heute hingegen lächelt angesichts solcher Aufgabenstellungen nur müde und zeigt auf sein Automationssystem – vielleicht auf Ansible-Basis [1]. Es gewährleistet, dass alle Dateien clusterweit identisch bleiben. Und weil der Administrator schlau war, hat er gleich ein Auditing wie InSpec integriert [2]. Das schaut ebenfalls regelmäßig nach, ob in allen Dateien drinsteht, was drinstehen soll, und schlägt andernfalls Alarm. Schöne neue Welt also, und offensichtlich ist das Thema Automatisierung in modernen Rechenzentren damit ein für alle Mal abgehandelt. Oder doch nicht?
Wer das annimmt, sitzt einem fatalen Irrtum auf. Zwar versprechen die Automation-Hersteller in ihren Broschüren eine perfekte Automatisierung bis in die letzte Ecke des Rechenzentrums, doch Wunsch und Wirklichkeit unterscheiden sich hier fundamental. Schaut man sich in einem beliebigen RZ um, fällt schnell auf: Inseln gibt es allerorten. Oft erfinden Administratoren für jedes Setup, das sie betreiben, das Rad immer wieder neu. Viele Aspekte sind gar nicht automatisiert, etwas das Handling von Hardware.
Wie hätte mans denn gern?
Bevor dieser Artikel auf die am Markt verfügbaren Produkte eingeht und zeigt, was mit aktueller Technik möglich ist, stellt sich eine andere Frage: Wie sieht der Idealzustand im Rechenzentrum aus? Welchen Grad an Automation muss ein Setup erreichen, damit sich der Administrator beruhigt um andere Themen als den Betrieb seiner Plattform kümmern kann?
Die Antwort darauf ist verhältnismäßig simpel. Eigentlich hat der Administrator ein Interesse daran, dass alle Aufgaben automatisiert sind, für die er oder seine Kollegen anderenfalls die immer gleichen Handgriffe zu vollziehen hätten. Allerdings verstecken sich hinter dieser Aussage eine Reihe technischer Details – auch und vor allem weil sich das Ziel der Automation in den vergangenen Jahren und Jahrzehnten immer wieder verändert hat, je nachdem, was technisch gerade möglich war.
Ursprüngliches Ziel der Automation war die effizientere Betreuung von Systemen. Administratoren waren es vor 15 Jahren gewohnt, dieselben Aufgaben immer und immer wieder zu erledigen, zumal damals die Zahl der Server, die ein Administrator betreute, weit geringer war als heute. Hatte man einen neuen Server gekauft, ausgepackt und ins Rack eingebaut, folgte zunächst die manuelle Installation eines Betriebssystems. War das vorhanden, installierte man zu Fuß oder mit Shell-Skripten Marke Eigenbau die benötigten Pakete samt den hierfür gebrauchten Konfigurationsdateien. Am Ende des Vorgangs nahm man das betroffene Systeme händisch ins Monitoring auf und führte eine formale Übergabe an den Kunden durch – erst dann war der ganze Vorgang erfolgreich abgeschlossen.
Dass das kein sonderlich effizientes Vorgehen ist, merkten die Linux-Server-Distributoren schon einigermaßen früh. Bei Red Hat existiert Anaconda im Huckepack von Kickstart seit vielen Jahren (siehe Abbildung 1), SUSE lässt sich per AutoYaST im vollautomatischen Modus installieren und Ubuntu erbt das Preseeding, das die Debian-Entwickler schon in den ersten Versionen des Debian-Installers erdacht und sukzessive erweitert haben. Den Fully Automated Installer für Debian gibt es gar noch länger (siehe Abbildung 2).
Wer sich mit dem Thema Automation beschäftigte, konnte sich schon vor vielen Jahren Arbeit vom Hals schaffen. Dass viele Administratoren sich damit nie beschäftigten, hat mindestens zwei Gründe: Zum einen waren konventionelle Setups kleiner als die großen skalierbaren Plattformen der Gegenwart. Zu oft war man deshalb der Meinung, die Arbeit, die man in die Automatisierung investieren müsse, stehe nicht in Relation zum Aufwand der händischen Installation. Zum anderen hielten viele Administratoren die Installation des Betriebssystems für den geringsten Teil. Zeitaufwendig sei das anschließende Einrichten der Systeme.
Die Automation muss also die Installation des Betriebssystems auf Servern umfassen, und sobald ein Server mit den rudimentären Linux-Werkzeugen ausgestattet ist, muss sie die Installation aller benötigten Software-Komponenten übernehmen.
Wartung bitte nicht vergessen
Zu einer leistungsfähigen Automation gehört allerdings viel mehr. Das Out-of-Band-Management etwa ist ein kritischer Faktor bei modernen Servern – denn nur mit ihm kommt man noch remote an den Server, wenn dieser kein funktionierendes Betriebssystem mehr hat. Damit es diese Aufgabe aber erfüllen kann, ist der Management-Port nach der Systeminstallation zu konfigurieren. Beim IPMI-Protokoll ist das keine Herausforderung, denn die Controller sind von der Kommandozeile aus steuerbar. Auch andere Remote-Management-Protokolle wie HPEs iLO oder Dells DRAC bieten entsprechende Schnittstellen. Viel zu oft bleiben sie aber ungenutzt, was im Fall des Falles schiefgehen kann.
Beinahe jeder Administrator wird sich eingestehen müssen, dass es die Fass-mich-nicht-an-Systeme auch in seiner Vergangenheit gegeben hat. Gemeint sind Server, die einmal installiert und konfiguriert und dann unkontrolliert so modifiziert wurden, dass am Ende niemand mehr den Zustand des Systems kannte oder hätte beschreiben können. Solche Systeme bekommen dann keine Updates mehr, weil unklar ist, wie sie sich auswirken.