-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
/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(a)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(a)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
<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(a)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
<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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
------------------------------------------------------------------------
Community-list mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
------------------------------------------------------------------------
mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
------------------------------------------------------------------------
Community-list mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
------------------------------------------------------------------------
Community-list mailing list Community-list(a)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(a)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/
iF4EAREIAAYFAlM8SAgACgkQMBKdi9lkZ6qd8wEAhPJWT5ibyppCvtxk8WZAObEv
7qq4rUfiGAQ00G3FFT8BAIbjYLIoAL7G8jLYYe8U6+r9hhvVoyJBjaTgKC4qJzzr
=FmYC
-----END PGP SIGNATURE-----