Autonomní diskless

Autonomní diskless, je koncept, který dál rozvíjí mou původní koncepci disklessového linuxu zaváděného přes Wi-Fi, implementovanou v roce 2019. Vymyšlen byl již před dvěma lety, ale realizaci překazil návrat k prezenční výuce po vynucené kovidové přestávce, který sebou přinesl úkoly s vyšší prioritou.

Co si představit pod pojmem autonomní diskless?

Na internetu jsem narazil v souvislosti s autonomním provozem počítačových subsystémů na článek s názvem Autonomy, Local Autonomy, and Coherence in Naming in Distributed Computer Systems, kde se mimo jiné píše:

„Subsystém nemusí být schopen nebo nemusí chtít dosáhnout úplné autonomie. Například bezdisková pracovní stanice má potenciálně menší autonomii než pracovní stanice s diskem.”

Ano, je to tak. Bezdisková pracovní stanice je vždy závislá na síťové konektivitě. A to byl problém, který bylo potřeba vyřešit.

Diskless linux přes Wi-Fi, s využitím lokálního sedviče fungoval pěkně, ale měl jednu velkou slabinu – pomalé a nespolehlivé připojení přes Wi-Fi.

Technické řešení tohoto problému jsem měl již od vánoc 2015, kdy po Praze jezdila speciální mazací tramvaj, která měla na korbě umístěn vánoční stromeček, vybavený řetězem LED RGB svíček, které mohli okolojdoucí rozsvěcet prostřednictvím on-line aplikace. Aplikace komunikovala s linuxovým systémem, který běžel na Raspberry Pi a řídil světelný řetěz. Mělo to ale háček – vše, včetně lokální wifi napájela ta tramvaj a když stála na konečné, byla vypnutá a bez proudu.

Bylo tedy potřeba zajistit, aby se automaticky po nahození proudu realizovaly následující kroky:

1. Nahození lokální wifi – tady mohlo trvat, než získalo vnější konektivitu AP na tramvaji
2. Nahození VPN klienta – aby mohla aplikace co běžela na serveru ve vnitřní síti ČVUT komunikovat s krabičkou na tramvaji.

U turtlebotů bylo potřeba zajistit pouze první krok. Jenže se objevili studenti a s nimi hned několik problémů, co by se projevily dřív, pokud by během kovidu s turtleboty někdo pracoval. Příčin bylo více:

1, Nevhodný styl práce s turtlebotem

Pokud student pracoval s turtlebotem tak, že posílal po síti zkompilovaná data na disklessového lokálního uživatele guest, bylo vše ok. Ovšem jakmile použil k přihlášení svůj uživatelský účet, komunikace přes NFS s centrálním úložištěm kde byl jeho uživatelský adresář spojení s turtlebotem totálně ubila.

2, Nevyvíjená aplikace mcachefs

Tahle aplikace měla jednu zásadní vadu v návrhu – nepodporovala atomické změny. Zřejmě to bylo důvodem proč ji dále nikdo nevyvíjel. Ale to nebyl jediný problém této aplikace, kterou nahradil jaderný modul bcache. Jenže ten zas má jiný problém a to, že se snaží fungovat jako souborový systém. Což u normálního systému nevadí, ale u disklessu ano.

Jako první se projevil problém spojený s kešováním souborů sdílených přes NFS a protože během výuky už nebylo možné něco zásadně měnit, bylo kešování vypnuto. Jenže tím výrazně stouply nároky na konektivitu, což při nevhodném stylu práce s turtlebotem vyvolávalo nežádoucí latence.

Efektivita disklessu ke totiž závislá na stabilní a rychlé konektivitě s vysokou propustností, což u mobilního připojení jako je např. WiFi nelze nikdy zcela zajistit.

Kromě toho má disklessový laboratorní systém slabinu, která se začala projevovat až při jeho využití 24/7. Při instalaci software, do vrstvy která se aktivně používá, hrozí, že dojde ke kolapsu všech systémů které s ní pracují, pokud na straně NFS serveru přestane existovat, nebo je nahrazen jinou verzí soubor či adresář se kterým pracují. Jediné řešení takové situace přináší vynucený restart. Jenže u stroje, kde přestane fungovat ověřování vůči LDAPu či AD to na dálku neuděláte.

V minulosti, kdy se s laboratorním disklessem pracovalo jen prezenčně, se to stávalo jen výjimečně. Ale narůstající počet studentů a možnost vzdáleného přístupu do počítačových laboratoří vedl k tomu že se v současné době jen těžko hledá časové okno, kdy se dají dělat aktualizace.

Proto je potřeba jít jinou cestou.

Lokální autonomie

Již zmíněný článek z roku 1988 pracuje s pojmem lokální autonomie (Local Autonomy) a specifikuje okolnosti, za jakých lze o ní hovořit:

Subsystém má lokální autonomii, pokud

• může lokálně spravovat své lokální objekty a
• může provádět operace se svými lokálními objekty nezávisle na zbytku systému.

