Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu

30. 4. 2012 | Luboš Doležel | Jaderné noviny | 3686×

Aktuální verze jádra: 3.4-rc2. Řada 2.4 končí. Nová wiki bezpečnostního subsystému. SCHED_DEADLINE se vrací. Nový přístup k uživatelským jmenným prostorům (kontejnery).

Obsah

• Aktuální verze jádra: 3.4-rc2
• Řada 2.4 končí
• Nová wiki bezpečnostního subsystému
• SCHED_DEADLINE se vrací
• Nový přístup k uživatelským jmenným prostorům (kontejnery)

Aktuální verze jádra: 3.4-rc2

Aktuální vývojová verze jádra je 3.4-rc2 vydaná 7. dubna. Obsahuje spoustu oprav; Linus se také rozhodl přetáhnout přípravné patche pro přepracování mapování DMA. To by ale měl být konec významných změn v tomto vývojovém cyklu. Odteď budu co se přetažení týče přísnější, vyskytlo se spousta „šumu“, nikoliv jen čisté patche. Krátký přehled změn naleznete v oznámení.

Stabilní aktualizace: za poslední týden žádné nevyšly. Verze 3.0.28, 3.2.15 a 3.3.2 se aktuálně revidují. Všechny tři verze obsahují dlouhý seznam oprav; jejich vydání se dá očekávat 13. dubna nebo později.

Řada 2.4 končí

Více než osm let po vydání verze 2.6.0 Willy Tarreau oznámil, že už nebude vydávat žádné aktualizace řady 2.4. Pro potřeby těch, co z nějakého důvodu nemohou upgradovat, udržuje strom v gitu s občasnými opravami, ale bez jakýchkoliv záruk.

Nová wiki bezpečnostního subsystému

Vývojáři zabývající se bezpečností v jádře už nechtěli dále čekat na návrat wiki systému kernel.org. Proto najdete všechny informace k vývoji zabezpečení v jádře na kernsec.org. Obnova obsahu wiki kernel.org ještě asi chvíli potrvá.

SCHED_DEADLINE se vrací

Plánovače na bázi deadline se tu už mnohokrát diskutovaly. Ve zkratce jde o to, že namísto priorit ohodnocuje deadline plánovač každý proces maximálním potřebným procesorovým časem a termínem („deadline“), do kterého musí daný čas obdržet. Správně napsaný deadline plánovač je schopen zajistit, že každý proces dodrží dané termíny a odmítne přitom jakoukoliv úlohu, která by způsobila nesplnění termínu. Patche doplňující deadline plánovač do Linuxu už existují několik let, ale jejich cesta do jádra byla poněkud pomalá, v poslední době dokonce velmi pomalá, protože hlavní vývojář se začal věnovat jiným projektům.

Juri Lelli se stal novým vývojářem těchto patchů; Juri zaslal novou verzi těchto patchů, aby nanovo rozjel diskuzi. Patch se od posledně moc nezměnil: reaguje na připomínky a má lepší mechanismus pro migraci. Plánem je opravovat nedostatky, aby se deadline stal vhodným pro produkční nasazení a aby se nakonec dostal do hlavní řady jádra. Proto vznikl nový Git repozitář, dále pak aplikace pro testování deadline plánování a mailing list. Dá se očekávat, že Juri bude vděčný za patche a testování.

Nový přístup k uživatelským jmenným prostorům (kontejnery)

"Kontejnery" se dají považovat za lehkotonážní podobu virtualizace. Virtualizovaní hosté vypadají, jako by běželi na svém vlastním dedikovaném hardwaru; kontejnery zato běží na jádře hostitele, jenže v prostředí, které dává iluzi, že mají celé jádro pro sebe. Výsledek je efektivnější; na jediném systému je obvykle možné provozovat více kontejnerů než virtualizovaných systémů. Nevýhodou z pohledu uživatele je flexibilita; virtualizovaní hosté mohou mít vlastní jádro a mohou tedy provozovat libovolný operační systém. Hosté v kontejneru musí používat to jádro, jaké používá hostitel.

S kontejnery se pojí další nevýhoda, kterou uživatelé nemusejí nezbytně zaznamenat: jejich jaderná implementace je v mnoha ohledech značně komplexnější. V systému, který podporuje kontejnery, musejí všechny globálně viditelné prostředky být zaobaleny ve vrstvě jmenného prostoru, který každému poskytuje vlastní pohled. Na linuxovém systému je spousta prostředků: například ID procesů, souborové systémy nebo síťová rozhraní. Dokonce i název systému a čas se mohou mezi kontejnery lišit. Následkem toho je to, že navzdory rokům snažení Linuxu stále chybí pořádná podpora kontejnerů, i když podpora virtualizace má už dlouhou dobu stabilní základy.

