Je už čas na Raspberry Pi cluster?

Před pár týdny jsem objevil Youtube kanál Jeffa Geerlinga, vyšlo na něm motivační video a ta myšlenka mi nedá spát. Navíc dnes je k disposici RPi4 s 8GB RAM. Nastal čas si postavit a postupně rozšiřovat Raspberry Pi cluster? Jaké to má výhody a jaké nevýhody? Pojďme se na to podívat.

Výchozí stav a zkušenosti

Doma provozuji dva domácí servříky. Jeden na Linuxu, druhý na FreeBSD. Jsou to moje staré desktopové desky ve velké bedně. Každý komp má 32GB paměti a 6HDD (většinou již 4TB). Jeden je AMD FX-8350, druhý je Intel-5.

Dle množství disků lze jistě vydedukovat, že primárním účelem je uložení dat, lidově řečeno NAS. Ano, to je pravda, ale pouze z části. Rád se hrabu v různých FS, zkouším různá nastavení storage, btrfs, zfs, mdadm apod. Pro mé čtenáře jistě nic nového. Poskytování samba a NFS share je pouze malou součástí služeb.

Na obou strojích mi běží několik kontejnerů. Na linuxu používám nspawn, na freebsd jaily. V kontejnerech mi běží věci jako mx server, dns server, Gitea pro správu repositářů, BackupPC pro zálohování, weby, databáze vývojové, databáze pro mé výtvory a tak dále. Celkem 18 jednoúčelových kontejnerů. Jejich počet se neustále mění, udělat nový kontejner pro odzkoušení něčeho nového je otázkou pár minut.

Mám to poloautomatizované pomocí ansible. Zatím nemám a ani vlastně nechci mít vyřešen celý životní cyklus kontejneru pomocí ansible – rád se dotýkám toho co dělám, rád píšu příkazy na terminál, rád si napíšu btrfs sub snap template new_machine a tak dále. Něco chci mít manuální. Každopádně, naspawnovat nový stroj a pustit na něm ansible pro konfiguraci dle nějakých rolí je otázka minut.

Výhody stávajícího řešení

• Vysoký výkon CPU – tohle je relativní, ale 8x core FX8350 není stále vůbec k zahození. Kompilace čehokoliv je na počkání. Pro běžně zpracovávaná data je to OK. FFmpeg pro překódování videa lze dát do fronty. Stejně to nepotřebuju hned (a pokud ano, pustím to na desktopu).
• Vysoký diskový výkon – 600MB/s na ZFS nad 6xHDD. Potřebu nízké latence pro databáze lze řešit na systémovém SSD (malá kapacita, vysoké IOPS).
• Velká dostupná paměť – 32GB není až tak moc, ale je to k disposici libovolnému procesu – toto bude zásadní rozdíl u clusteru nad RPi.
• Je to pc amd64 architektura (x86-64).

Nevýhody stávajícího řešení

• Prakticky nulová redundance. Kdyby mi teď chcípl FreeBSD server, bude jej těžké rychle nahradit (s cenou a dostupností komponent). Byl by to zkrátka problém.
• Velká spotřeba. Linux server jsem vypnul, u FreeBSD přemýšlím. Provoz jednoho desktopového serveru je cca 400Kč měsíčně. Příkon kolem 120W. Některé služby jsem přesunul na hosting v Německu. Cena 3EUR měsíčně (75Kč, jako náhrada za 400Kč). V minulém článku jsem popsal další možnosti úspory a využití energie.

Cluster nad Raspberry Pi

O tomhle se ví roky, spousta lidí si to staví. Já měl několik zásadních výhrad:

• Malá kapacita RAM. Na 1GB se toho moc nevleze. Proces vyžadující více paměti zde prostě není možné spustit.
• Divné síťové připojení – síťovka na interní USB sběrnici, sdílená s ostatními zařízeními.
• Pomalé CPU.
• Nepřítomnost SATA konektoru, praktická nemožnost připojit disk.

Tohle se postupně mění. Pro mě je gamechanger Rpi4 s 8GB RAM. Na 8GB lze pustit už i náročný proces zpracovávající hodně dat. Už to není jen 1GB, kde fakt nevím, co chcete provozovat (ale nesoudím). Paměť máme vyřešenu.

Výkon CPU. Tohle vždy bude záležet na typu úlohy. Já od serveru tohoto typu neočekávám výsledek hned. I pro ty PC jsem si napsal jednoduchou frontu, kam strčím třeba 5000 jobů a ono si to jede vlastním tempem, protože jeden ten job běží i minuty. Na 8 jádře potom 8 současně. Stejně to jede přes noc. Tohle se u Rpi clusteru nemění. Výkon jednoho jádra není oslňující, ale pokud jich bude k disposici 24 (6x rpi) nebo 48? To už je jiná, že jo. A díky velikosti paměti se klidně 4 procesy na jedno rpi vlezou. 2GB RAM per tento proces je ok. CPU máme vyřešeno.

