Jenze stejne nedosahnete toho aby slo efektivne provozovat pod KVM 100 guestu na jednom fyzickem serveru - pri takhle velke agregaci zacnete pocitovat krome samotne pameti dalsi problemy, jako obbsluhu preruseni a podobne. Budoucnost samozrejme je v kontejnerove virtualizaci, ale osobne si opravdu nejsem jist jestli zrovna v OpenVZ...
Takze kdyz uz tady mame tuhle krasnou debatu, tak pojdme probrat moznosti reseni.
1. Padani predpokladam zpusobuje nejaka race-condition chyba, coz znamena ze nalezeni nemusi bejt vubec jednoduchy a uz vubec ne rychly (obzvlaste pokud je v tom i ZFS diky SPL). Tim padem si nejsem uplne jisty tim, jestli stehovani jednotlivych VPS, tento problem nejak vyresi nebo "zamaskuje".
2. Co rozdelit soucasne VPS na rekneme mensi casti - vyuzit k tomu prave zminene KVM tak ze se na fyzickem stroji pusti nekolik (tak odhadem strelim 3 - 5) KVM guestu a OpenVZ az na nich. Takhle bude guest kernel porad pod kontrolou spravce fyzickeho serveru, takze sproblemy s ballooningem odpadaji... Zaroven se tim zmensi zatez na jednotliva OpenVZ jadra. Dalsi vyhodou je (a co v rpaxi obcas pouzivam) moznost i z totalne vytuhlyho guesta udelat memory dump celeho VPS a to si rozebrat pozdeji.
3. Jak zminoval Snajpa - problem kdyz to spadne ze nemuze vygenerovat ani backtrace, nepomohl by crashkernel+kdump? (pravdepodobne to Snajpa zna). https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... Me se to hodne osvedcilo pri debugovani KVM... :D
4. Kdyz uz se ma venovat cas vyvoji rekneme vlastniho systemu kontejneru, co nam brani zacit se pomalu orientovat na LXC/LXD? Jestli by nebylo efektivnejsi venovat ten cas necemu co je sice dnes jeste v plenkach ale narozdil od OpenVZ to ma pravdepodobne vetsi budoucnost...
-- Stanislav Petr
Dne 10.02.2015 v 14:35 Jirka Bourek napsal(a):
Pavel Snajdr wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Ono to docela zalezi. Jsou kontejnery, co nevyuzijou ani 100 MB RAM a byt to plna virtualizace, urcite ten kontejner 3.9 GB nevrati, obzvlast, kdyz je tam linux - staci zaplnit diskovou cache i totalne nepouzivanymi daty. Nebo se to uz da nejak nastavit, aby kdyztak pri pozadavku na pamet host pustil memory reclaim?
Dělá se to z userspace - "něco" musí hypervizoru říct, aby balloon ovladač odebral hostovi třeba 3.8GB RAM (aby mu nějaká cache zůstala). Jádro hosta pak vrátí diskové cache, protože bez těch se obejde - jo, když se to přežene, nastoupí oom killer.
Red Hat na to asi nějakého démona mít bude, to už nevím.
Samozřejmě by to šlo dělat ještě lépe - jádro hosta může vědět, že běží pod hypervizorem, a říkat mu, které konkrétní kusy paměti používá jako diskové cache. Hypervizor tuhle informaci předá jádru hostitele a to ji v případě potřeby může hostovi odebrat.
Hostovi se samozřejmě při pokusu tu paměť číst vrátí nějaká chyba, ale protože to byla cache, tak se s tím snadno vyrovná tím, že příslušná data znovu načte.
Vím, že na tomhle se pracovalo a AFAIK se to dostalo i do mainline. Akorát to vyvíjel někdo z Oracle a udělal to jenom pro Xen (protože KVM je konkurence), takže mám ten pocit, že KVM tohle nepoužívá.
Suma sumárum jde udělat to samé co v kontejneru, akorát je to o něco složitější - na rozdíl od kontejneru, do kterého je dobře vidět, jsou u plné virtualizace k dispozici jenom nějaké základní informace (u KVM 2.1 je to paměť celkem, volno, počítadlo minor a major fault a počítadlo swap-in a swap-out.) Na ostatní už je potřeba nějaký démon běžící v tom hostovi - u KVM qemu-guest-agent _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list