Enterprise-Storage ohne Enterprise-Preise? Das Ceph-Versprechen.

Willkommen bei IT for Business. Ich bin Mirko Peters.

Wir sind IT-Dienstleister für den Mittelstand, und hier geht es nicht um Produkte oder Hypes, sondern um echte IT-Entscheidungen: Infrastruktur, Cloud, Security und Architektur aus der Praxis.

Wenn Sie Verantwortung für IT tragen, Entscheidungen treffen oder Dienstleister bewerten, dann sind Sie hier richtig.

Und wenn Sie sich zu den Themen austauschen wollen, vernetzen Sie sich gerne mit mir auf LinkedIn, ich freue mich über den Austausch aus der Praxis.

Hier ist die eigentliche Frage: Was kostet Enterprise-Storage wirklich, wenn die Rechnung nicht im Angebot steht, sondern erst nach dem Go-Live auftaucht?

Ceph klingt erst einmal sehr vernünftig. Shared Storage im Cluster. Hochverfügbarkeit. Standard-Hardware statt Spezial-Array. Weniger Vendor Lock-in. Im Proxmox-Umfeld ist das ein Versprechen, das viele gerade sehr gerne hören.

Aber Open Source heißt noch lange nicht billig, einfach oder betriebssicher. Da versteckt sich das Risiko.

In dieser Folge schauen wir uns deshalb nicht nur die Technik an, sondern die wirtschaftliche Logik dahinter, die technischen Mindestanforderungen, die Risiken im Betrieb und am Ende einen klaren Entscheidungsrahmen für den Mittelstand.

Wir beginnen mit dem Versprechen selbst, dann mit der echten Kostenstruktur, danach mit der Betriebsrealität und am Schluss mit der Frage, wann Ceph strategisch stark ist und wann eben nicht.

Lassen Sie uns zuerst die Frage klären, warum Ceph überhaupt so attraktiv wirkt.

1. Das Versprechen hinter Ceph: Enterprise-Funktionen ohne klassisches SAN

Seien wir ehrlich: Viele Mittelständler sind Storage-seitig in einer unangenehmen Lage. Die Lizenzkosten steigen. Erweiterungen werden teuer. Und wenn ein klassisches Array einmal im Haus steht, folgt oft der Rest fast automatisch mit, weil Sie in den Pfad des Herstellers geraten. Mehr Kapazität bedeutet dann nicht einfach nur mehr Platten, sondern Freigaben, Kompatibilitäten, Controller-Grenzen und im Zweifel ein neues Preisschild, das niemand wirklich vermisst hat.

Genau an dieser Stelle wirkt Ceph wie ein Gegenentwurf. Und das ist erst einmal nicht falsch.

Ceph ist vereinfacht gesagt ein verteilter Storage-Verbund. Die Daten liegen nicht auf einem zentralen Storage-System, sondern verteilt über mehrere Knoten. Dabei werden Daten mehrfach abgelegt, damit beim Ausfall eines Knotens nicht gleich der Betrieb steht. Für den Proxmox-Cluster entsteht dadurch eine gemeinsame Storage-Basis, auf die mehrere Hosts zugreifen können.

Das ist der Punkt, an dem es für viele interessant wird. Sie haben dann nicht mehr das klassische Modell aus Compute auf der einen Seite und externem SAN auf der anderen. Stattdessen bauen Sie den Storage in die Cluster-Architektur selbst ein. Also näher an die Plattform, näher an die Workloads und näher an Ihre eigene Gestaltungshoheit.

Was wirtschaftlich daran reizvoll ist, liegt auf der Hand. Sie kaufen nicht zwingend eine proprietäre Appliance mit festem Erweiterungspfad, sondern setzen auf Standard-Hardware. Architektur schlägt Tools. Und in diesem Fall schlägt Architektur eben oft auch das Hersteller-Ökosystem.

