Názory k článku Kexec: rychlý restart bez restartu

nikdy jsem poradne nepochopil, proc servery bootuji tak dlouho. Ale i vetsina normalnich desktopu stravi v biosu radove tolik, co potom trva cely zbytek bootu. Takze takovyhle rychly restart se mi libi. Ale stejne ho asi nikdy nepouziju, protoze rebootuju tak jednou za rok :-)

U me je to z duvodu bootu biosu SAS radice, a pak u kazdeho - hlavni BIOS se spousti az kdyz nabehne ME/BMC.

Chtelo by to info od nekoho kdo vlastni Supermicro desky jak s -F tak bez F, coz je ten management - zda to dela rozdil

25. 11. 2020, 01:12 editováno autorem komentáře

Při rebootu BMC (stejně jako iLO, DRAC atd.) přece nenabíhá, to je na restartu systému nezávislé. A jinak ruční restart BMC je otázka necelé minuty, alespoň u starších X9DR3-F, A1SAi, X10SLM-F a A1SA7-2750F, se kterými mám zkušenost.

Zalezi na masine. Pokud jde ILOM (neplest s iLO) tak u nekterych cervenych serveru vyzaduje i restart hosta - z duvodu update FPGA komponent a update BIOSu. Narozdil treba od Dellu cervene masiny maji v ILOMu casto i novy BIOS - treba zkontrolovat changelog a ten se updatuje az pri startu hosta.

I u DRACu kde jsou jednotlive firmwary pomerne dobre oddeleny bylo v nekterych pripadech doporucovano restartovat hosta co nejdrive to bude mozne.
Ono BMC si na tech platformach nezije uplne oddelene od zbytku systemu.

Proc neverim na napoj nesmrtelnosti? Protoze ho vyrabim a ty changelogy obcas posilame dellu,oracle,HP na integraci s jejich fw.

To je sice hezké, ale nahoře se psalo o Supermicru a o čekání na restart BMC při POSTu. Což se očividně automaticky neděje. :-)

HW diagnostika. A i kdyz preskocis vetsinu diagnostiky tak porad ti zbyva dost veci co musis zinicializovat sekvencne s prodlevami ale nemuzes to udelat hned.
Pokud ma treba server jen 8 cpu po 24 corech uz to hodne prodlouzi boot.

Je to dan za to ze vsechno je nacpano hromadou veci uvnitr SoC a i na obycejne PC se nabalila spousta HW subsystemu.

Inicializace nekterych inteligentnich sitovek ktere maji hodne offloadu, hromadu front, VxLAN filtering etc. je proste za trest. Stejne tak radicu

Neni to tak dlouho co kompletni diagnosticky boot Slunickove Mx rady HW trval 30 minut. Pri diag bootu to osmatavalo i JTAG interface jednotlivych cpu boardu.

No zrovna dneska jsem restartoval server od HPE a trvalo to čistého času 2 hodiny, z toho cca 90% času server stál na "starting drivers".. Ale tohle je víceméně výjimka (vypadá to na bug v ILO), většinou to stihne do 15 minut (což je pořád dost), ale nedivím se, vzhledem k tomu co všechno ty "biosy" dnes umí (v podstatě startuje celý operační systém).

No, v podstatě startuje několik (a někdy i několik desítek) operačních systémů.

I těch 15 minut mi přijde jako opravdu dlouho. Myslím, že většina z toho co zdržuje bude reálně nějaká lenost výrobce/ dodavatele BIOSu resp. UEFI resp. firmwarů a různé další příliš dlouhé timeouty a checky.
Podle mě není nikde psáno, že by nemohl server bootovat v rámci třeba pár sekund + pár sekund pro operační systém. Nejen, že tam bude všude možně spousta prodlev stylem, radši tam dáme par sekund sleep a nemusíme tu řešit nějaký souběh...
Různé činnosti jako RAM conditioning jistě lze rozdělit a bootovat dál s menším množstvím a zbytek jader a RAM připojit třeba později až se prověří. I několik TB RAM se přečte za pár sekund. Rozhodně na různé úrovně pseudo hot-plug jsou různé technologie v reálných serverech již dnes pod pojmem RAS zabudované a počítá se s tím i kvůli virtualizaci a různým big.little architekturám. Dnes už dokonce umíme udělat oboustranné USB, tak možná že by se i výměna CPU nebo RAM za běhu mohla dostat z IBM mainframů do normálních 2-socketových serverů. Zavolal by se program třeba 'cpuunmount 0' nebo tak a potom by se prostě ten procesor vytáhl. Po připojení nového by se zavolalo 'cpumount 0' a bylo by. Podobně s RAM. A když jsme u toho, tak by mělo být rovnou možné i nastartovat dva nezávislé operační systémy na dvousocketovém serveru nebo aspoň vyměnit jádro za běhu systému (ano takový live-patch, ale čistěji, který by uměl třeba i "live-unpatch").
Omlouvám se, jsem trochu snílek :-)

