Im Oktober 2024 trat NIS-2 EU-weit in Kraft. Seit Januar 2025 gilt DORA für den Finanzsektor. Die Richtlinie zur Widerstandsfähigkeit kritischer Einrichtungen (CERD) erweiterte die Verpflichtungen um die physische und betriebliche Kontinuität. In Deutschland legt das KRITIS-Gesetz einige der strengsten Anforderungen an den Schutz kritischer Infrastrukturen in Europa fest. Es ging NIS-2 voraus und gilt parallel dazu für auf dem deutschen Markt tätige Organisationen. In den USA definiert CIRCIA neu, welche Nachweise Betreiber kritischer Infrastrukturen im Falle eines schwerwiegenden Cybervorfalls erbringen müssen. All diesen Rahmenwerken ist eine Gemeinsamkeit gemein, die leicht übersehen wird, wenn man nur die zusammenfassenden Schlagzeilen liest: Sie fragen nicht danach, ob Sie über Sicherheitstools verfügen. Sie fragen, ob Sie nachweisen können, dass Ihre Daten wiederherstellbar sind und nicht manipuliert wurden. Das ist eine Frage der Speicherung.

Warum die Speicherebene immer wieder übersehen wird

Diese Lücke ist nachvollziehbar. Compliance-Programme wurden um die Tools herum aufgebaut, die Protokolle erzeugten: Firewalls, Identitätsplattformen und Endpunkt-Agenten. Speichersysteme waren in der Vergangenheit keine primären Protokollquellen. Sie fielen nicht in den Anwendungsbereich von Penetrationstests. Sie waren kein Thema bei Tabletop-Übungen. Man ging davon aus: Wenn die übrigen Kontrollmaßnahmen greifen, ist auch der Speicher sicher.

Ransomware hat diese Annahme jedoch dauerhaft widerlegt. Das Angriffsmuster, das den Aufsichtsbehörden mittlerweile die meisten Sorgen bereitet, ist nicht das, bei dem Daten exfiltriert werden, sondern das, bei dem Daten verschlüsselt werden, 30, 60 oder 90 Tage gewartet wird und dann die Verschlüsselung ausgelöst wird. Bis der Verschlüsselungsauslöser zündet, enthält jedes Backup im Standard-Backup-Fenster eine Kopie der Infektion. Die Frage lautet daher nicht: „Haben Sie Backups?“, sondern: „Verfügen Sie über Wiederherstellungspunkte, von denen Sie nachweisen können, dass sie nicht manipuliert wurden?“ Das ist eine schwierigere Frage. Und die meisten Unternehmen stellen erst dann fest, dass sie diese Frage eindeutig beantworten können, wenn ein Prüfer danach fragt.

Was die Aufsichtsbehörden tatsächlich prüfen

Lässt man die rahmenspezifische Fachsprache und die technischen Anhänge einmal beiseite, so lässt sich die in NIS-2, DORA, CER und CIRCIA immer wieder auftauchende Compliance-Frage auf drei Punkte reduzieren:

Sind Sie in der Lage, den Betrieb wiederherzustellen? Nicht: „Haben Sie Backups?“ – sondern: Können Sie unter Testbedingungen eine definierte Wiederherstellungszeit und einen definierten Wiederherstellungspunkt für Ihre kritischen Systeme nachweisen? Ist diese Fähigkeit dokumentiert, getestet und belegt?

Sind Ihre Wiederherstellungsdaten sauber? Wenn ein Angreifer 60 Tage lang erweiterte Zugriffsrechte auf Ihre Umgebung hatte, wie können Sie sicher sein, dass die Wiederherstellungspunkte, auf die Sie sich verlassen, nicht verändert wurden? Wie sieht der Verifizierungsmechanismus aus? Wer kontrolliert ihn? Und was mindestens genauso wichtig ist: Könnte ein kompromittiertes Administratorkonto darauf zugegriffen haben?

