Rechenzentrums-Autarkie: Ceph-Cluster und NVMe-over-Fabrics im Hochleistungsbetrieb

Über fast drei Jahrzehnte hinweg folgte die Speicherarchitektur in europäischen Unternehmensrechenzentren einem ungeschriebenen Gesetz: Wer geschäftskritische Datenbanken, ERP-Kernsysteme und hochverfügbare Virtualisierungs-Cluster betreiben wollte, kaufte monolithische Storage-Area-Network-Systeme (SAN) etablierter US-Hersteller wie Dell EMC, NetApp, Hitachi Vantara oder Pure Storage. Dedizierte Fibre-Channel-Netzwerke und paarweise verschaltete Spezial-Controller galten als einzige Versicherung gegen Datenverlust und I/O-Engpässe.

Doch dieses Architekturmodell ist technisch und kaufmännisch an seine Grenzen gestoßen. Mit dem Durchbruch von PCIe-Gen4- und PCIe-Gen5-NVMe-Laufwerken hat sich das Leistungsgefüge im Serverraum fundamental gedreht. Eine einzelne moderne Enterprise-NVMe-SSD liefert heute mehr als eine Million Ein-/Ausgabeoperationen pro Sekunde (IOPS) und übertrifft damit die Leistung kompletter Festplattenschränke früherer Generationen.

In klassischen Dual-Controller-Arrays wird diese enorme Rohleistung jedoch durch zentrale Flaschenhälse im Controller-Kopf und veraltete Protokoll-Schichten künstlich ausgebremst. Gleichzeitig nutzen die Hersteller ihre proprietäre Firmware-Hoheit, um sich jedes zusätzliche Terabyte zu Preisen vergüten zu lassen, die das Drei- bis Fünffache des realen Halbleiter-Marktwertes betragen.

Dieser Architekturleitfaden zeigt CIOs, Infrastruktur-Leitern und Systemarchitekten, wie Sie diese Abhängigkeit durch die Kombination aus Ceph (in den aktuellen Enterprise-Releases Reef und Squid) sowie NVMe-over-Fabrics (NVMe-oF) dauerhaft auflösen. Wir beleuchten das technische Zusammenspiel von BlueStore- und Crimson-OSDs, verlustfreien 100/200-GbE-Netzwerken und CRUSH-Ausfalldomänen und berechnen die Vollkosten im Fünfjahresvergleich.

Das Ende der Fibre-Channel-Ära: Warum klassische SAN-Arrays zum Engpass werden

Die wirtschaftliche Schmerzstelle traditioneller Enterprise-SAN-Umgebungen offenbart sich meist im vierten oder fünften Betriebsjahr. Sobald der ursprüngliche Wartungsvertrag ausläuft, heben die Hersteller die Gebühren für die Support-Verlängerung (Post-Warranty-Support) drastisch an. Dieses Preismodell ist gezielt darauf ausgelegt, den Weiterbetrieb funktionierender Bestands-Hardware unwirtschaftlich zu machen und den Kunden in einen kompletten Austausch der Anlage (Forklift-Upgrade) zu drängen.

Noch schwerer wiegt die künstliche Verknappung auf Komponentenebene. Obwohl führende Storage-Ausrüster intern dieselben NAND-Flash-Zellen von Samsung, Kioxia oder Micron verbauen wie jeder Standard-Serverhersteller, versehen sie die Laufwerke mit einer herstellerspezifischen Firmware-Signatur. Das Array verweigert den Dienst mit baugleichen Standard-Enterprise-SSDs, sodass Erweiterungs-Shelves mit enormen Aufschlägen sowie zusätzlichen Kapazitätslizenzen für Funktionen wie Snapshots, Replikation oder Verschlüsselung bezahlt werden müssen.

Auch technisch erweist sich die klassische Scale-Up-Architektur eines Dual-Controller-SANs in modernen Cloud- und Container-Umgebungen als Bremsklotz. Da sämtlicher Datenverkehr zwingend durch zwei zentrale Controller-Knoten geschleust werden muss, entsteht bei wachsenden parallelen Workloads aus Kubernetes-Clustern, Datenbanken und KI-Pipelines eine unvermeidbare CPU- und PCIe-Lane-Sättigung in den Controller-Köpfen.