Aby mohly být tyto podmínky u disklessu splněny, musí mít k dispozici všechny sdílené soubory. Ovšem jak to zajistit a zároveň minimalizovat množství dat přenášené po síti?

Problém mobilní konektivity

Pro subsystém s mobilní konektivitou je typické, že se mění trasa jeho internetového připojení podle toho, kde se zrovna pohybuje. A pokud se pohybuje v místech kde připojení není musí fungovat dokud nedojde k jeho obnovení.

Autonomie u notebooků či mobilních telefonů byla v průběhu let vyřešena tím, že se do nich nainstaluje operační systém, který v případě výpadku mobilního připojení průběžně pokouší konektivitu obnovit.

Jenže disklessový systém má všechna data v RAM, do které si natahuje soubory podle potřeby a v případě Turtlebotů má nainstalován pouze zavaděč, který po restartu natáhne nakešované jádro s ramdiskem, ve kterém má konfiguraci pro nahození WiFi. Adresu získá až z DHCP na základě MAC adresy.

A problém spočívá v tom, že spojení nahozené během zavádění nelze přerušit, protože v ramdisku není kompletní network-manager, který by se pokoušel v pravidelných intervalech spojení obnovit.

To byl problém na který jsme narazili, když počet mobilních zařízení připojených na AP v laboratoři s TurtleBoty překročil jeho limit. AP takovou situaci řešilo obvyklým způsobem – vyhodilo všechny klienty a počkalo až se ty aktivní znovu připojí. Takže se na AP pověsily opět studentské notebooky, ale TurtleBoty bylo nutné restartovat a tak zahodit obsah který byl uložený v RAM.

To ovšem znamenalo, že student, který pracoval na Turtlebotu pod uživatelem "guest" přímo ztratil výsledek své práce. Proto mnozí začali používat svůj účet. Což má své výhody, ale také nevýhodu v tom, že výrazně stoupnul počet přenášených paketů.

Fakt, na kterém je postaven můj disklessový koncept z roku 2012 je ten, že je zbytečné předávat po síti data, která nejsou potřeba.

Sdílení squashovaných vrstev po síti

Stažení squashovaného sendiče 3c20c5703ad932a238c5b2c91db31cbd o velikosti 12GB přes nezatíženou Wi-Fi trvá 6,5 minuty

Neexportovala by se vrstva, ale adresář, ze kterého by se v režimu readonly nabízely squashované image vrstev.

U disklessu by se mountovaly ze sítě, přes qemu-nbd a u autonomního disklessu, který by měl k dispozici blokové zařízení by se mountovaly přes loop.

NFS server – exportován jeden adresář, v režimu RO

→ ramdisk (NFS mount)

→ ramdisk (loop) připojení squashovaných souborů sdílených přes NFS na lokální loop zařízení

→ ramdisk (loop mount squashfs)

→ ramdisk (sestavení a mount overlaye)

→ start do systému

U stroje s lokální autonomií…

NFS server – exportován jeden adresář, v režimu RO

→ ramdisk (NFS mount)

→ ramdisk (mount lokální keše) ověření přítomnosti všech souborů, identifikovaných v konfiguraci

→ ramdisk (aktualizace lokální keše) stažení binárních patchů do lokální keše

→ ramdisk (NFS unmount) odpojení vzdáleného NFS adresáře

→ ramdisk (loop) připojení squashovaných souborů z lokální keše na lokální loop zařízení

→ ramdisk (loop mount squashfs)

→ ramdisk (sestavení a mount overlaye)

→ start do systému

Je to sice více kroků, ale minimalizuje se tím množství paketů přřenášených po síti.

Jak zjistit odkud je namountovaná vrstva

Kdy a odkud přišel poslední požadavek na připojení adresáře sdíleného přes NFS lze zjistit z žurnálu:

journalctl -t rpc.mountd | grep torch

Pokud příslušný cílový stroj žije a máme na něj přístup, můžeme ověřit zdali je skutečně příslušný adresář namountovaný

guest@lab-dc:~$ cat /proc/net/nfsfs/volumes 
NV SERVER   PORT DEV          FSID                              FSC
v3 c0a84204  801 0:24         42e:0                             no 
v3 c0a84204  801 0:25         424:0                             no 
v3 c0a84204  801 0:26         438:0                             no 
v3 c0a84204  801 0:27         456:0                             no 
v3 c0a84204  801 0:28         44c:0                             no 
v3 c0a84204  801 0:29         68:0                              no 
v3 c0a84204  801 0:30         3fd:0                             no 
v3 c0a84204  801 0:31         401:0                             no 
v3 c0a84204  801 0:32         402:0                             no 
v3 c0a84204  801 0:33         3e9:0                             no 
v3 c0a84204  801 0:34         3e8:0                             no 
v3 c0a84204  801 0:35         3eb:0                             no 
v3 c0a84204  801 0:36         3ef:0                             no 
v3 c0a84204  801 0:37         406:0                             no 
v3 c0a84204  801 0:38         3ec:0                             no 

A ze souboru /run/sandwich zjistíme co se za příslušným fsid skrývá.

Infrastruktura

