Obsah

Přehled vývoje infrastruktury pro diskless Debian na katedře DCE »

Předchůdcem bezdiskové stanice (angl. diskless node) byl terminál. Šlo o zobrazovací zařízení, vybavené klávesnicí, připojené k velkému sálovému počítači kabelem (sériovou linkou), které umožnilo víceuživatelské využití velkých sálových počítačů. První terminály se objevily počátkem 60. let 20. století a vymizely s nástupem PC na jeho konci.

Disklessová infrastruktura je komplexní soubor technologií, umožňujících běh operačního systému na fyzických i virtuálních strojích, bez nutnosti lokální administrace (instalace, konfigurace, atp.). Diskless, neboli bezdiskový v tomto kontextu tedy není stroj, ale jeho systém.

Instalace je proces, při kterém se na souborový systém blokového zařízení stroje, kromě zavaděče a jádra systému, ukládají další soubory potřebné k obsluze jeho hardware a software pro využití jeho výpočetního výkonu k různým účelům.

Typologie

Na konci 20. století, když začaly bezdiskové terminály nahrazovat univerzální osobní počítače (PC), které měly vlastní CPU, RAM a blokové zařízení, se začalo operovat s pojmy „tenký klient” (thin client) a „tlustý klient” (fat client).

Pod výrazem tenký klient se rozuměl původní terminál, který plně spoléhal na výpočetní výkon vzdáleného stroje ke kterému byl připojen. Naopak tlustý klient využíval v maximální míře vlastní hardware, takže stroj, ke kterému byl připojen nemusel plýtvat svým výpočetním výkonem na operace, které mohl vyřešit hardware tlustého klienta.

	Tenký klient (Thin client)	Bezdisková stanice (Diskless node)	Tlustý klient, využívající sdílený datový prostor (Dataless node)	Tlustý klient
Využití lokálního blokového zařízení pro uložení dat	Ne	Ne	Ne	Ano
Využití lokálního blokového zařízení pro uložení systémových dat OS	Ne	Ne	Ano	Ano
Využití výpočetního výkonu lokálního CPU	Ne	Ano	Ano	Ano

V letech 2003–2008 jsem pracoval na ÚMOb Ostrava-Jih, který patří k nejlidnatějším městským obvodům v České republice. Patřil mezi první úřady, které měly pro zpracování agendy 120 tisíc obyvatel obvodu k dispozici počítač, na kterém běžel unixový systém SCO, se kterým pracovali úředníci prostřednictvím terminálů. A právě v době mého nástupu se přecházelo na linuxové tlusté klienty (SuSe), které využívaly centralizovaný sdílený datový prostor pro uložení dat uživatelských profilů. A já, ve spolupráci s mým kamarádem a pozdějším nástupcem Tomášem Lukeštíkem, vytvořil pro potřebu tohoto úřadu první redakční systém s javascriptovým WYSIWYG editorem na světě, nasazený do ostrého provozu od března 2004. (Aleš Kapica)

Non-Diskless: Je systém nainstalovaný na lokálním blokovém zařízení, který je technicky možné provozovat bez závislosti na připojení k externí infrastruktuře. Od Half-Disklessu se liší tím, že má všechny soubory (tedy nejenom zavaděč a jádro) uložené na lokálním blokovém zařízení. Pro vzdálený přístup k těmto souborům musí být zapnutý, připojený k síti, se spuštěnou službou, která ten vzdálený přístup umožní. Nejsou-li splněny všechny uvedené podmínky, jsou jeho data nedostupné.

Údržba většího počtu takových strojů je komplikovaná a časově náročná, pokud administrátor nemá možnost využít disklessovou infrastrukturu.

Full-Diskless

Nevyžaduje žádné blokové zařízení, i když ho umí využít, ale je závislý na přístupu k DHCP, TFTP a NFS serveru

Je rychlý, protože veškeré IO operace probíhají po síti nebo v RAM.
Je bezpečný, protože používá systémové soubory, které se sdílejí přes NFS v režimu READ-ONLY (jen pro čtení), takže ani po získání superuživatelského přístupu do spuštěného systému nelze modifikovat soubory na straně NFS serveru. Veškeré lokální změny jsou za běhu uloženy jen do RAM, která se během restartu zahodí.
A výhodný pro administrátory, protože se nic nemusí instalovat a vše se spravuje na jednom místě. Není potřeba řešit přístupy na více strojů. Není potřeba si lámat hlavu zabezpečením, protože je vše jako na dlani – ale jen pro admina. A zálohování je stupidně snadné.

Má ovšem své limity:

