Diskless
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 nim na jednom počítači (nezávisle na sobě) pracovat více 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 kombinaci fyzických a virtuálních strojů, které to umožňují.
Typologie
Pojmy „tenký” (thin) a „tlustý” (fat) klient se objevily během 80. let 20. století, kdy začaly terminály vytlačovat osobní počítače (PC).
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.
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 |
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.
Konstrukčně složitější PC 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 výkonem na operace, které si mohlo PC zajistit vlastními prostředky.
Na druhou stranu stoupla pravděpodobnost, že se vyskytne problém se kterým si „Běžný Franta Uživatel” (BFU) neporadí, což vyvolalo poptávku po lidech schopných takové problémy rychle a operativně řešit – a právě to zcela zásadním způsobem roku 1999 změnilo můj život.
Další 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 již od 90. let. A jen krátce 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ý kolega 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ůvodně přijat jako webmaster, což byla práce kterou původně zajišťoval nějaký mládenec na „civilní službě”. Tehdy už začínala statickému webu zvonit hrana, ale ještě neexistoval žádný open source redakční systém, proto jsme s kamarádem a mým 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).
- 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:
|
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.
- 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é.
Aplikací sendviče bylo odstraněno riziko, že nějaký software nabourá fungování systému. Umístěním rizikové vrstvy pod systémovou vrstvu je zajištěno, že se nekompatibilní knihovna do horních vrstev nedostane. A pokud je potřebná, umístí se do některé vyšší vrstvy takovým způsobem, aby byla neškodná.
Dynamický ramdisk
Dynamický ramdisk, další nápad Aleše Kapicy, posunul disklessovou infrastrukturu na zcela jinou úroveň. Jeho zavedení umožnilo zjednodušit záznam zavaděče.
Původně se totiž předával seznam vrstev a další proměnné prostřednictvím parametrů jádra. K těm se dá velice snadno dostat výpisem obsahu souboru /proc/cmdline
, ale pokud došlo k nějaké chybě při zápisu, skončil systém ve stavu, který vyřešil jen manuální restart přímo na místě.
Dynamický ramdisk pracuje s konfigurací, kterou si stahuje buď na základě předaného parametru name=
, nebo konfigurace sítě z DHCP, přidělené na základě MAC adresy. V případě, že se v konfiguraci objeví nějaká chyba, např. překlep v URL vrstvy sdílené před NFS, přeskočí neplatnou položku a pokračuje dál v zavádění.
Dynamický ramdisk vyřešil také otázku zavaděčů, protože se pracuje se stejnou konfigurací bez ohledu na to, který zavaděč a jakým způsobem jádro spustil. Nezáleží tedy na tom, je-li jádro zavedeno přes Legacy či UEFI PXE, nebo ho zavedl lokálně instalovaný Grub.
Díky tomu se administrace všech strojů disklessové infrastruktury soustředila do jediného místa a několika málo konfiguračních souborů. Většina strojů si vystačí s generickou konfigurací. Jenom stroje, které tvoří specifickou součást disklessové infrastruktury mají konfiguraci vlastní.
Také úprava konfigurace systému je velice snadná. Vše se řeší přes vrstvy. Základní vrstva, ve které jsou systémové soubory a distribuční software je u všech strojů stejná. A konfigurace se mění pouze tím, že se nad ní použije jiná vrstva.
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.
Obsah manuálu
(Vpravo je uveden aktuální stav zpracování kapitoly)
- Disklessová infrastruktura
- Postupy a manuály
- Disklessová pracovní stanice
- VMware Player v prostředí bezdiskového linuxu
- Virtualizovaný cluster
- VMware Player v prostředí bezdiskového linuxu
Doplňky