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

Wed Apr 18 15:18:57 CEST 2018

Ohledně SSD/SAS - záleží na tom, o kterou distribuovanou storage jde. 
Ceph určitě umí přiřadit různé disky do různých poolů a nody přitom 
nemusí být identické - stačí, když disky budou rozmístěné tak, aby bylo 
možné splnit požadavky na redundanci.

On 18.4.2018 15:08, Pavel Hruška wrote:
> Já se právě té replikace pomocí snapshotů trošku bojím, protože nad tím je
> jiný filesystém (NTFS) a můžou tam být problémy s konzistencí, která ve
> finále udělá víc problémů než užitku.
> 
> U lokálního storage jsem chtěl škálovat servery individuálně podle potřeby
> - třeba pro SQL bych dal SSD disky, do ostatních klasické SAS disky, teď
> ale nevím, jestli u distribuovaného storage toho můžu taky dosáhnout (aniž
> bych musel mít třeba 3 identické nody).
> 
> Protože si hraju s Proxmox VE, zkusím ještě Ceph, je to teď součást
> prostředí. Myslíš, že přes 10GbE je šance na reálný nasazení? Jediné místo
> "citlivé" na výkon je SQL databáze, relativně malá (desítky GB).
> 
> P.
> 
> Dne 18. dubna 2018 14:47 Pavel Snajdr <snajpa at snajpa.net> napsal(a):
> 
>> V praxi jsme zkouseli (v Relbitu, ne vpsFree) zalohovat InnoDB z MySQL
>> pomoci snapshotu ZFS;
>>
>> trochu problem je, kdyz nastane potreba obnovy *hned* a jenom nabeh te DB
>> ze snapshotu trva 45 minut kvuli InnoDB a jeho paranoie, ze by nemusel mit
>> neco ok :)
>>
>> (to byla DB s par tisicama tabulek, cca 3/4 TB).
>>
>> /snajpa
>>
>>
>> On 2018-04-18 13:12, Jirka Bourek wrote:
>>
>>> Tohle ale platí jenom pro vpsfree a kontejnery obecně, ne? Protože
>>> jinak ten ZFS filesystém těžko může vědět, jestli zrovna v daný
>>> okamžik byl konzistentní třeba ext4 nebo taky NTFS filesystém, co je v
>>> té virtuálce...
>>>
>>> On 18.4.2018 12:59, Ondrej.Flidr wrote:
>>>
>>>> To prave neni. Je to skutecne freeze filesystemu.
>>>>
>>>> ZFS pouziva tzv. copy-on-write pristup, kdy data neprepisuje, ale vlastne
>>>> pridava dalsi listy a vetve binarniho stromu. Kazdej vrchol toho stromu
>>>> ale
>>>> vi, kdy byl zmenen, takze ZFS je schopny danej filesystem vratit do
>>>> libovolnyho bodu v case (ono je to trochu slozitejsi, mota se do toho i
>>>> mergovani zmen aby FS zbytecne nebobtnal, ale principielne je to takhle).
>>>> Cili ty kdyz delas snapshot, tak reknes ZFS "vrat mi vsechny bloky
>>>> filesystemu ve stavu, v jakym byly k dnesnimu dni 12:54:12 SELC" a ZFS ti
>>>> vrati konzistentni obraz filesystemu. A dalsi sranda je, ze se da i rict
>>>> "mam obraz tvyho filesystemu k predvcerejsku, 20:58:19 SELC, updatni mi
>>>> ho k
>>>> dnesnimu 10:58:14" a on ti posle pouze diff zmen toho stromu. - ty updaty
>>>> jsou strasne rychly i kdyz mas petabytovej storage. Kdyz to mas pod tou
>>>> virtualkou, tak virtualka ani nevi, ze byla snapshotovana a netusi nic o
>>>> tom, ze nastartovala po vypnuti. Jeji filesystem je naprosto
>>>> konzistentni k
>>>> okamziku snapshotu. Kdyz nad tim mas nejakou SQL, tak ta se pak podiva do
>>>> binlogu, zjisti ze je pozadu za zbytkem clusteru a necha si poslat
>>>> updaty. A
>>>> vsechno je slunickovy a suprzeleny.
>>>>
>>>> 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 12:43:03
>>>> Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz
>>>> "
>>>> Tak předpokládám, že je to na úrovni "náhlého vypnutí stroje", se kterým
>>>> se
>>>> dnešní filesystémy už umí vypořádat...
>>>>
>>>>
>>>>
>>>> Dne 18. dubna 2018 12:36 Ondrej.Flidr <Ondrej.Flidr at seznam.cz
>>>> (mailto:Ondrej.Flidr at seznam.cz)> napsal(a):
>>>> "
>>>> Ty snapshoty prave resi ZFS.  Kdyz jako storage pro virtualy pouzijes
>>>> ZFS,
>>>> tak to neni problem, protoze ZFS snapshoty jsou atomicky - zamrazis celej
>>>> filesystem konzistentne. Jo, prijdes o data co jsou jenom v ram, ale to
>>>> nebejva tak moc.
>>>>
>>>> Ondra Flidr
>>>>
>>>> ---------- Původní e-mail ----------
>>>> Od: Pavel Hruška <mrpear at mrpear.net(mailto:mrpear at mrpear.net)>
>>>> Komu: vpsFree.cz Community list <community-list at lists.vpsfree.cz
>>>> (mailto:community-list at lists.vpsfree.cz)>
>>>> Datum: 18. 4. 2018 12:25:55
>>>>
>>>>
>>>> Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz
>>>> (http://vpsfree.cz)
>>>>
>>>>
>>>>
>>>>
>>>> "
>>>> Tak samozřejmě, že "5 minut výpadku je problém" do té doby, než řekneš,
>>>> kolik to stojí, aby teda ten výpadek nebyl, umocněno pravděpodobností,
>>>> že se
>>>> to fakt stane. To je běžná praxe kde se pohybuji, tedy menší a střední
>>>> firmy. A tím jedním dnem výpadku jsem opravdu myslel, že to "nepoloží
>>>> firmu", ale určitě jsem nemyslel "nemít problém". Cílem je ten výpadek co
>>>> nejvíc minimalizovat. A proto jsem rád za každou radu či názor.
>>>>
>>>>
>>>>
>>>> Víc storage na každý stroj sice potřebuju, nepotřebuju ale sdílený
>>>> storage,
>>>> který samo o sobě (mimo disků) taky něco stojí. Navíc se celkově
>>>> pohybuju v
>>>> pohodě, něco mezi 1-2 TB/node.
>>>>
>>>>
>>>>
>>>>
>>>> Migrace na druhou lokalitu není v plánu, je to poslední záchranej bod pro
>>>> data při totálním kolapsu (aka spadne mi sem letadlo) :o).
>>>>
>>>>
>>>>
>>>>
>>>> V praxi nevím, jak se bude chovat filesystém virtuálu, když bude mít
>>>> naběhnout ze "snapshotu". Přeci jen ten snapshot je dělanej za provozu.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> P.
>>>>
>>>>
>>>>
>>>>
>>>> Dne 18. dubna 2018 11:57 Ondrej.Flidr <Ondrej.Flidr at seznam.cz
>>>> (mailto:Ondrej.Flidr at seznam.cz)> napsal(a):
>>>> "
>>>> Hoj,
>>>> jo, hardware neumira. Ale HA nestavis za ucelem "co kdyz umre hardware"
>>>> ale
>>>> "nechci muset kazdou upravu delat ve tri rano, protoze chci tou dobou
>>>> bejt
>>>> na srot pod stolem nebo s holkou v posteli".
>>>>
>>>> Ja jsem holt zvyklej na situace, kdy 5 minut vypadku je problem :)
>>>> Samozrejme, pokud firmu nepolozi denni vypadek, tak jsi za vodou a proste
>>>> bych delal jenom zalohy a neresil. Virtualy na ZFS, kazdejch treba 30
>>>> minut
>>>> (podle velikosti okna, ktery si muzes/chces dovolit) zfs send na druhej
>>>> stroj a v pripade problemu nahodis klon.  Akorat to tvoje potrebuje
>>>> vyrazne
>>>> vic storage (vlastne na vsech serverech potrebujes misto pro vsechny
>>>> virtualy), coz muze byt docela drahy.
>>>>
>>>> S migraci na druhou lokalitu zacnes narazet na slozitosti s routovanim
>>>> (musis prehodit IP adresu => vlastni rozsah a reseni BGP).
>>>>
>>>> Ondra Flidr
>>>>
>>>> ---------- Původní e-mail ----------
>>>> Od: Pavel Hruška <mrpear at mrpear.net(mailto:mrpear at mrpear.net)>
>>>> Komu: vpsFree.cz Community list <community-list at lists.vpsfree.cz
>>>> (mailto:community-list at lists.vpsfree.cz)>
>>>> Datum: 18. 4. 2018 11:42:32
>>>>
>>>>
>>>> Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz
>>>> (http://vpsfree.cz)
>>>>
>>>>
>>>>
>>>>
>>>> "
>>>> Čauec, díky za objasnění. Já to trošku upřesním, trošku zmírním to, o co
>>>> mi
>>>> jde, protože úplně 100% HA nepotřebuju. Co si budeme povídat, firmu
>>>> nepoloží, když to nepojede hodinu, možná víc, nepoloží ji ani to, když to
>>>> nepojede den. Důležitý je nepřijít o data (resp. přijít o data co
>>>> nejmíň) a
>>>> dát to co nejdřív zase dohromady.
>>>>
>>>>
>>>>
>>>>
>>>> Dělat HA na úrovni aplikace taky není někdy sranda a hlavně to může vyjít
>>>> dráž (např. licence na SQL server), než HA na úrovni HW a virtualizace.
>>>> To
>>>> je třeba taky vzít v úvahu.
>>>>
>>>>
>>>>
>>>>
>>>> Přemýšlím nad možností replikace storage - tzn. 3 stroje v clusteru,
>>>> každý
>>>> má svoje virtuály a k nim storage. Storage se replikuje (rozdílově) v
>>>> určitých intervalech na zbylé stroje. Mohl bych teoreticky replikovat i
>>>> offsite na stroj v jiné lokalitě přes nějaký link (VPN). V případě
>>>> kolapsu
>>>> jednoho fyzického stroje by došlo k migraci jeho virtuálů na zbylé
>>>> stroje s
>>>> tím, že počítám s určitým oknem, ve kterém prostě můžu o něco přijít. Je
>>>> to
>>>> o definici toho, co jsem schopen tolerovat (a jestli tedy vůbec ano). K
>>>> tomu
>>>> samozřejmě podpora pomocí běžných záloh.
>>>>
>>>>
>>>>
>>>>
>>>> Vycházím z toho, že přeci jen ten HW zase tak moc neumírá a není to
>>>> otázka
>>>> běžné praxe. Ale chci s tím počítat.
>>>>
>>>>
>>>>
>>>>
>>>> Ještě jsem to takto nezkoušel, chystám si na to testlab, nevím jestli to
>>>> není úplně zcestné.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> P.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Dne 18. dubna 2018 11:06 Ondrej.Flidr <Ondrej.Flidr at seznam.cz
>>>> (mailto:Ondrej.Flidr at seznam.cz)> napsal(a):
>>>> "
>>>> 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 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: 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), 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/)
>>>>
>>>> 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/)
>>>>
>>>> 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/)
>>>>
>>>> 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)
>>>>
>>>> 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]
>>>> (https://kb.vpsfree.cz/informace/infrastruktura
>>>> (https://kb.vpsfree.cz/informace/infrastruktura) [2]), můj dotaz
>>>> jestli je popsaný stav aktuální?
>>>>
>>>>     Jsem u vpsfree.cz(http://vpsfree.cz) [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] 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] 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)
>>>> [2] https://kb.vpsfree.cz/informace/infrastruktura
>>>> (https://kb.vpsfree.cz/informace/infrastruktura)
>>>>
>>>> _______________________________________________
>>>> 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
>>>> _______________________________________________
>>>>
>>> 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
> 