On 2018-04-17 17:23, Pavel Vondřička wrote:

Na netu se taky dají najít Snajpovy dost zajímavý přednášky z akcí typu LinuxDays, InstallFest apod., třeba o SSD, ZFS nebo OpenVZ. Bohužel se věci rychle mění, takže to už není všechno zrovna aktuální (zvlášť když je to už třeba pár let starý).

Pro nás je to taky nedocenitelný zdroj informací a know-how, protože nejsme komerční firma a vlastní HW mini-infrastrukturu si musíme v pár lidech budovat a udržovat sami jako vedlejší bokovku k tomu, že na ní provozujeme a vyvíjíme akademický služby. Takže bych taky ocenil nějaký průběžně aktualizovaný zdroj informací a zkušeností, ale je mi jasný, že vytvářet dokumentaci je přinejmenším stejná, ne-li ještě větší práce než vyvíjet tu infrastrukturu. :-)

Tak pokud mas chut - na IRCcku mame vcelku dost aktivity, je tam takovy aktivni jadro, co se tyce technologii. Tam je vlastne to, co nepiseme do ML. #vpsfree na irc.freenode.net; tam resime vetsinu veci - a najdes tam i dalsi kamarady z cz/sk "produkcni komunity", s kym si radime, jak treba udelat sitovani a podobne (yanek) nebo jak se k cemu stavi v Seznamu (Ashlee a sasaniak), jirutka je borec s kym mluvit ohledne Alpine, dalsi lidi z hackerspacu, atd., atd. - to se ani neda vyjmenovat vsechny ;) #vpsadminos je pak relevantni pro resenice ohledne vpsAdminOS/vpsAdminu; no a dalsi kanaly ohledne vpsFree a primo souvisejicich veci budou pribejvat, jak budou potreba; ja osobne jeste visim na #base48, #brmlab, #zfsonlinux, #nixos, #lxcontainers, #openvz jako stalym minimu - a skoro kazdy opensource soft, co pouzivate, ma vyvojare nedaleko. Pokud chybi penize, ale mate lidi cas, je tu komunita, pokud o tom nevite, pripojte se, unika vam to jinak ;) /snajpa

Pavel

...