Práce na implementaci kontejnerů ale pokračuje; posledním dílkem je nová sada patchů pro uživatelské jmenné prostory od Erica Biedermana. „Uživatelský jmenný prostor“ lze vnímat jako zaobalení ID uživatele/skupiny a souvisejících práv; umožňuje vlastníkovi kontejneru být uživatelem root v rámci daného kontejneru a přitom izolovat zbytek systému od uživatelů v kontejneru. Náležitá implementace uživatelských jmenných prostorů byla z řady různých důvodů vždy problémem. Jaderný kód byl napsán s předpokladem, že každý proces má jedno, globálně uznávané UID; co se stane, když bude proces mít vícero UID v různých kontextech? Není obtížné si představit, jaké chyby by mohli vývojáři s UID udělat – šlo by o chyby, které by mohly vést k bezpečnostním chybám v hostitelském systému. Obavy z takových chyb a samozřejmě i obecná složitost problému způsobují, že se do jádra plná podpora uživatelských jmenných prostorů ještě nedostala.

Ericův patch na to jde trochu jinak, ve snaze zneviditelnit uživatelské jmenné prostory a současně odhalit chyby v kódu, hned jakmile jsou napsány. Proto patch zavádí nový typ, který má vyjadřovat „jaderná UID“ – kuid_t; pak je tam i typ kgid_t. Jaderné UID má popsat identitu procesu na základním systému bez ohledu na jakákoliv UID, která se vyskytují v kontejnerech; je to hodnota, která se používá hlavně při ověřování práv. Jaderná ID procesu se mohou (nebo nemusí) lišit od ID viditelných v uživatelském prostoru; proces to nemá jak poznat. Jaderná ID existují pouze za účelem ověření identity procesu v jádře samotném.

Ve zmiňovaném patchi je kuid_t typedef na strukturu s jediným polem; hlavním důvodem jeho existence je nebýt typově kompatibilní s obyčejným integerem [celočíselným typem], který se v jádře používá pro UID a GID. ID specifická pro kontejner mají původní integerové typy (uid_t a gid_t). Následkem toho je to, že jakákoliv snaha míchat jaderná ID s ID specifickými pro kontejner skončí chybou při kompilaci. To by mělo zneškodnit celou skupinu potenciálních chyb.

Typ uid_t, který je při používání v jádře neprůhledným typem, potřebuje sadu pomocných funkcí. Porovnání lze například dělat pomocí funkcí jako uid_eq(); podobné funkce existují pro většinu aritmetických porovnání. Pro většinu užití to postačuje. Bez ohledu na jmenný prostor jsou údaje o procesu uloženy v globálním prostoru kuid_t, takže většina porovnání ID funguje správně.

Občas je nutné udělat konverzi mezi jaderným ID a UID nebo GID v konkrétním jmenném prostoru. Nejsnazším příkladem je systémové volání jako getuid(); mělo by vrátit ID specifické pro daný kontejner, nikoliv pro jaderné ID. Pro tyto konverze existuje sada funkcí:

kuid_t make_kuid(struct user_namespace *from, uid_t uid);
uid_t from_kuid(struct user_namespace *to, kuid_t kuid);
uid_t from_kuid_munged(struct user_namespace *to, kuid_t kuid);
bool kuid_has_mapping(struct user_namespace *ns, kuid_t uid);

(Obdobná sada existuje samozřejmě i pro GID.) Konverze mezi jaderným ID a ID v rámci uživatelského prostoru vyžaduje používání mapování uloženého v jmenném prostoru, takže při používání je třeba dodat informaci o tom, o který jmenný prostor se má jednat. V případě kódu, který se spouští v kontextu procesu, stačí pro získání ukazatele na jmenný prostor zavolat current_user_ns(). make_kuid() převede UID z jmenného prostoru na jaderné ID a from_kuid() udělá zase opak. Pokud mezi ID není žádné mapování, funkce vrátí -1; v případech, kdy je nutné vrátit platné ID, volání from_kuid_munged)) vrátí speciální hodnotu „neznámého uživatele“. Jestli je mapování dostupné, se dá zjistit pomocí funkce kuid_has_mapping.

Nastavení samotného mapování musí udělat administrátor, který pravděpodobně vymezí rozsah ID pro kontejner. Patch kvůli tomu přidává do /proc/pid/ několik souborů; nastavení mapování je jen otázkou zapsání jedné nebo více množin tří čísel do /proc/pid/uid_map:

