Úložisko pre klastre AI: NFS, BeeGFS, Lustre a otázka o úložisku objektov

Zdieľané úložisko je súčasťou distribuovaného trénovacieho klastra, na ktorú nikto nepremýšľa, kým sa nestane dôvodom, prečo sú GPU využité na 40 %. V tomto bode je jeho nahradenie bolestivé – každý trénovací skript má zabudované predpoklady, každý kontrolný bod je vo formáte, ktorý sa môže, ale nemusí migrovať čiste, a klaster je v produkcii. Správny čas na rozhodnutie o úložisku je pred odložením druhého trénovacieho uzla.

Toto je úložná polovica série K. Je to pohľad kupujúceho a architekta, nie návod pre správcu systému – cieľom je s otvorenými očami rozhodovať medzi NFS, BeeGFS, Lustre a objektovými úložiskami a úprimne povedané, ktorý z nich väčšina zákazníkov Kentina skutočne potrebuje.

Prečo je zdieľané úložisko tichým úzkym hrdlom

Tréner jedného uzla číta svoju dataset z lokálneho NVMe a zapisuje kontrolné body na to isté miesto. Nie je o čom diskutovať. V momente, keď sa pripojí druhý uzol, zmenia sa dve veci:

1. Každý uzol číta rovnaký súbor údajov. Bajty sú identické na každom pracovníkovi a musia byť viditeľné z každého uzla.
2. Každý uzol zapisuje kontrolné body a únia musí prežiť. Pri FSDP alebo DeepSpeed ​​shardingu každá hodnosť zapisuje do vlastného segmentu; pri DDP hodnosti zapisujú redundantne. V oboch prípadoch súborový systém zaznamenáva vlnu veľkých zápisov každých niekoľko minút až niekoľko hodín.

Tieto prístupové vzorce sú opačné. Prístup k dátovým súborom je trvalý, sekvenčný, s vysokou mierou čítania a toleranciou latencie. Prístup k kontrolným bodom je impulzívny, s veľkými blokmi, s vysokou mierou zápisu a trénovacími blokmi. Úložný systém, ktorý je dobrý v jednom, je často priemerný v druhom.

Okrem toho moderné súbory údajov strojového učenia robia ešte tretiu vec: búrky metadátSúbor údajov s 50 miliónmi súborov JPEG s veľkosťou 4–12 KB predstavuje z pohľadu súborového systému 50 miliónov cyklov otvorenia/status/čítania/zatvorenia. Server metadát, nie dátová cesta, sa preruší ako prvý. Preto odpoveď „máme dostatok šírky pásma“ nie je dostatočná.

NFS – predvolený a vydrží dlhšie, než si myslíte

NFS (NFSv3 alebo v4) je cesta najmenšieho odporu. Každá distribúcia Linuxu ho dodáva, každý plánovač mu rozumie a „úložný uzol“ je len Linuxová škatuľa s množstvom disku, /etc/exports linku a rýchlu sieťovú kartu.

Čo vám poskytuje rozumne zostavený NFS server:

• Jeden menný priestor pripojený identicky na každom výpočtovom uzle.
• Slušná sekvenčná priepustnosť čítania, najmä s nconnect na moderných jadrách (multiplexovanie jedného pripojenia cez niekoľko TCP pripojení – strop jedného streamu je už roky preč).
• Prevádzkovo nudné. Zlyhania sú dobre pochopené, postupy obnovy sú v každej knihe o systémovej administrácii, ktorá bola kedy napísaná.

Čoho sa vzdáš:

• Jeden server, jedno úzke hrdlo. Agregovaná priepustnosť klastra je obmedzená na to, čo dané zariadenie obsluhuje.
• Uzamykanie a serializácia metadát. Pracovné zaťaženie malých súborov narazí na limity metadát skôr ako na limity šírky pásma.
• Žiadne elegantné škálovanie. Keď je krabica plná, vytvoríte druhú s iným bodom pripojenia a vaše skripty sa o tom dozvedia.

Nespravodlivá reputácia, ktorú má NFS v kruhoch HPC, je spôsobená najmä starým stropom pre jedno pripojenie a problémami s metadátami v malých súboroch. Na trénovanie dátových súborov v rozsahu od 100 GB do 1–2 TB na uzloch so 4–8 GPU je správne zostavený NFS server skutočne v poriadku. Videli sme zákazníkov, ktorí bez sťažností trénovali Qwen2.5-VL na dátových súboroch podporovaných NFS.

NFS začína bolieť, keď:

• Dátové množiny presahujú približne 2 TB a náhodné prehrávanie spôsobuje zahltenie vyrovnávacej pamäte na serveri.
• Viac ako ~8–12 výpočtových uzlov narazilo na rovnaký držiak pri zaťažení.
• Pracovnej záťaži dominujú desiatky miliónov malých súborov.
• Veľkosti kontrolných bodov na poradie presahujú 50 – 100 GB súbežne zapísaných.

Pod všetkými štyrmi prahovými hodnotami je NFS takmer určite správnou odpoveďou a paralelný súborový systém je prehnane komplikovaný.

BeeGFS — praktický stred

BeeGFS je paralelný súborový systém, ktorý ľudia v skutočnosti nasadzujú, keď NFS prestane stačiť. Rozdeľuje dáta medzi viacero ciele úložiska (disky na viacerých serveroch) a ciele metadát (samostatné NVMe servery). Klienti vidia jeden menný priestor; čítajú a zapisujú dáta v rámci cieľových úložísk paralelne.

Prečo sa objavuje v stredne veľkých zhlukoch:

• Príprava trvá dni, nie týždne. Kompetentný linuxový inžinier dokáže zvládnuť inštaláciu dvoch úložných uzlov a jedného MDS za jedno popoludnie. Lustre v tejto lige nie je.
• Agregovaná šírka pásma sa lineárne škáluje s cieľmi úložiska. Tri uzly na 100 GbE poskytujú takmer trojnásobnú priepustnosť čítania oproti jednému.
• Natívny RDMA na InfiniBand alebo RoCE – vyhýba sa réžii TCP/IP.
• Otvorený zdrojový kód, žiadna pasca licencií na TB. Komerčná podpora od ThinkParQ je voliteľná.

V čom je úprimne menej dobrý:

• Metadáta pre úlohy s veľmi mnohými malými súbormi. Jeden MDS sa stáva úzkym hrdlom pri dominancii súborov pod 4 KB. Môžete pridať ciele metadát, ale architektúra nie je taká agresívna ako Lustre DNE.
• Žiadne vstavané vrstvenie. Zvládajte horúčavu/chlad sami.
• HA je priskrutkované, nie je natívne. Zrkadlenie funguje, ale nie je také transparentné ako záložné prepnutie Lustre.

Ideálny bod: 4–32 trénovacích uzlov, 10–100 TB dátovej sady, súbory v rozsahu 1 MB až 1 GB. Kde sa nachádza väčšina viacuzlových stavieb Kentina.

Základné nasadenie BeeGFS pre 4-uzlový klaster triedy Kentino:

Trvalé agregované čítanie do štyroch trénerov sa zvyčajne pohybuje v rozsahu 30 – 60 GB/s, čo stačí na napájanie 32 GPU pri väčšine tréningov videnia a LLM. Toto škálovanie sa zastaví, keď sa server metadát nasýti – pridajte druhý cieľ metadát alebo začnite uvažovať o Lustre.

Lesk – zlatý štandard, skutočná komplexnosť

Lustre prevádzkuje úložnú vrstvu prakticky každého superpočítača z top 500, ktorý potrebuje POSIX, škálovateľnú na stovky petabajtov a celkovú priepustnosť niekoľko TB/s. Architektúra má tri úlohy: MGS/MDS (správa + metadáta), OSS (servery objektového úložiska uchovávajúce OST) a klienti. Klienti komunikujú s MDS o operáciách menného priestoru a potom komunikujú priamo s OSS, ktorý uchováva dáta – dátová cesta úplne obchádza server metadát. Toto oddelenie je dôvodom, prečo sa Lustre škáluje, a DNE (Distributed Namespace) umožňuje horizontálne škálovanie metadát.

Náklady sú prevádzkové: strmšia krivka učenia ako v prípade BeeGFS, prísne požiadavky na jadro/ovládač, desiatky ladiacich gombíkov (výkon po vybalení zvyčajne nie je to, čo hardvér dokáže poskytnúť) a postupy obnovy, ktoré vyžadujú kompetentného inžiniera úložiska.

Prahová hodnota, pri ktorej má Lustre zmysel, je približne 16 – 32+ trénovacích uzlov alebo súborov údajov triedy PB. Pod touto hranicou BeeGFS saturuje sieť dávno predtým, ako architektonické výhody Lustre začnú hrať rolu. Zostava Kentina väčšinou nedosahuje prahovú hodnotu – na požiadanie zostavíme klaster Lustre, ale najprv vám povieme, že BeeGFS plus výkonný MDS vám zabezpečí 80 % cesty pri 20 % prevádzkovej záťaže.

Objektové úložisko — MinIO a Ceph pre dátové jazerá strojového učenia