17. 4. 2018 v 16:27, Pavel Snajdr <snajpa@snajpa.net>:

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/

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/

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/

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

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 [1] (https://kb.vpsfree.cz/informace/infrastruktura [2]), můj dotaz jestli je popsaný stav aktuální? Jsem u 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 [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 [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] https://kb.vpsfree.cz/informace/infrastruktura _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

---

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

Ahoj Pavle, díky za odpověď. Pro mě je záběr 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@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/

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/

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/

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

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

Jsem u 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 [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 [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] https://kb.vpsfree.cz/informace/infrastruktura

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

Ahoj Pavle, díky za odpověď.

Pro mě je záběr 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@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/

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/

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/

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

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

Jsem u 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 [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 [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] https://kb.vpsfree.cz/informace/infrastruktura

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 11:42:32

Předmět: Re: [vpsFree.cz: community-list] Infrastruktura 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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

Ahoj Pavle, díky za odpověď.

Pro mě je záběr 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@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/

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/

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/

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

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

Jsem u 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 [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 [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] https://kb.vpsfree.cz/informace/infrastruktura

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.cz

Teď tomu úplně nerozumím, co znamená to "připojit se do té virtuálky", navíc ta virtulka je Windows stroj, není fsfreeze otázka jen Linuxu? P. Dne 18. dubna 2018 12:25 Jirka Bourek <vpsfree-list@keroub.cz> napsal(a):

Pokud se do té virtuálky jde připojit před pořízením toho snapshotu, dá se použít fsfreeze - filesystém v tom snapshotu by pak měl být konzistentní (což ale samozřejmě ještě neznamená, že budou konzistentní i např. data v databázích)

On 18.4.2018 12:22, Pavel Hruška wrote:

...

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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 11:42:32

Předmět: Re: [vpsFree.cz: community-list] Infrastruktura 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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

Ahoj Pavle, díky za odpověď.

Pro mě je záběr 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@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/

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/

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/

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

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

Jsem u 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 [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 [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] https://kb.vpsfree.cz/informace/infrastruktura

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.cz

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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 12:25:55 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura 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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " -- Ing. Pavel Hruška http://www.mrpear.net(http://www.mrpear.net/) mrpear@mrpear.net(mailto:mrpear@mrpear.net) web, webdesign, web-aplikace: http://www.pearfect.cz(http://www.pearfect.cz/) _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " -- Ing. Pavel Hruška http://www.mrpear.net(http://www.mrpear.net/) mrpear@mrpear.net(mailto:mrpear@mrpear.net) web, webdesign, web-aplikace: http://www.pearfect.cz(http://www.pearfect.cz/) _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " -- Ing. Pavel Hruška http://www.mrpear.net(http://www.mrpear.net/) mrpear@mrpear.net(mailto:mrpear@mrpear.net) web, webdesign, web-aplikace: http://www.pearfect.cz(http://www.pearfect.cz/) _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list "

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@mrpear.net> Komu: vpsFree.cz Community list <community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " -- Ing. Pavel Hruška http://www.mrpear.net(http://www.mrpear.net/) mrpear@mrpear.net(mailto:mrpear@mrpear.net) web, webdesign, web-aplikace: http://www.pearfect.cz(http://www.pearfect.cz/) _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " -- Ing. Pavel Hruška http://www.mrpear.net(http://www.mrpear.net/) mrpear@mrpear.net(mailto:mrpear@mrpear.net) web, webdesign, web-aplikace: http://www.pearfect.cz(http://www.pearfect.cz/) _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " -- Ing. Pavel Hruška http://www.mrpear.net(http://www.mrpear.net/) mrpear@mrpear.net(mailto:mrpear@mrpear.net) web, webdesign, web-aplikace: http://www.pearfect.cz(http://www.pearfect.cz/) _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " -- Ing. Pavel Hruška http://www.mrpear.net(http://www.mrpear.net/) mrpear@mrpear.net(mailto:mrpear@mrpear.net) web, webdesign, web-aplikace: http://www.pearfect.cz(http://www.pearfect.cz/) _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list "

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@mrpear.net> Komu: vpsFree.cz Community list <community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) "

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) "

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.cz

A můžu se zeptat, co přesně je to "funguje to celkem OK", hlavně co znamená to "celkem" :-)? Díky. Dne 18. dubna 2018 15:15 Ondrej.Flidr <Ondrej.Flidr@seznam.cz> napsal(a):

V proxmoxu mas od v5 ZFS snapshoty a synchronizaci virtualu pro hot standby primo zabudovanou, funguje to celkem OK.

Ad sit - pokud budes mit vyhrazenou sit pro storage (jako vyhrazenou fyzicky) tak to muze bejt OK. Pokud nebude fyzicky vyhrazena, prvni DDoS ti sejme celou platformu.

Ondra Flidr

---------- Původní e-mail ---------- Od: Pavel Hruška <mrpear@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 15:09:18

Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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/) <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/) <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) <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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) "

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.cz

Replikaci na víc cílů to umí, ne? Viz.: "Every guest can be replicated to multiple target nodes, but a guest cannot get replicated twice to the same target node" Tedy jestli se bavíme o tom samém: https://pve.proxmox.com/wiki/Storage_Replication P. Dne 18. dubna 2018 15:43 Ondrej.Flidr <Ondrej.Flidr@seznam.cz> napsal(a):

To znamena ze samotna replikace mezi dvouma nodama funguje. Co nefunguje, to je nejaky davkovy vypinani/zapinani jobu (pres pvesr), replikace na vic cilu apod.

Plus samozrejme funguje to pouze ZFS-to-ZFS.

Ondra Flidr