first-ns-id  first-target-id  count

first-ns-id je první platné UID v daném jmenném prostoru. Pravděpodobně to bude nula – ID roota je ve jmenném prostoru platné a neškodné. Toto první ID bude mapováno na first-target-id definované v nadřazeném jmenném prostoru a count je počet následujících ID, která v budou součástí mapování. Pokud se použije struktura několika úrovní jmenných prostorů, může vzniknout několik vrstev mapování, ale ty budou zploštěny mapovacím kódem, který si pamatuje jen přímé mapování z a na jaderné ID.

Vytváření mapování rozhodně musí být privilegovanou operací, takže proces, který je chce vytvořit, musí mít nastavenou capability CAP_SETUID. Proces běžící jako root v rámci svého jmenného prostoru může tuto capability mít, i když nemá k okolním prostorům přístup. Takže procesy v uživatelském jmenném prostoru si mohou sestavit vlastní podprostory s libovolnými mapováními – ale tato mapování mohou přistupovat jen k UID a GID v rodičovském prostoru. Dalším omezením je to, že mapování ID může být nastaveno jen jednou; poté už je neměnné.

Tyto mapovací funkce najdou využití na řadě míst v jádře. Jakékoliv systémové volání, které pracuje s UID a GID, musí obsahovat konverze z a do prostoru jaderných ID. Systémy souborů ext* umožňují určení UID, která mohou používat vyhrazené bloky, takže kód souborového systému musí pracovat s jadernými ID při porovnávání. Patch je tedy trochu intruzivní, ale Eric se jednoznačně snažil jeho dopad minimalizovat. Zejména se snažil o to, aby režie spojená s mapováním ID byla nejlépe nulová, pokud není v jádře podpora jmenných prostorů aktivní.

Jak říká, funkce uživatelských jmenných prostorů má řadu zajímavých vlastností:

S mou verzí jmenných prostorů se už nemusíte bát toho, že root v kontejneru zapíše do souborů v /proc nebo /sys a změní tak chování systému. Ani se nemusíte bát zpráv předávaných přes unixové sokety d-busu.

Aplikacím bez capabilities umožňuje používat vícero UID a implementovat oddělení oprávnění. Dovedu si představit, že takovéto jmenné prostory mají potenciál učinit linuxové systémy bezpečnějšími.

V době psaní tohoto textu bylo k patchi jen pár připomínek, takže nebylo jisté, jestli ostatní vývojáři s tímto zhodnocením souhlasí, nebo ne. Povaha práce na jmenných prostorech způsobuje, že dostat implementaci do jádra bude obtížné, protože vývojáři mohou mít obavy z režie a nemusí je přínosy až tak moc zajímat. Ale díky rokům úsilí se většina práce do jádra dostala tak jako tak, takže je tu šance, že se to nakonec povede i jmenným prostorům.

       

Komentáře

[snajpa]

Linuxu chybi kontejnery prijatelne do upstreamu, ne ze by neexistovalo plne funkcni a plnohodnotne reseni :)
Mel jsem sanci pracovat s kazdou otevrenou virtualizacni technologii a jedine OpenVZ splnuje vykonove moje naroky. Mozna to prehanim, ale x86-64 proste neni zatim platforma vhodna na hardwarovou virtualizaci (duvodu se najde hodne, ale vetsina se jich vaze ke context switchingu, multitaskingu a co tyhle procesy s virtualnimi CPU delaji na hostiteli).

[Mordae]

A co přesně tedy KVM dělá na hostiteli?

Vím, že se to chová extrémně špatně, ale nikdy jsem nedošel toho proč.

[Heron]

Take by me zajimaly konkretni duvody. RH stavi na KVM sve enterprise reseni, mnoho firem a lidi to pouziva k plne spokojenosti a co jsme merili u nas ve QCM, tak mezi kvm a vsphere nebyl prakticky zadny vykonnostni rozdil v nasich testech. (Nakonec tedy mame vsphere, ale jen diky lepsim nastrojum a taky za jine penize.) KVM funguje, je soucasti jadra a rozjet si virtualku na kompu je otazkou par minut.

[trekker.dk]

Snad se Pavel nebude zlobit, když sem nalinkuju jeho post do vpsfree-community. Relevantní jsou poslední 2 Q&A

http://lists.vpsfree.cz/pipermail/community-list/2012-February/000386.html

[Heron]

