overlay

From DCEwiki
Jump to navigation Jump to search

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[1] v kombinaci se zaváděním přes PXE.[2]

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.

ramdisk tmpfs.svg

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
...
Upozornění 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.
  1. Překrytí NFS adresáře pomocí unionfs použil Pavel Píša již roku 2005.
  2. V době mého nástupu na DCE (2008) fungovaly laboratorní stroje pouze jako Half-Diskless a já nevěděl o Disklessu nic. Byl jsem přijat coby expert na virtualizaci linuxových strojů, abych zajišťoval za katederního IT nezbytnou spolupráci při realizaci projektu Eusophos, v jehož rámci byl Ondrou Fialou vyvíjen LabLink – virtuální laboratorní systém, který využíval vrstvení virtualizovaných MS Windows pro zajištění software nezbytného k práci s laboratorními modely – ta koncepce se mi líbila a možná, že právě to mne přivedlo později na myšlenku využít sendviče i pro linuxový laboratorní diskless. První rok zabrala většinu mé pracovní doby dokumentace toho, co kde bylo v provozu. IT oddělení DCE tehdy ještě neexistovalo. Pracovní stanice řešil Petr Haba. MS Windows server s katederním webem Michal Komrska a František Vaněk měl pod palcem síť a Novell. Vše ostatní jsem měl řešit já, ale co, to nikdo nevěděl. Lukáš Moc, můj předchůdce mi předal štůsek papírů a zmizel, aniž by mi sdělil alespoň přístupové heslo. Bylo to jak v pohádce o kohoutkovi a slepičce. Abych měl kam sbírat informace, rozjel jsem tuhle wiki, ale nejdřív jsem si do ní musel udělat vlastní rozšíření, abych mohl na jednom místě soustředit veřejné i neveřejné infromace. A tak až po roce jsem se dostal k tomu, abych začal intenzivně spolupracovat s Pavlem Píšou(*1970) na vývoji laboratorního Full-Disklessu na bázi linuxové distribuce. Bohužel moduly linuxového jádra, které jsme potřebovali použít, tehdy ještě nebyly součástí hlavní vývojové větve. Také zavaděč Grub který jsme využívali byl problematický. Původní verze se již nevyvíjela a vývoj nové probíhal pomaleji než bychom si přáli. Takže za rok dosažení cíle lze považovat teprve rok 2011, kdy Pavel Píša odprezentoval náš Full-Diskless systém počítačové laboratoře, zhruba po roce ostrého nasazení, v rámci akce InstallFest (červen 2011).
    Citace z článku Jak jsem se dostal k vývoji disklessové infrastruktury, autor Aleš Kapica (*1969)