10 Feb
2015
10 Feb
'15
1:50 p.m.
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/ht…
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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list