---------- Původní e-mail ---------- Od: Pavel Hruška <mrpear@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 15:36:04

Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

A můžu se zeptat, co přesně je to "funguje to celkem OK", hlavně co znamená to "celkem" :-)?

Díky.

Dne 18. dubna 2018 15:15 Ondrej.Flidr <Ondrej.Flidr@seznam.cz> napsal(a):

V proxmoxu mas od v5 ZFS snapshoty a synchronizaci virtualu pro hot standby primo zabudovanou, funguje to celkem OK.

Ad sit - pokud budes mit vyhrazenou sit pro storage (jako vyhrazenou fyzicky) tak to muze bejt OK. Pokud nebude fyzicky vyhrazena, prvni DDoS ti sejme celou platformu.

Ondra Flidr

---------- Původní e-mail ---------- Od: Pavel Hruška <mrpear@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 15:09:18

Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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/) <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/) <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) <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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) "

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.cz

OK, pohraju si s tím. Dne 18. dubna 2018 15:51 Ondrej.Flidr <Ondrej.Flidr@seznam.cz> napsal(a):

Myslel jsem v ramci jednoho jobu. Nebo minimalne kdyz jsem si s tim hral tak to v ramci jednoho jobu neumeli.

Ondra Flidr

---------- Původní e-mail ---------- Od: Pavel Hruška <mrpear@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 15:48:57

Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

Replikaci na víc cílů to umí, ne? Viz.: "Every guest can be replicated to multiple target nodes, but a guest cannot get replicated twice to the same target node"

Tedy jestli se bavíme o tom samém:

https://pve.proxmox.com/wiki/Storage_Replication

P.

Dne 18. dubna 2018 15:43 Ondrej.Flidr <Ondrej.Flidr@seznam.cz> napsal(a):

To znamena ze samotna replikace mezi dvouma nodama funguje. Co nefunguje, to je nejaky davkovy vypinani/zapinani jobu (pres pvesr), replikace na vic cilu apod.

Plus samozrejme funguje to pouze ZFS-to-ZFS.

Ondra Flidr

---------- Původní e-mail ---------- Od: Pavel Hruška <mrpear@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 15:36:04

Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

A můžu se zeptat, co přesně je to "funguje to celkem OK", hlavně co znamená to "celkem" :-)?

Díky.

Dne 18. dubna 2018 15:15 Ondrej.Flidr <Ondrej.Flidr@seznam.cz> napsal(a):

V proxmoxu mas od v5 ZFS snapshoty a synchronizaci virtualu pro hot standby primo zabudovanou, funguje to celkem OK.

Ad sit - pokud budes mit vyhrazenou sit pro storage (jako vyhrazenou fyzicky) tak to muze bejt OK. Pokud nebude fyzicky vyhrazena, prvni DDoS ti sejme celou platformu.

Ondra Flidr

---------- Původní e-mail ---------- Od: Pavel Hruška <mrpear@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 15:09:18

Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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/) <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/) <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) <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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) "

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.cz

