[vpsFree.cz: community-list] Vypadky Node5

Tue Feb 10 15:17:31 CET 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/10/2015 02:50 PM, Stanislav Petr wrote:
> 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...

Achjo. Lidi, co vyviji OpenVZ, delaji LXC ve volnem case a podle toho
to taky vypada. Zdaleka se featurama LXC neblizi OpenVZ, uvnitr LXC
kontejneru to zdaleka nepripomina to, co OpenVZ. Spousta veci pod LXC
kontejnerem nechodi a dlouho chodit nebude.

Minimalne dokud se z LXC v Parallels nestane priorita, bude LXC OpenVZ
dobihat pomalu.

A port OpenVZ nad RHEL7 kernel uz je rozpracovany, akorat to neni
verejne a zatim k tomu nema pristup nikdo mimo Parallels a mozna
nekoho z Red Hatu.

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

Nic tim neziskame, jedine problemy s pridanou softwarovou vrstvou.
Navic se tim pripravime o moznost v kontejnerech virtualizovat (coz
mam rozdelane, ale momentalne, jak vidite, jsou jine priority).

Soucasne problemy uz nevypadaji byt race conditions, ted vypada, ze je
proste problem, ze se shrinkery pousti vsechny najednou, pricemz ARC
to chvili trva se zmensit a nereaguje na to zrovna nejlip.

Kdyby se seslo tech par CT, co delaji bordel na node5, nekde v mensim
KVM virtualu, sel by do kopru taky - ano, izolovaneji. To jest vyhodou
izolace. Ale spousta nevyhod plne virtualizace prijde s tim.

Nad necim podobnym premyslim uz chvili, ale spis stylem, ze bychom
postavili dedikovany cluster propojeny 10GE, soupnuli ty KVM masiny
nad nejake distribuovane uloziste a v nem jeli potom nas setup OpenVZ
s vpsAdminem. Ale je to jenom napad, zatim to hori na absenci vhodneho
distribuovaneho storage.

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

Dump 256GB po gigabitu trva dlouho a data jsou lokalne, cili... jedine
az bude 10GE, pak se o tom da uvazovat.

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

Viz vyse. Navic prechod na LXC, az to pujde, bude jednoduchy - boot
jineho jadra, mozna zmena userspace utilit, se kterymi se vpsAdmin
bavi a tim to pro nas hasne. Ale to na to nejdriv LXC musi dozrat.

/snajpa

> 
> -- 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
> 
> _______________________________________________ Community-list
> mailing list Community-list at lists.vpsfree.cz 
> http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iF4EAREIAAYFAlTaEvgACgkQgRwOVqYrsFWQwAEA02EhABb3dh+lSRJg7LFk3enE
V0expluJtxyuJ3huUioA/2XMnM5bZKl/B+tTMXQW5FFmNMxiqXt4oScoGsjXrQCn
=58JI
-----END PGP SIGNATURE-----