Fyzický stroj, ze kterého jsou síleny přes NFS Btrfs subvolumes v adresáři /srv. Vrstvy jsou identifikovány číslem, které odpovídá fsid, pod kterým jsou exportovány. Takže adresář /srv/1001/opt odpovídá exportované vrstvě opt

Pro sdílení binárních patchů a squashovaných vrstev se využívá stroj support, half-disklessový stroj, který umožňuje stahovat soubory přes HTTP. Half-disklessové stroje jsou nezávislé na běhu DHCP serveru, takže adresář /srv/diskless/server/support/var/www/html, který je ve skutečnosti Btrfs subvolume, prosymlinkované na /srv/SQ/layers je dostupný i když DHCP server neběží.

Vývoj

Pro vývoj jsem využil Half-diskless technologii, kterou mám nasazenu v reálném prostředí již od roku 2018. Ta umožnila vytvoření autonomní disklessové infrastruktury. Původní tzv. Full-diskless technologie, nasazená do produkce v laboratořích Katedry řídící techniky na FEL ČVUT v roce 2012, vyžadovala spuštěný DHCP server s TFTP serverem, aby měla odkud stáhnout přes PXE linuxové jádro a soubor s ramdiskem. Což znamená, že samotný DHCP server disklessový být nemohl.

Ale při half-diskless technologii se pracuje se souborem virtuálního blokového zařízení, vyexportovaným přes NFS, kde je zavaděč GRUB2 včetně jádrem a ramdisku. Jde o relativně malý soubor o velikosti cca 200MB.

Využil jsem této technologie k tomu, abych nasimuloval fyzický stroj s blokovým zařízením, na které skript spouštěný během zavádění kopíruje z úložiště soubory potřebné k jeho autonomnímu běhu.

Struktura těchto souborů je následující:

/grub
vmlinuz
initrd.img
sandvich
layer-X
layer-Y
layer-..
patch-123
patch-456

layer-

Jsou soubory vrstev, vyrobené přes squashfs

patch-

Jsou soubory patchů, které si stahuje jádro z úložiště, pokud neodpovídá kontrolní součet ne

sandwich

soubor, který obsahuje tuplice názvů vrstev layer- s počtem souborů získaným přes příkaz

unsquashfs -l layer-X | wc

Pokud skript v ramdisku detekuje blokové zařízení které obsahuje subvolume pro autonomní diskless, udělá mount, stáhne soubor sandwich a postupně zkontroluje zda počty souborů lokálních vrstev odpovídají. Pokud ne, udělá dva kontrolní součty, pro řádek lokálního souboru a příslušný řádek vzdáleného souboru. A pokusí se stáhnout binární patch s odpovídajícím názvem. Viz příklad.

Stažený soubor sandwich obsahuje řádek

bookworm 757634  757740 57775499

Lokální výsledek bude

bookworm 659365  659474 49763644

Pro první bude md5sum ecbcdae81270bc377fbd1e997e1bcada a pro druhý d0d75b9e18b9537c19dc66a32bb5785d

Stačí převzít prvních pět znaků řetězce.

Takže se pokusí najít soubor patch-ecbcd-d0d75, který aplikuje na lokální squashovaný image.

Pokud se mu to podaří, udělá nový kontrolní součet lokálního souboru. A tak bude pokračovat, dokud nebude stejný jako u řádku ze souboru sandwich.

V případě, že se mu nepodaří stáhnout patch, vrátí nějakou výstrahu, ale bude pokračovat tak, jako by došlo k úspěšnému opatchování.

--

Pro první spuštění budoucího autonomního stroje je potřeba instalátor, který založí subvolume do kterého nainstaluje grub a jádro s ramdiskem.

O stažení vrstev se postará skript ramdisku, pokud nenajde na lokálním fs soubor s image příslušné vrstvy. Vrstvy a binární patche se nestahují přes TFTP, ale přes autorizované HTTPS

Sdílení git repozitáře přes SSH připojení

Sdílení git repozitáře je klíčová věc. Protože nejsou vyloučeny změny infrastruktury, které se ukáží během vývoje, vytvořil jsem na serveru pro potřeby sdílení adresář /var/cache/git/SQ, a inicioval příkazem:

server:/var/cache/git/SQ$ git --bare init

… jako lokální úložiště. A následně ho přidal, jako remote cíl, do kterého jsem pushnul stávající kód, abych ho mohl sdílet na jiných strojích.

server:~$ cat .ssh/id_rsa.pub >> .ssh/authorized_keys
server:~$ cd /srv/SQ
server:/srv/SQ$ git remote add origin ssh://user@localhost/var/cache/git/SQ
server:/srv/SQ$ git push origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 40 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 1012 bytes | 1012.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://localhost/var/cache/git/SQ
* [new branch]      master -> master

A pak si ho naklonoval na svůj pracovní stroj:

server:~$ git clone ssh://user@server/var/cache/git/SQ

Pochopitelně jsou i jiné možnosti sdílení, ale ověřování pomocí ssh klíčů je rychlé a sdílení bezpečné.