Ahoj, tohle je trochu ožehavé téma. Mě samotného výpadky také trápi, ale na obranu vpsfree.cz je třeba si uvědomit, že to není komerční služba, kam lze volat a buzerovat v případě výpadků. Každý, kdo tu teď diskutujeme, jsme členem sdružení, platíme si za členství a v rámci tohoto členství máme k dispozici VPS. Podstatné ale je, že vpsfree se svým charakterem nedá s komerčními službami srovnávat, žádnou službu vlastně nenabízí, natož nějaké garance. S tím je třeba počítat a zahrnout do úvahy výhody/nevýhody. Pro provoz vysoce dostupné služby v tuto chvíli 1 VPS u vpsfree vhodná není. Jako členové máme kromě odchodu možnost si pořídit další VPS v druhém datacentru Praha/Brno a zkusit nějakou replikaci (cenově za ten výkon to stále může vycházet výhodněji), nebo ideálně, což se právě děje, vyvolat diskuzi o příčinách a hledat řešení. A ještě lépe přímo na členské schůzi. Nevím teď přesně, jaký je stav aktivních členů, kteří se starají o chod a vyvíjejí (podle odměn 6 lidí?), ale podle výše těch odměn to asi nikdo nedělá na fulltime, což by také mohlo hrát roli a já bych se pak nebál zvednout ruku pro investici právě do této oblasti. Nikos

On 10 Feb 2015, at 08:46, Michal Zobec (ZOBEC Consulting) <michal.zobec.news@gmail.com> wrote:

Ahoj,

Souhlasím, taky mi to už připadne nenormální … já k vám „přešel“ v listopadu. Mezitím začaly ty výpadky a tak nějak váhám jestli mám dokončit migraci. Sice máte super cenu ale u konkurence tohle fakt nezažívám …

…

s přátelským pozdravem | best regards

Michal Zobec | Senior IT Consultant, Project Manager Mobil: +420 608960987 | Email: michal@zobec.net <mailto:michal@zobec.net> LinkedIn: www.linkedin.com/in/michalzobec <http://www.linkedin.com/in/michalzobec> | Na volne noze: www.navolnenoze.cz/prezentace/michal-zobec/ <http://www.navolnenoze.cz/prezentace/michal-zobec/>

ZOBEC Consulting | Renneska trida 12, 63900 Brno, Czech Republic www.zobecconsulting.cz <http://www.zobecconsulting.cz/> | www.michalzobec.cz <http://www.michalzobec.cz/> | www.virtualnipc.cz <http://www.virtualnipc.cz/> LinkedIn: www.linkedin.com/company/michal-zobec-lightning-group-company <http://www.linkedin.com/company/michal-zobec-lightning-group-company>

<image002.jpg>

Plánovaná nepřítomnost | Planned absence (none) …

From: community-list-bounces@lists.vpsfree.cz [mailto:community-list-bounces@lists.vpsfree.cz] On Behalf Of Jiří Veruňák Sent: Tuesday, February 10, 2015 8:33 AM To: vpsFree.cz Community list Subject: [vpsFree.cz: community-list] Vypadky Node5

Ahoj,

uz drive tu nekdo zvedal reseni castych vypadku a pro me je to posledni zvolani po naprave. Jde o vypadky od zacatku roku Node5 (10.2, 8.2, 25.1, 18.1) typicky to byla nedele dopoledne 20 minut. S kazdym vypadkem mi volaji klienti a takto to dal nejde. Mam srovnani s konkurenci, kde na podobne sluzbe nebyl za posledni 4 roky vypadek zadny, takze to lze a cleny si take nevybiraji.

Drive se tu sklonovaly napady udelat stabilni Node s vybranymi VPS. Nechci navrhovat reseni jen se snazim rict, ze si to zada nejaky funkcni napravny krok nebo aspon jeden clen vas opusti z duvodu kvality s produkcni VPS.

Jsem sam, kdo ma s kvalitou zasadni problem?

Diky za vyjadreni a s pozdravem Jirka Verunak 731 544 587 _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