Im Proxmox-Umfeld ist das besonders greifbar. Wenn Ceph sauber geplant und sauber betrieben wird, bekommen Sie Funktionen, die viele Unternehmen sonst nur aus klassischen Enterprise-Storage-Welten kennen. Live-Migration von VMs. Hochverfügbarkeit im Cluster. Kein externer SAN-Zwang, nur damit virtuelle Maschinen im Fehlerfall auf einem anderen Host starten können. Die VM-Festplatten liegen nicht an einem einzelnen Server fest, sondern sind als gemeinsamer Storage im Cluster verfügbar.

Für Wartung und Betrieb ist das ein echter Unterschied. Sie können Lasten verschieben, Hosts geplanten Wartungen unterziehen und im Fehlerfall schneller reagieren, ohne jedes Mal den ganzen Unterbau neu zu organisieren. Das ist kein Marketingpunkt. Das ist ein betrieblicher Vorteil, wenn die Anforderungen dazu passen.

Betrachten Sie es wie ein Betriebsgelände mit nur einem Haupttor gegenüber mehreren Zufahrten. Beim klassischen Array läuft fast alles durch einen zentralen Zugang, auch wenn dahinter viel Redundanz steckt. Bei Ceph ist der Zugriff verteilt, der Storage ist nicht auf einen einzelnen Kasten konzentriert, sondern Teil des gesamten Systems. Das verändert nicht nur die Technik, sondern auch die Abhängigkeiten.

Nun kommt der Teil, über den Anbieter gern zu schnell hinweggehen. Dieses Versprechen ist real, aber nur dann, wenn Sie fair vergleichen. Also nicht eine fertig integrierte Enterprise-Appliance mit Support, Herstellerverantwortung und klaren Betriebsgrenzen gegen eine lose zusammengestellte Eigenkonstruktion, die auf dem Papier billig aussieht. Das ist kein sauberer Vergleich. Das ist Wunschdenken mit Excel.

Was bedeutet das konkret für Sie? Ceph kann Ihnen tatsächlich Enterprise-Funktionen ohne klassische Enterprise-Storage-Preise näherbringen. Aber nur dann, wenn Sie nicht den Fehler machen, Open Source mit kostenlos und Standard-Hardware mit beliebiger Hardware zu verwechseln. Der Preis verschwindet nicht. Er wandert nur an andere Stellen.

Und genau da beginnt der Denkfehler, denn gesparte Lizenzkosten verschwinden oft sofort an anderer Stelle.

2. Die echte Kostenstruktur: CAPEX sinkt, aber die Rechnung verschiebt sich

Der klassische Irrtum beginnt meistens sehr früh in der Diskussion. Ceph wird als kostenloses Storage gelesen, weil keine klassische Storage-Lizenz auf dem Tisch liegt. Das stimmt auf einer sehr engen Ebene, aber eben auch nur dort. Die Lizenzseite wird kleiner, ja. Daraus folgt aber nicht, dass die Storage-Plattform billig wird. Es bedeutet nur, dass die Rechnung anders aussieht.

Klartext: Sie sparen häufig am proprietären Storage-Controller, an Herstelleraufschlägen und an bestimmten Lizenzmodellen. Gleichzeitig verschiebt sich das Budget in die Knoten selbst, ins Netzwerk, in die Medien und in die Reserven, die ein verteiltes System nun einmal braucht. Wenn man das nicht sauber trennt, entsteht schnell die gefährliche Illusion, man könne Enterprise-Verhalten mit Lab-Hardware nachbauen und dabei auch noch Geld übrig behalten. Genau so entstehen später Frankenstein-Integrationen.

Fangen wir bei der Plattformlogik an. Ein tragfähiges Ceph-Design beginnt nicht bei einem einzelnen Host und auch nicht bei zwei Knoten, die man irgendwie zusammenbindet. Drei Knoten sind die Unterkante, wenn Sie Quorum und sinnvolle Redundanz wollen. Alles darunter ist im besten Fall ein Lernaufbau und im schlechtesten Fall eine produktive Fehlentscheidung. Das klingt hart, spart Ihnen aber Zeit. Wer mit zwei Knoten kalkuliert und Ceph daraufsetzt, plant an der Realität vorbei.

