1,6 TB/s auf AWS sind NICHT DIE SCHLAGZEILE für das Cloud-native Qumulo

Das Cloud-native Qumulo hat auf AWS eine Geschwindigkeit von 1,6 TB/s erreicht – und das ist noch nicht einmal das Beste daran. Hier erfahren Sie, was das für Sie bedeutet.

Seit Jahren äußern Unternehmenskunden immer wieder dieselbe Sorge in Bezug auf die Cloud:

„Es ist einfach nicht schnell genug.“
„Selbst wenn es so wäre, könnten wir in einer Verfügbarkeitszone nicht zuverlässig genügend Rechenleistung bereitstellen.“

Ein Kunde brachte die Herausforderung auf den Punkt:

„Wir müssen in der Cloud einen dauerhaften Durchsatz von mehr als 1,5 TB/s erreichen, ohne dabei Abstriche bei der Zuverlässigkeit oder Flexibilität zu machen.“

Das große „B“ in TB ist entscheidend. Es handelt sich um Bytes, nicht um Bits. Ein Byte entspricht acht Bits, daher entsprechen 1,5 TB/s einer kontinuierlichen Datenübertragungsrate von etwa 12 Terabit pro Sekunde. Und „kontinuierlich“ ist dabei ebenso wichtig. Es handelt sich nicht um einen kurzzeitigen Durchsatzspitzenwert oder einen durch den Cache unterstützten Anstieg, sondern um einen über einen längeren Zeitraum aufrechterhaltenen Durchsatz.

Um diese Zahl in einen Zusammenhang zu setzen: Für das Streamen eines einzelnen 4K-Films sind in der Regel etwa 25 Megabit pro Sekunde erforderlich. Bei 12 Tb/s könnte dasselbe System theoretisch fast eine halbe Million gleichzeitige 4K-Streams.

Und für alle, die sich das fragen: Qumulo CNQ hat die Herausforderung gemeistert und 1,6 TB/s sowie 20,7 Millionen IOPS erreicht – aber dazu später mehr.

Tatsächlich waren die Leistungszahlen allein nie das eigentliche Problem. Nur wenige Unternehmen benötigen heute 1,5 TB/s, aber die Erfahrung lehrt uns, dass es selten gut ausgeht, wenn man sich bei der Planung ausschließlich auf den aktuellen Bedarf beschränkt. Der Aufbau von Hochleistungssystemen aus Cloud-Ressourcen ist oft eine Frage des Budgets, der Risikotoleranz und der Anfälligkeit des Systems. Tatsächlich ist die ausschließliche Ausrichtung auf Geschwindigkeit in vielen Unternehmen ein sicherer Weg, sich mit dem Finanzvorstand auf „Du“ zu stellen – allerdings nicht im positiven Sinne. Die Kombination von Geschwindigkeit mit einer instabilen Infrastrukturarchitektur mag zwar vorübergehend eine Herausforderung lösen, führt jedoch als Folgeerscheinung zu zahlreichen zusätzlichen technologischen und wirtschaftlichen Problemen.

Um das Grundproblem der architektonischen Flexibilität zu lösen, ist ein Umdenken erforderlich.

Die meisten Cloud-Speicherplattformen zwingen Kunden dazu, frühzeitig langfristige Infrastrukturentscheidungen zu treffen. Leistung, Verfügbarkeit und Kosten sind eng miteinander verknüpft, was eine Überdimensionierung für Spitzenauslastungen, doppelte Daten zur Gewährleistung der Ausfallsicherheit oder die Bindung von Workloads an bestimmte Standorte erforderlich macht. Sind diese Entscheidungen einmal getroffen, lassen sie sich nur schwer und kostspielig rückgängig machen.

Infolgedessen wird der Speicher zu einem Engpass, den die Rechen-Teams bei ihrer Planung berücksichtigen müssen, anstatt eine flexible Grundlage zu sein, die sich an wechselnde Arbeitslasten anpasst.

Die bessere Frage, die sich Kunden stellen sollten, lautet nicht: „Wie schnell kann das Ding fahren?“

Die Frage lautet: Kann die Cloud bei Bedarf eine unglaublich hohe Leistung liefern, ohne mich an instabile Architekturen, doppelten Speicher oder eine dauerhaft überdimensionierte Infrastruktur zu binden?

