Im Jahr 2026 sehen sich Infrastrukturverantwortliche mit einer anderen Realität konfrontiert. Die Kosten für Komponenten – insbesondere für Speicher und Flash – steigen nach Jahren relativer Stabilität wieder an. Die KI-getriebene Nachfrage beansprucht Kapazitäten entlang der gesamten Halbleiter-Lieferkette. Die Vorlaufzeiten verlängern sich.

Anbieter konzentrieren sich auf margenstarke Segmente. Unternehmenskunden stellen zudem fest, dass die „nächste Erneuerung“ weder günstiger noch einfacher ist.

Dies ist keine vorübergehende Schwankung. Es handelt sich um einen strukturellen Wandel. Er offenbart die Anfälligkeit des traditionellen Speicher-Refresh-Modells.

Speicher ist nun an die globale Angebotsdynamik gebunden

Preisschwankungen bei DRAM und NAND-Flash gab es zwar schon immer, doch der derzeitige Druck ist neu. Hyperscale- und KI-Infrastrukturen verbrauchen enorme Mengen an Hochleistungsspeicher und -speichermedien. Die Hersteller straffen ihre Produktionslinien. Die Kapazitätszuweisung erfolgt strategisch.

Die Auswirkungen sind auch in der Unternehmens-IT spürbar:

• Höhere Materialkosten für Arrays und Server
• Geringere Verhandlungsmacht bei der Erneuerung der Hardware.
• Größere Preisvolatilität
• Längere Beschaffungszyklen.

Wenn das Angebot knapper wird und sich die Nachfrage auf das obere Marktsegment konzentriert, verlieren mittelständische und sogar große Unternehmen an Verhandlungsmacht. Sie kaufen nicht mehr in einem Käufermarkt ein.

Jahrelang stützten sich Speicher-Erneuerungszyklen auf fallende Kostenkurven, um einen vollständigen Austausch zu rechtfertigen. Wenn sich diese Kurve abflacht – oder gar umkehrt –, bricht die Wirtschaftlichkeit zusammen.

Das versteckte Risiko im traditionellen Erneuerungsmodell

Das klassische Modell sieht einfach aus:

Dieses Modell basiert auf drei Annahmen:

1. Die Preise verbessern sich im Laufe der Zeit.
2. Die Konditionen der Anbieter bleiben wettbewerbsfähig.
3. Die Migration ist überschaubar.

Im Jahr 2026 ist keine dieser Annahmen mehr garantiert.

Wenn Sie an die Hardware und den Datendienst-Stack eines einzigen Anbieters gebunden sind, sind Sie gezwungen, nach dessen Zeitplan, zu dessen Preisen und unter dessen Lizenzmodell zu kaufen. Steigen die Komponentenkosten, steigen auch Ihre Ersatzkosten. Verknappt sich das Angebot, verschiebt sich Ihr Projektzeitplan. Schrumpfen die Budgets, stehen Sie dennoch vor einer binären Entscheidung: Erneuerung oder das Risiko, den Support zu verlieren.

Das ist keine operative Agilität. Das ist strukturelle Abhängigkeit. Und Abhängigkeit ist teuer, wenn die Märkte angespannt sind.

Anbieterabhängigkeit ist nicht mehr nur ein IT-Problem, sondern ein finanzielles Risiko

Früher wurde Anbieterabhängigkeit lediglich als operatives Ärgernis betrachtet. Schwierigere Migrationen. Lizenzbeschränkungen. Eingeschränkte Flexibilität. In der heutigen Zeit wird sie jedoch zu etwas ganz anderem: einem Risiko für die Bilanz. Wenn Ihre Datendienste, Replikation, Snapshots und Leistungsschichten untrennbar mit proprietärer Hardware verbunden sind,

• Sie können nicht zwischen Hardware-Anbietern wählen.
• Sie können die Erneuerung der Hardware nicht nach Ihren eigenen Vorstellungen planen.
• Sie können die Lebensdauer der Anlagen nicht ohne Zustimmung des Anbieters verlängern.
• Sie können nicht aus einer Position der Stärke heraus verhandeln.

In stabilen Märkten erscheint diese Abhängigkeit erträglich. In volatilen Märkten wird sie jedoch zur Belastung. CFOs prüfen Infrastrukturausgaben daher zunehmend nicht nur auf Kosteneffizienz, sondern auch auf Flexibilität in unsicheren Zeiten. Eine Speicherarchitektur, die regelmäßige, kapitalintensive Erneuerungszyklen vorschreibt, steht im grundlegenden Widerspruch zu dieser Erwartung.

Der strategische Wandel: Von Erneuerungszyklen zur architektonischen Ausfallsicherheit

Es sollte nicht mehr die Frage sein, wann eine Erneuerung stattfindet. Vielmehr sollte die Frage lauten, ob Ihre Architektur überhaupt eine grundlegende Erneuerung erfordert. Vorausschauende IT-Entscheidungsträger stellen sich andere Fragen:

• Kann Hardware schrittweise statt komplett erneuert werden?
• Können Datendienste unabhängig von bestimmten Arrays weiterbestehen?
• Können mehrere Hardwareanbieter hinter einer gemeinsamen Steuerungsebene koexistieren?
• Können wir die Lebensdauer von Assets verlängern, ohne Support oder Leistung zu beeinträchtigen?

Hierbei geht es nicht darum, den neuesten Hardware-Innovationen hinterherzulaufen. Es geht vielmehr darum, die Infrastrukturstrategie von den von Anbietern vorgegebenen Zyklen zu entkoppeln.

Wenn softwaredefinierte Ansätze die Steuerungsebenen von den physischen Geräten trennen, gewinnen Unternehmen an Flexibilität. Hardware wird austauschbar. Kapazitäten können schrittweise hinzugefügt oder stillgelegt werden. Störungen in der Lieferkette werden so zu beherrschbaren Ereignissen statt zu existenziellen Krisen. Diese Freiheit und Flexibilität sind strategische Hebel.

Die Kosten der Untätigkeit

Betrachten Sie die Alternative. Ein Unternehmen, das in einem Umfeld steigender Kosten an starre Erneuerungszyklen gebunden ist, sieht sich folgenden Herausforderungen gegenüber:

• Höhere Investitionsspitzen alle paar Jahre
• Erhöhtes Projektrisiko bei Migrationen
• Geringere Verhandlungsmacht
• Unvorhersehbarkeit des Budgets
• Aufgeschobene Modernisierungsmaßnahmen in anderen Bereichen, um den Austausch der Infrastruktur zu finanzieren.

Mit der Zeit wird die Infrastruktur zu einem Hemmschuh für Innovationen, anstatt diese zu ermöglichen. Und in einer Zeit, in der digitale Initiativen direkt um Kapital konkurrieren, wird dieser Kompromiss besonders schmerzhaft.

Was IT-Führungskräfte jetzt tun sollten

Dies ist kein Aufruf zur Panik. Es ist ein Aufruf zur architektonischen Selbstreflexion. IT-Führungskräfte sollten:

1. Erfassen, wo in ihrem Storage-Stack echte Abhängigkeiten bestehen.
2. Die Gesamtlebenszykluskosten über zehn Jahre modellieren und nicht nur den Anschaffungspreis betrachten.
3. Beurteilen, wie viel ihrer Ausgaben von den Zeitplänen der Anbieter bestimmt wird.
4. Prüfen, ob Datendienste einen Hardware-Wechsel überstehen können.
5. Durch architektonische Flexibilität Verhandlungsmacht aufbauen.

Das Ziel ist nicht, Anbieter zu eliminieren. Es geht vielmehr darum, zu verhindern, dass ein einzelner Anbieter Ihre wirtschaftliche Zukunft bestimmt. In einem angespannten Markt ist Flexibilität gleichbedeutend mit Macht.

Eine neue Denkweise für 2026 und darüber hinaus

Die Ära des automatischen Kostenrückgangs bei Unternehmensspeichern ist vorerst vorbei. Die Nachfrage durch KI-Infrastrukturen, die Priorisierung der Lieferkette und Preisschwankungen haben die Landschaft nachhaltig verändert. IT-Organisationen, die an veralteten Denkweisen in Bezug auf die Erneuerung ihrer Systeme festhalten, müssen mit höheren Kosten, höheren Risiken und einer geringeren Hebelwirkung rechnen. Diejenigen, die ihre Architektur auf Unabhängigkeit ausrichten, werden jedoch etwas Wertvolleres als marginale Leistungssteigerungen gewinnen. Kontrolle. Und in unsicheren Märkten ist Kontrolle der ultimative Wettbewerbsvorteil.

Wir bei DataCore sind der Überzeugung, dass Unternehmen Flexibilität nicht gegen Leistung eintauschen oder eine Anbieterabhängigkeit als Preis für Stabilität hinnehmen sollten. Unsere softwaredefinierten Lösungen helfen IT-Teams, Wahlfreiheit in block-, datei-, objekt- und containerorientierten Umgebungen zu schaffen – dort, wo es am wichtigsten ist: vom zentralen Rechenzentrum bis zum Edge sowie in Hybrid- und Cloud-Architekturen.

Das Ergebnis ist praktische Kontrolle: Verlängerung der Lebensdauer von Assets, Reduzierung von Störungen und Risiken bei Veränderungen, Verbesserung der Kostenvorhersehbarkeit und Stärkung der Verhandlungsposition durch die Vermeidung herstellerbestimmter Erneuerungszyklen. Wenn Sie Ihre Speicherstrategie im heutigen volatilen Markt neu bewerten, wenden Sie sich an DataCore, um zu besprechen, wie architektonische Unabhängigkeit Ihnen helfen kann, die Kontrolle zu behalten.

Kontaktieren Sie uns

Nützliche Ressourcen

• Souveräne IT 2026: Fünf IT-Trends zwischen Hype und Pflichtprogramm und was sie für Ihre Daten bedeuten
• Schlüsseltechnologien, die die moderne Datenarchitektur prägen
• Die Lebensversicherung für Ihre Daten, die Sie sich schnellstens zulegen sollten

Jedes digitale System lebt von Daten. Sie werden gestreamt, synchronisiert, gesichert und wiederhergestellt. Es wirkt geordnet, kontrolliert und sicher. Doch in diesem endlosen Rhythmus kann sich eine infizierte Datei unbemerkt einschleichen. So beginnen Sicherheitsverletzungen – still und unsichtbar, lange bevor ein Alarm ausgelöst wird.

Stellen Sie sich Folgendes vor: Ein Benutzer lädt eine harmlos aussehende ZIP-Datei in Ihren Objektspeicher hoch. Darin versteckt sich ein neuer Trojaner, der den Signaturdatenbanken noch nicht bekannt ist. Die Datei wird gespeichert und repliziert – und wartet. Tage später wird sie im Rahmen eines geplanten Prozesses ausgeführt, verschlüsselt Dateien über Knoten hinweg und beschädigt Replikate. Dabei breitet sich die Infektion mit jeder automatisierten Aufgabe weiter aus. Was als einzelner Upload begann, hat den Speichercluster selbst zum Überträger gemacht. Ein solches Szenario spielt sich am häufigsten am Edge oder in Zweigstellen ab, wo Daten lokal gespeichert werden und die Sicherheitstransparenz am geringsten ist.

Wenn das Unsichtbare unvermeidlich wird

Malware hat sich zur Hintergrundstrahlung des Internets entwickelt: Sie ist allgegenwärtig, allumfassend und oft unsichtbar – bis es zu spät ist. Im vergangenen Jahr identifizierten Forscher über 100 Millionen neue Malware-Varianten und 81 % der Unternehmen sahen sich mindestens einem Malware-Vorfall gegenüber. Die wahren Kosten bestehen jedoch nicht nur in Ausfallzeiten oder der Beseitigung der Schäden, sondern auch in der Untergrabung des Vertrauens in die Daten selbst. Die Infektionswege sind äußerst einfallsreich: schlummernde Malware, die sich in archivierten Daten versteckt, kompromittierte Uploads, die beschädigte Dateien einschleusen, oder Fehlkonfigurationen durch Insider, die es bösartigem Code ermöglichen, sich innerhalb eines Speicherclusters zu verbreiten. Diese Bedrohungen überlisten die Abwehrmaßnahmen nicht, sondern warten sie einfach ab.

Der stillste und gefährlichste Ort, an dem sie sich verstecken können, ist die Speicherebene. Im Speicher ruht letztendlich alles: Objekte, Snapshots, Archive, Replikationen. Sobald Malware diese Ebene erreicht, bieten herkömmliche Abwehrmaßnahmen kaum noch Schutz. Man kann einen Server patchen, aber keine beschädigten Daten. Eine kompromittierte Datei kann sich von einem schlafenden Parasiten zur Ursache einer umfassenden Sicherheitsverletzung entwickeln. Sie kann nicht nur Live-Daten infizieren, sondern auch jede archivierte Kopie, der sie ausgesetzt ist.

Entwicklung eines Abwehrsystems gegen Malware

Herkömmliche Abwehrmechanismen funktionierten wie Mauern, die Bedrohungen fernhalten sollten. Doch Daten bleiben nicht mehr hinter Mauern, sondern bewegen sich durch Clouds, Edge-/ROBO-Standorte, APIs und gemeinsam genutzte Umgebungen. So kann Malware über vertrauenswürdige Pfade in die Systeme eindringen. Eine moderne Verteidigung erfordert daher eine Weiterentwicklung: Systeme mit „Instinkt”, die subtile Anomalien erkennen und reagieren können, bevor sich eine Infektion ausbreitet. Im Speicherbereich bedeutet dies eine proaktive Verteidigung: eine kontinuierliche Überwachung des Systems und der darin gespeicherten Daten, bei der stets alles, was nicht richtig erscheint, im Blick behalten wird. Doch Wachsamkeit allein reicht nicht aus. Echte Cyber-Resilienz hängt von einheitlicher Transparenz und automatisierten Reaktionen ab. Benötigt wird eine intelligente Ebene, die jeden Scan, jede Bedrohung und jedes Ereignis verfolgt und Richtlinien durchsetzt, sobald eine Gefahr auftritt.

Ein „Immunsystem“ für Ihre Edge-Daten

Edge-Umgebungen können sich keine mehrschichtigen Sicherheitsstacks oder spezialisierte Teams leisten. Remote-Büros, Zweigstellen und kleine IT-Umgebungen benötigen sofort einsatzbereiten Schutz, ohne dass eine weitere Plattform integriert und verwaltet werden muss.

Die Swarm Appliance ist eine schlüsselfertige All-in-one-Objektspeicher-Appliance. Sie wurde entwickelt, um lokale Daten an Edge- und ROBO-Standorten sowie in KMU-Umgebungen mit begrenzten Budgets, Platz und IT-Personal zu archivieren und zu schützen. Sie vereint Speicher, Datenschutz und integrierte Malware-Erkennung in einem einzigen System, das schnell bereitgestellt und mit minimalem Aufwand betrieben werden kann. Die Sicherheit ist nicht nachträglich hinzugefügt oder an externe Tools delegiert, sondern direkt in die Art und Weise eingebettet, wie Daten gespeichert werden. Durch die Bereitstellung intelligenter Malware-Abwehr als Teil eines eigenständigen Systems reduziert die Swarm Appliance die Komplexität und schließt gleichzeitig eine der häufigsten Sicherheitslücken am Edge: die Anhäufung ungeprüfter Daten im lokalen Speicher.

