overlay

Skutečný Full-Diskless, který se obejde bez jakékoliv lokální instalace umožnila technologie překrytí systémového adresáře připojeného z NFS serveru adresářem vytvořeným přes TMPFS z části RAM v kombinaci se zaváděním přes PXE.

Každý operační systém potřebuje datový prostor, kam může za běhu zapisovat změny – logy, databáze, konfigurační změny, atp. Rozdíl je pouze v tom, že se diskless nezdržuje čekáním na to, až se data zapíšou na lokální blokové zařízení – spoléhá že to za něj udělá NFS server kterému je posílá ať si je někam uloží přes ethernet.<ref> Je to velice výhodný přístup! Až do nástupu SSD a NVME disků, byly IO operace úzkým hrdlem každého počítačového systému. Aby mohl zapsat datový blok z rychlé RAM na pomalý rotační disk, musel vyčkat se zápisem až se roztočí, teprve poté co mu driver oznámil, že jsou data zapsaná mohl čekající proces pokračovat dál. Diskless nic takového nezdržuje, protože NFS server, který obdržel data po síti, ihned odpoví, že jsou data přijata a diskless už se nestará o to, kdy, kam a jak si ty data uloží. <ref> NFS server, který obsluhuje více takových strojů, má vždy lepší ekonomiku provozu než pracovní stanice.

• Je vybaven větším množstním RAM než pracovní stanice, takže se nezdržuje se neustálým roztáčením disků. Drží data v RAM, dokud ji nepotřebuje uvolnit. Nemá důvod se opakovaně zdržovat roztáčením pomalých rotačních disků aby mohl uložit.
• Má také obvykle i větší počet disků, což umožňuje paralelní zápis i čtení, což ve výsledku zkracuje dobu čekání na dokončení I/O operace, protože nemusí čekat na potvrzení o zápisu jako Non-Diskless stroje, které obvykle na to mají pouze jeden systémový disk. Server si rozdělí data na víc částí a každou z nich zapíše ve stejnou chvíli na jiný disk. A totéž platí i pro čtení.
• Server má navíc sdílenou RAM, takže se nezdržuje pokud chce více strojů najednou jeden a ten samý blok dat, který už jednou načetl do RAM, a rovnou jim ho odešle.
• Datový prostor na serveru je drahý. Hodně disků, hodně RAM, hodně počítání a také má poměrně velkou spotřebu elektrické energie. Ale čím víc obsluhuje klientů, tím se to víc vyplatí.

Diskless, který nemá overlay, neukládá změny do RAM. Musí tedy mít na NFS serveru vyhrazen svůj datový prostor, přístupný v režimu read-write, kam si může svoje změny zapsat. Nemůže zapisovat do stejného adresáře jako jiný stroj, poněvadž by to mohlo vést ke kolizím. Takže čím víc takových strojů NFS server obsluhuje, tím víc datového prostoru mu to zabere.

U strojů co mají overlay to není nutné, protože si změny zapisují do RAM a vůbec nevadí, že se při restartu zahodí. Naopak. Je výhodné, když se po restartu ocitne vše ve výchozím stavu, protože nezůstanou žádné soubory, ve kterých by číhal na svou oběť vir, či nějaký ransomware. A na NFS serveru tím pádem stačí pro všechny stroje jeden adresář, který může být klidně exportován read-only, takže nehrozí, že by jeho obsah v nestřeženou chvíli nějaký škodič zakryptoval. A protože je systém všude stejný, jsou i data, která si uživatel zapisuje přes NFSv4 do svého adresáře připojeného v režimu read-write, použitelná i jinde.

Princip

Skript postupně namountuje adresáře vrstev nasdílených přes NFS na přípojné body v ramdiskovém adresáři /tmp, pak zavede jaderný modul overlay a sestaví sendvič, který obsah vrstev připojených přes NFS překryje virtuálním tmpfs diskem vytvořeným v rámci dostupné RAM.

Na základě přidělené IPv4 adresy nastavuje aktuální hostname bezdiskového stroje a generuje soubor /etc/hosts, ve kterém ukazuje záznam nfsroot na aktuální NFS server.

Skript v ramdisku najdete v podadresáři /scripts/nfs-bottom/.

Pokud bude všechno v pořádku a linuxovému jádru nebude předána volba overlay=off najede stroj s překrytým souborovým systémem.

Zda-li overlay je či není aplikovaný lze zjistit kupř. z výpisu příkazu mount. Pokud systémový disk není překrytý, tak ho normálně vidíme namountovaný na kořen / souborového systému. V opačném případě se v tomto výpisu neobjeví.

Kam je připojený ale můžeme vidět, když si necháme vypsat obsah souboru /proc/mounts. Z něm by se měl objevit systémový disk připojený na /root.

A v adresáři /overlay/unirw by také měly být vidět veškeré nově vytvořené a změněné soubory.

Chceme-li překrytí vypnout, tak buď můžeme rovnou předat volbu overlay=off

vmlinuz ... overlay=off ...