Parallel dazu erfordert Fibre Channel (32G oder 64G FC) eine komplett isolierte Zweit-Infrastruktur aus eigenen Switches, speziellen Host-Bus-Adaptern (HBAs), eigenen Glasfaser-Verkabelungen und hochspezialisiertem Personal für das WWN-Zoning. In Zeiten von 100-, 200- und 400-Gigabit-Ethernet verliert dieses Sonder-Netzwerk sowohl seinen früheren Bandbreitenvorsprung als auch seine wirtschaftliche Berechtigung.

Wer eine wirklich souveräne Rechenzentrums-Infrastruktur nach dem Vorbild des Sovereign Cloud Stack (SCS) aufbaut, muss Rechenleistung, Netzwerk und Datenspeicherung auf standardisierter x86- oder ARM-Serverhardware zusammenführen. Erst die konsequente Entkopplung der Speichersoftware vom Blech schafft jene Verhandlungsmacht im Einkauf, die langfristige Kostensicherheit garantiert.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cloud-Exit-Strategie im Enterprise-Einsatz sowie zu Lift-and-Shift-Sanierung im Enterprise-Einsatz.

Technischer Deep-Dive: Ceph Reef/Squid, BlueStore, Crimson und NVMe-oF

Das architektonische Fundament dieser Befreiung bildet Ceph als verteiltes Unified-Storage-System, das Block-Storage (RBD), POSIX-kompatible Dateisysteme (CephFS) und S3-kompatiblen Objektspeicher (RADOS Gateway) in einem einzigen Software-Cluster vereint. Im Gegensatz zu traditionellen Speichersystemen verzichtet Ceph vollständig auf zentrale Metadaten-Tabellen oder Hardware-RAID-Controller.

Stattdessen nutzt Ceph den deterministischen CRUSH-Algorithmus (Controlled Replication Under Scalable Hashing). Jeder Client und jeder Speicherknoten berechnet anhand einer kompakten Cluster-Topologiekarte (CRUSH Map) und definierter Platzierungsregeln in Echtzeit selbstständig, auf welchem Object Storage Daemon (OSD) ein angeforderter 4-Megabyte-Datenblock liegt. Dadurch skaliert ein Ceph-Cluster von vier Einstiegsknoten bis auf mehrere tausend Server ohne zentralen Flaschenhals linear mit.

Von BlueStore zur neuen Crimson/SeaStore-Engine und PLP-Pflicht

Auf den einzelnen Speicherknoten verwaltet das bewährte BlueStore-Backend jedes physische NVMe-Laufwerk direkt als rohes Blockgerät ohne zwischengeschaltetes Linux-Dateisystem wie XFS oder ext4. Während die Nutzdaten unmittelbar auf die Flash-Blöcke geschrieben werden, legt BlueStore sämtliche internen Metadaten und Write-Ahead-Logs (WAL) in einer eingebetteten RocksDB-Instanz ab, wodurch doppelte Schreibzugriffe (Write Amplification) vermieden werden.

Mit den aktuellen Ceph-Generationen Reef (18.2) und Squid (19.2) hält zudem schrittweise das neuentwickelte Crimson-OSD-Projekt mit dem SeaStore-Backend Einzug. Während klassische OSD-Prozesse durch Thread-Kontextwechsel und Sperrmechanismen bei extrem schnellen PCIe-Gen5-Drives an CPU-Grenzen stoßen, nutzt Crimson das asynchrone Seastar-Framework nach dem Shared-Nothing-Prinzip, bei dem jeder zugewiesene CPU-Kern seine I/O-Queues komplett sperrfrei abarbeitet.

Unverzichtbare Hardware-Voraussetzung für jeden produktiven Ceph-Knoten sind dabei zertifizierte Datacenter-NVMe-SSDs (etwa im U.2/U.3- oder E1.S/E3.S-Formfaktor) mit mindestens 1 bis 3 Drive Writes Per Day (DWPD) und integrierter Power-Loss-Protection (PLP). Nur wenn Tantalkondensatoren auf der SSD garantieren, dass der flüchtige Schreibcache bei Stromausfall noch sicher in die NAND-Zellen geschrieben wird, kann Ceph synchrone O_DSYNC-Schreibbefehle in wenigen Mikrosekunden quittieren.

