[vpsFree.cz: community-list] Infrastruktura vpsfree.cz
Petr Žitný
petr at zitny.net
Wed Apr 18 18:04:21 CEST 2018
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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto:Email%3Asupport at pripravto.cz>
> Mobil: +420 702 549 370
> Web: www.pripravto.cz <http://www.pripravto.cz> [1]
>
>
> Dne 18. dubna 2018 14:43 Pavel Snajdr <snajpa at snajpa.net
> <mailto: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
> <mailto:mrpear at mrpear.net>>
> Komu: vpsFree.cz [2] Community list
> <community-list at lists.vpsfree.cz
> <mailto: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 <http://vpsfree.cz> [3]
>
> Ahoj Pavle, díky za odpověď.
>
> Pro mě je záběr vpsfree.cz <http://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
> <mailto: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/
> <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
> <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
> <http://vpsfree.cz> [3]
> [1] [1]
> (https://kb.vpsfree.cz/informace/infrastruktura
> <https://kb.vpsfree.cz/informace/infrastruktura> [8] [6]
> [2]), můj
> dotaz
> jestli je popsaný stav aktuální?
>
> Jsem u vpsfree.cz <http://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 <http://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 <http://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
> <https://kb.vpsfree.cz/informace/infrastruktura> [8] [6]
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <http://lists.vpsfree.cz/listinfo/community-list> [9] [7]
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <http://lists.vpsfree.cz/listinfo/community-list> [9] [7]
>
> --
>
> Ing. Pavel Hruška
> http://www.mrpear.net [10] [8]
>
> mrpear at mrpear.net <mailto:mrpear at mrpear.net>
>
> web, webdesign, web-aplikace:
> http://www.pearfect.cz [11] [9]
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <http://lists.vpsfree.cz/listinfo/community-list> [9] [7]
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <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/
> <https://lists.vpsfree.cz/pipermail/outage-list/> [6]
> [5] https://opencamp.sk/o-konferencii
> <https://opencamp.sk/o-konferencii> [7]
> [6] https://kb.vpsfree.cz/informace/infrastruktura
> <https://kb.vpsfree.cz/informace/infrastruktura> [8]
> [7] http://lists.vpsfree.cz/listinfo/community-list
> <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
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <http://lists.vpsfree.cz/listinfo/community-list> [9]
>
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <http://lists.vpsfree.cz/listinfo/community-list> [9]
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <http://lists.vpsfree.cz/listinfo/community-list> [9]
>
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <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/
> <https://lists.vpsfree.cz/pipermail/outage-list/>
> [7] https://opencamp.sk/o-konferencii
> <https://opencamp.sk/o-konferencii>
> [8] https://kb.vpsfree.cz/informace/infrastruktura
> <https://kb.vpsfree.cz/informace/infrastruktura>
> [9] http://lists.vpsfree.cz/listinfo/community-list
> <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
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <http://lists.vpsfree.cz/listinfo/community-list>
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list
> <http://lists.vpsfree.cz/listinfo/community-list>
>
>
>
>
> --
> PhDr. Dominik Prochazka
> 00421 902 121 571
>
>
>
>
>
>
> _______________________________________________
> 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/86a49fd2/attachment-0001.html>
More information about the Community-list
mailing list