abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
včera 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 0
včera 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
včera 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
včera 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 2
včera 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
13.12. 11:00 | Zajímavý software
Na Good Old Games je v rámci aktuálních zimních slev zdarma k dispozici remasterovaná verze klasické point&click adventury Grim Fandango, a to bez DRM a pro mainstreamové OS včetně GNU/Linuxu. Akce trvá do 14. prosince, 15:00 SEČ.
Fluttershy, yay! | Komentářů: 6
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 988 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

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

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

    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

    link

    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čí

    link

    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

    link

    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í

    link

    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)

    link

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

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    30.4.2012 01:38 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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).
    --- vpsFree.cz --- Virtuální servery svobodně
    2.5.2012 15:17 Mordae
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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 avatar 2.5.2012 17:46 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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.
    2.5.2012 22:27 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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
    Quando omni flunkus moritati
    Heron avatar 3.5.2012 07:25 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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.
    3.5.2012 08:29 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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.
    Quando omni flunkus moritati
    Heron avatar 3.5.2012 11:16 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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).

    3.5.2012 13:18 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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.

    Quando omni flunkus moritati
    Heron avatar 3.5.2012 15:16 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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.

    3.5.2012 16:53 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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
    Quando omni flunkus moritati
    Marek Stopka avatar 3.5.2012 22:29 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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. :(
    4.5.2012 00:14 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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).
    4.5.2012 12:59 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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.
    Quando omni flunkus moritati
    5.5.2012 11:32 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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 avatar 5.5.2012 12:00 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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ů?
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 4.5.2012 23:58 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    Já už nevím - ty snad buď schválně lžeš, nebo ze sebe děláš blba.
    Zas ty tomešoviny :).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    3.5.2012 09:17 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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?
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    5.5.2012 11:38 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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íš. ;-)
    5.5.2012 12:11 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    Starší, ale ukecanější prezentace: link
    5.5.2012 13:06 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    Nevedel jsem, prozkoumam, diky :)
    --- vpsFree.cz --- Virtuální servery svobodně
    7.5.2012 13:11 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 12. 4. 2012: Jak by mohly vypadat kontejnery v Linuxu
    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.
    Quando omni flunkus moritati

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.