Diskless

From DCEwiki
Jump to navigation Jump to search

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ů. K jednomu počítači jich mohlo být připojeno víc, protože Unix měl podporu pro souběžnou práci více uživatelů.

Začaly se používat počátkem 60. let 20. století. Nepotřebovaly blokové zařízení (disk nebo disketu) na kterém by měly nainstalován nějaký operační systém, šlo o diskless node - bezdiskové komunikační uzly, které stačilo jen zapnout. Diskless je tedy vlastnost. Stav, kdy pro práci se zařízením stačí pouze ho zapojit do sítě disklessové infrastruktury a zapnout. A to, zda má či nemá k dispozici nějaké lokální blokové zařízení na kterém je nainstalován operační systém není podstatné.

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.


Typologie

Během 80. let 20. století, kdy se místo terminálů začaly používat ve stále větší míře využívat pto terminálový přístup PC, se začaly používat pojmy „tenký klient” (thin client) a „tlustý klient” (fat client).[1]

„Tenký klient” (klient) je konstrukčně mnohem jednodušší zařízení než PC. V podstatě jen klávesnice s monitorem a port přes který je připojen kabelem k centrálnímu počítači (server), bez kterého je nepoužitelný. Proto, jako každý Full-Diskless, vyžaduje persistentní (stálé) připojení.

PC se začalo říkat „tlustý klient”, protože bylo funkční i bez připojení síti. Mělo svůj vlastní samostatný operační systém, uložený na lokálním blokovém zařízení (původně disketě, později rotačním disku) a kam se mohly ukládat i data, pokud zrovna nebyl server k dispozici. Bylo drahé, ale použitelné samo o sobě, takže mělo mnohem univerzálnější využití. Ale u každého HW elementu, co se stará o zpracování elektronických dat, se může vyskytnout chyba která může způsobit poškození nebo ztrátu uložených dat, pokud se průběžně neodesílají na server(!) – to je problém všech Non-Diskless systémů.

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
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.
Schéma, které vidíte je vizualizací, která demonstruje rozdíly v rámci popsané typologie.
A a B
stroje typu Non-Diskless, které se od sebe navzájem liší (mimo jiné) způsobem připojení:
A je do sítě připojen přes Wi-Fi (56Mbit/sec, bez možnosti PXE), kdežto
B prostřednictvím ethernetu (1Gbit/sec a výše + zavádění přes PXE).
Z disklessové infrastruktury oba stroje využívají pouze DHCP server, který jim přiděluje IPv4 adresu.
Rozdílné podbarvení schémat strojů naznačuje fakt, že u Non-Diskless strojů je velmi problematické udržovat identickou sadu dostupného software a dostupných dat – totéž naznačuje i rozdílná barva blokového zařízení.
C, E a D
Disklessová infrastruktura je schopna velice jednoduše zajistit, aby na každém stroji byla k dispozici stejná sada dostupných dat i software – bez ohledu na to, zda běží jako Full-Diskless (stroje C a E) nebo jako Half-Diskless (stroj D) – proto mají tyhle stroje stejné podbarvení schématatického zobrazení.
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 tak jako to má stroj D, ani diskový oddíl, který by měl návěští 'data', na který by si mohl odložit nějaké soubory.
Stroj D, protože komunikuje pouze přes Wi-Fi, musí fungovat jako Half-Diskless. Tzn. že musí mít diskový oddíl, který má návěští 'system', na který si může uložit soubory vmlinuz (jádro) a initrd.img (ramdisk), které si Full-Diskless stroje stahují z TFTP serveru, poté co získají přes PXE IPv4 adresu. Stroj, který jede přes Wi-Fi musí mít lokálně k dispozici ramdiskem, který obsahuje ovladač Wi-Fi a konfiguraci, přes kterou se stroj připojí k AP. Pak už to jede stejně jako u ostatních strojů disklessové infrastruktu – nfsroot stáhne konfigurační soubor, který ostatní skripty ve fázi nfs-premount a nfs-bottom zpracují aby mohl být zaveden systém.
diskless scheme.svg
Má-li disklessový systém k dispozici lokální blokové zařízení, lze ho využít ke zlepšení výkonu:
  • Sendvič sestavený z nakešovaných kryptovaných blobů nevyžaduje persistentní připojení na NFS server, a nehrozí že by nevhodným příkazem připojení pomalou síť zahltily pakety (Wi-Fi).
  • Připojením swapovacího oddílu lze předejít kolapsu systému z důvodu nedostatku volné RAM a zároveň ošálit aplikace, které jsou závislé na celkovém množství dostupné RAM (virtualizace).
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é.
Upozornění 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:
  1. neobsahuje žádnou instalaci, jenom stažené soubory, které mohou být navíc kryptované,
  2. .. 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.