Dann kommt der Punkt, der in vielen Angeboten zu klein gerechnet wird: Replikation. Wenn Daten mehrfach abgelegt werden, kaufen Sie rohe Kapazität und nutzbare Kapazität nicht im Verhältnis eins zu eins ein. Wenn ein Pool dreifach repliziert, schrumpft die nutzbare Kapazität entsprechend. Das ist kein Fehler im System, sondern der Preis für Fehlertoleranz. Nur muss dieser Preis eben vorher in die Planung hinein und nicht erst dann, wenn das Team nach dem Go-Live feststellt, dass der freie Platz erstaunlich schnell verschwindet.

Noch teurer wird es beim Netzwerk, weil sich dort das Risiko gern versteckt. Ceph lebt von sauberer Kommunikation zwischen den Knoten. Wenn diese Kommunikation um Bandbreite, Latenz oder schlechte Trennung mit anderem Traffic kämpfen muss, bezahlen Sie das später bei Performance und Recovery. Für produktive Designs ist 10 GbE die sinnvolle Unterkante. Wenn Sie NVMe-lastig planen oder mehr Druck auf dem System erwarten, ist 25 GbE der deutlich sauberere Weg. Das ist kein Luxus. Das ist die technische Folgerung daraus, dass Schreibvorgänge und Rebalancing nun einmal über das Netz laufen.

Und nein, ein schneller Storage-Cluster wird nicht dadurch günstig, dass man beim Switch spart. Das ist in etwa so, als würden Sie einen Fuhrpark erneuern und dann die Hofeinfahrt auf Feldweg-Niveau belassen. Die Fahrzeuge können mehr, aber sie kommen nicht sauber durch.

Dasselbe gilt für die Knoten selbst. Billige Hardware wird in Ceph-Umgebungen oft zweimal gekauft, erst im Einkauf und dann noch einmal im Betrieb. Uneinheitliche SSDs, schwache CPUs, zu wenig RAM oder Komponenten aus dem Consumer-Bereich führen nicht zwingend sofort zum Totalausfall. Das Problem ist oft perfider. Das System läuft irgendwie, aber unter Last wird es unruhig. Recovery dauert länger. Einzelne Komponenten bremsen den Rest aus. Und plötzlich verbringt Ihr Team Zeit damit, Symptome zu verwalten, die aus einem schlechten Einkaufsbeschluss entstanden sind.

Was bedeutet das konkret für Ihre Budgetplanung? Sie sparen nicht überall, sondern Sie investieren anders. Weniger Geld fließt in einen geschlossenen Storage-Kasten mit Herstellerlogo. Mehr Geld fließt in gleichmäßige Cluster-Knoten, tragfähige SSDs, CPU- und RAM-Reserven sowie in ein Netzwerk, das die Architektur nicht sabotiert. Der Unterschied ist wichtig, weil Sie die Kosten früher in der Planung sehen müssen und nicht später in Eskalationen, Nachrüstungen und Notmaßnahmen.

Für Sie heißt das ganz praktisch: Wenn ein Angebot nur drei Server ausweist und damit das Thema Ceph scheinbar abhakt, fehlt oft die halbe Wahrheit. Dann fehlen häufig das Storage-Netz, der Kapazitätsverlust durch Replikation und die Reserve für Recovery und Wachstum. Genau dort wird aus einem günstigen Projekt schnell ein teures.

Jetzt wird es interessant, denn selbst wenn die Hardware sauber geplant ist, entscheidet sich der Erfolg nicht im Rack, sondern im Betrieb.

3. Die Betriebsrealität: Ceph ist kein Produkt, sondern eine Betriebsverantwortung