Qumulo hat diese Herausforderung ernst genommen. Nicht, indem es einer reinen Zahl hinterherjagte, sondern indem es ein anderes Betriebsmodell unter Beweis stellte. Und genau deshalb sind 1,6 TB/s NICHT DIE SCHLAGZEILE. Sie fragen sich vielleicht: „Qumulo, wenn die Skalierung auf 1,6 TB/s auf AWS, „Das ist doch nicht die Schlagzeile – was dann?“

Was wäre, wenn es bei der eigentlichen Schlagzeile gar nicht um Geschwindigkeit ginge, sondern darum, zonale Einschränkungen zu beseitigen, ohne dafür einen wirtschaftlichen Preis zahlen zu müssen?

Die Antwort beginnt mit einer Cloud-nativen Architektur – und nicht mit einer nachgerüsteten.

1import os
2import sys
3from datetime import datetime
4import libnfs
5
6os.environ['LD_LIBRARY_PATH'] = "/var/task/lib:/var/task/libnfs:" + os.environ.get('LD_LIBRARY_PATH', '')
7sys.path.append('/var/task')
8
9def handler(event, context):
10    try:
11        nfs = libnfs.NFS("nfs://YOUR_CNQ_ADDRESS/YOUR_NFS_EXPORT")
12    except Exception as e:
13        return {"statusCode": 500, "body": "Error connecting to NFS export: " + str(e)}
14    
15    try:
16        timestamp = datetime.now().isoformat()
17        message = f"Hello from AWS Lambda via CNQ! - {timestamp}\n"
18        
19        f = nfs.open("/testing-from-lambda.txt", "w+")
20        f.write(message)
21        f.close()
22    except Exception as e:
23        return {"statusCode": 500, "body": "Error writing to file: " + str(e)}
24    
25    try:
26        f = nfs.open("/testing-from-lambda.txt", "r")
27        content = f.read()
28        return {"statusCode": 200, "body": content}
29    except Exception as e:
30        return {"statusCode": 500, "body": "Error reading file: " + str(e)}
31
32Built for the Cloud from the Beginning

Die Architektur von Qumulo wurde für die Cloud konzipiert und nicht erst an sie angepasst. Dieser Unterschied ist entscheidend.

Die meisten Cloud-Dateispeichersysteme sind nicht aufgrund mangelhafter Umsetzung gescheitert. Sie sind gescheitert, weil sie Annahmen aus einer von Hardware geprägten Ära übernommen hatten und nie vollständig für den Cloud-basierten Betrieb umgestaltet wurden.

Herkömmliche Dateisysteme basierten auf einer einfachen physikalischen Tatsache: Die Speicherhardware bestimmte sowohl die Kapazität als auch die Leistung. Mehr Festplatten bedeuteten mehr Speicherplatz, und mehr Speicherplatz bedeutete mehr Durchsatz. Kapazität und Leistung waren physikalisch miteinander verknüpft. Man konnte das eine nicht sinnvoll skalieren, ohne das andere mitzubeziehen. Dieses Modell war absolut sinnvoll, als Unternehmen noch rotierende Festplatten kauften, Server in Racks aufstellten und ihre eigenen Netzwerke verkabelten.

Als Cloud-Anbieter Managed-File-Services einführten, wurden viele dieser Annahmen einfach übernommen.

Einige Dienste skalieren ihre Kapazität automatisch, doch die Leistung hängt weiterhin von der Menge der gespeicherten Daten ab. Bei anderen müssen Kunden Kapazität und Durchsatz gemeinsam als feste Attribute bereitstellen. Eine gewisse Elastizität ist zwar gegeben, wird jedoch durch dieselbe Kopplung eingeschränkt, die auch bei lokalen Lösungen bestand.

Da Leistung und Kapazität weiterhin miteinander verknüpft sind, bleiben den Kunden zwei unattraktive Optionen:

• Vorkehrungen für Spitzenzeiten: Sie zahlen für maximale Leistung und Kapazität zu jeder Zeit, auch bei geringer Auslastung

• Durchschnittsrückstellung: Geld sparen, bis die Arbeitslasten an ihre Grenzen stoßen und die Leistung zum Engpass wird

Die meisten Teams entscheiden sich für die erste Option, da die Kosten durch gedrosselte Workloads oder versäumte Fristen die Kosten einer Überdimensionierung bei weitem übersteigen; allerdings zahlt man für das, was man könnte Bedarf ist das Gegenteil von Cloud-Ökonomie.

Das Problem verschärft sich noch, wenn die Vielfalt der Protokolle ins Spiel kommt. Linux-Umgebungen setzen NFS voraus. Windows-Umgebungen erfordern SMB. Moderne Anwendungen stützen sich zunehmend auf den Objektzugriff über S3-kompatible APIs.

Die Folge ist eine Fragmentierung. Unterschiedliche Dienste, unterschiedliche Skalierungsmodelle, unterschiedliche Betriebsabläufe. Teams, die gemischte Workloads ausführen, verwalten oft mehrere Speichersysteme, von denen jedes für einen engen Anwendungsfall optimiert ist.

Mit der Zeit wird der Speicher zum limitierenden Faktor, den die Rechen-Teams bei ihrer Planung berücksichtigen müssen.

„Wie viel Speicherplatz haben wir?“, fragen sie. „Was können wir darauf ausführen?“

Das ist verkehrt herum. Die Infrastruktur sollte sich an die Arbeitslasten anpassen, nicht umgekehrt.

Das Cloud-native Qumulo löst diese Kopplung auf.

Von Anfang an hat CNQ Leistung und Kapazität konzeptionell voneinander getrennt. Die Rechenleistung lässt sich unabhängig vom dauerhaften Objektspeicher skalieren, wobei die Leistung durch Anpassung der Rechenressourcen erhöht oder verringert wird, anstatt Kapazitäten im Voraus zuzuweisen. Kunden zahlen nur für den tatsächlich genutzten Speicherplatz, während die Leistung ein elastisches Merkmal und keine feste Verpflichtung darstellt.

Dadurch kann CNQ universelle Dateidienste für Unternehmen kostengünstig bereitstellen und gleichzeitig auf spezialisierte, rechenintensive Workloads skalieren, ohne dass Kunden zu einer dauerhaften Überdimensionierung oder zu fragmentierten Speichersilos gezwungen sind.

Damit ist die Schlagzeile klar: CNQ: Für die Cloud konzipiert, nicht nur an sie angepasst. Trotzdem habe ich das Gefühl, dass etwas fehlt.

Die Herausforderung: Schneller als bei einer lokalen Lösung – ohne Sicherheitsnetz

Die Kundenanforderung war nicht rein theoretischer Natur.

Vor Ort lief die Arbeitslast in einem einzigen Rechenzentrum, wobei die Rechenressourcen in unmittelbarer Nähe zum Speicher untergebracht waren, um die Latenz zu minimieren. Bei einem Ausfall der Infrastruktur – sei es der Stromversorgung, der Kühlung oder des Netzwerks – kam die Arbeitslast zum Stillstand. Es gab zwar eine Notfallwiederherstellung, doch wie die meisten DR-Systeme war diese asynchron, nur in geringem Umfang getestet und nicht in der Lage, die volle Leistung der Arbeitslast aufrechtzuerhalten.

Das System funktionierte zwar, war aber anfällig.

Bislang ging es bei der Umstellung auf die Cloud nie um Geschwindigkeit. Es ging vielmehr darum, einzelne Ausfallquellen zu beseitigen, ohne dabei neue Einschränkungen einzuführen. Aber wenn dies schnell möglich wäre, wie würde sich das auf die Geschäfte unserer Kunden auswirken?

Im Bereich Cloud waren die Erwartungen klar:

• Die Leistung der lokalen Lösung übertreffen

• Vermeiden Sie die Abhängigkeit von einer einzigen Verfügbarkeitszone

• Auch bei Ausfällen volle Leistungsfähigkeit gewährleisten

• Mach es, ohne die Speicherkosten zu verdoppeln

Gerade bei dieser letzten Anforderung scheitern viele Cloud-Dateisysteme.

Die meisten Multi-Availability-Zone-Angebote nutzen Replikation. In jeder Zone werden vollständige Kopien der Daten vorgehalten, um die Verfügbarkeit zu gewährleisten. Dieser Ansatz ist zwar im Hinblick auf die Datensicherheit wirksam, hat jedoch konkrete Konsequenzen. Die Speicherkosten steigen linear mit der Anzahl der Zonen. Die Schreibleistung wird aufgrund der zonübergreifenden Koordination beeinträchtigt. Multi-AZ wird daher von Kunden eher für Ausfallszenarien als für den Normalbetrieb genutzt.

