Wie CNQ „Multi-AZ“ aus der Versicherungsbranche in einen kostenneutralen Wettbewerbsvorteil verwandelt
Die Cloud verspricht elastische Rechenkapazitäten, die überall und in jeder Region genutzt werden können. GPU-Workloads haben dieses Versprechen jedoch stillschweigend gebrochen.
GPUs sind zwar in der Cloud vorhanden, aber stehen sie auch in derselben Region oder Zone zur Verfügung, in der sich Ihre Daten befinden? Sind die GPUs verfügbar, wenn Sie sie benötigen?
Die Nachfrage nach beschleunigter Rechenleistung übersteigt mittlerweile das lokale Angebot. In vielen Unternehmen übersteigt die Nachfrage nach GPUs die GPU-Kapazität in einer einzelnen Verfügbarkeitszone oder sogar in einer einzelnen Region, was zu kritischen Verzögerungen bei der Arbeit führt. Kapazitäten werden nur kurzzeitig verfügbar, verschieben sich unvorhersehbar und verschwinden ebenso schnell wieder.
Ungleichgewichte bei der Verfügbarkeit von GPUs schaffen eine neue betriebliche Realität. Die Teams planen keine GPU-Aufträge mehr ein. Sie suchen nach GPUs, wo und wann immer diese verfügbar werden. Da die Rechenkapazität nun dynamisch ist, wird die Datenlokalität zu einer Einschränkung. Die GPUs sind endlich da, doch die Daten befinden sich nie dort, wo sie sind.
Die meisten Unternehmen gehen dieses Problem auf eine von zwei kostspieligen Arten an.
Option 1: Reservieren und abwarten
GPUs im Wert von Millionen von Dollar stehen ungenutzt herum – nicht, weil die Aufgaben noch nicht bereitstehen, sondern weil sich die Daten nicht dort befinden, wo Rechenkapazität zur Verfügung steht. Teams sichern sich die knappen GPU-Kapazitäten unter enormen Kosten und warten dann Stunden oder Tage darauf, dass die Daten in die „richtige“ Verfügbarkeitszone kopiert werden. Die Rechenkapazität wird zuerst reserviert. Die Arbeit beginnt erst später. Während nichts läuft, läuft die Abrechnung weiterhin sekündlich weiter.
Option 2: Vorab kopieren und auf das Beste hoffen
Teams replizieren Daten im Voraus über mehrere Verfügbarkeitszonen, Regionen oder sogar Clouds hinweg. Die Daten müssen an jedem Standort übertragen, gespeichert und gepflegt werden, was zu einer Vervielfachung der Netzwerkgebühren, Speicherkosten und des Betriebsaufwands führt. Ein Großteil dieser Daten liegt ungenutzt herum und belastet das Budget, lange bevor eine GPU überhaupt nützliche Arbeit leistet.
Infolgedessen verbirgt sich hinter jedem großen GPU-Einsatz in der Cloud ein stiller Verlust. Ganz gleich, ob Unternehmen auf Daten oder auf Rechenleistung warten – das Ergebnis ist dasselbe: Das Unternehmen gibt Geld aus, noch bevor die Arbeit überhaupt beginnt.
Führungskräfte erkennen diesen Verlust selten in ihren Dashboards. Stattdessen zeigt er sich in Cloud-Rechnungen, verzögerten Projekten, verpassten Zeitfenstern und Teams, die langsamer vorankommen als die Konkurrenz.
Das ist kein Kapazitätsproblem. Es handelt sich um ein architektonisches Problem, für dessen Lösung Cloud Native Qumulo entwickelt wurde.
Die versteckten Kosten der GPU-Jagd
Theoretisch ist Cloud-Computing elastisch. In der Praxis ist die GPU-Kapazität jedoch über verschiedene Verfügbarkeitszonen verteilt und unterliegt ständigen Schwankungen. Heute steht in einer Zone Kapazität zur Verfügung, morgen in einer anderen.
Die meisten Architekturen von Speichersystemen können sich nicht an diese Bedingungen anpassen.
Herkömmliche Cloud-Dateisysteme binden aktive Daten nach wie vor an eine einzige Zone. Selbst wenn sie als „Multi-AZ“ bezeichnet werden, stützen sie sich auf einen primären Standort, an dem die Rechenprozesse ausgeführt werden müssen. Replikate befinden sich zwar an anderen Orten, doch die Leistung und damit auch die Ausführung bleiben an diesen Standort gebunden.
Das Ergebnis ist vorhersehbar:
Die Verfügbarkeit der GPUs stimmt nicht mit dem Standort der Daten in den jeweiligen Zonen überein
Die Daten müssen so kopiert werden, dass sie der Verfügbarkeit der GPUs in den einzelnen Zonen entsprechen.
Die GPUs laufen im Leerlauf, während Hunderte von Terabyte übertragen werden
Diese „GPU-Jagdsteuer“ ist mittlerweile ein struktureller Kostenfaktor bei der Nutzung von KI, ML und Simulationen in der Cloud.
Und mit zunehmendem Umfang wird es noch schlimmer.
Je teurer und knapper die Rechenleistung ist, desto verheerender wirkt sich jede Sekunde im Leerlauf aus. Wenn der Speicher bestimmt, wo die Arbeit ausgeführt werden kann, spielt die Verfügbarkeit in der gesamten Region keine Rolle mehr.
Der architektonische Fehler, den Multi-AZ beheben sollte
Multi-Availability Zone wurde entwickelt, um die Anforderungen an die Ausfallsicherheit zu erfüllen, und das tut es auch. Bei GPU-Workloads ist die Ausfallsicherheit jedoch nicht das Problem.
Der Zugriff ist.
Wenn Ihre Architektur es nicht ermöglicht, Rechenleistung dort an die Daten anzubinden, wo Kapazitäten verfügbar sind, verfügen Sie nicht über ein Multi-AZ-System. Sie verfügen über ein Single-AZ-System mit Backups.
Genau diesen Mangel sollte Cloud Native Qumulo beheben.
CNQ eliminiert Kosten für ungenutzte GPUs
Cloud Native Qumulo (CNQ) ist von Grund auf für mehrere Verfügbarkeitszonen ausgelegt, nicht durch Duplizierung.
Keine Primärzone.
Keine Datenbindung: Rechenleistung lässt sich sofort und überall mit den Daten verknüpfen.
Keine Vorbereitungsphase.
Mit CNQ können Recheninstanzen in mehreren Verfügbarkeitszonen gleichzeitig auf denselben Live-Datensatz zugreifen. Andere Plattformen beschränken den Zugriff auf eine primäre Verfügbarkeitszone.
Mit CNQ werden Daten nur einmal gespeichert und auf regionaler Ebene dauerhaft geschützt, während die Rechenleistung dort bereitgestellt wird, wo GPUs verfügbar sind.
Wenn sich die Kapazität verschiebt:
Nichts bewegt sich
Nichts baut wieder auf
Nichts wartet
Die Teams laufen einfach dort, wo derzeit GPUs vorhanden sind. Die Arbeit beginnt sofort. Keine Leerlaufzeiten.
Anstatt Petabytes vorsorglich im Voraus zu kopieren, streamt CNQ Daten bedarfsgerecht. Nur Daten, auf die tatsächlich zugegriffen wird, werden über das Netzwerk übertragen. Der Rest bleibt unberührt. GPUs greifen sofort auf die Daten zu, unabhängig von der Zone.
Die Suche nach GPUs ist nicht mehr nur eine logistische Aufgabe, sondern wird zu einer Frage der Terminplanung.
Kostenneutrales Multi-AZ ist der Durchbruch
Die meisten Multi-AZ-Speichersysteme verursachen im Gegenzug für ihre Ausfallsicherheit reale Kosten. Wenn Sie eine weitere Verfügbarkeitszone aktivieren, steigen die Speicherkosten, da die Daten vollständig repliziert und in dieser neuen Zone gespeichert werden. Dieser Vorgang wiederholt sich bei jeder neuen Verfügbarkeitszone. Daher wird Multi-AZ von Unternehmen eher widerwillig aktiviert und eher für Ausfallszenarien als für den täglichen Betrieb reserviert.
CNQ funktioniert anders. CNQ lagert Verfügbarkeit und Beständigkeit an Amazon S3 aus, das von Haus aus regionalen Schutz bietet. Dadurch existiert der Datensatz nur einmal auf regionaler Ebene und nicht einmal pro Verfügbarkeitszone. Sie zahlen nicht für mehrere vollständige Kopien derselben Daten, nur um den Zugriff über verschiedene Zonen hinweg zu ermöglichen. Die Speicherkosten bleiben praktisch unverändert, unabhängig davon, ob Sie eine oder mehrere Verfügbarkeitszonen nutzen.
Das ist kein Optimierungstrick. Es handelt sich um eine grundlegende architektonische Entscheidung.
Bei CNQ gibt es:
Keine Kostensteigerung bei mehreren Kopien von Daten, die in mehreren Verfügbarkeitszonen gespeichert sind
Keine Leistungseinbußen beim Zugriff über mehrere AZs
Keine Leerlaufkosten für Ausfallsicherheit
Der Transparenz halber sei darauf hingewiesen, dass bei CNQ geringfügige Netzwerkgebühren zwischen den Verfügbarkeitszonen anfallen können, wenn Daten aktiv geschrieben werden. Bei der überwiegenden Mehrheit der KI-, ML- und Analyse-Workloads sind die Zugriffsmuster jedoch überwiegend leseintensiv. In der Praxis bleibt dieser Mehraufwand minimal und tritt nur während der Ausführung der Workloads auf, nicht jedoch, während die Daten im Ruhezustand sind. Wie immer empfiehlt es sich, Ihre spezifische Arbeitslast gemeinsam mit einem Solutions Engineer zu prüfen.
Hinweis: Qumulo bietet kostenlose Sitzungen zur Architekturprüfung und Lösungsplanung an.
Wenn Teams CNQ einsetzen, um die GPU-Verfügbarkeit über verschiedene Verfügbarkeitszonen hinweg zu überwachen, erzielen sie automatisch Multi-AZ-Verfügbarkeit und -Beständigkeit für das Speichersystem. Was normalerweise als Absicherungsmaßnahme betrachtet wird, wird so zu einem integrierten Vorteil. Multi-AZ ist nicht länger ein zusätzlicher Kostenfaktor, der sich nur als Vorsichtsmaßnahme rechtfertigt. Es handelt sich um eine Kernfunktion, die es ermöglicht, Aufgaben überall dort auszuführen, wo GPUs verfügbar sind, ohne dass sich die Speicherkosten vervielfachen.
Warum dies die Wirtschaftlichkeit von GPUs verändert
Sobald Sie eine GPU bereitstellen, fallen für jede Sekunde des Betriebs Kosten an. Leerlaufsekunden führen zu Geldverschwendung. Jede Verzögerung summiert sich über Teams und Projekte hinweg.
Wenn GPUs knapp sind, stehen Teams vor einem ständigen Dilemma: Entweder fallen Rechenkosten an, während sie auf Daten warten, oder sie zahlen für Speicher- und Netzwerkkapazität, während sie auf Rechenleistung warten. Oft zahlen sie am Ende für beides. In jedem Fall zahlen Sie die „GPU-Hunting-Steuer“.
Durch die vollständige Abschaffung der Zonenverankerung beseitigt CNQ beide Kompromisse. Regionale GPU-Kapazität wird zu nutzbarer Kapazität. Kunden zahlen nicht mehr dafür, auf Daten zu warten oder ungenutzte Kopien davon zu pflegen. Sie zahlen nur, wenn die GPU tatsächlich Arbeit leistet.
Der entscheidende Vorteil liegt in der Flexibilität.
Mit CNQ:
Die Teams müssen nicht schon Wochen im Voraus vorhersagen, wo GPUs verfügbar sein werden.
Durch die Speicherung sind sie nicht mehr an frühzeitige Entscheidungen bezüglich der Instanz gebunden
Neue Instanzfamilien können ohne Migration und ohne Ausfallzeiten eingeführt werden
Wenn sich Kapazität, Preisgestaltung und Leistung ändern, passt sich die Infrastruktur automatisch an.
Nun wird das Versprechen von Ressourcen im Cloud-Maßstab Wirklichkeit. Elastive, standortunabhängige Rechenleistung, die sich in Echtzeit anpasst, unabhängig von Entscheidungen zur Infrastrukturplatzierung ist und überall dort ausgeführt werden kann, wo Kapazitäten verfügbar sind.
Von der defensiven Architektur zum Wettbewerbsvorteil
Man kann mit Fug und Recht behaupten, dass CNQ den Kauf einer GPU erleichtert.
Das wird den Einfluss jedoch unterschätzen.
Was CNQ tatsächlich beseitigt, ist die architektonische „Schwerkraft“. Der Speicher bestimmt nicht mehr, wo gearbeitet werden kann. Die Rechenleistung ist nicht mehr an die Platzierungsentscheidungen von gestern gebunden. Teams handeln, sobald sich eine Gelegenheit bietet – und nicht erst, wenn die Infrastruktur es zulässt.
An diesem Punkt geht es bei „Multi-Availability Zone“ nicht mehr darum, Ausfälle zu überstehen. Es geht darum, schneller als die Konkurrenz zu sein, sofort mit der Arbeit zu beginnen, sobald Kapazitäten verfügbar sind, und bisher ungenutzte GPU-Zeit in echte Ergebnisse umzuwandeln.
Das ist keine Versicherung.
Das ist ein Vorteil.