„Wer moderne PCIe-Gen5-NVMe-Laufwerke noch hinter proprietären Dual-Controller-Arrays und Fibre-Channel-Protokollen einsperrt, bezahlt den dreifachen Hardwarepreis für einen künstlichen Flaschenhals. Erst Ceph und NVMe-over-Fabrics legen die wahre Parallelität von Flash-Speicher im Rechenzentrum frei.“

Auf der Zugriffsseite ergänzt das in Ceph Reef und Squid massiv ausgebaute NVMe-over-Fabrics-Gateway (auf Basis des Storage Performance Development Kits, SPDK) das native librbd-Protokoll. Damit lassen sich Ceph-Block-Volumes als standardisierte NVMe-oF-Namespaces bereitstellen, sodass auch Betriebssysteme und Hypervisoren ohne nativen Ceph-Client mit voller NVMe-Queue-Parallelität (bis zu 64.000 Queues mit je 64.000 Kommandos) auf den Cluster zugreifen können.

NVMe/TCP versus NVMe/RDMA (RoCEv2) und 100/200-GbE Leaf-Spine-Fabrics

Für den Transport über das Rechenzentrumsnetzwerk stehen Systemarchitekten zwei hochperformante NVMe-oF-Ausprägungen zur Verfügung. Die erste Option ist NVMe/TCP: Es kapselt die NVMe-Submission- und Completion-Queues direkt in reguläre TCP/IP-Pakete. Da es ohne spezielle Switch-Konfigurationen auf jeder bestehenden 25- oder 100-GbE-Infrastruktur läuft und dennoch Latenzen von rund 150 bis 250 Mikrosekunden erreicht, hat sich NVMe/TCP als robuster Standard für große Enterprise-Umgebungen etabliert.

Wo für hochfrequente OLTP-Datenbanken oder KI-Trainingscluster das absolute Latenzminimum unter 80 Mikrosekunden gefordert ist, greift die zweite Option: NVMe over RDMA mittels RoCEv2 (RDMA over Converged Ethernet v2). Hierbei übertragen RDMA-fähige Netzwerkkarten (wie NVIDIA ConnectX-6/7 oder Intel E810) Speicherblöcke per Kernel-Bypass direkt zwischen dem Arbeitsspeicher des Storage-Knotens und dem RAM des Compute-Servers, ohne die Host-CPUs mit TCP-Interrupts zu belasten.

Damit sowohl Client-Zugriffe als auch die permanente Hintergrund-Replikation und Selbstheilung der OSDs niemals miteinander um Bandbreite konkurrieren, wird ein Enterprise-Ceph-Cluster auf einer blockierungsfreien 100- oder 200-GbE-Leaf-Spine-Topologie (CLOS-Architektur) aufgebaut. Best Practice ist die strikte logische und physische Trennung in ein Frontend-Netzwerk (Public Network für Clients und Monitore) und ein dediziertes Backend-Replikationsnetzwerk (Cluster Network für OSD-Heartbeat und Datenabgleich) mit aktivierten Jumbo-Frames (MTU 9000).

CRUSH-Failure-Domains, 3x-Replikation versus Erasure Coding und Praxisszenarien

Die Resilienz des Clusters wird deklarativ über die CRUSH-Hierarchie gesteuert, die physische Standorte in Raum-, Brandabschnitts-, Rack-, Chassis- und Host-Ebenen abbildet. Für latenzkritische Datenbank- und VM-Pools setzen Architekten auf eine dreifache synchrone Replikation (size=3, min_size=2) mit der Failure-Domain Rack oder Room: Jeder Schreibvorgang wird erst quittiert, wenn die Kopien auf drei unabhängigen Racks bzw. Brandabschnitten persistent auf NVMe-PLP-Medien liegen.

Für kapazitätsintensive Workloads wie S3-Objektspeicher, Data Lakes, medizinische Bildarchive oder Backup-Repositories kommt hingegen Erasure Coding (beispielsweise im Profil k=4, m=2 oder k=8, m=3) direkt auf schnellen Flash-Pools zum Einsatz. Dabei wird jedes Datenobjekt in Daten- und Paritätsfragmente zerlegt, sodass bei gleicher Ausfallsicherheit von zwei bis drei kompletten Server-Racks lediglich ein Speicher-Overhead von 37 bis 50 Prozent statt 200 Prozent anfällt.

