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(a)snajpa.net>
Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz>
Datum: 02.04.2014 19:35
Předmět: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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(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 <http://vpsFree.cz>> Community list Su bject:
Re:
[vpsFree.cz <http://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 <http://vpsFree.cz>>, o.s. |
RHCE
http://relbit.com <http://relbit.com> |
http://vpsfree.cz <http://vpsfree.cz>
|
https://www.redhat.com <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 <http://vpsFree.cz>> Community list Subject:
[vpsFree.cz <http://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
<http://lists.vpsfree.cz/listinfo/community-list>
------------------------------------------------------------------------
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>
------------------------------------------------------------------------
Community-list
mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>
------------------------------------------------------------------------
Community-list
mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>
------------------------------------------------------------------------
Community-list
mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>
------------------------------------------------------------------------
Community-list
mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>
------------------------------------------------------------------------
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
<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
<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
<http://lists.vpsfree.cz/listinfo/community-list>
_______________________________________________ Community-list
mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
<http://www.enigmail.net/>
iF4EAREIAAYFAlM8SjIACgkQMBKdi9lkZ6qryQD9G0N2z6BE4OcpLszx4/uaEjZA
OcZiZxvLmO23Foi8Vc8BAL8T9htJh+UMdQ0ZG6kmYdS80TAHBJChKS/vO0Lv3WVV
=3kDr
-----END PGP SIGNATURE-----
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz