Unterschiede zwischen Spacewalk, Red Hat Network Satellite und SUSE Manager

Mit Red Hat Network Satellite und SUSE Manager gibt es zwei Management-Suiten für die Linux Enterprise-Distributionen Red Hat Enterprise Linux und SUSE Linux Enterprise Server.

Auf den ersten Blick sehen die beiden Produkte gleich aus und auch aus technischer Sicht gibt es starke Ähnlichkeiten, da die Produkte beide auf der selben quelloffenen Software-Kernkomponenten aufbauen: Spacewalk. Spacewalk wurde 2008 durch Red Hat als Open-Source freigegeben und bildet die Basis für den kommerziellen Satellite Server.

Wo genauen liegen also die Unterschiede zwischen den Produkten? Die folgende Tabelle zeigt die Gemeinsamkeiten und Detailunterschiede:

Spacewalk RHN Satellite SUSE Manager
Version  2.1 5.6 1.7
Link  [klick mich!] [klick mich!] [klick mich!]
Preismodell kostenlos Subscription/Module
Verwaltung von Fedora, CentOS, SUSE, Debian, Solaris RHEL, Solaris SUSE, RHEL* (siehe unten)
Architekturen i386, x86_64 i386, x86_64, s390x i386, x86_64, ia64, s390x, ppc, ppc64
Datenbank Postgres, Oracle Oracle 10gR2/11g Postgres, Oracle 10gR2/11g
Funktionen
(gekürzt)
  • Logische Gruppierung von Hosts und Software-Kanälen
  • Software-/Patch-Management, bereitstellen von Distributor- und Eigenbau-Software
  • Provisioning von physischen und virtuellen Hosts
  • rudimentäres Host-Monitoring
  • Compliance-Reporting und Alerting
  • Proxy-Server, verwaltete Hosts benötigen keine direkte Internet-Verbindung mehr

Zentrale Verwaltung von RHEL- und SLES-Systemen mit einer Suite?

Was für Möglichkeiten bestehen für den Fall, dass RHEL- und SLES-Systeme parallel betrieben und zentral verwaltet werden sollen?

Genau die Frage habe ich mir auch gestellt, im Internet recherchiert und über Twitter einen Kontakt zu SUSE geknüpft.

Letztendlich gibt es zwei denkbare Möglichkeiten – ob diese praktikabel sind, liegt im eigenen Ermessen des Administrators.

1.Möglichkeit – SUSE Expanded Support

SUSE Expanded SupportIm Rahmen des „SUSE Expanded Support“ bietet SUSE neben den eigenen SLES-Patches auch digitale Flicken für RHEL. Das Ganze ist für langwierige Migrationen gedacht und soll den Red Hat Support überflüssig machen, da Patches nicht mehr direkt über das Red Hat Network bezogen werden. Die Patches kommen direkt von SUSE, wo sie aus den von Red Hat veröffentlichten Quellcodes übersetzt werden. Letztendlich sollte die Qualität der Software-Pakete die selbe sein, da sie ja dem gleichen Quellcode entspringen – ich persönlich würde es jedoch bevorzugen, meine Distributionspatches auch vom ursprünglichen Distributor zu erhalten.

Wenn man nicht gerade eine Migration plant und lediglich beabsichtigt, das Beste aus beiden „Welten“ zu kombinieren, ist dieser Lösungsansatz meiner Meinung nach nicht der Beste.

2.Möglichkeit – mrepo

SUSE Manager + mrepoEine andere Möglichkeit wäre die Verwendung eines Tools namens mrepo. Dieses Programm legt einen Spiegel eines YUM-Repositories an und stellt so die jeweiligen RPM-Pakete lokal zur Verfügung – laut Webseite soll das auch mit RHN-Kanälen möglich sein. Ich kann mir nur schwer vorstellen, dass diese Lösung lizenzrechtlich unbedenklich ist, da das lokale Vorhalten von RPM-Paketen aus dem RHN ja bewusst erschwert wird. In aller Regel soll das lokale Cachen nur über den RHN Satellite Server erfolgen.

Für Testzwecke wäre das sicherlich eine denkbare Lösung, in produktiven Umgebungen, in welchen ein sauberer Support-Status stets gegeben sein muss, würde ich von diesem Ansatz jedoch Abstand nehmen.

Fazit

Letztendlich handelt es sich bei RHN Satellite und SUSE Manager um identische Produkte (quasi „das Selbe in grün“  😛) – an eine unkomplizierte Kombination von beiden „Welten“ ist jedoch leider nicht zu denken.

Das Problem ist dabei weniger technischer, sondern lizenzrechtlicher Natur, wie ich kürzlich in einem Gespräch mit einem SUSE-Mitarbeiter erfahren habe. Die Gründe sind natürlich auch nachvollziehbar – die Hersteller wollen natürlich in erster Linie ihr eigenes Produkt „an den Mann bringen„, um konkurrenzfähig zu bleiben.

