Kategorie:Diskless

Z DCEwiki
Skočit na navigaci Skočit na vyhledávání

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

Pojmy „tenký klient” (thin client) a „tlustý klient” (fat client) se začaly používat během 80. let 20. století, kdy terminál začalo z úřednických stolů vytlačovat PC (zkratka z angl. Personal Computer – „osobní počítač”).[1]

„Tenký klient”
Je konstrukčně mnohem jednodušší zařízení než PC. V podstatě jen klávesnice s monitorem a port, k zapojení kabelu přes který komunikuje s centrálním počítačem – serverem. Stejně jako Full-Disklessový systém tedy závisel na persistentním (stálém) připojení do aktivní sítě. Bez připojení k běžícímu serveru to zařízení bylo samo o sobě nepoužitelné.

„Tlustý klient”
Je použitelný i bez aktivního připojení na server. Tuhle podmínku splňovalo PC – osobní počítač, protože měl vlastní operační systém, uložený na lokálním blokovém zařízení (původně disketě, později rotačním disku), na který si mohl odložit z RAM data, když jí nebylo dost, nebo když připojení na server nebylo zrovna k dispozici. Oproti klasickému terminálu je to dražší zařízení, protože obsahuje více součástek, a to pro změnu zvedalo pravděpodobnost, že dojde na poškození nebo ztrátu uložených dat pokud některá z nich selže.

Diskless node
Se objevil na scéně především proto, aby odlehčil centrálnímu serveru, který měl své fyzické limity. Jeho výkon nebylo technicky možné navyšovat do nekonečna a přenesením operačního systému do RAM klienské stanice, se šetřila jeho RAM a výkon CPU. Využíval se především při práci s grafikou. Výpočetně náročné úlohy, spojené s interpretací dat a zobrazením výsledku na monitoru, počítal HW klienta (jeho lokální CPU + grafická karta) a server, řešil pouze operace spojené s distribucí a ukládáním dat. Ušetřenou RAM mohl využít pro nakešování často používaných souborů, takže je nemusel pokaždé hledat na pomalém disku. A ušetřený výkon CPU mohl využít k lepší kompresi přenášených dat, což mělo příznivý vliv na propustnost sítě.

Dataless node
Synchronizace uživatelských dat a zálohování je věčný problém všech Non-Diskless systémů, co svá data primárně drží u sebe. Protože objem přenesených dat za jednotku času limituje propustnost sítě. Ethernetový kabel si lze představit jako vodovodní trubku, kterou za určitý čas proteče jen omezené množství vody. Je-li skupina strojů připojená do sítě switchem který tlačí veškerá IN/OUT data přes jeden 1Gb port, jde o „trubkou”, přes kterou za 1 sekundu proteče maximálně 128MB, ale jeden Full-Diskless, dříve než se na něj vůbec někdo přihlásí, si po síti při každém startu z NFS serveru stáhne zhruba 300 MB dat, takže čím větší bude skupina těch strojů, tím pomalejší bude start každého z nich. Viz Omezující faktory u TurtleBotů. Proto se začaly místo terminálů využívat PC, aby se nepřenášely po síti data nutná pro běh operačního systému.
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

Terminologie disklessu

Poznámka Podrobnější popis naleznete na stránkách věnovaných na příslušným termínům
  • Non-Diskless – sebemenší problém vyžaduje fyzickou přítomnost administrátora, který ho musí analyzovat a zjistit, zda je příčinou zlý úmysl, chyba na straně hardware, software, či konfigurace. A centralizovaná správa vyžaduje další, specializovaný software, který je nutné průběžně udržovat.
  • Full-Diskless – má centralizovanou správu a protože nepotřebuje k životu lokální blokové zařízení, je ideální také pro vzdálenou údržbu lokálně instalovaných Non-Diskless operačních systémů. Ale nefunguje bez persistentního připojení!
  • Half-Disklessje závislý na lokálním blokovém zařízení, ale bez něj se automaticky spouští jako Full-Diskless, pokud má možnost připojení, protože využívá stejný systém konfigurace i centralizovanou správu. Může fungovat autonomně, i na síti s velmi nízkou propustností (např. přes Wi-Fi), protože pracuje s kešováním souborů a je velmi robustní z hlediska zabezpečení.
diskless scheme.svg

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.

Slovník

Lokální úložiště
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).
  • Nakešováním systémové vrstvy a velkých souborů používaných při výuce lze vylepšit propustnost sítě.