In der europäischen Praxis bewährt sich diese Architektur längst in den anspruchsvollsten Branchen: Kreditinstitute und Zahlungsdienstleister betreiben darauf hochkonsistente Transaktionsdatenbanken über getrennte Brandabschnitte hinweg, während Universitätskliniken und Genomforschungszentren Petabytes an hochauflösenden MRT-Sequenzen gleichzeitig über CephFS und S3 verarbeiten. Auch Telekommunikationsanbieter für 5G-Core-Netze sowie die Automobilindustrie beim Ingest von Terabytes an Sensordaten aus Testflotten für autonomes Fahren setzen auf diese kombinierte Block-, Datei- und Objekt-Plattform.

Architektur- und Leistungsvergleich: Fibre-Channel-SAN versus Ceph NVMe-oF

Um im IT-Architekturboard eine objektive Entscheidung zwischen der Verlängerung proprietärer SAN-Landschaften und dem Aufbau einer softwaredefinierten Ceph-NVMe-oF-Fabric zu treffen, müssen Latenz, Skalierungsverhalten, Ausfallsicherheit und Lizenzmechanik direkt gegenübergestellt werden.

Die folgende Bloomberg-Radar-Matrix vergleicht ein klassisches Dual-Controller-All-Flash-SAN (32/64G Fibre Channel) mit einem modernen Ceph-Enterprise-Cluster (Reef/Squid) über 100/200-GbE NVMe-over-Fabrics anhand der fünf wichtigsten Entscheidungskriterien für den CIO:

Der direkte Architekturvergleich verdeutlicht, warum das klassische SAN-Modell vor allem bei wachsenden Datenbeständen ins Hintertreffen gerät. Während in einem herkömmlichen Array beim Ausfall einer großen 15,36-TB- oder 30,72-TB-NVMe-SSD ein stundenlanger RAID-Rebuild auf wenigen Nachbarlaufwerken desselben Einschubs lastet, verteilt Ceph die Wiederherstellung der fehlenden Placement Groups (PGs) gleichzeitig auf dutzende OSDs im gesamten Cluster.

Ebenso entfällt die harte Trennung zwischen verschiedenen Speichergattungen. Ob virtuelle Maschinen unter KVM und Proxmox VE ultraschnellen Blockspeicher über RBD bzw. NVMe-oF anfordern, Kubernetes-Container über den CSI-Treiber persistente CephFS-Volumes mounten oder Backup-Suiten unveränderbare S3-Buckets beschreiben: Alle Dienste schöpfen aus demselben physischen NVMe-Pool ohne isolierte Kapazitätsinseln.

Vollkostenrechnung über 60 Monate: 1 Petabyte Nettokapazität im TCO-Vergleich

Um die kaufmännische Tragweite für den Finanzvorstand (CFO) präzise zu beziffern, kalkulieren wir eine typische Enterprise-Anforderung über einen Betrachtungszeitraum von 60 Monaten (fünf Jahren). Gefordert ist eine hochverfügbare All-Flash-Speicherumgebung mit 1,0 Petabyte nutzbarer Nettokapazität, ausgelegt für geschäftskritische Datenbanken, Virtualisierung und S3-Datenhaltung über zwei Brandabschnitte inklusive einer Kapazitätserweiterung um 500 Terabyte im dritten Betriebsjahr.

Bei der Beschaffung eines proprietären Tier-1-Enterprise-All-Flash-SANs (redundante Active/Active-Arrays für Spiegelung über zwei Brandabschnitte inklusive 64G-Fibre-Channel-Director-Switches) liegt der reale Einkaufspreis nach Hersteller-Rabatten bei rund 780.000 Euro. Hinzu kommen fünf Jahre Hersteller-Wartung und Software-Subscription (jährlich rund 14 Prozent, also 546.000 Euro) sowie das Nachkauf-Upgrade von 500 TB im Jahr 3 mit zertifizierten Hersteller-Drives für weitere 340.000 Euro, was sich über fünf Jahre auf Gesamtkosten von 1.666.000 Euro summiert.

