Úložiská pre AI klastre: NFS, BeeGFS, Lustre a otázka object storage

Zdieľané úložisko je tá časť distribuovaného tréningového klastra, na ktorú nikto nemyslí, kým sa z nej nestane dôvod, prečo GPU bežia na 40 % využitia. V tej chvíli je už jeho výmena bolestivá — každý tréningový skript má v sebe zapečené predpoklady, každý checkpoint je vo formáte, ktorý sa možno prenesie čisto a možno nie, a klaster je v produkcii. Správny čas rozhodnúť o úložisku je predtým, než do racku zamontujete druhý tréningový uzol.

Toto je úložisková polovica série K. Ide o pohľad kupujúceho a architekta, nie o návod pre správcu systému — cieľom je rozhodnúť sa medzi NFS, BeeGFS, Lustre a objektovými úložiskami s otvorenými očami a povedať na rovinu, ktoré z nich väčšina zákazníkov Kentino skutočne potrebuje.

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

Tréning na jednom uzle číta dataset z lokálneho NVMe a na to isté miesto zapisuje checkpointy. Nie je o čom diskutovať. Vo chvíli, keď pribudne druhý uzol, sa menia dve veci:

1. Každý uzol číta ten istý dataset. Bajty sú na každom workeri identické a musia byť viditeľné z každého uzla.
2. Každý uzol zapisuje checkpointy a ich zjednotenie musí prežiť. Pri shardovaní cez FSDP alebo DeepSpeed zapisuje každý rank vlastnú časť; pri DDP zapisujú ranky redundantne. Tak či onak, súborový systém zažije každých pár minút až hodín nápor veľkých zápisov.

Tieto prístupové vzory sú protichodné. Prístup k datasetu je trvalý, sekvenčný, prevažne čítací a tolerantný voči latencii. Prístup pri checkpointoch je nárazový, veľkoblokový, prevažne zápisový a tréning naň čaká. Úložný systém, ktorý je dobrý v jednom, býva v druhom priemerný.

Navyše moderné ML datasety robia ešte tretiu vec: metadátové búrky. Dataset s 50 miliónmi JPEG súborov veľkosti 4–12 KB je z pohľadu súborového systému 50 miliónov cyklov open/stat/read/close. Ako prvý padne metadátový server, nie dátová cesta. Preto „máme dosť priepustnosti“ nie je dostatočná odpoveď.

NFS — predvolená voľba, ktorá vydrží dlhšie, než si myslíte

NFS (NFSv3 alebo v4) je cesta najmenšieho odporu. Dodáva ho každá distribúcia Linuxu, rozumie mu každý plánovač a „úložný uzol“ je len linuxový stroj s množstvom diskov, riadkom v /etc/exports a rýchlou sieťovou kartou.

Čo Vám rozumne postavený NFS server dá:

• Jeden menný priestor pripojený rovnako na každom výpočtovom uzle.
• Slušnú sekvenčnú čítaciu priepustnosť, najmä s nconnect na moderných jadrách (multiplexovanie jedného pripojenia cez viacero TCP spojení — strop jedného streamu je už roky minulosťou).
• Prevádzkovú nudu. Poruchy sú dobre zmapované a postupy obnovy nájdete v každej príručke pre správcov systému, aká kedy vznikla.

Čoho sa vzdáte:

• Jeden server, jedno úzke hrdlo. Celková priepustnosť klastra je obmedzená tým, čo zvládne obslúžiť tento jediný stroj.
• Zamykanie a serializácia metadát. Workloady s malými súbormi narazia na limity metadát skôr než na limity priepustnosti.
• Žiadne elegantné škálovanie do šírky. Keď je stroj plný, postavíte druhý s iným bodom pripojenia a Vaše skripty sa o tom musia dozvedieť.

Nespravodlivá povesť, ktorú má NFS v HPC kruhoch, stojí väčšinou na starom strope jedného spojenia a na metadátovom trápení s drobnými súbormi. Pri tréningových datasetoch v rozsahu 100 GB až 1–2 TB na uzloch so 4–8 GPU je poriadne postavený NFS server naozaj v poriadku. Videli sme zákazníkov, ktorí bez jedinej sťažnosti trénovali fine-tuny Qwen2.5-VL na datasetoch uložených na NFS.

NFS začne bolieť, keď:

• Datasety presiahnu ~2 TB a shuffle zahlcuje cache na serveri.
• Na ten istý mount point tlačí pod záťažou viac než ~8–12 výpočtových uzlov.
• Workloadu dominujú desiatky miliónov malých súborov.
• Veľkosť checkpointu na jeden rank presiahne 50–100 GB zapisovaných súbežne.