Wer hat was wann getan? Wenn ein Vorfall eintritt und die Untersuchung beginnt, erwarten die Aufsichtsbehörden einen Prüfpfad, der jede Konfigurationsänderung, jedes Zugriffsereignis und jede Richtlinienänderung einer Identität und einem Zeitstempel zuordnet. Es reicht nicht aus, ein allgemeines Protokoll zu führen – erforderlich ist eine spezifische, lückenlose und manipulationssichere Aufzeichnung.

Diese drei Fragen betreffen direkt die Speicherinfrastruktur. Nicht den Perimeter. Nicht den Endpunkt. Sondern die Ebene, auf der die Daten tatsächlich gespeichert sind.

Die meisten Unternehmen haben noch keine ehrliche Bestandsaufnahme vorgenommen

Die Compliance-Lücke im Bereich der Datenspeicherung ist in der Regel keine technologische Lücke, sondern eine Lücke bei den Nachweisen. Die Technologie zur Lösung dieser Probleme ist vorhanden. Was den meisten Unternehmen fehlt, ist die richtige Herangehensweise: eine Kombination aus Kontrollmaßnahmen, die zusammenwirken, konsequent angewendet werden und dokumentierbare Nachweise liefern, statt nur mündliche Zusicherungen abzugeben.

Überlegen Sie einmal, was „Wir haben Backups“ bei genauer Betrachtung tatsächlich bedeutet. Es bedeutet lediglich, dass es geplante Backup-Aufträge gibt. Es bedeutet jedoch nicht, dass diese Backups von der Angriffsfläche isoliert sind. Es bedeutet auch nicht, dass die Daten nicht verändert wurden. Und es bedeutet auch nicht, dass die Wiederherstellung kürzlich getestet wurde. Und es bedeutet auch nicht, dass es einen kryptografischen Integritätsnachweis gibt, den man einem Prüfer vorlegen kann.

Die Lücke zwischen „Wir haben Backups“ und „Wir können eine manipulationssichere, überprüfbare Wiederherstellungsfähigkeit nachweisen“ beschreibt genau die Situation, in der sich die meisten Organisationen derzeit befinden. Für regulierte Unternehmen, die unter NIS-2, DORA oder CIRCIA operieren, kann diese Lücke über das Bestehen oder Nichtbestehen eines Audits entscheiden.

Wie sieht eine tatsächlich compliancekonforme Speicherumgebung aus?

Es lohnt sich, konkret zu werden – allerdings nicht in Bezug auf Produkte, sondern auf Ergebnisse. Eine Speicherumgebung, die die oben genannten Anforderungen erfüllt, weist einige erkennbare Merkmale auf.

Wiederherstellungspunkte wie Snapshots sind beispielsweise unveränderlich. Sie sind nicht durch Konventionen oder Richtlinien gesperrt, sondern auf der Infrastrukturebene mit kryptografischer Überprüfung, die gewährleistet, dass sich die Daten seit dem Schreiben nicht verändert haben. Die Integritätsprüfung erfordert kein Vertrauen in einen Administrator. Sie erfordert Vertrauen in einen Hash.

Der Schutz erfolgt kontinuierlich und nicht periodisch. Backup-Fenster schaffen Lücken. Bei einem um 23:50 Uhr beginnenden Ransomware-Angriff, der sich gegen einen um Mitternacht geplanten Backup-Zeitplan richtet, gibt es fast 24 Stunden lang ungeschützte Schreibvorgänge. Kontinuierlicher Datenschutz, also die Aufzeichnung jedes Schreibvorgangs in Echtzeit, schließt dieses Fenster. Im Falle eines Angriffs kann nicht auf den Stand des letzten Backups, sondern auf den Zeitpunkt unmittelbar davor zurückgesetzt werden.