Druhou variantou je operativní vypnutí překrytí, máme-li zaváděcí proces přerušený parametrem break. V takovém případě stačí v kořeni ramdisku vytvořit soubor s názvem off a příkazem exit pak pokračovat v zavádění.

vmlinuz ... break ...
...
(initramfs) touch off
(initramfs) exit
...

Pokud přepínáme mezi překrytím a RW přístupem, je třeba aby byl pro RW přístup vyexportován také adresář virtuálního stroje na vzdáleném NFS serveru!

Tipy a triky

Drbne-li se do souboru soubor (může jít i o adresář), který je součástí sendviče, stane se nedostupný a pokus o jeho vylistování dopadne takto:

~# ls -alh soubor
ls: cannot access 'soubor': Stale file handle

A když vypíšeme obsah celého adresáře bude řádek, kde je soubor vypadat takto:

...
-????????? ? ?     ?       ?     ? soubor
...

Jde o velmi prekérní situaci, ze které pomůže jenom tvrdý restart, pokud uživatel nemá možnost přepnout na lokálního roota, nebo povoleno spouštět příkaz mount přes sudo, protože řešením je remount, přípojného bodu. Viz

~# mount -o remount /

Verze

MD5SUM	Velikost kB	Datum vytvoření
e14b162421e25a93dbd9025e56cd1ed1	1373	2013-01-28	root_overlay – původní verze skriptu s podporou aufs a unionfs.
b3b8fc923fceefeec607161b6883e18b	2334	2013-03-19	root_overlay rozšířený o podporu overlayfs
75367479f388b68e15b28859f346c66d	2531	2016-02-09	první verze skriptu po přejmenování na overlay, ještě s podporu skriptu unionfs
11082396ef01f915f060258cc7795d4a	10086	2016-09-22	verze publikovaná na SourceForge.net
51ea3d314d6083d8ff5900330869d68f	10536	2016-09-30	první verze s podporou pro findswap používaná na DCE až do XXX
d9a9896c718dbd3b801966d9f4c1066f	14133	2019-09-04	první vývojová verze s podporou pro mcachefs (pro turtleboty)
10c3c08b5b91dab1672a3ed51e600c08	15531	2019-09-18	druhá vývojová verze pro DC s podporou pro mcachefs (pro turtleboty)
ea6eeac8dcd1397c760fd912a0d67c29	18100	2020-03-19	třetí vývojová verze pro DC s podporou pro mcachefs (pro turtleboty) používaná do XXX

Až do verze XXX měla funkce, před kterou lze při parametru overlay=off namountovat systémovou vrstvu, tak aby do ní bylo možné najet bez překrytí omezení na prvních 9 vrstev. Byl to relikt původního řešení.

Tehdy se parametrem jádra overlay= nenastavovalo pořadové číslo NFS vrstvy v rámci sendviče, která se má namountovat po spuštění disklessu v režimu RW na přípojný bod, odvozený od pořadového čísla vrstvy v rámci sendviče (např. /layer3 pro 3. vrstvu).

Seznam vrstev, exportovaných přes NFSv3 se tehdy předával jako parametr jádra prostřednictvím konfigurace zavaděče a vypadal asi takto:

KERNEL boot/vmlinuz-4.6.0-0.bpo.1-amd64 ... break overlay=0
...
APPEND layers=/var/log;192.168.66.3:/srv/vmware

overlay=0 - systém najel překrytý

overlay=off - systém najel bez překrytí, takže bylo možné hrabat rovnou do adresáře sdíleného přes NFS

overlay=<integer> udával pořadové číslo vrstvy která se má namountovat na adresář /opt V tomto konkrétním ukázkovém případě by mělo efekt

1 - že by systém najel s lokálním adresářem /var/log namountovaným na /opt

2 - že by systém najel s namountaným NFS adresářem publikovaným ze 192.168.66.3:/srv/vmware na /opt

3 - že by systém najel toho že by něco bylo a adresáře /opt mountováno v režimu read-write

Položky, předávané v parametru layers nemusely být jen adresáře z NFS serveru. Mohly to být i bindované adresáře základního systému.

A k dispozici nebyl ani mechanismus, který by umožnil operativně do jeho prostředí naimportovat soubor /etc/hosts a /etc/resolv.conf, takže se muselo pracovat pouze s IPv4 adresami

overlay.service

Je služba, kterou si vynutilo zavedení sendviče. Spouští se v rámci disklessového systému během zavádění systemd. Zpracuje obsah konfiguračních souborů se sufixem .conf z adresáře /etc/overlay.d, které obsahují tři typy akcí:

remove – odstraní soubor, takže umožní založení jeho nové verze do ramdisku

noremove – odstraní všechny soubory, v předané lokaci, kromě toho co vyhoví vzorku

touch – aplikuje touch vytáhne soubor příkazem touch ze vzdáleného adresáře v ramdisku

notouch – aplikuje touch na všechny soubory, v předané lokaci, kromě těch co vyhoví vzorku

truncate – zmenší velikost souboru na 0, takže při zápisu nových dat nezabírá zbytečně místo v RAM.