Erkennung von Malware in Inhalten: Schutz gespeicherter Daten

Im Mittelpunkt des Schutzmodells der Swarm Appliance steht die Erkennung von Malware in Inhalten. Sie ist darauf ausgelegt, Daten im Moment des Schreibens in den lokalen Objektspeicher zu schützen. Jedes Mal, wenn ein Benutzer Inhalte hochlädt oder ein externes System ein Objekt schreibt, kann die Datei automatisch auf bekannte Malware-Signaturen, Trojaner und andere schädliche Payloads überprüft werden.

Diese Überprüfung erfolgt nach der Speicherung der Daten. Dadurch wird sichergestellt, dass Bedrohungen identifiziert werden, bevor Objekte repliziert, archiviert oder von nachgelagerten Prozessen genutzt werden. Da die Malware-Erkennung direkt innerhalb der Speicherschicht erfolgt, funktioniert sie auch dann, wenn Bedrohungen über vertrauenswürdige Pfade gelangen oder herkömmliche Perimeter-Abwehrmaßnahmen umgehen.

Wird Malware erkannt, werden Administratoren benachrichtigt und können entsprechend ihren betrieblichen Anforderungen Maßnahmen ergreifen. Infizierte Objekte können überprüft und in einem sicheren Quarantäne-Bucket isoliert oder vollständig entfernt werden. Erkennungsereignisse enthalten eindeutige Metadaten wie Bedrohungstyp, Quellpfad, Erkennungszeitpunkt und Status. Dadurch ist eine schnelle Überprüfung ohne forensische Komplexität möglich.

In Umgebungen, in denen Object Lock zum Einsatz kommt, bleiben regulatorische Anforderungen und Aufbewahrungsgarantien gewahrt. Gesperrte Objekte werden nicht automatisch unter Quarantäne gestellt oder verändert. Dadurch bleibt die Compliance gewährleistet und es wird gleichzeitig Einblick in erkannte Bedrohungen geboten.

Durch die direkte Integration der Malware-Erkennung in den Objektspeicher stellt die Swarm Appliance sicher, dass Edge-Daten nicht nur verfügbar, sondern auch vertrauenswürdig bleiben.

Fazit: Lassen Sie den Speicher nicht zum schwachen Glied werden!

Malware ist zur stillsten Krise in der modernen IT geworden. Sie versteckt sich in Dateien, lauert in archivierten Objekten und wartet auf den kleinsten Fehler, um wieder aufzutauchen. Sie stiehlt nicht nur Daten, sondern untergräbt auch das Vertrauen, auf dem diese Daten beruhen. In diesem Umfeld wird passiver Speicher zu Risikospeicher. Moderner Objektspeicher muss mehr tun, als nur Informationen zu bewahren – er muss sie auch verteidigen. Mit der Swarm Appliance von DataCore wird Echtzeit-Sicherheitsbewusstsein und -Reaktion ins Herzstück des Objektspeichers selbst gebracht und es wird sichergestellt, dass Malware-Bedrohungen dort erkannt werden, wo sie sich verstecken. Denn wenn jede Datei eine Waffe sein kann, kann Sicherheit nicht mehr nur am Perimeter existieren. Erfahren Sie, wie dieser neue Ansatz Ihre Umgebung stärkt, und wenden Sie sich an DataCore, um die Entwicklung hautnah mitzuerleben.

Holen Sie sich Swarm Appliance

Nützliche Ressourcen

• Whitepaper: Cyber-Resilienz – unverzichtbar für den Geschäftserfolg
• Informationssicherheit und die Kosten von Verstößen
• Wie Zero Trust die Sicherheit des Datenspeichers erhöht

Kubernetes wird häufig dafür gelobt, eine Plattform mit Selbstheilung zu sein. Pods starten selbstständig neu, Arbeitslasten werden automatisch verlegt und der Cluster kompensiert kleinere Ausfälle ohne großes Theater. Doch in dem Moment, in dem Sie unternehmenskritische Anwendungen ausführen, die unbedingt online bleiben müssen – kundengerichtete Systeme, transaktionale Arbeitslasten, interne Dienste, die nicht ausfallen dürfen –, wird „Selbstheilung“ vom netten Extra zur absoluten Notwendigkeit. Wenn bereits wenige Minuten Ausfallzeit dramatische Folgen haben können, müssen die Teams irgendwann feststellen, dass die Hochverfügbarkeit in Kubernetes nicht so automatisch ist, wie sie angepriesen wird.

Die versteckte Lücke in der Hochverfügbarkeit: Pod-Wiederherstellung vs. Datenverfügbarkeit bei zustandsbehafteten Anwendungen

Hochverfügbarkeit läuft in Kubernetes auf zwei Ebenen: auf der Steuerungsebene und in den Anwendungen selbst. Eine resiliente Steuerungsebene gewährleistet die Funktionsfähigkeit des Clusters selbst beim Ausfall von Knoten, sodass Kubernetes Entscheidungen treffen und Arbeitslasten bei Bedarf verschieben kann. Vor allem bei zustandslosen Anwendungen gelingt es Kubernetes ausgezeichnet, mit Replikaten zu arbeiten, die es bei Ausfällen neu startet. Das ist jedoch nur die halbe Miete. Bei zustandsbehafteten Anwendungen – die auf konsistente Daten angewiesen sind – verläuft die Wiederherstellung keineswegs so reibungslos. Kubernetes ist immer in der Lage, einen Pod neu zu starten, kann jedoch nicht garantieren, dass der letzte Zustand dieses Pods nach einem Ausfall sofort wieder zur Verfügung steht.

Das ist der Punkt, an dem die meisten Teams die wahre Herausforderung in puncto Hochverfügbarkeit erleben. Wenn ein Knoten plötzlich ausfällt, bringt Kubernetes den Pod schnell auf einem anderen Knoten wieder ans Laufen. Dieser Teil funktioniert hervorragend. Das Problem dabei: Was geschieht mit den Daten, die gerade von der Anwendung genutzt wurden, als es zum Ausfall kam? Ist nicht anderswo Speicher verfügbar oder wurden die Daten noch nicht über die Knoten hinweg synchronisiert, ist die neu gestartete Anwendung nicht wirklich wiederhergestellt – sie läuft lediglich zustandslos. Diese Diskrepanz zwischen Failover der Arbeitslast und Datenbereitschaft macht vielen Clustern zu schaffen. Sie ist auch der Grund dafür, dass Unternehmen sich nach solideren Möglichkeiten zur Sicherung der Verfügbarkeit ihrer Anwendungen und Daten umsehen, für den Fall, dass Kubernetes-Knoten ausfallen.

DataCore Puls8: Hochverfügbarkeit für zustandsbehaftete Kubernetes-Arbeitslasten

Die Lücke zwischen Pod-Wiederherstellung und Datenverfügbarkeit schließen

Für den Lückenschluss zwischen Pod-Wiederherstellung und Datenverfügbarkeit bietet DataCore Puls8 einen einheitlichen Ansatz zur Sicherstellung der Hochverfügbarkeit zustandsbehafteter Anwendungen. Anstatt sich auf fragmentierte Tools zu verlassen, synchronisiert Puls8 die Anwendungsdaten knotenübergreifend in Echtzeit und gewährleistet, dass Arbeitslasten an einem beliebigen Ort im Cluster im vollständigen, konsistenten Zustand neu starten und ausgeführt werden können. Anstatt Speicher und Failover getrennt zu betrachten, pflegt Puls8 eine aktive, gespiegelte Kopie der Anwendungsdaten über alle Knoten hinweg und stellt sicher, dass ein Neustart der Arbeitslasten überall im Cluster im vollständig intakten Zustand erfolgen kann.

Synchrone Spiegelung für sofortige Verfügbarkeit des neuesten Stands

Mit Puls8 läuft jeder Schreibvorgang parallel auf mehreren Knoten, sodass die Anwendungsdaten jederzeit und überall auf dem neuesten Stand und konsistent sind. So wird der Cluster auf Störungen vorbereitet: Ist ein Knoten nicht mehr erreichbar, besteht das Risiko nicht darin, dass Kubernetes den Pod vielleicht nicht neu starten kann, sondern dass die Arbeitslast nicht in ihrem jüngsten Zustand neu startet. Dieses Risiko beseitigt Puls8 vollständig, indem es eine einsatzfertige, synchronisierte Kopie der Daten auf einem anderen Knoten verfügbar hält, bevor ein Failover ausgeführt wird.

Wie die Architektur deterministische Konsistenz gewährleistet

Aus technischer Sicht nutzt Puls8 eine Architektur auf der Grundlage gespiegelter Datenträger auf Blockebene mit einem CSI-Treiber. Replikationsbestätigungen erfolgen erst dann, wenn beide Knoten den Schreibvorgang abgeschlossen haben. So ist die deterministische Konsistenz auch bei hohen, explosionsartigen oder transaktionalen Arbeitslasten gewährleistet. Diese Vorgehensweise verhindert Datendrift, asynchrone Lücken und Wiederherstellungsverzögerungen, die bei der Verwendung herkömmlicher replizierter Speicher in Kubernetes-Umgebungen häufig auftreten.

Sofortige Volumenverfügbarkeit und automatisierte Replikatverwaltung

Geht ein Knoten offline, zieht Puls8 automatisch den gespiegelten sekundären Datenträger heran. Puls8 kann nach einem Ausfall auch automatisch die gewünschte Anzahl von Volume-Instanzen (Replikaten) wiederherstellen und veraltete Kopien entfernen, sobald sich der Cluster stabilisiert hat.

Failover für garantierte Kontinuität

Kubernetes verlegt den Pod und stellt das vollständig synchronisierte Replikat bereit. Die Anwendung kann genau an dem Punkt neu starten, an dem sie aufgehört hat, ohne Wiederaufbau, Resynchronisation, Datenverlust oder langsames Wiederanheften. Das Failover erfolgt automatisch, transparent und schnell, sodass zustandsbehaftete Dienste sich so geschmeidig wie zustandslose verhalten, mit vollständig erhaltener Datenintegrität.

Wie Puls8 in der Praxis mit einem Knotenausfall umgeht

In diesem Beispiel sehen wir eine WordPress-Anwendung, die unter normalen Betriebsbedingungen auf Knoten 1 ausgeführt wird. Der Pod ist „gesund“ und dient planmäßig als Server für den Datenverkehr.

Der Cluster besteht aus drei Knoten (Knoten 0, Knoten 1 und Knoten 2) und liefert Kubernetes und Puls8 die Umgebung, die für die zuverlässige Ausführung der zustandsbehafteten Arbeitslast erforderlich ist. Puls8 repliziert kontinuierlich die Daten der Anwendung im Hintergrund, sodass der letzte Zustand immer auf einem weiteren Knoten bereitgehalten wird.

Auf dem folgenden Bild sehen wir, dass die Replikation für alle drei Knoten konfiguriert ist.

Auf dem nächsten Bild werden alle drei Knoten in einem fehlerfreien, synchronisierten Datenzustand angezeigt.

Hier sehen wir, dass Knoten 1 unerwartet offline geht. Ab diesem Punkt ist die Arbeitslast auf dem Knoten nicht länger verfügbar und Kubernetes muss den Pod verlegen, damit die Anwendung weiterlaufen kann.

Die WordPress-Anwendung wird auf Knoten 2 verlegt. Da Puls8 die Daten zuvor laufend repliziert hat, kann der Pod die Anwendung auf dem neuen Knoten sofort im korrekten, aktuellen Zustand starten.

Die Anwendung ist intakt und läuft jetzt normal auf Knoten 2. Mit kontinuierlicher Replikation und nahtlosem Failover sorgt Puls8 dafür, dass die zustandsbehaftete Arbeitslast ohne Ausfallzeit oder Störung weiterläuft.

Fazit: Die Grundlage für Hochverfügbarkeit in Kubernetes

Hochverfügbarkeit in Kubernetes basiert ultimativ auf der Sicherheit, dass Arbeitslasten online und Daten intakt bleiben und Störungen keine Ausfallzeit nach sich ziehen. Durch die Kombination aus synchronisierter Datenreplikation und nahtlosem, automatisiertem Failover der Anwendungen bewirkt DataCore Puls8 für zustandsbehaftete Anwendungen den gleichen Grad an Resilienz und Vorhersehbarkeit, den zustandslose Anwendungen genießen. Puls8 ist die Grundlage für Systeme, in denen Kontinuität bei Störungen nicht dem Zufall überlassen werden darf, sondern unabdingbar ist.

Darum bezeichnen wir diese Funktion als „Rettungsleine“. In dem Moment, in dem ein Knoten verschwindet, sorgt die Rettungsleine dafür, dass mit der Anwendung nicht das Gleiche passiert. Sie bewahrt den Zustand, erhält die Konsistenz und lässt den Dienst ohne Verzögerung weiterlaufen: als ein Sicherheitsnetz, auf das jede unternehmenskritische Arbeitslast angewiesen ist. Wenn Sie wissen möchten, wie Puls8 Hochverfügbarkeit in Kubernetes bewirkt, fordern Sie eine Demo bei DataCore an und erleben Sie den Unterschied selbst.

KONTAKTIEREN SIE UNS FÜR EINE DEMO VON PULS8

Nützliche Ressourcen

• Wie Puls8 persistenten Speicher für Kubernetes liefert
• Whitepaper: Maximale Performance mit Puls8 und Google Cloud Local SSD
• Die Puls8 Back & Restore Integration in Veeam Kasten

In der Enterprise-IT ist man sich einig: Es reicht nicht länger aus, Wiederherstellungsmechanismen in Kraft zu haben, man muss auch dafür sorgen, dass die Wiederherstellungsdaten unberührt bleiben. Ransomware, bösartige Skripte und auch menschliches Versagen, sie alle können Datenschutzstrategien aushebeln, doch ein Glied in der Kette entpuppt sich immer häufiger als Schwachstelle: die Fähigkeit, Wiederherstellungspunkte zu manipulieren.

Mit dem bevorstehenden DataCore SANsymphony 10.0 PSP21 Release wird diese Lücke mit Immutable Snapshots geschlossen. Damit können Unternehmen Wiederherstellungsdaten an der Quelle sperren und sicherstellen, dass einmal erfasste Snapshots nicht mehr geändert, gelöscht oder neu konfiguriert werden können, bis die definierte Aufbewahrungsfrist abgelaufen ist. Selbst Administratoren können diesen Mechanismus nicht außer Kraft setzen.

Damit ist nicht nur ein weiteres Element im Datenschutzarsenal gegeben, sondern die Art und Weise, in der SANsymphony die Datenintegrität schützt und gewährleistet, dass Ihre Datenkopie dauerhaft im letzten bekannten guten Zustand bleibt, wird revolutioniert.

Eine Linie, die nicht überschritten werden kann

Jede Wiederherstellungsstrategie beruht auf der Voraussetzung, dass Ihre Daten im entscheidenden Moment noch genauso sind, wie sie bei der Erstellung waren. Doch die meisten Wiederherstellungspunkte sind anfällig: für menschliches Versagen, fehlerhafte Automatisierung oder absichtliche Manipulation beispielsweise durch Cyberangriffe.