Wenn man beide Produkte verwendet und eine zentrale Management-Suite sucht, muss man sich meiner Meinung nach entweder für eine Migration der anderen Systemlandschaft entscheiden oder mehr Geld in die Hand nehmen, um beide Produkte parallel zu betreiben. Alternativ kann man sich auch eines Tricks bedienen, um RPM-Pakete aus dem Red Hat Network zwischenzuspeichern und zu verteilen. Wenn es keine Rolle spielt, woher die zu installierenden RHEL-Patches stammen, kann man auch auf den „SUSE Expanded Support“ zurückgreifen.

Ich persönlich lege großen Wert auf lückenlosen Support durch den ursprünglichen Distributor und würde mich daher in jedem Fall für die Implementation beider Management-Produkte entscheiden.

Galerie

Anbei noch einige Screenshots der einzelnen Management-Suiten.

Sharing is caring

5 Kommentare Schreibe einen Kommentar

  1. Ich sehe den SUSE Manager in Verbindung mit dem SUSE Expanded Support als deutlich bessere Lösung an, da damit beide Welten (RH+SUSE) verwaltet werden können. Wir haben neulich bei einem Kunden eine Migration vom RH Satellite zum SUSE Manager durchgeführt und den SUSE Expanded Support eingeführt, mit dem der Kunde eine deutliche Kostensenkung (20%!) erreicht hat.

    /Werbung an/
    siehe http://www.protosoft.de/referenzen/success-stories/success-story-delta-lloyd/
    /Werbung aus/

    • Hallo Herr Heldwein,

      danke für die Referenz!

      Mich würden in dem Fall mal genaue Preisunterschiede (pro Subscription/Lizenz) interessieren. Rechnet sich das Vorgehen auch bei kleineren Setups (~50 Server)?
      Ich konnte bisher auch keine genauen Informationen bezüglich der unterstützten Software-Kanäle finden – werden durch den Expanded Support auch zusätzliche Red Hat Software-Kanäle, wie beispielsweise „Workstation Supplementary“ oder „Optional Debug Info“ angeboten?

      Beste Grüße,
      Christian Stankowic.

    • Technisch funktioniert das sicher gut, aber es gibt zwei Dinge zu beachten:

      1. Support von 3rd Party Software. z.B. Oracle unterstützt ein RHEL System das mit Paketen von Suse gepatcht wurde nicht. Das habe ich mir vom Oracle-Support bestätigen lassen.

      2. Man muss sämtliche Subscriptions mit Red Hat kündigen oder man muss weiterhin für alle RHEL-Systeme Subscriptions bezahlen. Das ist die All-Or-Nothing Klausel von Red Hat.

      Fazit: Auf 3rd Party Software achten und _alle_ RHEL Server in den Expanded Support nehmen, sonst hat man evtl. ein Support-Problem oder ein Lizenzrechtliches.
      Oder gleich CentOS installieren wenn man nicht auf Support angewiesen ist…

      • Hallo Tronco!

        Ich bin zugegebenermaßen auch kein großer Freund der Lösung – aus den von Dir genannten Gründen. Die einzigen berechtigten Verwendungszwecke sehe ich für unkritische Test-Umgebungen (in denen man keinen Produktiv-Support benötigt) oder Migrationszwecke (beispielsweise eine mittelfristige Migration von RHEL auf SUSE).

        Wenn einer der Fälle gegeben ist, kann man natürlich Lizenzkosten sparen, wenn meine Preisrecherchen realistisch waren.

        Beste Grüße,
        Christian.

  2. Der Expanded Support rechnet sich auf alle Fälle ab ca. 25 Server. Allerdings gibt es keine vorgeschriebene Preisliste, sondern der Preis wird je nach Projekt kalkuliert. Die Ersparnis liegt in der Regel immer über 25% gegenüber Red Hat. Haben Sie ein konkreten Fall den wir uns anschauen können?

    Mit dem Expanded Support erhalten Sie keine RHEL Versionen, sondern lediglich Maintenance & Support für RHEL Server. SUSE kann Ihnen auch rechtlichen Gründen kein ISO Image des gesamten OS anbieten, aber Sie sind in der Lage Ihnen Updates, Patches, … zu liefern.

    Es gibt keine Liste mit den Channels. Beim Expanded Support werden aber alle Updates, Patch Releases von RH zur Verfügung gestellt. Von daher gesehen, sollten auch die Patches der oben erwähnten Channels enhalten sein.

    Siehe z.B.
    http://wiki.novell.com/index.php/SUSE_Manager/FAQ
    https://www.suse.com/products/suse-manager/features/suse-manager-1-7.html

Schreibe einen Kommentar zu Christian Heldwein Antworten abbrechen