Klartext: Einen Proxmox-Cluster bekommen Sie heute vergleichsweise schnell ans Laufen. Ein paar Knoten, Netzwerk sauber aufgesetzt, Grundkonfiguration, fertig. Bei Ceph beginnt die eigentliche Arbeit aber erst dann, wenn die Installation abgeschlossen ist. Genau das wird in Projekten gern verwechselt. Man bewertet die Einführungsphase und unterschätzt die Betriebsphase. Und das ist teuer.

Ceph ist kein einzelnes Storage-Gerät, das Sie hinstellen, verkabeln und dann weitgehend als Blackbox behandeln. Ceph ist ein verteiltes System. Dahinter stehen mehrere Rollen und Dienste, die zusammenspielen müssen: Monitore für den Cluster-Zustand und das Quorum, Manager für Steuerung und Sichtbarkeit, OSDs als eigentliche Storage-Dienste pro Laufwerk, dazu Rebalancing, Recovery und laufende Zustandsüberwachung. Das klingt nach Technikdetail, ist aber in Wahrheit eine Betriebsfrage. Denn jeder dieser Bausteine beeinflusst, wie sich das System unter Fehlern verhält.

Der Unterschied zu einem klassischen SAN ist simpel: Bei einem Array suchen Sie Fehler oft an einem zentralen Ort. Bei Ceph verteilen sich Ursache und Wirkung über mehrere Knoten, mehrere Dienste und über das Netzwerk. Fehlerbilder sehen deshalb anders aus. Nicht unbedingt spektakulärer, aber unübersichtlicher. Vor allem dann, wenn die Plattform nicht im Leerlauf steht, sondern produktiv Last trägt. Genau unter Druck zeigt ein verteiltes System, ob es sauber geplant und sauber betrieben wurde.

Nehmen wir einen ganz normalen Betriebsfall. Ein Knoten fällt aus, geplant oder ungeplant. Nun passiert nicht nur, dass Workloads verschoben oder neu gestartet werden. Gleichzeitig beginnt der Storage-Verbund damit, Daten neu zu bewerten, neu zu verteilen und die Redundanz wiederherzustellen. Das heißt in der Praxis: mehr Last auf den verbleibenden Knoten, mehr Netzverkehr und mehr Aktivität auf den verbliebenen Medien. Mit anderen Worten: Ausgerechnet in der Phase, in der Sie Stabilität brauchen, steigt die Belastung des Gesamtsystems.

Da wird es im kleinen Drei-Knoten-Setup schnell eng. Solange alles gesund ist, wirkt das kompakt und wirtschaftlich. In der Recovery-Phase zeigt sich dann die Kehrseite. Die Plattform bleibt zwar arbeitsfähig, aber die Fehlertoleranz ist faktisch enger. Wenn in diesem Fenster noch ein zweites Problem dazukommt, sei es ein weiterer Host, ein Laufwerk oder ein Netzthema, wird aus einem beherrschbaren Vorfall sehr schnell eine unangenehme Lage. Nicht weil Ceph schlecht wäre, sondern weil kleine Cluster weniger Puffer haben. Das muss man nüchtern aussprechen.

Deshalb entscheidet sich der Erfolg bei Ceph in den Day-2-Operations. Also dort, wo nach dem Projekt normalerweise niemand mehr so gern hinschaut. Monitoring muss stimmen. Updates müssen geplant sein. Kapazitätsgrenzen dürfen nicht erst auffallen, wenn Pools volllaufen oder Health-Warnungen länger gelb bleiben als allen lieb ist. Dokumentation muss so geführt sein, dass im Störungsfall nicht geraten wird. Und vor allem müssen Zuständigkeiten klar sein. Wer schaut auf Cluster-Gesundheit? Wer bewertet Warnungen? Wer entscheidet, ob man eingreift oder bewusst laufen lässt?

Jetzt kommt der Teil, den viele Teams unterschätzen. Für Ceph reicht keine reine GUI-Routine. Ihr Team braucht Linux-Verständnis, Netzwerkverständnis und ein Gefühl dafür, wie sich Plattformdienste unter Last verhalten. Es geht nicht darum, dass jeder zum Ceph-Kernel-Entwickler werden muss. Aber jemand muss die Logik des Systems wirklich verstehen. Sonst wird jeder gelbe Status zum Rätsel und jede Störung zur improvisierten Ursachenforschung.