Síťovka už je normální 1GbE. Síťování máme vyřešeno.

Připojení disků. Stále problém, stále nemáme sata. Už máme konečně USB-3, ale pro dlouhodobé připojení disků to není úplně vhodné. Tohle je potřeba dořešit.

Architektura aarch64. Nevidím problém, v repositářích je vše potřebné. Golang lze přeložit pro aarch64. Vyřešeno.

Řízení clusteru

Tady vidím příležitost se naučit něco nového. Vytváření jednotlivých kontejnerů (typu nspawn, případně jiné technologie, i té, kterou nemám rád) pomocí ansible je vyřešeno, ansible používám pár let. Ale jak řídit 6 nebo 12 node? Ano, šlo by si na to napsat ansible playbooky a dělat to poloautomaticky. Ale to neřeší automatické nasazení, balancing kontejnerů napříč clusterem apod. Tady si nechám poradit (Kubernetes?).

Návrh, výhody a nevýhody

Dospěl jsem k následujícímu návrhu:

• Na počátku 4 nebo 6 strojů. Cena přijatelná, redundance velmi dobrá. Snadná možnost postupného rozšíření až na cílových 12.
• Proč 12 – mám 12 datových disků. Představa je mít u každého rpi jeden datový disk. Každý node by měl k disposici vlastní disk. Jednak pro svoje interní data a druhak jako share pro sdílení souborů.
• Na strojích by běželo x kontejnerů pro různé činnosti.

Výhody

• Obrovská redundance. Při výpadku jedné desky z třeba z osmi se nic neděje. Její kontejnery se spustí někde jinde. Náhrada takové desky je potom jednoduchá a není potřeba na ní nijak zvlášť spěchat. Jen se tím sníží výkon clusteru. Čím více bude strojů, tím menší problém to bude.
• Snadné rozšiřování v čase. Není třeba vše pořídit hned. Stejně tak výměna za nový model bude rozložena v čase. Klidně dvě desky za rok. Dle situace.
• Obrovský (relativně) celkový výkon. 12 strojů poskytuje 48 arm cores, 96GB paměti, 12 disků. Jobů ke zpracování mám hodně (tísíce každý týden), každý z nich jede pár minut. Tady se masivní paralelizace vyloženě nabízí. Fronta pro spouštění jobů je již vyřešená. Vlastní řešení v golangu + postgresql jako centrální db. Zatím to není OSS, dělám na tom (tj. tak, když to není open hned od počátku a zpětně řešíte nepořádek v modulech, konečně mě k tomu golang dokopal). Je to jednoduchá atomická fronta postavená kolem SELECT FOR UPDATE SKIP LOCKED.
• Malá velikost – lze mít hodně krabiček klidně jen na polici.
• Malá spotřeba.

Nevýhody a nevyřešené věci

• Nedořešené napojení disků a vůbec problematika storage. Exportovat 12x samba share sice jde, ale není to moc uživatelsky přívětivé. Tady by to chtělo najít cluster storage s nějakou redundancí (ne vyloženě celé kopie, ale něco jako raid-6 – 10 disků, 2 paritní, s možností dynamické změny počtu strojů).
• Malá paměť pro jeden proces. 96GB RAM celého clusteru je krásné číslo, ale pro jeden proces je k disposici maximálně 8GB. Občas narazím i na strop 32GB. S tímto je potřeba počítat a hold některé věci dělat jen na desktopu.
• Malý výkon pro jeden proces. Je to prostě RPi, že jo. ARM 4 jádra. Na drtivou většinu věcí dobrý, ale na render komplexní scény v POV-Ray nebo konverze videa ffmpeg do h265 to asi není.

Fyzický vzhled příliš neřeším. V první iteraci to bude prostě položené na poličce. Není to žádný problém. Borec z odkazovaného videa řešil estetický vjem a řešil i takové drobnosti jako nevzhledné externí napájení – lze řešit POE switchem. Mě tohle opravdu netrápí. Tohle se bude řešit až ve chvíli, kdy se to ukáže jako života schopné.

Prosím diskutujte

Máte s tímto zkušenosti? Provozujete něco takového, ať již jen pro zábavu, nebo jako zcela vážně provozovanou věc? Jak to spravujete? Máte automatické řízení rozložení zátěže? Automatické spuštění kontejnerů v případě výpadku uzlu? Je to života schopné řešení? Stačí výkon a dostupná paměť? Spousta otázek. :-)