Distributionen & Auswahl

SUSE oder Red Hat: So legst du deinen Enterprise-Linux-Standard fest

Wer SAP betreibt, nimmt SLES, dort ist die Integration am tiefsten. Wer auf OpenShift und ein großes Partner-Ökosystem setzt, nimmt RHEL. Technisch trennt beide weniger, als die Vertriebsunterlagen nahelegen.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Zwei IT-Fachleute vergleichen Optionen an mehreren Bildschirmen

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Die Entscheidung scheitert selten an der Distribution, sondern am Betriebsmodell

Auf Serverebene sind SUSE Linux Enterprise Server und Red Hat Enterprise Linux erstaunlich ähnlich: gleicher Kernel-Stamm, systemd als Init, LVM, XFS oder Btrfs, RPM-Pakete, Mandatory Access Control über SELinux beziehungsweise AppArmor, dazu jeweils rund zehn Jahre Lifecycle und Live-Patching für den Kernel. Wer nur einen einzelnen Host betrachtet, findet kaum ein Argument, das die Wahl wirklich entscheidet. Sichtbar wird der Unterschied erst, wenn hunderte oder tausende Systeme gepatcht, in Content-Kanäle einsortiert, auditiert und automatisiert werden müssen.

Genau dort trennen sich die Ökosysteme. Bei Red Hat steht Satellite für das Lifecycle-Management mit Content Views und Capsules, dazu Ansible für die Automatisierung und OpenShift als Container-Plattform. Bei SUSE steht der Multi-Linux Manager, der aus Uyuni stammt und anders als Satellite auch Fremd-Distributionen wie RHEL, Ubuntu oder Debian mitverwaltet, dazu Rancher Prime für Kubernetes und NeuVector für Container-Security. Wer nur die Distribution vergleicht und die Management-Ebene ausblendet, entscheidet an der Stelle vorbei, an der später der Betriebsaufwand entsteht.

Drei Fehlermuster tauchen dabei regelmäßig auf. Erstens wird die Entscheidung rein über den Subskriptionspreis geführt, obwohl Schulung, Zertifizierung und Werkzeugketten den größeren Teil der Gesamtkosten ausmachen. Zweitens wird bestehende SAP-Landschaft ignoriert, obwohl SLES for SAP Applications mit Pacemaker-Ressource-Agents für HANA System Replication einen sehr konkreten Vorsprung hat. Drittens wird ein Hausstandard gesetzt, ohne die vorhandenen Skills zu prüfen, sodass ein Team mit RHCSA-Erfahrung plötzlich YaST, Zypper und Salt-basierte Verwaltung lernen soll oder umgekehrt.

Miniatur-Szene: drei Server-Podeste nebeneinander, davor eine Waage zum Vergleich zweier Optionen

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Entscheidungskriterien für den Enterprise-Linux-Standard

01 Workload und SAP-Anteil
02 Management-Ebene: Satellite oder Multi-Linux Manager
03 Container-Plattform: OpenShift oder Rancher Prime
04 Security-Modell: SELinux oder AppArmor
05 Support, Vertrag und Herstellersitz
06 Vorhandene Skills und Zertifizierungspfad

Was du mitnimmst

Wie du zu einer belastbaren Entscheidung kommst

Statt eines Featurevergleichs auf Paketebene hilft eine Bewertung entlang der Ebenen, die im Betrieb wirklich Arbeit machen. Die folgenden Punkte sind die Kriterien, die in unseren Projekten und Schulungen den Ausschlag geben.

Workload zuerst, Distribution danach

Wenn SAP HANA oder S/4HANA im Haus läuft, ist SLES for SAP Applications mit den vorbereiteten HA-Szenarien der kürzere Weg. Liegt der Schwerpunkt auf Container-Plattformen mit striktem Enterprise-Support, spielt OpenShift seine Stärken aus. Beides lässt sich nicht durch Preisverhandlung ausgleichen.

Management-Ebene bewerten, nicht nur den Server

Vergleiche Satellite und Multi-Linux Manager anhand deiner echten Anforderungen: Patch-Staging, Errata-Verwaltung, Air-Gap-Betrieb, Rollen- und Mandantentrennung. Wenn du eine gemischte Landschaft mit RHEL, SLES und Debian betreibst, ist die Fremd-Distributionsunterstützung des Multi-Linux Managers ein handfestes Argument.

Automatisierung und Konfigurationsmanagement festlegen

Ansible ist in beiden Welten praktikabel und in der Red-Hat-Welt zusätzlich zertifiziert eingebettet. Prüfe, ob dein Team Playbooks, Rollen und Inventare bereits sauber strukturiert, denn ohne diese Basis verschiebt kein Managementserver das Problem.

Security-Modell und Compliance klären

