Problém vizualizace

21.3. 15:54 | Přečteno: 1598× | Za vším hledej Linux | poslední úprava: 22.3. 17:42

Často, když se někomu pokouším objasnit nuance disklessové infrastruktury narážím na skutečnost, že si protistrana nedokáže dát do souvislosti zdánlivě nesouvisející fakta. Napomohla by vhodná vizualizace. Jenže mě nenapadá, jak by měla vypadat.

Zkoušel jsem najít alespoň něco podobného, čím by se dalo inspirovat na internetu, ale bez použitelného výsledku. Pokusím se to tedy alespoň okecat a třeba se najde někdo, kdo na základě toho něco použitelného najde.

Jde o to, že potřebuji dát do vzájemného vztahu omezení ze strany propustnosti internetové sítě s tím, jak v průběhu času nabobtnal objem používaného software.

Výchozí stav v roce 2008 byl takový, že na jednom laboratorním stroji (všechny byly víceméně identické) se 120GB HDD a 1,5 GB ram vedle sebe paralelně existovaly tři lokální instalace MS Windows, včetně software. Stroje disponovaly 100Mb ethernetovými kartami a po síti zaváděly disklessový debian ze serveru, který komunikoval s laboratorním switchem 1Gb drátem. Obsluhoval dvě laboratoře, které měly celkem 42 strojů a výuka na nich probíhala pouhé 2 dny v týdnu, v době od 8:00 do 18:00.

Do současné doby vše prošlo několika mezistavy. Upgradovala se síť, upgradovaly se stroje, aktualizovaly se distribuce a přibyly hromady dalšího SW.

Už dávno neplatí, že by se ten diskless využíval jen po dva dny v týdnu a o pracovní době. Používá se furt a nejenom při výuce. Studenti k němu mají přístup prakticky kdykoliv. Na fyzických i virtuálních strojích.

Nelze ani přesně říct, kolik obsluhuje lokalit, protože se NFS exportuje také do Dejvic. Ne že by se tam ten diskless používal nějak často, ale během posledních dvou týdnů ho pár lidí použilo.

Instalace tak pokrývá množství strojů, roztodivných HW kombinací, poskládaných v laboratořích jak šel čas, takže u nich velikost RAM kolísá od 16 ke 4 GB, kde to zachraňuje lokální swap. A na DCE je na disku rozlezlá už pouze jediná instance MS Windows 10, ve které je naplácaný veškerý SW protože víc instalací by se na disk stejně nevešlo.

Na DC žádná lokální instalace není. Používá se tam Half-Diskless, protože některé dráty v laborkách co vedou ke strojům už nejsou v kondici. Stroje sice mají stroje k dispozici 1Gb ethernet (až na TurtleBoty, co komunikují jen přes Wi-Fi), ale drát jim stejně víc než 100Mbit nedá.

Ovšem jak vysvětlit nezasvěcenému, že spouštění Half-Disklessu je pomalé kvůli molochodidní základní distribuční vrstvě, do které je naslintaná za posledních 15 let hromada zbytečného software, kterou je potřeba oddělit? Jenže kdo mi řekne co už je zbytečné a co ne? Každého zajímá jen to co v tom systému nemá a když odejde, prd se stará, že to tam zůstane.

Mohl bych tu kontrolu vypnout, ale ty stroje tak staré, že se jim nedá věřit, proto se musí před spuštěním zkontrolovat keš, jestli nebyl nakešovaný soubor poškozen a Btrfs, které je v tomhle případě jen v single-mode nemá implementovaný mechanismus na úrovni FS, který by umožňoval rychlou kontrolu konzistence velkých souborů.*

Je to zkrátka něco za něco. Spolehlivost a robustnost na úkor rychlosti zavádění. Stroje které kontrolují keš nezatěžují síť, o to rychleji se tedy kešují soubory tam, kde je to třeba.

Tam, kde se více strojů pere o jeden drát či AP, nebo kde se dotahuje přes NFS SW do RAM na pozadí, je limitující propustnost sítě na AP resp. na switchi. Pozorovatelné je to na tom, za jak dlouho se stáhnou soubory přes PXE a kdy se objeví přihlašovací obrazovka.

Ty stroje najíždějí různě. Taky je to vidět, že switch neobsluhuje všechny porty stejně rychle, když prostřednictvím disklessu klonujeme lokální OS. Teoreticky by měl obsluhovat všechny stejně, ale není tomu tak. Starší switch, který měl uplink 1Gb to tak dělal – klonovali jsme tehdy multicastem. Ale novější s uplinkem 10Gb rozhazuje data po skupinách a v důsledku toho klient v průběhu klonování multicastem u pomaleji obsluhovaných strojů popadal.

*) Existuje sice pro starší verzi Btrfs patch, který umožňuje udělat dump kontrolních součtů. Ale prakticky je nepoužitelný, protože na různých strojích ten dump vypadá jinak a některé ho nevrací vůbec. Zřejmě tedy záleží i na tom, jaká verze Btrfs je použita, když se ta lokální keš zakládá.