Unveränderbarkeit stellt das Vertrauen in diese Grundvoraussetzung wieder her. Sie definiert eine Linie, hinter der Daten nicht mehr flüchtig sind, sondern permanent werden: einen Datensatz, der für immer so bleibt, wie er zum Zeitpunkt seiner Entstehung ist. Sobald die Daten diese Linie überschreiten, werden sie zum nachprüfbaren, schreibgeschützten Abbild der Wahrheit. Durch die Beseitigung der Möglichkeit zur Änderung bringen Immutable Snapshots Dauerhaftigkeit in den Schutz der Daten. Der Speicher wird zum sicheren Refugium anstatt zum Ort der Ungewissheit – das Fundament wahrer Cyber-Resilienz.

Wenn Schutz als Beweis dient

Heute fragt niemand mehr: „Gibt es davon eine Kopie?“ Stattdessen fragt man: „Lässt sich nachweisen, dass die Kopie echt ist?“

Immutable Snapshots bewahren nicht nur Daten, sie bewahren Vertrauen. Sie markieren einen Zeitpunkt, der nicht verhandelbar ist, nicht neu geschrieben werden und nicht heimlich angepasst werden kann. Was zum Erstellungszeitpunkt Fakt war, ist immer noch Fakt und bis auf den letzten Block nachvollziehbar.

Für Unternehmen, die mit Audits, Vorschriften oder Wiederherstellungsereignissen zu tun haben, ist diese Sicherheit transformativ. Sie verwandelt Backups von einer Vorsichtsmaßnahme in ein Instrument des Vertrauensschutzes. Bei SANsymphony ist diese Integrität in die Speicherebene selbst integriert. So wird Unveränderbarkeit zu etwas, das stärker als reiner Schutz ist – sie ist der Nachweis, dass Ihre Daten genau das sind, was sie zu sein vorgeben.

Unveränderbarkeit als feste Komponente der Speicherebene

Bei SANsymphony ist die Unveränderbarkeit keine zusätzliche Schicht und kein Extra – sie ist fest in die Speicherebene integriert. Jeder Immutable Snapshot stärkt den Schutz auf der untersten Ebene, unabhängig von den Aktionen der Nutzer oder der Absicht des Administrators. Ist der Snapshot einmal erstellt, ist sein Zustand endgültig, bis die vorab definierte Aufbewahrungsfrist abgelaufen ist.

Diese Vorgabe wird ausnahmslos durchgesetzt. Kein Befehl, kein Privileg und kein Prozess kann einen Immutable Snapshot vor Ablauf der Frist ändern oder löschen. Auch bei einem Wartungsfenster, Neustart oder Failover bleiben die Wiederherstellungspunkte gesperrt und verifizierbar.

Hinter dieser Gewissheit steckt Methode:

• Durchsetzung der Aufbewahrungsfrist, die nicht weniger als 24 Stunden betragen kann; so werden vorzeitige Freigaben oder versehentliche Löschungen verhindert.
• Hash-basierte Integritätsprüfung zur Validierung jedes Immutable Snapshots anhand seines kryptografischen Siegels und zum Nachweis, dass keine Veränderungen vorgenommen wurden.
• Nahtlose Verwaltung über die Managementkonsole, PowerShell oder REST API als zusätzliche betriebliche Steuerung, ohne den Schutz zu schwächen.
• Bedingungslose Persistenz: Auch nach Abstürzen oder Neustarts werden unveränderbare Snapshots im schreibgeschützten Modus wiederhergestellt, sodass der lückenlose Schutz gewährleistet ist.

Dieser Schutz ist durch die Architektur vorgegeben – Unveränderbarkeit per Konzept, nicht durch Konfiguration. Dadurch wird die Speicherebene zur finalen, uneinnehmbaren Verteidigungslinie für die Unternehmensdaten.

Die Arbeit mit Immutable Snapshots

So erstellen Sie einen Immutable Snapshot

Die Erstellung eines Immutable Snapshots in SANsymphony beginnt wie jede andere Snapshot-Operation: Wählen Sie auf der Seite Virtual Disk Details Create Snapshot. Wenn Sie einen Haken in das Kontrollkästchen neben Immutable setzen, setzt SANsymphony den Snapshot-Typ automatisch auf Full, da für die Unveränderbarkeit ein vollständiges, unabhängiges Bild der Quelle benötigt wird.

Nach Wahl der Unveränderbarkeit setzt SANsymphony eine minimale Aufbewahrungsfrist von 24 Stunden durch. Wird eine kürzere Frist eingegeben, ändert das System diese automatisch ab und meldet dies vor dem Fortfahren.

Während der Erstellung startet die Hash-Berechnung automatisch. Jeder Datenblock im Snapshot wird in den kryptografischen Hash aufgenommen und bildet ein nachprüfbares Integritätssiegel. Der Fortschritt wird als Prozentsatz unter der Registerkarte Immutability angezeigt. Bereits während der Hash-Vorgang läuft, ist der Snapshot schreibgeschützt und vor Änderungen geschützt.

Nach dem erfolgreichen Abschluss des Hash-Vorgangs ändert sich der Status des Snapshots in Retention Locked. Von diesem Moment an kann er durch keinen Befehl, kein Privileg und keinen Prozess mehr geändert oder gelöscht werden, nicht einmal von einem Administrator.

So machen Sie einen vorhandenen Snapshot Immutable

Bereits vorhandene Snapshots können Sie nachträglich unveränderbar machen. Wählen Sie unter der Registerkarte Immutability des ausgewählten Snapshots Make Immutable und legen die Aufbewahrungsfrist fest. Nach der Bestätigung gelten hier die gleichen Regeln: Der Hash-Vorgang startet automatisch, der Snapshot ist ab sofort schreibgeschützt und der Status ändert sich nach Abschluss des Vorgangs in Retention Locked.

Mit dieser Funktion können Administratoren den Schutz auch nachträglich verstärken und beispielsweise einen kritischen Snapshot nach einer Validierung oder vor der Archivierung sichern.

Verifikation der Integrität

Sie können zu jedem Zeitpunkt Seal Verification ausführen, um sich zu vergewissern, dass der Hash eines Snapshots nach wie vor dem gespeicherten Siegel entspricht. Stimmen die Werte überein, ändert sich der Status des Snapshots in Verified. Werden Diskrepanzen erkannt, wird der Snapshot als Compromised gekennzeichnet, bleibt aber nach wie vor unveränderbar und geschützt.

Die Verifikation des Siegels gewährleistet langfristiges Vertrauen, speziell bei Unternehmen, die die Integrität der Überwachungskette oder die Einhaltung strenger Datenaufbewahrungsvorschriften nachweisen müssen.

Komprimierung möglich

Wenn Sie Immutable oder andere Snapshots erstellen, können Sie optional Compression freigeben, vorausgesetzt, der ausgewählte Pool unterstützt die Kapazitätsoptimierung. Die Komprimierung verringert die Standfläche des Speichers und behält ansonsten die vollständigen Unveränderbarkeitsmerkmale des Snapshots bei. Bei unveränderbaren Snapshots wird die Komprimierung bei der Erstellung angewendet und über die gesamte Aufbewahrungsfrist beibehalten. So lässt sich die Speichereffizienz optimieren, ohne die Datenintegrität zu beeinträchtigen.

Überwachung und Persistenz

Immutable Snapshots sind in das System Health Monitoring integriert. Die Konsole generiert automatisch Warnmeldungen, wenn Snapshots sich dem Ablauf der Frist nähern (per Systemvorgabe drei Tage im Voraus). Administratoren können die Erstellungszeiten, die Ablaufdaten und den Hash-Verifikationsstatus in einer einzigen Ebene ansehen. Auch nach einem Neustart, Wartungsfenster oder Failover werden Immutable Snapshots automatisch schreibgeschützt wiederhergestellt. Es ist keine manuelle erneute Anwendung oder Aktualisierung der Richtlinien erforderlich, die Unveränderbarkeit ist fest in das Design integriert.

Gesperrt. Nachweislich. Unüberwindlich.

Immutable Snapshots markieren einen Wendepunkt in der Konzeption des Schutzes von Unternehmensdaten. Durch die Integration der Unveränderbarkeit direkt in die SANsymphony-Architektur wird die letzte Schwachstelle eliminiert – die Möglichkeit, zu verändern, was nicht verändert werden darf. Jeder Snapshot wird zu einer uneinnehmbaren Festung, immun gegen Manipulation und Zeit. In einem Ökosystem, in dem die Datenwiederherstellung alleine nicht mehr ausreicht, sind Immutable Snapshots die Grundlage für echte Resilienz: Daten, die nicht nur überleben, sondern nachweislich integer sind.

Fragen Sie eine kostenlose Testversion von SANsymphony an, um Immutable Snapshots in Aktion zu erleben.

Nützliche Ressourcen

• Whitepaper: Cyber-Resilienz – unverzichtbar für den Geschäftserfolg
• Informationssicherheit und die Kosten von Verstößen
• Wie Zero Trust die Sicherheit des Datenspeichers erhöht

Latenz ist seit jeher die Achillesferse der Speichernetzwerke. Als es noch rotierende Festplatten gab, war eine Verzögerung von einigen Millisekunden nicht weiter tragisch, da das physische Medium selbst langsam war. Doch mit Flash und SSDs hat sich der Engpass vom Gerät zum Protokoll-Stack und Netzwerk verschoben. Auch mit Direct Attached NVMe SSDs können Anwendungen I/O im Zehner-Mikrosekundenbereich verarbeiten. Zum Vergleich: Bei traditionellen SAN-Protokollen wie iSCSI oder FCP kann jede I/O-Anfrage mit mehreren Hundert Mikrosekunden an Software- und Netzwerk-Overhead verbunden sein. Genau diese Lücke überbrückt NVMe-oF.

Technisch betrachtet übermittelt NVMe-oF die NVMe-Befehle mit minimaler Übersetzung über ein Netzwerk-Fabric. Es vermeidet die SCSI-Befehlsemulationsebene, die für einen Großteil des Overhead bei iSCSI oder Fibre Channel verantwortlich ist. Stattdessen unterstützt NVMe-oF direkte, Fabric-übergreifende Übermittlungs- und Verarbeitungswarteschlangen, sodass I/O-Anfragen direkt und mit minimaler Intervention zwischen Anwendung und SSD abgewickelt werden. Daraus resultiert eine Latenz im Bereich von 20 bis 30 Mikrosekunden über ein Fabric, was in etwa der Performance lokaler NVMe-Festplatten entspricht.

Skalierbarkeit ist ebenso wichtig. NVMe wurde für die massive parallele Verarbeitung mit mehreren Tausend Übermittlungs- und Verarbeitungswarteschlangen konzipiert. NVMe-oF überträgt dieses Merkmal auf das gesamte Netzwerk. Bei alten Protokollen wird eine einzelne Befehlswarteschlange zum Engpass. Im Gegensatz dazu können die Anwendungen und Hosts hier eigene Warteschlangen eröffnen, die direkt an die CPU-Kerne übertragen werden. Durch dieses Design kann die Infrastruktur mehrere Millionen IOPS pro Host ohne ineffizientes Kontext-Switching oder Warteschlangensperre abwickeln. Bei modernen Mehrkernservern mit mehreren Dutzend Containern oder VMs ist dies für eine durchgehende vorhersehbare Performance in großem Maßstab unverzichtbar.

Effizienz schließt den Kreis. In traditionellen Stacks führen hohe IOPS zu hoher CPU-Beanspruchung. Der Protokoll-Overhead belegt Rechenkapazität, die den Anwendungen vorbehalten sein sollte. NVMe-oF verringert diese Einbußen dramatisch. Benchmarks zeigen häufig, dass NVMe-oF das Drei- bis Vierfache an IOPS pro CPU-Kern im Vergleich zu iSCSI liefern kann. Damit können Rechenzentren die Infrastruktur ohne Performance-Abstriche konsolidieren. Darum sehen Hyperscaler und Cloud-Provider NVMe-oF nicht nur als Performance-Plus, sondern als TCO-Optimierung.

Auf Anwendungsfälle bezogen spielt dies eine Rolle in Umgebungen, in denen es auf jede Mikrosekunde ankommt:

• Datenbanken, die bei hohen Transaktionsraten Antwortzeiten von weniger als einer Millisekunde benötigen
• KI/ML-Trainingspipelines, in denen die GPUs inaktiv sind, wenn der Speicher nicht Schritt halten kann
• Edge-Workloads, in denen latenzempfindliche Anwendungen (autonome Systeme, 5G, IoT) keine langen Speicherpfade tolerieren
• Echtzeit-Auswertungen, bei denen Ströme von Eingangsdaten ohne Engpässe verarbeitet werden müssen

In all diesen Szenarien stellt NVMe-oF sicher, dass der Speicher kein Hemmschuh ist. Mit NVMe-oF können Unternehmen ihre Infrastruktur so gestalten, dass sich das Netzwerk praktisch wie Direct-Attached Flash verhält, allerdings mit der Flexibilität und Skalierbarkeit von Shared Storage.

Die Wahl des richtigen Fabric: RDMA, Fibre Channel oder TCP?

NVMe-oF ist kein einzelnes Protokoll, sondern ein Rahmen, der definiert, wie NVMe-Befehle über eine Vielzahl von Netzwerk-Fabrics transportiert werden können. Jede Übermittlung hat eigene Stärken, Einschränkungen und optimale Szenarien. Architekten, die die Performance maximieren möchten, ohne den Betrieb unnötig zu verkomplizieren, müssen diese Abstriche oder Kompromisse verstehen.

NVMe-Befehle werden nicht im „Rohzustand“ über ein Fabric transportiert. Stattdessen werden sie in leichte Container gepackt, d. h. verkapselt. Eine Kapsel kann entweder nur den Befehl oder, in bestimmten Fällen, den Befehl und die damit zusammenhängenden Daten enthalten. Die Verkapselung ermöglicht die problemlose Übertragung des warteschlangenbasierten NVMe-Modells auf unterschiedliche Transportprotokolle wie Fibre Channel, RDMA oder TCP. Der Overhead ist minimal und die Effizienz der direkten Übermittlungs- und Verarbeitungswarteschlangen von NVMe bleibt erhalten, sodass NVMe-oF ähnliche Latenzwerte wie Direct Attached Drives erzielen kann.

RDMA (RoCE und iWARP)

RDMA (Remote Direct Memory Access) ist der Goldstandard für geringe Latenz bei NVMe-oF. Per Konzept umgeht RDMA den Host-CPU und Kern bei Datentransfers und verschiebt Daten direkt vom Arbeitsspeicher eines Hosts in den eines anderen. Das bedeutet, dass ein NVMe-Befehl mit minimaler CPU-Beteiligung übermittelt und ausgeführt werden kann. Dies führt häufig zu einer Latenz von nur 10 bis 20 Mikrosekunden im Fabric.

