-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ahoj,
mame chybu v navrhu implementace mass migrations, uplne tam chybi
prioritizace rozdelanych tasku (tzn nerozlisuje jestli uz nejakou VPS
poslal k zemi a ted by si mel pospisit ji dodelat, nebo zacit migrovat
dalsi jinou). OMFG.
Aither zas bude mit co programovat (hlavne ze tam ty priority udelal,
ale pak je pouzije spatne, ach jo).
S pozdravem
Pavel Snajdr
+421 948 816 186 | +420 720 107 791 | 110-010-956
CTO of Relbit | Predseda vpsFree.cz, o.s. | RHCE
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
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> 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
>
------------------------------------------------------------------------
> 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
_______________________________________________
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/
iF4EAREIAAYFAlNHixcACgkQMBKdi9lkZ6rddAEAxXpfQYmWxFZagiuOoAvuqw5F
Q5iKljJhT48KXk1VDOYBAMBjoMnAm63+obmGGvyLVFHSjCoWzu9rin8ZSQqoinB4
=l/CS
-----END PGP SIGNATURE-----