Red Hat ist mit seinem Red Hat Network (RHN) ein Exot im Bereich des Systemmanagements. Das RHN ist als eine Plattform entstanden, mit der Pakete an Red-Hat-Kunden verteilt werden können und nicht als lokales Werkzeug für das Systemmanagement. Die «Satellite»-Varianten, mit denen ein RHN-Server auch beim Kunden betrieben werden kann, sind erst später realisiert worden.
Dagegen ist ZENworks Linux Management im aktuellen Release 6.6 eine Weiterentwicklung des Red-Carpet-Produkts. Novell hat Ximian, den Hersteller von Red Carpet, vor rund zwei Jahren übernommen. Red Carpet wiederum hat eine Geschichte, die mehr im Bereich des Client-Managements liegt. Mit den klassischen ZENworks-Produkten wie ZENworks Desktop Management (früher ZENworks for Desktops) oder ZENworks Server Management (ehemals ZENworks for Servers) hat ZENworks Linux Management noch wenig zu tun – es ist eben eine optimierte Red-Carpet-Version unter ZENworks-Label.
Wer einmal Red Hat Linux installiert hat, ist wahrscheinlich auch mit dem RHN in Kontakt gekommen. Das öffentliche, von Red Hat gehostete RHN ist der Dienst, bei dem Systeme registriert sowie Patches und neue Versionen angefordert werden können. Bei der Realisierung des RHN hat Red Hat grossen Wert auf Performance und Skalierbarkeit legen müssen, weil darüber riesige Mengen an Systemen verwaltet werden.
Davon abgeleitet wurde der RHN Satellite, der in den Kundennetzwerken installiert werden kann. Zwischen diesem und dem öffentlichen RHN gibt es den RHN Proxy, der als Schnittstelle dient und beispielsweise Informationen über neue Pakete auf den RHN Satellite legt.
Der Satellite wurde zunächst entwickelt, weil Kunden die Inventardaten nicht bei Red Hat liegen haben wollten – eine Anforderung, die auch heute noch häufig der erste Grund ist, sich mit dem RHN Satellite zu beschäftigen. Zusätzlich hat Red Hat inzwischen aber auch mehrere weitere Module realisiert, die die Funktionalität des RHN für die spezifischen unternehmensinternen Anforderungen erweitern.
Die Basisfunktionalität des RHN war und ist von den spezifischen Anforderungen an das öffentliche RHN geprägt. Dort stehen die Verteilung des Betriebssystems, die Distribution zusätzlicher und geänderter Pakete und eine grundlegende Inventarisierung im Vordergrund. Ausserdem ist das RHN sehr stark im Bereich der Erkennung von Abhängigkeiten zwischen verschiedenen Paketen. Das ist erforderlich, um Fehler auf den Zielsystemen durch dorthin verteilte Softwarepakete möglichst zu vermeiden.
Die reine Softwareverteilung reicht aber vielen Unternehmenskunden nicht aus. Das Hauptgeschäft von Red Hat ist inzwischen die Migration von Umgebungen, die auf unterschiedlichen UNIX-Derivaten betrieben werden. In solchen Umgebungen sind die Erwartungen an das Systemmanagement hoch. Die ersten beiden Zusatzmodule waren die Management- und Provisioning-Module. Das Management-Modul stellt Basisfunktionen für das Systemmanagement bereit, die auch vom Provisioning-Modul genutzt werden. Dieses kann Konfigurationsdateien verwalten, wobei auch eine Versionierung erfolgt. Die Konfigurationsdateien werden automatisch auf die verwalteten Systeme verteilt.
Neu ist das Monitoring-Modul, mit dem eine Überwachung von Systemen erfolgen kann. Dabei wird mit dem Ansatz von Probes gearbeitet. Probes sind definierte Parameter, die regelmässig überprüft werden. Für diese Probes können Schwellwerte und Warnungen konfiguriert werden, um in Ausnahmesituationen automatisch zu reagieren. Ausserdem gibt es eine umfangreiche Berichtsfunktion, um den Status der Systeme und die Entwicklung der von den Probes gelieferten Werte zu kontrollieren.
Mit dem RHN lässt sich somit der gesamte Lebenszyklus von Linux-Systemen und hier insbesondere Servern steuern. Das beginnt bei der Installation, die über Pre- und Post-Prozesse angepasst werden kann. Das Deployment kann sowohl auf «bare metal» als auch vorinstallierte Systeme erfolgen. Weitere Komponenten und Systemanpassungen können ebenfalls automatisiert werden. Die Steuerung erfolgt über Channels, die eine Zuordnung von Paketen und Gruppen von Systemen darstellen.
Zusätzlich gibt es auch eine API, über die eingegriffen werden kann. Diese wird als XML RPC-API bezeichnet und derzeit mehrmals im Jahr erweitert. Kunden können darüber Funktionen des RHN aus anderen Anwendungen heraus steuern und die Integration mit Systemen wie IBM Tivoli oder Remedy realisieren. Die API ist auch die Basis für die neu angekündigte engere Zusammenarbeit mit BMC im Bereich des plattformübergreifenden Systemmanagements, bei dem das RHN die Basis für das Linux-Management bildet, während BMC sein Know-how für andere Plattformen wie Windows beisteuert.
Wenn man sich ZENworks Linux Management betrachtet, gibt es zwei Probleme. Zum einen wird es im Herbst ein neues Release geben, das grundlegend überarbeitet wird. Dort werden viele der Einschränkungen der aktuellen Version entfallen. Zum anderen gibt es auch Managementfunktionen für Linux in ZENworks Server Management. Dazu gehören insbesondere die Verteilung von Konfigurationsdateien und die Monitoring-Funktionen. Allerdings ist das Konfigurationsmanagement auch dort nicht so ausgefeilt wie beim RHN.
Auf den ersten Blick gibt es dennoch eine beachtliche Ähnlichkeit der beiden Produkte. Auch beim ZENworks Linux Management gibt es Channels, bei denen konfiguriert wird, welche Pakete an welche Systeme verteilt werden sollen. Auf den Zielsystemen wird der Red-Carpet-Client benötigt.
Ein wichtiger Unterschied besteht bei der Channel-Konfiguration. Während im RHN auf viele vordefinierte Daten von Red Hat zugegriffen werden kann, die über den Proxy auch in den Satellite geladen werden können, muss man diese Konfiguration beim ZENworks Linux Management manuell durchführen. Bei beiden Systemen müssen die Computerobjekte manuell konfiguriert werden, da aktuell noch die enge Integration mit Verzeichnisdiensten fehlt.
Das fällt natürlich besonders beim ZENworks Linux Management auf, weil die anderen ZENworks-Produkte mit einer sehr engen eDirectory-Integration aufwarten können. ZENworks Linux Management hat eine solche Verbindung zu Novells Verzeichnisdienst dagegen nicht.
Ein weiterer Bereich, in dem mehr Integration wünschenswert wäre, ist die Inventarisierung. Das ZENworks Linux Management arbeitet nur mit lokalen Informationen auf den angeschlossenen Systemen. Dort werden beispielsweise Update-Informationen gespeichert, die auch für Rollbacks verwendet werden können. Es erfolgt aber keine zentrale Inventarisierung, wie sie bei ZENworks Desktop Management für Windows-Systeme durchgeführt werden kann.
Eine weitere Schwachstelle ist die Analyse von Abhängigkeiten. Während hier eine der Stärken des RHN liegt, gibt es bei ZENworks Linux Management zwar einige Tools dafür, aber keine echte Integration. Damit ist auch der Grad an Automatisierung, der in diesem Bereich erreichbar ist, deutlich geringer. Das Risiko von Versionskonflikten ist damit aber in der Konsequenz höher.
Dafür können Informationen über neue Pakete sowohl von SuSE über YaST (Yet another Setup Tool) als auch über das RHN eingelesen werden. Hier ist Novell offener als Red Hat.
Im Vergleich zu Windows-Lösungen bieten beide Produkte den Vorteil, dass sie faktisch auch das Patch-Management übernehmen. Denn aus Sicht der Linux-Systemadministration ist ein Patch nichts anderes als ein Package, das verteilt werden muss. Die bei Windows oft zu findende künstliche Trennung zwischen der Softwareverteilung und dem Patch-Management gibt es nicht. Und sowohl SuSE als auch Red Hat liefern über ihre Server die Informationen zu den neu verfügbaren Paketen und damit auch den Patches.
Im Ergebnis ist das Red Hat Network zum aktuellen Zeitpunkt sicherlich die ausgefeiltere Lösung für das Server- und auch das Client-Management von Linux-Systemen in Unternehmen. Bei Novell hängt dagegen viel vom kommenden Release ab. Novell hat hier einige Chancen, die wohl auch genutzt werden. Dazu zählt die Integration mit den anderen ZENworks-Produkten, so dass ein plattformübergreifendes Systemmanagement auf hohem Niveau ermöglicht wird. Da aber mit ZENworks 7 die gesamte ZENworks-Architektur verändert wird, wird es sicherlich einige
Zeit dauern, bis alle Funktionen
für verschiedene Systeme auf
einem einigermassen identischen
Niveau verfügbar sind. Schon
heute gibt es gerade beim Servermanagement erhebliche Unterschiede im funktionalen Umfang beispielsweise für Windows,
Solaris und Linux.
Auf der anderen Seite ist die Entscheidung für eines der beiden Produkte immer auch eine Entscheidung für eine Linux-Plattform – im Fall von RHN noch mehr als beim ZENworks Linux Management, das etwas mehr Offenheit bietet. Insofern geht es meist nicht direkt um eine Auswahlentscheidung zwischen den Produkten.
Zudem muss man sich die Frage stellen, ob der Fokus rein auf das Linux-Management überhaupt sinnvoll ist. Die RHN-Ankündigung der Zusammenarbeit mit BMC zeigt ebenso wie Novells Strategie von plattformübergreifenden ZEN-works-Lösungen, dass der Trend
in Richtung heterogenes Systemmanagement geht. Derzeit haben
die spezifischen Linux-Lösungen
hier noch klare Vorteile. Bei Auswahlentscheidungen sollte aber auch geprüft werden, wie gut deren Zusammenspiel mit anderen Systemmanagement-Lösungen im Unternehmen ist.
ZENworks Linux Management 7 wird das erste Produkt der neuen ZENworks-Generation sein. Diese arbeitet mit einer grundlegend geänderten Architektur. Die meisten Informationen werden nicht mehr im eDirectory, sondern in Datenbanken gespeichert. Der Vorteil ist, dass sich die ZENworks-Produkte damit einfacher in unterschiedlichen Systemumgebungen einsetzen lassen, also beispielsweise im Zusammenspiel mit dem Active Directory.
Mit dem neuen ZENworks-Release sollen Funktionen wie Remote Control, die Inventarisierung, das Deployment von Images und eine starke Steuerung über Richtlinien kommen. Ausserdem soll auch das Configuration Lockdown unterstützt werden, mit dem Systeme auf einem definierten Status gehalten werden können. Insgesamt sind die Ankündigungen von Novell vielversprechend – ZENworks Linux Management 7 könnte die Messlatte für das Systemmanagement in Linux-Umgebungen höherlegen.
Und das Produkt wird sowohl SuSE Linux als auch Red Hat Linux unterstützen.
