Lücken bei neocloud storage lassen die meisten Anbieter ohne Medaillen
neocloud storage ist zu einem sichtbaren Maßstab dafür geworden, ob GPU-orientierte Cloud-Infrastruktur für anspruchsvolle Kunden bereit ist. In ClusterMAX 3.0 vergab SemiAnalysis nur 19 der 77 eingehend getesteten neocloud-Anbieter eine Medallion rating. Die veröffentlichten Stufen reichen von Platinum, Gold, Silver und Bronze bis zu einem neuen Participation Ribbon und liefern potenziellen Kunden damit ein Ergebnis, das sie prüfen können, bevor sie mit einem Anbieter zusammenarbeiten. Mehrere Anbieter, die zuvor Silver- oder Gold-Bewertungen hatten, verloren diese in der aktuellen Runde.
Speicher ist eine Voraussetzung und kein optionaler Teil der Bewertung. Jeder Anbieter muss mindestens 10 TB Hochleistungs-Dateispeicher bereitstellen, bei dem Anwendungen über vertraute Dateien und Ordner mit Daten arbeiten, sowie 10 TB S3-kompatiblen object storage, der Daten über ein S3-artiges Interface als unabhängig adressierbare Objekte speichert. SemiAnalysis testet zunächst die Performance und prüft dann, ob sie 15 Minuten lang unter anhaltendem gemischtem Datenverkehr bestehen bleibt. Einige Anbieter verloren während des zweiten Tests fast 40 % ihrer Bandbreite, also ihrer Kapazität zur Datenübertragung.
Die Größe entschied nicht über das Ergebnis. SemiAnalysis meldete Speicherprobleme bei AWS und Azure, bezeichnete den Speicher des deutlich kleineren Anbieters TensorWave jedoch als außergewöhnlich. Der wichtigere Unterschied bestand darin, ob der Speicher einen klaren Zweck, eine festgelegte Plattform und einen verantwortlichen Eigentümer hatte. Ein Anbieter kann ihn als vorübergehenden scratch space behandeln, während Kunden Daten importieren, einen job ausführen und die Ergebnisse wieder entfernen. Er kann eine Konfiguration übernehmen, die niemand regelmäßig überprüft. Oder er kann einer Person oder einem Vertrag die dauerhafte Verantwortung zuweisen. Der erste Ansatz kann für die stundenweise GPU-Vermietung geeignet sein, weil später nur wenig migriert werden muss. Der zweite wird riskant, sobald Kunden beginnen, Daten auf der Plattform zu belassen, da dann während eines schnellen Wachstums Entscheidungen über Standort, Zugriff, Maschinenausfälle und Preise getroffen werden müssen.
SemiAnalysis identifizierte vier wiederkehrende Fehler: falsch konfiguriertes role-based access control (RBAC), das volumes entsprechend den einem Benutzer zugewiesenen Berechtigungen beschränken soll; Speicher, der fälschlicherweise in einem overlay network platziert wurde, sodass Kunden das zugrunde liegende physische Netzwerk erreichen konnten; backend storage, der ein gemeinsames Netzwerk ohne Isolation nutzte; und eine BlueField data processing unit (DPU), die im standardmäßigen host-trusted mode belassen wurde. Eine DPU ist ein kleiner, in eine Netzwerkkarte integrierter Computer, der Netzwerk-, Speicher- und Sicherheitsaufgaben übernimmt.
In NVIDIAs Referenzdesign setzt die DPU Regeln durch, die bei der Trennung von tenants helfen, also von Kunden, die dasselbe physische System gemeinsam nutzen. Die Werkseinstellung vertraut jedem mit root access, der höchsten Kontrollebene über einen Server. Das passt zu einem Modell, in dem dem Serveradministrator vertraut wird, doch Kunden einer GPU-Cloud erhalten häufig selbst root access. Ein solcher Kunde kann daher möglicherweise die DPU erreichen, die die Grenze zwischen Benutzern durchsetzt, und diese Grenze potenziell schwächen oder deaktivieren. SemiAnalysis fand mindestens einen host, bei dem dieser Zugriffsweg offen geblieben war. Der Bericht führte die Gefährdung darauf zurück, dass die ausgelieferte Standardeinstellung nie geändert worden war, und nicht auf eine bewusste Designentscheidung.
In den niedrigeren Bewertungsstufen wurden die Probleme grundlegender. Der einzige Kritikpunkt am Speicher von CoreWeave war das Fehlen von lokalem GPUDirect Storage per one-click, einem direkten Datenpfad, der GPUs effizient mit Daten versorgen soll; SemiAnalysis bezeichnete diese Kritik als kleinlich. In den mittleren Stufen ließ sich die default StorageClass von Azure, also die Kubernetes-Einstellung, die bestimmt, wie Anwendungen Speicher erhalten, nicht anbinden. Auch das Laden eines Modells aus Network File System (NFS) storage überschritt das Zeitlimit, weil dem Slurm cluster ein parallel filesystem fehlte, das viele Vorgänge gleichzeitig verarbeiten konnte.
Bei Bronze und darunter fehlte mitunter nutzbarer gemeinsamer Speicher. In einem cluster in Seattle stand kein shared filesystem für Tests zur Verfügung. Einem anderen fehlte eine RWX StorageClass, die mehreren Systemen das Lesen und Schreiben desselben Speichers erlaubt, sodass es keinen Ort gab, an dem `/shared` gemountet werden konnte. Bei einem dritten Anbieter war zwar Non-Volatile Memory Express (NVMe) hardware vorhanden, wurde Anwendungen jedoch nicht bereitgestellt, sodass persistent volume claims (PVCs), also Speicheranforderungen von Anwendungen, im Status „pending“ verblieben. In einem weiteren Fall erstellte und band die default StorageClass Speicher, ließ den application pod jedoch in `ContainerCreating` hängen. Auf denselben worker nodes erreichte ein Lustre parallel filesystem über 32 clients hinweg eine aggregierte Lesegeschwindigkeit von 91,7 GB/s. Die zugrunde liegende hardware war schnell, doch der default path ließ sie unbrauchbar erscheinen.
Die Schwächen beim Speicher gingen mit umfassenderen Fehlern bei der tenant isolation einher, auch bei Anbietern, die GB300 racks testeten. SemiAnalysis fand eine gemeinsame Kubernetes control plane, also das System, das einen cluster verwaltet, über die namespaces anderer tenants sichtbar waren. Ein standardmäßiger InfiniBand partition key, der Zugriffe in einem Hochgeschwindigkeitsnetzwerk voneinander trennen soll, legte 532 hostnames offen. Ein Grafana monitoring dashboard schien Kunden visuell voneinander zu trennen, doch die dahinterliegende credential konnte die logs sämtlicher tenants lesen. Dem Bericht zufolge gehörten zu den betroffenen Kunden Banken, Telekommunikationsunternehmen, Universitäten, Forschungseinrichtungen, KI-Labore und ein nationaler Nachrichtendienst.
Diese Erkenntnisse machen aus Architekturfragen konkrete Beschaffungsfragen. Kunden müssen wissen, ob workloads durch containers, virtual machines oder dedicated nodes voneinander getrennt werden; ob die control plane gemeinsam genutzt wird; wer ihre volumes lesen kann; ob die Durchsetzung innerhalb des Speichers oder nur über das davorliegende Interface erfolgt; ob der backend storage über ein isoliertes Netzwerk verfügt; wer beim Anbieter auf logs und monitoring data zugreifen kann; und ob Maschinen vollständig neu aufgebaut oder zwischen Kunden wiederverwendet werden. Anbieter benötigen dokumentierte Antworten, bevor eine diligence review beginnt.
Die Erkenntnisse von SemiAnalysis weisen auf drei legitime Betriebsmodelle hin. Der Aufbau auf Ceph, einer verteilten Speicherplattform, verschafft dem Anbieter Kontrolle über das Design und Unabhängigkeit vom Veröffentlichungszeitplan einer anderen Partei, erfordert jedoch dauerhaft spezialisiertes Personal, das nicht einfach durch compute engineers ersetzt werden kann. Der Aufbau eigener storage hardware hält Design, Betrieb und Umsätze im eigenen Unternehmen, bringt jedoch Beschaffungsarbeit, refresh cycles und Kapitalverpflichtungen mit sich, die Jahre vor dem Bekanntwerden der Nachfrage eingegangen werden. Durch eine Partnerschaft können sich die engineers des Anbieters weiter auf compute konzentrieren, doch der Anbieter gibt einen Teil der Kontrolle über Preise, roadmaps und deprecation schedules ab. Kunden werden sich weiterhin an den neocloud-Anbieter wenden, wenn ein job hängen bleibt, unabhängig davon, wer den Speicher betreibt.
Leser, die externe Infrastrukturoptionen vergleichen, können auch AEU Data, einen Anbieter europäischer Cloud- und Dateninfrastruktur, anhand derselben Fragen zu Eigentümerschaft und Isolation bewerten. Die übertragbare Lehre lautet, sich für ein storage operating model zu entscheiden, bevor Kunden Daten ansammeln: Verantwortung zuweisen, den default path so testen, wie Kunden ihn vorfinden werden, die Isolation überprüfen und Performance-Tests unter anhaltendem Datenverkehr wiederholen.