Bei einer klassischen Appliance liefert der Hersteller mehr Geländer. Das hat seinen Preis, aber es nimmt dem Betrieb auch Entscheidungen ab. Bei Ceph haben Sie mehr Freiheit. Sie sind weniger in einem Herstellerpfad eingesperrt, können Architektur und Ausbau stärker selbst steuern und gewinnen damit echte Unabhängigkeit. Gleichzeitig übernehmen Sie aber auch mehr Verantwortung. Freiheit ohne Betriebsdisziplin ist in der Infrastruktur selten ein Vorteil.

Was bedeutet das konkret für Sie? Wenn Ihr Betrieb heute schon bei Backups, Monitoring oder Patch-Fenstern improvisiert, dann wird Ceph diese Schwächen nicht verdecken. Es legt sie offen. Ein verteiltes Storage-System heilt keine organisatorischen Lücken. Es macht sie sichtbarer und im Fehlerfall teurer.

Genau deshalb ist die Technikfrage allein zu klein, denn Sie müssen Ceph immer gegen die Alternativen bewerten.

4. Die unbequeme Vergleichsfrage: Wann ZFS oder ein dediziertes Storage-System die bessere Entscheidung ist

Seien wir ehrlich: Nicht jedes Mittelstandsprojekt braucht verteiltes Shared Storage. Genau da wird die Diskussion oft unnötig ideologisch. Dann klingt Ceph automatisch nach der erwachseneren Lösung, und alles andere wirkt wie ein Kompromiss. Das ist zu schlicht gedacht.

ZFS ist in vielen Umgebungen kein Notbehelf, sondern eine sehr vernünftige Entscheidung. Sie arbeiten dabei mit lokalen Storage-Pools pro Knoten. Das macht die Architektur deutlich überschaubarer. Sie bekommen Snapshots, Datenintegrität und Replikationsmöglichkeiten, ohne gleich ein verteiltes Storage-System betreiben zu müssen. Für viele Teams ist das ein handhabbarer Rahmen, weil die Komplexität dort bleibt, wo sie hingehört, nämlich pro Host und nicht quer über das ganze Cluster.

Der praktische Vorteil zeigt sich vor allem in kleineren Setups. Wenn ein Knoten mit lokalem ZFS ein Problem hat, bleibt das Problem zunächst lokaler. Sie müssen nicht gleichzeitig beurteilen, wie sich eine Recovery auf mehrere Storage-Dienste, auf den Cluster-Zustand und auf den restlichen Verbund auswirkt. Die Fehlersuche ist meist direkter. Auch der Betrieb ist für kleinere Teams oft besser beherrschbar, weil weniger bewegliche Teile zusammenspielen.

Natürlich hat das seinen Preis. Und der Unterschied ist nicht kosmetisch, sondern grundlegend. ZFS auf lokalen Knoten liefert kein echtes Shared Storage im Sinn von Ceph. Sie haben also nicht dieselbe Form von nahtloser Hochverfügbarkeit, bei der eine VM-Festplatte dem Cluster jederzeit gemeinsam zur Verfügung steht. Stattdessen arbeiten Sie eher mit Replikationsfenstern. Das heißt: Daten werden in sinnvollen Intervallen auf andere Knoten übertragen, aber eben nicht permanent in derselben Logik wie bei einem verteilten Shared-Storage-System.

Was bedeutet das konkret? Im Fehlerfall kann es eine Lücke zwischen letzter Replikation und aktuellem Zustand geben. Je nach Anwendung ist das akzeptabel oder eben nicht. Für einen internen Anwendungsserver mag das vertretbar sein. Für eine stark schreibende Datenbank oder besonders zeitkritische Prozesse oft deutlich weniger. Genau deshalb ist ZFS keine kleinere Ausgabe von Ceph, sondern ein anderes Betriebsmodell mit einem anderen Risiko-Profil.