CPU hotplug na většině dnešních systému už má:

echo 0 > /sys/devices/sys­tem/cpu/cpu6/on­line
grep "processor" /proc/cpuinfo

Spousta dalších zařízení má hotplug také (SATA...).

Pokud leností nazývate i to, že je certifikační proces/audit proběhl v cenově rozumné hladině pak ano. Ale obecně si myslím, že je to dáno tím, že servery se nerebootujou tak často aby zákazníka pálily jednotky minut (a někdy i desítky, nám ale vše bootuje do 5 minut) víc než spolehlivost a stabilita serveru. Ono natřískat něco funkcemi umí kdejakej "Acer" ale pak je to v servisu během záruční doby sedmkrát. To si nemůžete dovolit u serveru ani když je oprava plně hrazená.

Jak je mysleno toto?

Existuje jedna výjimka, kdy restart pomocí volání kexec není plnohodnotnou náhradou běžného restartu. Je to v případě, kdy obraz initramfs obsahuje kromě startovacího souborového systému také aktualizaci mikrokódu. Tu kexec provést neumí.

Protoze v prikladech mate specifikovan jak kernel, tak initramfs, takze nic nebrani tomu, aby nove initramfs aplikovalo microcode update.

Mozna je vyjimka jina a netyka se samotneho kexec - a to to, ze ten microcode update lze uzamknout proti pozdejsim aktualizacim (coz je imho blbost - ale muze to vynucovat bezpecnostni politika firmy, a pak kazdy update znamena chte-nechte cold boot).

Lze update micro-kódu dělat pouze pokud je procesor v RealMode? Teď mě napadá UEFI běží v RealMode? Předpokládám, že kexec nepřepíná režim procesoru a "jenom" udělá JMP do nového jádra.

