-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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 mi 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", no 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.
- -- 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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 mi 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", no 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.
- -- 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
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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 mi 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", no 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
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).
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 Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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 mi 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", no 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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.
Abych 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 Subject: 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 mi 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", no 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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] toolset b] dost RAM na analyzu. Ted si predstav tahat to ven z nodu po gigabitu...
/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.
Abych 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 Subject: 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 mi 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", no 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
-----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] toolset 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.
Abych 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 Subject: 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 mi 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", no 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
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 freetel, 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] toolset 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. Abych 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 Subject: 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 mi 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", no 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
Vybornej napad, hned me napadlo, jak to rozvinout a realizovat. Domyslim to a pak to popisu :)
Sent from your iPad
On Apr 2, 2014, at 14:57, Michal Krajcirovic michal@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 freetel, 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] toolset 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. Abych 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 Subject: 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 mi 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", no 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 http://lists.vpsfree.cz/listinfo/community-list
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@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 freetel, 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] toolset 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. Abych 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 Subject: 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 mi 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", no 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 http://lists.vpsfree.cz/listinfo/community-list
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@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@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@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@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-- 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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Routovat takovejhle provoz na linuxu nebo BSD s Birdem je samozrejme blbost, ale Bird se v tehle pripadech bezne pouziva jako route reflector. A samozrejme distribuovat blackhole z RR je bezne doporucovana praxe, protoze cpat blackhole prez spojeni kterym ten dos tece nemusi vest k uspechu - bh route zacne flapovat z duvodu ztratovosti a danej peer pokud ma agresivnejsi politiku bgp dampeningu muze tu routu uplne zahodit.
On 2. dubna 2014 19:18:07 CEST, Michal Krajcirovic michal@krajcirovic.cz wrote:
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@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 simohl
clovek zvolit, jestli chce nejmodernejsi featury za cenu rizik shorsi
dostupnosti, nebo na featury kasle, a preferuje dostupnost. Napr. za sebe u vpsfree mam veci, ktery nejsou existencnekriticky, 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, zenebudu mit
"to nejlepsi". Prestoze nejakymu plgr prostredi co si chces udelat na testovanijader
fandim, neverim ze tam dovedes nasimulovat ani vetsinu problemuktere
realne nastanou az proste "nekdo neco" udela. Soucasne jeste maly koment k tem DDOSum - u sve site (mam dvaupstreamy)
mi jeden z nich (jde o fr eetel, pokud by to nekoho zajimalo) umoznuje poslat prefix k null routovani s prislusnou bgp komunitou a najejich
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 tutofeaturu
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 propripad
utoku, ale jestli routujeme na birdu, nedelam si iluzi, ze ten hwudrzi
radove vetsi jednotky Gbit, aby bylo jak to blokovat, na to jeobavam se
jedinou cestou router, co tech 10G opravdu uroutuje a nepujde dohnoje
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 vyvojetech
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 jeblbost,
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 <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@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 jakdlouho
nas ten shitstorm jeste ceka, nez pomine? padajici ipv6: bird, snad pobezi, uvidimedal,
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 chytitstabilni
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 kterysbirat
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.czhttp://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.czhttp://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-- 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@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 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@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@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@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@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
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
-- 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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----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@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@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@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@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
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
-- 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@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
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@snajpa.net Komu: "vpsFree.cz Community list" community-list@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@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@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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list
mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list
mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list
mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list
mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
-----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 http://relbit.com | http://vpsfree.cz | https://www.redhat.com
On 04/11/2014 08:19 AM, bacu@centrum.cz wrote:
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@snajpa.net Komu: "vpsFree.cz Community list" community-list@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@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@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@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@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
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
-- 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@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 SIGNED MESSAGE----- Hash: SHA256
Aka. tim jsem chtel rict ze jsem ty automaticky migrace zrusil a ted je poustim rucne po par jednotlivech VPS, tzn. jeste to mozna vypadne, ale uz jenom na chvili a to uz bude konecne proto, ze pak uz fakt budes mit tu VPS na node9.
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/11/2014 08:19 AM, bacu@centrum.cz wrote:
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@snajpa.net Komu: "vpsFree.cz Community list" community-list@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@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@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@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@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
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
-- 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@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
2014-04-02 12:01 GMT+02:00 Pavel Snajdr snajpa@snajpa.net:
-----BEGIN PGP SIGNED MESSAGE----- Abych 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.
RE: 256GB, Hovorime tu stale o kdump? Nemyslim, ze je nutne dumpovat komplet obsah RAM. makedumpfile (ktory je predpokladam pouzity) vie odfiltrovat user-space/zero/free stranky (parameter -d), takze vo vysledku by ten vmcore mal byt podstatne mensi.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 12:15 PM, Ján Stanček wrote:
2014-04-02 12:01 GMT+02:00 Pavel Snajdr <snajpa@snajpa.net mailto:snajpa@snajpa.net>:
-----BEGIN PGP SIGNED MESSAGE----- Abych 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.
RE: 256GB, Hovorime tu stale o kdump? Nemyslim, ze je nutne dumpovat komplet obsah RAM. makedumpfile (ktory je predpokladam pouzity) vie odfiltrovat user-space/zero/free stranky (parameter -d), takze vo vysledku by ten vmcore mal byt podstatne mensi.
Kdybych mel pocit, ze staci dumpovat jenom neco, tak bych to zminil :) For various reasons aby ty kdumpy k necemu byly, musi tam bejt vsechno. Nikdy nevis, co presne se podela a kdyz uz budu jednou takovouhle vec zprovoznovat, tak to musi fungovat poradne a ne ze mi kdump ve vetsine pripadu bude slouzit akorat jako ted podivani se na konzoli - "hmmm hezky podle stack trace to pada asi tak tady nekde, mozna"...
Kapis? :)
/snajpa
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 02 Apr 2014 12:18:16 +0200 Pavel Snajdr snajpa@snajpa.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 12:15 PM, Ján Stanček wrote:
2014-04-02 12:01 GMT+02:00 Pavel Snajdr <snajpa@snajpa.net mailto:snajpa@snajpa.net>:
-----BEGIN PGP SIGNED MESSAGE----- Abych 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.
RE: 256GB, Hovorime tu stale o kdump? Nemyslim, ze je nutne dumpovat komplet obsah RAM. makedumpfile (ktory je predpokladam pouzity) vie odfiltrovat user-space/zero/free stranky (parameter -d), takze vo vysledku by ten vmcore mal byt podstatne mensi.
Kdybych mel pocit, ze staci dumpovat jenom neco, tak bych to zminil :) For various reasons aby ty kdumpy k necemu byly, musi tam bejt vsechno. Nikdy nevis, co presne se podela a kdyz uz budu jednou takovouhle vec zprovoznovat, tak to musi fungovat poradne a ne ze mi kdump ve vetsine pripadu bude slouzit akorat jako ted podivani se na konzoli - "hmmm hezky podle stack trace to pada asi tak tady nekde, mozna"...
Kapis? :)
Nechápu.
Zabývám se analýzou crash dumpů už nějaký ten pátek (cca 7 let?) a ještě nikdy jsem nepotřeboval např. obsah pagecache (ne metadata, ale vlastní obsah stránek, které tam byly nakešované). Teoreticky se může přepsat memmap, takže se odfiltruje stránka, která odfiltrovaná být neměla (protože má špatné pageflags), ale v takových případech k analýze zatím vždy stačila informace z té příslušné struct page.
Tj. opravdu nechápu, k čemu je potřeba ukládat úplný obraz paměti. Sorry.
Petr T
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 01:15 PM, Petr Tesařík wrote:
On Wed, 02 Apr 2014 12:18:16 +0200 Pavel Snajdr snajpa@snajpa.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 12:15 PM, Ján Stanček wrote:
2014-04-02 12:01 GMT+02:00 Pavel Snajdr <snajpa@snajpa.net mailto:snajpa@snajpa.net>:
-----BEGIN PGP SIGNED MESSAGE----- Abych 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.
RE: 256GB, Hovorime tu stale o kdump? Nemyslim, ze je nutne dumpovat komplet obsah RAM. makedumpfile (ktory je predpokladam pouzity) vie odfiltrovat user-space/zero/free stranky (parameter -d), takze vo vysledku by ten vmcore mal byt podstatne mensi.
Kdybych mel pocit, ze staci dumpovat jenom neco, tak bych to zminil :) For various reasons aby ty kdumpy k necemu byly, musi tam bejt vsechno. Nikdy nevis, co presne se podela a kdyz uz budu jednou takovouhle vec zprovoznovat, tak to musi fungovat poradne a ne ze mi kdump ve vetsine pripadu bude slouzit akorat jako ted podivani se na konzoli - "hmmm hezky podle stack trace to pada asi tak tady nekde, mozna"...
Kapis? :)
Nechápu.
Zabývám se analýzou crash dumpů už nějaký ten pátek (cca 7 let?) a ještě nikdy jsem nepotřeboval např. obsah pagecache (ne metadata, ale vlastní obsah stránek, které tam byly nakešované). Teoreticky se může přepsat memmap, takže se odfiltruje stránka, která odfiltrovaná být neměla (protože má špatné pageflags), ale v takových případech k analýze zatím vždy stačila informace z té příslušné struct page.
Tj. opravdu nechápu, k čemu je potřeba ukládat úplný obraz paměti. Sorry.
Podivej se na grafy vyuziti pameti @ https://prasiatko.vpsfree.cz/munin/ na nody node3.prg, node5.prg, node8.prg, node2.brq - tam uvidis, ze tech dat k dumpovani je obrovska hromada. Duvod je, ze ZFS nepouziva linuxovou cache, ale misto toho si alokuje svoji pamet a dela si cache samo. Ten algoritmus je uplne uzasnej, ma hitrate, o kterych se linux LRU dcache muze zdat a stalo by za to, abych se o nem rozepsal, nicmene to je OT.
Pointa je, ze na systemu, kde bezi ZFS, je diky ZFS samotnymu o hodne vic pameti, kterou potrebujeme mit v dumpu, nez na beznym linuxovym systemu. Z pohledu systemu jsou to vsechno slab cache, tezko rozeznat, ktera je na co pouzivana, to je totiz dany zpusobem, jakym bylo ZFS na Linux portovany - pres abstrakcni modul SPL (Solaris Porting Layer, par headeru a obalujicich funkci, nic vic). I tak, pokud se bavime o dumpovani uzitecnejch stranek, na vpsFree, pujde o 70GB dat (aplikace + a par dalsich drobnosti, to chces mit), a to jsou data narychlo z nodu, kde neni ZFS, tzn. ani tam neni tolik kontejneru (nebo jsou malinky), protoze by to nestihal filesystem. Data ZFS jsou potom dalsi desitky gigabajtu, jelikoz mezi tema slabama nejde moc rozlisit, co je struktura popisujici data a co data, dokud do nich nevidis.
Napad byl, ze bych nemusel resit dumpovani aplikaci v kontejnerech, ale kdyz to nejaka aplikace v kontejneru shodi v kontextu, ze pouziva napr. tun/tap nejak divne, tak to chci vedet... hypoteticky, kazdopadne userspace nema co shazovat jadro a ten userspace, co muze jadro shodit, je i v kontejnerech.
Nebo vis o necem, o cem ja ne?
/snajpa
Petr T _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps-virtual-private-server, ale nemám zkušenost.
Díky za rady a omlouvám se, pokud se to už někdy někde řešilo.
Dne 2. dubna 2014 11:58 Stanislav Petr glux@glux.org napsal(a):
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).
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 Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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 mi 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", no 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlM73mYACgkQMBKdi9lkZ6p3FwD+JFTJ5xlIc6KLQZ169YpIFWap wMmhwjioHfuneqqXvx0A/i8zMKZG3RBhuI6Snif5cfg04AwG7wzL0az4I8IZFEla =m2R9 -----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 http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Nechces se radsi zamyslet nad jinym zvysenim dostupnosti, nez ze uplne jina VPS pro ty projekty? Kdyz uz chces utracet navic prave ve jmenu dostupnosti, tak si porid nekde jinde jeste *dalsi* VPS a udelej mezi nima nejaky HA, podle toho, co aplikace povoluje, neprijde ti to jako lepsi reseni?
Presouvat to na jinej SPOF, kde sice slibujou, ze bude stabilnejsi, ale presto SPOF, kdyz uz te zacinaji stresovat vypadky, imho neni nejstastnejsi volba z tech, co mas na vyber.
/snajpa
On 04/02/2014 12:15 PM, Nikos Timiopulos wrote:
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps-virtual-private-server, ale nemám zkušenost.
Díky za rady a omlouvám se, pokud se to už někdy někde řešilo.
Dne 2. dubna 2014 11:58 Stanislav Petr <glux@glux.org mailto:glux@glux.org> napsal(a):
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).
Stanislav Petr Tel.: +420 602 620 026 tel:%2B420%20602%20620%20026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz mailto:community-list-bounces@lists.vpsfree.cz [mailto: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 Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
Disk uz neni kam dat :)
S pozdravem
Pavel Snajdr
+421 948 816 186 tel:%2B421%20948%20816%20186 | +420 720 107 791 tel:%2B420%20720%20107%20791 | 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 tel:%2B420%20602%20620%20026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz
mailto:community-list-bounces@lists.vpsfree.cz
[mailto: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 mi 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", no 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
mailto:Community-list@lists.vpsfree.cz
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz
mailto:Community-list@lists.vpsfree.cz
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz mailto: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
Budu se tím zabývat. Každopádně díky za tipy.
On 02 Apr 2014, at 12:30, Pavel Snajdr snajpa@snajpa.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Nechces se radsi zamyslet nad jinym zvysenim dostupnosti, nez ze uplne jina VPS pro ty projekty? Kdyz uz chces utracet navic prave ve jmenu dostupnosti, tak si porid nekde jinde jeste *dalsi* VPS a udelej mezi nima nejaky HA, podle toho, co aplikace povoluje, neprijde ti to jako lepsi reseni?
Presouvat to na jinej SPOF, kde sice slibujou, ze bude stabilnejsi, ale presto SPOF, kdyz uz te zacinaji stresovat vypadky, imho neni nejstastnejsi volba z tech, co mas na vyber.
/snajpa
On 04/02/2014 12:15 PM, Nikos Timiopulos wrote:
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps-virtual-private-server, ale nemám zkušenost.
Díky za rady a omlouvám se, pokud se to už někdy někde řešilo.
Dne 2. dubna 2014 11:58 Stanislav Petr <glux@glux.org <mailto:glux@glux.org glux@glux.org>> napsal(a):
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).
Stanislav Petr Tel.: +420 602 620 026 tel:%2B420%20602%20620%20026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz <mailto:community-list-bounces@lists.vpsfree.czcommunity-list-bounces@lists.vpsfree.cz
[mailto:community-list-bounces@lists.vpsfree.czcommunity-list-bounces@lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.czcommunity-list-bounces@lists.vpsfree.cz>] On Behalf Of Pavel Snajdr Sent: Wednesday, April 02, 2014 11:55 AM To: vpsFree.cz Community list Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
Disk uz neni kam dat :)
S pozdravem
Pavel Snajdr
+421 948 816 186 tel:%2B421%20948%20816%20186 | +420 720 107 791 tel:%2B420%20720%20107%20791 | 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 tel:%2B420%20602%20620%20026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.czcommunity-list-bounces@lists.vpsfree.cz
[mailto:community-list-bounces@lists.vpsfree.czcommunity-list-bounces@lists.vpsfree.cz
<mailto:community-list-bounces@lists.vpsfree.czcommunity-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 mi 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", no 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
<mailto:Community-list@lists.vpsfree.cz Community-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz
<mailto:Community-list@lists.vpsfree.cz Community-list@lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz 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
Nechci dělat vyloženě špatnou reklamu, ale pokud uvažuješ o komerečním poskytovateli, vyhýbej se na kilometr daleko hexageeku. Měli jsme tam servery a abych to shrnul - zpracování plateb řeší ručně, takže jsou s tím často problémy/prodlevy, při výpadku nekomunikují klidně i několik dní, technická podpora to samé...Když se podíváš na webtrh a přečteš si pár vláken o nich, uvidíš že nejsem sám :)
---------- Původní zpráva ---------- Od: Nikos Timiopulos nikos@manikstudio.cz Komu: vpsFree.cz Community list community-list@lists.vpsfree.cz Datum: 2. 4. 2014 12:16:24 Předmět: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
"
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps- virtual-private-server (http://www.hexageek.cz/cze/pages/vps-virtual-private-server), ale nemám zkušenost.
Díky za rady a omlouvám se, pokud se to už někdy někde řešilo.
Dne 2. dubna 2014 11:58 Stanislav Petr <glux@glux.org(mailto:glux@glux.org)> napsal(a): "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).
Stanislav Petr Tel.: +420 602 620 026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz (mailto:community-list-bounces@lists.vpsfree.cz) [mailto: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
Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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://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@lists.vpsfree.cz
(mailto:community-list-bounces@lists.vpsfree.cz)
[mailto: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 mi 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", no 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
(mailto:Community-list@lists.vpsfree.cz)
(http://lists.vpsfree.cz/listinfo/community-list)
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz
(mailto:Community-list@lists.vpsfree.cz)
(http://lists.vpsfree.cz/listinfo/community-list)
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list)
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list)
"
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list"
Záleží co hledáš,
- nejlevnější holé VPSky jsou u Wedos, nyní budou mít servery - slušné fyzické stroje s dobrou podporou nabízí Tele3 http://www.tele3.cz/pronajem-serveru-tabulka.html - uděláš si konfiguraci dle přání. Nabízí i silnější fyzické stroje, individuální konfigurace - Coolhousing, slušné stroje - http://www.coolhousing.net/hewlett-packard-servery.html - http://www.superhosting.cz/dedikovane-servery - pěkné - OVH.cz - Kimusufi, http://www.kimsufi.com/cz/#servers - OVH.cz - So you start - http://www.soyoustart.com/cz/ silnější modely - Hetzner - použité stroje, zajímavá cena, http://www.hetzner.de/en/hosting/produkte_rootserver/serverboerse nebo nové stroje a dalo by se pokračovat...
Dne 2.4.2014 12:51, Pavel Muller napsal(a):
Nechci dělat vyloženě špatnou reklamu, ale pokud uvažuješ o komerečním poskytovateli, vyhýbej se na kilometr daleko hexageeku. Měli jsme tam servery a abych to shrnul - zpracování plateb řeší ručně, takže jsou s tím často problémy/prodlevy, při výpadku nekomunikují klidně i několik dní, technická podpora to samé...Když se podíváš na webtrh a přečteš si pár vláken o nich, uvidíš že nejsem sám :)
---------- Původní zpráva ---------- Od: Nikos Timiopulos nikos@manikstudio.cz Komu: vpsFree.cz Community list community-list@lists.vpsfree.cz Datum: 2. 4. 2014 12:16:24 Předmět: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps-virtual-private-server, ale nemám zkušenost. Díky za rady a omlouvám se, pokud se to už někdy někde řešilo. Dne 2. dubna 2014 11:58 Stanislav Petr <glux@glux.org <mailto:glux@glux.org>> napsal(a): 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). Stanislav Petr Tel.: +420 602 620 026 -----Original Message----- From: community-list-bounces@lists.vpsfree.cz <mailto:community-list-bounces@lists.vpsfree.cz> [mailto: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 Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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> > [mailto: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 mi 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", no 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 01:45 PM, Vaclav Dusek wrote:
Záleží co hledáš,
- nejlevnější holé VPSky jsou u Wedos, nyní budou mít servery -
slušné fyzické stroje s dobrou podporou nabízí Tele3 http://www.tele3.cz/pronajem-serveru-tabulka.html - uděláš si konfiguraci dle přání. Nabízí i silnější fyzické stroje, individuální konfigurace - Coolhousing, slušné stroje - http://www.coolhousing.net/hewlett-packard-servery.html - http://www.superhosting.cz/dedikovane-servery - pěkné - OVH.cz - Kimusufi, http://www.kimsufi.com/cz/#servers - OVH.cz - So you start - http://www.soyoustart.com/cz/ silnější modely - Hetzner - použité stroje, zajímavá cena, http://www.hetzner.de/en/hosting/produkte_rootserver/serverboerse nebo nové stroje a dalo by se pokračovat...
Ne ze bych chtel pomlouvat, ale presne vsechny tyhle, co jsi vyjmenoval, neni vubec slozity sundat jenom UDP floodem. Neptej se jak to vim :)
/snajpa
Dne 2.4.2014 12:51, Pavel Muller napsal(a):
Nechci dělat vyloženě špatnou reklamu, ale pokud uvažuješ o komerečním poskytovateli, vyhýbej se na kilometr daleko hexageeku. Měli jsme tam servery a abych to shrnul - zpracování plateb řeší ručně, takže jsou s tím často problémy/prodlevy, při výpadku nekomunikují klidně i několik dní, technická podpora to samé...Když se podíváš na webtrh a přečteš si pár vláken o nich, uvidíš že nejsem sám :)
---------- Původní zpráva ---------- Od: Nikos Timiopulos nikos@manikstudio.cz Komu: vpsFree.cz Community list community-list@lists.vpsfree.cz Datum: 2. 4. 2014 12:16:24 Předmět: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps-virtual-private-server, ale nemám zkušenost.
Díky za rady a omlouvám se, pokud se to už někdy někde řešilo.
Dne 2. dubna 2014 11:58 Stanislav Petr <glux@glux.org mailto:glux@glux.org> napsal(a):
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).
Stanislav Petr Tel.: +420 602 620 026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz mailto:community-list-bounces@lists.vpsfree.cz [mailto: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 Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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
[mailto: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 mi 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", no 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 01:55 PM, Pavel Snajdr wrote:
On 04/02/2014 01:45 PM, Vaclav Dusek wrote:
Záleží co hledáš,
- nejlevnější holé VPSky jsou u Wedos, nyní budou mít servery -
slušné fyzické stroje s dobrou podporou nabízí Tele3 http://www.tele3.cz/pronajem-serveru-tabulka.html - uděláš si konfiguraci dle přání. Nabízí i silnější fyzické stroje, individuální konfigurace - Coolhousing, slušné stroje - http://www.coolhousing.net/hewlett-packard-servery.html - http://www.superhosting.cz/dedikovane-servery - pěkné - OVH.cz
- Kimusufi, http://www.kimsufi.com/cz/#servers - OVH.cz - So you
start - http://www.soyoustart.com/cz/ silnější modely - Hetzner
- použité stroje, zajímavá cena,
http://www.hetzner.de/en/hosting/produkte_rootserver/serverboerse
nebo nové stroje a dalo by se pokračovat...
Ne ze bych chtel pomlouvat, ale presne vsechny tyhle, co jsi vyjmenoval, neni vubec slozity sundat jenom UDP floodem. Neptej se jak to vim :)
/snajpa
Teda az na Tele3, ty neznam.
/snajpa
Dne 2.4.2014 12:51, Pavel Muller napsal(a):
Nechci dělat vyloženě špatnou reklamu, ale pokud uvažuješ o komerečním poskytovateli, vyhýbej se na kilometr daleko hexageeku. Měli jsme tam servery a abych to shrnul - zpracování plateb řeší ručně, takže jsou s tím často problémy/prodlevy, při výpadku nekomunikují klidně i několik dní, technická podpora to samé...Když se podíváš na webtrh a přečteš si pár vláken o nich, uvidíš že nejsem sám :)
---------- Původní zpráva ---------- Od: Nikos Timiopulos nikos@manikstudio.cz Komu: vpsFree.cz Community list community-list@lists.vpsfree.cz Datum: 2. 4. 2014 12:16:24 Předmět: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps-virtual-private-server, ale nemám zkušenost.
Díky za rady a omlouvám se, pokud se to už někdy někde řešilo.
Dne 2. dubna 2014 11:58 Stanislav Petr <glux@glux.org mailto:glux@glux.org> napsal(a):
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).
Stanislav Petr Tel.: +420 602 620 026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz mailto:community-list-bounces@lists.vpsfree.cz [mailto: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 Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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
[mailto: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 mi 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", no 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
U každého je něco, ale celý život je o kompromisech...
Hexageek určitě ne (viz Webtrh, nikdo vlastně neví co je zač), Best-Hosting také ne (výpadky), Wedos má pomalé disky - IO operace.
Pak už znám jen něco v zahraničí za vodou - USA/Kanada
Osobně si myslím, že z hlediska poměru cena/výkonpodpora v CZ je VPSFree dobré, ale i zde se něco najde ;)
Dne 2.4.2014 13:55, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 01:45 PM, Vaclav Dusek wrote:
Záleží co hledáš,
- nejlevnější holé VPSky jsou u Wedos, nyní budou mít servery -
slušné fyzické stroje s dobrou podporou nabízí Tele3 http://www.tele3.cz/pronajem-serveru-tabulka.html - uděláš si konfiguraci dle přání. Nabízí i silnější fyzické stroje, individuální konfigurace - Coolhousing, slušné stroje - http://www.coolhousing.net/hewlett-packard-servery.html - http://www.superhosting.cz/dedikovane-servery - pěkné - OVH.cz - Kimusufi, http://www.kimsufi.com/cz/#servers - OVH.cz - So you start - http://www.soyoustart.com/cz/ silnější modely - Hetzner - použité stroje, zajímavá cena, http://www.hetzner.de/en/hosting/produkte_rootserver/serverboerse nebo nové stroje a dalo by se pokračovat...
Ne ze bych chtel pomlouvat, ale presne vsechny tyhle, co jsi vyjmenoval, neni vubec slozity sundat jenom UDP floodem. Neptej se jak to vim :)
/snajpa
Dne 2.4.2014 12:51, Pavel Muller napsal(a):
Nechci dělat vyloženě špatnou reklamu, ale pokud uvažuješ o komerečním poskytovateli, vyhýbej se na kilometr daleko hexageeku. Měli jsme tam servery a abych to shrnul - zpracování plateb řeší ručně, takže jsou s tím často problémy/prodlevy, při výpadku nekomunikují klidně i několik dní, technická podpora to samé...Když se podíváš na webtrh a přečteš si pár vláken o nich, uvidíš že nejsem sám :)
---------- Původní zpráva ---------- Od: Nikos Timiopulos nikos@manikstudio.cz Komu: vpsFree.cz Community list community-list@lists.vpsfree.cz Datum: 2. 4. 2014 12:16:24 Předmět: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps-virtual-private-server, ale nemám zkušenost.
Díky za rady a omlouvám se, pokud se to už někdy někde řešilo.
Dne 2. dubna 2014 11:58 Stanislav Petr <glux@glux.org mailto:glux@glux.org> napsal(a):
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).
Stanislav Petr Tel.: +420 602 620 026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz mailto:community-list-bounces@lists.vpsfree.cz [mailto: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 Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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
[mailto: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 mi 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", no 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlM7+sgACgkQMBKdi9lkZ6qlmAD+NGVQS56gt1Gu50bfFArARyFg kYKWTDMMDndWCC9fUPEA+wUSqAGIsMb2kkOsmZHr2pof8eKTsIgZrRegPUwDXLzC =4vRf -----END PGP SIGNATURE----- _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
za sebe muzu rict ze ani wedos ne. Naprosto nekompetentni a nefunkcni a lina podpora. Nepomuzou ti ani za boha. je to takova podpora DIY. Napriklad klient dostal 1h ban na IP pro prihlaseni k mailu (intrusion prevent) a trvalo jim 2,5 hodiny konstatovat ze zadnej problem neviej. A desitky podobnych kecu u nekolika klientu.
O.
Dne 2. dubna 2014 14:03 Vaclav Dusek Vaclav.Dusek@cz-pro.cz napsal(a):
U každého je něco, ale celý život je o kompromisech...
Hexageek určitě ne (viz Webtrh, nikdo vlastně neví co je zač), Best-Hosting také ne (výpadky), Wedos má pomalé disky - IO operace.
Pak už znám jen něco v zahraničí za vodou - USA/Kanada
Osobně si myslím, že z hlediska poměru cena/výkonpodpora v CZ je VPSFree dobré, ale i zde se něco najde ;)
Dne 2.4.2014 13:55, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/02/2014 01:45 PM, Vaclav Dusek wrote:
Záleží co hledáš,
- nejlevnější holé VPSky jsou u Wedos, nyní budou mít servery -
slušné fyzické stroje s dobrou podporou nabízí Tele3 http://www.tele3.cz/pronajem-serveru-tabulka.html - uděláš si konfiguraci dle přání. Nabízí i silnější fyzické stroje, individuální konfigurace - Coolhousing, slušné stroje - http://www.coolhousing.net/hewlett-packard-servery.html - http://www.superhosting.cz/dedikovane-servery - pěkné - OVH.cz - Kimusufi, http://www.kimsufi.com/cz/#servers - OVH.cz - So you start - http://www.soyoustart.com/cz/ silnější modely - Hetzner - použité stroje, zajímavá cena, http://www.hetzner.de/en/hosting/produkte_rootserver/serverboerse nebo nové stroje a dalo by se pokračovat...
Ne ze bych chtel pomlouvat, ale presne vsechny tyhle, co jsi vyjmenoval, neni vubec slozity sundat jenom UDP floodem. Neptej se jak to vim :)
/snajpa
Dne 2.4.2014 12:51, Pavel Muller napsal(a):
Nechci dělat vyloženě špatnou reklamu, ale pokud uvažuješ o komerečním poskytovateli, vyhýbej se na kilometr daleko hexageeku. Měli jsme tam servery a abych to shrnul - zpracování plateb řeší ručně, takže jsou s tím často problémy/prodlevy, při výpadku nekomunikují klidně i několik dní, technická podpora to samé...Když se podíváš na webtrh a přečteš si pár vláken o nich, uvidíš že nejsem sám :)
---------- Původní zpráva ---------- Od: Nikos Timiopulos nikos@manikstudio.cz Komu: vpsFree.cz Community list community-list@lists.vpsfree.cz Datum: 2. 4. 2014 12:16:24 Předmět: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
Díky za shrnutí, ve vlákně s DDoSem jsi zmínil, že jsi s některými musel řešit přechod jinam. Osobně nemám zkušenost s žádným komerčním poskytovatelem, tak se chci zeptat, koho můžete doporučit? Uvažuji o tom, že některé projekty, které mě při výpadku začínají trápit čím dál víc, přesunu jinam. So far jsem zabýval cloud hostingem přímo u Masteru, akorát je to hold kurva drahý. Pak mě zaujaly http://www.hexageek.cz/cze/pages/vps-virtual-private-server, ale nemám zkušenost.
Díky za rady a omlouvám se, pokud se to už někdy někde řešilo.
Dne 2. dubna 2014 11:58 Stanislav Petr <glux@glux.org mailto:glux@glux.org> napsal(a):
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).
Stanislav Petr Tel.: +420 602 620 026
-----Original Message----- From: community-list-bounces@lists.vpsfree.cz mailto:community-list-bounces@lists.vpsfree.cz [mailto: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 Subject: Re: [vpsFree.cz: community-list] Vypadky a problemy - checklist
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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
[mailto: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 mi 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", no 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlM7+sgACgkQMBKdi9lkZ6qlmAD+NGVQS56gt1Gu50bfFArARyFg kYKWTDMMDndWCC9fUPEA+wUSqAGIsMb2kkOsmZHr2pof8eKTsIgZrRegPUwDXLzC =4vRf -----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 http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
bacu＠centrum.cz -
Ján Stanček -
Michal Krajcirovic -
Nikos Timiopulos -
Ondrej Beranek -
Pavel Muller -
Pavel Snajdr -
Petr Tesařík -
Stanislav Petr -
Vaclav Dusek