Poznámka 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.


Diskless technologie

  • překrytí NFS adresáře, tzv. overlay se využívá od roku 2006
  • od roku 2011 se využívá zavádění přes PXE
  • virtualizační skript kvm se používá u diskless infrastrujtury od roku 2012
  • sendviče byly zavedeny v roce 2016
  • Half-Diskless boot systém se používá od září 2018
  • od roku 2019 se používá dynamický ramdisk
  • Sjednocení systémů a uživatelských účtů 2019–2023
  • Zrušení závislosti na distribuovaném úložišti CEPH 2023
  • Autonomní diskless 2023

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

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


Původní Full-Diskless řešení z roku 2011 používalo pouze jeden systémový adresář nasdílený přes NFS, překrytý adresářem vytvořeným v RAM. Viz schéma:

nfs classic.svg

Mělo jednu velkou nevýhodu.

Každá verze Debianu vyžadovala svůj vlastní sdílený adresář, do kterého bylo nutné následně implementovat změny klíčové pro Diskless. Během „ladění” laboratorního disklessu se tak míchaly v jednom kotli distribuční soubory instalované přes APT s aplikacemi, které se instalovaly jinou cestou a sledovat dílčí konfigurační změny na off-line adresáři bylo stále víc obtížné.

Proto, když se do jádra dostal modul overlay[4] byl skript overlay upraven tak, aby šlo překrytí vypnout.

Operativní vypnutí překrytí

Varianty, jak to udělat, byly dvě. Buď jádru předat volbu overlay=off rovnou při zavádění

vmlinuz ... overlay=off ...

Nebo zavádění přerušit parametrem break, pomocí příkazu touch vytvořit v kořeni ramdisku soubor s názvem off a následně příkazem exit pokračovat v zavádění.

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

Pak bylo možné dělat změny rovnou do adresáře disklessového systému na NFS serveru, který pochopitelně musel mít při exportu povolen RW přístup pro adresu laboratorního stroje, na kterém se realizovaly změny.

Sendvič

V září kdy měl modul overlay, již vyřešen problém s překrytím NFS přišel čas definitivně zahodit aufs a to umožnilo přejít na sendvič, sestavený z většího počtu vrstev.

První verze sendvičování, používaná od 22.září 2016, také pracovala s parametrem jádra overlay=, ale jiným způsobem. Zavaděč totiž nově předával také parametr layers=, ve kterém byl seznam vrstev co se měly sloučit do sendviče, kromě hodnoty off bylo možné předat také pořadové číslo vrstvy, která se po zavedení namountovala na přípojný bod /opt-layer kde v ní bylo možné za běhu dělat potřebné změny, pokud měl stroj povolen RW přístup na NFS.

Mělo to ovšem jednu drobnou vadu – systémová (distribuční) vrstva musela být první v pořadí, na nejnižší úrovni, protože jinak by systém nenajel.

nfs sandwich.svg

Schéma které vidíte názorně demonstruje jak funguje sendvič.

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, pokud se ve 3. vrstvě ocitnou soubory, které překryjí soubory níže položených vrstev, může nastat problém (jak je naznačeno vykřičníkem), pokud jde o soubory které jsou důležité pro systém.

U disklessu, který pracoval pouze s jedním adresářem sdíleným přes NFS, k takové situaci dojít nemohlo, protože s ním pracoval pouze administrátor disklessové infrastruktury, který dobře ví co dělat nemá. Ale sendvičování mělo otevřít do budoucna cestu k tomu, aby si mohli obsah svých vrstev modifikovat sami uživatelé.