Zajimave cteni, precetl jsem si to cele. Opet tentyz stejny problem, jako s pameti. Vpsfree prideluje neco, co proste nema. Uz na vmware jsme si odzkouseli, ze celkovy objem pameti prideleny virtualum musi byt mensi, nez je velikost fyzicke (baloon realne nefunguje, typicky si vsechny vs reknou o pamet i cpu ve stejnem case - ve spicce, mozna u vas ne, mate jiny typ zateze). Ve QA se pise totez pro vcpu, s tim jsme vetsi problem dosud nemeli, ani hostingy na KVM si nestezuji.

[trekker.dk]

Opet tentyz stejny problem, jako s pameti. Vpsfree prideluje neco, co proste nema.

Já už nevím - ty snad buď schválně lžeš, nebo ze sebe děláš blba. Už ti tady bylo několikrát vysvětleno, že OpenVZ se s VMware nedá takhle srovnávat, protože to v podstatě není virtualizace. A taky už ti bylo několikrát vysvětleno, že ten limit velikosti paměti je limit na celkový součet virtuální paměti procesů v kontejneru, který je vždy větší - a zpravidla o dost - než kolik ty procesy nakonec reálně využijí.

Že to vychází naprosto v pohodě, se může každý snadno přesvědčit sám - https://prasiatko.vpsfree.cz/munin/ - doporučuju prohlídnout si zejména položku cache - stroj, který trpí nedostatkem paměti, takhle rozhodně vypadat nebude.

[Heron]

Já už nevím - ty snad buď schválně lžeš, nebo ze sebe děláš blba.

No pravda se ukáže snadno. Na stránkách VPS free je napsáno: "RAM: 4096 MB virtuální paměti". Odpověz mi po pravdě na otázku, jestli si každý z provozovaných virtuálů může alokovat a reálně použít 4GB paměti. Děkuji za odpověď. Ano vím, co to je virtuální pamět, ano vím, co to to je overcommit.

Ostatně, to co píšu nakonec potvrzuje i Snajpa v rozhovoru na rootu, kde píše, že plánují _snížit_ limit na 2GB, protože openvz už bude umět počítat obsazené stránky.

Ale já jsem se o tomto tématu opravdu hádat nechtěl. Jestli vám to funguje, je to k vašemu dobru. Jen jsem chtěl upozornit na problémy v ostrém produkčním nasazení, kdy často jedou všechny VS na max (co se paměti týče, cpu moc problém není, mě spíše zajímali problémy s cpu a schedulerem, co Snajpa naznačoval) ve stejnou dobu (špičce) a proto je nutné držet přidělenou pamět pod fyzickou. Takovýto typ záteže by vpsfree neustál.

Grafy z produkčního prostředí bohužel doložit nemůžu, ale je tam krásně vidět, že všechny VS vykazují v podstatě stejnou křivku zátěže a spotřebovávají zdroje ve stejnou dobu. Proto nelze použít ani memory baloon (kvm, vmware).

[trekker.dk]

Odpověz mi po pravdě na otázku, jestli si každý z provozovaných virtuálů může alokovat a reálně použít 4GB paměti.

Odpovím protiotázkou: řídíš se tím, co se v reálném provozu může stát, nebo tím, se děje? V tom prvním případě bys měl na vmware přidělovat více paměti, než máš, protože to vyřeší balloon. V tom druhém není na tvoji otázku potřeba odpovídat.

Ostatně, to co píšu nakonec potvrzuje i Snajpa v rozhovoru na rootu, kde píše, že plánují _snížit_ limit na 2GB, protože openvz už bude umět počítat obsazené stránky.

Je otázka, jak moc je to opravdu snížení, když se jedná o jiný limit - tzn. spousty uživatelů se to nemusí vůbec dotknout, protože při nějakém konkrétním způsobu využívání VPS programy nevyužívaly tolik paměti, o kolik si řekly.

Jen jsem chtěl upozornit na problémy v ostrém produkčním nasazení, kdy často jedou všechny VS na max

To ale přece závisí na způsobu nasazení. Jestli máš každý VS = webserver s DB (např.), tak je vcelku očekávatelné, že budou mít podobné špičky. Kdežto když se každý VS využívá jinak (což je AFAIK situace vpsfree), špičky se rozprostřou.

[Heron]

Odpovím protiotázkou: řídíš se tím, co se v reálném provozu může stát, nebo tím, se děje?

