Folgende Info vorab: Mit scVENUS stellt mein Arbeitgeber science + computing auch ein eigenes Clustermanagement-System her.

Wenn ich die Provisionierung erkläre, kommt immer wieder die Frage: “Sagen Sie mal, Herr Wender, warum machen Sie so eine komplizierte Installation und kein einfaches Image? Alle anderen machen doch auch Imageverteilung!” Daher will ich hier mal die Vor- und Nachteile der beiden Verfahren vorstellen.

Eine Image-basierte Installation wird zum Beispiel von xCAT, OSCAR oder Perceus verwendet, wohingegen Rocks und scVENUS paketbasiert arbeiten. Einige Clustermanagement-Systeme wie UniCluster oder Platform Cluster Manager können sowohl Image- wie auch paketbasiert installieren.

Verständlichkeit

Der große Vorteil Image-basierter Verfahren ist die leichte Verständlichkeit des Konzepts. Das Erstellen eines Festplattenabbildes und anschließende Verteilen ist leicht einsichtig. Bei einer paketbasierten Installation muss ich nach der Installation noch mit einem Skript die notwendigen Anpassungen durchführen. Dadurch haben die paketbasierten Verfahren einen höheren Einarbeitungsaufwand.

Änderungsfreundlichkeit

Im wirklichen Leben wird sich die Umgebung des Clusters im Lauf der Zeit ändern, so dass ich die Konfiguration anpassen muss. Idealerweise sollte dies bei einfachen Änderungen im laufenden Betrieb geschehen, um keine Rechenjobs abbrechen oder erst wieder auf ein Servicefenster warten zu müssen.
Mit Image-basierten Verfahren ist das nicht so einfach. Ich muss die Änderung in den Images einpflegen und entweder die Rechner neu aufsetzen (in der Regel ein Reboot) oder die gleiche Änderung nochmal manuell auf allen Rechnern ausführen.

Bei einem paketbasierten Verfahren muss ich das Anpassungsskript erweitern. Sinnvollerweise erzeuge ich ein neues Sub-Skript, das die entsprechende Änderung durchführt. Dieses Skript wird einerseits in den Installationsablauf integriert und andererseits auf den aktiven Computern ausgeführt. Somit werden künftig auch neue Knoten automatisch korrekt installiert.

Nachvollziehbarkeit

In der Adminstration von Computern ist es wichtig, dass Änderungen nachvollzogen werden können. Wer hat wann, wo und warum eine Änderung gemacht. Oft haben Änderungen unvorhergesehene Auswirkungen, die teilweise auch erst nach einiger Zeit auftreten. Um diese in den Griff zu bekommen, ohne die ursprüngliche Änderung auszuhebeln, muss ich wissen, warum eine Änderung durchgeführt wurde. Hier haben Image-basierte Verfahren Schwierigkeiten. Mal boshaft beschrieben: Bei der Erstellung eines Images wird solange rumgewurschtelt, bis es passt. Wie das entstanden ist, lässt sich später nicht mehr rekonstruieren. Prinzipiell ließe sich der Dateibaum in einem Versionskontrollsystem verwalten, das wird aber von keinem mir bekannten Image-basierten Verfahren angeboten. Ebensowenig gibt es eine Versionskontrolle für die Images (die auch ziemlich viel Platz verbrauchen würde, da Versionskontrollsysteme mit großen Binärdateien nicht gut umgehen können).

Bei einem paketbasierten Verfahren sind die Änderungen in einem Sub-Skript enthalten. In diesem kann ich erstens die Änderung dokumentieren, und zweitens sind diese relativ kleinen Textdateien leicht mit einem Versionskontrollsystem zu verwalten. Die skriptbasierte Anpassung erleichtert den Überblick, weil die jeweiligen Änderungen in einem Skript zusammengefasst sind und sich nicht über das gesamte Image verstreuen.

Mehrbenutzerfähigkeit

Wird mein Cluster von mehreren Administratoren gleichzeitig verwaltet, muss verhindert werden, dass sich diese bei Änderungen gegenseitig in die Quere kommen. Bei Images bleibt nur, die Bearbeitung eines kompletten Images nur einem Admin zur Zeit zu erlauben. Ansonsten kann sehr schnell ein komplettes Durcheinander entstehen: Administrator A erstellt schon das neue Image, weil seine Änderungen fertig sind, und packt dabei ungewollt auch die halbfertigen Änderungen des Praktikanten B mit ein.

Bei skriptbasierten Änderungen kann jeder Administrator in seinem eigenen Skriptbereich arbeiten, ohne dass die anderen direkt gestört würden. In fortgeschrittener Version bietet das Clustermanagement entsprechende Sperrfunktionen, so dass die Administratoren sehen können, wer gerade woran arbeitet.

Upgradefähigkeit

Für einen Upgrade meines Clusters auf eine neue Betriebssystemversion gibt es zwei mögliche Vorgehen: Ich kann den Upgrade-Mechnismus des Betriebssystems verwenden, also auf allen Knoten entsprechende Paketquellen einrichten, das Upgrade per Kommando starten und anschließend die ganzen Problemkinder aufräumen, bei denen es nicht richtig geklappt hat. In der Praxis wird daher meistens das zweite mögliche Verfahren, eine Neuinstallation, durchgeführt.

Bei einem Image-basierten Verfahren muss ich ein neues Image erstellen, und anschließend alle Änderungen einbauen, die im bisherigen Image gemacht wurden. Da diese im Image nicht unbedingt nachvollziehbar sind, bin ich auf externe Dokumentation angewiesen (die ich hoffentlich gemacht habe…).

Bei einem paketbasierten Verfahren muss ich im ersten Schritt der Installation das neue OS integrieren. Die dazugehörige Steuerdatei kann in der Regel nach kleinen Anpassungen von der älteren Version wiederverwendet werden. Dann muss ich noch die anschließend ausgeführten Skripte durchsehen, ob sie für das neue OS angepasst werden müssen.

Das hat zur Folge, daß ich bei einem Image-basierten Verfahren das gesamte Betriebssystem (nämlich in dem Image) pflegen muss, bei einer paketbasierten Installation nur die Unterschiede zur Standard-Installation. Dabei kann ich hoffen, daß die Änderungen bei einem Upgrade gleich bleiben.

DRY

In der agilen Softwareentwicklung gibt es das DRY-Prinzip: Don’t repeat yourself. Eine Information sollte nur an einer Stelle liegen. Alle anderen Verwendungen dieser Information sollten sich auf diese Stelle beziehen. Im Datenbankbereich heißt das Normalisierung. Dieses Prinzip ist auch in der Systemadministration sinnvoll anzuwenden, weil sich dann Änderungen an dieser Information viel leichter durchführen lassen.

Images können hier Schwierigkeiten haben, insbesondere wenn mehrere Images parallel gepflegt werden müssen. Bei skriptbasierten Verfahren lässt sich ein entsprechender Umgang mit Informationen leichter integrieren, wenn es nicht sowieso schon vom Clustermanagement angeboten wird.

Heterogenität

In der Idealvorstellung sind alle Rechner in meinem Cluster identisch. Leider geht dieses Ideal sehr schnell verloren: Knoten haben unterschiedliche Aufgaben, die unterschiedliche Installationen erfordern. Im Lauf der Zeit ändert sich die Hardware der Rechner, so dass unterschiedliche Treiber notwendig sind. Zudem gibt es gibt immer mehr Mehrzweck-Cluster, in denen von Anfang an unterschiedliche Knoten-Typen vorgesehen sind.

In einem Image-basierten Verfahren führt dies dazu, dass ich für jeden Knotentyp ein eigenes Image pflegen muss. Bei Änderungen müssen dann entsprechend viele Images angepasst werden.

Bei einem paketbasierten Verfahren kann ich mit einer oder wenigen Grundinstallationen auskommen, die dann je nach Einsatzzweck durch unterschiedliche Skripte angepasst werden. Auch die Grundinstallationen werden sich meist nur durch die Steuerdatei unterscheiden und die gleichen Paketquellen verwenden.

Diskless nodes

Eine Möglichkeit bei der Installation von Cluster-Knoten ist die Diskless-Installation. Dabei wird häufig das OS nicht auf eine lokale Festplatte installiert, sondern in eine RAM-Disk. Andere Systeme verwenden Netzwerkverzeichnisse, wobei dann für die individuellen Bestandteile des OS eine Lösung gefunden werden muss.

Dieses Vorgehen ist gut geeignet für Image-basierte Verfahren, weil sie einfach das Image an die Computer weitergeben und starten. Paketbasierte Installationen hingegen sind dafür nicht so geeignet, weil die Installation normalerweise doch ein wenig länger läuft als das Übertragen eines Images.

Die Vor- und Nachteile plattenloser Installationen sind aber doch etwas umfänglicher und verdienen einen eigenen Artikel. Den gibt es hier in Kürze zu lesen.