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

Wed Apr 18 16:10:19 CEST 2018

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