Gleichzeitig ist die Rechenkapazität in der Cloud nicht gleichmäßig verteilt.

GPU- und CPU-intensive Workloads sind häufig mit Kapazitätsengpässen konfrontiert, die je nach Zone und im Zeitverlauf variieren. Ein Design, bei dem Daten an eine einzige Zone gebunden sind, zwingt die Rechenressourcen dazu, dieser Zone zu folgen – selbst wenn anderswo in der Region Kapazitäten verfügbar sind. Kunden sehen sich dadurch gezwungen, nach Instanzen zu suchen, Rechenkapazitäten zu reservieren, bevor die Daten bereitstehen (was kostspielig ist), oder die Arbeit gänzlich zu verzögern (was die Zeit bis zum Vorliegen der Ergebnisse verlängert).

Der Kunde stellte Qumulo vor die Herausforderung, Geschwindigkeit, Zuverlässigkeit und Ausfallsicherheit zu gewährleisten. Die Lösung muss eine höhere Leistung bieten und gleichzeitig die Abhängigkeit auf Zonenebene beseitigen, Speicherduplizierungen vermeiden und es ermöglichen, Workloads dort auszuführen, wo zu einem bestimmten Zeitpunkt Rechenkapazität verfügbar ist.

Qumulo löst dieses Problem auf architektonischer Ebene, anstatt die Verfügbarkeit einfach auf veraltete Annahmen aufzubauen.

Die Architektur: Mehrere Verfügbarkeitszonen durch Konzeption, nicht durch Duplizierung

Im Mittelpunkt dieser Bereitstellung stand ein Multi-AZ-CNQ-Cluster, der gleichmäßig auf drei Verfügbarkeitszonen innerhalb einer einzigen AWS-Region verteilt war.

Eine Verfügbarkeitszone (Availability Zone, AZ) ist eine physisch getrennte Gruppe aus einem oder mehreren Rechenzentren innerhalb einer AWS-Region. Jede AZ ist so konzipiert, dass sie unabhängig arbeitet und über eine eigene Stromversorgung, Kühlung und Netzwerkinfrastruktur verfügt, während sie gleichzeitig über Verbindungen mit hoher Bandbreite und geringer Latenz mit anderen AZs in der Region verbunden ist. Diese Trennung gewährleistet, dass Anwendungen auch dann verfügbar bleiben, wenn an einem gesamten Rechenzentrumsstandort ein Ausfall auftritt.

Die Datenbeständigkeit wird von Amazon S3 auf regionaler Ebene gewährleistet, wo die Daten automatisch über mehrere Standorte hinweg geschützt werden. Aus diesem Grund bietet AWS eine Datenbeständigkeit von 11 Neunen (99,999999999 %), was weithin als Branchenmaßstab für den Datenschutz gilt.

Die Architektur von CNQ ist so konzipiert, dass sie sich über mehrere AWS-Verfügbarkeitszonen erstreckt, ohne dass in jeder Zone vollständige Replikate der Kundendaten erforderlich sind. Daraus ergibt sich:

• Die Speicherkosten sind identisch, unabhängig davon, ob CNQ in einer oder mehreren Verfügbarkeitszonen (AZ) ausgeführt wird.

• Die Schreibleistung wird durch die zonübergreifende Replikation nicht beeinträchtigt

• Der Multi-AZ-Betrieb ist der Normalzustand und kein Ausfallmodus.

Hinweis: In der Regel kosten Multi-AZ-Dienste doppelt so viel wie ihre Single-AZ-Implementierungen. Die Beibehaltung gleicher Kosten stellt einen erheblichen wirtschaftlichen Vorteil dar.

Sollte eine Verfügbarkeitszone ausfallen, läuft der Cluster in den verbleibenden Zonen ohne Datenverlust weiter, ohne dass ein Failover auf eine sekundäre Kopie erforderlich ist.

Dieses Konzept ist einfacher, schneller und wesentlich kostengünstiger als Multi-AZ-Ansätze auf Replikationsbasis.

Es wäre ein Leichtes, dies zur Schlagzeile zu machen: CNQ Architecture bietet Multi-AZ-Ausfallsicherheit ohne Datenduplizierung. Das ist nicht falsch. Aber wir können es noch besser machen.

Der Vorteil von CNQ mit mehreren Verfügbarkeitszonen für GPU-intensive Workloads

