[vpsFree.cz: community-list] Vypadky Node5

[Stanislav Petr]

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/html/Deployment_Guide/s2-kdump-configuration-cli.html
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 at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list