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

zd nex zdnexnet at gmail.com
Wed Apr 18 15:19:15 CEST 2018


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


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 Community list <community-list at lists.vpsfree.cz>
>>> Datum: 18. 4. 2018 10:45:27
>>> Předmět: Re: [vpsFree.cz: community-list] Infrastruktura
>>> vpsfree.cz
>>>
>>> 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 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/ [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 at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [7]
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [7]
>>>
>>
>>  --
>>
>> Ing. Pavel Hruška
>> http://www.mrpear.net [8]
>>
>> mrpear at mrpear.net
>>
>> web, webdesign, web-aplikace:
>> http://www.pearfect.cz [9]
>> _______________________________________________
>>  Community-list mailing list
>>  Community-list at lists.vpsfree.cz
>>  http://lists.vpsfree.cz/listinfo/community-list [7]
>>
>> _______________________________________________
>> Community-list mailing list
>> Community-list at 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/
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20180418/c7729fb8/attachment-0001.html>


More information about the Community-list mailing list