Le lacune del neocloud storage lasciano la maggior parte dei provider senza medaglie
Il neocloud storage è diventato un indicatore evidente della capacità delle infrastrutture cloud incentrate sulle GPU di soddisfare i clienti più esigenti. In ClusterMAX 3.0, SemiAnalysis ha assegnato una valutazione Medallion solo a 19 dei 77 provider neocloud sottoposti a test approfonditi. Le fasce pubblicate vanno da Platinum, Gold, Silver e Bronze fino alla nuova Participation Ribbon, offrendo ai potenziali clienti un risultato da esaminare prima di affidarsi a un provider. Diversi provider che in precedenza avevano ottenuto valutazioni Silver o Gold le hanno perse in questa tornata.
Lo storage è un requisito indispensabile, non una sezione facoltativa della valutazione. Ogni provider deve fornire almeno 10TB di file storage ad alte prestazioni, in cui le applicazioni utilizzano i dati attraverso file e cartelle familiari, oltre a 10TB di object storage compatibile con S3, che conserva i dati come oggetti indirizzati in modo indipendente tramite un'interfaccia in stile S3. SemiAnalysis verifica prima le prestazioni, quindi controlla se vengono mantenute durante 15 minuti di traffico misto continuo. Alcuni provider hanno perso quasi il 40% della propria larghezza di banda, ossia della capacità di trasferimento dei dati, durante il secondo test.
Le dimensioni non hanno determinato il risultato. SemiAnalysis ha segnalato problemi di storage presso AWS e Azure, descrivendo invece come eccezionale lo storage della molto più piccola TensorWave. La distinzione più significativa riguardava la presenza di uno scopo, una piattaforma e un responsabile esplicitamente assegnati allo storage. Un provider può trattarlo come scratch space temporaneo mentre i clienti importano dati, eseguono un job e rimuovono i risultati. Può ereditare una configurazione che nessuno riesamina regolarmente. Oppure può assegnarne la responsabilità continuativa a una persona o tramite un contratto. Il primo approccio può essere adatto al noleggio orario di GPU, perché in seguito è necessario migrare ben poco. Il secondo diventa rischioso quando i clienti iniziano a lasciare i dati sulla piattaforma, imponendo decisioni su ubicazione, accesso, guasti delle macchine e prezzi durante una crescita rapida.
SemiAnalysis ha individuato quattro problemi ricorrenti: un role-based access control (RBAC) configurato in modo errato, che dovrebbe limitare i volumi in base ai permessi assegnati all'utente; storage collocato in modo scorretto su una overlay network, consentendo ai clienti di raggiungere la rete fisica sottostante; backend storage che utilizza una rete condivisa senza isolamento; e una data processing unit BlueField (DPU) lasciata nella modalità host-trusted predefinita. Una DPU è un piccolo computer integrato in una scheda di rete per gestire attività di networking, storage e sicurezza.
Nel reference design di NVIDIA, la DPU applica regole che contribuiscono a separare i tenant, cioè i clienti che condividono lo stesso sistema fisico. L'impostazione di fabbrica considera attendibile chiunque disponga di root access, il massimo livello di controllo su un server. Ciò è adatto a un modello in cui l'amministratore del server è considerato attendibile, ma i clienti dei cloud GPU spesso ricevono a loro volta root access. Un cliente di questo tipo potrebbe quindi riuscire a raggiungere la DPU che impone il confine tra gli utenti e potenzialmente indebolire o disabilitare tale confine. SemiAnalysis ha trovato almeno un host in cui questo percorso era rimasto aperto. Il rapporto ha attribuito l'esposizione all'impostazione predefinita fornita, che non era mai stata modificata, anziché a una decisione progettuale deliberata.
I problemi diventavano più fondamentali nelle fasce inferiori della valutazione. L'unica critica rivolta allo storage di CoreWeave riguardava l'assenza di GPUDirect Storage locale attivabile con un solo clic, un percorso diretto dei dati progettato per alimentare le GPU in modo efficiente, e SemiAnalysis ha descritto tale critica come eccessivamente pignola. Nelle fasce intermedie, la StorageClass predefinita di Azure, l'impostazione Kubernetes che determina come viene fornito lo storage alle applicazioni, non riusciva a collegarsi. Anche il caricamento di un modello dallo storage Network File System (NFS) è scaduto perché il cluster Slurm non disponeva di un filesystem parallelo capace di gestire simultaneamente molte operazioni.
Nella fascia Bronze e in quelle inferiori, a volte mancava uno storage condiviso utilizzabile. Un cluster di Seattle non disponeva di alcun filesystem condiviso per i test. Un altro non aveva una RWX StorageClass, che consente a più sistemi di leggere e scrivere sullo stesso storage, e quindi non offriva alcuna posizione in cui montare `/shared`. Presso un terzo provider era presente hardware Non-Volatile Memory Express (NVMe), ma non era esposto alle applicazioni; di conseguenza, le persistent volume claims (PVCs), ossia le richieste di storage da parte delle applicazioni, rimanevano in sospeso. In un altro caso, la StorageClass predefinita creava e associava lo storage, ma lasciava il pod dell'applicazione bloccato nello stato `ContainerCreating`. Sugli stessi worker nodes, un filesystem parallelo Lustre ha raggiunto una velocità di lettura aggregata di 91,7 GB/s su 32 client. L'hardware sottostante era veloce, ma il percorso predefinito lo faceva apparire inutilizzabile.
Le debolezze dello storage erano accompagnate da problemi più ampi di tenant isolation, anche presso provider che stavano testando rack GB300. SemiAnalysis ha individuato un Kubernetes control plane condiviso, il sistema che gestisce un cluster, che esponeva i namespace di altri tenant. Una partition key InfiniBand predefinita, utilizzata per separare l'accesso su una rete ad alta velocità, rivelava 532 hostname. Una dashboard di monitoraggio Grafana sembrava separare visivamente i clienti, ma la credential sottostante poteva leggere i log di tutti i tenant. Secondo il rapporto, tra i clienti esposti figuravano banche, aziende di telecomunicazioni, università, istituti di ricerca, laboratori di AI e un'agenzia nazionale di intelligence.
Questi risultati trasformano le questioni architetturali in questioni di acquisto. I clienti devono sapere se i workload sono separati tramite container, macchine virtuali o nodi dedicati; se il control plane è condiviso; chi può leggere i loro volumi; se i controlli vengono applicati all'interno dello storage o soltanto tramite l'interfaccia che lo precede; se il backend storage dispone di una rete isolata; chi, presso il provider, può accedere ai log e ai dati di monitoraggio; e se le macchine vengono ricostruite da zero o riutilizzate tra clienti diversi. I provider devono disporre di risposte documentate prima dell'inizio di una verifica di due diligence.
I risultati di SemiAnalysis indicano tre scelte operative legittime. Costruire su Ceph, una piattaforma di storage distribuito, offre al provider controllo sulla progettazione e indipendenza dal calendario delle release di terzi, ma richiede personale specializzato permanente che non può essere semplicemente sostituito da ingegneri del compute. La realizzazione di hardware di storage personalizzato mantiene internamente progettazione, attività operative e ricavi, ma comporta attività di approvvigionamento, cicli di rinnovo e impegni di capitale assunti anni prima di conoscere la domanda. Una partnership può consentire agli ingegneri del provider di concentrarsi sul compute, ma comporta la rinuncia a una parte del controllo su prezzi, roadmap e calendari di deprecation. Quando un job si blocca, i clienti contatteranno comunque il provider neocloud, indipendentemente da chi gestisce lo storage.
I lettori che confrontano opzioni infrastrutturali esterne possono inoltre valutare AEU Data, che fornisce servizi cloud e infrastrutture dati europee, ponendo le stesse domande in materia di responsabilità e isolamento. La lezione applicabile altrove è scegliere un modello operativo dello storage prima che i clienti accumulino dati: assegnare le responsabilità, testare il percorso predefinito così come verrà utilizzato dai clienti, verificare l'isolamento e ripetere i test delle prestazioni con traffico continuo.