Druhá verze sendvičování

Po zavedení dynamicky řízeného ramdisku, je možné měnit operativně pořadí vrstev. Systémovou vrstvu lze umístit na libovolnou úroveň a tak využít specifických vlastností slučování vrstev skrze modul overlay velmi sofistikovaným způsobem.

  • Bylo tak odstraněno riziko, že někdo neúmyslně nabourá fungování systému, protože rizikové vrstvy jsou umístěné na nižšší úroveň, než je systém, takže se nekompatibilní knihovna či záměrně infikovaná systémová aplikace z takové vrstvy do spuštěného systému nedostane, protože ji nahradí ta správná.
  • A zároveň to umožnilo jednoduchou hromadnou konfiguraci tam, kde je to potřeba.

Dynamický ramdisk

Technologie dynamického ramdisku, zavedená v září 2019 posunula disklessovou infrastrukturu na zcela jinou úroveň, protože umožnila zjednodušit konfiguraci zavaděče[5] a soustředit konfiguraci veškeré disklessové infrastruktury[6] do jednoho adresáře verzovaného přes git.


Obsah manuálu

(Vpravo je uveden aktuální stav zpracování kapitoly)

Diskless  
 
90%
Disklessová infrastruktura  
 
60%
Přehled vývoje infrastruktury pro diskless Debian na katedře DCE  
 
70%
Postupy a manuály
Zavádění bezdiskových strojů  
 
20%
Jak vytvořit bezdiskový stroj s operačním systémem GNU/Linux  
 
60%

Skripty pro dynamický ramdisk

nfs  
 
00%
crypto  
 
10%
debug  
 
20%
findswap  
 
70%
nfsroot  
 
20%
overlay  
 
80%
Práce v prostředí ramdisku  
 
80%
Překrytí systémového disku - overlay filesystem  
 
80%
Disklessová pracovní stanice  
 
60%
TurtleBot  
 
50%
VMware Player v prostředí bezdiskového linuxu  
 
90%
Virtualizovaný cluster  
 
60%
(opuštěný koncept)

Administrátorské Skripty

SQimage.sh  
 
50%
SQcrypto.sh  
 