SELinux mit gezielt entwickelten Policy-Modulen und AppArmor-Profile lösen unterschiedlich viel Aufwand aus. Kläre früh, welche Härtungsvorgaben, CIS-Profile oder Auditanforderungen gelten und wer im Team sie umsetzen kann.

Support, Vertragslaufzeiten und Herkunft prüfen

Neben Reaktionszeiten und Eskalationswegen ist für viele Behörden und Konzerne relevant, wo Hersteller und Support sitzen. SUSE hat den Unternehmenssitz in Deutschland, Red Hat gehört zu IBM mit Sitz in den USA. Bewerte das anhand deiner eigenen Beschaffungs- und Souveränitätsvorgaben, nicht anhand von Marketingaussagen.

Skills und Zertifizierungspfad einplanen

Rechne die Qualifizierung von Anfang an mit ein. Auf der Red-Hat-Seite führt der Weg über RH124, RH134 oder den Schnelldurchlauf RH199 und weiter über AU294 für Ansible sowie DO180 und DO280 für OpenShift. Auf der SUSE-Seite über SLE201v15, SLE301v15, die High-Availability-Kurse und den Multi-Linux Manager. cmt führt beide offiziellen Kurswelten, sodass du dich nicht durch das Schulungsangebot in eine Richtung drängen lassen musst.

Tutorial

Der Testaufbau, der die Entscheidung wirklich beantwortet

Statt Featurelisten zu vergleichen, setzt du beide Systeme parallel auf und führst dieselben Betriebsaufgaben durch. Der Ablauf folgt der realen Reihenfolge: registrieren, patchen, automatisieren, härten und nachweisen. Am Ende steht ein Bewertungsraster mit Abbruchkriterien statt eines Bauchgefühls.

Beide Systeme in denselben Ausgangszustand bringen

Ein Vergleich taugt nur etwas, wenn die Bedingungen gleich sind. Gleiche Hardware oder gleich dimensionierte virtuelle Maschinen, gleiche Partitionierung, gleicher Patchstichtag.

Registrierung und Repos

# SLES: Registrierung, Status und verfügbare Erweiterungen
sudo SUSEConnect -r <registrierungscode>
sudo SUSEConnect --status-text
sudo SUSEConnect --list-extensions
zypper lr -u

# RHEL: Registrierung, Status und Repos
sudo subscription-manager register --activationkey=<aktivierungscode> --org=<organisation>
sudo subscription-manager status
sudo dnf repolist -v

Ohne Registrierung bekommst du auf beiden Seiten keine Updates, und ein ungepatchtes Testsystem beantwortet keine Betriebsfrage. Für Evaluierungen bieten beide Hersteller kostenfreie Test- beziehungsweise Entwicklerzugänge an, mit denen sich der komplette Ablauf durchspielen lässt.

Patchbetrieb im direkten Vergleich

Der Alltag besteht nicht aus Installationen, sondern aus Patchläufen. Übertrage eure bestehende Routine auf beide Systeme, dann siehst du sofort, wo das Team umlernen müsste.

Dieselbe Aufgabe, zwei Werkzeuge

Aufgabe	SLES mit zypper	RHEL mit dnf
Paket suchen	`zypper se muster`	`dnf search muster`
Welches Paket liefert eine Datei?	`zypper se --provides /pfad/zur/datei`	`dnf provides /pfad/zur/datei`
Repos anzeigen	`zypper lr -u`	`dnf repolist -v`
Nur Sicherheitsupdates	`zypper lp --category security`	`dnf updateinfo list security`
Welche Dienste brauchen einen Neustart?	`zypper ps -s`	`dnf needs-restarting -r`
Supportende einzelner Pakete	`zypper lifecycle`	kein direktes Gegenstück, Lebenszyklus je Release
Großer Versionssprung	`zypper migration`	`leapp preupgrade`, danach `leapp upgrade`

Patchlauf inklusive Neustartbedarf

# SLES
sudo zypper refresh
sudo zypper lp --category security
sudo zypper patch
sudo zypper ps -s          # Prozesse, die noch alte Bibliotheken benutzen

# RHEL
sudo dnf makecache
sudo dnf updateinfo list security
sudo dnf upgrade --security
sudo dnf needs-restarting -r   # Rückgabewert 1 bedeutet: Neustart nötig

zypper ps und dnf needs-restarting beantworten dieselbe Frage: Läuft noch ein Prozess mit einer Bibliothek, die gerade ersetzt wurde? Ohne diesen Schritt hast du zwar gepatcht, die Lücke bleibt aber im laufenden Dienst offen.

Installation und Konfiguration automatisieren

Die Frage ist selten, ob eine Distribution automatisierbar ist, sondern wie gut sie zu dem Werkzeug passt, das bei euch bereits läuft.

