Das Biest bezwingen
Linux-Provisioning-Tools – Deren Hersteller behaupten, sie könnten die Installation des Betriebssystems zähmen. Das stimmt sogar – bis zu einem gewissen Punkt.
Es ist gerade mal einige Jahre her, da bedeutete der Einsatz von Linux auf Servern und Arbeitsstationen der Enterprise-Klasse, ein billiges (oder im Fall eines Downloads sogar kostenloses) Betriebssystem mit hohen Betriebskosten zu haben. Diese Tage sind vorbei, Linux-Betriebssystem-Distributionen sind gereift und nun stabil. Die Kosten, welche die Ausführung von Linux im Unternehmen erzeugt, sind geringer denn je.
Natürlich, Linux auf einem Server zu implementieren und zu nutzen ist leicht, aber das bedeutet nicht, dass es ebenso leicht ist, Linux auf einer ganzen Flotte von Enterprise-Linux-Servern und -Arbeitsstationen einzurichten. Standorte mit hoher Linux-Präsenz erzeugen typischerweise komplizierte benutzerdefinierte Scripts und Programme, um die Installation zu erledigen – und solche Anpassungen erstrecken sich weit über die konventionellen Grenzen der vom Hersteller gelieferten Installationssysteme hinaus.
Linux-Provisioning-Systeme können dabei helfen, die Last zu verringern. Sie kombinieren Controls für die Betriebssysteminstallation und -konfiguration, Richtliniendurchsetzung und Patching in einer einzelnen Schnittstelle. Sie sind eine umfassenden Lösung für Unix- und Linux-Bereitstellungen und befreien von der Notwendigkeit, vom Hersteller gelieferte Installationswerkzeuge sowie benutzerdefinierte Scripts und Programme gebrauchen zu müssen. Große Unix- und Linux-Standorte können mit diesen Systemen viel gewinnen.
Wie so oft im Leben, gibt es natürlich auch bei Linux-Provisioning-Systemen ein paar Fallstricke. Möglich wäre beispielsweise, dass der Hersteller des Betriebssystems auch der Hersteller des Provisioning-Tools sein muss. In diesem Fall wäre die Abhängigkeit von einem Hersteller zu groß. Und wenn ein Linux-Provisioning-System im Einsatz ist, die Organisation aber zu einem anderen wechseln möchte, ist die Migration sorgfältig zu planen. Jede Organisation, die sich darauf vorbereitet, ein Linux-Provisioning-System einzuführen, sollte sich vorher über diese beiden Punkte Gedanken machen.
Feature-Checkliste
Egal, ob eine Organisation eines der von Network Computing getesteten (siehe Vergleichstest auf den folgenden Seiten) oder ein anderes Provisioning-System ins Auge fasst, sie sollte stets an die generellen Vor- und Nachteile dieser Klasse von Werkzeugen denken.
Mit einem kommerziellen System können Administratoren beispielsweise eines der immerwährenden Probleme in den Griff bekommen: die Dokumentation. Wer viele selbst gestrickte Provisioning-Tools hat, muss jemanden vom Stab dazu auswählen, diese Programme zu dokumentieren – und diese Arbeit hat meist nur geringe Priorität. Beim Einsatz eines kommerziellen Provisioning-Tools verschwindet diese Aufgabe.
Und da gerade von Dokumentation die Rede ist: Administratoren wollen die aktuellen Zustände der Maschinen im Unternehmen dokumentiert haben. Ein kommerzielles Tool generiert eine vollständige Sammlung von Informationen, die diese Maschinen betreffen. Diese Tools können außerdem detaillierte Inventarberichte über die bereitgestellte Hardware produzieren. Diese Informationen entdecken die Provisioning-Tools typischerweise schon während der Installation jeder Maschine, oder wenn ein Programm oder Dienst auf den Clients läuft.
Ein weiterer Vorteil kommerzieller Provisioning-Tools ist, dass sie vom Schreiben benutzerdefinierter Programme befreien. Falls nur ein oder zwei Mitarbeiter der Organisation vollständig durchschauen, wie das benutzerdefinierte Provisioning-System funktioniert, repräsentiert dies eine große Verantwortung. Bei kommerziellen Systemen gibt es dieses Risiko nicht.
Wie zu erwarten, arbeiten kommerzielle Linux-Provisioning-Systeme generell besser, wenn sie zur Bereitstellung der Betriebssystem-Distribution desselben Herstellers benutzt werden. Einige Provisioning-Systeme bereiten zwar weniger Probleme mit spezifischen Linux-Versionen, erfordern diese aber nicht. Wer ein Provisioning-Tool einsetzt, das von demselben Hersteller stammt wie die Betriebssystem-Distribution, schwächt seine Position bei künftigen Verhandlungen mit diesem Hersteller, denn er ist von ihm abhängig. Stoppt dieser Hersteller plötzlich seine Gefälligkeiten, kann dies dornige Konsequenzen haben.
Da Provisioning-Systeme alle Werkzeuge haben, die für die Einbeziehung existierender Server erforderlich sind, ist der Migrationspfad für den Wechsel des Provisioning-Systems geradlinig. Wie bei jedem größeren Wechsel erfordert eine solche Migration aber sorgfältige Planung. Eine mögliche Migrationsstrategie könnte sein, das nicht mehr gefällige Provisioning-System auszuschalten und die existierenden Server ins neue Provisioning-System einzubeziehen. Ein anderer Weg, wahrscheinlich für Desktops besser geeignet, wäre einfach die Neuinstallation des Betriebssystems im neuen Provisioning-System. Mit mehr und mehr automatisierten Installationsprozessen sinken die Kosten kompletter Neuinstallationen schnell.
In Gold gegossen
Der erste Schritt bei der Bereitstellung einer großen Anzahl von Maschinen ist die Erzeugung eines goldenen Images. Ein Provisioning-System wird ein Image einer vollständigen Kopie des Inhalts der Maschine anfertigen, oder eine vollständige Kopie der Konfigurationsdateien, die zur Erzeugung des Inhalts der Maschine notwendig sind. Sobald das Image erstellt ist, speichert das Tool es auf einem Server, und das Provisioning-System installiert es, wo es erforderlich ist. Diese Fähigkeit, eine Maschine von null an zu installieren – durch Booten der Maschine durch PXE direkt vom Netzwerkserver –, ist das elementarste Feature jedes Provisioning-Systems.
In den meisten Fällen wird eine Organisation eine Auswahl verschiedener Hardware- und Softwarekonfigurationen haben, wodurch sie gezwungen ist, einen Ansatz für die Bereitstellung zu wählen. Entweder fertigt sie ein Image für jede Konfiguration an, was eine Menge Zeit kostet, oder sie erzeugt weniger spezifische Images, die Anpassungen erfordern, bevor eine Maschine nutzbar ist.
Maschinen zu patchen ist kritisch für den Betrieb der Organisation. Provisioning-Tools wie Zenworks oder xDMS erlauben dem Administrator, ein lokales Software-Repository zu erzeugen und Updates aus diesem lokalen Cache zu verteilen. Zenworks enthält ein Software-Paket, Zenworks-Linux-Mirror, das eine feine Kontrolle darüber erlaubt, welche Software-Pakete in Zenworks importiert werden sollten. Zenworks-Linux-Mirror kann Pakete herunterladen von entfernten Zenworks-Servern, Yast-Online-Updates oder Redhat-Netzwekservern.
dj@networkcomputing.de