40%


  1. Výkonné sálové počítače s terminálovým přístupem si mohly dovolit jen velké instituce. Proto se pro většinu lidí stalo synonymem počítače až relativně levná, ojetá, repasovaná PC, dovážená do zemí bývalého RVHP po roce 1990 většinou ze západního Německa, kde se původně tato PC používala v režimu „tlustého klienta” k práci na výkonném sálovém počítači (mainframe). Spokojeni byli všichni. Západní instituce, které chtěly nakoupit novější a výkonnější stroje nemusely řešit likvidaci rychle zastarávajících strojů, které různí podnikavci, kteří je od nich vykupovali jako šrot určený k likvidaci, který následně se ziskem prodali v ČR. Nové stroje tehdy byly pro většinu zájemců v zemích bývalého RVHP finančně nedostupné. Jen pro zajímavost. V roce 1990 stála 3,5" Floppy mechanika 3500Kčs, IBM PC AT (tj. i286 na 10MHz) kompatibilní počítač 100 tisíc Kčs a výkonnější i386 150 tisíc Kčs. V té době se dal za takové peníze koupit rodinný dům se zahradou. Průměrná mzda byla okolo 4,5 tis. Kčs a nový automobil značky Škoda Favorit stál 84 tisíc Kčs. O 5 let později už ceny starších modelů počítačů klesly natolik, že si je mohli dovolit i mnozí nadšenci a protože je výpočetní výkon těchto strojů nutil k tomu, aby produkovali lepší a efektivnější kód, vyrostla v České republice generace vývojářů co dnes patří podle statistiky vývojářů dle země původu z června 2023 mezi světovou špičku. Konstrukčně složitější PC bylo mnohem dražší než terminál, ale mělo k dispozici vlastní CPU, RAM a výpočetní grafickou kartu, takže centrální počítač (server) nemusel plýtvat výkonem na operace, které si mohl „tlustý klient” zajistit vlastními prostředky. PC mělo navíc mnohem univerzálnější využití, protože mohlo fungovat i nezávisle na připojení k síti. Na druhou stranu šlo o složitější mechanismul a pravděpodobnost, že se vyskytne problém se kterým si „Běžný Franta Uživatel” (BFU) neporadí výrazně stoupla, což vyvolalo poptávku po lidech schopných takové problémy rychle a operativně řešit. Mezi takové jsem patřil i já, a tak jsem během brigády v brněnské překladatelské agentuře Skřivánek s.r.o. roku 1999 dostal nabídku, abych z uklízeče kanceláří „povýšil” na IT specialistu. Nicméně placen jsem byl za odvedenou práci editora. A personální změny vedly k tomu, že zakázky které mne živily začal nový obchoďák přihrávat svým kamarádům. Proto jsem tuhle firmu asi po roce opustil, abych místo toho nastoupil na přední webový portál v ČR, kterým byl tehdy prudce expandující Atlas.cz jako pracovník helpdesku – v Praze. Trvalý pracovní poměr v Praze již nebylo možné kombinovat s denním studiem v Brně a měl jsem také jiné zájmy. Proto jsem studium ukončil, abych pracoval dále na živnost jako IT poradce. Ale velice záhy jsem zjistil, že mne podnikání nebaví. Přerušil jsem živnost a v květnu 2003 byl vybrán v rámci výběrového řízení na pozici webmastera ÚMOb Ostrava-Jih, který patří k nejlidnatějším městským obvodům v České republice. Tam 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 krátce před mým nástupem (v květnu 2003) nahradily původní terminály linuxové stroje. Což byl i jeden z důvodů, proč jsem byl přijat. Fungovaly jako dataless node – neboli tlustý klient, který využíval datový prostor na SCO serveru k uložení 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 dnes již zesnulý, Jozef „Bedřich” Perzyna (*1963 – †2022), můj budoucí šéf. Během pohovoru se mne zeptal na nějakou blbost ohledně MS Windows a když jsem mu upřímně řekl, že tenhle systém už je mimo okruh mého zájmu protože mne zajímá Linux, bylo rozhodnuto.
    Citace z článku Jak jsem se dostal k vývoji disklessové infrastruktury, autor Aleš Kapica (*1969)
  2. Překrytí NFS adresáře pomocí unionfs použil Pavel Píša již roku 2005.
  3. 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)
  4. Odseparovat adresář s balíky instalovanými z distribučními repozitářů a překrýt ho dalšími vrstvami bylo možné až poté, co se do linuxového jádra dostal modul overlay, který to umožnil. Jenže nebylo to hned. Původní verze modulu overlay, vyvíjená od roku 2010 pod názvem overlayfs, uměla – stejně jako aufs, sloučit pouze dva adresáře. Ale kód přejmenovaného modulu, který byl začleněn roku 2015 do hlavní vývojové větve jádra for-next obsahoval změny, které umožnily sloučit do jednoho sendviče několik vrstev najednou. Jenže to mělo háček – overlay neuměl sloučit adresář, který byl namountován přes NFS. Provizorní řešení přes aplikaci unionfs a modul fuse se mi podařilo najít v únoru 2016. Disklessové stroje sice měly o něco horší výkon při diskových operacích, ale umožnilo nám to opustit aufs, které vyžadovalo kompilaci vlastního jádra. A protože jsem od dubna 2016 začal pracovat také pro DC, nasadil jsem (od září 2016) stejnou diskless infrastrukturu také tam. To už byl problém s překrytím NFS u modulu overlay vyřešen, takže jsem se mohl zbavit závislosti na kombinaci unionfs a fuse. A když už jsem byl v tom, přepsal jsem rovnou skript overlay tak, aby podporoval více vrstev.
    Citace z článku Jak jsem se dostal k vývoji disklessové infrastruktury, autor Aleš Kapica (*1969)
  5. Více v kapitole Zavádění bezdiskových strojů.
  6. Viz – Přehled vývoje infrastruktury pro diskless Debian na katedře DCE.