Unbeaufsichtigte Installation und ein gemeinsames Playbook

# SLES: AutoYaST-Profil beim Booten mitgeben
autoyast=http://<server>/profile/autoinst.xml

# RHEL: Kickstart-Datei beim Booten mitgeben
inst.ks=http://<server>/ks/rhel.ks

# Ein Playbook für beide Seiten: generisches Modul statt zypper oder dnf
- hosts: linux_alle
  become: true
  tasks:
    - name: Basispakete
      ansible.builtin.package:
        name: [chrony, tuned, rsyslog]
        state: present

    - name: Nur dort unterscheiden, wo die Namen abweichen
      ansible.builtin.debug:
        msg: "{{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_major_version'] }}"

ansible.builtin.package wählt selbst zypper oder dnf. Nutze es überall dort, wo die Paketnamen gleich sind, und weiche nur an den Stellen auf distributionsspezifische Aufgaben aus, an denen sie es nicht sind. Diese Ausnahmeliste ist am Ende eine sehr konkrete Entscheidungsgrundlage.

Die Managementebene gehört mit in den Test

Auf SUSE-Seite arbeitet der Multi-Linux Manager mit Salt und stammt aus dem Uyuni-Projekt.
Auf Red-Hat-Seite übernimmt Satellite diese Rolle, aufbauend auf Foreman und Katello.
Spiele genau eine Aufgabe durch: einen Patchstand einfrieren, ihn auf eine Testgruppe ausrollen, danach auf die Produktivgruppe. Wie umständlich das ist, bestimmt später euren Betriebsaufwand deutlich stärker als die Kommandozeile.

Härtung und Nachweis

Hier liegt der größte tatsächliche Unterschied im Alltag: das verpflichtende Zugriffsschutzmodell. Fast alles andere lässt sich auf beiden Seiten ähnlich lösen.

Welcher Schutzmechanismus ist aktiv?

# SLES: AppArmor
sudo aa-status
ls /etc/apparmor.d/

# RHEL: SELinux
sestatus
sudo semanage fcontext -l | head

# Auf beiden Seiten ohne Rätselraten
systemctl is-active apparmor 2>/dev/null
getenforce 2>/dev/null

AppArmor arbeitet pfadbasiert, SELinux labelbasiert. Praktisch heißt das: Ein AppArmor-Profil liest sich schneller und ist schneller geschrieben, es bricht aber genauso, wenn Daten an einen anderen Ort wandern. SELinux ist aufwendiger zu lernen und deckt dafür Fälle ab, die über Dateipfade hinausgehen. Entscheide danach, was euer Team dauerhaft betreiben kann.

Härtungsnachweis mit OpenSCAP

sudo zypper in openscap-utils scap-security-guide       # SLES
sudo dnf install openscap-scanner scap-security-guide   # RHEL

# Welche Profile enthält der Datastream?
oscap info /usr/share/xml/scap/ssg/content/<datastream>.xml

# Bewertung erzeugen
sudo oscap xccdf eval \
  --profile <profil-id> \
  --results ergebnis.xml --report ergebnis.html \
  /usr/share/xml/scap/ssg/content/<datastream>.xml

Der Bericht liegt auf beiden Seiten in derselben Form vor und ist damit ein echter Vergleichswert: gleiches Profil, gleiche Prüfpunkte, unterschiedliche Trefferquote im Auslieferungszustand. Im deutschen Kontext ist das auch der Anknüpfungspunkt an den IT-Grundschutz-Baustein SYS.1.3 zu Servern unter Linux und Unix, dessen Anforderungen du damit belegbar machst.

Bewertungsraster und Abbruchkriterien

Schreibe die Kriterien auf, bevor der Test beginnt. Sonst gewinnt am Ende die Distribution, mit der die lauteste Person im Raum bereits gearbeitet hat.

Was am Ende des Tests beantwortet sein muss

Eure drei wichtigsten Anwendungen liefen im Test, nicht nur ein leeres Betriebssystem.Eine Herstellerzertifizierung sagt nur, dass etwas unterstützt wird. Ob euer Betriebshandbuch dazu passt, zeigt erst der Lauf mit echten Daten und echten Schnittstellen.
Ein Service-Pack- beziehungsweise Minor-Wechsel ist einmal im Labor durchgespielt.Der teure Moment kommt nicht bei der Installation, sondern beim ersten großen Sprung zwei Jahre später. Wer ihn einmal gesehen hat, plant Wartungsfenster realistisch.
Die Systemverwaltung ist festgelegt, samt Aufwand für die Managementebene.Multi-Linux Manager und Satellite sind eigene Produkte mit eigenem Betrieb und eigenen Kosten. Sie fallen bei Vergleichen regelmäßig unter den Tisch und machen später einen erheblichen Teil des Aufwands aus.
Es steht fest, wer Subscriptions verwaltet und wie neue Systeme registriert werden.Nicht registrierte Systeme bekommen keine Updates. In kleinen Umgebungen fällt das erst auf, wenn ein Audit ansteht oder eine Lücke ausgenutzt wurde.
Der Schulungsbedarf ist benannt und terminiert, bevor der Rollout beginnt.Die Werkzeuge unterscheiden sich weit genug, dass eingespielte Abläufe nicht eins zu eins übertragbar sind. Wer das erst nach dem Rollout merkt, bezahlt es in Ausfallzeit.
Ein Abbruchkriterium wurde vor dem Test aufgeschrieben.Ohne vorher festgelegtes Ausschlusskriterium wird aus einem technischen Test eine Geschmacksfrage, und die Entscheidung lässt sich später niemandem mehr begründen.

