Úložiště pro clustery AI: NFS, BeeGFS, Lustre a otázka týkající se úložiště objektů

Sdílené úložiště je součástí distribuovaného trénovacího clusteru, o které nikdo nepřemýšlí, dokud se nestane důvodem, proč jsou GPU využity na 40 %. V tomto okamžiku je jeho nahrazení bolestivé – každý trénovací skript má zabudované předpoklady, každý kontrolní bod je ve formátu, který se může, ale nemusí čistě migrovat, a cluster je v produkčním prostředí. Správný čas na rozhodnutí o úložišti je předtím, než je druhý trénovací uzel nainstalován do racku.

Toto je úložná polovina řady K. Je to pohled kupujícího a architekta, nikoli návod pro správce systémů – cílem je s otevřenýma očima volat mezi NFS, BeeGFS, Lustre a objektovými úložišti a upřímně si uvědomit, které z nich většina zákazníků Kentina skutečně potřebuje.

Proč je sdílené úložiště tichým úzkým hrdlem

Jednouzlový trenér čte svou datovou sadu z lokálního NVMe a zapisuje kontrolní body na stejné místo. Není o čem diskutovat. V okamžiku, kdy se připojí druhý uzel, se změní dvě věci:

1. Každý uzel čte stejnou datovou sadu. Bajty jsou identické na každém workeru a musí být viditelné z každého uzlu.
2. Každý uzel zapisuje kontrolní body a sjednocení musí přežít. U FSDP nebo DeepSpeed ​​shardingu zapisuje každá rank do svého vlastního segmentu; u DDP ranky zapisují redundantně. V obou případech souborový systém zaznamenává velké zápisy každých několik minut až hodin.

Tyto přístupové vzorce jsou opačné. Přístup k datovým sadám je trvalý, sekvenční, s vysokou mírou čtení a tolerancí latence. Přístup k kontrolním bodům je nárazový, s velkými bloky, s vysokou mírou zápisu a trénovacími bloky. Úložný systém, který je dobrý v jednom, je často průměrný v druhém.

Navíc moderní datové sady strojového učení dělají ještě třetí věc: metadatové bouřeDatová sada o velikosti 50 milionů souborů JPEG o velikosti 4–12 KB představuje z pohledu souborového systému 50 milionů cyklů otevřít/status/číst/zavřít. Server metadat, nikoli datová cesta, se přeruší jako první. Proto odpověď „máme dostatek šířky pásma“ není dostatečná.

NFS – výchozí a vydrží déle, než si myslíte

NFS (NFSv3 nebo v4) je cesta nejmenšího odporu. Každá linuxová distribuce ho dodává, každý plánovač mu rozumí a „storage node“ je jen linuxová krabička s velkým množstvím disku, /etc/exports linku a rychlou síťovou kartu.

Co vám nabízí rozumně postavený NFS server:

• Jeden jmenný prostor připojený identicky na každém výpočetním uzlu.
• Slušná sekvenční propustnost čtení, zejména s nconnect na moderních jádrech (multiplexování jednoho připojení přes několik TCP spojení – strop jednoho streamu je už léta pryč).
• Provozně nudné. Chyby jsou dobře pochopeny, postupy obnovy jsou v každé knize o systémové administraci, která kdy byla napsána.

Čeho se vzdáte:

• Jeden server, jedno úzké hrdlo. Agregovaná propustnost clusteru je omezena na to, co dané zařízení obsluhuje.
• Zamykání a serializace metadat. Úlohy s malými soubory narážejí na limity metadat dříve než na limity šířky pásma.
• Žádné elegantní horizontální navýšení kapacity. Když je krabice plná, vytvoříte druhou s jiným bodem připojení a vaše skripty se o tom dozví.

Nespravedlivá pověst, kterou má NFS v kruzích HPC, pramení především ze starého limitu pro jedno připojení a problémů s metadaty u malých souborů. Pro trénování datových sad v rozsahu od 100 GB do 1–2 TB na 4–8 uzlech GPU je správně sestavený NFS server skutečně v pořádku. Viděli jsme zákazníky, kteří trénovali Qwen2.5-VL na datových sadách založených na NFS bez stížností.

NFS začíná bolet, když:

• Datové sady přesahují velikost ~2 TB a jejich náhodné ukládání způsobuje na serveru zahlcení mezipamětí.
• Více než ~8–12 výpočetních uzlů narazilo na stejnou pozici při zatížení.
• Pracovní zátěži dominují desítky milionů malých souborů.
• Velikost kontrolních bodů na úroveň přesahuje 50–100 GB souběžně zapsaných.

Pod všemi čtyřmi prahovými hodnotami je NFS téměř jistě správnou odpovědí a paralelní souborový systém je přehnaně komplikovaný.

BeeGFS — praktický střed

BeeGFS je paralelní souborový systém, který lidé ve skutečnosti nasazují, když NFS přestane stačit. Rozděluje data mezi více cíle úložiště (disky na více serverech) a cíle metadat (samostatné NVMe servery). Klienti vidí jeden jmenný prostor; čte a zapisuje stripe napříč cílovými úložišti paralelně.

Proč se objevuje ve středně velkých klastrech:

• Nastavení trvá dny, ne týdny. Zkušený linuxový inženýr zvládne instalaci dvou úložných uzlů a jednoho MDS za jedno odpoledne. Lustre v této lize nepatří.
• Agregovaná šířka pásma se lineárně škáluje s cílovými úložišti. Tři uzly na 100 GbE poskytují téměř trojnásobnou propustnost čtení oproti jednomu.
• Nativní RDMA na InfiniBand nebo RoCE – eliminuje režijní náklady TCP/IP.
• Otevřený zdrojový kód, žádná past s licencováním na TB. Komerční podpora od ThinkParQ je volitelná.

V čem je upřímně méně dobrý:

• Metadata pro úlohy s velmi mnoha malými soubory. Jeden MDS se stává úzkým hrdlem při dominanci souborů menších než 4 KB. Můžete přidat cíle metadat, ale architektura není tak agresivní jako Lustreho DNE.
• Žádné vestavěné vrstvení. Zvládejte horko/chlad sami.
• HA je přišroubované, ne nativní. Zrcadlení funguje, ale není tak transparentní jako převzetí služeb při selhání v Lustre.

Ideální místo: 4–32 trénovacích uzlů, 10–100 TB datové sady, soubory v rozsahu 1 MB až 1 GB. Kde se nachází většina víceuzlových projektů Kentina.

Základní nasazení BeeGFS pro cluster třídy Kentino se 4 uzly:

Trvalé agregované čtení do čtyř trenérů se obvykle pohybuje v rozmezí 30–60 GB/s, což stačí k napájení 32 GPU při většině tréninků vidění a LLM. Škálování se zastaví, když je server metadat nasycen – přidejte druhý cíl metadat nebo začněte uvažovat o Lustre.

Lesk – zlatý standard, skutečná složitost

Lustre provozuje úložnou vrstvu prakticky každého superpočítače z top 500, který potřebuje POSIX, a to škálovatelně na stovky petabajtů a celkovou propustnost několika TB/s. Architektura má tři role: MGS/MDS (správa + metadata), OSS (servery pro ukládání objektů uchovávající OST) a klienti. Klienti komunikují s MDS ohledně operací jmenného prostoru a poté komunikují přímo s OSS, který uchovává data – datová cesta zcela obchází server metadat. Toto oddělení je důvodem, proč Lustre škáluje, a DNE (Distributed Namespace) umožňuje horizontální škálování metadat.

Náklady jsou provozní: strmější křivka učení než u BeeGFS, přísné požadavky na jádro/ovladač, desítky ladicích knoflíků (výkon po vybalení obvykle neodpovídá tomu, co hardware dokáže nabídnout) a procedury obnovy, které vyžadují kompetentního inženýra pro ukládání dat.

Prahová hodnota, kde má Lustre smysl, je zhruba 16–32+ trénovacích uzlů nebo datových sad třídy PB. Pod touto hranicí BeeGFS saturuje síť dlouho předtím, než se projeví architektonické výhody Lustre. Sestava Kentina většinou nedosahuje prahové hodnoty – na požádání sestavíme cluster Lustre, ale nejdříve vám řekneme, že BeeGFS plus robustní MDS vám pomůže s 80 % cesty při 20 % provozní zátěže.

Objektové úložiště — MinIO a Ceph pro datová jezera ML

