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

Wed Apr 18 17:00:25 CEST 2018

Myslis jako "tuhle VPS mirroruj do druhy na nodu XY" nebo "Mam tady 4 nody, 
64GB RAM a 12 jader kazdej, udelej mi VPS s 200GB RAM a 36 jadry"? To prvni 
je zajimavej koncept a je resitelnej prave pres ty snapshoty (realne je to 
to, co v proxmoxu dela pvesr). To druhy na normalnich x86 moc nejde kvuli 
synchronizaci RAM mezi nody. Umej to superpocitace od IBM, ale to je jednak 
dost specialni hardware a druhak dost drahej. Ostatne to je duvod, proc to 
nenabizi ani aws ani jiny provideri, ale maj maximalni velikost VM (danou 
maximalni velikosti jednoho nodu).

Ondra Flidr

---------- Původní e-mail ----------
Od: zd nex <zdnexnet at gmail.com>
Komu: vpsFree.cz Community list <community-list at lists.vpsfree.cz>
Datum: 18. 4. 2018 16:12:10
Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz 
"
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:support at pripravto.cz) 
Mobil: +420 702 549 370
Web: www.pripravto.cz(http://www.pripravto.cz)

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(http://vpsfree.cz) 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(http://vpsfree.cz): community-list] Infrastruktura
vpsfree.cz(http://vpsfree.cz)

Ahoj Pavle, díky za odpověď.

Pro mě je záběr vpsfree.cz(http://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
(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/(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/(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/
(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(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
(http://vpsfree.cz)
[1] [1]
(https://kb.vpsfree.cz/informace/infrastruktura
(https://kb.vpsfree.cz/informace/infrastruktura) [6] [2]), můj
dotaz
jestli je popsaný stav aktuální?

Jsem u vpsfree.cz(http://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(http://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(http://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(http://vpsfree.cz) [1]
[2] https://kb.vpsfree.cz/informace/infrastruktura
(https://kb.vpsfree.cz/informace/infrastruktura) [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) [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) [7]
" 
 --

Ing. Pavel Hruška
http://www.mrpear.net(http://www.mrpear.net) [8]

mrpear at mrpear.net(mailto:mrpear at mrpear.net)

web, webdesign, web-aplikace:
http://www.pearfect.cz(http://www.pearfect.cz) [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) [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) [7]

Links:
------
[1] http://vpsfree.cz(http://vpsfree.cz)
[2] https://github.com/vpsfreecz/(https://github.com/vpsfreecz/)
[3] https://vpsadminos.org/(https://vpsadminos.org/)
[4] https://lists.vpsfree.cz/pipermail/outage-list/
(https://lists.vpsfree.cz/pipermail/outage-list/)
[5] https://opencamp.sk/o-konferencii(https://opencamp.sk/o-konferencii)
[6] https://kb.vpsfree.cz/informace/infrastruktura
(https://kb.vpsfree.cz/informace/infrastruktura)
[7] http://lists.vpsfree.cz/listinfo/community-list
(http://lists.vpsfree.cz/listinfo/community-list)
[8] http://www.mrpear.net/(http://www.mrpear.net/)
[9] http://www.pearfect.cz/(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)

"

""
_______________________________________________
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)

"

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