Der Zugriff ist geregelt und nachverfolgbar. Jede administrative Aktion auf der Speicherebene wird einer Identität zugeordnet und mit einem Zeitstempel versehen. Der Prüfpfad ist kein nachträglicher Einfall, sondern ein zentraler Bestandteil des Speichersystems. Er wird automatisch erstellt und kann bei Bedarf abgefragt werden.

Resilienz wird gemessen, nicht einfach vorausgesetzt. Auf die Frage „Wie resilient ist Ihr Speichersystem?“ sollte nicht mit einer Beschreibung der Architektur geantwortet werden. Die Antwort sollte eine Zahl, eine Methodik und einen Zeitstempel enthalten. Unternehmen, die zu einem quantifizierten Resilienzansatz übergegangen sind, kennen ihren Wert, wissen, was ihn beeinflusst und inwiefern er mit ihren regulatorischen Verpflichtungen korreliert. Sie befinden sich in einer grundlegend anderen Compliance-Diskussion als Unternehmen, die sich nach wie vor auf Architekturdiagramme verlassen.

Das Fenster schließt sich

Die Durchsetzung von NIS-2 ist bereits im Gange. DORA ist im Januar 2025 in Kraft getreten. Die Aufsichtsbehörden warten nicht ab, bis sich die Organisationen mit den Rahmenwerken vertraut gemacht haben, bevor sie Fragen stellen.

Diejenigen, die der Prüfung am besten standhalten werden, sind nicht die Organisationen, die in den Wochen vor einer Bewertung hastig ein Compliance-Tool eingeführt haben. Es sind diejenigen, die die entsprechenden Voraussetzungen geschaffen haben: Unveränderlichkeit, Kontinuität, Zugriffssteuerung und Prüfpfad sind feste Bestandteile ihrer Infrastruktur und keine in letzter Minute angehängten Zusatzfunktionen.

Der Speicher war schon immer der Ort, an dem die Daten liegen. Nun sind dort auch die Nachweise für die Compliance zu finden. Die Frage ist, ob Ihre Speicherinfrastruktur bereit ist, diese Nachweise zu liefern.

DataCore SANsymphony wurde nicht nur für die Architektur, sondern auch für die Prüfung entwickelt

Die meisten Speicherplattformen wurden zu einer Zeit konzipiert, als Compliance im Zusammenhang mit Speicher noch kein Thema war. Die von den Aufsichtsbehörden heute geforderten Kontrollmechanismen wurden erst später nachgerüstet – sofern sie überhaupt vorhanden sind.

DataCore SANsymphony ist anders. Sie bietet unveränderliche, kryptografisch überprüfbare Wiederherstellungspunkte, eine kontinuierliche Datensicherung und eine Echtzeit-Bewertung der Cyber-Resilienz. Letztere liefert Prüfern eine quantifizierte, dokumentierbare Antwort auf die Frage nach der Resilienz – und nicht nur ein Architekturdiagramm.

Dies ist für Unternehmen, die unter NIS-2, DORA, CER oder CIRCIA operieren, von Bedeutung, da sie bei einer Überprüfung Compliance-Nachweise vorlegen müssen. SANsymphony trägt dazu bei, diese Nachweise in die Infrastruktur selbst zu integrieren und macht den Speicher so zu einer Quelle nachweisbarer Resilienz, statt ihn zu einem System zu machen, das Compliance-Teams im Nachhinein erklären müssen.

KOSTENLOSE TESTVERSION VON SANSYMPHONY HERUNTERLADEN

Seit Anfang 2024 hat die Dynamik hinter Red Hat OpenShift ein beispielloses Niveau erreicht. Laut aktuellen Daten von Red Hat ist die Kundenakzeptanz allein von OpenShift Virtualization seit Anfang 2024 um 178 gestiegen%. Produktionsbereitstellungen nehmen deutlich zu, da Unternehmen nach einer stabilen, skalierbaren Alternative zu älteren Hypervisoren suchen. Dieser Wandel wird durch den Bedarf an einer einheitlichen Basis vorangetrieben, die sowohl containerisierte Microservices als auch ältere virtuelle Maschinen verarbeiten kann. Wenn Sie diese Umgebungen jedoch skalieren, stellen Sie schnell fest, dass OpenShift zwar tausend Container in Sekundenschnelle orchestrieren kann, der zugrunde liegende OpenShift-Speicher jedoch oft Mühe hat, Schritt zu halten.

Die OpenShift-Speicherherausforderung: Die „zustandsbehaftete“ Spannung in einer zustandslosen Welt

In der Branche wird oft behauptet, das Container Storage Interface (CSI) sei die universelle Lösung für Kubernetes-Speicher. In der Praxis ist das CSI jedoch lediglich ein Übersetzer. Zwar ermöglicht es OpenShift die „Kommunikation“ mit einem externen Array, trägt aber nichts dazu bei, die grundlegende architektonische Diskrepanz zwischen verteilter Orchestrierung und zentralisiertem Speicher zu beheben.

Das Problem ist nicht nur die Konnektivität, sondern auch die Latenz und das deterministische Verhalten.

Wenn Sie hochleistungsfähige, zustandsbehaftete Workloads – wie PostgreSQL, Kafka oder KI-Trainingspipelines – auf OpenShift ausführen, stoßen Sie auf den sogenannten „I/O-Blender“-Effekt. Herkömmliche SANs sind für die vorhersehbare, träge Welt physischer Server ausgelegt. In einer dynamischen OpenShift-Umgebung sind Pods dagegen kurzlebig. Sie bewegen sich. Sie skalieren. Sie fallen aus und starten auf anderen Knoten neu.

Wenn Ihre OpenShift-Speicherschicht nicht Kubernetes-nativ ist, sehen Sie sich mit drei entscheidenden Problemen konfrontiert:

1. Latenz beim Einbinden: Das Warten darauf, dass ein älteres SAN bei der Migration eines Pods eine LUN einem neuen Knoten neu zuordnet, kann Minuten dauern. In einer Microservices-Architektur ist das eine Ewigkeit.
2. Leistungsschwankungen: Herkömmlichen Arrays fehlt oft die detaillierte Transparenz, um bestimmte Persistent Volume Claims (PVCs) zu priorisieren. Das kann zu „Noisy-Neighbor“-Problemen führen, die die Anwendungsleistung beeinträchtigen.
3. Komplexe Day-2-Operationen: Die Verwaltung des Speichers über eine separate Konsole außerhalb der OpenShift-oc-CLI oder der GitOps-Workflows unterbricht die Automatisierungskette.

Die Lösung: DataCore Puls8 als OpenShift Storage Fabric

DataCore Puls8 wurde entwickelt, um Reibungsverluste zwischen Orchestrator und Speicher zu beseitigen. Anstatt als externes Zusatzmodul zu fungieren, arbeitet Puls8 als verteilte Storage Fabric, die direkt im OpenShift-Cluster integriert ist. Dabei wird Speicher als vollwertiger Bestandteil des Kubernetes-Stacks behandelt.

Puls8 schließt diese „Lücke“, indem es die Datenebene in den Kernel-Bereich der Worker-Knoten verlagert. Dadurch wird sichergestellt, dass die Speicherleistung deterministisch ist. Wenn Sie ein Volume über eine StorageClass bereitstellen, reserviert Puls8 nicht nur Speicherplatz auf einem Array, sondern orchestriert auch einen Hochleistungspfad unter Verwendung von NVMe-over-Fabrics-(NVMe-oF)-Protokollen. So wird sichergestellt, dass die I/O-Latenz unabhängig von der Clustergröße im Sub-Millisekundenbereich bleibt.