Pod všetkými štyrmi prahmi je NFS takmer isto správnou odpoveďou a paralelný súborový systém je zbytočné prekomplikovanie.

BeeGFS — praktický stred

BeeGFS je paralelný súborový systém, ktorý sa reálne nasadzuje vtedy, keď NFS prestane stačiť. Dáta rozdeľuje medzi viacero úložných cieľov (disky na viacerých serveroch) a metadátových cieľov (samostatné NVMe servery). Klienti vidia jeden menný priestor; čítania a zápisy sa paralelne rozkladajú naprieč úložnými cieľmi.

Prečo sa objavuje v klastroch strednej veľkosti:

• Nasadenie trvá dni, nie týždne. Schopný linuxový inžinier postaví inštaláciu s dvoma úložnými uzlami a jedným MDS za jedno popoludnie. Lustre v tejto lige nehrá.
• Agregovaná priepustnosť škáluje lineárne s počtom úložných cieľov. Tri uzly na 100 GbE doručia takmer 3× vyššiu čítaciu priepustnosť než jeden.
• Natívne RDMA na InfiniBande alebo RoCE — obchádza réžiu TCP/IP.
• Open source, bez pasce licencovania za TB. Komerčná podpora od ThinkParQ je voliteľná.

V čom je úprimne slabší:

• Metadáta pri workloadoch s obrovským množstvom malých súborov. Jediný MDS sa stane úzkym hrdlom, keď prevažujú súbory pod 4 KB. Metadátové ciele sa dajú pridať, ale architektúra nie je taká agresívna ako DNE v Lustre.
• Žiadne vstavané vrstvenie. Horúce a studené dáta si spravujete sami.
• Vysoká dostupnosť je pridaná, nie natívna. Zrkadlenie funguje, ale nie je také transparentné ako failover v Lustre.

Ideálny rozsah: 4–32 tréningových uzlov, 10–100 TB datasetu, súbory v rozmedzí 1 MB až 1 GB. Presne tam, kde končí väčšina viacuzlových zostáv Kentino.

Základné nasadenie BeeGFS pre štvoruzlový klaster triedy Kentino:

Trvalé agregované čítanie do štyroch tréningových uzlov sa zvyčajne pohybuje v rozmedzí 30–60 GB/s, čo stačí na nasýtenie 32 GPU pri väčšine vision aj LLM tréningov. Škálovanie sa zastaví, keď sa nasýti metadátový server — pridajte druhý metadátový cieľ alebo začnite rozmýšľať nad Lustre.

Lustre — zlatý štandard, skutočná zložitosť

Lustre poháňa úložnú vrstvu prakticky každého superpočítača z rebríčka Top 500, ktorý potrebuje POSIX, a škáluje na stovky petabajtov a agregovanú priepustnosť v jednotkách TB/s. Architektúra má tri role: MGS/MDS (správa + metadáta), OSS (objektové úložné servery nesúce OST) a klientov. Klienti komunikujú s MDS kvôli operáciám s menným priestorom a potom priamo s tým OSS, ktorý drží dáta — dátová cesta metadátový server úplne obchádza. Práve toto oddelenie je dôvodom, prečo Lustre škáluje, a DNE (Distributed Namespace) umožňuje horizontálne škálovať aj metadáta.

Cena je prevádzková: strmšia krivka učenia než pri BeeGFS, prísne požiadavky na jadro a ovládače, desiatky ladiacich parametrov (výkon hneď po inštalácii zvyčajne nie je tým, čo hardvér dokáže dať) a postupy obnovy, ktoré si vyžadujú schopného úložného inžiniera.

Hranica, od ktorej dáva Lustre zmysel, je zhruba 16–32+ tréningových uzlov alebo datasety v rádoch PB. Pod ňou BeeGFS nasýti sieť dávno predtým, než sa prejavia architektonické výhody Lustre. Ponuka Kentino túto hranicu väčšinou nedosahuje — Lustre klaster postavíme, ak si ho vyžiadate, ale najprv Vám povieme, že BeeGFS so silným MDS Vás dostane na 80 % cesty za 20 % prevádzkovej bolesti.

Objektové úložiská — MinIO a Ceph pre ML dátové jazerá

Paralelné súborové systémy vyššie sú správnou voľbou vtedy, keď framework očakáva súbory. Rastúca časť moderných ML pipeline to tak nerobí — datasety žijú ako S3 objekty, data loader ich ťahá cez HTTP a lokálny súborový systém slúži len ako dočasný scratch.