Multi-AZ wird in der Regel als Verfügbarkeitsfunktion diskutiert, was zwar in Ordnung ist, doch heutzutage gilt Verfügbarkeit als Grundvoraussetzung. Was tatsächlich zählt, ist, welche Möglichkeiten CNQ im Bereich der Rechenleistung eröffnet, nämlich die Beschaffung von GPUs und CPUs deutlich zu vereinfachen.

Die meisten Cloud-Dateisysteme, selbst solche, die als „Multi-AZ“ vermarktet werden, binden den Speicher an eine einzige Primärzone. Die Rechenleistung muss den Daten folgen. Sind in dieser Zone keine GPUs oder CPUs verfügbar, kommt die Arbeitslast zum Stillstand – selbst wenn an anderer Stelle in der Region ungenutzte Kapazitäten vorhanden sind.

Dies zwingt Teams dazu, nach GPUs und CPUs zu suchen. Zunächst suchen sie nach den knappen Recheninstanzen. Dann reservieren sie diese Rechenkapazität und bezahlen dafür, bevor sie genutzt werden kann. Als Nächstes stellt sich das Datenproblem. Große Datensätze müssen an den Ort kopiert oder übertragen werden, an dem die Rechenkapazität gefunden wurde. Erst wenn all diese Schritte abgeschlossen sind, kann die Arbeit fortgesetzt werden. CNQ beseitigt diese Einschränkung.

Mit CNQ können Rechenressourcen in mehreren Verfügbarkeitszonen gleichzeitig auf denselben Datensatz zugreifen. Kunden können Kapazitäten über verschiedene Zonen hinweg zu einem einzigen logischen Pool zusammenfassen, ohne Daten kopieren oder neu bereitstellen zu müssen.

Wenn am Montag in einer Zone und am Dienstag in einer anderen Zone GPUs verfügbar sind, müssen Kunden weder Daten verschieben noch die Infrastruktur neu aufbauen. Sie leiten die bestehende CNQ-Bereitstellung einfach dorthin um, wo Rechenkapazitäten verfügbar sind.

Aus Kundensicht bietet dies folgende Vorteile:

• Schnellerer Zugriff auf knappe GPUs und CPUs

• Keine Phasen zur Neuordnung oder Kopie der Daten

• Keine Replikationsverluste

• Keine Erhöhung der Lagerkosten

Die Arbeit kann sofort beginnen, da die Daten bereits in jeder Verfügbarkeitszone innerhalb von S3 vorhanden sind, das als persistente Speicherschicht dient. Im Gegensatz zu Amazon Elastic Block Store (EBS) oder instanzgebundenem Speicher erfordert diese Architektur kein Kopieren oder erneutes Einlesen von Daten in jede Zone, bevor die Rechenverarbeitung beginnen kann. Stattdessen greift das Dateisystem über NeuralCache lokal auf die Daten in jeder AZ zu. Dieser Ansatz macht wochenlange Vorbereitungsarbeiten für die Datenbereitstellung überflüssig und sorgt dafür, dass teure Rechenressourcen von Beginn an voll ausgelastet sind.

Vielleicht denken Sie jetzt wieder: Das muss doch sicher die Überschrift sein: CNQ und die Kunst, die Suche nach GPUs erträglich zu machen. Wir sind auf dem richtigen Weg. Mal sehen, ob wir das noch toppen können.

Skalieren Sie die Leistung so weit nach oben, wie Sie möchten, und skalieren Sie sie anschließend wieder zurück

Der Kunde wünschte sich einen dauerhaften Durchsatz von mehr als 1,5 TB/s in der Cloud, ohne dabei Abstriche bei der Zuverlässigkeit oder Flexibilität machen zu müssen. Qumulo richtete eine Testumgebung ein, die die Erwartungen schließlich übertraf und einen dauerhaften Gesamtdurchsatz von 1,6 TB/s sowie 20,7 Millionen IOPS erreichte. Zwar sind diese Zahlen beeindruckend (zukünftige Leser sollten bitte das Veröffentlichungsdatum beachten, um den Kontext zu verstehen), aber handelt es sich dabei um Spitzen- oder Durchschnittswerte? Und wenn Sie als Kunde diesen Artikel lesen und an 1,6 TB/s sowie 20,7 Millionen IOPS interessiert sind, machen Sie sich keine Sorgen – wir haben die Lösung für Sie! Lesen Sie weiter unten.