• RoCE (RDMA over Converged Ethernet) ist die am häufigsten genutzte Variante, die allerdings ein verlustfreies Ethernet-Fabric benötigt (das mit Data Center Bridging oder PFC erreicht wird). Das kann sowohl das Netzwerkdesign als auch die Fehlersuche verkomplizieren.
• iWARP hingegen läuft über TCP und ist nicht auf ein verlustfreies Fabric angewiesen. iWARP wird im Markt jedoch nicht durchgehend eingesetzt, und die meisten Anbieter priorisieren RoCE bei ihren NVMe-oF-Lösungen.
• InfiniBand ist eine weitere Transportmethode, die RDMA nativ implementiert. InfiniBand wird häufig in High-Performance-Computerumgebungen eingesetzt, in denen extrem geringe Latenz und extrem hoher Durchsatz unabdingbar sind.

Optimale Anwendungsfälle: High-Performance-Cluster, KI/ML-Pipelines, Finanzdienstleistungen, Arbeitslasten, bei denen eine möglichst geringe Latenz unverzichtbar ist.

Abstriche:

• Erfordert spezialisierte NICs mit RDMA-Support
• Konfiguration und Fehlersuche können kompliziert sein (speziell bei RoCE)
• In Umgebungen mit mehreren Anbietern ist die Interoperabilität begrenzt.

Fibre Channel (FC-NVMe)

Fibre Channel hat sich bei Enterprise Storage bewährt. Mit FC-NVMe können Unternehmen NVMe-Befehle über vorhandene FC-Fabrics ausführen, ohne die komplette Infrastruktur austauschen zu müssen. Bei Unternehmen, die viel Geld in SANs investiert haben, ist dies die einfachste Art, NVMe-oF einzuführen.

Die Vorteile, die für FC sprechen, sind seine Reife, seine Stabilität und sein Toolset. Speicheradministratoren, die schon jahrelang FC-Umgebungen verwalten, können FC-NVMe mit minimalem Training einsetzen. Die Performance ist stark und die Latenz liegt in der Regel bei 50 bis 100 Mikrosekunden – nicht so gering wie bei RDMA, aber immer noch erheblich besser als SCSI-over-FC.

Optimale Anwendungsfälle: Unternehmen, die ihre vorhandenen FC-SAN-Deployments modernisieren möchten, ohne ihre Netzwerke komplett überholen zu müssen.

Abstriche:

• Erfordert FC-HBAs und FC-Switches (kann vorhandene Ethernet-Netzwerke nicht nutzen)
• Geringere Anbieterdichte gegenüber Ethernet-basierten Konzepten
• Betriebliche Silos: Den Netzwerkteams fehlt möglicherweise das spezifische FC-Fachwissen.

TCP (NVMe/TCP)

Das neueste Konzept, NVMe/TCP, verfolgt einen pragmatischen Ansatz: Es erlaubt die Übermittlung der NVMe-Befehle über Standard-TCP/IP-Netzwerke. Spezialisierte NICs oder verlustfreies Ethernet sind nicht erforderlich. Wenn Sie ein IP-Netzwerk haben, können Sie NVMe/TCP einsetzen.

Während TCP mit mehr Overhead als RDMA verbunden ist, haben moderne CPU- und NIC-Offloading-Funktionen die Performance-Lücke deutlich verkleinert. Die Latenz liegt bei NVMe/TCP in der Regel zwischen 100 und 200 Mikrosekunden; höher als RDMA, aber immer noch erheblich geringer als bei iSCSI oder Legacy-Protokollen. Für die meisten Enterprise-Workloads ist das schnell genug, und das einfache Deployment macht häufig die geringen Abstriche bei der Latenz wett.

Optimale Anwendungsfälle: Unternehmen, die die Vorteile von NVMe-oF wünschen, ohne in spezielle Hardware zu investieren oder ihre Netzwerkarchitektur umzubauen. Ideal für Cloud-Umgebungen, Brownfield-Rechenzentren und Kubernetes-native Plattformen.

Abstriche:

• Geringfügig höhere Latenz als RDMA und FC
• Ist für den Transport auf die CPU angewiesen, was bei sehr hohen Arbeitslasten die Performance beeinträchtigen kann (allerdings entwickelt sich das DPU- und NIC-Offloading weiter, um dieses Manko zu beheben)
• Im Vergleich zu RDMA und FC ist das Ökosystem noch nicht völlig ausgereift.

Das ganze Bild

Bei der Fabric-Entscheidung geht es nicht darum, welches allgemein die beste Lösung ist, sondern welches die beste Lösung für die jeweilige Arbeitslast und Umgebung ist.

• Ist eine extrem niedrige Latenz unverzichtbar und Sie besitzen die Kompetenzen, um ein verlustfreies Ethernet-Fabric zu verwalten, wählen Sie RDMA (RoCE).
• Wenn Sie bereits ein stabiles FC-SAN haben, ist FC-NVMe am einfachsten umzusetzen.
• Spielen Einfachheit und breite Akzeptanz eine größere Rolle als das Herausholen der letzten Mikrosekunde, ist NVMe/TCP für Sie eine zukunftsfähige Wahl.

In der Praxis wählen viele Unternehmen einen hybriden Ansatz: RDMA für ihre High-Performance-Cluster, TCP für Container-nativen Speicher in Kubernetes und FC-NVMe zur Verlängerung der Nutzung ihrer SAN-Investitionen.

NVMe-oF in modernen Architekturen

Das wahre Potenzial von NVMe over Fabrics zeigt sich aber nicht nur in Benchmarks, sondern darin, wie es das Design moderner Infrastrukturen verändert. Durch die Übertragung der geringen Latenz von NVMe auf das gesamte Netzwerk beseitigt NVMe-oF einen der letzten großen Engpässe beim datenzentrierten Computing: die Performance von Shared Storage. Diese Veränderung beeinflusst verschiedene Architekturmodelle gleichzeitig – von eng integrierten Clustern bis hin zu massiv parallelen Supercomputing-Systemen. Im Folgenden beleuchten wir vier Bereiche, in denen NVMe-oF fundamental wird:

Hyperkonvergierte Infrastruktur (HCI)

Hyperkonvergierte Infrastrukturen bündeln Rechenkapazität, Speicher und Netzwerk in einem einzigen System. Die Herausforderung besteht seit jeher darin, dass über mehrere Server verteilter Shared Storage die Konsistenz der Performance beeinträchtigt. Traditionelle Stacks leiden unter Engpässen, die durch Protokoll-Overhead und ineffiziente I/O-Pfade verursacht werden.

Mit NVMe-oF können die Server in einem Cluster ihre lokalen NVMe-Festplatten beinahe ohne zusätzliche Latenz an ihre Peers bereitstellen. Die Übermittlungs- und Verarbeitungswarteschlangen können im gesamten Fabric abgebildet werden, sodass sich Remote-Zugriff beinahe wie lokaler Zugriff anfühlt. In der Praxis verwandelt dies eine Sammlung von Festplatten, die auf verschiedenen Servern verteilt sind, in einen einheitlichen, leistungsstarken Speicherpool.

Das hat zwei wesentliche Vorteile: Arbeitslasten mit strikten Latenzanforderungen können ohne ein separates SAN direkt auf HCI laufen und die Performance kann durch Hinzufügen von Servern linear skaliert werden. In gemischten Umgebungen mit Datenbanken, Auswertungsmaschinen und Virtual Desktops wird dadurch einer der größten Abstriche der Hyperkonvergenz beseitigt.

Software-Defined Storage

Software-Defined Storage (SDS)-Plattformen bündeln Speicher über mehrere Server hinweg zu einem logischen Pool, abstrahieren ihn und verwalten ihn über eine Software. Die Achillesferse ist seit jeher das Netzwerk. Unabhängig davon, wie schnell die Festplatten sind: Die Gesamtleistung wird von der Kommunikation zwischen den Servern bestimmt.

NVMe-oF hilft SDS-Systemen dabei, eine Near-Local-Performance zu erreichen. Durch die Beseitigung des Fabric-Overheads wird eine Lese- oder Schreibanfrage zwischen verschiedenen Servern mit einer Latenz im Zehner-Mikrosekundenbereich anstatt im Hunderter-Mikrosekundenbereich übermittelt. So kann SDS latenzempfindliche Arbeitslasten unterstützen, die bisher an dedizierte Arrays relegiert wurden.

Der Parallelismus des Protokolls unterstützt auch Mehrmandanten- oder Mehranwendungsumgebungen. Pro Mandant oder Arbeitslast können mehrere Tausend Übermittlungs- und Verarbeitungswarteschlangen zugewiesen werden. Dadurch werden Konkurrenz- und „Noisy Neighbour“-Effekte verringert. In der Praxis bedeutet dies eine vorhersehbare Performance, selbst wenn mehrere Dutzend unabhängige Clients sich denselben verteilten Speicherpool teilen.

Parallele File-Systeme

Beim High-Performance Computing und großvolumigen Datenauswertungen ermöglichen parallele File-Systeme mehreren Tausend Clients den gleichzeitigen Zugriff auf denselben Datensatz. In diesen Systemen entstehen Engpässe häufig nicht durch die rohe Mediengeschwindigkeit, sondern durch die Latenz und den Durchsatz des Fabrics zwischen Rechenkapazität und Speicher.

NVMe-oF behebt dieses Problem, indem es den direkten, latenzarmen Zugriff der Rechenserver auf die NVMe-gestützten Speicherziele ermöglicht. Die I/O-Anfragen müssen nicht mehrere Übersetzungsebenen durchlaufen, sondern die Befehle werden nativ über das Fabric übermittelt. Bei der RDMA-Übermittlung sinkt die Latenz selbst bei einer Skalierung auf mehrere Tausend Server in den Zehner-Mikrosekundenbereich. Bei TCP-Übermittlung können Unternehmen parallele Dateisysteme über Ethernet einsetzen und trotzdem Leistungsverbesserungen im Vergleich zu veralteten NFS oder iSCSI erzielen.

Das führt zur effizienteren Nutzung von Rechenclustern. CPUs und GPUs verbringen weniger Zeit mit dem Warten auf Daten und mehr Zeit mit der Verarbeitung der Daten. Für wissenschaftliche Simulationen, das Training großvolumiger KI-Modelle oder die Auswertung von Datensätzen im Petabyte-Bereich verkürzen diese Verbesserungen direkt die Zeit bis zu den Ergebnissen.

Container-nativer Speicher

Container sind von Natur aus flüchtig, doch die Anwendungen, die darauf laufen, sind dies häufig nicht. Zustandsbehaftete Arbeitslasten wie Datenbanken, Nachrichtensysteme und KI-Pipelines benötigen persistenten Speicher, der mit der Flexibilität des Containermodells mithalten kann.

Mit NVMe-oF können Container-native Speicherplattformen persistente Datenträger mit der gleichen niedrigen Latenz wie lokale NVMe-Festplatten nutzen und dabei die Flexibilität der gemeinsamen Infrastruktur wahren. Pods können Blockspeicher dynamisch an- und abkoppeln. Die Antwortzeit beträgt dabei Mikrosekunden statt Millisekunden.

Da moderne Betriebssysteme NVMe-oF automatisch unterstützen, kann es von Containerspeicher-Treibern ohne zusätzliche Emulationsebenen implementiert werden. Das verringert die Komplexität und stellt sicher, dass bei High-Performance Workloads (wie zustandsbehaftete Datenbanken in Kubernetes-Clustern) keine Abstriche zwischen Flexibilität und Geschwindigkeit mehr nötig sind.

Fazit

Es geht bei NVMe over Fabrics nicht in erster Linie um Befehlssätze oder um die letzte Mikrosekunde verkürzte I/O-Pfade. Es geht viel eher darum, wie sich die Infrastruktur weiterentwickeln kann, wenn der Speicher kein Hemmschuh mehr ist. Sobald der Speicher parallel mit der Rechenkapazität und dem Netzwerk skalieren kann, ergeben sich neue Designmuster, die reibungslosere, effizientere und besser auf den Datenabruf der Anwendungen abgestimmte Architekturen ermöglichen.

Der große Vorteil von NVMe-oF ist, dass es im Hintergrund läuft. Die Anwendungen müssen nicht „wissen“, ob ihre Daten lokal oder remote sind. Entwickler müssen keine Kompromisse zwischen Flexibilität und Performance eingehen. Architekten müssen nicht zwischen Effizienz und Skalierung wählen. Mit NVMe-oF kann das Storage-Fabric einfach Schritt halten.

In Zukunft wird NVMe-oF vermutlich eine noch größere Rolle spielen, wenn neue Beschleuniger, smarte Netzwerkgeräte und speichersemantische Fabrics Einzug in die Rechenzentren halten. Doch der Zweck bleibt gleich: Distanzen als Hemmschuh beseitigen, damit Daten so schnell und nahtlos übermittelt werden können, wie es moderne Arbeitslasten erfordern. Für Unternehmen geht es nicht darum, ob NVMe-oF schneller ist. Es geht darum, ob sie bereit sind, Systeme so zu gestalten, dass die Storage Performance kein Engpass mehr ist, und sich dadurch mehr Möglichkeiten eröffnen.

Kontaktieren Sie DataCore, um zu erfahren, was NVMe-oF für unsere Datenspeicherlösungen bedeutet und wie NVMe-oF die Performance, Skalierbarkeit und Effizienz Ihrer Infrastruktur beschleunigen kann.

Nützliche Ressourcen

• Blog: NVMe: Die Kraft der Hochgeschwindigkeitsspeicherung freisetzen
• Blog: Die wichtigsten Technologien, die die moderne Datenarchitektur prägen
• Blog: Verbessern Sie die Performance Ihrer Anwendungen mit vier Best Practices für die Speicherung

• Was kostet das langfristig tatsächlich?
• Und zahlt sich das am Ende für das Unternehmen aus?

Das ist der ewige Kampf zwischen Gesamtbetriebskosten (TCO) und Kapitalrendite (ROI). Jahrelang bemühten sich IT-Führungskräfte um Schonung ihrer Budgets, indem sie sich auf eine Seite der Gleichung konzentrierten: Kostensenkung. Doch in der hoch digitalisierten Welt von heute reichen Einsparungen nicht aus, um wettbewerbsfähig zu bleiben. Unternehmen benötigen eine Technologiestrategie, die sowohl Effizienz als auch Wachstum liefert.

Hier überzeugt die hyperkonvergierte Infrastruktur (HCI). Durch die Konvergenz von Rechenkapazität, Speicher und Netzwerk in einem einheitlichen, softwaregesteuerten System ermöglicht HCI nicht nur Kosteneinsparungen, sondern auch messbaren Geschäftswert.

TCO und ROI bei IT-Investitionen

Bei der Bewertung jeder Technologie wird die Diskussion von zwei finanziellen Faktoren bestimmt: TCO und ROI. Diese Faktoren hängen zwar zusammen, messen jedoch unterschiedliche Wertaspekte.

Zusammen genommen liefern TCO und ROI ein ganzheitliches Bild des Werts, den eine Technologie bietet. Geringe TCO ohne messbare ROI sind ein Indikator für Effizienz, aber nicht für Wachstum. Umgekehrt ist eine hohe ROI ohne nachhaltige TCO langfristig finanziell nicht tragbar. Betrachtet man diese beiden Kennzahlen nebeneinander, werden Risse in den traditionellen Infrastrukturmodellen sichtbar, die Unternehmen weitaus mehr kosten, als ihnen klar ist.