MinIO je jednoúčelové objektové úložisko kompatibilné s S3. Distribuovaný režim beží na 4–32+ uzloch s erasure codingom. Open source, prevádzkovo jednoduchšie než ktorýkoľvek paralelný súborový systém, a moderné data loadery (PyTorch s fsspec/s3fs, WebDataset, NVIDIA DALI) z neho čítajú priamo.

Ceph je širší — blokové (RBD), súborové (CephFS) aj objektové (RGW) úložisko nad tou istou vrstvou RADOS. Ceph vyhráva vtedy, keď chcete jeden úložný systém pre viacero workloadov (virtuálne stroje, súborové zdieľania, ML objekty). Prehráva na prevádzkovej jednoduchosti — Ceph je systém, ku ktorému sa zaviažete, s vlastným monitoringom, ladením a pohotovostnou disciplínou.

Čo objektové úložisko prináša pre ML: lacnú kapacitu (husté HDD uzly s erasure codingom dávajú €/TB čísla, na ktoré flash nemá), prevádzkovo jednoduché škálovanie do šírky, shardovanie už z princípu (žiadne metadátové úzke hrdlo) a dobrý súlad s data loadermi založenými na shardoch. Čoho sa vzdáte: latencia je v desiatkach ms na operáciu (nie v mikrosekundách), chýba priamy POSIX (buď prepíšete loader, alebo prijmete penalizáciu cez FUSE) a nie sú možné zápisy na mieste (objekty sú nemenné — pre checkpointy v poriadku, pre čokoľvek, čo sa mení, zle).

Architektúra, ktorá funguje v praxi: objektové úložisko ako trvalé, veľké a lacné dátové jazero; paralelný alebo NFS súborový systém ako rýchla pracovná množina pripravená pre aktuálny beh. Dataset žije v MinIO. Úloha si na začiatku pripraví relevantné shardy na BeeGFS alebo na lokálny NVMe scratch. Finálne checkpointy putujú späť do MinIO na archiváciu.

WekaIO a VAST — enterprise vrstva (v krátkosti)

WekaIO a VAST Data sú účelovo stavanou odpoveďou za enterprise ceny: extrémny metadátový výkon pri malých súboroch, veľmi vysoká agregovaná priepustnosť, natívne S3 aj POSIX, integrované vrstvenie, cesty GPU-direct. Dávajú vynikajúci zmysel pri klastroch so 100+ GPU, kde úložisko musí držať krok s výdavkami na GPU. Nie sú správnou voľbou pre server so 4 alebo 8 GPU ani pre klaster zo štyroch takých — cena úložiska by celej zostave dominovala. Uvádzame ich tu kvôli úprimnosti o hornom konci trhu, nie ako odporúčanie pre kupujúceho, pre ktorého je táto séria napísaná.

Prístupové vzory k datasetu a prečo na nich záleží

ML tréningu dominujú dva vzory. Vzor A — veľké shardy: datasety vopred zabalené do WebDataset tarballov, parquetu alebo LMDB, 100 MB až 10 GB na shard, čítané sekvenčne a premiešavané vo vnútri. V tomto je dobrý každý úložný systém. Vzor B — množstvo malých súborov: milióny JPEG/PNG/JSON súborov, jeden na vzorku, ktoré bombardujú metadátovú cestu. Toto trestá NFS, pri väčšom rozsahu bolí aj BeeGFS a je to dôvod, prečo existujú Weka a VAST.

Rozhodnutím s najväčšou pákou v tréningovom úložisku je presunúť vzor B do vzoru A. Ak sa Váš dataset skladá z malých súborov, pred tréningom ho prebaľte do shardov. Cenou je jeden predspracovací prechod; prínosom je, že postačovať začne ľubovoľný úložný systém. Videli sme pipeline, ktoré zrýchlili 3–5× bez akejkoľvek zmeny úložného hardvéru, len vďaka prebaleniu.

Ak prebaliť nemôžete — dataset sa neustále mení, framework naozaj vyžaduje súbor na každú vzorku — dimenzujte úložisko podľa metadátových IOPS, nie podľa priepustnosti. To Vás tlačí k BeeGFS s viacerými MDS cieľmi, k Weka/VAST alebo k Lustre s DNE.

Stratégia checkpointov — zapisovať rýchlo, zapisovať neskôr, zapisovať menej

Zápisy checkpointov sú najhorším možným vzorom: každý rank zapisuje súčasne, zápisy sú veľké a tréning čaká, kým sú dáta trvalo uložené. Naivný synchrónny checkpoint pri modeli so 100 B parametrami dokáže zastaviť tréning na desiatky minút.

