Disklessová infrastruktura

Z DCEwiki
Skočit na navigaci Skočit na vyhledávání
Obsah
Základem disklessové infrastruktury co distribuuje bezdiskový linuxový systém v rámci katederních laboratoří aj., je fyzický, virtualizační server, kde běží pouze NFS[1] server. Ostatní služby potřebné pro její funkcionalitu poskytují virtuální disklessové stroje. Ty zajištují:
  • přidělování IP adres přes DHCP
  • poskytování linuxového jádra, ramdisku a konfiguračních souborů přes TFTP[2]
  • ověřování ID uživatelů přes LDAP, resp. Microsoft AD
  • sdílení dat přes jiné protokoly. Jako HTTPS, CIFS[3] a jiné.

Od roku 2005, kdy se začal diskless na FEL ČVUT používat, prošla tato infrastruktura vývojem, který je dokumentován v rámci přehledu vývoje disklessové infrastruktury na katedře DCE a DC.

V současné době už jde o velmi sofistikovanou záležitost, a toto je manuál pro administrátora disklessové infrastruktury, jehož cílem je objasnit fungování této infrastruktury od NFS serveru, až po sestavení distribuovaného systému pracovních stanic a serverů a řešení případných problémů.

Slovník

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[4] – 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é
Kromě toho že znají heslo na lokálního roota, mohou mít také nastaven nadstandardní přístup do vybraných vrstev na straně NFS serveru. To lze realizovat několika způsoby o kterých se zde zmíním v samostatné kapitole.
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.).

Vrstvy

Původně byl laboratorní diskless namaštěný do jednoho adresáře, sdíleného přes NFS. Software, který nebyl standardní součástí distribuce se instaloval do adresáře opt.

Situace na katedře kybernetiky si vynutila vznik konfiguračních vrstev a při té příležitosti byl od základní vrstvy oddělen také opt a přešlo se na sendvič (viz níže).

A od léta 2019 se začal software, z původního adresáře opt separovat do samostatných aplikačních vrstev vrstev.

Základní vrstvy

Základní systém, instalovaný a aktualizovaný z distribučních repozitářů

Aplikační vrstvy

Vrstvy, do kterých se instaluje software, který není součástí základní distribuce.

Jejich součástí mohou být také knihovny, které v základním systému již, nebo ještě nejsou.

Do vybraných aplikačních vrstev mohou zasahovat také privilegovaní uživatelé.

Konfigurační vrstvy

Jsou velmi tenké vrstvy, které obsahují konfigurační soubory, skripty aj.

Typicky sem patří vrstvy pro nastavení přístupu na LDAP, konfiguraci stroje v režimu SSH proxy, atp.

Sendvič

Tento výraz se používá pro sestavu vrstev, která se sloučí přes overlayfs. Sendvič sestavuje v případě disklessové infrastruktury na DCE a DC skript overlay, na základě konfigurace, kterou stahuje přes TFTP během zavádění skript nfsroot[5]

Původně se tímto způsobem spojovaly pouze adresáře připojené NFS, ale od roku 2019 se takto kombinují adresáře sdílené přes NFS přeplácnuté lokální keší.

Poznámka K sestavení sendviče dojde i v případě, že některá vrstva je momentálně nedostupná a to ještě před zavedením finálního systému, kterému se pak sestavený sendvič jeví jako jeden kompaktní adresářový strom.

Které vrstvy se podařilo sestavit a v jakém pořadí, lze zjistit se souboru s názvem sandwich, který je rovněž k nalezení v adresáři /run

Privilegovaní uživatelé

Do této kategorie spadají vyučující, cvičící a vybraní studenti.

  • Znají heslo na lokálního roota
  • Dávají požadavky jaký software potřebují k výuce, a podílejí se na jeho testování
  • A v opodstatněnách případech mají možnost zasahovat do obsahu na straně NFS serveru

Pokud se týče naplnění posledního bodu, jsou možné (a aktuálně používané) tyto metody:

SSH jail na straně NFS serveru

Původní řešení, kterého je třeba se do budoucna zbavit, protože vyžaduje speciální konfiguraci na straně NFS serveru. Výhodnější je využít vrstvy vyexportované v režimu RW (čtení-zápis) pro servisní virtuální stroj. (export NFS by se mohl realizovat pro IPv4 nebo IPv6 adresu stroje, ze kterého by se měnila konfigurace v rámci webového konfigurátoru)

RW připojení vrstvy exportované z NFS na vybraném stroji

Výhodné především z toho důvodu, že lze takovým způsobem aktualizovat i základní systém v rámci virtuálního kontejneru, vytvořeného přes systemd-nspawn.

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í).

V případě potřeby se povolí RW zápis přes NFS pouze pro IP adresu vybraného stroje.

Poznámka V současné tobě to může udělat pouze administrátor disklessové infrastruktury, ale níže uvedený webový konfigurátor by mohl umožnit dočasné nastavení RW módu i privilegovaným uživatelům.

Webový konfigurátor

V současné době leží vše ohledně konfigurace disklessové infastruktury na administrátorech.

Ti připravují základní systém a jednotlivé vrstvy. Testují chování sendviče a v kooperaci s vyučujícími rozhodují o tom, co se v laboratorním systému octne, odlaďují chyby, a případně doplňují potřebné funkcionality.

