-----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.
- 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".
- 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.
- 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
Dump 256GB po gigabitu trva dlouho a data jsou lokalne, cili... jedine az bude 10GE, pak se o tom da uvazovat.
- 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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list