Ahoj, vytvořit a vyhodnotit dotazník v google forms na téma "Kolik procent členů vyžaduje jaké SLA" je otázka minut. Patřím do skupiny členů - uživatelů, kteří jsou ochotni za premiovou službu zaplatit premiovou cenu. Před půl rokem se tu otevřelo téma vytvoření stabilní buňky s konzervativnější politikou nasazování aktualizací apod. Nevím zda je zrovna toto primární příčina výpadků nebo je to binec na uživatelských VPS. Někdo z aktivních členů ovšem odpověď zná a dokáže říct, co je se součanými "zdroji" možné - a jsme zpátky u toho, co popsal Nikos. Michal 2015-02-10 10:25 GMT+01:00 O. Auda <auda.aow@gmail.com>:

Ahoj,

myslím, že Nikos to shrnul moc pěkně, vidím to taky tak. S tímto jsem počítal při vstupu. A mimochodem, ta transparentnost v tom, co se děje, proč se tak děje a co se s tím dělá, je docela prima.

Olda

10. 2. 2015 v 10:04, Nikos Timiopulos <nikos@manikstudio.cz>:

Ahoj,

tohle je trochu ožehavé téma. Mě samotného výpadky také trápi, ale na obranu vpsfree.cz je třeba si uvědomit, že to není komerční služba, kam lze volat a buzerovat v případě výpadků. Každý, kdo tu teď diskutujeme, jsme členem sdružení, platíme si za členství a v rámci tohoto členství máme k dispozici VPS. Podstatné ale je, že vpsfree se svým charakterem nedá s komerčními službami srovnávat, žádnou službu vlastně nenabízí, natož nějaké garance. S tím je třeba počítat a zahrnout do úvahy výhody/nevýhody. Pro provoz vysoce dostupné služby v tuto chvíli 1 VPS u vpsfree vhodná není.

Jako členové máme kromě odchodu možnost si pořídit další VPS v druhém datacentru Praha/Brno a zkusit nějakou replikaci (cenově za ten výkon to stále může vycházet výhodněji), nebo ideálně, což se právě děje, vyvolat diskuzi o příčinách a hledat řešení. A ještě lépe přímo na členské schůzi.

Nevím teď přesně, jaký je stav aktivních členů, kteří se starají o chod a vyvíjejí (podle odměn 6 lidí?), ale podle výše těch odměn to asi nikdo nedělá na fulltime, což by také mohlo hrát roli a já bych se pak nebál zvednout ruku pro investici právě do této oblasti.

Nikos

On 10 Feb 2015, at 08:46, Michal Zobec (ZOBEC Consulting) < michal.zobec.news@gmail.com> wrote:

Ahoj,

Souhlasím, taky mi to už připadne nenormální … já k vám „přešel“ v listopadu. Mezitím začaly ty výpadky a tak nějak váhám jestli mám dokončit migraci. Sice máte super cenu ale u konkurence tohle fakt nezažívám …

…

s přátelským pozdravem | best regards

*Michal Zobec **| *Senior IT Consultant, Project Manager Mobil: +420 608960987 | Email: michal@zobec.net LinkedIn: www.linkedin.com/in/michalzobec | Na volne noze: www.navolnenoze.cz/prezentace/michal-zobec/

*ZOBEC Consulting | *Renneska trida 12, 63900 Brno, Czech Republic www.zobecconsulting.cz | www.michalzobec.cz | www.virtualnipc.cz LinkedIn: www.linkedin.com/company/michal-zobec-lightning-group-company

<image002.jpg>

Plánovaná nepřítomnost | Planned absence (none) …

*From:* community-list-bounces@lists.vpsfree.cz [ mailto:community-list-bounces@lists.vpsfree.cz <community-list-bounces@lists.vpsfree.cz>] *On Behalf Of *Jiří Veruňák *Sent:* Tuesday, February 10, 2015 8:33 AM *To:* vpsFree.cz Community list *Subject:* [vpsFree.cz: community-list] Vypadky Node5

Ahoj,

uz drive tu nekdo zvedal reseni castych vypadku a pro me je to posledni zvolani po naprave. Jde o vypadky od zacatku roku Node5 (10.2, 8.2, 25.1, 18.1) typicky to byla nedele dopoledne 20 minut. S kazdym vypadkem mi volaji klienti a takto to dal nejde. Mam srovnani s konkurenci, kde na podobne sluzbe nebyl za posledni 4 roky vypadek zadny, takze to lze a cleny si take nevybiraji.