Tím se ovšem základní systém rozrůstá o další a další softwarové vybavení, které je nutné do budoucna udržovat (závislosti, licence, lokální úpravy, aj.) a při větším počtu instalací různých linuxových systémů v rámci disklessové infrastruktury je neúnosné spoléhat na to, že si to někdo bude pamatovat. Proto je nutné vytvořit (ideálně webový) konfigurátor, který ohlídá:

  1. Závislosti vrstev – linuxové distribuce mají svá specifika, proto by se měl navrhnout systém kódového značení, který by to usnadnil. Při instalaci (a zavedení) nového základního systému by se měl tento objevit jako další položka. U vrstvy by měla existovat možnost nastavit kladným či záporným číslem úroveň vrstvy – výchozí 0 (úroveň base systému), záporná (potenciálně konfliktní či nebezpečná vrstva, kterou je nutné posadit na nižší úroveň) a kladná (vrstva musí být na vyšší úrovni). Asi by to mělo vypadat jako rolovací seznam vrstev s checkboxy, generovaný na základě kompatibility s base vrstvou – pro každou base vrstvu samostatný seznam – ve kterém by se změnou pořadí vrstev měnilo také pořadí pro sendvič u cílové konfigurace.
  2. Jejich aktuálnost – záznam by měl obsahovat konkrétní údaj do kdy se má vrstva udržovat, kdo si ji vyžádal a kdo bude v budoucnu oprávněn rozhodnout o to, jestli se má vrstva zrušit, nebo ne. Platnost od – do + textová poznámka. Vrstva, které by vypršela platnost by se generovala v seznamech podbarvená rudě.
  3. Testovací vrstvy – vrstvy u kterých by platnost od předcházela aktuální datum – v seznamech by se podbarvovaly zeleně.

Umístění

Mělo by jít o webovou aplikaci, běžící na vyhrazeném virtuálním stroji, který by měl přístup přes NFS k exportovaným adresářům.

  • Přístup může být pasivní (RO), ovšem pak by nebylo možné přes ni editovat soubory v .desc
  • Pokud by se přes ni měl nastavovat (a rušit) také NFS export či konfigurace DHCP, je třeba vyřešit vhodný mechanismus – jako ideální se mi jeví nějaký shellový wrapper (agent), se kterým by aplikace komunikovala přes ssh ověřované klíčem. Ten by mohl vkládat, komentovat či rušit záznamy v v konfiguračních souborech, a každou změnu pushovat do lokálního git repozitáře. Tím pádem by bylo snadné zjistit poslední změny i přes ssh konzoli, aniž by bylo nutné se přihlašovat přes web.



Schéma

  • Karta DHCP – každá infrastruktura může používat jiný DHCP server a u některé ho může být mimo správu administrátora disklessové infrastruktury
  • Karta Vrstvy – rodná karta vrstvy
    1. Vrstvy by se před toto GUI neměly zakládat, ale detekovat z nastaveného adresářového stromu na straně NFS serveru. Za vrstvu by se považoval první adresář s podadresářem .desc
    2. Typ vrstvy určený číslem, by určoval její prioritu v rámci sendviče. Base vrstva vždy 0. Záporné číslo by měly aplikační vrstvy které nespravuje administrátor infrastruktury. A kladné číslo by měly vrstvy konfigurační a aplikační spravované administrátorem.
    3. Závislost vrstvy na base systému – roleta s base vrstvami (s hodnotou 0) a checkboxy – ty zaškrtnuté by se braly jako kompatibilní.
    4. Období platnosti vrstvy, od – do. Vrstva, které by ještě nezačalo období platnosti by byla podbarvena zeleně. Naopak vrstva po období platnosti podbarvena rudě.
    5. Popis vrstvy, by se natahoval z adresáře .desc
  • Karta Sendviče – Sendvič zástupné jméno pro konfigurační soubor, se kterým by se pracovalo v kartě PXE.
    • Sendvič tvoří jedna base vrstva + vrstvy konfigurační a aplikační. Podle typu overlaye (aufs či overlayfs) by se natahovaly příslušné init skripty, které by bylo možné individuálně v rámci karty PXE u sendviče vypínat.
  • Karta PXE – hotové sendviče nabízené přes PXE
Sendvič by bylo možné přiřadit buď na základě hostname, IP, brány nebo skupiny.
  1. ↑ Systémová data se sdílejí přes NFSv3. Použití NFSv4 je v tomto případě zbytečné. Domovské adresáře se sdílejí vždy přes NFSv4.
  2. ↑ I když by bylo možné v ramdisku využít i stahování souborů přes HTTP protokol, v praxi je jednodušší využít TFTP server, přes který se sdílí i soubory PXE menu.
  3. ↑ Použití CIFS má smysl jen pokud jde o data sdílená i na strojích s MS Windows.
  4. ↑ 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.
  5. ↑ Aktuálně staženou konfiguraci naleznete vždy v rámci spuštěného systému v adresáři /run, rovněž pod názvem nfsroot. Na straně TFTP však jde o soubory s příponou .conf, co se stahují na základě nastavení, které stroj získá z DHCP (IP adresa, brána, hostname) či PXE menu (hodnota parametru name).
Citováno z „https://wiki.control.fel.cvut.cz/mediawiki/index.php?title=Disklessová_infrastruktura&oldid=35693“