[vpsFree.cz: community-list] Vypadky a problemy - checklist

Fri Apr 11 08:27:22 CEST 2014

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

Aka. tim jsem chtel rict ze jsem ty automaticky migrace zrusil a ted
je poustim rucne po par jednotlivech VPS, tzn. jeste to mozna vypadne,
ale uz jenom na chvili a to uz bude konecne proto, ze pak uz fakt
budes mit tu VPS na node9.

S pozdravem

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 04/11/2014 08:19 AM, bacu at centrum.cz wrote:
> dobré ráno,
> 
> 
> 
> nemáte pls. nějakou přibližnou představu jak dlouho bude trvat
> 
> 
> Migration node8 -> node9 in progress
> 
> 
> 
> díky za info
> 
> 
> 
> Jan Macík
> 
> IT DEVELOPER
> 
> 
> 
> 776 005 239
> 
> 
> 
> 
> 
> ______________________________________________________________
>> Od: Pavel Snajdr <snajpa at snajpa.net> Komu: "vpsFree.cz Community
>> list" <community-list at lists.vpsfree.cz> Datum: 02.04.2014 19:35 
>> Předmět: Re: [vpsFree.cz: community-list] Vypadky a problemy -
>> checklist
>> 
> 
> On 04/02/2014 07:25 PM, Pavel Snajdr wrote:
>> Nakonec jsme se rozhodli pro trochu jiny reseni, je to ve
>> vyvoji, verim, ze se ukaze jako zivotaschopna. Dneska mam plodnej
>> den :)
> 
>> Stavime na blackholingu, MAI ho podporuje a pokud vim, tak to
>> pak propaguji i dal (kam se da, to proverim a budu tlacit na
>> zavedeni, pokud neni).
> 
>> Zkusime na to jit distribuovane, nepotrebujeme big box ani 
>> centralni bod, kterej by videl vsechen traffic.
> 
>> Mirime na reakcni cas do 1, max 1.5 minuty, zatim zapracujeme do 
>> vpsAdminu sbirani dat o toku dostatecne casto (co to pujde).
>> Potom podle dat vymodelujeme nejaky algoritmus, co bude delat
> 
>> a] blackholing decision b] QoS shaper decision
> 
>> + vpsadmind dostane podporu ovladat BIRD (aby mohl MAI oznamit 
>> blackholes, bude na to dedikovana instance BIRDu)
> 
>> + vpsadmind dostane podporu tc+htb
> 
> Slabinu navrhu vidim v jednom miste - spolejham se, ze v pripade
> DDoSu neco porad dotece na hw, kde ta cilova VPS je. Nebojim se, ze
> by se ten traffic nedal stihat (a stihat odcitat tak casto),
> vpsadmin uz ho ted cte kazdou chvili (v minutach) a nebyl problem,
> zachytavani pres iptables chainy uz tam je kvuli accountingu
> trafficu.
> 
> To je sice pravda, ale umim si predstavit situaci, kdyby to ten
> router neudrzel a proste z toho spadnul.
> 
> Nicmene to se zatim nikdy nestalo, jediny side-effect je, ze jsem 
> prisel na fakt, ze mame poskozenou medenou linku na prvni router - 
> projevila se jeji poruchovost...
> 
> /snajpa
> 
> 
>> /snajpa
> 
>> On 04/02/2014 07:12 PM, Stanislav Petr wrote:
>>> Jinak tomu jak rikas null routovani se rika blackholing. A uz 
>>> jsem popisoval jednoduse scriptovatelny reseni je sflow sonda
>>> na ASBR a napr. pmacct jako collector.
> 
> 
> 
>>> On 2. dubna 2014 14:57:01 CEST, Michal Krajcirovic 
>>> <michal at krajcirovic.cz> wrote:
> 
>>> Kluci, mozna ted budu vypadat desne nekompetentne a verejne se
>>> tu znemoznim :) Ale nestalo by za to udelat na vpsfree dve 
>>> "varianty", kdy by si mohl clovek zvolit, jestli chce 
>>> nejmodernejsi featury za cenu rizik s horsi dostupnosti, nebo
>>> na featury kasle, a preferuje dostupnost.
> 
>>> Napr. za sebe u vpsfree mam veci, ktery nejsou existencne 
>>> kriticky, ale je blby kdyz nejedou (tercialni dns, primarni 
>>> monitoring) - nelpim na poslednim buildu jadra a na kvantu 
>>> featur, naopak bych rad, kdybych mel co nejmene planovanych i 
>>> neplanovanych vypadku i za cenu, ze nebudu mit "to nejlepsi".
> 
>>> Prestoze nejakymu plgr prostredi co si chces udelat na
>>> testovani jader fandim, neverim ze tam dovedes nasimulovat ani
>>> vetsinu problemu ktere realne nastanou az proste "nekdo neco"
>>> udela.
> 
> 
>>> Soucasne jeste maly koment k tem DDOSum - u sve site (mam dva 
>>> upstreamy) mi jeden z nich (jde o fr eetel, pokud by to nekoho 
>>> zajimalo) umoznuje poslat prefix k null routovani s prislusnou 
>>> bgp komunitou a na jejich infrastrukture (a dle jejich
>>> vyjadreni i na infrastrukture jejich usptreamu) dojde
>>> automaticky k zariznuti. Tedy, pokud umime (idealne
>>> automaticky) detekovat na koho ten utok jde (coz pocitam ze
>>> ano), pak je to spis o tom dotlacit upstreama (master) k tomu,
>>> aby nam tuto featuru umoznil, a tipuju ze nebude nejak zvlast
>>> obtizny to naskriptovat, aby se to delo automaticky pri nejakym
>>> evidnetne problemovym chovani.
> 
>>> Zaverem - upgrade na 10GE nam jiste vyresi vetsi kapacitu pro 
>>> pripad utoku, ale jestli routujeme na birdu, nedelam si iluzi, 
>>> ze ten hw udrzi radove vetsi jednotky Gbit, aby bylo jak to 
>>> blokovat, na to je obavam se jedinou cestou router, co tech
>>> 10G opravdu uroutuje a nepujde do hnoje driv, nez vubec bude
>>> mozny nejaky prefix nullroutovat.
> 
>>> m
> 
> 
>>> Dne 2. 4. 2014 13:06 , Pavel Snajdr napsal(a):
> 
>>> On 04/02/2014 12:08 PM, Pavel Snajdr wrote:
> 
>>> A btw hlavni vyhoda ukladani dumpu po siti - nepotrebuju ten
>>> node nejak rozdejchavat na to, abych mohl zacit analyzovat
>>> dump.
> 
>>> Kdyz se mi povede vymyslet, co ted vymejslim s Infinibandem a 
>>> distribuovanym replikovanim ZFS, tak by se to melo projevit 
>>> naplno jako vyhoda - VPS budou nekde nabihat, zatim co ja muzu 
>>> analyzovat, proc to sletelo a nekdo jinej muze davat dokupy
>>> ten server primo (ssh/reseni se supportem v DC/...).
> 
>>> Kdezto s lokalnim kdumpem musim vzdycky tu masinu privyst k 
>>> zivotu a pak z toho tech 256GB vytahnout na misto, kde budu
>>> mit a] too lset b] dost RAM na analyzu. Ted si predstav tahat
>>> to ven z nodu po gigabitu...
> 
>>> Jeste ke kdumpum a proc ma smysl je delat:
> 
>>> Diky tomu, ze budeme mit kompletni image ram z momentu padu 
>>> serveru (pripadne se da dump vyvolat i pri zfs deadlocku
>>> atd.), jsme schopny potom post-mortem cokoliv dohledat a
>>> dodebugovat. Odpada tim nutnost na milionkrat se snazit ten bug
>>> reprodukovat.
> 
>>> A kdyz budeme pracovat ve spolupraci s lidma od OpenVZ / ZFS / 
>>> Red Hatu, coz postupne zacinam minimalne ja osobne vic a vic 
>>> (myslim ze muj nick uz znaji celkem duverne :D) delat, umozni
>>> nam to prijit k pomyslnymu stolu vyvoje tech opensource
>>> projektu, co nas zajimaji, s cennyma debug informacema na,
>>> ktery urychly zasadne hledani problemu.
> 
>>> Takze v tom vidim nejenom nutnost, ale v podstate i metodu,
>>> jak pomoct nejenom sobe, ale i celymu ekosystemu.
> 
>>> /snajpa
> 
>>> /snajpa
> 
>>> On 04/02/2014 12:01 PM, Pavel Snajdr wrote:
> 
>>> On 04/02/2014 11:58 AM, Stanislav Petr wrote:
> 
>>> Tak vytvorit servisni oddil na nejakym stavajicim disku nebo 
>>> zkusit zauvazovat nad pouzitim USB3 externi flash (sileny, ja 
>>> vim, ale mohlo by to fungovat levne).
> 
>>> Vsak prave, ze uz jsem varianty zvazoval a vzhledem k tomu, ze 
>>> 10GE se blizi tak jako tak. 1GE je tragicky malo, navic pri 
>>> zalohach uz 1GE dneska je limit, "zejtra" bude totalni limit
>>> pri prechodu z rsyncu na zfs send/receive - pak budou zalohy, 
>>> restory, migrace opravdu vyuzivat to, ze budou sedet na rychly 
>>> siti. Ab ych udelal misto na 256GB blbosti lokalne na kazdym 
>>> nodu, musel bych vyrazne zmensit cast SSD, ktera se pouziva
>>> pro level 2 read caching (a to se hodne pozna v momentech, kdy
>>> je na tom stroji min ramky, nez je idealni). Delani mista na
>>> rotacnich diskach je blbost, protoze by to rozhodilo tvar
>>> celyho zpoolu. Tak nejak mi nevysla jina moznost, nez
>>> NFSv3+10GE... /snajpa
> 
> 
>>> Stanislav Petr Tel.: +420 602 620 026 -----Original
>>> Message----- From: community-list-bounces at lists.vpsfree.cz 
>>> [mailto:community-list-bounces at lists.vpsfree.cz] On Behalf Of 
>>> Pavel Snajdr Sent: Wednesday, April 02, 2014 11:55 AM To: 
>>> vpsFree.cz <http://vpsFree.cz> Community list Su bject: Re: 
>>> [vpsFree.cz <http://vpsFree.cz>: community-list] Vypadky a 
>>> problemy - checklist Disk uz neni kam dat :) S pozdravem Pavel 
>>> Snajdr +421 948 816 186 | +420 720 107 791 | 110-010-956 CTO
>>> of Relbit | Predseda vpsFree.cz <http://vpsFree.cz>, o.s. |
>>> RHCE http://relbit.com | http://vpsfree.cz |
>>> https://www.redhat.com On 04/02/2014 11:49 AM, Stanislav Petr
>>> wrote:
> 
>>> Hele k tomu kdumpu a zfs. Jednoduchy a elegantni reseni -
>>> budto pridat jeden disk nebo oddil s EXT a ten vyhradit pro
>>> kdump. Tim ti odpadne problém se zapisovanim kdumpu do zfs
>>> kterej není podporovanej. Stanislav Petr Tel.: +420 602 620
>>> 026 -----Original Message----- From : 
>>> community-list-bounces at lists.vpsfree.cz 
>>> [mailto:community-list-bounces at lists.vpsfree.cz] On Behalf Of 
>>> Pavel Snajdr Sent: Wednesday, April 02, 2014 11:38 AM To: 
>>> vpsFree.cz <http://vpsFree.cz> Community list Subject: 
>>> [vpsFree.cz <http://vpsFree.cz>: community-list] Vypadky a 
>>> problemy - checklist Caute, vim, ze nekteri trpite zhruba
>>> stejne, jako ja, tak jak jsme na tom ted, a jak dlouho nas ten
>>> shitstorm jeste ceka, nez pomine? padajici ipv6: bird, snad
>>> pobezi, uvidime dal, prichozi ddosy: in progress, cosi se mozna
>>> rysuje ve spolupraci s Master Internet, nebo pripadne custom
>>> solution s BGP blackholingem, kernel panic: ted je tam kernel,
>>> kterej pres vsechny jeho chyby pokud vim na panic nepada, takze
>>> od nej je klid a dalsi kernel uz by mel projit lepsim
>>> testovanim, nez ho nasadime, zfs deadlock: po poupdatovani
>>> codebase napric vsema serverama se m i uz dari chytit stabilni
>>> ZFS setup na vsech nodech, takze se ZFS uz nebudou problemy
>>> (dokud se s nim zase nerozhodneme delat psi kusy, ale to pujde
>>> uz pres QA masinu) QA: minimalne jsem se dost nastval na to,
>>> aby mi nevadilo, ze vyhodime jednu velkou silnou masinu na
>>> testovani, takze ohledne QA se veci snad taky pohnou. kdump:
>>> potrebujeme 10GE infratrukturu po ktery sbirat memory dumpy
>>> odpadlejch nodu, bez toho je kdump celkem useless,
> 
> 
>>> -> seznam je to nepekne nekratkej, nastesti vsechno uz ve
>>> stavu pri nejhorsim "znam reseni", n o uz by se na nej nemuselo
>>> nic chvili pridavat, protoze jinak uz mne z toho chytaji
>>> infarktovy stavy... Navic mam tuseni, ze hranice trpelivosti,
>>> nez zacnou lidi hromadne migrovat veci pryc, je tak nejak
>>> blizko a ted uz to proste musi vsechno bezet bez problemu, i za
>>> cenu odlozeni nejakych inovaci na par mesicu. 
>>> ------------------------------------------------------------------------
>
>>>  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
> 
>>> ------------------------------------------------------------------------
>
>>> 
>>> 
> 
>> 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
> 
>>> ------------------------------------------------------------------------
>
>>> 
>>> 
> 
>> 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
> 
> 
>>> ------------------------------------------------------------------------
>
>>>  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<
>>> br />http://lists.vpsfree.cz/listinfo/community-list
> 
> 
>>> -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. 
>>> Omluvte prosím moji stručnost.
> 
> 
>>> _______________________________________________ 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
> 
> _______________________________________________ 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
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlNHi0oACgkQMBKdi9lkZ6rVyQEAxBF/Oy0MPivfflA1+u+eNRi3
Be8QvtmLScGn9FQz8ZUA/2BF/5JO+NrPpeH7Msqz4e+br9LMjURv2Ng/VtQ98oYd
=uEIm
-----END PGP SIGNATURE-----