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):
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA256

 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@lists.vpsfree.cz
 [mailto:community-list-bounces@lists.vpsfree.cz] On Behalf Of
 Pavel Snajdr Sent: Wednesday, April 02, 2014 11:55 AM To:
 vpsFree.cz Community list Su
 bject:
Re: [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, 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@lists.vpsfree.cz
 [mailto:community-list-bounces@lists.vpsfree.cz] On Behalf Of
   Pavel Snajdr Sent: Wednesday, April 02, 2014 11:38 AM To:
 vpsFree.cz Community list Subject: [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@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

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 SIGNATURE-----
 Version: GnuPG v1
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iF4EAREIAAYFAlM77y4ACgkQMBKdi9lkZ6pWjwD/a0qiAdOAazaq+hv8fRmyV3QA
 WD3f7xQ+f/e2tfarq1QA/iBX6gfs28bZohfP91rO1a04zPGJpkgyufh530LDYPKe
 =73NH
 -----END PGP SIGNATURE-----

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