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

Pavel Hruška mrpear at mrpear.net
Thu Apr 19 10:43:35 CEST 2018 

Ahoj, ještě jednou bych chtěl poprosit jestli by mě přímo Tomáš nebo nněkdo
nenakopl správným směrem ohledně "snapshoty v ZFS + NTFS/EXT", tak jak psal
Tomáš (viz jak správně tedy nastavit mount pointy pro disk image a
synchronizaci zápisů). Rád bych si s tím pohrál.

Díky,
P.

Dne 18. dubna 2018 15:17 Tomas Srnka <tomas.srnka at gmail.com> napsal(a):

> Ahoj,
>
> snapshotov v ZFS + NTFS/EXT sa nemas preco bat ked mas spravne nastavene
> mount pointy pre disk image a synchronizaciou zapisov (existuje aj guest
> utilita, ktora riesi sync z guesta az po FS na diskovom poli, myslim, ze je
> prednaska na poslednom fosdeme o tom). Pouzivame tak NexentaStor polia
> (komercne ZFS riesenie) a par tisic KVM virtualok nad tym. Este druhu
> moznost mas pouzivat ZVOL nad ZFS + iSCSI, kde ti tento problem odpada.
> Jedine obmedzenie je potom pocet diskov, ktore tak vies vyexportovat.
>
> Ak chces distribuovane riesenie, odporucam jedine Nx 10GE + SSD only. V
> pripade ak je vsetko online je to OK, ale akonahle treba dopocitat data po
> zlyhani nodu, tak ide vykon "do kytek".  V ziadnom pripade by som nemiesal
> HDD a SSD pokial na to nie je extremne dobry dovod.
>
> Z mojej skusenosti pokial nemas 30+ nodov, tak sa stale oplati "centralne"
> pole (pomer cena/vykon/stabilita/zlozitost prevadzky a siete).
>
> Tomas
>
> 2018-04-18 15:08 GMT+02:00 Pavel Hruška <mrpear at mrpear.net>:
>
>> 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
>>>
>>
>>
>>
>> --
>> Ing. Pavel Hruška
>> http://www.mrpear.net
>> mrpear at mrpear.net
>>
>> web, webdesign, web-aplikace:
>> 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
>
>


-- 
Ing. Pavel Hruška
http://www.mrpear.net
mrpear at mrpear.net

web, webdesign, web-aplikace:
http://www.pearfect.cz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20180419/b8957088/attachment-0001.html>

More information about the Community-list mailing list