Drive se tu sklonovaly napady udelat stabilni Node s vybranymi VPS. Nechci navrhovat reseni jen se snazim rict, ze si to zada nejaky funkcni napravny krok nebo aspon jeden clen vas opusti z duvodu kvality s produkcni VPS.

Jsem sam, kdo ma s kvalitou zasadni problem?

Diky za vyjadreni a s pozdravem Jirka Verunak 731 544 587 _______________________________________________ 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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Ahojte, o vypadcich node5 vime a nenechavame to jen tak. Nicmene neni jednoduche odladit, kde presne vznika problem, kdyz se ta masina zasekne tak, ze ani stack trace z ni nejde vydolovat. Nejlepsim resenim pro ted bude z nejvice postizenych stroju odhazet kontejnery, ktere vyuzivaji nejvic RAM, na cisty stroj, ktery bych mel dnes/zitra nainstalovat. Tim by melo mnozstvi problemu radove ustat. Dalsi vec je, ze vsechny ty problemy resime s upstreamem, at uz s vyvojari OpenVZ nebo ZFS, cili by se situace mela zlepsovat. Pokud pro nekoho je (ted vcelku casty) restart problem, coz se ani nedivim, ze problem je - neni potreba cekat, az pretece cise trpelivosti, kdyz se clovek rozhlidne, node5 neni jediny server, co mame a v clusteru mame taky stroje, ktere maji uptime aktualne 146 dni. Z nejakeho duvodu se nam na node4.prg, node5.prg, node8.prg a node2.brq seslo neco, co tomu jadru nedela dobre. Pred 7mi dny jsme na nich aktualizovali jadro a ZFS patchnute o dlouhodobe resene problemy se spravou pameti, na node8.prg a node2.brq to, zda se, problemy vyresilo, ale node4.prg a node5.prg trpi problemy dal, pricemz node5 je na tom absolutne nejhur. Pro ty z vas, kteri potrebuji situaci resit ASAP, piste na podporu, popresouvame ty VPS na stabilnejsi stroje (a ano, je pravdepodobnost, ze tim presunem i kontejner, ktery to shazuje tim, co dela - ale to by bylo spis dobre, nez spatne, protoze budeme mit jasno). K tomu, co pise Nikos - ano, dostupnost a garance jsou u nas "ozehave" tema zhruba ve smyslu, jak to Nikos popisuje, ale v momente, kdy jsme se s poctem clenu prehoupnuli pres pul tisicovky a mirime k tisicovce cele, uz to tak jak tak, at jsme dobrovolne sdruzeni nebo ne, nejde brat jen tak na lehkou vahu - problemy s jednim nebo izolovanym poctem stroju pak hazi spatne svetlo na cele sdruzeni, zatim co stovky clenu jsou spokojene, najde se par desitek, ktere jsme vypekli temi vypadky a kteri o nas moc dobreho mezi lidmi nereknou - a to nechceme. No a k poslednimu Nikove odstavci mam akorat aktualni zpravu :) Jelikoz jsme se rozhodli ukoncit podnikani v Bratislave a zavrit spolecnost Relbit, ktere jsem do ted venoval drtivou vetsinu casu, mel jsem ted moznost se rozhodnout, co dal se sebou, jestli mam jit nekam pracovat (vzhledem k me praxi za celkem slusne penize), nebo jestli zkusit cestu "vetsiho punku" a jit delat vpsFree na full-time. Tedy, situace se vyvinula tak, ze jsem se pred tydnem a neco konecne zabydlel v Brne, aktualne se venuju rozbehani clusteru pro jednoho zakaznika, ale jakmile to budu mit hotove, dostane to nase sdruzeni moji maximalni pozornost. Cili odhadem cca 3-4 tydny a potom se budu vpsFree venovat vicemene na plny uvazek - ale jelikoz by mne vpsFree nezvladlo adekvatne zaplatit, musim si prave vyresit dalsi prijem k tomu, proto mesicni zbrzdeni. Mezitim vyplnuju bugy a komunikuju s vyvojari software, ktery pouzivame a ktery ma nejvetsi problemy u nas, cili veci se hybou, ale nez budu mit cas naplno se ponorit do Ccka a zdrojaku, ktere pouzivame, bude to cca mesic trvat. Do te doby jako docasny workaround rozbalancujeme zatez a popresouvame VPSka, jak to pujde + musime posbirat dostatecne mnozstvi debug informaci, aby bylo od ceho se odrazit. All in all, tyhle problemy mame, protoze nepouzivame zadny dobre znamy stack software - kdybychom pouzivali KVM a jako storage LVM, to je velmi dobre testovane (Red Hat na tom stavi byznys preci) a funguje to, nicmene takovy pristup je IMHO prave vhodny pro komercni poskytovatele, kteri potrebuji poskytnout sluzbu, zkasirovat a vic neresit. U nas je to o co nejlepsim sharovani tech HW prostredku, co uz jsme si nakoupili, coz KVM ani trochu neumoznuje. V podstate to neumoznuje zadna out-of-box dostupna technologie v Linuxu, proto se starame o vlastni platformu. Vlastni platforma nam potom umoznuje delat kouzla a integraci, jaka by s cizi (a plnou) virtualizaci nebyla vubec myslitelna. Uz pred 6 lety jsem si myslel, ze jit cestou kontejneru, i kdyz vsichni jdou cestou plne virtualizace, je ta spravna cesta pro nas. Snahy o LXC a use-cases, pro ktere jsou podobne technologie mirene, to akorat potvrzuji a ukazuje se, ze kontejnery jako technologie jsou mnohem vhodnejsi pro typy workloadu, jako mame my. Chtel bych tohle obhajit a dal byt prukopnikem v oblasti, chci, abychom technologie spis rozvijeli a byli na spicce vyvoje, nez se jenom vezli a pouzivali to nejposlednejsi a nejvic otestovane. Samozrejme to znamena uplne jinou casovou narocnost a narocnost na vedomosti, ale presne proto vpsFree.cz od zacatku aspon ja osobne delam - silene mne to bavi. A ted mam prilezitost se tomu venovat na plno. Hodlam ji vyuzit a tesim se na ni. S pozdravem / Best regards, Pavel Snajdr +421 948 816 186 | +420 720 107 791 | 110-010-956 CTO of Relbit | Predseda vpsFree.cz, o.s. | RHCE http://relbit.com | http://vpsfree.cz | https://www.redhat.com On 02/10/2015 10:04 AM, Nikos Timiopulos wrote:

