Motivácia na nákup nového výpočtového servera
V priebehu minulého roka sa k nám občas dostali otázky, či poskytujeme v rámci fakultnej výpočtovej infraštruktúry možnosť počítania na grafických kartách. Tie sme museli odmietať, keďže náš výpočtový server Aura (a ani iný) nemal GPU. Alternatívami mohli byť CVT stroje v B311 s Windows majúce grafickú kartu Nvidia GeForce GTX 1070 alebo potom presmerovanie záujemcov buď na ústretovosť laboratórií, ktoré dedikované výpočtové GPU uzly už nejaké chvíľu majú (napríklad CBIA a NLP), alebo na Metacentrum, pokiaľ ide o zámerom dostatočne odôvodnenú výpočtovú prácu.
Ďalším signálom toho, že server Aura začína v niektorých typoch úloh zaostávať, bola požiadavka na podporu inštrukcií CPU, ktoré prišli až s novšími generáciami procesorov a na CPU Aury ešte nie sú – konkrétne šlo o inštrukcie AVX vyžadované pythonovským modulom TensorFlow.
Historickým problémom, na ktorý sme u tohto železa kedysi narazili, ale už ho máme nejakú dobu vyriešený, bola tiež jeho možnosť bootovať len z diskov využívajúcich diskový radič, ktorý vyžadoval použitie hardvérového RAIDu. Tomu sa snažíme vždy vyhýbať a používať softvérový RAID – totiž v momente, keď by ste o ten hardvérový radič (alebo o základnú dosku servera, ak by funkciu hardvérového RAIDu poskytovala priamo ona) prišli, mohli by ste mať problém dostať sa k dátam (to môže byť problém i v prípade zálohovania), keďže hardvérový RAID je obvykle riešený proprietárne a každý môže mať iný spôsob ukladania metadát. A tiež musíte mat dedikované nástroje na monitoring RAIDu a prípadných problémov s ním, ktorých podpora môže byť v linuxových distribúciách horšia. Problém sa nám nakoniec podarilo vyriešiť tak, že sme v konfigurácii firmvéru vytvorili z každého disku RAID 0 s jediným diskom (skutočný RAID sme definovali až na softvérovej úrovni), čím sme pre naše praktické účely dosiahli (nami pri nákupoch štandardne vyžadovanú) konfiguráciu JBOD – v tú chvíľu je totiž prípadná strata metadát/dát nepodstatná.
No a záverom, s nákupom Aisy a Anxura (2017) sme sa dostali množstvom jej dostupnej pamäte (512 GB) i počtom jadier (64) na úroveň výpočtového servera, čo bol takisto určitý signál ohľadne vhodnosti zadováženia nového výpočtového uzla. Nehovoriac o tom, že server Aura je už mimo záruky, hoci nám jeho hardvér zatiaľ funguje dlhodobo spoľahlivo.
Pôvodný server Aura
História tohto železa siaha skutočne do minulosti, dokonca takej, ktorej autor tohto článku priamym účastníkom nebol. Išlo o nákup výpočtového servera z roku 2010, ktorý bol spoločne financovaný CVT a laboratóriom Paradise s rozpočtom cca 1,7 milióna Kč (po zohľadnení inflácie 2,1 milióna Kč). Na tú dobu išlo o skutočne úctyhodný hardvér od HP (dnes HPE) postavený na platforme ProLiant DL980 7. generácie (viď prehľad a špecifikáciu) s výškou 8 U. Osadený je ôsmimi osemjadrovými procesormi Intel Xeon X7560 s taktom 2,26 GHz a 448 GiB RAM typu DDR3.
Dodatočne sme ju ešte rozširovali o diskové pole a disky, ktoré sa stali základom väčšieho fyzického úložiska pre /var/tmp.
Pôvodný server má ešte jednu zaujímavosť. Je vybavený malým displejom, nazývaným System Insights Display, na ktorom je možné po jeho nakonfigurovaní zobrazovať veľmi jednoduché prehľadové stavové informácie o aktuálnej činnosti na stroji:
Auru sme však napriek nejakým nevýhodám popisovaným vyššie úplne z prevádzky nevyradili. Rolu výpočtového servera sme jej zachovali, pod novým názvom Adonis a zároveň sme na nej otvorili prístup pre všetkých študentov (pôvodne mala Aura prístup len pre zamestnancov, dohodárov, doktorských študentov a pre osoby explicitne pridané zamestnancami). Výpočtové dáta vo /var/tmp sme nepresúvali a zachovali sme ich na starom serveri (hlavne z dôvodu menšieho, ale rýchlejšieho úložiska), takže ich prípadný presun na nový server je na ich vlastníkoch.
Nový server Aura
Hlavnými cieľmi pri nákupe servera boli zvýšenie kapacity (a zrýchlenie) fyzickej pamäte, zvýšenie počtu CPU jadier, výrazné zrýchlenie diskového úložiska a už zmieňované doplnenie GPU.
Nový server je postavený na základnej doske od ASUSu a je osadený dvomi 64-jadrovými AMD EPYC 7713 2.0 GHz (patrí medzi najvýkonnejšie dostupné CPU od AMD), 2 TB RAM typu DDR4 a dvomi GPU kartami Nvidia A100 v PCIe verzii s 80 GB GPU RAM (vrátane ich prepojenia cez NVLink).
V porovnaní s pôvodnou Aurou má teda vyše štvornásobnú kapacitu pamäte, štvornásobný počet vlákien, takmer trojnásobne rýchlejšiu RAM a z pohľadu IOPS radikálne rýchlejšie úložisko v dôsledku prechodu z rotačných diskov na NVMe solid-state disky, viď porovnanie parametrov:
| Parameter |
Adonis |
Aura |
| Počet vlákien CPU |
64 |
256 |
| Takt CPU |
2,26 GHz |
2,0 GHz |
| Kapacita RAM |
440 GiB |
2000 GiB |
| Rychlost RAM |
1066 MT/s |
2933 MT/s |
| Typ/pripojenie úložiska* |
HDD/SAS |
SSD/NVMe |
| Kapacita úložiska* |
8 TB |
4 TB |
| Rýchlosť úložiska* |
175 MBps |
6,9/4 GBps, 1,4/0,35 MIOPS |
| Efektívna rýchlosť úložiska** |
1,6 GBps |
13,8 GBps |
* – Ide o nominálne parametre diskov hlavného lokálneho úložiska /var/tmp určeného pre výpočty.
** – Ide o maximálnu reálne dosiahnutú rýchlosť sekvenčného čítania pomocou nástroja fio nad úložiskom /var/tmp. Použitým príkazom bolo fio --filename=/var/tmp/test --direct=1 --rw=read --bs=64M --size=1G --ioengine=libaio --iodepth=256 --runtime=10 --numjobs=1 --name=read-test --time_based --readonly (zdroj inšpirácie). V prípade Aury to vychádza na 100-percentnú saturáciu možností diskov a 86-percentnú saturáciu možností použitej zbernice PCIe (4.0 x4). Zaujímavosťou je, že pri testovaní rýchlosti čítania priamo z blokového zariadenia logical volume sa nám podarilo dosiahnuť saturáciu len 91 % a pri zbežných pokusoch o určenie rýchlosti čítania zo súboru v /tmp (nad tmpfs, t.j. dáta sú v RAM) sme dosiahli len rýchlosti okolo 6 GBps.
GPU
Význačnou vlastnosťou nového výpočtového servera je možnosť výpočtov na GPU. Pre tieto účely sme sa, po konzultáciách s CBIA, rozhodli pre v tej dobe (šlo o február 2021) state-of-art model A100 postavený na mikroarchitektúre Ampere. Motiváciou bolo i to, že vývoj GPU rýchlo napreduje, o čom sme sa bohužiaľ presvedčili i pri písaní tohto článku – v marci 2022 bola totiž na trh uvedená nová generácia Hooper s modelom H100 a my sme tu už nemohli použiť výraz state-of-art bez upresnenia…
Nvidia vydáva dve prevedenia kariet GPU: verzie s PCIe zbernicou, ktoré idú bežne použiť v obvyklom serveri rackového prevedenia, alebo verzie SXM, ktoré obsahujú niekoľko uzlov GPU na špecializovanej karte (v prípade A100 existujú varianty so 4 a 8 uzlami). Verzie SXM však neumožňujú zapojenie do bežného serveru a nepredávajú sa samostatne – sú dodávané len ako súčasť serverov v prevedení tower a z hľadiska počtu kusov a od toho odvíjajúcej sa ceny sme v plánovanom rozpočte uvažovali len o dvoch uzloch GPU. Preto sme smerovali k verzii PCIe. To nám teda mierne zneisťovalo nákup, pretože v čase jeho plánovania a písania špecifikácií bola na trhu k dispozícii len verzia SXM (Nvidia vydáva PCIe verzie modelov až s odstupom po vydaní SXM), ale tesne pred vyhlásením súťaže v júli prišiel oznam, že bude dostupná i verzia PCIe a tým sa napäté čakanie skončilo.
Proces nákupu chvíľu trval, ale nakoniec sme sa serverov vrátane novej Aury dočkali v novembri 2021 s vysúťaženou cenou 1,1 milióna Kč. Následne sme v rámci pár mesiacov priebežne pracovali na inštalácii servera, ktorej významnú časť tvoril prieskum administratívnych možností/rozhodnutí ohľadne GPU. Tie sa pokúsime v tomto článku pre zaujímavosť stručne priblížiť.
MIG
Jednou z možností, ktoré poskytujú GPU od generácie Ampere, je rozdelenie karty na niekoľko úplne nezávislých výpočtových jednotiek pomocou technológie Multi-instance GPU. Pri výpočtoch GPU sa totiž často nedá spoliehať na to, že počítajúci bude (schopný) obmedzovať množstvo prostriedkov, ktoré jeho výpočet využije (a z nášho pohľadu musíme predpokladať, že takýto prípad bude občas nastávať a musíme naň byť pripravení), takže možnosť využiť MIG bola pre nás vítanou vlastnosťou. Vďaka nej môžeme z dvoch výpočtových kariet spraviť niekoľko virtuálnych inštancií s menšími (ale stále dosť vysokými!) parametrami (na výber je necelá desiatka možných konfigurácií), kde sa používatelia nebudú ovplyvňovať. Výpočty na GPU totiž typicky využijú všetky dostupné prostriedky a konfigurácia limitov v jednotlivých nástrojoch nie je vždy priamočiara a nechceme sa spoliehať na to, že používatelia to budú korektne nastavovať.
Ako aktuálne rozdelenie sme zvolili rozdelenie na štyri inštancie zhruba zodpovedajúce 1 GPU, 0,5 GPU, 0,25 GPU a 0,25 GPU. Na základe požiadaviek budeme následne schopní v prípade potreby operatívne meniť konfiguráciu inštancií (je možné realizovať bez reštartu servera) tak, aby sme uspokojili prípadné iné požiadavky.
MPS
Ďalšou technológiou, ktorú sme zvažovali využiť, je Multi-Process Service (MPS). Táto technológia umožňuje férovejšie využitie výpočtových prostriedkov v prípade, že GPU/inštanciu využíva viacero procesov súčasne. V takomto prípade sa výpočtové procesy nepripájajú priamo na GPU (typicky by v takom prípade využili všetky dostupné prostriedky), ale komunikujú s ním pomocou MPS, čo zabezpečí rovnomernejšie využitie výpočtového výkonu.
Problémom však je, že MPS je single-user technológia a nemôže ju využívať viacero používateľských účtov súčasne. V našom kontexte teda nedáva zmysel mať ju spustenú a je prípadne len na samotnom používateľovi, či po nej v prípade vhodných okolností siahne.
Ovládače a knižnice
Dôležitými súčasťami výpočtového prostredia sú ovládače GPU a knižnice CUDA. Z hľadiska ovládačov sme sa snažili spríjemniť prácu vďaka ich perzistencii. Normálne totiž dochádza k transparentnému načítaniu ovládačov a s tým spojenej inicializácii GPU až pri pokuse o použitie GPU. To má mať podľa dokumentácie za následok niekoľkosekundové zdržanie, ale podľa našich pozorovaní išlo občas o zdržanie aj niekoľko desiatok sekúnd. Vďaka perzistencii sú ovládače a GPU stále v aktívnom stave (aj keď ich aktuálne nepoužíva žiadny proces) a teda i spúšťanie úloh je oveľa responzívnejšie.
Čo sa týka knižnice CUDA, jej požadovaná verzia môže byť závislou na frameworku, ktorý využíva API CUDA. K dispozícii máme teda dve verzie: najnovšiu 11.6 a 10.
Softvérové vybavenie
Ohľadne softvéru sme sa snažili uviesť novú Auru trochu do čistejšieho stavu a tie systémové balíčky, ktoré tam boli (často už i veľmi dávno) nainštalované na žiadosť používateľov, sme automaticky neinštalovali, aby sme sa zbavili historizmov. Ak by ste však našli niečo, čo vám tam chýba (alebo vyslovene zmizlo), posúďte možnosti inštalácie softvéru (alebo nám napíšte na unix@fi).
Doplnili sme tam však (cez pip) nástroje TensorFlow a PyTorch, čo sú zrejme najtypickejší predstavitelia nástrojov na prácu s GPU, a tiež nástroj nvitop na sledovanie využitia GPU. Pokiaľ by ste mali návrh na nejaký všeobecne užitočný nástroj/knižnicu, ktoré by bolo vhodné doplniť, budeme radi za návrh.
Rôzne
Cgroups v2: Na oboch výpočtových serveroch sme zapli cgroups verzie 2. Ich výhodou je, že je možné priamočiarejšie obmedzovať množstvo využitej pamäte, čo s doterajšími cgroups verzie 1 možné nebolo a bolo nutné v prípade potreby používať ulimit, čo nie je na tieto účely vždy vhodné. Pre popis a príklad použitia viď sekciu Omezení paměti pomocí systemd v dokumentácii Aury.
Privítanie pri prvom prihlásení: S prechodom na novú Auru sme začali pri prvom prihlásení zobrazovať veľmi stručné info o novom serveri a upozornenie na pravidlá výpočtov. (Viď /etc/profile.d/first_login.sh.)
Dočasné úložisko Aury nad tmpfs: Dáta v dočasnom úložisku /tmp na novej Aure (neplatí pre Adonis) sme prestali ukladať na disk a zmenili sme ho na tmpfs, ktorý je umiestnený v RAM a je teda výrazne rýchlejší.
