Disklessová infrastruktura

From DCEwiki
Jump to navigation Jump to search
Disklessová infrastruktura zajišťuje provoz linuxového desktopu virtuálních i fyzických strojů v rámci katederní sítě. Jde o soustavu fyzických a virtuálních serverů, poskytujících tyto základní služby:
  • sdílení souborů přes NFS<ref>

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. </ref>, případně skrz CIFS<ref>

Použití CIFS má smysl jen pokud jde o data sdílená i na strojích s MS Windows.</ref>

  • přidělování IP adres přes DHCP
  • poskytování linuxového jádra, ramdisku a konfiguračních souborů přes TFTP<ref>

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. </ref>

  • ID uživatelů a jejich ověření (LDAP, resp. Microsoft AD)
Od roku 2005<ref>

Více viz kapitola Přehled vývoje infrastruktury pro diskless Debian na katedře DCE

</ref> se stalo disklessové řešení na FEL ČVUT velmi sofistikovanou záležitostí, proto by mělo, jako další logický krok, následovat vytvoření webové aplikace, která by usnadnila správu disklessové infrastruktury a umožnila generování konfiguračních souborů pro sestavení systému pracovních stanic a serverů, také uživatelům na nižší úrovni, než je administrátor disklessové infrastruktury. Více viz níže.

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

U linuxového disklessu s overlayem

Lokální uživatel
Je každý, kdo pracuje s linuxovým desktopem.
Uživatel
Je uživatel, který pracuje s linuxovým desktopem a má svůj domovský adresář připojen z centrálního úložiště.
Privilegovaní uživatelé
Jsou uživatelé, co mají nadstandardní přístup do vybraných vrstev – zpravidla vyučující a cvičící.
Lokální root
Privilegovaní uživatelé co znají heslo lokálního roota mohou v rámci lokálního stroje dočasně zasahovat do konfigurace běžícího stroje – po restartu disklessový stroj s overlayem vždy najede ve výchozí konfiguraci!
Administrátor disklessové infrastruktury
Má přístup do nejnižších vrstev. Tj. ke konfiguraci NFS serveru, DHCP serveru a souborům sdíleným přes TFTP.

Omezení disklessu s overlayem

U laboratorních strojů najíždí diskless vždy s overlayem!

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


<references />