Ahoj,

tohle je trochu ožehavé téma. Mě samotného výpadky také trápi, ale na obranu vpsfree.cz je třeba si uvědomit, že to není komerční služba, kam lze volat a buzerovat v případě výpadků. Každý, kdo tu teď diskutujeme, jsme členem sdružení, platíme si za členství a v rámci tohoto členství máme k dispozici VPS. Podstatné ale je, že vpsfree se svým charakterem nedá s komerčními službami srovnávat, žádnou službu vlastně nenabízí, natož nějaké garance. S tím je třeba počítat a zahrnout do úvahy výhody/nevýhody. Pro provoz vysoce dostupné služby v tuto chvíli 1 VPS u vpsfree vhodná není.

Jako členové máme kromě odchodu možnost si pořídit další VPS v druhém datacentru Praha/Brno a zkusit nějakou replikaci (cenově za ten výkon to stále může vycházet výhodněji), nebo ideálně, což se právě děje, vyvolat diskuzi o příčinách a hledat řešení. A ještě lépe přímo na členské schůzi.

Nevím teď přesně, jaký je stav aktivních členů, kteří se starají o chod a vyvíjejí (podle odměn 6 lidí?), ale podle výše těch odměn to asi nikdo nedělá na fulltime, což by také mohlo hrát roli a já bych se pak nebál zvednout ruku pro investici právě do této oblasti.

Nikos

...

On 10 Feb 2015, at 08:46, Michal Zobec (ZOBEC Consulting) <michal.zobec.news@gmail.com <mailto:michal.zobec.news@gmail.com>> wrote:

Ahoj,

Souhlasím, taky mi to už připadne nenormální … já k vám „přešel“ v listopadu. Mezitím začaly ty výpadky a tak nějak váhám jestli mám dokončit migraci. Sice máte super cenu ale u konkurence tohle fakt nezažívám …

…

s přátelským pozdravem | best regards

