Hot-standby je mašina bez disků?
Dne st 18. 4. 2018 18:36 uživatel Pavel Snajdr <snajpa(a)snajpa.net>
napsal:
On 2018-04-18 13:00, Pavel Hruška wrote:
Nad cluster storage jsem taky uvažoval, ale četl
jsem, že tam
"může" být problém s výkonem (i kdyby 10GbE, tak má sice
propustnost, ale problém může být latence a je třeba počkat
na
potvrzení od všech nodů v clusteru) - nevím, jen
jsem četl,
nezkoušel jsem.
Broadcom Trident II switch cipy, ktere budeme pouzivat, maji mit
nejakych 600ns port-to-port latenci, kdyz zapocitas, ze packet
pujde
(kdyz mezi racky) max pres 2 switche, udela to z NVMe disku vec s o
par
stovek mikrosekund vetsi latenci, dokud je volny bandwidth (a tam
zalezi
na zesilovacim efektu pri zapisu, tj. jak a kolika nodam se dava
vedet,
kdyz jedna noda neco pise do clusteru).
Pro zajímavost, řešili jste někdy takovou situaci, že by
klekl HW
celého node tak jak to tu diskutujeme?
Ojeje, jasne.
Nastesti jsme vzdycky meli nejaky volny hardware, i kdyz v Brne,
kdyz
byly problemy s node1.brq, to bylo zajimavejsi a downtime by byl
kratsi,
kdyby tam byla hot-standby masina, jak je to ted uz pravidelne v
Praze.
Nastesti Brno neni daleko od Bratislavy a Tomas dovezl nahradni
desku,
kterou jsme to vyresili docasne, nez prisla nova.
Celkove ty vypadky, kdyz se neco takovyho deje, jsou max tak na 2
hodky.
Jina vec je to s NASem, ten ale neni zdvojeny vicemene "by design",
protoze to je vec postavena z penez, co zbydou - a jeste nezbyly
penize
na zdvojeni - bo to mmj. i do budoucna zdvojnasobi naklad uz na
vzdycky,
co jednou nekomu slibime, uz brat zpatky tezko muzem, ze ;). To
vyresime
casem, nejdriv 2x10GE konektivitu per noda.
Hlavni je se nestrelit do nohy jak my s node4.brq, co je 350k CZK
lezicich jen tak; je to zatim jedna jedina NVMe noda a samozrejme
technologie kravi, takze namigrovane VPSky sly do par tydnu dolu.
Novy HW, jakoze novou konfiguraci, kupovat zasadne v dvojici a mit
kam
premigrovat z toho zdravyho nodu z nich...
Ted mi node4.brq lezi na stole v base48 a akorat si s nim hraju,
abych
zjistil, co je vlastne za problem.
(vlivem cca moji vlastni blbosti uz neni v zaruce a porad nevim, co
je
tam za problem, prinejhorsim pujde out na soucastky po jejich
validaci)
/snajpa
P.
Dne 18. dubna 2018 12:46 sorki <srk(a)48.io> napsal(a):
> Ahoj,
>
> data VPSiek su momentalne na nodach a je to vcelku nestastne
lebo
> ked umre hardware tak jedina moznost je
prehadzat disky do inej
> masiny aby sli VPSky aspon odmigrovat. Pohravali sme sa s
myslienkou
> stand-by node, do ktorych by prave sli disky
takto prehadzat,
> problem je vsak, ze niektore nody maju iny pocet diskov a po
novom
> sa nam do toho miesa este aj NVMe.
>
> Dalsia moznost by bola bezat nad clustrovym storageom (snajpa
> navrhoval skusit DRBD9), kde by v pripade vypadku hw mohli VPS
> nastartovat na inych nodach (storage zdielany cez vsetky nody v
> lokacii). Prave druhu moznost by som rad casom virtualizovane
> vyskusal, otazka je ako to bude fungovat so zfs.
>
> - srk
>
> On 04/18/2018 11:06 AM, Ondrej.Flidr wrote:
> Hoj,
> Co ti muzu rict ze svoji zkusenosti, tak data jsou na nodu, kde
> bezi virtual. Kdyz node slitne, virtual nejede. Delaly se nejaky
> experimenty s centralnim storage, ale bylo to nechutne pomaly
> (prakticky takhle vznikl NASbox). Ostatne to je problem vzdycky,
ono
> i 100Gbit linky jsou pomaly, kdyz pres to
tahas image stovek
> virtualu.
>
> Pokud chces mit jistotu, ze ti veci pojedou at se stane cokoliv,
> musis jit do klasickejch HA technik - balancing napric vic VPS,
> nesmej bejt na stejnym nodu (idealne pulka v Praze, pulka v
Brne,
> abys dokazal ustat i DDoS). Je to drahy ale
to je HA vzdycky.
>
> At tvuj stack a jak to udelat lip - vsechno musi byt min. 2x :)
> Pokud chces mit jistotu, ze to bude OK, musis to postavit
takhle:
>
> - min 3x vypocetni stroj
> - v kazdym 2x radic diskovyho pole
> - 2x SAS/FC switch
> - Z kazdyho serveru kabel do kazdyho SAS/FC switche
> - Z kazdyho SAS/FC switche kabely do kazdyho pole
> - V kazdym poli 2x radic, kazdej pripojenej do jednoho switche
> - Na obou polich totozny data
>
> Takhle budes mit jistotu, ze at uz umre cokoliv, porad bude
nejaka
> cesta jak se danej node dostane k datum.
Nicmene uprimne - na
tohle
> bych se vykaslal, delal storage primo na
serverech a mirror/HA
na
> urovni aplikaci ve virtualech. A proste
pocitat s tim, ze
hardware
> muze umrit, ale aplikaci je to jedno.
>
> Co se tyce site, tu pak res stejnym konceptem:
>
> - 2x switch
> - v kazdym serveru 2x sitovka, kazda 2 porty (1 muze byt
onboard)
> - Nakonfigurovany Bond-over-Bond - vzdycky 1
port z kazdy
sitovky
> do stejnyho switche, nad tim LACP bond a nad
temahle dvouma
bondama
> dalsi v rezimu active-passive (pokud nemas
switche co umej
stackovat
> a LACP pres ruzny zarizeni)
> - 2x router, kazdej vlastni uplink
> - kazdej switch pripojenej do obou routeru a mezi sebou. Je
potreba
> mit dobre nastaveny STP, aby jsi se nezabil
na smyckach
>
> Ondra Flidr
>
> ---------- Původní e-mail ----------
> Od: Pavel Hruška <mrpear(a)mrpear.net>
> Komu: vpsFree.cz Community list
<community-list(a)lists.vpsfree.cz>
> Datum: 18. 4. 2018 10:45:27
> Předmět: Re: [vpsFree.cz: community-list] Infrastruktura
> vpsfree.cz [1] [1]
>
> Ahoj Pavle, díky za odpověď.
>
> Pro mě je záběr vpsfree.cz [1] [1], resp. vpsadminos, tedy
to, že
> bych se hrabal ve zdrojácích na githubu,
trošku za hranou,
navíc
> pokud píšeš, že to není příliš friendly pro
lidi
neznalé "z
> venku" :). Jsem o "několik pater
jako admin výš" a některé
> věci nechávám raději jako black-box. Jinak virtualizuju
spíš
> Windows stroje přes KVM (tedy ne u vás, ale
tady na firmě).
>
> Nicméně rád bych věděl trošku víc jak máte z principu
> postavený celý systém - jestli chápu dobře, tak každý
node je
> samostatný, tzn. je včetně svého úložiště
(prostě když
> mám svůj virtuál na node14, data mám taky na něm)? NAS je
> samozřejmě po síti dostupný z každého node. Zajímá mě
co se
> děje při výpadku node: hostované virtály na
něm pak
nejedou?
> Chodí mi samozřejmě maily z outage listu, ale
když mi něco
> přijde a zkusím si svůj server, vždy to běží, tak nevím,
> jestli to chodí až po výpadku nebo jak přesně? Nebo je to
> úplně jinak? A pak samozřejmě jde o to, kdyby byl nějaký
> horší výpadek, třeba to, že se node celý sesype (hw
serveru,
> disky), co pak?
>
> Aktuálně mám virtualizovaný dva fyzický stroje, které
sdílí
> společné diskové pole, nepřijde mi to moc
šťastné,
protože
> při výpadku toho pole jsem....no asi víš kde.
Tak
přemýšlím,
> jak to vyřešit lépe.
>
> Na tom vašem HW mě překvapilo i to, že se v nodech
používají
> desktop-grade disky (WD black jsem tam
viděl), teda jestli jsem
to
> pochopil správně. A jaké máš dlouhodobě
zkušenosti s
> Supermicro servery, jsou ok? Četl jsem rozporuplné názory...
Já
> jedu na HP.
>
> V podstatě v tom prvním mailu jsem se ptal na to, jestli už
> třeba někde nevisí přednáška nebo něco, která by tohle
> popisovala. Nechci zbytečně otravovat ;).
>
> P.
>
> Dne 17. dubna 2018 16:27 Pavel Snajdr <snajpa(a)snajpa.net>
napsal(a):
> Cauko Pavle,
>
> v te tabulce chybi nove nody a celkove je dost zastarala;
nechtelo
> by se Ti na to napsat skript, ktery by ji
generoval? Nebo kdyz
ne
> tobe, nasel by se jiny dobrovolnik?
>
> Na vsechny nody mam SSH, skript bych poustel od sebe, jako
parametr
> by dostal hostnames a pak, kdyby idealne
vyplivnul Dokuwiki
tabulku
> s udaji per node:
>
> - typ desky (dmidecode)
> - nainstalovane procesory (dmidecode)
> - nainstalovana pamet (dmidecode)
> - nainstalovane disky (lsblk? smartctl -a /dev/sd* ?)
>
> Kdyby se to nekomu chtelo splacnout, budu velmi rad :)
>
> Jinak zdrojaky k tomu, co jedeme, jsou na Githubu:
>
>
https://github.com/vpsfreecz/ [2] [2]
>
> Aktualni reseni neni moc staveny na vic deploymentu, aby si to
> kazdy mohl nasadit u sebe - neni to moc dobre podokumentovane a
uz
> vubec se nepocita pri updatech s nekym
"neinformovanym".
>
> Tak jako tak, OpenVZ 6 doziva a stavime nastupnicky reseni nad
> upstream technologiemi:
>
>
https://vpsadminos.org/ [3] [3]
>
> Tohle uz si troufame mirit i pro ostatni k nasazeni, je to jeste
> dost dlouhy kus cesty, ale chceme se tam dostat.
>
> Aby si mohli treba kluci v Indii zalozit svoje vpsFree, protoze
pro
> nas se tam dostat je vcelku z fleku nerealny,
kdyz nezname
mistni
> pomery (a na slepo do nejakyho indickyho
datacentra jit, to je o
> nervy).
>
> Vypadky hlasime v outage-listu:
>
>
https://lists.vpsfree.cz/pipermail/outage-list/ [4] [4]
>
> Na konferencich nas muzes potkat uz nekolikaty rok, jezdime na
> InstallFest, LinuxDays, OpenAlt a cokoliv, co se zrovna povede v
> Bratislave - pristi vikend se muzem potkat prave na OpenCampu,
> sobota, FIT STU:
>
>
https://opencamp.sk/o-konferencii [5] [5]
>
> A jinak se urcite ptej dal, kdyztak dej prosim konkretnejsi
dotaz,
> akorat ;)
>
> /snajpa
>
> On 2018-04-17 15:15, Pavel Hruška wrote:
> Ahojte,
>
> četl jsem si ve znalostní bázi o infrastruktuře vpsfree.cz
[1]
můj
> dotaz
> jestli je popsaný stav aktuální?
>
> Jsem u vpsfree.cz [1] [1] [1] přes dva roky a řeším teď
> infrastrukturu
> ve firmě, tedy v menším měřítku (3 fyzické servery) a
také
> díky vpsfree.cz [1] [1] [1] se začínám
zajímat více o
> (opensource)
> linuxovou virtualizaci a především ZFS. Dozvědět se více o
> tom,
> jak funguje infrastruktura vpsfree.cz [1] [1] [1] by byla
skvělá
inspirace,
např. zkušenosti se servery, jak přesněji je řešeno
úložiště, co výpadky nodů (jestli jsou a jak se to
případně
řeší) atp. Nedá někde zjistit více, nebude nějaká
konference,
přednáška, ...?
Díky,
Pavel
Links:
------
[1]
http://vpsfree.cz [1] [1]
[2]
https://kb.vpsfree.cz/informace/infrastruktura [6] [6]
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list [7] [7]
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list [7] [7]
--
Ing. Pavel Hruška
http://www.mrpear.net [8] [8]
mrpear(a)mrpear.net
web, webdesign, web-aplikace:
http://www.pearfect.cz [9] [9]
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list [7] [7]
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list [7] [7]
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list [7] [7]
--
Ing. Pavel Hruška
http://www.mrpear.net [8] [8]
mrpear(a)mrpear.net
web, webdesign, web-aplikace:
http://www.pearfect.cz [9] [9]
Links:
------
[1]
http://vpsfree.cz [1]
[2]
https://github.com/vpsfreecz/ [2]
[3]
https://vpsadminos.org/ [3]
[4]
https://lists.vpsfree.cz/pipermail/outage-list/ [4]
[5]
https://opencamp.sk/o-konferencii [5]
[6]
https://kb.vpsfree.cz/informace/infrastruktura [6]
[7]
http://lists.vpsfree.cz/listinfo/community-list [7]
[8]
http://www.mrpear.net/ [10]
[9]
http://www.pearfect.cz/ [11]
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list [7]
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list [7]
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz