kexec: rebootoljuk gyorsabban a Linuxot!

Címkék

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ások

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.

?

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

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

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!

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

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