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

Pavel Snajdr snajpa at snajpa.net
Wed Apr 18 15:53:54 CEST 2018 

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
> 
> 
> 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
> 
> _______________________________________________
> 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/f27b358c/attachment-0001.html>

More information about the Community-list mailing list