Obsah

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

Předchůdcem bezdiskových stanic byly terminály. Terminál – zobrazovací zařízení s klávesnicí, byl k centrálnímu sálovému počítači připojen kabelem – sériovou linkou, o délce až 50 metrů. A protože jich mohlo být k počítači připojeno více, mohlo díky terminálům na něm (nezávisle na sobě) pracovat víc uživatelů.

Terminály, které se začaly používat počátkem 60. let 20. století, neměly žádné blokové zařízení (disk nebo disketu) na kterém by měly nainstalován nějaký operační systém, proto se jim anglicky říkalo diskless node.

Diskless je tedy systém, který se obejde bez toho, že by měl k dispozici lokálního blokového zařízení. A disklessová infrastruktura představuje soubor technologií co mu to umožňují.

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

Asi od 80. let 20. století začaly terminály vytlačovat osobní počítače (PC) a objevily se pojmy „tenký” (thin) a „tlustý” (fat) klient.

Terminál „tenký klient”, byl konstrukčně jednodušší než PC, protože obsluhoval jen sériový port, monitor a klávesnici. Jenže vyžadoval – jako každý Full-Diskless – persistentní (stálé) kabelové připojení na drahý a výkonný centrální počítač (server), bez kterého byl k ničemu. Zatím co Non-Diskless PC bylo použitelné standalone (samo o sobě).

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.

Konstrukčně složitější PC, však mělo mnohem univerzálnější využití, protože mohlo fungovat samostatně. Mělo výkonnější CPU, větší množství RAM a později i výpočetní grafickou kartu, takže pokud bylo použito jako tzv. „tlustý klient” nemusel centrální počítač (server) plýtvat svým výkonem na operace, které si mohlo PC zajistit vlastními prostředky.

V České republice si mohly velké sálové počítače s terminálovým přístupem dovolit jen velké instituce. Pro většinu lidí se tak stalo synonymem počítače relativně levné, ojeté, repasované PC, které různí podnikavci za směšnou cenu v západoevropských zemích vykupovali, dováželi do ČR a zde s patřičným ziskem prodávali.

Spokojeni byli všichni. Západní instituce, které nakupovaly nové a výkonnější PC se lacino zbavily morálně zastaralých krámů, které se díky tomu dostávaly do rukou zájemců v ČR, co si koupi nového PC nemohli z nejrůznějších důvodů dovolit. A omezené prostředky těchto strojů tlačily české programátory k tomu, aby produkovali lepší a efektivnější kód. A díky tomu dnes patří vývojáři z České republiky mezi světovou špičku – viz statistika vývojářů podle zemí z června 2023.

Víceméně náhoda vedla k tomu, že jsem během let 2003–2008, kdy končila éra výkonných počítačů s terminálovým přístupem pracoval na ÚMOb Ostrava-Jih, který patří k nejlidnatějším městským obvodům v České republice. Zde využívali ke zpracování agendy pro 120 tisíc obyvatel obvodu centrální počítač s terminálovým přístupem od 90. let. A těsně před mým nástupem (v květnu 2003) nahradily původní terminály linuxové stroje s distribucí SuSe, které fungovaly jako dataless node – neboli tlustý klient, využívající centralizovaný sdílený datový prostor k uložení dat uživatelských profilů.

Instalaci klientů měl na starosti můj dnes již zesnulý kolegova Ivan Doležal (*1964 – †2014) a o SCO server se staral náš šéf, také již zesnulý Jozef „Bedřich” Perzyna (*1963 – †2022). Já byl přijat jako webmaster, což byla práce kterou původně zajišťoval nějaký „civilkář”. Tehdy už začínala statickému webu zvonit hrana, ale ještě neexistoval žádný open source redakční systém. Proto jsme ve spolupráci s mým kamarádem a pozdějším nástupcem Tomášem Lukeštíkem (*1968), během roku vytvořili pro potřebu úř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 (*1969), 7.1.2023

	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

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ů.

V době mého nástupu na DCE (2008) se využíval na laboratorních strojích Half-Diskless. 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, jehož výsledkem byl LabLink – laboratorní systém, který využíval vrstvení virtualizovaných MS Windows při práci s laboratorními modely. Možná, že právě to mne později přivedlo na myšlenku využít sendviče i pro linuxový laboratorní diskless.

První rok zabrala většinu času dokumentace toho, co již bylo v provozu. Ale již v následujícím roce jsem začal intenzivně spolupracovat s Pavlem Píšou(*1970) na vývoji Full-Diskless řešení 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, i zavaděč Grub2 procházel bouřlivým vývojem. Takže za rok úspěšného dokončení tohoto úkolu lze považovat teprve rok 2011.

Aleš Kapica (*1969), 7.1.2023

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.

Diskless technologie

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.