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 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 1
dnes 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 0
dnes 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 6
včera 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
včera 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
včera 22:04 | Pozvánky

Rádi bychom vás pozvali na přednášku o frameworku Avocado. Jedná se o testovací framework další generace, inspirovaný Autotestem a moderními vývojovými nástroji, jako je třeba git. Přednáška se bude konat 23. října od 17 hodin na FEL ČVUT (Karlovo náměstí, budova E, auditorium K9 – KN:E 301). Více informací na Facebooku.

… více »
mjedlick | Komentářů: 0
včera 21:44 | Bezpečnostní upozornění

Nový útok na WPA2 se nazývá KRACK a postihuje prakticky všechna Wi-Fi zařízení / operační systémy. Využívá manipulace s úvodním handshake. Chyba by měla být softwarově opravitelná, je nutné nainstalovat záplaty operačních systémů a aktualizovat firmware zařízení (až budou). Mezitím je doporučeno používat HTTPS a VPN jako další stupeň ochrany.

Václav HFechs Švirga | Komentářů: 3
15.10. 00:11 | Zajímavý projekt

Server Hackaday představuje projekt RainMan 2.0, aneb jak naučit Raspberry Pi 3 s kamerovým modulem pomocí Pythonu a knihovny pro rozpoznávání obrazu OpenCV hrát karetní hru Blackjack. Ukázka rozpoznávání karet na YouTube. Zdrojové kódy jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 0
14.10. 15:11 | IT novinky

Online obchod s počítačovými hrami a elektronickými knihami Humble Bundle byl koupen společností IGN. Dle oficiálních prohlášení by měl Humble Bundle dále fungovat stejně jako dosud.

Ladislav Hagara | Komentářů: 8
14.10. 06:00 | Zajímavý článek

Brendan Gregg již v roce 2008 upozornil (YouTube), že na pevné disky se nemá křičet, že jim to nedělá dobře. Plotny disku se mohou rozkmitat a tím se mohou prodloužit časy odezvy pevného disku. V září letošního roku proběhla v Buenos Aires konference věnovaná počítačové bezpečnosti ekoparty. Alfredo Ortega zde demonstroval (YouTube, pdf), že díky tomu lze pevný disk použít také jako nekvalitní mikrofon. Stačí přesně měřit časy odezvy

… více »
Ladislav Hagara | Komentářů: 8
Těžíte nějakou kryptoměnu?
 (6%)
 (2%)
 (15%)
 (76%)
Celkem 719 hlasů
 Komentářů: 24, poslední 27.9. 08:30
    Rozcestník

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

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

    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ů?
    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 :).
    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.