Výše uvedené paralelní souborové systémy jsou správné, když framework očekává soubory. Rostoucí podíl moderních ML pipelines je neočekává – datové sady existují jako objekty S3, zavaděč dat je stahuje přes HTTP a lokální souborový systém je dočasně schovaný.

MinIO je jednoúčelové úložiště objektů kompatibilní s S3. Distribuovaný režim běží na 4–32+ uzlech s mazacím kódem. Otevřený zdrojový kód, provozně jednodušší než jakýkoli paralelní souborový systém a moderní zavaděče dat (PyTorch s fsspec/s3fs, WebDataset, NVIDIA DALI) jej přečtou přímo.

ceph je širší – blok (RBD), soubor (CephFS), objekt (RGW) na stejné vrstvě RADOS. Ceph vyhrává, když chcete jeden úložný systém pro více úloh (virtuální počítače, sdílené soubory, objekty ML). Prohrává v provozní jednoduchosti – Ceph je systém, ke kterému se zavážete, s vlastním monitorováním, laděním a disciplínou na pohotovosti.

Co vám objektové úložiště pro ML nabízí: nízkou kapacitu (husté HDD uzly s erasure kódováním dávají čísla €/TB, kterých se flash paměť nedotkne), provozně jednoduché horizontální škálování, horizontálně horizontálně rozdělené prostředí (žádné úzké místo v metadatech) a dobrou shodu s datovými zavaděči založenými na horizontálně rozdělených oblastech. Čeho se vzdáte: latence desítek ms na operaci (ne mikrosekund), žádný přímý POSIX (přepište zavaděč nebo akceptujte penalizaci FUSE) a žádné zápisy na místě (objekty jsou neměnné – v pořádku pro kontrolní body, špatné pro cokoli, co mutuje).

Architektura, která funguje v praxi: objektové úložiště jako odolné, velké a levné datové jezero; paralelní nebo NFS souborový systém jako rychlá pracovní sada připravená pro aktuální běh. Datová sada se nachází v MinIO. Úloha při spuštění umístí relevantní shardy na BeeGFS nebo lokální NVMe scratch. Finální kontrolní body se odešlou zpět do MinIO k archivaci.

WekaIO a VAST — podniková úroveň (stručně)

WekaIO a VAST Data jsou účelovým řešením s ohledem na cenu podniků: extrémně malá metadata souborů, velmi vysoká agregovaná šířka pásma, nativní S3 a POSIX, integrované vrstvení, cesty GPU-direct. Tyto řešení dávají vynikající smysl pro clustery s více než 100 GPU, kde úložiště musí držet krok s výdaji na GPU. Nejsou to správná volba pro server se 4 nebo 8 GPU, ani pro cluster čtyř takových – náklady na úložiště by dominovaly sestavení. Zmíněno zde pro upřímnost ohledně high-end řešení, nikoli jako doporučení pro kupujícího, pro kterého je tato série napsána.

Vzory přístupu k datovým sadám a proč jsou důležité

V ML školení dominují dva vzorce. Vzor A – velké střepy: datové sady předem zabalené do tarballů WebDataset, Parquet nebo LMDB, 100 MB až 10 GB na shard, sekvenčně čtené a uvnitř promíchané. Každý úložný systém je v tom dobrý. Vzor B – mnoho malých souborů: Miliony souborů JPEG/PNG/JSON, jeden na vzorek, což zatěžuje cestu k metadatům. To trestá NFS, ve velkém měřítku poškozuje BeeGFS a je to důvod, proč existují Weka a VAST.

Jediným nejvýznamnějším rozhodnutím v oblasti úložiště pro trénink je přesun vzoru B do vzoru A. Pokud se vaše datová sada skládá z malých souborů, před trénováním je znovu zabalte do fragmentů. Nákladem je jeden průchod předběžného zpracování; výhodou je, že jakýkoli úložný systém se stane dostačujícím. Viděli jsme zrychlení datových kanálů 3–5× bez změny hardwaru úložiště, pouhým opětovným zabalením.

Pokud nelze datasety přebalit – datasety se neustále mutují, framework skutečně vyžaduje soubory pro každý vzorek – velikost úložiště se rovná počtu IOPS metadat, nikoli šířce pásma. To vás posouvá spíše k BeeGFS s více cíli MDS, Weka/VAST nebo Lustre s DNE.

Strategie kontrolních bodů – pište rychle, pište později, pište méně

