Mangësitë në neocloud storage e lënë shumicën e ofruesve pa medalje
Neocloud storage është bërë një tregues i dukshëm nëse infrastruktura cloud e përqendruar te GPU-të është gati për klientë me kërkesa të larta. Në ClusterMAX 3.0, SemiAnalysis u dha një vlerësim Medallion vetëm 19 prej 77 ofruesve neocloud që testoi në thellësi. Nivelet e publikuara shkojnë nga Platinum, Gold, Silver dhe Bronze deri te kategoria e re Participation Ribbon, duke u dhënë klientëve të mundshëm një rezultat që mund ta shqyrtojnë përpara se të angazhohen me një ofrues. Disa ofrues që më parë kishin vlerësime Silver ose Gold i humbën ato në këtë raund.
Storage është parakusht, jo një pjesë opsionale e vlerësimit. Çdo ofrues duhet të sigurojë të paktën 10 TB file storage me performancë të lartë, ku aplikacionet punojnë me të dhënat përmes skedarëve dhe dosjeve të zakonshme, si edhe 10 TB object storage në përputhje me S3, i cili i ruan të dhënat si objekte të adresuara në mënyrë të pavarur përmes një interface të tipit S3. SemiAnalysis teston fillimisht performancën dhe më pas kontrollon nëse ajo ruhet gjatë 15 minutave me trafik të përzier e të vazhdueshëm. Disa ofrues humbën pothuajse 40% të bandwidth të tyre, domethënë të kapacitetit për transferimin e të dhënave, gjatë testit të dytë.
Madhësia nuk e përcaktoi rezultatin. SemiAnalysis raportoi probleme me storage në AWS dhe Azure, ndërsa e përshkroi storage e TensorWave, një kompani shumë më e vogël, si të jashtëzakonshëm. Dallimi më i qartë ishte nëse storage kishte një qëllim, platformë dhe përgjegjës të përcaktuar qartë. Një ofrues mund ta trajtojë atë si scratch space të përkohshëm, ndërsa klientët importojnë të dhëna, ekzekutojnë një job dhe heqin rezultatet. Ai mund të trashëgojë një konfigurim që askush nuk e rishikon rregullisht. Ose mund t’ia caktojë përgjegjësinë e vazhdueshme një personi apo një kontraktori. Qasja e parë mund të jetë e përshtatshme për dhënien me qira të GPU-ve me orë, sepse më vonë duhet të migrohet shumë pak. Qasja e dytë bëhet e rrezikshme kur klientët fillojnë të lënë të dhëna në platformë, duke imponuar vendime për vendndodhjen, access, dështimin e makinave dhe çmimet gjatë rritjes së shpejtë.
SemiAnalysis identifikoi katër dështime të përsëritura: role-based access control (RBAC) të pasaktë, i cili duhet t’i kufizojë volume sipas permissions që i janë caktuar një përdoruesi; storage të vendosur gabimisht në një overlay network, duke u mundësuar klientëve të arrijnë underlying physical network; backend storage që përdor një network të përbashkët pa izolim; dhe një data processing unit BlueField (DPU) të lënë në konfigurimin e tij default host-trusted. Një DPU është një kompjuter i vogël i integruar në një network card për të trajtuar detyrat e networking, storage dhe security.
Në reference design të NVIDIA-s, DPU zbaton rregulla që ndihmojnë në ndarjen e tenants, domethënë klientëve që përdorin të njëjtin sistem fizik. Konfigurimi i tij i fabrikës i beson kujtdo që ka root access, nivelin më të lartë të kontrollit mbi një server. Kjo i përshtatet një modeli ku administratorit të serverit i besohet, por klientët e GPU cloud shpesh marrin vetë root access. Si rrjedhojë, një klient i tillë mund të jetë në gjendje të arrijë DPU që zbaton kufirin mes përdoruesve dhe potencialisht ta dobësojë ose çaktivizojë atë kufi. SemiAnalysis gjeti të paktën një host ku kjo rrugë mbetej e hapur. Raporti ia atribuoi ekspozimin faktit se konfigurimi default i produktit nuk ishte ndryshuar kurrë, dhe jo një vendimi të qëllimshëm të design.
Problemet u bënë më themelore në nivelet më të ulëta të vlerësimit. Kritika e vetme ndaj storage të CoreWeave ishte mungesa e local GPUDirect Storage me një klikim, një rrugë e drejtpërdrejtë e të dhënave e synuar për të furnizuar GPU-të në mënyrë efikase, dhe SemiAnalysis e përshkroi këtë kritikë si tepër pedante. Në nivelet e mesme, StorageClass default i Azure, konfigurimi i Kubernetes që përcakton mënyrën se si storage u ofrohet aplikacioneve, nuk mund të lidhej. Ngarkimi i një modeli nga storage me Network File System (NFS) gjithashtu përfundoi me timeout, sepse cluster Slurm nuk kishte një parallel filesystem të aftë për të shërbyer shumë operacione njëkohësisht.
Në nivelin Bronze e më poshtë, ndonjëherë mungonte plotësisht storage i përbashkët dhe i përdorshëm. Një cluster në Seattle nuk kishte asnjë shared filesystem të disponueshëm për testim. Një tjetër nuk kishte një RWX StorageClass, i cili u lejon disa sistemeve të lexojnë dhe të shkruajnë në të njëjtin storage, duke mos lënë asnjë vend ku të bëhej mount `/shared`. Te një ofrues i tretë, hardware Non-Volatile Memory Express (NVMe) ekzistonte, por nuk ishte i ekspozuar ndaj aplikacioneve, ndaj persistent volume claims (PVCs), kërkesat e aplikacioneve për storage, mbetën në pritje. Në një rast tjetër, StorageClass default krijoi dhe lidhi storage, por e la pod e aplikacionit të bllokuar në `ContainerCreating`. Në të njëjtat worker nodes, një Lustre parallel filesystem arriti një shpejtësi të përgjithshme leximi prej 91.7 GB/s në 32 clients. Hardware bazë ishte i shpejtë, por rruga default e bënte të dukej i papërdorshëm.
Dobësitë e storage u shoqëruan me dështime më të gjera të tenant isolation, përfshirë edhe ofrues që testonin racks GB300. SemiAnalysis gjeti një Kubernetes control plane të përbashkët, sistemin që menaxhon një cluster, i cili ekspozonte namespaces të tenants të tjerë. Një InfiniBand partition key default, që përdoret për të ndarë access në një network me shpejtësi të lartë, zbuloi 532 hostnames. Një Grafana monitoring dashboard dukej sikur i ndante klientët vizualisht, por credential pas tij mund të lexonte logs të çdo tenant. Raporti tha se klientët e ekspozuar përfshinin banka, kompani telekomunikacioni, universitete, institucione kërkimore, laboratorë të AI dhe një agjenci kombëtare të inteligjencës.
Këto gjetje i kthejnë pyetjet për arkitekturën në pyetje për blerjen. Klientët duhet të dinë nëse workloads ndahen përmes containers, virtual machines apo dedicated nodes; nëse control plane është i përbashkët; kush mund t’i lexojë volumes e tyre; nëse zbatimi i rregullave bëhet brenda storage apo vetëm përmes interface përpara tij; nëse backend storage ka një network të izoluar; kush te ofruesi mund të ketë access te logs dhe të dhënat e monitoring; dhe nëse makinat rindërtohen nga e para apo ripërdoren mes klientëve. Ofruesit duhet të kenë përgjigje të dokumentuara përpara se të fillojë një shqyrtim i kujdesshëm.
Gjetjet e SemiAnalysis tregojnë tri zgjedhje të vlefshme operimi. Ndërtimi mbi Ceph, një platformë distributed storage, i jep ofruesit kontroll mbi design dhe pavarësi nga kalendari i publikimeve të një pale tjetër, por kërkon staf të përhershëm specialistësh që nuk mund të zëvendësohet thjesht me compute engineers. Ndërtimi i custom storage hardware e mban design, operimin dhe të ardhurat brenda kompanisë, por sjell punë prokurimi, refresh cycles dhe angazhime kapitali të bëra vite përpara se të njihet kërkesa. Një partneritet mund t’i lërë engineers e ofruesit të përqendruar te compute, por heq dorë nga një pjesë e kontrollit mbi çmimet, roadmaps dhe deprecation schedules. Klientët do të kontaktojnë përsëri neocloud kur një job të bllokohet, pavarësisht se kush e operon storage.
Lexuesit që krahasojnë opsionet e infrastrukturës së jashtme mund të vlerësojnë gjithashtu AEU Data, e cila ofron cloud dhe infrastrukturë të dhënash në Evropë, duke përdorur të njëjtat pyetje për pronësinë dhe izolimin. Mësimi që mund të zbatohet gjerësisht është të zgjidhet një model operimi për storage përpara se klientët të grumbullojnë të dhëna: të caktohet përgjegjësia, të testohet rruga default ashtu siç do ta hasin klientët, të verifikohet izolimi dhe të përsëriten testet e performancës nën trafik të vazhdueshëm.