Passende Kurse

Kurse zu SUSE und Red Hat bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

SUSE Linux Enterprise Server 15 Administration - SLE201v15 5 Tage Präsenz nächster Termin 09.11.2026 Zum Kurs RH124 Red Hat System Administration I 5 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs SUSE Linux Enterprise Server 15 Advanced Administration - SLE301v15 4 Tage Präsenz oder Live-Online nächster Termin 17.08.2026 Garantietermin Zum Kurs RH134 Red Hat System Administration II 5 Tage Präsenz nächster Termin 14.09.2026 Zum Kurs SUSE Multi-Linux Manager 5 Operations - SMGR201v5 3 Tage Präsenz nächster Termin 30.11.2026 Zum Kurs

Unverbindlich beraten lassen Alle SUSE-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest RHCSA Quiz Teste dein Wissen für die Red Hat Prüfung EX200: systemd, SELinux, firewalld, LVM, Podman und dnf. Quiz starten

Gut zu wissen

Häufige Fragen zu SUSE und Red Hat

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Was ist der wichtigste technische Unterschied zwischen SLES und RHEL?

Im Kern sind sich beide sehr ähnlich, weil sie denselben Kernel-Stamm, systemd und RPM nutzen. Die spürbaren Unterschiede liegen im Paketmanagement mit Zypper gegenüber DNF, im Standard-Dateisystem mit Btrfs und Snapper auf SLES gegenüber XFS auf RHEL, im Mandatory Access Control mit AppArmor gegenüber SELinux sowie in den Verwaltungswerkzeugen YaST und Cockpit.

Welche Distribution ist für SAP HANA die bessere Wahl?

SLES for SAP Applications ist historisch die verbreitetste Plattform für SAP HANA und bringt fertige Pacemaker-Ressource-Agents für HANA System Replication, angepasste Kernel-Parameter und Setup-Werkzeuge mit. RHEL for SAP Solutions ist ebenfalls von SAP zertifiziert und eine tragfähige Option, besonders wenn im Haus bereits RHEL-Standard und Satellite etabliert sind. Entscheidend ist, welche Plattform dein SAP-Betrieb und dein Hoster tatsächlich unterstützen.

Kann der SUSE Multi-Linux Manager auch RHEL-Systeme verwalten?

Ja. Der Multi-Linux Manager basiert auf Uyuni und verwaltet neben SLES auch RHEL, Ubuntu, Debian und weitere Distributionen über Salt-Minions. Red Hat Satellite ist dagegen auf das Red-Hat-Ökosystem ausgerichtet. In gemischten Landschaften ist das oft das ausschlaggebende Argument.

Lässt sich eine Migration von RHEL nach SLES oder umgekehrt sinnvoll durchführen?

Technisch ist eine Migration möglich, im Regelfall aber über Neuinstallation und automatisiertes Ausrollen der Konfiguration statt über einen In-Place-Wechsel. Der Aufwand steckt weniger im Betriebssystem als in Managementserver, Repositories, Härtungsvorgaben, Monitoring und den Skripten deines Teams. Plane die Umstellung deshalb als Plattformprojekt und nicht als Paketaustausch.

Welche Zertifizierung passt zu welcher Entscheidung?

Für RHEL führt der übliche Weg über den RHCSA, der auf RH124 und RH134 aufbaut, und danach über Ansible- und OpenShift-Kurse. Für SLES sind die offiziellen SUSE-Kurse zu Administration, Advanced Administration und High Availability der Standardweg. Wenn du herstellerneutral bleiben willst, sind LPIC-1 und LPIC-2 eine gute Grundlage, weil sie Wissen vermitteln, das auf beiden Plattformen trägt.

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.

Rückmeldung aus dem Kurs „SUSE Linux Enterprise 15 High Availability Deployment – HAE311v15“

“

Für den Einsteigerkurs ganz gut umgesetzt. Passt soweit und kann man ohne Bedenken weiter empfehlen.

Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.