10 Feb
2015
10 Feb
'15
2:17 p.m.
-----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/ht…
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:
_______________________________________________ Community-list
mailing list Community-list(a)lists.vpsfree.cz
-----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlTaEvgACgkQgRwOVqYrsFWQwAEA02EhABb3dh+lSRJg7LFk3enE
V0expluJtxyuJ3huUioA/2XMnM5bZKl/B+tTMXQW5FFmNMxiqXt4oScoGsjXrQCn
=58JI
-----END PGP SIGNATURE----- -----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