Zápisy v kontrolních bodech představují nejhorší možný vzorec: každá hodnost zapisuje současně, zápisy jsou velké, trénovací bloky trvají až do doby trvání. Naivní synchronní kontrolní bod na modelu se 100 B parametry může trénování zastavit o desítky minut.

Současným osvědčeným postupem je třístupňový přístup, nativní v PyTorchu. torch.distributed.checkpoint (DCP), NVIDIA NeMo a většina moderních frameworků:

1. Každá hodnost zapíše svůj shard na lokální NVMe scratch. Celková šířka pásma zápisu clusteru je součtem rychlostí NVMe na uzel (5–50 GB/s na uzel). Trénink odblokuje systém během několika sekund.
2. Asynchronní proces na pozadí kopíruje data do sdíleného úložiště. Trénink byl mezitím obnoven.
3. Starší kontrolní body jsou odstraněny nebo přesunuty do úložiště objektů. podle plánu. Poslední 2–3 nechte na rychlém úložišti, zbytek na MinIO/Ceph.

Důsledek: Sdílené úložiště nemusí absorbovat každý kontrolní bod plnou rychlostí. Potřebuje asynchronní kopii přijmout, aniž by zaostával za kadencí. Pro model s 70 B a kontrolním bodováním každých 30 minut stačí nízká trvalá rychlost zápisu v řádu jednociferných GB/s – v rámci kompetentního BeeGFS nebo dobrého NFS serveru.

Chyba, které se vyvarovat: synchronní, nehardované kontrolní body zapisované přímo do NFS. To bylo v roce 2022 normální. Dnes už to tak není. Pokud to váš pipeline dělá, oprava kontrolního kódu má větší vliv než upgrade úložiště.

Otázka uplinku clusteru

Sdílí úložný provoz strukturu s tréninkem, nebo ji využívá samostatně?

Sdílená struktura fabric je vhodná pro clustery se 4–8 uzly s asynchronními kontrolními body; rozdělená struktura fabric je oprávněná pro clustery nad 8 uzly nebo pro náročné synchronní I/O.

Pro clustery třídy Kentino se 4–8 uzly je sdílená struktura fabric v pořádku, když se používá asynchronní kontrolní bodování a úloha úložiště je převážně čtení – trvalé čtení koexistuje s kolektivy NCCL bez vážného poškození. Dělená struktura fabric je opodstatněná pro rozsáhlé trénování LLM s FSDP při vysokém stupni TP/PP, silném synchronním provozu úložiště nebo když to rozpočet dovolí. Praktická výchozí hodnota: sdílená 100 GbE až 8 uzlů s úložnou VLAN jako měkkou izolací.

Upřímná doporučení podle rozsahu

Většina zákazníků Kentina skončí ve druhé a třetí řadě. Zbytek vyrobíme na vaši žádost, ale řekneme vám, kdy je nadstandardní.

Co se láme

Způsoby selhání, které jsme pozorovali, seřazené podle četnosti kousání:

• Hladovění metadat při načítání malých souborů. Příznak: Vytížení grafických karet 30–50 %, nečinnost sítě, nečinnost úložiště CPU, každý open() pomalé. Oprava: přebalit do shardů nebo škálovat cíle MDS.
• Synchronní kontrolní body brzdí výcvik. Oprava: asynchronní shardované kontrolní body (PyTorch DCP nebo NeMo).
• Jeden pomalý disk ničí cluster. Selhávající SSD disk neselže čistě – jen se zpomalí. Oprava: monitorujte latenci jednotlivých zařízení, alarm při > 2× základní hodnota.
• Došlo k narušení mezipaměti stránek na úložném uzlu. Datová sada se nevejde do RAM, každá epocha vytlačí tu předchozí. Oprava: více RAM.
• nconnect není povoleno na klientech NFS. Výchozí omezení NFS pro jeden stream je hluboko pod hranicí rychlosti síťové karty. nconnect=8 or =16 poskytuje 4–8× propustnost na stejném hardwaru.
• MinIO ve velkém měřítku bez ladění EC. Výchozí nastavení upřednostňují odolnost před latencí; latence malých objektů trpí. Nepřijímejte výchozí nastavení slepě.

Nic z toho není exotické. Všechny jsou předvídatelné, jakmile je jednou vidíte.

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.