Hlavne ze si rozumime ;) Jde o to, ze to co pisu ma - aspon z mych
vlastnich zkusenosti - smysl jen tehdy, kdyz minimalne tvuj upstream
dokaze toto od tebe brat automaticky a cinit totez i na sve strane.
Jinak je ti na prd ze nullroutujes neco, ceho ti prichazi do site tolik,
ze ti to ucpe hrdlo... A ze i 10gigovy hrdlo se ucpe raz dva (nemluve o
tom, ze driv spadne ten bird)
m
Dne 2. 4. 2014 19:12, Stanislav Petr napsal(a):
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):
-----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(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
------------------------------------------------------------------------
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
http://lists.vpsfree.cz/listinfo/community-list
------------------------------------------------------------------------
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/
iF4EAREIAAYFAlM77y4ACgkQMBKdi9lkZ6pWjwD/a0qiAdOAazaq+hv8fRmyV3QA
WD3f7xQ+f/e2tfarq1QA/iBX6gfs28bZohfP91rO1a04zPGJpkgyufh530LDYPKe
=73NH -----END PGP SIGNATURE-----
------------------------------------------------------------------------
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