Vyššie uvedené paralelné súborové systémy sú správne, keď framework očakáva súbory. Rastúci podiel moderných ML kanálov ich neočakáva – datasety existujú ako objekty S3, zavádzač dát ich stiahne cez HTTP a lokálny súborový systém je dočasne scratch.

MinIO je jednoúčelové úložisko objektov kompatibilné s S3. Distribuovaný režim beží na 4–32+ uzloch s vymazávacím kódom. Open source, operačne jednoduchší ako akýkoľvek paralelný súborový systém a moderné zavádzače údajov (PyTorch s fsspec/s3fs, WebDataset, NVIDIA DALI) si ho prečítajú priamo.

CEF je širší – blok (RBD), súbor (CephFS), objekt (RGW) na tej istej vrstve RADOS. Ceph vyhráva, keď chcete jeden úložný systém pre viacero pracovných zaťažení (virtuálne počítače, zdieľané súbory, objekty strojového učenia). Stráca na prevádzkovej jednoduchosti – Ceph je systém, ku ktorému sa zaviažete, s vlastným monitorovaním, ladením a disciplínou v oblasti pohotovosti.

Čo vám objektové úložisko poskytuje pre ML: nízku kapacitu (husté HDD uzly s kódovaním na vymazanie dávajú čísla €/TB, ktorých sa flash pamäť nedotkne), operačne jednoduché škálovanie, segmentované rozdelenie už od návrhu (žiadne úzke miesto v metadátach) a dobrú zhodu s dátovými zavádzačmi založenými na segmentoch. Čoho sa vzdáte: latencie desiatok ms na operáciu (nie mikrosekúnd), žiadneho priameho POSIXu (prepíšte zavádzač alebo akceptujte penalizáciu FUSE) a žiadnych zápisov na mieste (objekty sú nemenné – v poriadku pre kontrolné body, zlé pre čokoľvek, čo mutuje).

Architektúra, ktorá funguje v praxi: objektové úložisko ako odolné, rozsiahle a lacné dátové jazero; paralelný alebo NFS súborový systém ako rýchlopracujúca sada pripravená pre aktuálne spustenie. Dátová sada sa nachádza v MinIO. Úloha na začiatku pripraví relevantné shardy na BeeGFS alebo lokálny NVMe scratch. Finálne kontrolné body sa odošlú späť do MinIO na archiváciu.

WekaIO a VAST – podniková úroveň (stručne)

WekaIO a VAST Data sú účelovým riešením s cenou pre podniky: extrémne malé metadáta súborov, veľmi vysoká agregovaná šírka pásma, natívne S3 a POSIX, integrované vrstvenie, priame cesty GPU. Tieto riešenia dávajú vynikajúci zmysel pre klastre s viac ako 100 GPU, kde úložisko musí držať krok s výdavkami na GPU. Nie sú to správne riešenie pre server so 4 alebo 8 GPU, ani pre klaster so štyrmi takýmito procesormi – náklady na úložisko by dominovali zostave. Spomínané tu pre úprimnosť ohľadom špičkovej technológie, nie ako odporúčanie pre kupujúceho, pre ktorého je táto séria určená.

Vzory prístupu k dátovým súborom a prečo sú dôležité

V tréningu strojového učenia dominujú dva vzorce. Vzor A – veľké črepy: dátové súbory vopred zabalené do tarballov WebDataset, Parquet alebo LMDB, 100 MB až 10 GB na shard, čítané sekvenčne a premiešané vo vnútri. Každý úložný systém je v tom dobrý. Vzor B – veľa malých súborov: milióny súborov JPEG/PNG/JSON, jeden na vzorku, čo zaťažuje cestu k metadátam. To trestá NFS, vo veľkom rozsahu poškodzuje BeeGFS a je dôvodom existencie Weka a VAST.

Jediným najvýznamnejším rozhodnutím v oblasti ukladania tréningových dát je presunutie vzoru B do vzoru A. Ak je vaša dátová množina malá, pred trénovaním ju prekombinujte do segmentov (shardov). Nákladom je jeden predbežný proces; výhodou je, že akýkoľvek úložný systém sa stane postačujúcim. Videli sme zrýchlenie dátových kanálov 3 – 5-krát bez zmeny úložného hardvéru, len prekombinovaním.

Ak nemôžete prebaľovať dáta – dátový súbor sa neustále mení, framework skutočne vyžaduje súbory pre každú vzorku – veľkosť úložiska sa prispôsobuje IOPS metadát, nie šírke pásma. To vás posúva smerom k BeeGFS s viacerými cieľmi MDS, Weka/VAST alebo Lustre s DNE.

Stratégia kontrolných bodov – píšte rýchlo, píšte neskôr, píšte menej

