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

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(a)gmail.com>om>:

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

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:

Dne 10.2.2015 v 13:07 Jirka Bourek napsal(a): 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(a)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:

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/ht… 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):

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.

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(a)lists.vpsfree.cz Reply To: vpsFree.cz Community list Subject: Re: [vpsFree.cz: community-list] Vypadky Node5 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(a)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(a)abclinuxu.cz>cz>:

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

On 10.02.2015 13:07, Jirka Bourek wrote: 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. Vdaka, konecne viem na co je ten "baloon" ovladac ;)