Herausforderungen traditioneller Infrastrukturen

Traditionelle Infrastrukturen mit drei Ebenen, in denen sich Server, Speicher und Netzwerke in separaten Silos befinden, waren früher der Goldstandard. Heute verursacht diese Struktur jedoch eher Kopfschmerzen als Nutzen. Die Kosten werden schnell unübersichtlich, da Spitzenbedarfe häufig mit zusätzlicher Hardware abgedeckt werden, die in normalen Zeiten ungenutzt bleibt. Die Verwaltung unterschiedlicher Systeme und Anbieter erhöht die Komplexität und bindet IT-Mitarbeiter, die dann nicht mehr für Innovation zur Verfügung stehen.

Bei einer Skalierung verschlimmert sich alles. Eine Kapazitätserweiterung ist häufig mit Betriebsstörungen und gewaltsamen Upgrades verbunden. Verdeckte Kosten beispielsweise für Strom, Kühlung und Platzbedarf treiben die Ausgaben unbemerkt weiter in die Höhe. Das Ergebnis: eine Umgebung, die teuer und unflexibel und immer häufiger nicht auf die Anforderungen eines schnell getakteten digitalen Geschäfts abgestimmt ist.

Der Auftritt der hyperkonvergierten Infrastruktur (HCI)

Hyperkonvergierte Infrastruktur wurde entwickelt, um genau diese Herausforderungen zu meistern. Im Wesentlichen bricht HCI die Silos der Rechenkapazität, Speicher und Netzwerke auf und führt sie in einem einzelnen, softwaredefinierten System zusammen. Anstatt unterschiedliche Technologien zu verwalten, verwalten Sie eine zentrale Plattform, meist über eine intuitive Oberfläche, die Ihnen über eine einheitliche Bedienkonsole den vollständigen Überblick über Ihre Infrastrukturen ermöglicht.

Daraus resultiert ein Rechenzentrum, das sich völlig anders anfühlt. Bei einer Skalierung ist kein gewaltsames Upgrade erforderlich. Sie fügen einfach einen weiteren Server zum Cluster hinzu und das System verteilt die Arbeitslasten automatisch neu. Die Bereitstellung nimmt nicht länger mehrere Wochen unter Einbindung mehrerer Teams und Genehmigungsstufen in Anspruch, sondern kommt in Sachen Geschwindigkeit und Einfachheit an den Start einer virtuellen Maschine heran. Weil die Infrastruktur softwaredefiniert ist, ist sie flexibler und kann mit hybriden und Multi-Cloud-Strategien verknüpft werden, wenn sich die geschäftlichen Anforderungen weiterentwickeln.

Im Wesentlichen passt HCI das Rechenzentrum an die Realität der modernen Geschäftswelt an: Es wird schlanker, schneller und anpassungsfähiger. Dabei geht es nicht nur um Kostensenkung, es geht darum, eine IT-Grundlage zu schaffen, die auf die Arbeitsweise moderner Unternehmen im digitalen Zeitalter abgestimmt ist.

Der TCO-Vorteil durch HCI

• Hardware-Konsolidierung
  HCI macht separate Speicher- und Netzwerksysteme überflüssig, senkt Anschaffungskosten und verringert die physische Ausbreitung des Equipments.
• Geringere Betriebskosten
  Gibt es weniger Teile, die sich bewegen, spart man an Strom, Kühlung und Platz – alles Faktoren, die die TCO in traditionellen Umgebungen still und leise in die Höhe treiben.
• Vereinfachtes Management
  Die zentralisierte Steuerung optimiert den Betrieb, der Arbeitsaufwand verringert sich und für die Verwaltung der Infrastruktur sind keine Spezialkenntnisse erforderlich.
• Vorhersehbare Skalierung
  Anstatt hohe Anfangsinvestitionen in große Kapazitätsmengen zu tätigen, können Unternehmen dank HCI nach und nach bedarfsgerecht skalieren.
• Schnellere Bereitstellung
  Mit vorkonfigurierten, softwaregesteuerten Lösungen oder einsatzfertigen HCI-Appliances ist die Infrastruktur schnell betriebsbereit. Das senkt auch die Beratungskosten und verkürzt die Amortisationsdauer.

So entsteht eine schlankere, besser vorhersehbare Kostenstruktur, die verhindert, dass die Ausgaben explodieren.

ROI-Treiber durch HCI

• Agilität und Geschwindigkeit
  HCI ermöglicht die schnelle Bereitstellung von Ressourcen, sodass Unternehmen neue Anwendungen und Dienste rascher einführen können, um Marktchancen zu ergreifen.
• Eingebaute Resilienz
  Redundanz- und Notfallwiederherstellungsfunktionen sind in HCI nativ vorhanden. So werden Ausfallzeiten minimiert und Umsätze geschützt.
• Höhere Produktivität
  Automatisierung befreit IT-Teams von Routinewartungsarbeiten, sodass sie sich auf strategische Initiativen konzentrieren können, die Innovation fördern.
• Performance-Optimierung
  Softwaredefinierte Effizienz gewährleistet den reibungslosen Ablauf von Arbeitslasten, verbessert das Benutzererlebnis und das Geschäftsergebnis.
• Zukunftssicherheit
  HCI legt das Fundament für hybride und Multi-Cloud-Einführungen und sichert die Anpassungsfähigkeit der Unternehmen bei sich weiterentwickelnden geschäftlichen und technologischen Anforderungen.

Kurz gesagt: HCI senkt nicht nur die Kosten, sondern schafft auch messbaren geschäftlichen Mehrwert, durch Wachstum, Resilienz und Innovation.

TCO vs. ROI: Auf das Gleichgewicht kommt es an

Die wahre Stärke einer hyperkonvergierten Infrastruktur liegt in ihrer Fähigkeit, sowohl TCO-Einsparungen als auch ROI-Vorteile zu erzielen. Im Gegensatz zu traditionellen Infrastrukturen, die häufig Kompromisse zwischen Kosteneffizienz und Agilität erfordern, punktet HCI auf beiden Seiten der Gleichung.

Ein einfacher Vergleich sieht wie folgt aus:

Indem HCI ein Gleichgewicht zwischen niedrigerem TCO und höherem ROI gelingt, schafft sie ein starkes Geschäftsszenario für die IT-Modernisierung. Dabei handelt es sich nicht einfach um eine technologische Erneuerung, sondern um eine strategische Investition, die die IT auf die Geschäftsergebnisse ausrichtet.

Fazit

IT-Infrastrukturentscheidungen wurden jahrzehntelang durch Kompromisse zwischen Kosten und Nutzen bestimmt. Traditionelle, aus drei Ebenen bestehende Systeme zwangen Führungskräfte, eine Wahl zu treffen: entweder Kosten senken und möglicherweise Innovation hemmen oder hohe Investitionen tätigen, nur um agil zu bleiben. Hyperkonvergierte Infrastruktur löst dieses Dilemma. Durch Aufbrechen der Silos der Rechenkapazität, Speicher und Netzwerke und die Zusammenführung in einer einheitlichen, softwaregesteuerten Plattform senkt HCI die Gesamtbetriebskosten und verbessert die Geschäftsergebnisse.

Für Unternehmen, deren IT-Infrastruktur Altsysteme umfasst, ist der Weg in die Zukunft klar vorgegeben. HCI ist nicht nur ein technologisches Upgrade, sondern eine intelligente Möglichkeit, die IT auf die geschäftlichen Ziele abzustimmen. Unternehmen, die diesen Schritt früher vollziehen, werden am besten positioniert sein, um in der digitalisierten Wirtschaft zu wachsen, innovativ zu sein und wettbewerbsfähig zu bleiben.

Kontaktieren Sie DataCore noch heute, um zu erfahren, wie unsere HCI-Lösungen Ihnen dabei helfen können, Kosten zu sparen, Innovation zu beschleunigen und eine zukunftssichere Infrastruktur aufzubauen.

Nützliche Ressourcen

• Whitepaper: Datenspeicher Neu Gedacht
• Case Study: Sicherstellung der Geschäftskontinuität für Zuegg mit einer zuverlässigen hyperkonvergierten Infrastrukturlösung
• StarWind HCI-Lösungen von DataCore entdecken

Bis dieses schöne Gefüge von der Realität eingeholt wurde. Die Geschäftswelt basiert auf Daten: Bestellverläufe, Nutzerprofile, Finanztransaktionen, Produktbestände, Protokolle, Auswertungen … Diese Arbeitslasten sind nicht zustandslos; sie sind darauf angewiesen, dass im Laufe der Zeit immer wieder auf dieselben Daten zugegriffen werden kann. Plötzlich hatte Kubernetes es mit Anwendungen zu tun, bei denen „einfach neu starten“ den Verlust riesiger Mengen an kritischen Daten bedeuten konnte.

Hier kam persistenter Speicher ins Spiel. Ohne persistenten Speicher ist die Verarbeitung zustandsbehafteter Arbeitslasten auf Kubernetes wie das Anlegen einer Datenbank auf einer Festplatte aus Eis. Man kann darauf unzählige Schreibvorgänge ausführen, aber in dem Moment, in dem sich die Temperatur ändert, geht alles den Bach runter.

Zustandslose oder zustandsbehaftete Arbeitslasten: ein Unterschied, der alles verändert

Am einfachsten lässt sich die Notwendigkeit persistenten Speichers verstehen, wenn man sich den Unterschied zwischen zustandslosen und zustandsbehafteten Arbeitslasten in Kubernetes vor Augen führt.

Ein zustandsloser Dienst ist wie ein Mitarbeiter einer Mautstelle, der keine Aufzeichnungen führt. Die Autos passieren die Stelle, er kassiert die Gebühr, damit ist der Job erledigt. Geht der Mitarbeiter nach Hause und seine Ablösung übernimmt seinen Dienst, geht kein Verlauf verloren. In Kubernetes-Begriffen ausgedrückt wäre das beispielsweise eine HTTP API für Produktlisten, ein PDF-Renderdienst oder ein einfacher Ereignisprozessor.

Zustandsbehaftete Arbeitslasten könnte man hingegen eher mit einem Bankmitarbeiter vergleichen. Jede Transaktion muss aufgezeichnet und gespeichert werden und später noch zugänglich sein. Geht der Mitarbeiter nach Hause und nimmt die Aufzeichnungen mit, bricht der Geschäftsbetrieb der Bank zusammen. In Kubernetes wären das Ihre MySQL-Datenbank, Ihre Kafka-Broker, Ihr Elasticsearch-Cluster oder sogar Redis im Persistenzmodus.

Der Grund für den Unterschied liegt im Lebenszyklus der Kubernetes-Pods: Die Pods sind flüchtig. Sie sind nicht an eine bestimmte Hardware gebunden und können jederzeit gelöscht oder verschoben werden. Das ist ein großer Vorteil für die Skalierung und die Resilienz, aber ein eklatanter Nachteil für alles, was darauf angewiesen ist, dass lokale Daten morgen auch noch da sind.

Das Problem mit dem flüchtigen Speicher

Jeder Pod in Kubernetes hat einen integrierten Speicher, der allerdings flüchtig ist – er existiert nur so lange, wie der Pod existiert. Fällt der Pod aus, sei es, weil Sie ein Update aufspielen oder weil der Knoten, auf dem er läuft, abstürzt, wird der Speicher gelöscht.

In Kubernetes kann man Datenträger wie emptyDir als temporären Speicher nutzen. Sie sind perfekt für Caches, temporäre Dateien oder kurzfristige Rechenvorgänge. Sie sind allerdings auf den Lebenszyklus des Pods beschränkt. Das bedeutet, wenn der PostgreSQL-Pod emptyDir zur Speicherung seiner Datenbankdateien verwendet, ist das so, als würden Sie diese direkt in /tmp speichern – gibt es den Pod nicht mehr, sind Ihre Daten ebenfalls weg.

Diese flüchtige Art macht auch die Wiederherstellung schwierig. Man stelle sich einen ausgefallenen Kafka-Broker-Pod vor. Ohne persistenten Speicher beginnt Kubernetes bei jeder Erstellung eines neuen Brokers wieder bei null. Die Offsets der Nachrichten sind weg, die Partitionsreplikate sind weg und der Cluster muss den Zustand anhand anderer Replikate wieder aufbauen – sofern es diese überhaupt gibt.

Persistenter Speicher: Entkopplung der Daten von der Rechenkapazität

Die zentrale Idee hinter persistentem Speicher in Kubernetes ist die Entkopplung der Daten vom Pod. Die Rechenressourcen (die Pods) können kommen und gehen, aber die von ihnen verwendeten Daten werden unabhängig davon in einem Speichersystem gespeichert, das Kubernetes bei Bedarf wieder ankoppeln kann.

Mit diesem Modell können Sie:

• Serverausfälle ohne Datenverlust überstehen;
• rollierende Updates durchführen, ohne den Zustand der Anwendung zu löschen;
• zustandsbehaftete Arbeitslasten auf Knoten ohne manuelle Intervention skalieren;
• ein einheitliches Verhalten der Anwendung auch bei Verschiebungen sicherstellen.

Aus Implementierungssicht gibt Kubernetes uns PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs).

• Ein PV ist die tatsächliche Speicherressource, z. B. ein AWS EBS-Datenträger, Azure Managed Disk, Google Persistent Disk, NFS-Speicher oder Ceph RBD-Blockspeicher.
• Ein PVC ist der „Vertrag“ zwischen Ihrer Anwendung und diesem Speicher. Anstatt die Speicherdetails in der Anwendungskonfiguration fest zu programmieren, geben Sie an: „Ich brauche 20 GiB an ReadWriteOnce Storage“. Kubernetes überlegt dann, wie die Bereitstellung erfolgen kann und der Speicher basierend auf den verfügbaren Speicherklassen angekoppelt werden soll.

StatefulSets: Mehr als Speicher

Während PersistentVolumes das Speicherproblem lösen, liefern sie nicht alles, was zustandsbehaftete Arbeitslasten benötigen. Viele zustandsbehaftete Anwendungen brauchen stabile Netzwerkidentitäten und geordnete Sequenzen zum Starten und Herunterfahren.

Stellen Sie sich einen Datenbank-Cluster mit Leader-/Follower-Knoten vor. Sie können nicht einfach alle Pods nach dem Zufallsprinzip gleichzeitig starten und hoffen, dass sich alles schon selbst regeln wird. Manche Knoten müssen vor anderen starten und denselben Namen behalten, um von anderen gefunden zu werden.

Zu diesem Zweck hat Kubernetes StatefulSets eingeführt. Im Gegensatz zu Deployments, die die Pods wie austauschbares Nutzvieh behandeln, behandeln StatefulSets die Pods mehr wie Haustiere, denen sie Namen geben. Die Pod-Namen sind fest (app-0, app-1, etc.) und die zugehörigen PVCs sind direkt mit diesen Namen verbunden.

Das heißt: Falls mysql-0 ausfällt, wird Kubernetes ihn als mysql-0 neu erstellen und derselbe PVC ist immer noch daran gekoppelt, unabhängig davon, auf welchem Knoten er landet. Die Anwendung kann den Betrieb wieder aufnehmen, ohne ihre Daten aus dem Blick zu verlieren.