*Michal Zobec **| *Senior IT Consultant, Project Manager Mobil: +420 608960987 | Email: michal@zobec.net <mailto:michal@zobec.net> LinkedIn: www.linkedin.com/in/michalzobec <http://www.linkedin.com/in/michalzobec> | Na volne noze: www.navolnenoze.cz/prezentace/michal-zobec/ <http://www.navolnenoze.cz/prezentace/michal-zobec/>

*ZOBEC Consulting | *Renneska trida 12, 63900 Brno, Czech Republic www.zobecconsulting.cz <http://www.zobecconsulting.cz/> | www.michalzobec.cz <http://www.michalzobec.cz/> | www.virtualnipc.cz <http://www.virtualnipc.cz/> LinkedIn: www.linkedin.com/company/michal-zobec-lightning-group-company <http://www.linkedin.com/company/michal-zobec-lightning-group-company>

<image002.jpg>

Plánovaná nepřítomnost | Planned absence (none) …

*From:* community-list-bounces@lists.vpsfree.cz <mailto:community-list-bounces@lists.vpsfree.cz> [mailto:community-list-bounces@lists.vpsfree.cz] *On Behalf Of *Jiří Veruňák *Sent:* Tuesday, February 10, 2015 8:33 AM *To:* vpsFree.cz Community list *Subject:* [vpsFree.cz: community-list] Vypadky Node5

Ahoj,

uz drive tu nekdo zvedal reseni castych vypadku a pro me je to posledni zvolani po naprave. Jde o vypadky od zacatku roku Node5 (10.2, 8.2, 25.1, 18.1) typicky to byla nedele dopoledne 20 minut. S kazdym vypadkem mi volaji klienti a takto to dal nejde. Mam srovnani s konkurenci, kde na podobne sluzbe nebyl za posledni 4 roky vypadek zadny, takze to lze a cleny si take nevybiraji.

Drive se tu sklonovaly napady udelat stabilni Node s vybranymi VPS. Nechci navrhovat reseni jen se snazim rict, ze si to zada nejaky funkcni napravny krok nebo aspon jeden clen vas opusti z duvodu kvality s produkcni VPS.

Jsem sam, kdo ma s kvalitou zasadni problem?

Diky za vyjadreni a s pozdravem Jirka Verunak 731 544 587 _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto: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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAlTZ140ACgkQgRwOVqYrsFVdUAD/drif7rwW1B1D3tfMlpWe2Clq X6ge4e6tPYOzUKFWDhEA/1te1mBEC/xJfne/qMP3geI+htQKkp2pFEtB2COXQHEr =PBkl -----END PGP SIGNATURE-----

Zdravim, zasa nevyhoda KVM (podla mojho laickeho nazoru) je, ze volna ram-ka sa neda zdielat medzi roznymi VM. Napriklad nas stroj momentalne pouziva len 1gb ram, co znamena, ze dalsie 3gb moze byt pouzite na ine ucely, ine VM... Nevyznam sa vsak vo virtualizacii, rad sa necham poucit. On 10.02.2015 11:57, Jirka Bourek wrote:

Pavel Snajdr wrote:

...

Uz pred 6 lety jsem si myslel, ze jit cestou kontejneru, i kdyz vsichni jdou cestou plne virtualizace, je ta spravna cesta pro nas. Snahy o LXC a use-cases, pro ktere jsou podobne technologie mirene, to akorat potvrzuji a ukazuje se, ze kontejnery jako technologie jsou mnohem vhodnejsi pro typy workloadu, jako mame my.

Já bych se tady trochu zastal KVM a plné virtualizace obecně - ono to není jenom o tom, že je to dobře otestované, ale taky má mnohem jednodušší práci. To, že si ve virtuálu pustíte vlastní kernel, vám šetří spoustu práce jinde, protože najednou kernel hostitele nemusí řešit to, že má čtyřicet procesů s PID 1, že je v systému spousta síťovek, ale každý vidí jenom nějaké a tak.

Samozřejmě penalizací za to je o něco málo nižší výkon, ale upřímně, hardware je (relativně) levný.

A vývoj pak samozřejmě nestojí a protože je víc uživatelů plné virtualizace - spokojených se stabilitou i výkonem - jde do jejího vývoje víc prostředků. S těmi se pak snadno dohání/dohnalo to, co je na kontejnerech dobré.

