[vpsFree.cz: community-list] Infrastruktura vpsfree.cz

Wed Apr 18 18:02:26 CEST 2018

tohle mne celkem zaujalo:

1. zalohovaci pole (co nejvic raw disku, zadne HW RAIDy)

proc zadne hw raidy?

2018-04-18 17:59 GMT+02:00 Pavel Snajdr <snajpa at snajpa.net>:

> Co myslis konkretne?
>
> Vlastni vpsAdminOS cluster? Jo. Presne tam je namireny, aby se co mame v
> produkci, dalo snadno replikovat.
>
> vpsAdminOS dostava prave integraci s vpsAdminem (proto to jmeno, zejo).
>
> Potom si budes moct deploynout svuj cluster sam.
>
> Do dvou nodu budes potrebovat strcit flashku, aby mely jak nabootovat, ty
> pak budou delat zaroven PXE prostredi pro zbytek clusteru.
>
> Cele by to melo byt self-hosting, tj. vystaci si to samo, ale krom serveru
> s lokalnim storage (kombo SSD+HDD nebo SSD only) potrebujes dve zasadni
> veci:
>
> 1. zalohovaci pole (co nejvic raw disku, zadne HW RAIDy)
> 2. BGP na switchich/BGP-schopnou-sit (kdyz ne na switchich, dva linuxove
> treba OpenWRT routery)
>
> Ohledne replikace dat, jak jsem psal, to budeme teprv resit, takze vetsi
> HAcka teprv prijdou.
>
> Na send/recv jsme se taky vykaslali, protoze pokud nejste Nexenta a nemate
> zamestnanych par skilled ZFS developeru, dost to drhne.
>
> /snajpa
>
>
> On 2018-04-18 16:10, zd nex wrote:
>
>> Jasně chápu ;)
>>
>> Prostě mě to zajímalo. Btw půjde v budoucnu nějakým způsobem
>> postavit VPS nad více nody?
>>
>> Dne 18. dubna 2018 15:53 Pavel Snajdr <snajpa at snajpa.net> napsal(a):
>>
>> My chceme mit primy dosah na technologie, co bezime.
>>>
>>> Ty statisice radku Pythonu, Go, Ruby a ceho ja vim jeste mame uz
>>> nejakou chvili napsane po svem, na zlomek radku kodu. Mame to primo
>>> zaintegrovane tak, jak podkladove technologie, vetsinou psane v
>>> Ccku, pouzivame. Hadej, co bylo driv, vpsFree servery v produkci
>>> nebo vubec nejaky prvni release OpenStacku? ;)
>>>
>>> Uz s tim delame prilis dlouho, abychom se chteli vztekat, ze danou
>>> vec chce projekt X delat po svem a upstream patch pro zmenu chovani
>>> nechce prijmout...
>>>
>>> Ja si myslim, ze vyvoj vlastniho reseni je v podstate od zacatku az
>>> do ted cca podminkou pro to, abychom mohli mit takovyhle setup s
>>> kontejnery ‘jako plne VM’, v takove hustote and all.
>>>
>>> /snajpa
>>>
>>> On 18 Apr 2018, at 15:19, zd nex <zdnexnet at gmail.com> wrote:
>>>
>>> Když už je řeč např. Ceph > nevyplatí se i vyzkoušet
>>> například OpenStack či podobné technologie, které slučují HW
>>> dohromady pod jednu nastavitelnou platformu pro jednodušší
>>> škálování? Nebo se o toto bude snažit právě nové LXC?
>>>
>>> --
>>> S pozdravem,
>>>
>>> Zdeněk Dlauhý
>>>
>>> Email:support at pripravto.cz
>>> Mobil: +420 702 549 370
>>> Web: www.pripravto.cz [1]
>>>
>>>
>>> Dne 18. dubna 2018 14:43 Pavel Snajdr <snajpa at snajpa.net> napsal(a):
>>> Ja bych ani nerekl, ze je to nestastny. Je to, jak to je - lokalni
>>> storage je v podstate jedina mozna produkcni varianta, jak jsme to
>>> vubec mohli mit.
>>>
>>> Kdo u nas uz je dost dlouho, mozna pamatujete na rackovou akci -
>>> kdy jsme chteli prejit do racku a pro virtualy prave udelat shared
>>> storage s tim, ze bychom ho pak pres treba prave DRBD mirrorovali na
>>> druhe pole.
>>>
>>> Narazili jsme na to, ze neexistoval (a stale ee) rozumny zpusob,
>>> jak vysdilet s nizkou latenci a rozumnym cachovanim (sta-)miliony
>>> malinkych souboru.
>>>
>>> NFSv3 ma omezeni na 16 secondary group, do kterych muze user patrit
>>> a neumi ACLka a dalsi veci.
>>>
>>> NFSv4 se neda dokopat k raw uid/gid, co pro kontejnery taky
>>> potrebujem, protoze host nevidi (nemelo by ho to vubec zajimat),
>>> jake UID/GID ma jak pouzite kontejner. Tedy, tak to bylo s OpenVZ 6;
>>> s user namespace pri upstream kernelu uz NFSv4 pravdepodobne nejak
>>> nahackovat pujde, ale ruku do ohne za takovy reseni nedam...
>>>
>>> Taky jsme meli slabou sit (2xGE) a celkove si myslim, ze i
>>> kdybychom to postavili, asi bychom tim zabili sami sebe a s tim chut
>>> vpsFree nejak dal rozsirovat. Jsem si celkem jisty, ze pouzitelnost
>>> reseni v prepoctu na jednu koncovou VPSku by byla v kopru, s
>>> dostupnosti ve finale horsi, nez s lokalnim ulozistem.
>>>
>>> Lokalni storage proste skaluje nejvic. Vi to vsichni a vsude, kde
>>> se virtualizuje kus vic - ve verejnych Internetovych datacentrech se
>>> jede scale-out, centralni prvky neskaluji. V korporatnich je to neco
>>> jinyho, kdyz si firma muze dovolit (a chce mit) proprietarni reseni,
>>> da se.
>>>
>>> Nad OpenVZ jadrem se toho moc vymyslet nedalo, no.
>>>
>>> S upstream kernelem mame najednou jinaci moznosti - a s dostupnosti
>>> 10Gbit sitovani za rozumne ceny (z druhe ruky) se uz da premyslet o
>>> nejakem rozumnejsim clusterovani, jako treba Ceph, nebo DRBD9.
>>>
>>> Kdyz neni sit limitujicim faktorem, na kterem by se to kuckalo,
>>> pojede to zase jinak.
>>>
>>> Ale myslim si, ze zadna velka migrace na clustered storage nebude,
>>> ze pojedeme obe reseni najednou.
>>>
>>> Na lokalnich discich budou jak VPSky, tak blockstore pro nejaky
>>> distributed storage (a VPSky nad nim) - a kazdy bude mit na vyber,
>>> jak chce mit data ulozena (protoze to mmj. znamena taky jinou rezii
>>> na ulozeny GB, kdyz to promitnem na raw diskovy prostor).
>>>
>>> Tohle budeme zavadet postupne, prvni metou je dostat se na upstream
>>> kernel. A jestli to bude Ceph, DRBD9, nebo iSCSI ciste s Declustered
>>> RAID driverem v ZFS, nebo co presne, to jeste jasne vubec neni, to
>>> bude zalezet, jak se to v praxi bude chovat nad nasim konkretnim
>>> poctem serveru (a vyhledy do budoucna), pro nas use-case.
>>>
>>> /snajpa
>>>
>>> On 2018-04-18 12:46, sorki wrote:
>>>
>>> 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 at mrpear.net>
>>> Komu: vpsFree.cz [2] Community list
>>> <community-list at lists.vpsfree.cz>
>>> Datum: 18. 4. 2018 10:45:27
>>> Předmět: Re: [vpsFree.cz [2]: community-list] Infrastruktura
>>> vpsfree.cz [3]
>>>
>>> Ahoj Pavle, díky za odpověď.
>>>
>>> Pro mě je záběr vpsfree.cz [3] [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 at 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/ [4] [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/ [5] [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/ [6] [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 [7] [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 [3]
>>> [1] [1]
>>> (https://kb.vpsfree.cz/informace/infrastruktura [8] [6] [2]), můj
>>> dotaz
>>> jestli je popsaný stav aktuální?
>>>
>>> Jsem u vpsfree.cz [3] [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 [3] [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 [3] [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 [3] [1]
>>> [2] https://kb.vpsfree.cz/informace/infrastruktura [8] [6]
>>>
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [9] [7]
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [9] [7]
>>>
>>> --
>>>
>>> Ing. Pavel Hruška
>>> http://www.mrpear.net [10] [8]
>>>
>>> mrpear at mrpear.net
>>>
>>> web, webdesign, web-aplikace:
>>> http://www.pearfect.cz [11] [9]
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [9] [7]
>>>
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [9] [7]
>>>
>>> Links:
>>> ------
>>> [1] http://vpsfree.cz [3]
>>> [2] https://github.com/vpsfreecz/ [4]
>>> [3] https://vpsadminos.org/ [5]
>>> [4] https://lists.vpsfree.cz/pipermail/outage-list/ [6]
>>> [5] https://opencamp.sk/o-konferencii [7]
>>> [6] https://kb.vpsfree.cz/informace/infrastruktura [8]
>>> [7] http://lists.vpsfree.cz/listinfo/community-list [9]
>>> [8] http://www.mrpear.net/ [12]
>>> [9] http://www.pearfect.cz/ [13]
>>>
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [9]
>>>
>>
>>  _______________________________________________
>>  Community-list mailing list
>>  Community-list at lists.vpsfree.cz
>>  http://lists.vpsfree.cz/listinfo/community-list [9]
>>
>> _______________________________________________
>>> Community-list mailing list
>>> Community-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [9]
>>>
>>
>> _______________________________________________
>>  Community-list mailing list
>>  Community-list at lists.vpsfree.cz
>>  http://lists.vpsfree.cz/listinfo/community-list [9]
>>
>>
>>
>> Links:
>> ------
>> [1] http://www.pripravto.cz
>> [2] http://vpsFree.cz
>> [3] http://vpsfree.cz
>> [4] https://github.com/vpsfreecz/
>> [5] https://vpsadminos.org/
>> [6] https://lists.vpsfree.cz/pipermail/outage-list/
>> [7] https://opencamp.sk/o-konferencii
>> [8] https://kb.vpsfree.cz/informace/infrastruktura
>> [9] http://lists.vpsfree.cz/listinfo/community-list
>> [10] http://www.mrpear.net
>> [11] http://www.pearfect.cz
>> [12] http://www.mrpear.net/
>> [13] http://www.pearfect.cz/
>>
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
>>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>

-- 
PhDr. Dominik Prochazka
00421 902 121 571
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20180418/6edae85e/attachment-0001.html>