Praxisbezogene Herausforderungen des persistenten Speichers in Kubernetes

Selbst mit PVs, PVCs und StatefulSets funktioniert der Speicher in Kubernetes nicht in jedem Szenario nach dem „Plug & Play“-Prinzip.

• Performance-Optimierung: Manche Workloads sind höchst empfindlich gegenüber I/O-Latenz. Mit der falschen Speicherklasse oder dem falschen Backend schaffen Sie möglicherweise einen Engpass für das gesamte System.
• Zonenübergreifende Verfügbarkeit: Viele Blockspeichersysteme sind an eine einzelne Verfügbarkeitszone gebunden, was hochverfügbare Deployments erschwert.
• Backup und Notfallwiederherstellung: Persistente Speicher sind nicht das Gleiche wie Backups. Wenn der zugrunde liegende Speicher ausfällt oder gelöscht wird, braucht man weiterhin Wiederherstellungsmechanismen wie Snapshots oder Replikation.
• Multi-Writer-Komplexität: Arbeitslasten, die ReadWriteMany-Zugriff benötigen, müssen sorgfältig koordiniert werden, um Beschädigungen zu vermeiden. Sie verwenden häufig gemeinsam genutzte Dateisysteme oder verteilte Speicher.

Und es gibt einen tieferen Grund, warum sich das alles so schwierig anfühlt: Die meisten herkömmlichen externen Speicher sind nicht Kubernetes-nativ. Da sie außerhalb der Kubernetes-Steuerungsebene mit eigenem Scheduler, eigenen Ausfalldomänen und eigenem Datendienstmodell angesiedelt sind, kann Kubernetes das An- und Abkoppeln, Failover oder Richtlinien nicht auf natürliche Weise koordinieren, sodass Umplanungen anfällig werden und sich der Betrieb wie ein Fremdkörper anfühlt.

Container-nativer Speicher: Die moderne Antwort

Persistenter Speicher in Kubernetes bedeutet nicht einfach, eine Festplatte zu haben, die einen Neustart der Pods überlebt. Es geht darum, einen Speicher zu haben, der die Sprache von Kubernetes versteht und spricht. Traditionelle Speichersysteme wurden bereits entwickelt, lange bevor Container gängige Praxis wurden. Sie behandeln Kubernetes häufig nur als einen Client von vielen und heften sich von außen an den Cluster. Theoretisch funktioniert das zwar, praktisch führt das allerdings zu Reibungen, beispielsweise durch manuelle Bereitstellung, komplexe Integration, nicht übereinstimmende Skalierungsmuster und schlechte Automatisierung.

Container-Native Storage (CNS) dreht dieses Modell um. Anstatt als externes System zu fungieren, mit dem Kubernetes kommunizieren muss, wird CNS als Mikrodienste-Satz im Innern von Kubernetes eingesetzt, genau wie die Anwendungen. Die Speicherebene wird damit zum Bewohner derselben Umgebung – und mit denselben Kubernetes Primitives organisiert, skaliert und verwaltet wie alles andere.

Das macht für persistenten Speicher einen großen Unterschied aus, denn es löst die zwei großen Herausforderungen, um die es in diesem Blog geht:

1. Dass die Daten länger leben müssen als der Pod, und zwar auf eine Weise, die bei einem Failover zuverlässig und vorhersehbar ist.
2. Dass der persistente Speicher so dynamisch und automatisiert wie der Rest von Kubernetes sein muss, damit man zustandsbehaftete Arbeitslasten nicht wie zarte Schneeflöckchen behandeln muss.

Mit CNS werden persistente Datenträger nicht manuell von einem Speicheradministrator im Voraus bereitgestellt; sie werden dynamisch erstellt, sobald ein PersistentVolumeClaim vorliegt. In dem Moment, in dem die Anwendung 50 GiB an ReadWriteOnce-Speicher anfordert, stellt die CNS-Ebene automatisch einen Datenträger bereit, integriert ihn in das PersistentVolume-Subsystem von Kubernetes und koppelt ihn an die betreffende Arbeitslast.

Weil der CNS im Cluster verteilt ist, gilt:

• Daten können knotenweit repliziert werden, um Hochverfügbarkeit sicherzustellen, damit der Ausfall eines Knotens nicht den Ausfall des Speichers bedeutet.
• Das Failover ist nativ. Wird ein Pod auf einen anderen Knoten verschoben, kommt der Speicher automatisch mit (oder ein identisches Replikat befindet sich bereits dort).
• Die Speicher-Performance skaliert gemeinsam mit dem Cluster. Wenn Sie Knoten hinzufügen, erhalten Sie nicht nur mehr Rechenkapazität, sondern auch mehr Speicherkapazität und mehr Durchsatz.
• Speicherdienste wie Snapshots, Thin Provisioning usw. sind in dieselbe Umgebung eingebaut und benötigen keine externen Verwaltungswerkzeuge.

Anders ausgedrückt: CNS liefert Kubernetes nicht nur persistenten Speicher, sondern dieser persistente Speicher ist sogar Kubernetes-nativ. Die persistente Speicherebene hinkt der Rechenebene in puncto Automatisierung, Resilienz und Skalierung nicht länger hinterher. So ist es endlich möglich, zustandsbehaftete Arbeitslasten mit der gleichen betrieblichen Sicherheit zu verarbeiten wie zustandslose.

So kann DataCore helfen

Bei der Wahl und dem Betrieb der passenden persistenten Speicherstrategie in Kubernetes geht es nicht nur um die Wahl einer Technologie. Es geht darum, diese Technologie an das Performance-Profil, den Verfügbarkeitsbedarf und die Wachstumspläne Ihrer Anwendung anzupassen. Hier kann DataCore den entscheidenden Unterschied bewirken.

DataCore ist Experte für softwaredefinierte, Container-native Speicherlösungen, die sich nahtlos in Kubernetes integrieren lassen. Durch die Kombination aus Speicherdiensten der Enterprise-Klasse – wie Hochverfügbarkeit, Replikation, Snapshots und Backups – mit einem Kubernetes-nativen Betriebsmodell hilft DataCore Unternehmen dabei, selbst anspruchsvollste zustandsbehaftete Arbeitslasten sicher zu verarbeiten.

Ob Sie vorhandene Anwendungen modernisieren, Cloud-native Datenbanken einsetzen oder von Grund auf neue zustandsbehaftete Dienste aufbauen: DataCore bietet Ihnen die Tools, Leitlinien für die Architektur und operativen Support, damit Ihre Speicherebene ebenso agil, resilient und automatisiert ist wie Kubernetes selbst. Das Ergebnis: eine Plattform, auf der sowohl zustandslose als auch zustandsbehaftete Arbeitslasten Seite an Seite funktionieren können, ohne dass Sie Kompromisse eingehen müssen.

Sind Sie bereit, Ihren persistenten Speicher für Kubernetes produktionsreif zu machen? Kontaktieren Sie uns, um zu besprechen, wie DataCore Ihnen bei der Verarbeitung zustandsbehafteter Arbeitslasten helfen und höchste Zuverlässigkeit und Performance sicherstellen kann.

Entdecken Sie DataCore Puls8

Trotzdem unterschätzen viele Unternehmen immer noch, wie teuer selbst Ausfallzeiten von nur wenigen Minuten sein können.

Was sind Ausfallzeiten?

Der Begriff „Ausfallzeit“ bezeichnet jeden Zeitraum, für den ein System oder eine Anwendung nicht verfügbar ist oder nicht wie beabsichtigt funktioniert. Es gibt geplante Ausfallzeiten (z. B. Wartungsfenster) und ungeplante Ausfallzeiten (z. B. Hardwarefehler, Cyberangriffe, Softwareviren, Stromausfälle).

Geplante Ausfallzeiten lassen sich durch Vorausplanung und Kommunikation steuern. Ungeplante Ausfallzeiten kommen aus heiterem Himmel und können zu erheblichen Schäden führen.

Ausfallzeit = finanzieller Verlust

In erster Linie führt Ausfallzeit dazu, dass kein Umsatz erzielt wird. Bei Unternehmen, die auf Transaktionssysteme angewiesen sind – ob Onlineshops, Buchungsmaschinen oder Onlinebanking – bedeutet ein Ausfall, dass keine Einnahmen erzielt werden.

Beispiele:

• Ein globaler Zahlungsverarbeiter könnte bei einem 30-minütigen Ausfall zu Spitzenzeiten Millionen an Transaktionsvolumen verlieren – vom Vertrauen der Kunden ganz abgesehen.
• Gehen die Kassensysteme einer Einzelhandelskette auch nur kurz offline, kann dies zu Umsatzverlusten, Bestandsabweichungen und langen Schlangen an den Kassen führen, sodass sich die Kunden genervt verabschieden.

Selbst wenn in Ihrem Unternehmen keine Transaktionen in Echtzeit abgewickelt werden, können Ausfallzeiten Ihren Betrieb in Form von Produktionsverzögerungen oder Lieferkettenstörungen indirekt beeinträchtigen.

Das Uptime Institute fand heraus, dass ungeplante Ausfallzeiten von Anwendungen Unternehmen über 100.000 Dollar pro Zwischenfall kosteten – manche Ausfälle brachten es sogar auf über 1 Million Dollar, abhängig von Schweregrad und Dauer.

Betriebsstörungen und Produktivitätsverluste

Wenn Systeme ausfallen, können Menschen nicht arbeiten. Geschäftsprozesse, die auf den Echtzeitzugriff auf Anwendungen und Daten angewiesen sind, können nicht ausgeführt werden. Teams und Abteilungen müssen untätig ausharren, bis die Systeme wieder online sind.

• Software-Ingenieure haben keinen Zugriff auf Codespeicher und können nicht an ihren Pipelines arbeiten. So verzögern sich Neuentwicklungen und Bereitstellungen.
• Vertriebsteams verlieren den Zugriff auf CRMs, wodurch ihnen Opportunities und Follow-ups entgehen, die sich nicht ohne Weiteres aufholen lassen.
• Support-Teams können die Datensätze der Kunden und Ticketverläufe nicht aufrufen. Das frustriert die Nutzer und beeinträchtigt die Servicequalität.
• Produktionssysteme stoppen, weil die Prozessleitsysteme nicht funktionieren. Die Produktionsabläufe werden gestört, die Betriebskosten steigen.

Solche Produktivitätseinbußen schlagen Wellen durch das gesamte Unternehmen. Teams greifen entweder auf ineffiziente manuelle Umleitungen zurück oder stellen die Arbeit komplett ein. So werden Fälligkeitstermine überschritten, Projektzeiträume gesprengt und die Motivation ausgebremst. Selbst kurze Ausfälle können überdimensional große nachgelagerte Auswirkungen haben, vor allem in schnell getakteten oder stark automatisierten Umgebungen.

Versteckte Kosten: Markenimage, Vertrauen und Moral

Kunden erwarten Verfügbarkeit. Schon ein einziger Ausfall kann ihre Wahrnehmung drastisch verändern, vor allem, wenn Nutzer in Echtzeit in Social Media davon berichten.

• SaaS-Unternehmen riskieren, dass Kunden abwandern, wenn B2B-Kunden das Vertrauen in die Stabilität der Plattform verlieren.
• Gesundheitsorganisationen drohen Sicherheitsprobleme und aufsichtsrechtliche Strafen, wenn Systeme mit Patienten- oder Diagnosedaten unvermittelt offline gehen.
• Mitarbeiter sind frustriert, Support-Teams überlastet und die Moral leidet mit jeder Minute, die die Behebung des Zwischenfalls dauert.

Ein einziger Ausfall kann einen ganzen Rattenschwanz an negativen Auswirkungen für die Reputation nach sich ziehen, die weit länger anhalten als der Zwischenfall selbst.

Compliance- und Rechtsfolgen

Ausfälle können zu Verletzungen von Branchenvorschriften (z. B. HIPAA, DSGVO, NIS2, PCI-DSS) führen, wenn sensible Daten nicht länger durch Systeme geschützt sind oder nicht abgerufen werden können. Eine solche Situation kann Prüfungen, Gerichtsverfahren und drastische Bußgelder nach sich ziehen.

Beispiel: Ein Finanzdienstleistungsunternehmen, das aufgrund eines Systemausfalls vorgeschriebene Meldungen nicht vornehmen kann, verstößt damit gegen gesetzliche Anforderungen. Neben der Rufschädigung drohen möglicherweise auch noch Bußgelder.

Was fällt eigentlich aus? Die Realität der Infrastruktur

Die meisten Ausfallzeiten entstehen nicht durch Naturkatastrophen oder raffinierte Cyberangriffe. Viel häufiger ist es die grundlegende Infrastruktur, die ausfällt, falsch konfiguriert ist oder ohne ausreichend Redundanz geplant wurde. Solche Probleme bauen sich still und leise auf und kommen erst dann an die Oberfläche, wenn es zu spät ist. Häufige Gründe:

• Single-points-of-failure in Speichersystemen oder Netzwerkpfaden
• Manuelle Failover-Prozesse, die langsam und fehleranfällig oder gar nicht vorhanden sind
• Alternde Hardware, die moderne hochverfügbare Konfigurationen nicht mehr unterstützt
• Fehlende Echtzeit-Replikation zwischen kritischen Speicherservern und damit verbunden Datenverluste oder Inkonsistenzen
• Wiederherstellungsverfahren, die eine manuelle Intervention oder den vollständigen Neustart der Systeme erfordern und so die Ausfallzeit von Minuten auf Stunden verlängern

In vielen Fällen passieren solche Ausfälle nicht isoliert; sie laufen lawinenartig ab. Eine einzige ausgefallene Komponente verlangsamt alle Abläufe, löst Engpässe und I/O-Zeitfehler aus, bis am Ende die gesamte Anwendung abstürzt. Am häufigsten gehen Ausfallzeiten auf Designfehler zurück und nicht auf unglückliche Umstände.

Die Speicherebene: die am häufigsten übersehene Ursache von Ausfällen

Wenn es um Verfügbarkeit geht, wird Anwendungen, Netzwerken und Rechenkapazität die größte Aufmerksamkeit geschenkt. In der Realität ist es jedoch häufig der Speicher, der für ungeplante Ausfälle oder längere Wiederherstellungszeiten sorgt – nicht etwa, weil er selbst anfällig ist, sondern weil er bei der Architektur nicht genügend beachtet wurde; Stichworte: Verfügbarkeit und Fehlertoleranz.

In vielen Umgebungen wird das Speichersystem zum Single-point-of-failure, speziell in Systemkonfigurationen mit Direct Attached Storage (DAS), traditionellen SAN-Arrays mit begrenzter Controller-Redundanz oder isolierten Systemen ohne Replikation. Ein Festplattenausfall mag zunächst nicht katastrophal erscheinen, doch in Systemen ohne Synchronen Spiegel oder automatisches Failover können selbst kleinere Störungen zu einer Kaskade von gesperrten Datenträgern, unterbrochenen Schreibvorgängen oder Abstürzen im kompletten Stack führen.

