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