Ohledně té stability - měl jsem pár let zpátky možnost nakouknout pod pokličku jinému uživateli OpenVZ a co jsem slyšel, to bylo dost děsivé (proces v hostovi zaseknutý tak, že šel zlikvidovat jenom restartem hostitele a tak.) To zase musím uznat, že lidi ve vpsfree odvádějí obrovský kus práce, díky kterému ty VPS fungují tak dobře, jak fungují _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

Dne 10.2.2015 v 13:07 Jirka Bourek napsal(a):

U vpsfree to není vidět, ale minimálně část z těch "volných" 3GB se takhle bude používat.

Nody mají všechny 256 GB paměti a průměrně 100 GB na nich zabírají ostrá data jednotlivých VPS. Zbytek se používá na společnou diskovou cache, což je obrovská výhoda a umožňuje to ve výsledku současný stav, kdy se drtivá většina I/O provozu odehrává v RAM. -- Petr Krčmář vpsFree.cz

-----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? Konkretne na node5 co se tyce RAM kontejneru, to vypada takhle - druhej sloupec je pouzita RAM, treti je limit (maximum, co muze CT pouzit): [root@node5.prg.vpsfree.cz] ~ # vzlist -Ho ctid,physpages,physpages.l | awk '{ printf "%10s\t%10.2f MB\t%10.2f MB\n", "****", $2/256, $3/256; }' | sort -k2n **** 21.38 MB 4096.00 MB **** 42.86 MB 4096.00 MB **** 45.86 MB 4096.00 MB **** 46.38 MB 4096.00 MB **** 55.22 MB 4096.00 MB **** 61.79 MB 4096.00 MB **** 65.56 MB 4096.00 MB **** 73.11 MB 4096.00 MB **** 73.77 MB 4096.00 MB **** 94.55 MB 4096.00 MB **** 112.35 MB 4096.00 MB **** 118.19 MB 4096.00 MB **** 122.36 MB 4096.00 MB **** 128.89 MB 4096.00 MB **** 129.13 MB 4096.00 MB **** 142.07 MB 4096.00 MB **** 147.91 MB 4096.00 MB **** 175.71 MB 4096.00 MB **** 190.92 MB 4096.00 MB **** 192.06 MB 4096.00 MB **** 193.20 MB 4096.00 MB **** 205.00 MB 4096.00 MB **** 207.98 MB 4096.00 MB **** 229.64 MB 4096.00 MB **** 236.94 MB 4096.00 MB **** 238.64 MB 4096.00 MB **** 295.70 MB 4096.00 MB **** 304.15 MB 4096.00 MB **** 312.55 MB 4096.00 MB **** 325.16 MB 4096.00 MB **** 331.49 MB 4096.00 MB **** 366.92 MB 4096.00 MB **** 380.72 MB 4096.00 MB **** 385.47 MB 4096.00 MB **** 421.50 MB 4096.00 MB **** 445.71 MB 4096.00 MB **** 447.61 MB 4096.00 MB **** 463.60 MB 4096.00 MB **** 472.57 MB 4096.00 MB **** 481.50 MB 4096.00 MB **** 500.85 MB 4096.00 MB **** 521.79 MB 4096.00 MB **** 524.90 MB 4096.00 MB **** 528.19 MB 4096.00 MB **** 546.50 MB 4096.00 MB **** 558.87 MB 4096.00 MB **** 566.52 MB 4096.00 MB **** 578.58 MB 4096.00 MB **** 610.66 MB 4096.00 MB **** 614.10 MB 4096.00 MB **** 631.46 MB 4096.00 MB **** 633.26 MB 4096.00 MB **** 642.01 MB 4096.00 MB **** 645.02 MB 4096.00 MB **** 655.37 MB 4096.00 MB **** 716.04 MB 4096.00 MB **** 716.58 MB 4096.00 MB **** 722.77 MB 4096.00 MB **** 734.97 MB 4096.00 MB **** 744.45 MB 4096.00 MB **** 789.10 MB 4096.00 MB **** 815.24 MB 4096.00 MB **** 832.77 MB 4096.00 MB **** 869.09 MB 4096.00 MB **** 890.22 MB 4096.00 MB **** 901.20 MB 4096.00 MB **** 1002.91 MB 4096.00 MB **** 1036.48 MB 4096.00 MB **** 1036.65 MB 4096.00 MB **** 1040.54 MB 4096.00 MB **** 1114.04 MB 4096.00 MB **** 1124.09 MB 4096.00 MB **** 1144.97 MB 4096.00 MB **** 1161.19 MB 4096.00 MB **** 1163.27 MB 4096.00 MB **** 1210.90 MB 4096.00 MB **** 1219.21 MB 4096.00 MB **** 1251.27 MB 4096.00 MB **** 1262.60 MB 4096.00 MB **** 1298.83 MB 4096.00 MB **** 1305.11 MB 4096.00 MB **** 1406.04 MB 4096.00 MB **** 1412.97 MB 4096.00 MB **** 1431.59 MB 4096.00 MB **** 1442.28 MB 4096.00 MB **** 1491.90 MB 4096.00 MB **** 1577.61 MB 4096.00 MB **** 1710.93 MB 4096.00 MB **** 1847.06 MB 4096.00 MB **** 1932.87 MB 4096.00 MB **** 2027.19 MB 4096.00 MB **** 2042.27 MB 4096.00 MB **** 2632.69 MB 4096.00 MB **** 3174.29 MB 4096.00 MB **** 3893.23 MB 4096.00 MB **** 4089.19 MB 4096.00 MB **** 5066.41 MB 12288.00 MB **** 12402.32 MB 16384.00 MB /snajpa On 02/10/2015 01:34 PM, Jirka Bourek wrote:

...

Nody mají všechny 256 GB paměti a průměrně 100 GB na nich zabírají ostrá data jednotlivých VPS. Zbytek se používá na společnou diskovou cache, což je obrovská výhoda a umožňuje to ve výsledku současný stav, kdy se drtivá většina I/O provozu odehrává v RAM.

To je trochu zavádějící tvrzení - tohle není výhoda kontejnerů, ale výhoda toho, že ten stroj má hromadu RAM. Když z té hromady u plné virtualizace přidělíte dostatek RAM jednotlivým VM, výsledný stav bude stejný. _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iF4EAREIAAYFAlTaAUoACgkQgRwOVqYrsFXaFwEAnM9FL8XvsxAm2+XU3BiNVpFD 4FM5qmGJlBtP8aLb5XYA/2N8MbMVqxTispVNU3TKovvr+1ddna6B1Ws70/qF+hfg =nDiJ -----END PGP SIGNATURE-----

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/htm... 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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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.

Ceph by nešel? Já na něj zatím koukal jenom tak z rychlíku, ale distribuovaný je a k výslednému úložišti se dá přistupovat jako k block device, takže KVM by nad tím běžet mělo. (Mám za to, že KVM dokonce má podporu pro Ceph přímo, ale jak to funguje, to už fakt nemám tušení.) Jen tak pro představu, co taková 10GE síť může stát? Hádám, že to bude docela pálka.

Naposled, co jsem koukal, se uz za 100k dal sehnat 24 port 10GBase-T switch, sitovky jsou okolo desitky. Pro Prahu to ted dela dva switche, 12 sitovek a hromada Cat6 kabelu, odhadem neco okolo 350k.

Pro nové stroje se nechají sehnat servery s 10gbit síťovkami přímo na desce - nedávno jsem našel nějaké v nové nabídce od Supermicra. Ale nepochybuju o tom, že si to taky nechají zaplatit.

no najdrahsi bude switch, ale aj tam uz isli ceny celkom dole. Nedavno som kupoval jeden switch od dellu - N4032 a po zatlaceni spustili na asi 6500CHF. Sent from my BlackBerry 10 smartphone.   Original Message   From: Jirka Bourek Sent: Dienstag, 10. Februar 2015 15:41 To: community-list@lists.vpsfree.cz Reply To: vpsFree.cz Community list Subject: Re: [vpsFree.cz: community-list] Vypadky Node5

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.

Ceph by nešel? Já na něj zatím koukal jenom tak z rychlíku, ale distribuovaný je a k výslednému úložišti se dá přistupovat jako k block device, takže KVM by nad tím běžet mělo. (Mám za to, že KVM dokonce má podporu pro Ceph přímo, ale jak to funguje, to už fakt nemám tušení.) Jen tak pro představu, co taková 10GE síť může stát? Hádám, že to bude docela pálka. _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