Durch den Einsatz synchroner Replikation stellt Puls8 außerdem sicher, dass Daten über mehrere Verfügbarkeitszonen oder Knoten hinweg stets verfügbar sind. Dabei geht es nicht nur um ein „Backup“, sondern um ausfallsichere Kontinuität. Fällt ein Knoten aus, sind die Daten bereits auf einem anderen Knoten vorhanden. Somit kann der OpenShift-Scheduler den Pod sofort neu starten, ohne auf komplexe Speicher-Neuverknüpfungen warten zu müssen.

Der Leitfaden: Praktische Ausfallsicherheit in einem OpenShift-Cluster

Stellen Sie sich das folgende gängige Szenario vor: Sie betreiben einen geschäftskritischen MongoDB-Cluster auf OpenShift in einer Konfiguration mit drei Knoten.

In einer herkömmlichen Konfiguration verschiebt der OpenShift-Scheduler den MongoDB-Pod auf Knoten 2, wenn Knoten 1 ausfällt. Der CSI-Treiber muss dem externen Array dann signalisieren, das Volume von Knoten 1 zu entkoppeln und Knoten 2 zuzuordnen. Wenn der Befehl „unmap” hängt – was in älteren Fabric-Umgebungen häufig vorkommt –, wird das Volume gesperrt und Ihre Datenbank bleibt offline.

Mit DataCore Puls8 ist der Arbeitsablauf automatisiert und deterministisch:

• Bereitstellung: Sie definieren eine Puls8-StorageClass mit einem Replikationsfaktor von drei. Puls8 verteilt die Datenreplikate automatisch auf Ihre Worker-Knoten.
• Der Ausfall: Knoten 1 fällt unerwartet aus.
• Die Wiederherstellung: OpenShift erkennt den Ausfall und plant den Pod auf Knoten 2 ein. Da Puls8 bereits eine synchrone, bitgenaue Replik der Daten auf Knoten 2 gepflegt hat, ist das Volume sofort verfügbar.
• Das Ergebnis: Es ist kein manueller Eingriff erforderlich, es gibt keine „Stale Lock“ auf dem SAN und die Ausfallzeiten sind nicht länger. Die Anwendung nimmt den Betrieb innerhalb von Sekunden wieder auf.

Dieser Ansatz verwandelt die Speicherung von einer reaktiven Komponente in eine automatisierte Dienstleistung. Anstatt LUNs oder Masking zu verwalten, verwalten Sie Richtlinien über dieselben YAML-Manifeste, die Sie auch für Ihre Anwendungen verwenden.

Fazit: Technik für Sicherheit

Der Umstieg auf OpenShift ist eine strategische Entscheidung für eine moderne, automatisierte Infrastruktur. Diese Strategie ist jedoch nur so robust wie ihr schwächstes Glied. Wenn Sie eine Containerplattform der nächsten Generation mit veralteten Speicherarchitekturen betreiben, bringt das unnötige Risiken und betrieblichen Aufwand mit sich.

DataCore Puls8 schlägt eine Brücke zwischen der Agilität von Kubernetes und der Zuverlässigkeit, die Unternehmen benötigen. Es geht nicht nur darum, Ihren Containern „Kapazität” zur Verfügung zu stellen, sondern eine ausfallsichere, leistungsstarke Datenebene bereitzustellen, die sich linear an Ihre Ambitionen anpasst. Es geht darum, zu wissen, dass Ihre Daten sicher sind und Ihre Leistung garantiert ist, statt nur darauf zu hoffen.

Sind Sie bereit, Puls8 in Aktion zu erleben?

In diesem Video sehen Sie, wie DataCore Puls8 synchrone Replikation und automatisches Failover innerhalb eines Kubernetes-Clusters bereitstellt. So bleiben Ihre Daten auch bei Knotenausfällen zugänglich.

Um die Speicherherausforderungen von OpenShift zu lösen, ist ein Kubernetes-nativer Ansatz erforderlich, der konsistente Leistung, hohe Verfügbarkeit und vereinfachte Abläufe bietet.

KOSTENLOSE TESTVERSION VON PULS8 ANFORDERN

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