S3-basierter Speicher mit um 22 % geringeren Kosten als bei Objektspeicher, Standardfunktionen und -zugriff des Dateisystems sowie höchstmöglicher Leistung
Die Herausforderung: Migration dateibasierter Workloads in die Cloud
Sie befinden sich mitten in Ihrer Cloud-Migration. Sie haben eine Anwendung – vielleicht eine von Tausenden –, die noch auf einem herkömmlichen dateibasierten Speichersystem läuft. Nun stehen Sie vor einer wichtigen Entscheidung: Wie können Sie diese Anwendung in die Cloud migrieren, ohne dabei Abstriche bei der Leistung, der Zusammenarbeit oder Ihren Budgetzielen zu machen?
In der Vergangenheit gab es drei Möglichkeiten:
Option 1: Umstellung auf Objektspeicher
Auf den ersten Blick scheint dies der „Cloud-native“ Weg zu sein. S3-kompatibler Objektspeicher ist kostengünstig, einfach bereitzustellen und erfordert nur wenig Infrastruktur.
Die Realität ist jedoch weitaus komplexer.
Der Haken: Komplexität, Kosten und Bindung an einen Anbieter
Die Umgestaltung von Legacy-Anwendungen für den Objektspeicher umfasst:
Zeitaufwendig: Code so umzuschreiben, dass er die Objektsemantik in möglicherweise Zehntausenden von Apps unterstützt, ist kein Wochenendprojekt – es ist ein jahrzehntelanges Unterfangen.
Teuer: Sie sparen zwar bei der Infrastruktur, müssen aber erhebliche Kosten für Softwareentwicklung, Tests und die langfristige Wartung aufwenden.
Hohe Latenz, niedrige IOPS: Objektspeicher ist nicht für „kommunikationsintensive“ Workloads mit geringer Latenz ausgelegt, die Hunderttausende bis Millionen kleiner Lese- und Schreibvorgänge erfordern. Bei Workloads, die eigentlich für den Einsatz auf hochleistungsfähigen Dateisystemen ausgelegt sind, werden Sie Schwierigkeiten haben.
Operativ komplex: Bei Anwendungen, auf die Sie keinen Einfluss haben (z. B. Software von Drittanbietern oder veraltete Anbietersoftware), ist eine Umgestaltung möglicherweise nicht möglich. Dies zwingt Sie dazu, ein Datei-Gateway (nächstes Thema) zu verwenden oder benutzerdefinierte Workflows zu erstellen, die Daten aus dem Objektspeicher in ein lokales Dateisystem übertragen, nur um sie anschließend wieder zurückzuschreiben – was zusätzliche Kosten, Latenz und Synchronisationsrisiken mit sich bringt.
Anbieterabhängigkeit bei Cloud-Diensten: Wenn Sie Ihren Code für bestimmte Objekt-Speicher-APIs umgestalten, sind Sie eng an einen bestimmten Cloud-Anbieter gebunden.
Ja, es gibt auch positive Aspekte…
Geringe Infrastrukturkosten
Langlebige, strapazierfähige Aufbewahrungslösung
Einfach zu implementieren
… doch diese Vorteile wiegen die Herausforderungen bei den meisten dateibasierten Workloads nicht auf.
Option 2: „Lift-and-Shift“ über das Datei-Gateway
Ein weiterer gängiger Ansatz besteht darin, ein Datei-Gateway zu verwenden, um Ihre dateibasierte Anwendung ohne Codeänderungen mit dem Objektspeicher zu verbinden.
Der Haken: Schlechte Leistung und hohe API-Kosten
Maßstab: Gateways werden häufig als einzelne VMs oder Hosts implementiert, auf denen eine Protokollabstraktionsschicht läuft und die NFS- oder SMB-Dienste bereitstellen, die vor den APIs des Objektspeichers angesiedelt sind. Selbst mit einem lokalen Cache ist man durch die maximale Bandbreite und die maximale Rechenleistung begrenzt, die ein einzelner Host bereitstellen kann. Dies macht sie für groß angelegte Workloads wie HPC, KI-Training oder 3D-Rendering ungeeignet.
Einschränkungen bei einem einzigen Autor: Selbst wenn Sie mehrere Gateways betreiben würden, um Skalierungsbeschränkungen zu überwinden, können die meisten Datei-Gateways den Zugriff nicht sicher über verschiedene Standorte hinweg freigeben. Das schließt eine Zusammenarbeit in Echtzeit aus und birgt darüber hinaus das Risiko von Datenbeschädigungen im Objekt-Bucket, da mehrere Gateways aus ihren eigenen zwischengespeicherten Ansichten der Daten lesen und schreiben.
Overhead bei API-Aufrufen: Da Gateways Dateioperationen in S3-API-Aufrufe übersetzen, steigen Ihre Kosten sprunghaft an – insbesondere bei Anwendungen mit hohem Metadaten-Aufkommen oder vielen kleinen Dateien.
Anwendungskompatibilität: Viele Anwendungen wurden ursprünglich für den Betrieb auf lokalen Dateisystemen entwickelt und entworfen und wurden für den Einsatz in Unternehmen skaliert, indem sie auf einem NAS der Enterprise-Klasse ausgeführt wurden. Oftmals vertragen sie keine unvollständigen oder inkonsistenten SMB- oder NFS-Implementierungen, die nicht dem vom offiziellen Linux-NFS-Server oder Windows-Dateiserver vorgegebenen Standard entsprechen – was bei Gateways häufig vorkommt, die auf Open-Source-Protokollstacks zurückgreifen oder FUSE-Treiber verwenden.
Positives?
Schnell einsatzbereit
Erfordert keine Änderungen an der App
Dennoch lässt dieser Ansatz viel zu wünschen übrig – insbesondere bei großem Umfang oder in globalen Teams.
Option 3: Ein Cloud-Dateisystem verwenden
Cloud-basierte Dateisysteme wie Amazon FSx, EFS, Azure Files oder Azure NetApp Files versprechen, Dateisemantik in die Cloud zu bringen.
Der Haken: Hohe Kosten, begrenzter Umfang und isolierte Implementierungen
Teuer: Da es sich um Portierungen von lokalen Speicherservern in die Cloud handelt, benötigen sie rund um die Uhr bereitgestellten Blockspeicher (wie z. B. EBS), was im Vergleich zu Objektspeicher zu extrem hohen Kosten führt, insbesondere bei großem Umfang.
Begrenzte Größenordnung: Manche „Cloud-Dateispeicher“ bestehen tatsächlich lediglich aus Hardware von Drittanbietern, die in Cloud-Rechenzentren betrieben wird. Dies führt zu Kapazitätsproblemen, da die Lieferkette, die Bereitstellungslogik und die Provisionierung völlig unabhängig von den standardisierten Hardware- und Rack-Konfigurationen sind, die bei Objektspeichern und anderen nativen Diensten zum Einsatz kommen. Andere Dienste stoßen an ihre Grenzen, weil sie die Speicherbeschränkung einer einzelnen VM – die bei einigen hundert TB liegt – einfach nicht überschreiten können oder weil die Software-Stacks einfach nicht in der Lage sind, mehr Speicher zu unterstützen. Die Folge ist, dass Sie Ihre Daten auf mehrere Instanzen aufteilen müssen, was zu einer komplexeren Verwaltung führt.
Eingeschränkte Funktionen: Viele der Cloud-nativen Dateidienste von Erstanbietern sind selbst entwickelte Implementierungen und daher auf ein einziges Protokoll beschränkt; zudem fehlen ihnen die Funktionen auf Unternehmensniveau, die Sie von On-Premise-Systemen gewohnt sind (z. B. Snapshots, Kontingente, Audit-Protokollierung, Replikation, Zugriffskontrolle).
Unelastisch: Andererseits leiden viele der in der Cloud gehosteten Versionen bestehender On-Prem-Software-Stacks darunter, dass es sich um Portierungen von Software handelt, die für den Betrieb in einem weitgehend statischen Rechenzentrum auf weitgehend statischer Serverhardware konzipiert wurde. Die Software wurde nicht dafür konzipiert, dass Knoten nach Bedarf hinzugefügt oder entfernt werden. Sie war nicht darauf ausgelegt, einen praktisch unbegrenzten Pool an Objektspeicherkapazität zu adressieren, der nur spärlich belegt ist. Daher erfordern viele dieser Angebote bereits bei der Bereitstellung endgültige Entscheidungen, die keine Rückgängigmachung zulassen, und bieten keine Möglichkeit, die Leistung bei Bedarf zu erhöhen, bei Nichtbedarf zu reduzieren oder Speicher freizugeben (damit man nicht mehr dafür zahlen muss), wenn sich die Anforderungen ändern.
Positives?
Schnell einsetzbar
Eine Umgestaltung ist nicht erforderlich
Verwaltete Infrastruktur
Wenn Ihr Anwendungsfall jedoch Hochleistungsrechnen, globale Zusammenarbeit oder Datensätze im Multi-Petabyte-Bereich umfasst, reichen diese Lösungen oft nicht aus.
Die bessere Lösung für Cloud-Dateien
Was wäre, wenn Sie sich nicht zwischen Leistung, Kosten und Einfachheit entscheiden müssten?
Cloud Native Qumulo bietet eine wirklich moderne Dateispeicherplattform – nativ für die Cloud entwickelt und darauf ausgelegt, dateibasierte Workloads zu S3-Konditionen auszuführen, und das bei besserer Leistung und weniger Kompromissen.
Warum Cloud-Native Qumulo?
✅ Keine Umgestaltung erforderlich
Verlagern Sie Ihre bestehenden dateibasierten Workloads unverändert in die Cloud. Auch die Benutzererfahrung bleibt unverändert.
✅ Native S3-Integration
Profitieren Sie von der Langlebigkeit und Redundanz von S3 im Hintergrund, ohne Ihre Anwendung umgestalten zu müssen, damit sie „Objekt“ spricht.
✅ Echte Multiprotokoll-Unterstützung
Greifen Sie über NFS, SMB oder S3 auf dieselben Daten zu – ganz ohne Datensilos.
✅ Globale Zusammenarbeit mit CDF (Cloud Data Fabric)
Arbeiten Sie sofort regionen- und cloudübergreifend zusammen. Keine Replikation erforderlich. Es funktioniert einfach.
✅ Flexible Skalierbarkeit
Fangen Sie klein an und skalieren Sie auf 10 EB+. Die Leistung wächst mit der Kapazität – bis zu 1,6 TB/s Durchsatz und 20 Millionen IOPS.
✅ 80 % niedrigere Gesamtbetriebskosten (TCO)
Im Vergleich zu herkömmlichen Cloud-Dateisystemen senkt Qumulo die Gesamtkosten durch:
Intelligentes Caching (Senkung der S3-API-Kosten)
Komprimierung (Reduzierung der in S3 gespeicherten Daten)
Höhere Lagereffizienz
✅ Höhere Leistung als die S3-API allein
Selbst bei Verwendung der S3-API übertrifft Qumulo herkömmliche Objektspeicherlösungen.
Erfolg in der Praxis: Luft- und Raumfahrt im Petabyte-Maßstab
Aus diesem Grund hat sich ein weltweit tätiges Luft- und Raumfahrtunternehmen dafür entschieden, seine Multi-Petabyte-Workloads auf Qumulo zu migrieren, und konnte dabei erhebliche Vorteile erzielen:
✅ 22 % geringere Speicherkosten im Vergleich zu einer vollständig überarbeiteten App, die Standard S3 nutzt
✅ Weniger API-Aufrufe dank intelligentem Caching und Cloud Data Fabric (CDF)
✅ Geringerer Speicherbedarf dank integrierter Komprimierung
✅ Keine Neugestaltung/Umgestaltung von Legacy-Anwendungen erforderlich
Ihr nächster Schritt: Testen Sie Qumulo noch heute
Ganz gleich, ob Sie eine einzelne Anwendung oder Tausende von Anwendungen migrieren – Qumulo bietet Ihnen eine zukunftssichere Grundlage für die Ausführung Ihrer dateibasierten Workloads in der Cloud – zu geringeren Kosten, mit höherer Leistung und ohne Kompromisse.
📩 Sind Sie bereit, loszulegen?
Schreiben Sie uns eine E-Mail an aws@qumulo.com oder besuchen Sie uns auf der AWS Marketplace um Ihre Bereitstellung noch heute zu starten.