# SUSE Enterprise Storage: Das Software-Defined Data Center

TL;DR / Management Summary SUSE Enterprise Storage (SES) ist die kommerzielle, gehärtete Version des Open-Source Projekts Ceph. Es bietet Unified Storage (Block, File und Object) auf Standard-x86-Hardware. SES skaliert von wenigen Terabytes bis in den Petabyte-Bereich und eliminiert teure, proprietäre SAN-Hardware. Wer SES unter SLES beherrscht, baut Storage-Infrastrukturen, die keine “Single Points of Failure” mehr kennen.

# 1. Einführung & Architektur

Alles ist ein Objekt.

Ceph speichert Daten als Objekte in einem flachen Adressraum. Die Intelligenz liegt beim Client und den OSDs (Object Storage Dämons), die via CRUSH-Algorithmus berechnen, wo Daten liegen – ohne zentralen Lookup-Server.

# Die SES-Architektur (Mermaid)

graph TD
    A[Clients: S3 / iSCSI / CephFS] --> B[RADOS Cluster]
    subgraph "Ceph Core"
        B --> C[MON: Monitors - Quorum]
        B --> D[MGR: Managers - Stats]
        B --> E[OSD: Object Storage Daemons - Disks]
    end
    E --- F[Physical Disk 1]
    E --- G[Physical Disk 2]
    E --- H[Physical Disk N]

# 2. Deployment mit DeepSea (Salt)

Automatisierung ab Werk.

SUSE nutzt traditionell DeepSea (ein Set aus Salt-Formulas), um SES-Cluster zu provisionieren.

# Der Deployment-Workflow

1. Stage 0: Discovery (Minions beim Salt-Master registrieren).
2. Stage 1: Infrastruktur-Setup (Repositories, NTP).
3. Stage 2: Ceph-Konfiguration generieren.
4. Stage 3: Deployment der Dämons (MONs, MGRs, OSDs).

# Start des Deployments am Salt Master
salt-run state.orch ceph.stage.3

# 3. Die SES-Schnittstellen

Ein Pool für alles.

• RBD (RADOS Block Device): Für VMs (Proxmox/OpenStack). Schnell und Snapshot-fähig.
• CephFS: Ein verteiltes POSIX-Dateisystem.
• RGW (RADOS Gateway): S3-kompatibler Object-Store für moderne Web-Apps.

# 4. Day-2 Operations: Monitoring & Health

Den Puls des Clusters fühlen.

SES liefert ein Dashboard (basiert auf Ceph Dashboard) mit, das tief in SLES integriert ist.

# Health Check via CLI

# Der wichtigste Befehl
ceph -s

Achten Sie auf HEALTH_OK. Warnungen wie HEALTH_WARN deuten oft auf fehlende Replikation oder ausgefallene Disks hin.

# 5. Troubleshooting & “War Stories”

Wenn der Cluster ‘rebalanced’.

# Story 1: “Der hängende OSD nach Disk-Tausch”

Symptom: Eine Disk wurde getauscht, aber Ceph beginnt nicht mit dem Wiederaufbau (Recovery). Der Status bleibt auf degraded. Ursache: Die neue Disk hat noch alte Partitionstabellen oder der OSD-Dienst wurde nicht sauber initialisiert. Lösung: Bereinigen Sie die Disk mit ceph-volume lvm zap /dev/sdX und fügen Sie das OSD via DeepSea oder Orchestrator neu hinzu.

# Story 2: “Das langsame Netzwerk-Killer”

Symptom: Die I/O-Performance bricht massiv ein, obwohl die Disks (SSDs) gelangweilt sind. Ursache: Ceph nutzt das Netzwerk für die Replikation. Wenn das Backend-Netzwerk (Replication Network) auf 1Gbit/s limitiert ist oder hohe Latenzen hat, warten alle Schreibvorgänge auf die Bestätigung der anderen Nodes. Lösung: Nutzen Sie immer ein separates 10G/25G Netzwerk für den internen Ceph-Traffic.

# 6. Fazit & Empfehlung

• Hardware: Nutzen Sie identische Server-Konfigurationen für die OSD-Nodes.
• Quorum: Betreiben Sie immer eine ungerade Anzahl an Monitoren (mind. 3).
• Wahl: SES ist die perfekte Ergänzung für SLES-basierte Private Clouds. Für kleine Setups (< 3 Nodes) ist SES oft zu komplex – nutzen Sie dort lokales ZFS (Artikel 023).

# Anhang: Cheatsheet