Die Resilienz des I/O-Pfads ist genauso kritisch. Ist das Multipathing inkorrekt konfiguriert oder wird der Speicher-Controller durch die Failover-Last zum Engpass, leidet die Reaktion der Anwendungen, selbst wenn der Speicher technisch nicht offline ist. Diese Art von „Greyout“, bei der die Verschlechterung der Performance wie ein Totallausfall wirkt, ist bei Transaktionen oder latenzempfindlichen Workloads besonders gefährlich.

Der Speicher spielt auch für die Recovery Time Objectives (RTO) eine wichtige Rolle. Snapshots, Replikationsverzögerungen oder uneinheitlich bereitgestellte Datenträger können die für die Wiederherstellung benötigte Zeit unnötig in die Länge ziehen. Und wenn es Speicherplattformen an granularer Transparenz oder zentraler Orchestrierung mangelt, verlängert dies die Reaktionszeit bei Zwischenfällen und zwingt Teams, blind auf Fehlersuche zu gehen.

In modernen Umgebungen, speziell in solchen, in denen Virtualisierung, Containerisierung und verteilte Anwendungen dominieren, muss die Speicherinfrastruktur störungsfreies Skalieren, Live-Updates, schnelles Failover und richtliniengesteuerte Automatisierung unterstützen. Ohne diese Fähigkeiten ist selbst ein gut geplanter Rechen- oder Anwendungsstack anfällig.

Wie DataCore Ihnen hilft, Ausfallzeiten zu vermeiden

Ausfallzeiten sind häufig auf Lücken in der Speicherebene zurückzuführen. Durch mangelnde Redundanz, begrenzte Failover-Automatisierung oder Performance-Engpässe kann sich eine kleine Störung zu einem ausgewachsenen Systemausfall entwickeln. DataCore mindert diese Risiken durch die Unterstützung von serverübergreifendem synchronem Spiegeln und kontinuierlichen I/O-Operationen auch beim Ausfall eines Servers oder Pfads. DataCore ermöglicht außerdem unterbrechungsfreie Wartungen und Upgrades, sodass auf geplante Wartungszeitfenster – die die Verfügbarkeit natürlich beeinträchtigen – verzichtet werden kann. Eingebaute Failover-Logik und Mechanismen für die schnelle Wiederherstellung verringern die Notwendigkeit manueller Interventionen, sodass Ihre Teams die Systeme im Idealfall innerhalb von Sekunden (und nicht Stunden) wieder zum Laufen bringen können.

Um die Hochverfügbarkeit in unterschiedlichsten Umgebungen – vom Großunternehmen bis zu abgelegenen oder verteilten Standorten – zu gewährleisten, bietet DataCore maßgeschneiderte Lösungen an:

• SANsymphony ist ideal für Kernrechenzentren, die für ihre missionskritischen Arbeitslasten auf hohe Performance, große Volumina und kontinuierliche Verfügbarkeit angewiesen sind.
• StarWind (jetzt Teil von DataCore) bietet eine kompakte, widerstandsfähige HCI-Lösung für Edge-, ROBO- und dezentrale IT-Umgebungen, in denen es auf Einfachheit, geringen Platzbedarf und hohe Verfügbarkeit ankommt.

Um zu erfahren, wie DataCore Ihnen helfen kann, Ausfallzeiten zu vermeiden und Ihre Infrastruktur zu stärken, kontaktieren Sie uns, um ein Beratungsgespräch oder eine Demo zu vereinbaren.

Nützliche Ressourcen

• Blog: Verfügbarkeit vs. Langlebigkeit vs. Zuverlässigkeit vs. Resilienz vs. Fehlertoleranz
• Whitepaper: RPO, RTO und RTA: 3 wesentliche Kennzahlen zur Widerstandsfähigkeit der IT
• Blog: Skalierbare Hochverfügbarkeit und Ausfallsicherheit von Daten mit SANsymphony

Eine interessante Redensart mit einer noch interessanteren (und düsteren!) Geschichte, die auf alle möglichen Lebenslagen passt und im Grunde darauf beruht, dass man kurzfristig etwas einsetzen muss, um langfristig etwas zu erreichen.

In gewisser Weise gilt das auch für die Virtualisierung. Wir simulieren andere Systeme durch Software. Das kostet möglicherweise etwas an Performance, doch keine Sorge: Es lohnt sich, denn die Vorteile überwiegen.

Bei der Server-Virtualisierung ist die Kosten-Nutzen-Rechnung einfacher nachzuvollziehen. Solche Umgebungen sind mittlerweile weit verbreitet. Wir sehen immer häufiger Multikern-Serverarchitekturen und erleben, dass die Managementabläufe effizienter und effektiver sind.

Bei der Speichervirtualisierung erschließt sich der Kostenvorteil nicht direkt auf den ersten Blick. Das beginnt mit der Sache, die virtualisiert wird. Es handelt sich entweder um ein (scheinbar) unintelligentes Gerät oder um ein teures, intelligentes Speichersystem. Warum sollte man so etwas (das Eine wie das Andere) virtualisieren?

Es gibt überzeugende Gründe für die Speichervirtualisierung, einschließlich solcher, die man nicht sofort sieht. Kann man sie erst sehen, liegen sie auf der Hand.

Warum ist Virtualisierung also vorteilhaft?

Nur, weil wir das behaupten?

Auf der Speichervirtualisierungsseite unserer Website finden Sie die typischen Formulierungen, mit denen Anbieter üblicherweise die Vorteile der Virtualisierung anpreisen:

• Geringere Kosten
• Höhere Zuverlässigkeit
• Verbesserte Performance
• Mehr Flexibilität und Skalierbarkeit

Das wirft möglicherweise Fragen auf. Welche Kosten sind das überhaupt? Welche Vorteile lassen sich wie erzielen?

Der Einsatz

Generell ist Virtualisierung eine zusätzliche Softwareebene, die man auf unterschiedliche Weise erreichen kann. Jon Toigo unterscheidet zwischen „in-band“ und „out-of-band“ Methoden, doch letztendlich handelt es sich immer um eine zusätzliche Ebene, die im Datenpfad berücksichtigt werden muss.

Wenn wir eine Speichervirtualisierungsebene einbauen, nehmen wir im Prinzip die Geräte, die lesen und schreiben, und packen sie in eine Software, die diese Lese- und Schreibvorgänge simuliert. Ein bisschen so wie auf der Stelle zu laufen. Aber warum?

Was bringt das?  

Wir haben damit einen Platz im Datenpfad geschaffen, an dem ein leistungsstarker Allzweckcomputer eine Software ausführen kann. So entsteht enormes Mehrwertpotenzial, einschließlich der oben bereits genannten Punkte:

• Geringere Kosten
• Höhere Zuverlässigkeit
• Verbesserte Performance
• Mehr Flexibilität und Skalierbarkeit

Um zu sehen, wie diese Vorteile umgesetzt werden, schauen wir uns die Virtualisierung einmal genauer an.

Punkte für gutes Verhalten

Das Zusammenspiel zwischen den Anwendungen und dem Speicher kann man als Zugriffsmethode bezeichnen. Diese kann als Programmierschnittstelle, kurz API, modelliert werden. Die API definiert das erwartete Verhalten und liefert uns einen praktischen Rahmen für die Virtualisierung.

Der Blockspeicher ist eine Zugriffsmethode, die das SCSI Architecture Model (SAM) als „Execute Command remote procedure“ definiert:

Geringere Kosten

Zunächst können wir Blöcke voller Nullen mit … nichts darstellen! Null-Blöcke müssen nicht gespeichert werden – eine gängige Thin-Provisioning-Methode. Thin Provisioning vereinfacht die Kapazitätsplanung. Es verbessert die Nutzung der zugrunde liegenden Kapazität, um Kosten zu sparen. Spinnt man diesen Gedanken weiter, kommt man zur Deduplizierung, die doppelte Blockdaten in einzelne Instanzen im Speicherpool herunterbricht.

Wir können Zugriffsmuster bei virtuellen Blöcken verfolgen, die „Temperatur“ eines jeden Blocks synthetisieren und die Blöcke innerhalb eines Storage Pools so anordnen, dass „heiße“ Daten in schnellen (teuren) Speicher und „kalte“ Daten in langsamen (preiswerten) Speicher oder die Cloud befördert werden. Diese Auto-Tiering-Funktion arrangiert die Daten in virtuellen Disks, sodass die Anwendungen die Daten sehen, die sie benötigen, während das Virtualisierungssystem die Daten dynamisch und automatisch anhand der Kosten und Performance zuweist. Das senkt die Kosten weiter und verbessert dabei die Performance. Darauf gehen wir gleich noch näher ein.

Höhere Zuverlässigkeit

Datenblöcke können an zwei oder mehr Orten auf verschiedenen Hardwareplattformen gespeichert werden, um Hochverfügbarkeit zu gewährleisten und vor Ausfällen zu schützen.

Datenblöcke können über das Internet verteilt werden, um für Notfälle gerüstet zu sein.

Mehr Flexibilität und Skalierbarkeit

Virtuelle Disks bleiben logisch konstant, während die Datenblöcke „im Hintergrund“ automatisch verschoben werden. Das vereinfacht Migrationen. Verbinden Sie ein neues Speichersystem einfach mit dem hinteren Ende der Speichervirtualisierungssoftware und übertragen Sie die Daten automatisch und nahtlos in den neuen Speicher.

Sie wollen horizontal skalieren? Fügen Sie einfach weitere Server für die Speichervirtualisierung hinzu, um eine N+1-Architektur zu erhalten. Die virtuellen Disks können Sie zwischen diesen Servern bewegen, nach einem ähnlichen Konzept wie bei einer Live-Migration virtueller Maschinen, um die Last neu zu verteilen.

Verbesserte Performance

Sollten sich durch die zusätzliche Verarbeitung und Komplexität nicht die Latenz erhöhen und der Durchsatz verringern? Nicht unbedingt – und das ist vermutlich noch interessanter als die ganzen Speicherdienste.

Wie ist das möglich? Das System kann dynamisch und flexibel reagieren – es kann „spielen“. Dafür wurde es schließlich konzipiert. Sie haben eine moderne Multikern-Serverplattform randvoll mit High-Speed-RAM und Dutzenden paralleler CPUs.

Nutzen Sie sie.

Cachen Sie heiße Daten im RAM. Schützen Sie die RAM-Caches durch synchrones Spiegeln vor Einzelausfällen. Verarbeiten Sie I/O-Anfragen parallel auf so vielen CPUs wie möglich. Setzen Sie alle Ihre Zugpferde ein! Nutzen Sie jeden einzelnen Transistor in Ihrer Virtualisierungsimplementierung. Die durchschnittliche Latenz sinkt und der aggregierte Durchsatz steigt beträchtlich. Auch wenn man es nicht vermuten sollte: Virtualisierung erhöht tatsächlich die Performance.

Diese Vorteile werden durch das „Spielen“ mit dem Blockadressraum erreicht. Die komplexeren Speicherdienste wie die Erstellung von Snapshot–Kopien virtueller Disks oder die Verschlüsselung von Data-at-rest haben wir noch gar nicht angesprochen. Die Möglichkeiten sind praktisch grenzenlos.

I/O-Virtualisierung

Es gibt noch einen weiteren interessanten Aspekt der Blockspeichervirtualisierung. Vorhin haben wir über die Virtualisierung der Blockadressen gesprochen. Das ist nicht die einzige Möglichkeit. Wir können auch individuelle I/O-Anfragen virtualisieren.

Was bedeutet das? Hier geht es nicht so sehr um die Neuanordnung von Blöcken, sondern um die Art und Weise der Bearbeitung von Lese- und Schreibanfragen. Das eröffnet andere Möglichkeiten.

Anstatt Seiten mit Blockadressen wie ein virtuelles Memory-System neu anzuordnen, können wir die Daten in unserer Implementierung beliebig auslegen.

Wir können Sie sequenziell auslegen, wie ein Log. Das allein wirkt sich bereits positiv auf die Performance von Random-Write-Workloads aus.

Wir können die Sequenz und Struktur individueller I/O-Anfragen in diesem Log ignorieren und uns darauf konzentrieren, wie sich das sequenzielle Layout auf den Durchsatz auswirkt. Doch wenn wir die Sequenz und die Struktur der individuellen Anfragen beibehalten, bauen wir ein Zeitelement in das Log ein. Auf einmal haben wir ein System, das Continuous Data Protection (CDP) unterstützt, in dem wir sofort ein Bild einer virtuellen Disk in einem früheren Zustand herstellen können. Von allen tollen Dingen, die man mit Software anstellen kann, zählen Zeitreisen vermutlich zu den Besten.

Dateivirtualisierung

Was wäre, wenn wir mit anderen Zugriffsmethoden spielen würden, um andere Speicherdomänen zu virtualisieren? Netzwerk-Dateisystemprotokolle bieten einen weiteren breiten Anwendungsbereich für die Virtualisierung. Auch hier umfasst die Zugriffsmethode eine API, die uns den Rahmen für eine Dateivirtualisierung bietet.

Dateispeichersysteme beinhalten Dateidaten und Dateimetadaten: die Namensraumhierarchie, Ordnernamen, Dateinamen, Dateierstellungs-, -zugriffs- und -änderungszeiten. Alles Dinge, mit denen das System spielen kann! Beginnen wir mit den Daten und Metadaten.

Trennung der Zuständigkeiten

Wir können Dateimetadaten von den Dateidaten trennen. Was bringt uns das? Bessere Organisation und Performance.

Stellen wir uns eine öffentliche Bibliothek aus einer Zeit vor, als es noch physische Kartenkatalogindizes gab. Es gibt einerseits den Kartenkatalogindex (die Metadaten) und andererseits die Bücher in den Regalen (die Daten).

Der Kartenkatalogindex ist für den schnellen, problemlosen Zugriff organisiert. Er befindet sich vorne in der Bibliothek und ist einfach erreichbar. Er ist nach Thema, Autor und Titel organisiert. Verglichen mit dem Bücherstapel ist der Index ziemlich klein. Der Index ist gemäß den Anforderungen der Nutzer organisiert und optimiert.

Die Bücher sind gemäß ihren unterschiedlichen Anforderungen an die Lagerung separat untergebracht. Seltene Bücher müssen in klimatisch kontrollierten, teuren Lagerbereichen mit wenig Verkehr gelagert werden. Taschenbücher befinden sich an einem anderen Ort – preiswerter, mit mehr Verkehr und in der Nähe der Fachliteratur. Größere Folianten und Quartbände wandern größenbedingt in spezielle Regale. Bücher, die nur selten jemand ausleiht, können extern untergebracht werden.

Das ist so normal und offensichtlich, dass wir keinen Gedanken daran verschwenden. Doch stellen Sie sich vor, der Kartenkatalog würde sich wie ein Faden quer durch die Bücherstapel und die Regale spannen. Dann erkennen Sie, welche Probleme eine Mischung von Metadaten und Daten für Anwendungen bereiten kann, die auf die Speichersysteme zugreifen.