Stellt man dieser Rechnung einen redundanten Ceph-NVMe-oF-Cluster aus zwölf 1U/2U-Standard-Servern (etwa Dell PowerEdge, HPE ProLiant, Lenovo oder Supermicro) mit insgesamt 144 Enterprise-NVMe-PLP-Laufwerken (je 15,36 TB Rohkapazität für ~2,2 PB Raw inkl. 3x-Replikation und Erasure-Coding-Mix) sowie vier 100/200-GbE-Leaf-Spine-Switches gegenüber, beträgt die initiale Hardware-Investition lediglich rund 265.000 Euro.

Selbst wenn das Unternehmen für höchste Betriebssicherheit eine kommerzielle Enterprise-Ceph-Subscription bzw. ein spezialisiertes 24/7-Systemhaus-SLA für 38.000 Euro pro Jahr (190.000 Euro über fünf Jahre) abschließt und im dritten Jahr die 500-TB-Erweiterung über frei am Markt gekaufte Enterprise-NVMe-SSDs für 85.000 Euro realisiert, liegen die Fünfjahresgesamtkosten bei exakt 540.000 Euro. Das entspricht einer Netto-Einsparung von 1.126.000 Euro (rund 68 Prozent TCO-Senkung), wie auch unser übergreifender 5-Jahres-TCO-Vergleich zwischen Rechenzentrums-Eigenbetrieb und Hyperscalern untermauert.

Die Make-or-Buy Sourcing-Weiche und regulatorische Resilienz unter DORA^** und NIS-2

Ein verteiltes Speichersystem wie Ceph ersetzt teure proprietäre Hardware-Logik durch intelligente Software und Netzwerkarchitektur. Damit diese Freiheit im operativen Betrieb nicht an fehlender Site-Reliability-Engineering-Erfahrung (SRE) scheitert, sollten CIOs die Bereitstellung strikt entlang der internen Linux- und Netzwerk-Kompetenz unterteilen.

Erstens (Eigenbetrieb auf Proxmox VE): Für mittelständische Rechenzentren mit 4 bis 25 Knoten, die im Zuge des VMware-Exits zu Proxmox VE und Ceph wechseln, ist die direkt in Proxmox integrierte Ceph-Verwaltung der effizienteste Weg. Bereitstellung, OSD-Rollout, Monitoring und Upgrades erfolgen konsistent über die Proxmox-GUI und CLI, abgesichert durch einen einheitlichen europäischen Hersteller-Supportvertrag pro Server-Sockel.

Zweitens (Dedizierte Ceph-Fabric): Organisationen ab 500 Terabyte bis in den zweistelligen Petabyte-Bereich, die neben KVM/Proxmox auch große Bare-Metal-Datenbanken, OpenStack-Umgebungen oder Kubernetes-Farmen über NVMe-oF und S3 versorgen, betreiben ein eigenständiges Ceph-Cluster via cephadm-Orchestrierung. Die Absicherung erfolgt über kommerzielle Enterprise-Subscriptions (etwa IBM/Red Hat Ceph Storage, Canonical Ubuntu Ceph oder spezialisierte europäische Open-Source-Systemhäuser wie Croit oder Heinlein/B1 Systems) mit garantierten 24/7-Reaktionszeiten.

Drittens (Managed-Storage-Betrieb): Unternehmen mit schlanker eigener Betriebsmannschaft beziehen dedizierte Ceph-NVMe-Cluster als Managed Infrastructure in deutschen Tier-3/Tier-4-Colocation-Rechenzentren. Entscheidend für die Einkaufsrichtlinie in allen drei Pfaden ist das strikte Verbot klassischer Hardware-RAID-Controller: Ceph benötigt zwingend reine NVMe-Backplanes oder Host-Bus-Adapter (HBAs) im direkten IT-Pass-Through-Modus, damit BlueStore unmittelbaren physischen Durchgriff auf jedes einzelne Laufwerk hat.

Gleichzeitig erfüllt eine sauber geschnittene Ceph-Architektur höchste regulatorische Anforderungen nach DORA (Verordnung EU 2022/2554), NIS-2 und BSI IT-Grundschutz (Bausteine SYS.1.1 Allgemeiner Server und OPS.1.2.2 Archivierung). Ruhende Daten werden auf OSD-Ebene transparent über LUKS und dm-crypt mit hardwarebeschleunigtem AES-XTS-256 verschlüsselt, wobei die Schlüssel getrennt in externen Key-Management-Systemen (etwa HashiCorp Vault oder KMIP-HSMs) verwaltet werden.