Centrální pole OK do doby, než mi zdechne. Musím na něj držet podporu, abych měl jistotu, že se mému problému bude někdo věnovat, cena takové podpory garantující rozumnou dobu řešení, je úplně extrémní a myslím, že levněji vyjde mít ta pole dvě. Když mi zdechne server, je to přeci jen víc obecnější kus hardware, můžu jej nahradit "relativně čímkoliv" jiným. Na sdílené poje jedu teď, mám nad tím HA a jo, pokud to jede (jako že zatím jo), je to pohodička. Moje myšlenka je zbavit se centrálního prvku, který mi může shodit úplně všechno. To s tím mixem SSD/HDD v distr řešení beru, myslel jsem si to. Mohl bych poprosit o víc rozepsání té první myšlenky ohledně spapshotů ZFS+NTFS? Abych se mohl chytnout toho jak to správně rozjet a na co si dát pozor. Mě se totiž tahle cesta pořád líbí nejvíc... Díky, Dne 18. dubna 2018 15:17 Tomas Srnka <tomas.srnka@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@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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz ) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz ) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) "

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.cz

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@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@seznam.cz (mailto:Ondrej.Flidr@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz (mailto:community-list@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@snajpa.net (mailto:snajpa@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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) "

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

Nad cluster storage jsem taky uvažoval, ale četl jsem, že tam "může" být problém s výkonem (i kdyby 10GbE, tak má sice propustnost, ale problém může být latence a je třeba počkat na potvrzení od všech nodů v clusteru) - nevím, jen jsem četl, nezkoušel jsem. Pro zajímavost, řešili jste někdy takovou situaci, že by klekl HW celého node tak jak to tu diskutujeme? P. Dne 18. dubna 2018 12:46 sorki <srk@48.io> napsal(a):

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@mrpear.net> <mrpear@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

Ahoj Pavle, díky za odpověď.

Pro mě je záběr 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@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/

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/

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/

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

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

Jsem u 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 [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 [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] https://kb.vpsfree.cz/informace/infrastruktura

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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

web, webdesign, web-aplikace: http://www.pearfect.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing listCommunity-list@lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- Ing. Pavel Hruška http://www.mrpear.net mrpear@mrpear.net web, webdesign, web-aplikace: http://www.pearfect.cz

On 2018-04-18 13:00, Pavel Hruška wrote:

Nad cluster storage jsem taky uvažoval, ale četl jsem, že tam "může" být problém s výkonem (i kdyby 10GbE, tak má sice propustnost, ale problém může být latence a je třeba počkat na potvrzení od všech nodů v clusteru) - nevím, jen jsem četl, nezkoušel jsem.

Broadcom Trident II switch cipy, ktere budeme pouzivat, maji mit nejakych 600ns port-to-port latenci, kdyz zapocitas, ze packet pujde (kdyz mezi racky) max pres 2 switche, udela to z NVMe disku vec s o par stovek mikrosekund vetsi latenci, dokud je volny bandwidth (a tam zalezi na zesilovacim efektu pri zapisu, tj. jak a kolika nodam se dava vedet, kdyz jedna noda neco pise do clusteru).

Pro zajímavost, řešili jste někdy takovou situaci, že by klekl HW celého node tak jak to tu diskutujeme?

Ojeje, jasne. Nastesti jsme vzdycky meli nejaky volny hardware, i kdyz v Brne, kdyz byly problemy s node1.brq, to bylo zajimavejsi a downtime by byl kratsi, kdyby tam byla hot-standby masina, jak je to ted uz pravidelne v Praze. Nastesti Brno neni daleko od Bratislavy a Tomas dovezl nahradni desku, kterou jsme to vyresili docasne, nez prisla nova. Celkove ty vypadky, kdyz se neco takovyho deje, jsou max tak na 2 hodky. Jina vec je to s NASem, ten ale neni zdvojeny vicemene "by design", protoze to je vec postavena z penez, co zbydou - a jeste nezbyly penize na zdvojeni - bo to mmj. i do budoucna zdvojnasobi naklad uz na vzdycky, co jednou nekomu slibime, uz brat zpatky tezko muzem, ze ;). To vyresime casem, nejdriv 2x10GE konektivitu per noda. Hlavni je se nestrelit do nohy jak my s node4.brq, co je 350k CZK lezicich jen tak; je to zatim jedna jedina NVMe noda a samozrejme technologie kravi, takze namigrovane VPSky sly do par tydnu dolu. Novy HW, jakoze novou konfiguraci, kupovat zasadne v dvojici a mit kam premigrovat z toho zdravyho nodu z nich... Ted mi node4.brq lezi na stole v base48 a akorat si s nim hraju, abych zjistil, co je vlastne za problem. (vlivem cca moji vlastni blbosti uz neni v zaruce a porad nevim, co je tam za problem, prinejhorsim pujde out na soucastky po jejich validaci) /snajpa

P.

Dne 18. dubna 2018 12:46 sorki <srk@48.io> napsal(a):

...

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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz [1]

Ahoj Pavle, díky za odpověď.

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

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

--

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

mrpear@mrpear.net

web, webdesign, web-aplikace: http://www.pearfect.cz [9] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

--

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

mrpear@mrpear.net

web, webdesign, web-aplikace: http://www.pearfect.cz [9]

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

Hot standby je cela masina v OK stavu ready na nasunuti kontejneru, idealne zapnuta a regnuta ve vpsAdminu. V pripade totalni paniky se precvaknou disky, v pripade klidnejsiho konce sveta je jenom migrujou VPSky za chodu. /snajpa On 2018-04-18 18:59, Pavel Hruška wrote:

Hot-standby je mašina bez disků?

Dne st 18. 4. 2018 18:36 uživatel Pavel Snajdr <snajpa@snajpa.net> napsal:

...

On 2018-04-18 13:00, Pavel Hruška wrote:

...

Nad cluster storage jsem taky uvažoval, ale četl jsem, že tam "může" být problém s výkonem (i kdyby 10GbE, tak má sice propustnost, ale problém může být latence a je třeba počkat na potvrzení od všech nodů v clusteru) - nevím, jen jsem četl, nezkoušel jsem.

Broadcom Trident II switch cipy, ktere budeme pouzivat, maji mit nejakych 600ns port-to-port latenci, kdyz zapocitas, ze packet pujde (kdyz mezi racky) max pres 2 switche, udela to z NVMe disku vec s o par stovek mikrosekund vetsi latenci, dokud je volny bandwidth (a tam zalezi na zesilovacim efektu pri zapisu, tj. jak a kolika nodam se dava vedet, kdyz jedna noda neco pise do clusteru).

...

Pro zajímavost, řešili jste někdy takovou situaci, že by

klekl HW

...

celého node tak jak to tu diskutujeme?

Ojeje, jasne.

Nastesti jsme vzdycky meli nejaky volny hardware, i kdyz v Brne, kdyz byly problemy s node1.brq, to bylo zajimavejsi a downtime by byl kratsi, kdyby tam byla hot-standby masina, jak je to ted uz pravidelne v Praze. Nastesti Brno neni daleko od Bratislavy a Tomas dovezl nahradni desku, kterou jsme to vyresili docasne, nez prisla nova.

Celkove ty vypadky, kdyz se neco takovyho deje, jsou max tak na 2 hodky.

Jina vec je to s NASem, ten ale neni zdvojeny vicemene "by design",

protoze to je vec postavena z penez, co zbydou - a jeste nezbyly penize na zdvojeni - bo to mmj. i do budoucna zdvojnasobi naklad uz na vzdycky, co jednou nekomu slibime, uz brat zpatky tezko muzem, ze ;). To vyresime casem, nejdriv 2x10GE konektivitu per noda.

Hlavni je se nestrelit do nohy jak my s node4.brq, co je 350k CZK lezicich jen tak; je to zatim jedna jedina NVMe noda a samozrejme technologie kravi, takze namigrovane VPSky sly do par tydnu dolu.

Novy HW, jakoze novou konfiguraci, kupovat zasadne v dvojici a mit kam premigrovat z toho zdravyho nodu z nich...

Ted mi node4.brq lezi na stole v base48 a akorat si s nim hraju, abych zjistil, co je vlastne za problem.

(vlivem cca moji vlastni blbosti uz neni v zaruce a porad nevim, co je tam za problem, prinejhorsim pujde out na soucastky po jejich validaci)

/snajpa

...

P.

Dne 18. dubna 2018 12:46 sorki <srk@48.io> napsal(a):

...

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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz [1] [1]

Ahoj Pavle, díky za odpověď.

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

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7] [7] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7] [7]