Je závislý na přístupu k disklessové infrastruktuře – nastane-li problém v síti je nepoužitelný. Takové situace si však velice rychle někdo všimne. Tohle je stručný přehled skutečných problémů, které zapříčinily problém s dostupností disklessové infrastruktury: duplicitní IP adresa, propojené subnety, pirátský DHCP server, výpadek elektřiny, aj.
Dojde-li k přerušení připojení zamrzne. Ale nezhroutí se! Bude čekat, dokud NFS server nedoručí požadovaná data. V tom jak rychle data doručí hraje roli více faktorů, kromě konektivity i konfigurace NFS serveru. By default používá NFS server jen omezené množství vláken (XX), které je potřeba adekvátně navýšit, pokud má obsloužit větší množství strojů.
Žádná data nejsou lokálně uložená, vše se po restartu natahuje znovu, takže u většího počtu strojů spuštěných ve stejný okamžik můžete narazit na nedostatečnou propustnost sítě, protože switche pokud nestíhají zahazují pakety. NFS připojení, které jede přes TCP to ustojí, protože tenhle protokol počítá s tím, že se cestou něco ztratí – projevuje se to pomalým nabíháním aplikace při prvním spuštění. Každém další už bude rychlejší, protože se použije to co se po prvním spuštění uložilo do RAM. Ale procesy, které komunikují přes UDP protokol (jednodušší a tím pádem rychlejší) mohou v takových podmínkách kolabovat, pokud jim nějaký paket nedorazí včas.
Systém, který využívá overlayfs má k dispozici menší množství volné operační paměti, protože má část RAM vyhrazenou pro uložení modifikovaných souborů.

Half-Diskless

Využívá blokové zařízení jako úložiště (storage) a to umožňuje obejít omezení Full-Disklessu, takže je závislý pouze na přístupu k NFS serveru. QEMU totiž umožňuje virtuálnímu stroji podstrčit virtuální blokové zařízení, nasdílené přes NFS. A pokud je na něm nainstalován zavaděč, který linuxovému jádru rovnou nastaví IP adresu rozhraní, přes které si pak připojí zbytek systému nasdíleného přes NFS, nepotřebuje funkční DHCP server. Proto se klíčové stroje disklessové infrastruktury spouští jako Half-Diskless. Vše ostatní jako Full-Diskless

Autonomní diskless

Je ve své podstatě Half-Diskless, který využívá lokální blokové zařízení (je-li na to připravené) nejenom k instalaci lokálního zavaděče, který je schopen zavést jádro s podporou konektivity přes Wi-Fi v případě, že nelze využít síťového rozhraní které má PXE, ale také jako:

swap (pokud obsahuje swapovací diskový oddíl), který umožňuje obsadit větší množství RAM, než kolik jí skutečně je, a ..
persistentní keš, do které si uloží při spuštění soubory stažené ze sítě, aby je nemusel po restartu stahovat znova.

Využití blokového zařízení pro kešování velkých souborů je zcela zásadní funkcionalita, bez které nelze dosáhnout autonomie. Jedině díky tomu je schopen fungovat po startu i bez síťové konektivity, podobně jako Non-Diskless, od kterého se ale zcela zásadě liší tím že:

neobsahuje žádnou instalaci, jenom stažené soubory, které mohou být navíc kryptované,
.. a to je důvod proč vyžaduje při startu funkční síťové připojení. Jedině tak se totiž dostane ke své konfiguraci a získá klíče, kterými se dají nakešované soubory odemknout.

Bez přístupu k síti zůstane viset v ramdisku, který neobsahuje žádné informace, které by umožnily nakešované soubory odemknout a použít k sestavení sendviče. Všechno běží v RAM, jakmile tedy autonomní systém zkolabuje a ztratí obsah RAM, zůstanou na lokálním disku jen bezcenné kryptované bloby dat.

Po spuštění už je na připojení nezávislý a může existovat i bez něj, pokud dostane při startu do sendviče vrstvu, která obsahuje instrukce, jimiž se má řídit.

Výše uvedené schéma vizualizuje základní rozdíly. První dva stroje – A a B – jsou typu Non-Diskless. Od sebe navzájem se liší mimo jiné tím, že stroj A je do sítě připojen pomalým bezdrátovým připojením přes Wi-Fi, kdežto B prostřednictvím rychlého ethernetu. Z disklessové infrastruktury oba stroje využívají pouze DHCP server, který jim přiděluje IPv4 adresu. Rozdílným podbarvením schematických obrázků těchto strojů jsem se pokusil naznačit fakt, že u Non-Diskless strojů je velmi problematické udržovat identickou sadu dostupného software a dostupných dat. A totéž naznačuje i rozdílná barva blokového zařízení.

Ale disklessová infrastruktura je schopna zajistit velice jednoduchým způsobem to, aby na každém stroji byla k dispozici stejná sada dostupných dat i software – bez ohledu na to, zda-li ten stroj běží jako Full-Diskless (stroje C, E) nebo jako Half-Diskless (stroj D) – proto mají tyhle stroje na schématu stejnou barvu podbarvení.

Jejich hardwarové prostředky, se pochopitelně liší. Např. stroj E nemá k dispozici žádné blokové zařízení, proto si musí vystačit pouze s RAM. A stroj C, který nějaké blokové zařízení k dispozici má, ho stejně nepoužívá, protože neobsahuje swapovací oddíl, který by mohl využít k rozšíření RAM jako stroj D, ani diskový oddíl, který by měl label "data", na který by si mohl nějaké soubory nakešovat.

