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]
>>
>> Ahoj Pavle, díky za odpověď.
>>
>> Pro mě je záběr vpsfree.cz [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]
>>
>> 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]
>>
>> 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]
>>
>> 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]
>>
>> 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]
>> (https://kb.vpsfree.cz/informace/infrastruktura [6] [2]), můj
>> dotaz
>> jestli je popsaný stav aktuální?
>>
>> Jsem u vpsfree.cz [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] 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] 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]
>> [2] https://kb.vpsfree.cz/informace/infrastruktura [6]
>>
>> _______________________________________________
>> 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]
>
> --
>
> Ing. Pavel Hruška
> http://www.mrpear.net [8]
>
> mrpear@mrpear.net
>
> web, webdesign, web-aplikace:
> http://www.pearfect.cz [9]
> _______________________________________________
> 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]
>
> _______________________________________________
> Community-list mailing list
> Community-list@lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list [7]
>
> --
>
> Ing. Pavel Hruška
> http://www.mrpear.net [8]
>
> mrpear@mrpear.net
>
> web, webdesign, web-aplikace:
> http://www.pearfect.cz [9]
>
> 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/
>
> _______________________________________________
> 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