Lokální swap
Připojením lokálního 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).
Diskless linux
Linuxový systém, který nevyžaduje pro svůj běh lokální blokovém zařízení, protože veškeré IO operace probíhají po síti: disklessový systém ↔ NFS server. Takovým způsobem fungují servisních servery, které jsou součástí disklessové infrastruktury. Konkrétně stroj k333-dhcp (DHCP), či k333stu1 (LDAP) na katedře DC, nebo stroj k2 (DHCP) na DCE.
Linuxový diskless s overlayem
Disklessový linux, u kterého je z jednotlivých vrstev sdílených přes NFS sestaven v ramdisku sendvič, který se překryje virtuálním diskem, který existuje v RAM pouze po dobu aktuálního sezení – při restartu se všechny změny zahodí. Na rozdíl od běžného diskless linuxu tečou data pouze směrem: disklessový systém ↔ lokální RAM ← NFS server. Takto fungují běžné laboratorní počítače a virtuální SSH proxy[2]turtle a postel.
Diskless s lokální keší
Je diskless linux u kterého se využívá lokální blokové zařízení pro uložení přenesených souborů, aby se nemusely (pokud u nich nedošlo ke změně opakovaně po restartu přenášet po síti. Data se přenášejí takto disklessový systém ↔ lokální disk ⇤ NFS server. Lokální keš v kombinaci s overlayem: disklessový systém ↔ lokální RAM ← lokální disk ⇤ NFS server se používá u TurtleBotů.

Uživatelé

Specifikem linuxových disklessů je, že na rozdíl od běžného desktopu mají lokální uživatelé jen omezený rozsah toho co by mohli, ať již záměrně, či nevědomky rozbít.

Lokální uživatel
Nemá domovský adresář připojený z centrálního úložiště a jeho lokálně uložená data se při restartu stroje zahodí. Takový efekt má (mimo jiné) použití vrstvy isolate

Uživatel
Většina uživatelů a má při práci s linuxovým desktopem svůj domovský adresář připojen z centrálního úložiště.

Lokální root
Privilegovaní uživatelé, co znají heslo lokálního roota (typicky vyučující a svičící) mohou v rámci lokálního stroje dočasně zasahovat do konfigurace běžícího stroje, kupř. když chtějí nainstalovat a otestovat nový software – po restartu ale disklessový stroj s overlayem opět najede ve výchozí konfiguraci!
Privilegovaní uživatelé
Do této kategorie spadají vyučující, cvičící a vybraní studenti.
  • mohou znát heslo na lokálního roota
  • zadávají požadavky na software, který potřebují k výuce, a podílejí se na jeho testování
  • v opodstatněnách případech mají možnost zasahovat do obsahu na straně NFS serveru[3]

Administrátor disklessové infrastruktury
Má přístup na NFS server a tím pádem může zasahovat do všech vrstev. Může měnit konfiguraci NFS a DHCP serveru, a zasahovat do souborů sdílených přes TFTP (jádro, ramdisk, konfigurace, PXE menu, atp.). Viz Disklessová infrastruktura - administrace

Disklessové technologie, jak byly aplikovány v čase

  • překrytí NFS adresáře, tzv. overlay se využívá od roku 2007
  • od roku 2011 se využívá zavádění disklessového linuxu přes PXE
  • virtualizační skript kvm se používá u diskless infrastruktury od roku 2012 (vlastní technologie)
  • stack byly zavedeny v roce 2016 (vlastní technologie)
  • Half-Diskless boot systém se používá od září 2018 (vlastní technologie)
  • od roku 2019 se používá dynamický ramdisk, který umožnil zjednodušit konfiguraci zavaděče a centralizovat správu disklessové infrastruktury (vlastní technologie)

Po dvouleté kovidové pauze, roku 2023, se podařilo:

  • … dokončit sjednocení systému laboratorního linuxu v rámci kateder DCE a DC, včetně používaných uživatelských účtů, které započalo rokem 2019
  • … zbavit disklessovou infrastrukturu závislosti na distribuovaném úložišti (CEPH)
  • … dořešit autonomní diskless (vlastní technologie)

V březnu 2025 začaly práce na rozdělení základní systémové (distribuční) vrstvy.

direction a suivre 3 yve 01.svgČíst dále..

  1. Cena PC v letech 1989–1995 prudce klesla. Jaký byl poměr ceny PC v roce 1991 vůči průměrné mzdě, se můžete dočíst v retrospektivním článku: Jak jsem se dostal k vývoji disklessové infrastruktury
  2. SSH proxy jsou virtuální disklessové systémy, dostupné z vnější sítě, které umožňují vzdálený přístup na fyzické laboratorní stroje.
  3. Všechny vrstvy, včetně základního systému, na straně NFS serveru jsou by default exportovány v režimu RO (jen pro čtení). RW zápis přes NFS jen pro vybranou IP adresu může povolit jen administrátor disklessové infrastruktury.
    RW připojení vrstvy exportované z NFS na vybraném stroji
    Je výhodné především proto, že lze takovým způsobem použít vrstvu i v rámci virtuálního kontejneru, vytvořeného přes systemd-nspawn. Z hlediska disklessové infrastruktury jde o velmi rizikové řešení
    SSH jail
    Původně se používalo tohle řešení na straně NFS serveru. Není tak rizikové, jako přímý mount přes NFS, ale vyžaduje speciální konfiguraci SSH. Proto je výhodnější využít kombinaci vrstvy vyexportované v režimu RW (čtení-zápis), namountované na servisní virtuální stroj – NFS export může být realizován přes interní IPv4 nebo local linkovou IPv6 adresu stroje.