Es gibt noch eine dritte Option, die in diesen Diskussionen erstaunlich oft untergeht: ein dedizierter Storage-Server oder ein klassisches NAS- beziehungsweise SAN-System als gemeinsame Storage-Schicht. Das ist häufig der pragmatische Mittelweg. Sie behalten gemeinsames Storage für Migration und Failover, ohne gleich die volle verteilte Storage-Architektur im Cluster aufzubauen. Für manche Umgebungen ist das die sauberere Balance zwischen Funktion, Kosten und Betriebsaufwand.

Wirtschaftlich kann das sehr sinnvoll sein. Denn drei Ceph-Knoten mit gleichmäßig starker Hardware, guten SSDs und schnellem Netzwerk kosten Geld, und zwar auf allen Knoten gleichzeitig. Ein zentrales Storage-System bündelt diese Investition stärker an einer Stelle. Das kann am Ende günstiger sein, als die gleiche Storage-Qualität mehrfach in jedem Cluster-Knoten mitzukaufen. Vor allem dann, wenn die Anforderungen an Kapazität und Verfügbarkeit klar sind, das Team aber nicht noch ein verteiltes Storage-System im eigenen Betrieb verantworten möchte.

Die typische Entscheidungslogik im Mittelstand ist deshalb meist nüchterner als in Foren oder Lab-Setups. Kleine Cluster, begrenzte Teams und der Wunsch nach kalkulierbarem Betrieb sprechen oft gegen Ceph. Höhere HA-Anforderungen, wachsender Plattformbedarf und der Wunsch nach weniger externer Storage-Abhängigkeit sprechen eher dafür.

Klartext: Die richtige Architektur ist nicht die modernste. Sie ist diejenige, die Ihr Team nachts stabil betreiben kann.

Damit kommen wir zum eigentlichen Punkt, nämlich wie diese Bausteine zusammen als Entscheidungssystem funktionieren.

5. Das Entscheidungssystem: Wann das Ceph-Versprechen trägt und wann es zur Kostenfalle wird

Wenn Sie Ceph sauber bewerten wollen, brauchen Sie kein Bauchgefühl und auch keine Forenmeinung, sondern ein einfaches Entscheidungssystem. Aus meiner Sicht sind es drei Ebenen, die gleichzeitig tragen müssen. Sobald eine davon schwach ist, wird das Projekt wacklig, auch wenn die Technik auf dem Papier modern aussieht.

Die erste Ebene ist die Geschäftsanforderung. Hier ist die eigentliche Frage nicht, ob Ceph technisch interessant ist, sondern ob Sie die Eigenschaften wirklich brauchen. Brauchen Sie Shared Storage im Cluster? Brauchen Sie Live-Migration ohne Verschieben der VM-Festplatten? Brauchen Sie Hochverfügbarkeit so, dass ein Host-Ausfall nicht erst ein Restore- oder Replikationsproblem auslöst? Wenn diese Anforderungen weich sind oder nur aus einem allgemeinen Wunsch nach Modernisierung entstehen, dann ist Ceph oft zu viel Lösung für zu wenig Problem.

Die zweite Ebene ist die Infrastruktur-Reife. Also ganz nüchtern: Können Sie drei oder mehr sauber ausgestattete Knoten wirklich finanzieren, inklusive des Netzes, der Medien und der Reserven, die Sie für Replikation und Recovery brauchen? Nicht auf Kante genäht, sondern belastbar. Wenn die Antwort nur deshalb Ja lautet, weil man an Komponenten spart oder Risiken in spätere Phasen verschiebt, dann trägt das Modell nicht. Ein verteiltes Storage-System bestraft knappe Architektur früher oder später.

