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

Pavel Snajdr snajpa at snajpa.net
Wed Apr 18 18:16:16 CEST 2018 

Protoze, najednou:

1. snapshot+send je operace, kterou vynutis txg sync (=> rozdelane 
asynchronni zapisy
2. protoze 1. to odesilaci kolecko trva desitky sekund u par datasetu, 
jednotky minut pro celou nodu
3. po celou dobu toho kolecka jsou disky zabity zapisama, txg buffer je 
tak akorat na paradu
4. nejenom to, ale disky jsou taky zamestnany ctenim ty delty, ktera se 
posila, protoze uz dost z toho ani nemusi byt v ARC (RAM)

Takze ciste SSD-only reseni a no a chce to trochu lepsi SSDcka, aby neco 
vydrzely.

/snajpa

On 2018-04-18 18:04, Petr Žitný wrote:
> Urcite protoze Raidz, ale me by spis zajimalo proc ne to zfs
> send/recv... :-)
> 
>  Dne 18.4.2018 v 18:02 Dominik Prochazka napsal(a):
> 
>> 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] [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 [2] [3]
>> 
>> Ahoj Pavle, díky za odpověď.
>> 
>> Pro mě je záběr vpsfree.cz [2] [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/ [3] [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/ [4] [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/ [5] [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 [6] [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 [2]
>> [3]
>> [1] [1]
>> (https://kb.vpsfree.cz/informace/infrastruktura [7] [8] [6] [2]),
>> můj
>> dotaz
>> jestli je popsaný stav aktuální?
>> 
>> Jsem u vpsfree.cz [2] [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 [2] [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 [2] [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 [2] [3] [1]
>> [2] https://kb.vpsfree.cz/informace/infrastruktura [7] [8] [6]
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8] [9] [7]
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8] [9] [7]
>> 
>> --
>> 
>> Ing. Pavel Hruška
>> http://www.mrpear.net [9] [10] [8]
>> 
>> mrpear at mrpear.net
>> 
>> web, webdesign, web-aplikace:
>> http://www.pearfect.cz [10] [11] [9]
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8] [9] [7]
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8] [9] [7]
>> 
>> Links:
>> ------
>> [1] http://vpsfree.cz [2] [3]
>> [2] https://github.com/vpsfreecz/ [3] [4]
>> [3] https://vpsadminos.org/ [4] [5]
>> [4] https://lists.vpsfree.cz/pipermail/outage-list/ [5] [6]
>> [5] https://opencamp.sk/o-konferencii [6] [7]
>> [6] https://kb.vpsfree.cz/informace/infrastruktura [7] [8]
>> [7] http://lists.vpsfree.cz/listinfo/community-list [8] [9]
>> [8] http://www.mrpear.net/ [11] [12]
>> [9] http://www.pearfect.cz/ [12] [13]
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8] [9]
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8] [9]
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8] [9]
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8] [9]
>> 
>> Links:
>> ------
>> [1] http://www.pripravto.cz [1]
>> [2] http://vpsFree.cz [13]
>> [3] http://vpsfree.cz [2]
>> [4] https://github.com/vpsfreecz/ [3]
>> [5] https://vpsadminos.org/ [4]
>> [6] https://lists.vpsfree.cz/pipermail/outage-list/ [5]
>> [7] https://opencamp.sk/o-konferencii [6]
>> [8] https://kb.vpsfree.cz/informace/infrastruktura [7]
>> [9] http://lists.vpsfree.cz/listinfo/community-list [8]
>> [10] http://www.mrpear.net [9]
>> [11] http://www.pearfect.cz [10]
>> [12] http://www.mrpear.net/ [11]
>> [13] http://www.pearfect.cz/ [12]
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list [8]
> 
>  _______________________________________________
>  Community-list mailing list
>  Community-list at lists.vpsfree.cz
>  http://lists.vpsfree.cz/listinfo/community-list [8]
> 
>  --
> 
> PhDr. Dominik Prochazka
>  00421 902 121 571
> 
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list [8]
> 
> 
> 
> Links:
> ------
> [1] http://www.pripravto.cz
> [2] http://vpsfree.cz
> [3] https://github.com/vpsfreecz/
> [4] https://vpsadminos.org/
> [5] https://lists.vpsfree.cz/pipermail/outage-list/
> [6] https://opencamp.sk/o-konferencii
> [7] https://kb.vpsfree.cz/informace/infrastruktura
> [8] http://lists.vpsfree.cz/listinfo/community-list
> [9] http://www.mrpear.net
> [10] http://www.pearfect.cz
> [11] http://www.mrpear.net/
> [12] http://www.pearfect.cz/
> [13] http://vpsFree.cz
> 
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list

More information about the Community-list mailing list