UEFI jede v protected mode, zavedenému modulu se předává řízení na CPL=0. Pochybuji, že by pak bootloader (grub) po zavedení linuxového jádra přepínal zpět do real mode. Navíc update microcode se dá udělat i za běhu ( https://software.intel.com/security-software-guidance/secure-coding/loading-microcode-os ).

BTW Ano, při kexecu se nepřepíná režim procesoru, ale to "jenom" JMP do nového jádra je dost komplikované, alespoň na architekturách i386 a amd64 se musí předtím odehrát několik netriviálních věcí - ošéfovat power management (aby třeba zrovna nechtěl usnout), deaktivovat přerušení přeprogramováním PIC (aby se toho po CLI nenafrontovalo moc), nechat běžet jen první procesor a ostatní jádra zadusit, vypnout stránkování (resp. v long mode se vypnout ani nedá, takže nastavit identitní stránkování, tj. aby virtuální adresa=fyzická adresa) a udělat to tak, aby nejen nové jádro a jeho initrd, ale i zásobník a všechny potřebné struktury pro chráněný režim zůstaly i po zrušení stránkování na svém místě a dostupné. Pak se teprve dá skočit do toho správného entrypointu nového kernelu (entrypointů v kernelu je víc podle typu zavedení).

Jako RISC bych to asi neoznačoval. Mikrokód přece jen vypadá kapku jinak než normální instrukce. A architektury, co vypadají jako vnitřek moderních x86 se běžně označují jako VLIW (very long instruction word).

Ono to VLIW moc neni, jak Itanium tak amd gpu tenhle pristup opustilo.

Spravne pojmenovani rozkladu z x86 instrukci na vnitrek jsou uOps (mikro operace). Tyto se pak vykonavaji klidne paralelne z vice naslednych instrukci, kdyz ma procesor vicero paralelnich jednotek (od doby Pentia).

Ty uOps jsou blizko k RISC, to jo, ale je to jen prostredek - samotny vykon prinasi az ta moznost paralelizace a jine chytrosti.

> obdobně lze předat i aktuálně používaný startovací RAMdisk

Jak tohle funguje? Myslel jsem, že při bootu se provede pivot_root z initramdisku do „skutečného“ systému a původní initramdisk (rozbalený i to co tam nahrál předchozí zavaděč) se uvolní.

Nojo, ale jak to ten soubor najde v souborovém systému? To je skutečně zajímavá otázka a neznám na ni odpověď.

Nový kernel nehledá v tomto případě initrd na souborovém systému (bez initrd nemusí mít holý kernel drivery, aby se dostal na storage, dokonce menusí mít ani moduly filesystémů), ale má ho už přednačtený v paměti bootloaderem nebo kexecem. A k předání informace, kde se initrd nachází, slouží paměťové struktury známé jako linux boot protocol ( https://www.kernel.org/doc/html/latest/x86/boot.html , pole initrd load address a initrd size).

Trochu jiná situace je u přímého zavedení kernelu z UEFI (bez bootloaderu), tam si kernel načítá initrd sám z ESP pomocí volání do UEFI (umístění initrd dostane kernel na cmdline, https://wiki.debian.org/EFIStub ).

Mně šlo právě o to, co předá příkaz kexec novému jádru při použití funkce --reuse-initrd. Jenže teď, když se ponořuju hlouběji, nemůžu nikde tuhle volbu najít. Ovšem určitě jsem jí někde (vlevo dole) v manuálu viděl.

Tedy omluvám se za zmatek, zdá se, že volba na znovupoužití aktuálně běžícího RAMdisku přinejmenším v aktuální verzi kexecu není možná.

Kexec nebyl myslen pro zkracovani normalniho bootu. Je s nim spokeno spoustu problemu v ovlafacich napriklad grafickych. Kexec byl napsan pro kratkodoby replace kernelu pro dump ladicich informaci, a proto doporucuju mit nizka ocekavani. Mel jsem moznost testovat kexec na desitkach tisic serverech u ruznych zakazniku a problemy se objevuji velmi casto.

Napriklad petiteboot na Power platforme ale kexec pouzivs pro boot systemu. Tam s tim ale autori ovladacu pocitaji a je to otestovane.

"Snad každý, kdo se někdy osobně prováděl restart ve studené uličce datacentra, dokáže potvrdit, že POST u těchto serverů trvá nekonečně dlouho"

Neni to vec rychle kontroly RAM, kterou maji desktopy vetsinou vypnutu? U nas servery vzdy bootovali rychle, mozna kolem 30s nez funguje SSH a dalsich nekolik min nez bezi uplne vsechno.

SuperMicro: ne, samozřejmě kontrola RAM trvá (bývá jí tam taky podstatně víc), ale inicializuje se taky RAID a kde co, docela to trvá. V té studené uličce to člověku připadá nekonečně, naštěstí konzolu od KVM máme bokem a servery mají IPMI, takže v té uličce stojím jen než server zasunu do racku. Fyzicky k serveru musím skutečně jen při manipulaci s hardwarem.

Pokud nekdo pouziva SuperMicro tak chapu ze v te studene ulicce travi spoustu casu. Je toto pokus o troll? Mozna...

Delal jsem pro jeden cesky startup a tyto servery uz nikdy vic. Jakmile bezpecaci zacli resit certifikace tak po tom mnozstvi bugu a chybejicich fixech to byla posledni kapka. Nehlede na to ze servery v akci od dellu se velmi blizili cene za SM(cti Sado-Maso).

Pro malou firmu co ma levnou pracovni silu, hodne sluzeb na microservicy a koupi k jednomu supermicro dalsiho do vymeny to je mozna i strategie. Podobne jako treba google s levnymi PC. Ale ma to sve hranice.

25. 11. 2020, 10:44 editováno autorem komentáře

Taky mam se SM jenom spatnou zkusenost - kdyz na X8 pristupovalo lm_sensors i BMC k senzorum, tak to zrejme udelal kolizi a totalne pomatlo BMC - takze to chvili rvalo ze je to prehrate nebo umrznute, poustelo vetraky na plno - a to nejhorsi - vetraky zcela odstavilo.

Asi nejaky self-destruct mode, kdyz deska vi ze je po zaruce? :-)

My máme se SM zkušenosti i dobré i špatné. Ale stejně i Dellem a HPE.
Teda s HPE hlavně špatné, v době kdy jsme je měli tak měly zabugované firmwary kde čeho. U Dellů nám starší iDRAC zamrzal a byl nutný firmware upgrade (což je na legacy serveru s nápisem "nevypínat" docela oříšek, nakonec jsme ten software, co na něm běží, po restartu nějak zprovoznili).
Supermicra máme historicky hlavně na "levnou pracovní sílu", takže microcloudy bez raidu. To funguje dobře a startuje celkem rychle. Teď už nakupujeme i "dražší" supermicra a s těmi novými zatím nebyl problém. U starších strojů s hw raidy nám tyto občas odcházejí, ale nejen u supermicra.

3. 12. 2020, 00:15 editováno autorem komentáře

Ta rychla kontrola ram se dela i u quick bootu.
Minimalne potrebujes stahnout konfiguraci pameti z modulu, zjistit jestli je to kompatibilni se stavajici konfiguraci, nastavit casovani a inicializovat. To je naproste minimum co je nutne udelat. Mozna jeste procistit kriticke pametove lokace.
Spravne se ma nulovat vsechno a cele pameti projet rychlym testem, nicmene ve vetsine konfiguraci to lze preskocit.

> Spravne se ma nulovat vsechno a cele pameti projet rychlym testem, nicmene ve vetsine konfiguraci to lze preskocit.

Pokud ovšem nemáte ECC, tam by to mohlo vést k chybám pri čtení nevynulované paměti.

Predpokladam ze BIOS vi, ze pri cteni ECC pameti z cold-bootu by dostaval jenom chyby, takze tu pameti zapisuje, ale to je otazkou par vterin (mozna to ale dela per radic, takze vzdy ta incializace jede v 1ch rezimu).

OS pri normalnim provozu necte nahodne pametove lokace - vzdy se neco prvne zapise. A alokator virtualni pameti funguje tak, ze v pripade page-fault pro oblast ktera patri do alokovaneho rozsahu to vytvori novou stranku - a vynuluje ji. Tohle se deje na nejnizsi urovni v kernelu.. takze nechapu jak a kdy by jste chtel cist fyzickou pamet, ktera nebyla dotcena.

Presne tak. OS navic muze pri bootu udelat jeste scrub pameti mimo kernel space pro jistotu - zalezi co ma clovek za OS nebo hypervisor. Tady nelze generalizovat.
Dale je treba zminit ze delat nulovani u serveru ktere maji TB pameti (coz uz je dnes bezne) a pamet funguje v omezenem rezimu pri POSTu neni uplne optimalni na rychly boot.

kexec používám od dob jader 2.6.x, ale funguje mi to dobře jenom někde. Obecně je problém s tím, že na rozdíl od zavedení jádra po POST, kdy jsou periferie v definovaném stavu, jsou u zavedení nového jádra přes kexec ve stavu, v jakém je ponechaly jejich ovladače. Na první pohled to bývá rozpadlá grafika, ale v dmesg se pak člověk kolikrát dozví další překvápka a třeba taková síťovka (myslím, že to byl nějaký starší Broadcom) s nemožností zavést její firmware, sice je vidět, ale už nejde nahodit do stavu up, takže to pak člověka stejně donutí projít plným restartem.

Pokud driver spoléhá na to, že je zařízení v určitém počátečním stavu, místo toho, aby ho řádně inicializoval, je to bug. Ne že by se to občas nedělo, ale naštěstí už podstatně méně než kdysi.

Tezko rici hlavne u zařízení které musí fungovat už před bootem OS je to složité. Po bootu se jeste treba nahrazuje aktualni firmware. Musi se prevzit hodnoty jinam. Dnesni hw je nechutně složitý proti tomu pred 20ti lety.Třeba ta grafika nebo řadiče. I ty hloupe stovky mají dneska svůj nezávislý management
který funguje třeba i po vypnutí.
Nedivil se že spousta hw to nemá odladene. Je to další test který někdo musí udělat.

25. 11. 2020, 14:11 editováno autorem komentáře

Jo, souhlas, ale narazil jsem kdysi na nějaké I/O karty (asi SDLC, už fakt nevím), které už jednou zinicializované nešly softwarově zinicializovat znovu - prostě potřebovaly pro inicializaci "šťouch" ze sběrnice v podobě signálu RESET. Byla to docela pakárna, protože některé základní desky posílaly kartám aktivní RESET i při warm restartu (Ctrl+Alt+Del), ale jiné to dělaly jen po zapnutí nebo zmáčknutí resetu na bedně.

Inicializovat zařízení vždy do počátečního stavu je snadné, ale ne vždy žádoucí. Třeba problikávání obrazovky při přepínání grafických módů už dnes není považováno za normální součást bootu počítače. Stejně tak nepotěší reset USB sběrnice – při bootu si rozsvítím klávesnici, zapnu Num Lock, načež se resetuje USB a vše zase zhasne.

@Filip Jirsák

Nikdo neříká, že to musíte inicializovat hloupě - tedy resetovat vše "na nulu" a bez ohledu na aktuální stav. Sdělení je o tom, že na konci postupu by mělo být zařízení v souladu se stavem, o kterém ví systém a může s tím dál pracovat. Inicializace klidně může přeskočit kroky vedoucí k problikávání obrazovky - když ovšem víc co dělá.

Asi si každý představujeme pod slovem inicializace něco jiného. Já jsem nepsal nic proti uvedení zařízení do definovaného stavu, psal jsem právě o inicializaci.

Opravdu není v příkladech použití ani zmínka o kdumpu? To je docela překvapivé.