--

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

mrpear@mrpear.net

web, webdesign, web-aplikace: http://www.pearfect.cz [9] [9] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7] [7]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7] [7]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7] [7]

--

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

mrpear@mrpear.net

web, webdesign, web-aplikace: http://www.pearfect.cz [9] [9]

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

---

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

Ahoj Pavle, díky za odpověď.

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

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

--

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

mrpear@mrpear.net

web, webdesign, web-aplikace: http://www.pearfect.cz [9] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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@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@pripravto.cz Mobil: +420 702 549 370 Web: www.pripravto.cz

Dne 18. dubna 2018 14:43 Pavel Snajdr <snajpa@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@mrpear.net> Komu: vpsFree.cz Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz: community-list] Infrastruktura vpsfree.cz

Ahoj Pavle, díky za odpověď.

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

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

--

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

mrpear@mrpear.net

web, webdesign, web-aplikace: http://www.pearfect.cz [9] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [7]

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

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

---

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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@gmail.com> Komu: vpsFree.cz Community list <community-list@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@snajpa.net (mailto:snajpa@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@gmail.com (mailto:zdnexnet@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@pripravto.cz(mailto:support@pripravto.cz) Mobil: +420 702 549 370 Web: www.pripravto.cz(http://www.pripravto.cz) Dne 18. dubna 2018 14:43 Pavel Snajdr <snajpa@snajpa.net (mailto:snajpa@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@mrpear.net(mailto:mrpear@mrpear.net)> Komu: vpsFree.cz(http://vpsfree.cz) Community list <community-list@lists. vpsfree.cz(mailto:community-list@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@snajpa.net (mailto:snajpa@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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) [7] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@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@mrpear.net(mailto:mrpear@mrpear.net) web, webdesign, web-aplikace: http://www.pearfect.cz(http://www.pearfect.cz) [9] _______________________________________________  Community-list mailing list  Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz)  http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) [7] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@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@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " "" _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz(mailto:Community-list@lists.vpsfree.cz) http://lists.vpsfree.cz/listinfo/community-list (http://lists.vpsfree.cz/listinfo/community-list) " _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list "

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@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@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@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@pripravto.cz Mobil: +420 702 549 370 Web: www.pripravto.cz [1]

Dne 18. dubna 2018 14:43 Pavel Snajdr <snajpa@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@mrpear.net> Komu: vpsFree.cz [2] Community list <community-list@lists.vpsfree.cz> Datum: 18. 4. 2018 10:45:27 Předmět: Re: [vpsFree.cz [2]: community-list] Infrastruktura vpsfree.cz [3]

Ahoj Pavle, díky za odpověď.

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

Jsem u 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 [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 [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 [8] [6]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [9] [7] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [9] [7]

--

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

mrpear@mrpear.net

web, webdesign, web-aplikace: http://www.pearfect.cz [11] [9] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [9] [7]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz 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/ [6] [5] https://opencamp.sk/o-konferencii [7] [6] https://kb.vpsfree.cz/informace/infrastruktura [8] [7] 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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [9]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [9]

_______________________________________________

...

Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [9]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz 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/ [7] https://opencamp.sk/o-konferencii [8] https://kb.vpsfree.cz/informace/infrastruktura [9] 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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

-- PhDr. Dominik Prochazka 00421 902 121 571

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@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@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@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@pripravto.cz Mobil: +420 702 549 370 Web: www.pripravto.cz [1] [1]

Dne 18. dubna 2018 14:43 Pavel Snajdr <snajpa@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@mrpear.net> Komu: vpsFree.cz [2] Community list <community-list@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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [8] [9] [7] _______________________________________________ Community-list mailing list Community-list@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@mrpear.net

web, webdesign, web-aplikace: http://www.pearfect.cz [10] [11] [9] _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [8] [9] [7]

_______________________________________________ Community-list mailing list Community-list@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [8] [9]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [8] [9]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [8] [9]

_______________________________________________ Community-list mailing list Community-list@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [8]

_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [8]

--

PhDr. Dominik Prochazka 00421 902 121 571

_______________________________________________ Community-list mailing list Community-list@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list