Jaderné noviny - 20. 5. 2015: Úvod k "čistým" kontejnerům

11. 8. 2015 | Redakce | Jaderné noviny | 2920×

Stav vydání jádra. Citáty týdne. Úvod k "čistým" kontejnerům.

Stav vydání jádra

Aktuální vývojový kernel je 4.1-rc4, vydaný 18. května. "Tak je to tu, opravy na poslednní chvíli a tak. Patch -rc4 je o něco větší než ten předchozí, ale to bude v důsledku normálního náhodného načasování - kolísání sloučení stromů submaintainerů."

Stabilní aktualizace: 4.0.4, 3.14.43 a 3.10.79 byly vydány 17. května.

Citáty týdne

Samozřejmě, že se obecně věří, že Smack+Tomoyo nebo SELinux+AppArmor je mnohem zajímavější kombinace než SELinux+Smack. Upřímně, nikdy jsem netoužil po tom, vidět explodovat hlavu bezpečnostního admina a bojím se, že by se to v případě SELinux+Smack mohlo stát.

-Casey Schaufler

Úvod k "čistým" kontejnerům

Kontejnery jsou skvělé. Všichni je milují. Vývojáři je milují pro jednoduchost, s jakou je možné vytvořit bundle pro uživatele, DevOps a IT vývojáři je milují jejich jednoduchost pro správu a nasazení. Do záře reflektorů se kontejnery dostaly v okamžiku, kdy Docker změnil prostředí pro vývoj aplikací podobně, jako iPhone změnil klientské prostředí.

Slovo "kontejner" (angl. container) se nepoužívá pouze pro aplikace, ale také k popisu technologií, která je schopná spustit software izolovaně. Takové kontejnery jsou o používání kontrolních skupin ke správě prostředků a uživatelského prostoru jádra a omezení viditelnosti a dosahu kontejnerové aplikace. Zhruba toto by si pod označením kontejner mohl představit typický čtenář LWN a Abc Linuxu.

Lidé obhajující kontejnery tvrdí, že virtuální stroje jsou náročné, trvá jim než se rozjedou, a že kontejnery prostě poskytují efektivnější alternativu. Proti kontejnerům svědčí jejich bezpečnost vůči nepřátelským uživatelům s arzenálem exploitů po kapsách. Na toto téma by bylo možné se hádat celé hodiny, ale realita je taková, že spoustu potenciálních uživatelů kontejnerů právě toto vnímá jako zásadní nedostatek. Na zlepšení bezpečnosti kontejnerů a uživatelského prostoru pilně pracují jak open-source projekty, tak startupy.

My (skupina Intel Clear Containers) se na bezpečnost kontejnerů díváme zase trochu jinak a položili jsme si základní otázku: Jak nákladná je ve skutečnosti technologie virtuálních strojů? Výkon se v tomto případě poměřuje pomocí dvou hledisek: prvním je čas spuštění a druhým zatížení paměti. První hledisko se týká rychlosti, za jakou jsou vaše datová centra schopna odpovědět na příchozí požadavek (např. uživatel se přihlásí ke svému emailu), druhé toho, kolik kontejnerů je možné umístit na jeden server.

Rozhodli jsme se vytvořit systém (který nazýváme "Čistý Kontejner"), ve kterém je možné využít izolace virtuálního stroje spolu s výhodami kontejnerů. Zároveň jsme se rozhodli upustit od tradičního označení "stroj" (machine), které se spojuje s virtuálními stroji. Nebudeme předstírat, že se jedná o standardní PC, které je kompatibilní se všemi operačními systémy na světě.

Několik dosavadních výsledků: Dokážeme spustit takto zabezpečený kontejner, využívající technologie virtualizace pod 150 milisekund a zatížení paměti na jeden kontejner dosahuje zhruba 18 až 20 MB (což znamená, že na serveru se 128 GB RAM je možné spustit 3500 kontejnerů). I když se zatím nedokážeme vyrovnat nejrychlejším spuštěním Dockeru s použitím jmenných prostorů jádra, pro mnoho aplikací by to mohlo stačit. Navíc ještě stále optimalizujeme.

Jak jsme toho dosáhli?

Hypervizor

Jako hepervizora jsme vybrali KVM a podívali jsme se na vrstvu QEMU. QEMU je skvělý emulátor pro běh Windows nebo starší verze Linuxu, ale jeho flexibilitu vyvažují velké nároky. Emulace vyžaduje spoustu paměti, a také nějakou formu firmware v hostu. To vše se přičítá ke startovacím časům virtuálního stroje (neobvyklé nejsou časy kolem 500 - 700 milisekud).

K dispozici máme mini-hypervizor kvmtool (o kvmtool se na LWN již psalo). Díky kvmtool nepotřebujeme BIOS ani UEFI (jednotné rozšiřitelné firmwarové rozhraní), místo toho můžeme přejít přímo do linuxového jádra. KVMtool potřebuje pro spuštění a vytvoření CPU kontextů asi 30 milisekund. Vylepšili jsme kvmtool, takže podporuje XIP (execute in place) v jádře bez nutnosti rozbalit obraz jádra, stačí mmap() soubor vmlinux a přejít do něj, což šetří paměť i čas.