Obojím. Jak reálným stavem, tak i tím, co se může stát (a taky se dřív nebo později stane, pak je z toho reálný stav). Proto má každá virtuálka o dost víc prostředků, než běžně (protože špičky jsou často i stonásobek běžného provozu, takže místo 40MB náhle může být potřeba 4GB) potřebuje a proto je také součet prostředků přiděleným virtuálkám menší než je hw (to platí pro paměť a pro storage kapacity, s cpu problém není -- a ještě jsem se stále nedozvěděl to, čím začal tento thread, proč by s tím měl být problém v kvm). Takto se pokryjí špičky jednotlivých VS i stav, kdy všechny VS začnou běžet na 100% ve stejnou chvíli.

To ale přece závisí na způsobu nasazení. Jestli máš každý VS = webserver s DB (např.), tak je vcelku očekávatelné, že budou mít podobné špičky. Kdežto když se každý VS využívá jinak (což je AFAIK situace vpsfree), špičky se rozprostřou.

Jasně, psal jsem, že máte jinou pracovní zátež. Proto to může fungovat.

Ale zpět k nějaké plodnější diskusi. V RAM a CPU nějak není problém (já ho tam z praxe nevidím). Osadit server 64GB RAM a 24 (ht)cores CPU jde snadno. Co bych spíše uvítal a má to pořádně až vsphere5 je lepší řízení storage. Limitace IOPS, ioscheduler s ohledem na latence apod.

[trekker.dk]

a taky se dřív nebo později stane, pak je z toho reálný stav

Přiznám se, že u vpsfree nevím o případu, kdy by se tohle stalo, přičemž když dojde na nějaký výpadek, chodí maily

a ještě jsem se stále nedozvěděl to, čím začal tento thread, proč by s tím měl být problém v kvm

Jo, tak o tom nevíc víc, než co jsem nalinkoval

[Käyttäjä 11133]

Co bych spíše uvítal a má to pořádně až vsphere5 je lepší řízení storage. Limitace IOPS, ioscheduler s ohledem na latence apod.

Možná to ve vSphere dlouho neměli, protože se tohle má řešit na úrovni toho pole a ne na úrovni virtualizačního hypervisora. :(

[David Jaša]

Grafy z produkčního prostředí bohužel doložit nemůžu, ale je tam krásně vidět, že všechny VS vykazují v podstatě stejnou křivku zátěže a spotřebovávají zdroje ve stejnou dobu. Proto nelze použít ani memory baloon (kvm, vmware).

Pokud je dost podobných virtuálek běžících na jednom hypervisoru, může se minimálně u KVM dobře uplatnit linuxí KSM (jestli to pomůže i u OpenVZ, to netuším).

[trekker.dk]

Hádám, že KSM u OpenVZ moc nepomůže. První krok u používání KSM je totiž syscall madvise(), kterým aplikace jádru řekne, že tenhle kus paměti možná obsahuje data, která půjde deduplikovat. U KVM tohle udělá proces kvm, v OpenVZ provozuješ programy přímo na hostiteli a běžné programy ten syscall nedělají, protože pro ně nemá smysl.

[David Jaša]

U KVM tohle udělá proces kvm, v OpenVZ provozuješ programy přímo na hostiteli a běžné programy ten syscall nedělají, protože pro ně nemá smysl.

Čekal bych, že programy typu Google Chrome nebo Apache v prefork módu, které spouští mnoho stejných procesů, tyto funkce využívat budou. Nicméně je to opravdu na libovůli aplikací, zatímco KVM to třeba u několika VM ze stejné šablony udělá pro celý virtualizovaný OS samo.

[pavlix]

A není náhodou kód sdílených knihoven sdílený? Není jediným smyslem deduplikace právě obejití toho, že kernel nevidí do všech systémů?

[pavlix]

Já už nevím - ty snad buď schválně lžeš, nebo ze sebe děláš blba.

Zas ty tomešoviny :).

[Ladicek]

Opet tentyz stejny problem, jako s pameti. Vpsfree prideluje neco, co proste nema.

WTF? To přece dělají operační systémy už drahně let. Nebo si snad zakazuješ overcommit?

[David Jaša]

duvodu se najde hodne, ale vetsina se jich vaze ke context switchingu, multitaskingu a co tyhle procesy s virtualnimi CPU delaji na hostiteli

O autonuma víš? Viz pidiprezentaci s benchmarkem, zbytek vygůglíš.

[David Jaša]

Starší, ale ukecanější prezentace: link

[snajpa]

Nevedel jsem, prozkoumam, diky :)

[trekker.dk]

Něco takového (stěhování paměti tam, kde běží vlastník apod.) se nedávno objevilo na LWN - http://lwn.net/Articles/486858/ - mám takovou obavu, že než se to dostane do hlavní řady, tak si docela počkáme.