Die dritte Ebene ist die Betriebsreife. Wer schaut täglich auf den Zustand der Plattform? Wer pflegt Dokumentation? Wer bewertet Warnungen und Kapazitätsgrenzen, bevor daraus ein Problem wird? Und vor allem: Gibt es im Team Menschen, die ein verteiltes System nicht nur einführen, sondern auch im Alltag beherrschen? Wenn diese Ebene fehlt, wird aus technischer Freiheit sehr schnell operative Unruhe.

Genau hier liegt der eigentliche Aha-Moment. Ceph spart nicht einfach Geld. Ceph tauscht Kostenarten. Weniger Abhängigkeit vom Storage-Hersteller, dafür mehr Verantwortung in Architektur und Betrieb. Weniger klassischer Vendor Lock-in, dafür mehr eigener Anspruch an Design, Disziplin und Plattformkompetenz. Das ist weder gut noch schlecht. Es ist nur eine andere Verteilung von Risiko und Kontrolle.

Problematisch wird es, wenn Unternehmen diese drei Ebenen getrennt betrachten. Dann entscheidet die Geschäftsführung auf Basis des Preises, das Infrastruktur-Team auf Basis der Features und der Betrieb hofft, dass es schon irgendwie laufen wird. Genau so entsteht Frankenstein-Infrastruktur. Von außen modern, intern widersprüchlich und im Alltag störanfällig. Dann haben Sie kein klares Betriebsmodell, sondern mehrere halbe Entscheidungen, die sich gegenseitig ausbremsen.

Wenn dagegen alle drei Ebenen zusammenpassen, wird Ceph strategisch stark. Dann ergibt Standard-Hardware mit verteilter Hochverfügbarkeit wirtschaftlich Sinn. Dann ist weniger Lock-in nicht nur ein Schlagwort, sondern echte Handlungsfreiheit. Und dann wächst die Plattform kontrollierbar, weil Architektur, Budget und Betrieb dieselbe Richtung haben.

Für den Mittelstand ist das der brauchbare Raster. Ceph nur dann, wenn Business-Ziel, Plattformdesign und Betriebsmodell gleichzeitig tragen. Nicht, wenn nur einer dieser Punkte gut aussieht.

Daraus folgen ein paar sehr konkrete Schritte, bevor Sie überhaupt Angebote vergleichen oder Hardware bestellen.

Konkrete nächste Schritte / Takeaways

Erstens: Schreiben Sie Ihr Lastenheft nicht von der Hardware her, sondern vom Verfügbarkeitsziel. Also: Wie viel Ausfall verträgt der Betrieb, welches Recovery erwarten Sie und welches Betriebsrisiko ist akzeptabel? Erst dann reden Sie über Storage.

Zweitens: Rechnen Sie Ceph immer gegen Alternativen. Gegen ZFS. Gegen dedizierte Shared-Storage-Optionen. Und zwar vollständig, inklusive Netzwerk, nutzbarer statt roher Kapazität, Betriebsaufwand und Schulungsbedarf.

Drittens: Prüfen Sie Dienstleister mit unbequemen Fragen. Wie sieht Quorum im Fehlerfall aus? Was passiert bei Recovery unter Last? Wie ist das Netzwerk getrennt? Wer verantwortet Monitoring und Day-2-Operations? Wenn Antworten ausweichend bleiben, ist das kein Nebengeräusch.

Sprechen Sie mit Ihrem Team, bevor Sie unterschreiben.

Outro / Schluss

Das war IT for Business.

Wenn Sie aus dieser Folge etwas mitnehmen, dann vielleicht das: Gute IT entscheidet sich nicht im Tool, sondern in der Architektur und den Entscheidungen davor.

Wenn Ihnen die Folge gefallen hat, abonnieren Sie den Podcast, um keine weiteren Episoden zu IT-Entscheidungen aus der Praxis zu verpassen.

Und wenn Sie selbst vor einer IT-Modernisierung oder einem Projekt stehen: Stellen Sie die richtigen Fragen früh, nicht erst im Betrieb.

Bis zur nächsten Folge.