kexec: rebootoljuk gyorsabban a Linuxot!

 ( trey | 2004. május 7., péntek - 15:43 )

Pont egy évvel ezelőtt írtam már a kexec-ről. Akkor még csak arról számolhattam be, folyamatban van a fejlesztése az akkor még fejlesztői állapotban levő 2.5-ös Linux kernelhez. Azóta már megjelent a stabil 2.6-os kernel is, úgyhogy nézzük mi változott azóta:

Abban az esetben, ha munkád nem követeli meg azt, hogy rebootold a Linuxod napjában többször, vagy nem dolgozol olyan környezetben, ahol a rendszer pár perces kiesése is gondot okozhat, valószínűleg nem fog érdekelni, hogy az operációs rendszered 20 másodpercet, vagy mondjuk 2 percet bootol. Ellenkező esetben megtennél mindent, hogy minél rövidebb időre csökkentsd a rendszered elindulásának idejét...
A gyors rendszerindítás annyira foglalkoztatja a kernel fejlesztőket is, hogy megszületett a kexec, amely pont ezt hivatott szolgálni. A kexec segítségével elérhetjük azt, hogy egy új Linux kernelt bootoljuk be anélkül, hogy keresztül kellene mennünk a bootloader-en. A kexec megkönnyíti a kernel fejlesztők, szoftver fejlesztők, ISP-k, és más olyan felhasználók életét, akiknek napjában többször is újra kell indítaniuk a gépüket, vagy az újraindítás időtartamát minél kisebbre kell szorítaniuk.
A kexec-nek egyetlen korlátja van jelenleg: csak 32-bites x86 platformon működik. Ahogy a számítógépek fejlődnek, és egyre bonyolultabb lesz a belső felépítésük, úgy számíthaunk arra, hogy egyre hosszabb lesz a rendszerek boot-olási ideje is. Az újraindítások időtartama egyre nagyobb, ha mondjuk sok eszközt kiszolgáló SCSI buszaink vannak, vagy a gépünkben nagy mennyiségű ECC memória van, stb. Az elvégzett tesztek szerint a bootolási idő jelentős részét a firmware szakasz adja (az a szakasz, amikor a rendszer felismeri és ``megszólítja'' a hozzákapcsolt fizikai eszközöket). Ha ezt a szakaszt át tudnánk lépni, akkor jelentősen lerövidíthetnénk a rendszer újraindításának idejét. A kexec pontosan ezt teszi.

Ahhoz, hogy megismerjük a kexec működését, fontos, hogy átlássuk a Linux kernel boot folyamatát. Ez a folyamat két részből áll: a bootloader szakaszból és a kernel szakaszból.
A bootloader szakasz fő részei a hardver szakasz, a firmware szakasz, az első szintű bootloader (first-level bootloader) és a másod szintű bootloader (second-level bootloader). A boot folyamat azzal kezdődik, hogy bekapcsoljuk a számítógépet. Bizonyos inicializálások után az irányítás a firmware-hez kerül. A firmware-t egyes architektúrákon hívjuk "BIOS" -nak is. A firmware felismeri az egyes eszközöket, pl. a memória kontroller(eke)t, busz eszközöket, háttértárakat, stb. Ezután a firmware a beállítások alapján átadja a vezérlést egy minimális bootloader-nek, amelyet Master Boot Record-nak (MBR) is hívunk. Az MBR vagy merevlemezen, vagy eltávolítható eszközön vagy akár ``hálózaton'' is lehet. A következő lépés az, hogy az MBR az irányítást átadja az operációs rendszernek. Ez a feladat már a másod szintű bootloader-re hárul (gyakran ezt nevezik boot loader-nek). Ez a boot loader teszi lehetővé a felhasználónak, hogy kiválassza a futtatandó kernelt, betölti a kernelt a memóriába a megadott paraméterekkel, inicializálja a kernelt, kialakítja a megfelelő futtatási környezetet, majd ``futtatja'' a kernelt.

Az előzőekben ismertetett szakaszokat hivatott áthidalni a kexec, hiszen a következő lépcsőfok már a kernel szakasz, ahol a kernel átveszi az irányítást.