Viele Kunden legen Wert auf Flexibilität und benötigen die Möglichkeit, Ressourcen je nach Bedarf nach oben oder unten zu skalieren. Wie bereits erwähnt, stehen Kunden oft vor der Wahl, entweder zu hohen Kosten für Spitzenauslastungen vorzusorgen oder die Kapazitäten auf die durchschnittliche Auslastung auszurichten und dabei Leistungsengpässe zu riskieren. Dieser Zielkonflikt unterstreicht den Kernwert der Cloud: Flexibilität. Diese Konfiguration kann etwa 5.000 US-Dollar pro Stunde kosten, was sie bei Bedarf zwar wertvoll macht, einen kontinuierlichen Betrieb jedoch wirtschaftlich unrentabel. Die Möglichkeit, dieses Leistungsniveau nur bei Bedarf in Anspruch zu nehmen, macht einen cloudbasierten Ansatz im Vergleich zu einer lokalen Infrastruktur wirtschaftlich sinnvoll.

Mit CNQ können Kunden Spitzenleistung erzielen, ohne ständig für Spitzenkapazität bezahlen zu müssen. Das ist der Unterschied.

Bei vielen Cloud-Dateisystemen hängt die Leistung von der dauerhaft bereitgestellten Kapazität ab. Wenn Sie die Kapazität für Spitzenauslastungen dimensionieren, zahlen Sie ständig den Spitzenpreis, auch wenn die Auslastung nachlässt.

CNQ trennt diese Entscheidungen voneinander.

Kunden können die Leistung gezielt hochskalieren, um einen Termin, einen Schulungszeitraum oder einen Produktionsanstieg zu bewältigen, und sie anschließend wieder zurückskalieren, sobald die Spitzenlast vorbei ist. Sie binden sich nicht an eine Konfiguration mit maximaler Auslastung, nur um gelegentliche Spitzen abzudecken.

Diese Flexibilität gilt nicht nur für die Skalierung, sondern auch für die Auswahl der Instanzen. Bei dieser Bereitstellung wurden die Instanztypen aufgrund regionaler Kapazitätsengpässe noch während der Planungsphase angepasst. Der Cluster wuchs einfach auf 250 Knoten an, bewältigte rund 333.000 Verbindungen und nutzte dabei eine geringere Bandbreite pro Knoten, ohne dass eine Neugestaltung erforderlich war.

Später können Kunden mithilfe des rollierenden Austauschs zu neueren Instanzfamilien zu geringeren Kosten wechseln, ohne dass es zu Ausfallzeiten oder einer Datenmigration kommt.

Gemeinsam haben wir endlich die Überschrift gefunden: CNQ bietet Spitzenleistung ohne maximalen Einsatz. Stimmt’s? Aber wozu braucht man überhaupt so viel Spitzenleistung?

Die Momente, in denen Höchstleistungen gefragt sind

Nicht jede Arbeitslast erfordert einen extrem hohen Durchsatz, und genau das ist der springende Punkt.

Bei dieser Architektur geht es nicht darum, stets mit 1,6 TB/s zu arbeiten. Es geht darum, die Möglichkeit zu haben, in zeitkritischen Situationen so schnell zu arbeiten, ohne dafür in der übrigen Zeit finanzielle oder betriebliche Nachteile in Kauf nehmen zu müssen.

Was heute noch übertrieben erscheint, wird oft schon morgen zum Standard. Warum sollte also jemand diese Leistung benötigen?

Nehmen wir einmal an, ein Energieunternehmen muss entscheiden, ob es eine Bohrstelle im Wert von einer Milliarde Dollar pachten soll. Die Frage ist nicht, ob die Analyse ein paar Millionen mehr an Cloud-Kosten verursacht. Die Frage ist, wer zuerst die Antwort findet. Wer zuerst da ist, kann darüber entscheiden, wer sich die Anlage sichert und wer leer ausgeht.

Im Gesundheitswesen kann eine schnellere Genomanalyse den Unterschied zwischen anhaltender Ungewissheit und einer lebensrettenden Behandlungsentscheidung ausmachen.

In der Medien- und Unterhaltungsbranche kann die Geschwindigkeit darüber entscheiden, ob ein Projekt seinen Veröffentlichungstermin einhält oder ob sich Verzögerungen zu ungeplanten Kosten summieren, die die Gewinnmargen zunichte machen. Schnelleres Rendering, schnellere Analysen und schnellere Iterationen bedeuten, dass weniger Kreativteams untätig auf die Infrastruktur warten müssen.