Tak už to mám

Tohle je například vizualizace, kde je názorně vidět, kolik času zabere příprava laborky.

Před mým nástupem se instaloval lokální operační systém laboratorních strojů s využitím externího boxu.

Od roku 2013 se začal k distribuci využívat diskless a můj skript ntfs-radio.sh.

Takže pro ty, kterým nestačí pouhá čísla je zde pro názornost graf, který demonstruje v čem byl ten pokrok.

Uvedené časové intervaly jednotlivých operací odpovídají reálu. Rozdíl je pouze v tom, že v reálu se nedistribuuje systém na 5 strojů, ale 21. Takže se nejprve připraví klon a rozsypává se až odpoledne.

Příprava operačního systému stroje A na klonování je kritická hlavně když se dělá pouhá aktualizace. Před klonováním se musí vyhodit z domény. A pokud na to zapomenete je o zábavu postaráno. A také musí obsahovat veškerý software, protože dodatečná instalace znamená několikahodinový kolotoč kolem těch strojů, kdy vám jde ze zadávání hesel hlava kolem.

Vizualizaci následujícího kódu si můžete udělat zde. Já mám na to v rámci svojí wiki Widget:Graph.

gantt
    title Kolik času zebere příprava laborky k provozu
    dateFormat  hh:mm
    axisFormat %H:%M
    section Čas instalace za použití instalačního média a externího boxu
    Příprava instalačního média  :a1, 08:30, 1h
    Instalace stroje A  :a2, after a1  , 30m
    Instalace B  : a3, after a2  , 30m
    Instalace C  : a4, after a3  , 30m
    Instalace D  : a5, after a4  , 30m
    Instalace E  : a6, after a5  , 30m
    section Příprava stroje A na klonování
    Příprava stroje A na klonování : crit, b1, after a2  , 10m
    section Čas instalace za použití externího boxu
    Uložení image stroje A na box  :active, b2, after b1  , 30m
    Klonování B  : b3, after b2 , 30m
    Zadoménování stroje A : done, after b2, 2m
    Naklonování C  : b4, after b3  , 30m
    Zadoménování stroje B : done, after b3, 2m
    Naklonování D  : b5, after b4  , 30m
    Zadoménování stroje C : done, after b4, 2m
    Naklonování E  : b6, after b5  , 30m
    Zadoménování stroje D : done, after b5, 2m
    Zadoménování stroje E : done, after b6, 2m
    section Čas distribuce naklonováním za ideálních podmínek
    Uložení image stroje A na server   :active, c1, after b1  , 30m
    Zadoménování stroje A : done, after c1, 2m
    Distribuce na B : c2, after c1, 1h
    Zadoménování stroje B : done, c3, after c2, 2m
    Distribuce na C : c3, after c1, 1h
    Zadoménování stroje C : done, c4, after c3, 2m
    Distribuce na D : c4, after c1, 1h
    Zadoménování stroje D : done, c5, after c4, 2m
    Distribuce na E : c5, after c1, 1h
    Zadoménování stroje E : done, after c5, 2m

       

Komentáře

[Lukas]

Ja som obzcajny user nevyznam sa velmi do problematiky virtualizacie ale par postrehov.

vzdy ked si instalujem linux a skladam pc rozmyslam tak ze nie ako ti nacpe instalator napr Ubuntu ze jeden disk alebo ako su ludia zvykly rozdelovat disk na C D: , vzdy davam system na jeden disk a data na iny disk, pouzivam odelene systemovy a datovy disk. to to ci tie datove disky nejako prepojim to je uz ine inac super vecicka je toto ICY BOX RAID:

https://www.alza.sk/icy-box-ib-rd2253-c31-raid-na-2-2-5-sata-hdd-ssd-d9912759.htm?kampan=adw4_prislusenstvi-pro-it-tv_pla_all_prislusenstvo_externe-boxy_c_9062583___IBeb08_420984916731_~96772070556~&gad_source=1&gclid=EAIaIQobChMIlIqD0subjAMVw5aDBx0WrBw1EAQYASABEgJlVvD_BwE

dalsia vec je filesystem ako som psial som obycajny user ale aj ja kus experimentujem sksual som XFS ten sa rozbyl do dna po vypadku teda som zle vypol pc tak mu treba, lepsie skor nez potom keby tam boli uz skopyrovane data.

FreeBSD mnohy nedaju nan dopustit zo ZFS je cool ale ako ja stale ked si testujem FreeBSD tak davam UFS+SoftUpdates u SSD zapnute TRIM uz sa mi stalo tiez ze zly vypadok a u UFS plati ze zapisuje data s oneskorenim teda skor stratis data nez by ti ostali poskodene na disku.

Podla mna dokonaly sytsem s ktorym experimentujem je nieco na styl SLAX a don moduly Virtualbox a QEMU, zapnes pc nastartuje priamo do virtualboxu kde si vybereiem OS. sem tam zalohujem virtualy. je to takmer nerozbytny system.

[Want]

Nic ve zlém, pro tohle už vizualizaci dávno mám.

[Want]

Ale už mám i nápad, jak udělám tu vizualizaci. 8-)

[Dva disky v notasu]

Svaty Otce Nebesky uz je cas, zvoni! Prosime o urychlene uzdraveni Alese, protoze kdyz stune tak ma grafomanii a chrli do blogu nejen blbosti ale atakuje i hranici nesmyslu. Dekujeme, amen.

[_]

Parada, prace se stackem z roku 2013 za penize co byly adekvatni v roce 2013

[Want]

Ty jsi úplný engine agentury Kantar. Bacha ať si neskřípneš ty své křišťálové koule. Krom toho, sendvič není stack.

[plostenka]

Neumi Apparmor/Selinux reportovat do logu ktere binarky jsou spoustene? Pak staci jen vygrepovat logy za posledni rok...

[Aleš Kapica]

? Já neřeším pouze jeden stroj. Tady je lehký nástřel, protředí, kterého se to týká:

mindmap
  root((Hlavní
switch))
    Konektivita ven
    Rack A
        Disklessová
infrastruktura
        ::icon(fa fa-server)
        WWW servery
        ::icon(fa fa-server)
    Rack B
        Netapp
        ::icon(fa fa-server)
        VMware
        ::icon(fa fa-server)
    Laboratorní
switch AD
        Stroj A
        ::icon(fa fa-computer)
        Stroj B
        ::icon(fa fa-computer)
        Stroj C
        ::icon(fa fa-computer)
        Stroj D
        ::icon(fa fa-computer)
        Stroj E
        ::icon(fa fa-computer)
    Switch
        Wi-Fi AP
        Laboratorní
switch FJ
            Stroj F
            ::icon(fa fa-computer)
            Stroj G
            ::icon(fa fa-computer)
            Stroj H
            ::icon(fa fa-computer)
            Stroj I
            ::icon(fa fa-computer)
            Stroj J
            ::icon(fa fa-computer)

Ovšem to je pouze mapa. A jsou to sakra rozdíly mezi tím, když se zapne pouze jeden stroj o víkendu, nebo se zapnou v pondělí ráno všechny najednou.

Kolega, který loni zajišťoval disklessovou infrastrukturu pro Evropské mistrovství soutěže ICPC, to vyřešil distribuovanými NFS servery, které se spouštějí pouze v RAM. Jenže laboratorní diskless není relativně malý image který by se do ní vešel, ale moloch, co poskytuje několik desítek gigabajt nejrůznějšího software. Pouhá jedna verze MATLABu zabírá 25GB, a to jsou k dispozici verze tři.

[Aleš Kapica]

Ale ty reaguješ asi na:

hromada zbytečného software, kterou je potřeba oddělit? Jenže kdo mi řekne co už je zbytečné a co ne?

Není-liž pravda?

Z praxe ti mohu říct, že je to zbytečná ztráta času a rok je příliš krátká doba. Učí se různé předměty a některý software se používá častěji, a jiný zase jenom někdy. Pak do toho přistupují osobní preference. Někdo má oblíbený software, proto ho tam chce. I když ho mimo něj nikdo jiný nepoužívá. Analýzou využití sice odhalíš co se používá a jak často. Ale k čemu ti to je, když vyhozením té aplikace ušetříš jen několik bajtů?

To největší zvěrstvo je TEX

[plostenka]

Histogram pouziti presne řekne co už je zbytečné a co ne.

Ale k čemu ti to je, když vyhozením té aplikace ušetříš jen několik bajtů?

Tak snad odstranis cely balik, ne jen zastupce na plose... omg.

To největší zvěrstvo je TEX

Pouhá jedna verze MATLABu zabírá 25GB, a to jsou k dispozici verze tři.

Mate >75G instalaci texovych balicku? A mohla bych ji videt?

[Want]

Tex je momentálně součástí distribuční vrstvy a zabírá 6GB. Na vykynožení do samostatné vrstvy se pracuje, ale prioritu toho co dělám určují i jiné faktory.

[Aleš Kapica]

Jinými slovy. Tex, v samostatné vrstvě je v pohodě. V distribuční vrstvě – zlo.

[_]

Klasika, když si matláci zvolí špatně architekturu a použité technologie, tak s tím další desítky let tvrdohlavě bojují bez ohledu na okolní svět. Přece je jednodušší patlat další a další bash skripty než se učit cokoliv nového (Tex je s námi od pradávna, kdo do teď neví co s ním, to nebude vědět nikdy

[Want]

Je pouze jeden člověk, na kterého bych mohl ukázat prstem, který zuby nehty trval na smatlání distribuční vrstvy současného stavu, protože u full-disklessu je to fuk. Jenže už nejsme v dobách kdy se programátoři předháněli v psaní efektivního kódu.

V dnešní době se bohužel stalo zvykem, že si kdejaká blbost sebou táhne půl operačního systému, protože je závislá na specifických verzích, modulů narychlo splácaných v Pythonu, Go, Ruby, aj. Případně si sebou tahá zapakované chromium. A podle toho to pak vypadá.