Pan nach XML übersetzen

Das Template übergibt der Administrator als Nächstes dem Pan-Compiler Panc, der das Template in das XML- oder JSON-Format übersetzt (Bild 2). Dieses maschinenlesbare Ergebnis bezeichnet die Quattor als Profil, das wiederum später das Node Configuration Management auf den Nodes auswertet und umsetzt.

Bild 2: Das Listing "Beispiel für eine Pan-Konfiguration" nach der Transformation ins XML-Format.

Das fertige Profil ordnet die Konfigurationseinstellungen immer in einer Hierarchie beziehungsweise Baumstruktur an. Bild 3 präsentiert exemplarisch den Aufbau des übersetzten Listings. Die Hierarchie ergibt sich dabei immer aus den Bezeichnungen der Einstellungen, die Schrägstriche in den Bezeichnungen bilden dabei die einzelnen Abzweigungen. Kenner des XML-Standards dürften diese Hierarchie auch in Bild 2 wiedererkennen.

Panc wandelt das Template nicht nur in ein maschinenlesbares Format um, sondern prüft auch noch die Inhalte auf Tippfehler. Insbesondere prüft der Compiler, ob alle Werte die korrekten Typen besitzen. Die Angabe von:

‘/software/components/ntpd/active’ = OK;

produziert einen Fehler, da “OK” für den Compiler eine Zeichenkette und kein an dieser Stelle erlaubter boolescher Wert ist. Administratoren können in Panc zudem eigene Validierungsfunktionen und Schemata definieren. Panc validiert dann die Angaben im Template gegen dieses Schema und schlägt gegebenenfalls Alarm. Auf diese Weise lässt sich etwa sicherstellen, dass IPv4-Adressen immer mit “192. 168.” beginnen.

Panc selbst ist in den Programmiersprachen Java und Closure geschrieben und läuft daher auf allen Systemen mit einer Java-Laufzeitumgebung. Panc bevorzugt dabei das JRE von Oracle, vom OpenJDK raten seine Entwickler ab.

Bild 3: Die Einstellung "/software/components/ntpd/active" landet in der Hierarchie im Ast software, components, ntpd, active.

Integration in CMDB

Alle erstellten Konfigurationen landen in einer Datenbank, der sogenannten Configuration Management Data Base (CMDB). In früheren Quattor-Versionen stellte diese Datenbank eine Komponente namens CDB zur Verfügung, die Pan-Templates in einer CVS-Versionsverwaltung speicherte. Ihre Nachfolgerin namens SCDB setzte hingegen auf Subversion, zeigte jedoch in der Praxis Skalierungsprobleme ab 2.500 Knoten. Aus diesem Grund entwickelten die Quattor-Macher mit Aquilon eine dritte Generation der CMDB [3].

Aquilon lagert Pen-Templates in der verteilten Versionsverwaltung Git, die fertigen Profile in einem RDBMS und ist auf eine hohe Skalierbarkeit ausgelegt. Aquilon stellt zudem sicher, dass Administratoren nicht versehentlich gleichzeitig Konfigurationen ändern und so zerstören. Kernstück von Aquilon ist der aqd-Daemon, der die eigentliche Verwaltung übernimmt. Administratoren steuern ihn über das Kommandozeilenprogramm . Aquilon selbst ist in Python geschrieben, die Kommunikation und der Datenaustausch erfolgen über Standard-Protokolle. So liefert Aquilon die Profile per HTTP-Server aus. Den Zugriff regeln X.509-Zertifikate, Kerberos-Server und Access Control Lists (ACLs).

Um die automatische Installation eines Betriebssystems auf den Nodes kümmert sich die Automated Installation Infrastructure (AII) [4]. Sie besteht aus mehreren Perl-Skripten, die wiederum die passenden Standardwerkzeuge steuern. So kümmert sich etwa das Skript um die Einrichtung des PXE-Boot-Prozesses, während Kickstart-Dateien für das Anaconda-System von RHEL-Distributionen schreibt. Steuern lassen sich die AII-Komponenten über entsprechende Pan-Profile.