Súčasnou najlepšou praxou je trojfázový prístup, natívne prítomný v torch.distributed.checkpoint (DCP) v PyTorchi, v NVIDIA NeMo a vo väčšine moderných frameworkov:

1. Každý rank zapíše svoj shard na lokálny NVMe scratch. Celková zápisová priepustnosť klastra je súčtom rýchlostí NVMe na jednotlivých uzloch (5–50 GB/s na uzol). Tréning sa odblokuje v priebehu sekúnd.
2. Asynchrónny proces na pozadí kopíruje dáta na zdieľané úložisko. Tréning už medzitým pokračuje.
3. Staršie checkpointy sa mažú alebo presúvajú do objektového úložiska podľa plánu. Posledné 2–3 nechajte na rýchlom úložisku, zvyšok do MinIO/Ceph.

Dôsledok: zdieľané úložisko nemusí pohltiť každý checkpoint plnou rýchlosťou. Musí len stihnúť prijať asynchrónnu kópiu bez toho, aby zaostalo za kadenciou. Pri modeli so 70 B parametrami a checkpointe každých 30 minút stačí trvalý zápis v nízkych jednotkách GB/s — hlboko v možnostiach schopného BeeGFS alebo dobrého NFS servera.

Chyba, ktorej sa treba vyhnúť: synchrónne, neshardované checkpointy zapisované priamo na NFS. V roku 2022 to bolo bežné. Dnes už nie. Ak to Vaša pipeline robí, oprava kódu checkpointov má väčšiu páku než upgrade úložiska.

Otázka uplinku klastra

Má úložná prevádzka zdieľať sieťovú fabric s tréningom, alebo dostane vlastnú?

Zdieľaná fabric je v poriadku pre klastre so 4–8 uzlami a asynchrónnym checkpointovaním; oddelená fabric sa oplatí nad 8 uzlov alebo pri silnom synchrónnom I/O.

Pri klastroch triedy Kentino so 4–8 uzlami je zdieľaná fabric v poriadku vtedy, keď sa používa asynchrónne checkpointovanie a úložný workload tvoria prevažne čítania — trvalé čítanie koexistuje s NCCL kolektívami bez vážnej ujmy. Oddelená fabric sa oplatí pri veľkom LLM tréningu s FSDP a vysokým stupňom TP/PP, pri silnej synchrónnej úložnej prevádzke alebo vtedy, keď rozpočet dovolí rezervu. Praktická predvoľba: zdieľaná 100 GbE do 8 uzlov so samostatnou úložnou VLAN ako mäkkou izoláciou.

Úprimné odporúčania podľa veľkosti

Väčšina zákazníkov Kentino skončí v druhom a treťom riadku. Zvyšok postavíme, ak si ho vyžiadate, ale povieme Vám, keď je predimenzovaný.

Čo sa pokazí

Poruchové stavy, ktoré sme videli, zoradené podľa toho, ako často udrú:

• Hladovanie metadát pri záťaži malými súbormi. Príznak: GPU na 30–50 %, sieť nevyťažená, CPU úložiska nevyťažené, každé open() pomalé. Riešenie: prebaliť do shardov alebo pridať MDS ciele.
• Synchrónne checkpointy zastavujúce tréning. Riešenie: asynchrónne shardované checkpointy (PyTorch DCP alebo NeMo).
• Jeden pomalý disk, ktorý potopí celý klaster. Umierajúce SSD nezlyhá čisto — len sa spomalí. Riešenie: monitorujte latenciu jednotlivých zariadení a alarmujte pri > 2× východiskovej hodnoty.
• Zahltenie page cache na úložnom uzle. Dataset sa nezmestí do RAM, každá epocha vytlačí tú predchádzajúcu. Riešenie: viac RAM.
• Nezapnutý nconnect na NFS klientoch. Predvolené jednostreamové NFS sa zastropuje hlboko pod rýchlosťou sieťovej karty. nconnect=8 alebo =16 dá na rovnakom hardvéri 4–8× vyššiu priepustnosť.
• MinIO vo veľkom bez ladenia erasure codingu. Predvoľby uprednostňujú trvanlivosť pred latenciou; latencia malých objektov tým trpí. Neprijímajte predvoľby slepo.

Nič z toho nie je exotické. Všetko je po prvom stretnutí predvídateľné.

Toto je súčasť Kentino Wiki, referenčnej série o AI výpočtoch, robotike a systémoch, ktoré ich spájajú. Pripomienky a opravy uvítame na info@kentino.com.