Bei all diesen Beispielen liegt die Einschränkung nicht in der Menge der Daten, die gespeichert werden können. Es geht vielmehr um die Zeit bis zur Erkenntnis und die Zeit bis zur Entscheidung. Wenn die Infrastruktur schneller Antworten liefert, führen Unternehmen nicht nur ihre Workloads schneller aus, sondern erzielen auch schneller Ergebnisse. Sie verkürzen ganze Entscheidungszyklen und schöpfen mehr Wert aus ihrer teuersten und unersetzbarsten Ressource: der Arbeitszeit ihrer Experten.

Stellen Sie sich vor, was Ihr Unternehmen erreichen könnte, wenn sich die Leistung nach oben und unten skalieren lässt, Sie nicht mehr für ungenutzte Kapazitäten bezahlen müssen und stattdessen für Ergebnisse bezahlen.

Die Überschrift muss doch sicher lauten: Warten Sie nicht länger auf die Infrastruktur. CNQ liefert schneller Ergebnisse. Aber gibt das wirklich alles wieder?

Der kumulative Effekt

Mit einem dauerhaften Gesamtdurchsatz von 1,6 TB/s beim sequenziellen Lesen übertraf Qumulo das ursprüngliche Leistungsziel des Kunden im Vergleich zu lokalen Systemen um mehr als 50 Prozent. Um dieses Leistungsniveau zu erreichen, war eine cloudnative Architektur erforderlich, die vollständig auf der Standard-AWS-Infrastruktur aufbaut und sich über drei Verfügbarkeitszonen erstreckt.

Noch wichtiger ist, dass diese Arbeit zeigt, dass Spitzenleistung keine unzumutbaren Kompromisse erfordert.

Neben einem Durchsatz von 1,6 TB/s erreichte das System 20,7 Millionen IOPS bei einer Latenz von unter einer Millisekunde.

Der wahre Wert geht jedoch über die Zahlen hinaus. Die Architektur ermöglicht es Kunden, Rechenleistung über alle Verfügbarkeitszonen hinweg zu nutzen, anstatt auf eine einzige Zone beschränkt zu sein, was die Beschaffung von GPU- und CPU-Ressourcen in großem Maßstab erheblich vereinfacht. Zudem bestätigt dies die Ausfallsicherheit von CNQ auf AWS und bietet hervorragende Datenverfügbarkeit sowie eine Datendauerhaftigkeit von elf Neunen, ohne die Speicherkosten durch Duplizierung in die Höhe zu treiben. Kunden behalten die Flexibilität, Instanzfamilien zu wählen, die ihren Leistungsanforderungen und Budgets entsprechen, und zahlen nur für das, was sie tatsächlich nutzen.

Zusammengenommen entfalten diese Fähigkeiten eine kumulative Wirkung, die wir als Kumulativer Effekt.

Vielleicht ist es nicht nur eine Schlagzeile, die Ihre Aufmerksamkeit wecken sollte. Vielleicht sind es alle.

• Das Cloud-native Qumulo wurde auf AWS auf 1,6 TB/s skaliert

• CNQ: Für die Cloud konzipiert, nicht an sie angepasst

• CNQ Architecture bietet Multi-AZ-Ausfallsicherheit ohne Datenduplizierung

• CNQ und die Kunst, die Suche nach einer GPU erträglich zu machen

• CNQ bietet Spitzenleistung ohne großen Aufwand

• Warten Sie nicht länger auf die Infrastruktur. CNQ liefert schneller Ergebnisse

Genau diese Kombination macht die Geschichte aus.

Das Fazit

Diese Implementierung hat gezeigt, dass ein cloud-natives Dateisystem extreme Leistung ohne Kompromisse bieten kann:

• Multi-AZ von Grund auf, nicht durch Duplizierung

• Leistung, die sich nach oben und unten skalieren lässt

• Die Freiheit, Rechenkapazitäten dort zu nutzen, wo sie verfügbar sind, und nicht dort, wo die Daten gebunden sind

• Dies führt zu einer schnelleren Erzielung von Ergebnissen

Die Cloud muss nicht nur schnell genug sein. Mit der richtigen Architektur kann sie flexibler, ausfallsicherer und wirtschaftlicher sein, als es lokale Systeme jemals waren.