Stellen Sie sich jetzt eine Bibliothek mit mehreren Zweigstellen vor. Die Zweigstelle könnte den gesamten globalen Buchbestand anbieten, auch wenn sich nur wenige Bücher tatsächlich vor Ort befinden. Wir teilen den Haupt-Kartenkatalog mit der Zweigstele, sodass die Nutzer dieses Katalogs den gesamten globalen Bestand sehen können (den Namensraum). Ein Liefersystem liefert die Bücher auf Anfrage. Das zeigt, wie sinnvoll die Trennung der Metadaten von den Daten ist. (Es zeigt auch, dass Informatiker eine Menge von Bibliothekaren lernen können, doch das ist eine andere Geschichte.)

Indem wir die Metadaten separat behandeln, können wir einen globalen Namensraum erstellen, der die Grenzen zwischen den Geräten auflöst. Wir können die Dateimetadaten gemäß den Anwendungs- oder Verwaltungsanforderungen ändern. Die Dateidaten können dabei nach einem anderen Plan mit ganz anderen Anforderungen bewegt werden. Wir können die Metadaten teilen, um die standortübergreifende Zusammenarbeit in einem universellen Namensraum zu ermöglichen. Wir können die Metadaten mit spezifischen Tags und Werten versehen und damit die Nützlichkeit (und den Wert!) der damit verbundenen Dateidaten erhöhen.

Die Trennung der Dateimetadaten von den Dateidaten nutzt auch der Performance. Die Parallel-NFS-Standards definieren den Vertrag zwischen Clients und Servern, sodass diese von den durch die Trennung der Zuständigkeiten entstehenden Leistungssteigerungen profitieren können.

Die Dateivirtualisierung verspricht, ebenso relevant und interessant zu werden, wie es die Blockspeichervirtualisierung seit 20 Jahren schon ist.

Was das für uns bedeutet

Mit der Zugriffsmethode erhalten Sie ein Virtualisierungsmodell, das Ihnen einen Ort liefert, an dem Sie Software und Rechenkapazität hinzufügen können – und damit die Grundlage und die Leistungsfähigkeit für fantasievolle Lösungen für Daten- und Speicherprobleme erhalten.

Virtualisierungssysteme kosten zwar etwas, doch sind sie ihren Preis meist mehr als wert. Wir können mit Sicherheit behaupten, dass sich Virtualisierung in vielen Fällen bezahlt macht. Wir können auch noch einen Schritt weitergehen und behaupten, dass Virtualisierung eigentlich immer vorteilhaft ist.

Und ganz ehrlich: Wir können sogar behaupten, dass die Vorteile der Virtualisierung nicht von der Hand zu weisen sind und für sich selbst sprechen. Um auf unser Sprichwort zurückzukommen: Wenn Sie Hardware sehen, lohnt es sich, ein paar Eier aufzuschlagen. Das Omelett ist Ihnen sicher.

Daten sind einerseits das Herzstück moderner HPC-Systeme, stellen andererseits aber auch einen der größten Engpässe dar. Je umfangreicher die Systeme, je komplexer die Arbeitsabläufe und je gewaltiger die Datenmengen werden, umso unverzichtbarer sind hoher Durchsatz, geringe Latenz und eine intelligent orchestrierte Dateninfrastruktur.

Hier gehen wir auf die wichtigsten Herausforderungen für HPC-Performance ein und erläutern, wie Sie sie mit einer optimal konfigurierten Infrastruktur meistern können.

#1 Beeinträchtigung der Rechenkapazität durch langsame Datenfeeds

HPC-Systeme basieren heute in der Regel auf hoher Rechenkapazität – allen voran GPUs, die in der Lage sind, gewaltige Datenmengen parallel zu verarbeiten. Diese Systeme sind allerdings nur so leistungsstark wie die Pipelines, die sie füttern.

In vielen Umgebungen kann der Speicher nicht mehr mit den Anforderungen mithalten. Beschränkte Bandbreite, hohe Latenz oder begrenzte I/O-Pfade führen dazu, dass die GPUs „Däumchen drehend“ darauf warten, dass die Daten endlich eintreffen. Dies beeinträchtigt vor allem Arbeitsabläufe, die mit KI oder Simulationen arbeiten und bei denen Prozesse kontinuierlich und iterativ große Datensätze verarbeiten müssen.

Das Ergebnis: Verschwendete Rechenkapazität, längere Zeit bis zu den Ergebnissen und eine geringere Rendite der kostspieligen Hardware-Investitionen. Um diese Situation zu verbessern, ist eine optimierte Speicherebene erforderlich, die einen hohen Durchsatz bei geringer Latenz gewährleistet – vor allem bei gleichzeitigem Zugriff.

#2 Schlechte I/O-Skalierung bei gleichzeitigem Zugriff

Ein maßgebliches Merkmal von HPC-Arbeitslasten ist ihre Skalierung. Routinejobs können Hunderte oder Tausende von Rechenknoten beinhalten, die alle gleichzeitig Zugriff auf gemeinsam genutzte Daten benötigen. Ohne ein Speichersystem, das auf parallele Verarbeitung ausgelegt ist, ist der „Streit“ in diesen Umgebungen vorprogrammiert.

Herkömmliche Enterprise-Dateisysteme gehen häufig unter dem massiven Druck paralleler I/O in die Knie. Je höher die Zahl der Clients, umso langsamer wird die I/O-Performance. Jobs brauchen länger, SLA-Vorgaben können nicht eingehalten werden und Rechenkapazitäten werden nicht ausreichend genutzt. Die Auswirkungen sind vor allem bei dicht gekoppelten MPI-Anwendungen und verteiltem Deep Learning spürbar, wo I/O-Engpässe die Koordination zwischen den Prozessen erheblich beeinträchtigen können.

Die Lösung sind Speichersysteme, die die I/O-Performance linear an die Client Load anpassen und vorhersehbaren, anhaltenden Durchsatz ungeachtet der Clustergröße garantieren.

#3 Speichersilos bei Projekten und Standorten

In vielen HPC-Organisationen landen die Daten letztendlich fragmentiert in unterschiedlichen Speichersystemen: in temporären Speichern, Hauptverzeichnissen, NAS-Shares einzelner Abteilungen, veralteten Archiven oder sogar geografisch verteilten Speichern. Häufig wird jeder einzelne dieser Speicher separat verwaltet und erfordert eine eigene Authentifizierung, Zugriffskontrolle und Schnittstelle.

Diese Fragmentierung führt zu doppelter Datenführung, Inkonsistenz und Durcheinander. Sie behindert außerdem gemeinsame Forschungen, da relevante Datensätze nur schwer zu finden oder zu teilen sind und Entwickler Zeit damit verschwenden müssen, anwendungsspezifische Zugriffslogiken zu schreiben. Im schlimmsten Fall „verschwinden“ wertvolle Daten einfach im System. Auch wenn sie noch vorhanden sind, sind sie praktisch unerreichbar.

Eine einheitliche Speicherumgebung, idealerweise mit einem globalen Namensraum und zentralisiertem Datenkatalog, beseitigt diese Hindernisse. Eine solche Umgebung ermöglicht die Wiederverwendung von Daten, verringert den Verwaltungsaufwand und verbessert die Effizienz der Forschungen und der gleichzeitig stattfindenden Arbeitsabläufe.

#4 Manuelle und starre Datenabläufe

HPC-Workflows basieren häufig auf Tools, Shell-Skripten und Batch-Jobs, die über viele Jahre hinweg in Eigenarbeit entwickelt wurden. Auch wenn sie funktionieren, sind diese Methoden anfällig, schwer skalierbar und stark vom Wissen der Beteiligten abhängig.

Ein Beispiel: Datensätze werden manuell in Zwischenspeicher kopiert und nach der Verarbeitung manuell zurückbefördert (oder archiviert). Dieser Ansatz ist mit menschlichen Fehlern, Verzögerungen und Ineffizienzen verbunden – insbesondere, wenn Jobs fehlschlagen, neu starten müssen oder die Datenplatzierung dynamisch angepasst werden muss.

Moderne HPC-Umgebung benötigen Orchestrierungsplattformen mit intelligenter Automatisierung der Datenverschiebung. Idealerweise sollten die Daten nahtlos und transparent zwischen Erfassung, Verarbeitung und Archivierung transportiert werden. Die Steuerung übernehmen in diesem Fall Job-Scheduler oder Zugriffsrichtlinien – keine Ad-hoc-Skripte.

#5 Ineffiziente Nutzung von Tier-0

Hochperformante NVMe-Speicherebenen sind für die Rechenkapazität unverzichtbar, gleichzeitig aber auch teuer und nur begrenzt verfügbar. Trotzdem wird der Tier-0-Speicher in vielen Umgebungen mit alten oder inaktiven Daten belastet, einfach weil es keinen automatisierten Mechanismus gibt, der diese Daten in einen besser geeigneten Speicher befördert.

Konsequenzen sind entweder die unnötige Erweiterung des teuren Speichers oder die manuelle Verwaltung der Lebenszyklen der Daten durch die Nutzer selbst. Beides ist nicht wünschenswert.

Tier-0 sollte der Speicherung aktiver Daten mit hoher Priorität vorbehalten sein. Alles andere – kalte Daten, abgeschlossene Jobs, temporäre Dateien – sollte automatisch in preiswerteren Speicher mit geringerer Performance (z. B. HDD oder Objektspeicher) verschoben werden. Der Trick? Diesen Vorgang transparent zu machen, ohne Zugriffspfade zu unterbrechen oder Konflikte zu verursachen.

#6 Fehlen eines einheitlichen, Ebenen übergreifenden Namensraums

Wenn Daten sich zwischen temporärem Speicher, Archiv und Cloud bewegen, ändern sich häufig die Pfade, Protokolle oder Zugriffsmethoden. Nutzer müssen dann wissen, wo die Daten gespeichert werden und wie sie sie abrufen können. Das macht jeden Arbeitsablauf unnötig kompliziert.

Fehlt ein einheitlicher Namensraum, beeinträchtigt dies auch die Automatisierung und die Skripterstellung. Jeder Wechsel der Speicherebene ist möglicherweise mit einem Wechsel der Job-Skripte oder Datenpfade verbunden. Das verlangsamt die Arbeitsabläufe und erhöht die Anfälligkeit.

Ein einziger globaler Namensraum über alle Ebenen hinweg sorgt dafür, dass Daten frei bewegt werden können und dabei kontinuierlich abrufbar sind. Dies vereinfacht die Entwicklung von Anwendungen, verringert die Verwirrung der Nutzer und ermöglicht eine nahtlose Datenorchestrierung im Hintergrund.

#7 Unerreichbarkeit der archivierten Daten

Die Datenarchivierung ist beim HPC von maßgeblicher Bedeutung, sowohl zwecks Kostenkontrolle als auch wegen der langfristigen Aufbewahrung der Daten. Traditionelle Archivsysteme werden jedoch häufig zu Datenfriedhöfen: Sie sind kalt, langsam und schwer zu durchsuchen. Darüber hinaus sind die Daten schwer abrufbar.

Das Problem liegt nicht nur in der Geschwindigkeit, sondern auch in der Integration. Archivierte Daten werden in der Regel aus dem Hauptnamensraum entfernt und separat gespeichert. Ihre Wiederverwendung erfordert spezielle Werkzeuge, IT-Interventionen oder Datenduplizierungen. Bei Arbeitsabläufen im Zusammenhang mit KI und Forschung stellt dies eine erhebliche Einschränkung dar. Frühere Trainingsläufe, Simulationsergebnisse und Referenzdaten müssen schnell abrufbar sei, insbesondere bei der Optimierung von Modellen oder der Wiederholung von Experimenten.

Moderne Ansätze behandeln das Archiv als dynamische Erweiterung der aktiven Datenumgebung. Die Daten sind bei Bedarf sofort abrufbar und für den Nutzer oder die Anwendung vollständig transparent.

#8 Beschränkung der Flexibilität und Kooperationsfähigkeit durch Datenbindung

Je mehr sich HPC-Umgebungen weiterentwickeln, umso mehr entwickeln sich auch die Datennutzungsmuster weiter, einschließlich institutionsübergreifender Zusammenarbeit, Hybrid-Cloud-Nutzung und KI-Workflows, die On-Premises und in der Cloud stattfinden. Häufig führen Speichersysteme jedoch dazu, dass Daten aufgrund proprietärer Formate, geschlossener Protokolle oder Cloud-spezifischer Tools isoliert sind.

Das schränkt die Fähigkeit zur Anpassung, Skalierung oder gemeinsamen Nutzung der Daten ein. Die Verschiebung der Daten zwischen den Plattformen wird kompliziert, teuer oder sogar unmöglich. Datenbindung hemmt nicht nur Innovationen, sie erhöht auch die langfristigen Gesamtbetriebskosten und das Risiko.

HPC-Plattformen sollten möglichst offene Standards, portable Datenformate und Cloud-neutrale Orchestrierung priorisieren. Die Daten sollten problemlos an den jeweils benötigten Ort verschoben werden können, ohne dass Code neu geschrieben werden muss, Metadaten verloren gehen oder drastische Ausstiegsgebühren anfallen.

So hilft DataCore Ihnen dabei, HPC-Datenengpässe zu verhindern

Um die datenbezogenen Herausforderungen zu bewältigen, die HPC-Performance beeinträchtigen können, benötigen Sie mehr als nur schnellere Hardware oder zusätzliche Fixes – Sie benötigen eine einheitliche Datenspeicherplattform, die mit der Rechenkapazität Schritt halten kann. DataCore Nexus liefert genau das.

Nexus kombiniert die bewährten Funktionen von Pixstor für hochperformante Dateidienste mit Ngenea für intelligente Datenorchestrierung und bietet eine komplette Dateninfrastruktur, die für anspruchsvolle HPC-Workflows optimiert wurde. Nexus stellt sicher, dass die Daten immer an dem Ort sind, an dem sie benötigt werden, mit dem Durchsatz der Gleichzeitigkeit und der Flexibilität, die für die vollständige Ausnutzung der Rechenkapazität erforderlich sind.

Nexus optimiert Vorgänge durch automatische Datenverschiebung zwischen den Ebenen und macht manuelles Staging, Scripting und Cleanups überflüssig. Nexus vereinfacht die Zusammenarbeit und die Wiederverwendung der Daten durch einen einheitlichen zentralen Namensraum, der Projekte, Teams und sogar geografisch verteilte Standorte umfasst. Nexus unterstützt offene Standards und den Einsatz an mehreren Standorten. Damit sind Sie unabhängig und können frei skalieren – ob On-Premises, in der Cloud oder beides.

Für Umgebungen, die große Mengen an historischen HPC-Daten aufbewahren müssen, ist DataCore Swarm die ideale Ergänzung zu Nexus. Swarm bietet kosteneffektiven, skalierbaren Archivspeicher, in dem ältere Daten jederzeit zum Wiederabruf, zur Auswertung oder zu Wiederverwendung zugänglich sind, ohne dass die aktiven Workflows verlangsamt werden.

Gemeinsam bilden DataCore Nexus und Swarm eine leistungsstarke integrierte Lösung für moderne HCP-Herausforderungen und gewährleisten die Performance, Flexibilität und Unkompliziertheit, die für schnelle Erkenntnisse und maximale Rendite der Infrastrukturinvestitionen nötig sind.

Wenden Sie sich an DataCore, um zu erfahren, wie Ihre HPC-Workflows mit Nexus schnell, skalierbar und effizient werden.