Full-Diskless

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: 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ů.

Popis

Jádro získá IP adresu rozhraní, přes které si připojí systém nasdílený přes NFS, při zavádění jádra přes PXE. Ramdisk i jádro si klientská stanice stahuje přes TFTP.

FAQ

Zavádění skončilo v (initramfs)

Nejprve je třeba zjistit, v jaké fázi došlo k selhání.

Existuje-li namountovaný adresář /root/run, tak by měl obsahovat tyto soubory:

net-enp0s2.conf – s konfigurací sítě z DHCP. Jeho název se může měnit v závislosti na názvu ethernetového rozhraní. Obsahuje důležité proměnné: HOSTNAME, IPV4ADDR, ROOTSERVER

sandwich – je výchozí bod pro zjistění, které NFS adresáře se podařilo namountovat

nfsroot – je stažený soubor s konfigurací

Vždy je příčinou selhání lidská chyba!

Následující pořadí odpovídá krokům nezbytným pro analýzu příčiny selhání:

1. Natažení jiného konfiguračního souboru do nfsroot (natahuje se ten správný soubor?)
2. Překlep v konfiguračním souboru nfsroot (jsou namountovány všechny vrstvy?)
3. Změněná IP adresa NFS serveru
4. Změněná cesta k mountované vrstvě
5. Zapomenutý záznam pro vyexportování příslušné vrstvy
6. Chybně nastavena přístupová práva k vrstvě (místo rw uvedeno ro, špatný rozsah IP adres, aj.)