Für den unveränderbaren Schutz vor Ransomware-Manipulationen und die Einhaltung steuerrechtlicher GoBD-Aufbewahrungspflichten stellt das Ceph Object Gateway (RGW) standardkonformes S3 Object Lock im Compliance-Modus bereit. Einmal mit einer Aufbewahrungsfrist versehene Backup- und Archiv-Objekte sind auf Speicherebene strikt nach dem WORM-Prinzip (Write Once, Read Many) gesperrt und können selbst mit höchsten Administratorenrechten vor Ablauf der Frist weder überschrieben noch gelöscht werden.

Der 4-Phasen-Umsetzungsfahrplan: Vom Legacy-SAN zur autonomen NVMe-Fabric

Die Ablösung eines gewachsenen Fibre-Channel-SANs erfolgt niemals im riskanten Big-Bang-Verfahren an einem einzigen Wochenende. In der Enterprise-Praxis hat sich ein strukturierter Vier-Phasen-Migrationsplan über drei bis sechs Monate bewährt, der Leistung und Ausfallsicherheit vor dem ersten produktiven Datenumzug lückenlos beweist.

Phase 1 (Woche 1 bis 4): I/O-Profiling, Hardware-Sizing und Lossless-Switch-Design

Zu Beginn erfasst das Architekturteam die realen Spitzenlasten des Bestands-SANs hinsichtlich IOPS, Lese-/Schreib-Verhältnis, Blockgrößen und 99,9-Perzentil-Latenzen. Darauf aufbauend werden die Serverknoten mit PLP-geschützten Enterprise-NVMe-SSDs sowie die redundanten 100/200-GbE-Leaf-Spine-Switches beschafft und hinsichtlich MTU 9000, LACP/BGP-EVPN sowie (bei Wahl von RoCEv2) verlustfreiem PFC und ECN vorkonfiguriert.

Phase 2 (Woche 5 bis 8): Cluster-Bootstrapping, CRUSH-Regeln und FIO-Abnahmetests

Mithilfe von cephadm (bzw. der Proxmox-Ceph-Integration) werden die Monitor-, Manager-, OSD- und NVMe-oF-Gateway-Dienste ausgerollt und die CRUSH-Failure-Domains exakt auf die physischen Racks und Brandabschnitte abgebildet. Bevor ein einziges produktives Byte auf dem Cluster landet, durchläuft die Anlage mehrtägige synthetische FIO-Belastungstests sowie reale Chaos-Tests, bei denen im laufenden Schreibbetrieb gezielt NVMe-Drives, Switch-Uplinks und ganze Serverknoten gezogen werden.

Phase 3 (Woche 9 bis 16): Online-Storage-Migration und S3-Object-Lock-Kopplung

Nach bestandener Abnahme wird das neue Ceph-Cluster parallel zum bestehenden SAN an die Hypervisor- und Datenbank-Hosts angebunden. Über Live-Storage-Motion (unter Proxmox VE, KVM oder noch laufenden vSphere-Knoten via NVMe-oF) sowie native Datenbank-Replikation wandern die produktiven Volumes im Hintergrund ohne Applikationsausfall auf die neuen NVMe-Pools, während Backup-Server ihre Immutable-Snapshots auf das neue Ceph-S3-Gateway richten.

Phase 4 (Woche 17 bis 24): Produktiv-Cutover, Telemetrie-Härtung und SAN-Stilllegung

Sobald sämtliche Workloads stabil auf der neuen Speicher-Fabric laufen und das Prometheus/Grafana-Monitoring inklusive automatisierter SMART- und Latenz-Alarmierung im 24/7-Betriebsteam verankert ist, werden die alten Fibre-Channel-LUNs ausgehängt. Die abgeschriebenen SAN-Arrays und FC-Switches werden rechtzeitig vor dem Stichtag der nächsten Wartungsverlängerung sicher gelöscht und außer Betrieb genommen, wodurch zusätzlich beträchtliche Strom- und Kühlkosten im Rack entfallen.

Fünf Kontrollfragen für Vorstand und IT-Leitung vor der Speicher-Transformation

