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