A stroj D, který komunikuje pouze přes Wi-Fi, naopak musí fungovat jako Half-Diskless, aby si mohl na diskový oddíl "system", uložit soubory vmlinuz (jádro) a initrd.img (ramdisk), které se u Full-Disklessu stahují z TFTP serveru poté co získá stroj IPv4 adresu přes PXE. Wi-Fi žádné PXE nemá. Proto se musí přes lokálně nainstalovaný zavaděč zavést jádro s ramdiskem, který obsahuje ovladač Wi-Fi a konfiguraci, přes kterou se stroj připojí k síti. Pak už to jede jako u ostatních strojů. Stáhne se konfigurace, kterou jádro zpracuje a nahodí systém.

A je-li k dispozici lokální blokové zařízení, proč ho rovnou nevyužít ke zlepšení výkonu? Sendvič sestavený z nakešovaných kryptovaných blobů nezatěžuje síť zbytečnými dotazy na NFS server, které by mohly snadno zahltit Wi-Fi připojení. A připojením swapu lze ošálit aplikace, závislé na velikosti RAM.

Klíčové prvky technologie diskless

První opravdový Full-Diskless systém, kdy na stroji není potřeba absolutně žádné instalace, jsme začali používat až od roku 2011, ale klíčový krok, od kterého se bylo možné odrazit, byl nápad Pavla Píši z roku 2005 – překrýt připojený adresář nasdílený z NFS serveru adresářem v RAM, vytvořeným přes tmpfs, pomocí unionfs.

Virtualizační skript kvm (používán od roku 2012)
Zavedení sendviče 2016
Přechod na dynamický ramdisk
Sjednocení systémů
Sjednocení účtů
Zrušení závislosti na distribuovaném úložišti

Overlay

Co přinesl nápad Pavla Píši nejlépe ozřejmí následující obrázek.

Každý operační systém, který běží jako diskless vyžaduje na serveru vyhrazený datový prostor, přístupný v režimu read-write, kde může zapisovat změny – logy, databáze, konfigurační změny, atp. Ovšem primárním požadavkem pro laboratorní stroje byla možnost dostat po restartu systém opět do výchozího stavu. Zachováno mělo zůstat jen to, co si uživatel uložil do svého domovského adresáře připojeného v režimu read-write.

Overlay umožnil systémové změny zapisovat do lokální RAM. Díky tomu tedy bylo možné použít pouze jeden systémový adresář exportovaný přes NFS v režimu read-only. V červnu 2011 Pavel Píša prezentoval tuhle koncepci počítačové laboratoře v rámci akce InstallFest.

Sandwich

Sendvič je nápad Aleše Kapicy implementovaný a používaný v rámci disklessové infrastruktury DC a DCE ČVUT od roku 2016. Dříve to ani nebylo možné. Jaderný modul overlay, který ummožňuje sendvič sestavit sice byl začleněn do hlavní vývojové větve jádra již v roce 2014, ale neumožňoval překrytí adresáře sdíleného přes NFS, proto jsme stále používali modul aufs, který ovšem vyžadoval kompilaci vlastního jádra. A to až do roku 2016, kdy byl problém s překrytím NFS vyřešen. Princip je jednoduchý. Sendvič je sestaven z několika připojených NFS adresářů a zapisovatelné horní vrstvy v RAM vytvořené přes tmpfs.

U původní verze byla systémová vrstva úplně dole, ale zavedení dynamicky řízeného ramdisku si vyžádalo přepracování původního skriptu a to umožnilo umístit systémovou vrstvu na libovolnou úroveň a tak využít specických vlastností overlaye velice sofistikovaným způsobem. Překrytím lze soubory nejenom přidat, ale také odstranit či nahradit. Přičemž přednost má vrstva co je nejvíc nahoře. Jak naznačuje obrázek. Soubory ze 3. vrstvy označené vykřičníkem překrývají soubory z vrstvy č. 1 i 2. U disklessu, který pracuje pouze s jedním systémovým adresářem sdíleným přes NFS, jak naznačuje obrázek níže, něco takového není možné.

Dynamický ramdisk

Dynamický ramdisk, je další nápad Aleše Kapicy, který posunul disklessovou infrastrukturu na zcela jinou úroveň.

Jeho zavedení umožnilo zjednodušit záznam zavaděče.

Bezpečnost

Dokud byl předáván seznam vrstev prostřednictvím zavaděče, mohl každý jednoduše zjistit co, odkud a v jakém pořadí se mountuje.

Pokud došlo k chybě v zápisu, skončil systém ve stavu, který vyžadoval manuální restart.

Dynamický ramdisk umožnil nedostupný NFS adresář přeskočit a pokračovat v zavádění.

Soustředil administraci celého disklesu do jediného místa a několika málo konfiguračních souborů

Modifikace systému je velice snadná. Např. rozdílné metody ověřování řeší dvě velice tenké vrstvy, které obsahují pouze konfigurační soubory. Prostřednictvím vrstvy isolate lze velice elegantním způsobem získat stroj ideální ke zkouškám, kde je dostupný veškerý software ale přístup do sítě omezen jen na vyhrazené stroje.

Dynamický ramdisk také umožnil vytvořit technologii autonomního Half-Disklessu.