Ahoj, nejsíš je to úplně mimo ale znáte tohle http://www.openvstorage.com/ ? K. 2015-02-10 15:40 GMT+01:00 Jirka Bourek <trekker.dk@abclinuxu.cz>:

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.

Ceph by nešel? Já na něj zatím koukal jenom tak z rychlíku, ale distribuovaný je a k výslednému úložišti se dá přistupovat jako k block device, takže KVM by nad tím běžet mělo.

(Mám za to, že KVM dokonce má podporu pro Ceph přímo, ale jak to funguje, to už fakt nemám tušení.)

Jen tak pro představu, co taková 10GE síť může stát? Hádám, že to bude docela pálka.

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

Např. https://rwmj.wordpress.com/2010/07/17/virtio-balloon/ Přímo od RH je ke stažení ISO image s ovladači Dne 10.2.2015 v 20:01 Martin Sivák napsal(a):

Ahoj,

...

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.

Je to přesně tak. Obvykle je vyžadován i guest agent, aby se dalo vhodně počítat, kolik paměti ta VM používá.

...

Red Hat na to asi nějakého démona mít bude, to už nevím.

MoM - http://gerrit.ovirt.org/gitweb?p=mom.git;a=summary

Ale je dost magie to vyladit.. zvlášť, když nastoupí ještě KSM (deduplikace stránek na hypervizoru). Linux totiž klidně vrátí všechnu volnou pamět.. a pak stačí, když si kernel řekne o nějaký buffer a Oops…. OOM killer nemá šanci vůbec reagovat. A když to je pomalejší, tak se občas stane, že OOM killer zabije guest agenta a tím znemožní vrácení paměti (protože MOM toho guesta začne ignorovat) :)

Jako jeden z hlavních vývojářů MoMu jsem takových situací viděl a vyvolal dost... Správa prostředků ve virtualizaci je občas velká "sranda". Vůbec to Pavlovi nezávidím (a mám VPS na jiném nodu ;).

On 10.02.2015 13:07, Jirka Bourek wrote:

Martin Vysny wrote:

...

Zdravim, zasa nevyhoda KVM (podla mojho laickeho nazoru) je, ze volna ram-ka sa neda zdielat medzi roznymi VM. Napriklad nas stroj momentalne pouziva len 1gb ram, co znamena, ze dalsie 3gb moze byt pouzite na ine ucely, ine VM... Nevyznam sa vsak vo virtualizacii, rad sa necham poucit.

No, ono pro začátek je potřeba si říct, co je to volná RAM - na dostatečně dlouho běžícím linuxovém stroji totiž žádnou volnou RAM mít nebudete, co nevyužijí aplikace, to využije kernel jako page cache (diskovou cache)

Dakujem za odpoved. Nejak zaciatocnicko-intuitivne pri OpenVZ a podobnych para-virtualnych rieseniach by som cakal, ze guesty ziadnu diskovu cache nemaju, resp. ju sharuju s hostom. Je vsak mozne, ze z nejakeho dovodu to tak nie je.

U vpsfree to není vidět, ale minimálně část z těch "volných" 3GB se takhle bude používat. Co tím chci říct, že když tuhle paměť použijete na jiné účely, zpomalí se I/O operace (čtění z disků) pro ten stroj, kterému takhle byla paměť odebrána (je častěji nutné tu I/O operaci provést, protože data nejsou v cache.) Je potřeba mít to na paměti, špatně to být nemusí.

U plné virtualizace lze sdílet paměť mezi VM taky, pokud to podporuje kernel hosta. V kernelu hosta je načtený ovladač "balón", který zajistí, že VM nebude používat nějakou část paměti, ta se vrátí kernelu hostitele a ten ji může dát jinému VM. Efektivně to bude fungovat stejně jako na OpenVZ (míň RAM pro diskové cache specifického hosta).

Vdaka, konecne viem na co je ten "baloon" ovladac ;)

Co vím, tak tohle není jediný mechanismus sdílení paměti mezi VM, ale v jakém stavu jsou ty ostatní, to teď z hlavy nedám.

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list