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

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 &lt;mrpear(a)mrpear.net&gt; > Komu: vpsFree.cz Community list &lt;community-list(a)lists.vpsfree.cz&gt; > 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 &lt;Ondrej.Flidr(a)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 &lt;community-list(a)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 &lt;Ondrej.Flidr(a)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 &lt;community-list(a)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 &lt;Ondrej.Flidr(a)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 &lt;community-list(a)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 &lt;snajpa(a)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(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list > _______________________________________________ > Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list