Hot standby je cela masina v OK stavu ready na nasunuti kontejneru,
idealne zapnuta a regnuta ve vpsAdminu.
V pripade totalni paniky se precvaknou disky, v pripade klidnejsiho
konce sveta je jenom migrujou VPSky za chodu.
/snajpa
On 2018-04-18 18:59, Pavel Hruška wrote:
> Hot-standby je mašina bez disků?
>
> Dne st 18. 4. 2018 18:36 uživatel Pavel Snajdr <snajpa@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@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@mrpear.net>
>>>> Komu: vpsFree.cz Community list
>> <community-list@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@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]
>>>> [1] [1]
>>>> (https://kb.vpsfree.cz/informace/infrastruktura [6] [6] [2]),
>> 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@lists.vpsfree.cz
>>>> http://lists.vpsfree.cz/listinfo/community-list [7] [7]
>>>> _______________________________________________
>>>> Community-list mailing list
>>>> Community-list@lists.vpsfree.cz
>>>> http://lists.vpsfree.cz/listinfo/community-list [7] [7]
>>>
>>> --
>>>
>>> Ing. Pavel Hruška
>>> http://www.mrpear.net [8] [8]
>>>
>>> mrpear@mrpear.net
>>>
>>> web, webdesign, web-aplikace:
>>> http://www.pearfect.cz [9] [9]
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list@lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [7] [7]
>>>
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list@lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [7] [7]
>>>
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list@lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [7] [7]
>>>
>>> --
>>>
>>> Ing. Pavel Hruška
>>> http://www.mrpear.net [8] [8]
>>>
>>> mrpear@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@lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [7]
>> _______________________________________________
>> Community-list mailing list
>> Community-list@lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [7]
>
>
> Links:
> ------
> [1] http://vpsfree.cz
> [2] https://github.com/vpsfreecz/
> [3] https://vpsadminos.org/
> [4] https://lists.vpsfree.cz/pipermail/outage-list/
> [5] https://opencamp.sk/o-konferencii
> [6] https://kb.vpsfree.cz/informace/infrastruktura
> [7] http://lists.vpsfree.cz/listinfo/community-list
> [8] http://www.mrpear.net
> [9] http://www.pearfect.cz
> [10] http://www.mrpear.net/
> [11] http://www.pearfect.cz/
>
> _______________________________________________
> 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