Kernel

Linuxové jádro nabíhá velmi rychle. Na skutečném stroji představuje většina startovacího času jádra inicializaci hardwaru. Na virtuálním stroji žádné hardwarové zpoždění není - je to podvod, ve skutečnosti se využívají pouze virtio zařízení, jejichž nastavení trvá velmi krátce. V některých případech [jsme] skryli čekání na inicializaci CPU, ale jinak trvá bootování kernelu ve virtuálním stroji zhruba 32 milisekund, takže zůstává spousta prostoru pro optimalizaci.

Museli jsme také opravit několik chyb v jádře. Několik oprav jsme již odeslali (upstream), další odešleme v následujících týdnech.

Uživatelský prostor

V roce 2008 jsme na Plumbers Conference mluvili o 5sekundovém bootu. Od té doby se mnoho změnilo, nejvýrazněji sysemd. Díky systemd je jednoduché vytvořit prostředí uživatelského rozhraní, které bootuje velmi rychle. Rád bych se na tomto místě rozepsal o tom, jak jsme museli optimalizovat uživatelský prostor, ale pravdou je, že s menšími úpravami správným sestavením operačního systému, bootuje uživatelský prostor opravdu rychle (trvá to méně než 75 milisekund). (Při použití bootchartingu při vzorkování ve vysokém rozlišení je to o něco více, ale to jsou horní hranice měření).

Spotřeba paměti

Klíčovým prvkem, který by mohl pomoci snížit spotřebu paměti je DAX, kernel 4.0 jej již podporuje v souborovém systému ext4. Je-li vaše úložiště viditelné hostitelskému CPU jako běžná paměť, umožní DAX zcela obejít page cache i subsystém virtuální paměti. Pro aplikace, které využívají mmap() to znamená operace zero-copy, a pro kód, který využívá volání read() (nebo jiný ekvivalent) to znamená pouze jedny data. DAX byl původně navržen pro rychlé paměti (podobné flash), které CPU vidí jako paměť. V prostředí virtuálního stroje není problém úložiště tohoto typu jednoduše emulovat. Je třeba namapovat obraz hostitelského disku do fyzické paměti hosta a použít malý ovladač zařízení v kernelu hosta, který kernelu zobrazuje tuto oblast paměti jako DAX-ready blokové zařízení.

Tato (DAX) metoda nabízí zero-copy řešení bez spotřeby paměti pro ukládání kódu operačního systému a dat do uživatelského prostoru hosta. Při použití příznaku MAP_PRIVATE v hypervizoru se úložiště stane copy-for-write bez využití paměti, zápisy do souborového systému v hostu nejsou trvalé, takže dojde k jejich smazání v okamžiku ukončení hostova kontejneru. Možnost MAP_PRIVATE umožňuje jednoduché sdílené téhož obrazu disku mezi všemi kontejnery, což také znamená, že i když dojde k poškození a "zasvinění" obrazu operačního systému, nebudou tyhle změny přetrvávat v budoucích kontejnerech.

Další klíčovou vlastností ke snížení spotřeby paměti je same-page merging (KSM) na hostiteli. KSM poskytuje způsob jak deduplikovat paměť v rámci a mezi procesy a KVM hosty.

Nakonec jsme optimalizovali základní uživatelský prostor pro co nejnižší spotřebu paměti. Toho jsme dosáhli voláním funkce malloc_trim() na konci inicializačního procesu rezidentských démonů, čímž jsme je přiměli vrátit zpět do jádra jakékoli malloc() buffery, které v využíval glibc. Ve výchozím nastavení implementuje glibc typ hystereze, tzn, drží si jistou část volné paměti jako optimalizaci v případě, že je paměť brzy znovu zapotřebí.

Další kroky

Jako důkaz snad poslouží funkčního koncept s rkt (nedávný článek o appc na LWN). Jakmile s prací pokročíme, budeme se soustředit na přidávání podpory pro Docker. Více informací o tom, jak začít a kde stáhnout kód, najdete na clearlinux.org, který aktualizujeme jakmile pokročíme s integrací a optimalizací.

       

Komentáře

[majk]

tak tohle je pecka clanek, diky!

[jaroslav]

+1

nádherný příklad toho, že "umět" a "umět vysvětlit" jsou dvě dost odlišné věci...

[Pev]

Link na Docker má být https://www.docker.com/.

Díky za překlad .

[Conscript89]

Díky kvmtool nepotřebujeme BIOS ani UEFI (jednotné rozšiřitelné firmwarové rozhraní), místo toho můžeme přejít přímo do linuxového jádra. KVMtool potřebuje pro spuštění a vytvoření CPU kontextů asi 30 milisekund.

Pokud vim, tak neco podobneho umi i qemu: qemu-kvm -serial stdio -kernel vmlinuz -initrd vmlinuz -append console=ttyS0