Zápisy kontrolných bodov sú najhorším prípadom: každá hodnosť zapisuje súčasne, zápisy sú veľké, trénovacie bloky sú trvalé. Naivný synchrónny kontrolný bod na modeli so 100 B parametrami môže trénovanie zastaviť na desiatky minút.

Súčasným osvedčeným postupom je trojstupňový prístup, ktorý je pôvodne založený na PyTorch. torch.distributed.checkpoint (DCP), NVIDIA NeMo a väčšina moderných frameworkov:

1. Každá hodnosť zapíše svoj shard na lokálny NVMe scratch. Celková šírka pásma zápisu klastra je súčtom rýchlostí NVMe na uzol (5 – 50 GB/s pre každý). Trénovanie odblokuje dáta v priebehu niekoľkých sekúnd.
2. Asynchrónny proces na pozadí kopíruje do zdieľaného úložiska. Tréning sa už obnovil.
3. Staršie kontrolné body sa odstránia alebo presunú do úložiska objektov. podľa plánu. Posledné 2–3 nechajte na rýchlom úložisku, zvyšok na MinIO/Ceph.

Dôsledok: Zdieľané úložisko nemusí absorbovať každý kontrolný bod plnou rýchlosťou. Musí prijímať asynchrónnu kópiu bez toho, aby zaostával za kadenciou. Pre kontrolný bod modelu 70 B každých 30 minút postačuje nízka trvalá rýchlosť zápisu v jednom GB/s – čo je v rámci kompetentného BeeGFS alebo dobrého NFS servera.

Chyba, ktorej sa treba vyhnúť: synchrónne, nedegradované kontrolné body zapisované priamo do NFS. To bolo v roku 2022 normálne. Dnes to už nie je. Ak to váš kanál robí, oprava kódu kontrolného bodu má väčší vplyv ako aktualizácia úložiska.

Otázka klastrového uplinku

Zdieľa úložná prevádzka štruktúru s tréningom alebo dostáva samostatnú?

Zdieľaná infraštruktúra je vhodná pre klastre so 4–8 uzlami s asynchrónnymi kontrolnými bodmi; rozdelená infraštruktúra je opodstatnená pre klastre nad 8 uzlov alebo pre náročné synchrónne I/O.

Pre klastre Kentino triedy 4–8 je zdieľaná infraštruktúra v poriadku, keď sa používa asynchrónne kontrolné stanovenie a pracovná záťaž úložiska je prevažne čítanie – trvalé čítanie koexistuje s kolektívmi NCCL bez vážneho poškodenia. Rozdelená infraštruktúra je opodstatnená pre rozsiahle trénovanie LLM s FSDP pri vysokom stupni TP/PP, pri veľkej synchrónnej prevádzke úložiska alebo keď to rozpočet dovoľuje. Praktická predvolená hodnota: zdieľaná 100 GbE až do 8 uzlov s úložnou VLAN ako mäkkou izoláciou.

Úprimné odporúčania podľa rozsahu

Väčšina zákazníkov spoločnosti Kentino pristane v druhom a treťom rade. Zvyšok vyrobíme na požiadanie, ale povieme vám, kedy je nad rámec špecifikácií.

Čo sa zlomí

Spôsoby zlyhania, ktoré sme pozorovali, zoradené podľa toho, ako často sa zahryznú:

• Hladovanie metadát pri načítaní malých súborov. Príznak: GPU na 30–50 %, sieť nečinná, úložisko nečinné CPU, každý open() pomalé. Oprava: prebaľovanie do shardov alebo škálovanie cieľov MDS.
• Synchrónne kontrolné body brzdia tréning. Oprava: asynchrónne delené kontrolné body (PyTorch DCP alebo NeMo).
• Jeden pomalý disk ničí klaster. Zlyhávajúci SSD disk nezlyhá úplne – iba sa spomalí. Oprava: monitorovanie latencie pre každé zariadenie, alarm pri > 2× základnej čiare.
• Vyrovnávacia pamäť stránok na úložnom uzle je poškodená. Dátová sada sa nezmestí do RAM, každá epocha vytlačí predchádzajúcu. Oprava: viac RAM.
• nconnect nie je povolené na klientoch NFS. Predvolené obmedzenie jednoprúdového NFS je hlboko pod rýchlosťou sieťovej karty. nconnect=8 or =16 poskytuje 4–8-násobnú priepustnosť na rovnakom hardvéri.
• MinIO vo veľkom meradle bez ladenia EC. Predvolené hodnoty uprednostňujú trvanlivosť pred latenciou; latencia malých objektov trpí. Neprijímajte predvolené hodnoty slepo.

Nič z toho nie je exotické. Všetky sú predvídateľné, keď ich raz uvidíte.

Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na info@kentino.com.