1. Wann laufen die bestehenden SAN-Wartungsverträge aus und wie hoch ist der Post-Warranty-Aufschlag?

Fordern Sie vom Einkauf eine vollständige Übersicht aller Speicher-Arrays inklusive der anstehenden Support-Verlängerungsangebote für das vierte bis sechste Betriebsjahr an. In der Regel übersteigen allein zwei Jahre verlängerter Hersteller-Wartung für ein Bestands-SAN bereits die gesamten Hardware-Anschaffungskosten eines neuen, doppelt so schnellen Ceph-NVMe-Clusters.

2. Sind in der Ausschreibung zwingend Enterprise-NVMe-SSDs mit Power-Loss-Protection (PLP) vorgeschrieben?

Prüfen Sie die Hardware-Stücklisten Ihrer Serverlieferanten kompromisslos auf echte Datacenter-NVMe-Laufwerke mit physischen Stützkondensatoren (PLP) und dokumentierter Dauerlastfestigkeit (mindestens 1 bis 3 DWPD). Ohne PLP bricht die synchrone Schreibleistung unter Ceph BlueStore um bis zu 90 Prozent ein, was im Nachgang nur durch einen kostspieligen Austausch aller SSDs korrigiert werden kann.

3. Ist das Rechenzentrumsnetzwerk sauber in Public- und Cluster-Traffic auf 100/200-GbE-Basis getrennt?

Stellen Sie sicher, dass die Netzwerkarchitektur genügend 100- oder 200-GbE-Switch-Ports bereitstellt, um den eingehenden Client-Datenverkehr strikt vom internen OSD-Replikations- und Selbstheilungsverkehr zu isolieren. Nur so bleibt die Antwortzeit für geschäftskritische Datenbanken auch dann im Mikrosekundenbereich, wenn der Cluster nach einem Serverausfall im Hintergrund mehrere Terabyte neu verteilt.

4. Soll der Zugriff über leicht beherrschbares NVMe/TCP oder über latenzminimiertes RoCEv2 (RDMA) erfolgen?

Treffen Sie eine bewusste Architekturentscheidung gemeinsam mit Ihrem Netzwerkteam: Während NVMe/TCP auf jedem modernen Ethernet-Switch sofort stabil läuft und für 95 Prozent aller Enterprise-Workloads mehr als ausreichende Performance liefert, lohnt sich der zusätzliche Konfigurationsaufwand für RoCEv2 (PFC/ECN) vor allem bei extrem latenzkritischen In-Memory- und Hochfrequenz-Datenbanken.

5. Bildet die CRUSH-Map Ihre realen physischen Brandabschnitte und Stromversorgungszonen korrekt ab?

Vergewissern Sie sich vor dem Produktivstart, dass die logischen Platzierungsregeln der CRUSH-Map exakt mit der physischen Topologie Ihres Rechenzentrums übereinstimmen. Erst wenn jedes der drei Replikate garantiert in einem anderen Rack mit getrennter A/B-Stromzuführung bzw. in einem getrennten Brandabschnitt liegt, erreicht der Cluster echte Katastrophen-Resilienz.

Strategisches Fazit: Vom proprietären Speichersilo zur souveränen Daten-Fabric

Die Ablösung monolithischer Fibre-Channel-SANs durch Ceph und NVMe-over-Fabrics ist weit mehr als eine technische Modernisierung der untersten Infrastrukturschicht. Sie beendet eines der kostspieligsten Abhängigkeitsverhältnisse der Unternehmens-IT, bei dem Organisationen über Jahrzehnte hinweg gezwungen waren, handelsüblichen Flash-Speicher und Standard-Softwarefunktionen mit extremen Monopolmargen zu bezahlen.

Wer heute auf offene Enterprise-Server, PLP-geschützte Standard-NVMe-Laufwerke, 100/200-GbE-Netzwerke und die ausgereifte Ceph-Architektur setzt, gewinnt die volle technologische und kaufmännische Autarkie über sein Rechenzentrum zurück. Unternehmen senken ihre Speicher-Vollkosten dauerhaft um über 60 Prozent, beseitigen zentrale Controller-Flaschenhälse und schaffen ein selbstheilendes, DORA-konformes Fundament für das kommende Jahrzehnt.

Häufig gestellte Fragen (FAQ) zu Ceph und NVMe-over-Fabrics