Mi az a kexec?
A kexec Eric Biederman munkája, amely jelenleg is folyamatos fejlesztés alatt áll. A kexec egy kernel patch, amely lehetővé teszi, hogy egy futó kernelből egy másik kernelt indítsunk anélkül, hoyg végig kelljen mennünk a bekapcsolástól a másod szintű bootloader-ig terjedő szakaszokon. Közben nincs hardver reset, nincs detektálás és inicializálás, és semmi olyan lépés, amely lelassíthatná a boot folyamatot.

Hogy működik?
A kexec két részből áll. Egy kernel patch-ből és egy ``user-space'' segédprogramból, amely a kexec-tools névre hallgat. A patchel meg kell foltozni a kernelünket, majd egy kernelt kell fordítani a patchelt forrásból a CONFIG_KEXEC opciót engedélyezve. A kexec-tools segédprogramot le kell fordítani az operációs rendszerünkön.

A kexec használata:

# kexec -l kernel_image -append="kernel_paraméterek"

konkrétabban:

# kexec -l /boot/bzImage -append="root=/dev/hda1"

Ha a már futó kernelt szeretnénk rebootolni, akkor a

# kexec -e

paranccsal adhatunk utasítást erre.



A kexec patcheket és az user-space utility-t letöltheted a legfrissebb 2.6-os kernelekhez innen. Bővebb infót a kexec-ről az IBM developerWorks oldalain olvashatsz itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A trey/tray elírást a legkönnyebben úgy tudod elkerülni, hogy kevesebbet használsz Windowst, és akkor nem találkozol annyit a tray szóval :)

friczy.degec.org :)

Igen mukodnek, legalabbis leirast mar lattam.. (2 CPU eseten pl.)

1. az egyik CPU-t elerhetetlenne kell tenni (a masikhoz "dedikalodnak" a processzek
2. ezen a CPU-n inditjak el az uj kernelt

3. a masik CPU, hasonloan mint az elobb "atadja a processzeit"

4. a regi kernel kihal...

Zsiraf

Google: kexec+kernel hot swap

És ez mennyire rontja (ronthatja) egy Linux rendszer hatékonyságát vayg stabilítását...?

Figyi Tray, nagyon honorable ahogy ezekkel a ezekkel a cikkekkel gurcolsz,
de nem erzel idonkent kesztetest arra hogy odabiggyessz egy ilyesmit a
vegere hogy "Ez a forditas ax XY dokument alapjan keszult."

Ennek hianyaban nekem a dolog kisse plagizalasnak tunik.
Nem arrol van szo hogy nincs ott a link a sourcera hanem
annak az explicit kifejezese hogy te azt forditottad.

?

Ott van ra a link. Azer van ott, hogy meg lehet nezni. De ha neked kell akkor legkozelebb odairom.

Személyes adatok: borso
e-mail címem: hu!vein!saturnus!vekoll@borso
Lakóhely: Degec

:))

legalabb a nickem tudnad leirni normalisan...

Ez még nem is semmi, de nézd meg... az "A" és az "E" mégcsak nem is szomszédok... na ennyit a félregépelésről. Jó cikk, köszönöm a többiek nevében is, asszem forgatok vele egy teszt-kernelt...

Nah, nem OFF -olok tovább...

Hello trey!

Nagyon fogsz szeretni:

>>Az MBR vagy merevlemezen, vagy eltávolítható eszközön vagy akár ``hálózaton'' is lehet.

Halozaton nincsen MBR. (hanem inkabb a halozati kartya EPROM-jaban)

udv

>>Nah, nem OFF -olok tovább...

hali never!

ez nem offolas, hanem nyaladzas:)

Igaz, ezen elgondolkoztam en is. Ez viszont az eredeti dokumentumbol valo:

master boot record, which could be on a disk drive, on a removable media, or over the network.

En is ugy tudtam, hogy a bios az halokartya epromot inicializalja, amelyik utana broadcast dhcp kereseket kuld, majd ha kap IP cimet, akkor felbootol mondjuk egy tftp szerverrol...

egyebkent ezert irtam `` '' koze a halozaton keresztult, mert en is felvontam a szemoldokom. hiaba na az IBM-nel is csak emberke dolgoznak :-)

Gondolom ezert van idezojelben.
A lenyeg, hogy halozatrol boot-ol.

KoS

Hoppa... elkestem :-)

KoS

Regota vartam mar ezt a kexec-et. (Nem mintha nagy szuksegem lenne ra, hanem csak elvbol).

Kovetkezo fazis:

Kernelcsere reboot/kexec nelkul de a futo processzek megtartasa! Bar ez egy kicsit bonyolultabb. De nagyon hasznos lenne!

És a végén eljutunk oda, hogy a Linux mikrokerneles lesz...

A kérdés csak az, h ilyenkor az uptime-ot nullázni kell-e, vagy sem... (:

Nem hiszem, elvből monolitikus kernelnek lesz nevezve;-) Viszont a mikrokernel összes előnye meglesz valósítva.;-)))

>Kernelcsere reboot/kexec nelkul de a futo processzek megtartasa! Bar ez egy kicsit bonyolultabb. De nagyon hasznos lenne!

vannak mar ra kiserletek, bar azt nem tudom, hogy a processzeket magtarja-e vagy sem. mintha ilyen funkciok nagygepes kornyeztben mar mukodnenek.

Nem is tudtam, hogy nyáladzás, ha az ember megköszön egy cikket... hmmm...

Nagyon sajnalom ha degeckedesnek vetted az eszrevetelt,
azt pedig kulonosen hogy rosszul emlekeztem a nickedre.

A portalon olvastam hogy "Minden visszajelzest szivesen latok"
(vagy hasonlot). A te irasaidban megfigyeltem valamit, ami
engem zavart. Ezt szandekosan a mindenki altal olvashato
hozzaszolasok kozott hoztam fel, hogy nyilvanosan meg lehessen
vitatni, hatha foglalkoztat meg mast is hogy nincs egyertelmuen
elkulonitve es megjelolve az altalad kitalalt es a forditott
tartalom. Az olvasott reakciokbol ugy tunik senkit nem erdekel,
ugyhogy vedd ugy hogy nem mondtam semmit es maradjunk meg ennyiben.

*sigh*

Nezd, en q nem akarom a cikkeket leforditani, plane, hogy csak az idom megy veluk.
Az olvasok egy reszenek kifejezett igenye, hogy legyen valami magyar bevezeto, mert nem tudnak angolul. En megtehetem holnaptol azt is, hogy benyomok egy linket, aztan *****ogassa mindenki izlese szerint.

De szerintem abszurd lenne, hogy egy cikkben beirjam:

A cikk egy reszenek forrasa ez, majd utana megjelolgetnem, hogy ez a sajat velemenyem, majd megint mashova (errol mar irtam egy evvel ezelott, btw ezt te nem vetted eszere, hogy a cikk magjat mar megirtam egy evvel a developerWorks cikk elott, igy akar mondhatnam azt is hogy tudnak magyarul, es ok meritettek innen), majd a vegen meg egyszer linkeljem a cikket, hogy ott folytathatod. Aki akarja igy is megtalalja a forrast, amely _mindig_ ott van a cikkek vegen. Kiveve ha en irom a cikket magam, ami nem ritka dolog. Persze a vegen meg felirhatnam, hogy a Sun szo a Sun Microsystems vedjegye, a IBM szo es kep a IBM-e stb. csak akkor az egesz cikk ebbol allna. Szoval nekem nem eletem a cikkek forditgatasa elhiheted. Es megegyszer: a forras ott a cikkek vegen...

> Kernelcsere reboot/kexec nelkul de a futo processzek
> megtartasa!

Nem lenne rossz, különönsen mikor valami gpnd jön elő a kernelben... úgy lehetne újratölteni a javított kernelt, hogy közben megmaradnának a processzek, nem lenne kiesés. Ez egy szerver esetében különösen fontos lehet...

A Degec-et meg nem en irtam neked, ha jol latom :-)

Nem baj, mindennap tanulunk vmi ujat, :|

akkor elvileg ezzel lehet ugy kernelt frissiteni, hogy megmarad az uptime?

hehe

ugy latom, elhintettem a fumagot:)