Fórum Root.cz
Hlavní témata => Server => Téma založeno: Jan Karas 15. 08. 2017, 21:12:47
-
ve firmě bychom rádi přešli na virtualizaci (s hyper-V). Chceme provozovat 2 x Hyper-V, kde jeden stroj bude produkční a druhý záložní. Na obou Hyper-V poběží 3 linuxové VM (centos), na tom záložním stroji by ty linuxoé VM nebyly aktivní. V případě potřeby (např. při havárii produkčního hyper-V by se nabootovaly ty 3 linuxové VM a vše by běželo dál. Potud je vše podle našeho OK. Záložní VM má tu samou IP, vsechna nastavení a konfigurace jsou shodna (např. i crontab) s produkční VM.
Problém vidíme v tom, že se může stát, že za běhu produkčních VM někdo nabootuje na záložním hyper-V jednu z těch VM. V síti jsou pak 2 shodné IP-adresy a hlavně se na tom záložním VM rozběhne cron a nastává chaos(zakázky by se potvrzovly v internetu 2 krat a pod.).
Je tohle vůbec nějak řešitelné, nezná někdo nějakou fintu? Nebo něco přehlížíme?
-
preco hyper-V? budu tam aj nejake ine virtualky? ak to je linux only prostredie, tak by som sa vykaslal na hyper-v... lebo tam bude HA licencia asi draha :) a to co hladas je HA, hociaky hypervizor s podporpu HA a so zdielanym storage dokaze to co chcete.
Ak to chcete mat na single instancii a nejaky fencing, tak bohuzial, musite si to nejak cigansky oscriptovat, implementovat do cronu nejaku logiku aby kontroloval ci mu bezi sused. a ak ano, tak sa nespusti script a hlavne preco musia mat rovnake IPcky?
-
Trochu se obávám, že jestliže si myslíte, že největší problém je cron, tak byste se do toho radši pouštět neměli. Nebo si ještě hodně dostudovat a jít do toho až pak...
Pro inspiraci např: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/High_Availability_Add-On_Administration/ch-startup-HAAA.html
-
ve firmě bychom rádi přešli na virtualizaci (s hyper-V). Chceme provozovat 2 x Hyper-V, kde jeden stroj bude produkční a druhý záložní. Na obou Hyper-V poběží 3 linuxové VM (centos), na tom záložním stroji by ty linuxoé VM nebyly aktivní. V případě potřeby (např. při havárii produkčního hyper-V by se nabootovaly ty 3 linuxové VM a vše by běželo dál. Potud je vše podle našeho OK. Záložní VM má tu samou IP, vsechna nastavení a konfigurace jsou shodna (např. i crontab) s produkční VM.
Problém vidíme v tom, že se může stát, že za běhu produkčních VM někdo nabootuje na záložním hyper-V jednu z těch VM. V síti jsou pak 2 shodné IP-adresy a hlavně se na tom záložním VM rozběhne cron a nastává chaos(zakázky by se potvrzovly v internetu 2 krat a pod.).
Je tohle vůbec nějak řešitelné, nezná někdo nějakou fintu? Nebo něco přehlížíme?
doporucuju proxmox5 a zsync gui, 2 stejne/podobne servery a 3. pixla pro fencing staci nejaky microserver opet s proxmoxem
pak se to muze chovat SKORO jako ha cluster, pouze s tim, ze nejde online migrace a data jsou na replikovanych lokalech cili je tam virtualka stara par minut a ne online jako v pripade SANu
-
doporucuju proxmox5 a zsync
Když zmiňuješ proxmox a ZFS, jaký s tím máš zkušenosti? Já jsem byl silně rozčarovanej nad stabilitou 4ky: dokud byl swap na zvolu, padalo to jak hrušky. Když jsem ho zrušil, bylo to lepší, ale pořád ne úplně stabilní. 5ka zatím vypadá být úplně v pohodě (fingers crossed).
Mám to víceméně jenom na testování na stroji s 8G RAM, což není moc, ale až takhle velkou nestabilitu jsem neočekával...
-
doporucuju proxmox5 a zsync
Když zmiňuješ proxmox a ZFS, jaký s tím máš zkušenosti? Já jsem byl silně rozčarovanej nad stabilitou 4ky: dokud byl swap na zvolu, padalo to jak hrušky. Když jsem ho zrušil, bylo to lepší, ale pořád ne úplně stabilní. 5ka zatím vypadá být úplně v pohodě (fingers crossed).
Mám to víceméně jenom na testování na stroji s 8G RAM, což není moc, ale až takhle velkou nestabilitu jsem neočekával...
mam ty same zkusenosti, ale vyresil jsem je tak, ze jsem nainstaloval zram-config a zakazal swapovani do ZFS a pak jeste zfs destroy rpool/swap a od te doby to beha jako vino.. kazdopadne 8GB RAM je tak na zkouseni a ne na provoz, vetsinou mam 32 az 192GB RAMky
-
preco hyper-V? budu tam aj nejake ine virtualky? ak to je linux only prostredie, tak by som sa vykaslal na hyper-v... lebo tam bude HA licencia asi draha :) a to co hladas je HA, hociaky hypervizor s podporpu HA a so zdielanym storage dokaze to co chcete.
Ak to chcete mat na single instancii a nejaky fencing, tak bohuzial, musite si to nejak cigansky oscriptovat, implementovat do cronu nejaku logiku aby kontroloval ci mu bezi sused. a ak ano, tak sa nespusti script a hlavne preco musia mat rovnake IPcky?
ja nevím, jestli hledám HA. Výpadek 2 hodiny je u nás asi v pohodě, proto jsme se zatím s HA nezabývali. Ten hyper-V je raz-dva nainstalovaný, nestojí nic a dnes to prý už provozuje kde-kdo. Tu zálohu dělá hyper-V sám, což by pro nás byla úspora, protože to teď děláme přes řadu rsync-scriptů. Ta nevýhoda je, že se zálohuje image té VM a v ní se samozřejmě skrývá např. i ta IP-adresa. To s tím 'oscriptováním' nás taky napadlo, ale máš pravdu, že je to takove 'nepříjemné'.
-
doporucuju proxmox5 a zsync gui, 2 stejne/podobne servery a 3. pixla pro fencing staci nejaky microserver opet s proxmoxem
díky za podnětný návrh. Jestli jsem to dobře pochopil, jedná se o HA řešení, které 'mý být' méně náročné na správu. To je trochu náš problém a obávám se, že se o to musí někdo starat. Proto bych rád vědel, co to v běžném provozu obnáší. Někdo tady napsal, že s verzí 4 měl problémy, verze 5 je z cervna 2017 - tedy relativně nová věc. A i ty připomínky ohledně ZFS jsou trochu znervózňující.
Za jak dlouho je možno odhadem se do problematiky zapracovat? (máme 20 let zkušenosti s unixem). Běží to skutečně bezproblémově?
-
díky za podnětný návrh. Jestli jsem to dobře pochopil, jedná se o HA řešení
Zsync není opravdové HA řešení. Opravdové HA musí vypadat nějak takhle:
1. minimálně dva nody schopné převzít zátěž (spustit virtuály)
2. společné (!) úložiště - tj. data virtuálů nejsou uložená na nodu, ale mimo něj, přístupné oběma nody
3. nějaký způsob detekce živosti (třetím nodem) + fencing (v případě výpadku nodu 1 jej natvrdo (!) vypne a virtuály spustí na nodu 2) - fencing se opravdu dělá tvrdě, např. vypnutím proudu pro ten node, aby byla jistota, že se v síti nemůžou plést oba dva nody
U zsync je ten bod 2 udělaný jinak - každý z nodů má virtuály uložené na svém lokálním úložišti a čas od času se data synchronizují.
U všech řešení je potřeba dát pozor na dvě věci:
1. typicky se nesynchronizuje obsah RAM - cokoli je v RAM a není na disku, bude při pádu nodu nenávratně ztraceno, HA neHA.
2. bacha na to, že disk se může synchonizovat (u společného úložiště může pří pádu zůstat v) nějakým způsobem nekorektním/neúplném stavu. Na to je potřeba myslet hlavně u zápisů, které nemají transakce. Pokud transakce jsou, je potřeba myslet na to, jestli jsou klientovi potvrzeny skutečně až po plném zápisu na disk (bacha na disky, které lžou apod.) Není to žádná pr.del, na 100%ní spolehlivost nelze spolíhat, pokud tomu člověk úplně suprově nerozumí a nemá všechno perfektně otestované a ověřené.
, které 'mý být' méně náročné na správu. To je trochu náš problém a obávám se, že se o to musí někdo starat. Proto bych rád vědel, co to v běžném provozu obnáší.
ProxMox je klikačka, se kterou se člověk seznámí rychle a údržbu vyžaduje takovou, jako jakýkoliv linuxový stroj (hlavně updaty, případné restarty). Výhodou je, že virtuály se dají migrovat, takže je možné virtuál odmigrovat, stroj updatovat, restartovat. Totéž na druhém stroji.
Někdo tady napsal, že s verzí 4 měl problémy, verze 5 je z cervna 2017 - tedy relativně nová věc. A i ty připomínky ohledně ZFS jsou trochu znervózňující.
To se týká výlučně ZFS. ProxMox má víc druhů úložišť. Já jsem chtěl ZFS hlavně proto, že s ním mám zkušenost. Bohužel na Linuxu je to se stabilitou asi tak stejný jako na FreeBSD před sedmi lety...
Zkoušel jsem ještě LVM, ale tam ProxMox používá thin provisioning, na můj vkus je to příliš složité a málo přehledné a při nekorektním vypnutím se mi podařilo ho dostat do stavu, který jsem neuměl opravit (tím netvrdím, že to nešlo). Takže ZFS mi přišlo jako lepší volba. V 5ce se navíc zdá být už rozumně stabilní.
Za jak dlouho je možno odhadem se do problematiky zapracovat? (máme 20 let zkušenosti s unixem). Běží to skutečně bezproblémově?
Týden zkoušení člověkem, který má aspoň nějaké povědomí o Linuxu a aspoň trochu tuší, co bude dělat. Pak nějakou dobu na ne-produkční testování - jak dlouho záleží na tom, jak moc velkou jistotu chce člověk mít...
Řekl bych, že největší věda je vymyslet, jak to vlastně celé bude fungovat (ZFS, LVM nebo Ceph?) sdílené úložiště nebo lokální? Automatický fencinf a failover, nebo prostě manuální přepnutí? Kdyř ZFS, tak cache na SSD? Čtecí nebo zápisová? Atd. atd. Naštěstí ale díky tomu, že se VMs dají migrovat, hodně se dá i ex post změnit, buď úplně za běhu, nebo jenom s minimálními výpadky.
-
... Výpadek 2 hodiny je u nás asi v pohodě, ...
Asi by som v takom prípade záložným serverom nastavil iné IP adresy, crony vyradil (zakomentoval) a niekde na viditeľnom mieste nechal README ako to zmeniť späť (alternatívne spraviť jednoduchý skript, ktorý sa musí ručne spustiť a ktorý reaktivuje crony a zmení IP adresu). Potom by náhodné spustenie záložných serverov nevadilo.
Btw, nebude ich treba tak či tak občas spustiť kvôli aktualizácii?
-
doporucuju proxmox5 a zsync gui, 2 stejne/podobne servery a 3. pixla pro fencing staci nejaky microserver opet s proxmoxem
díky za podnětný návrh. Jestli jsem to dobře pochopil, jedná se o HA řešení, které 'mý být' méně náročné na správu. To je trochu náš problém a obávám se, že se o to musí někdo starat. Proto bych rád vědel, co to v běžném provozu obnáší. Někdo tady napsal, že s verzí 4 měl problémy, verze 5 je z cervna 2017 - tedy relativně nová věc. A i ty připomínky ohledně ZFS jsou trochu znervózňující.
Za jak dlouho je možno odhadem se do problematiky zapracovat? (máme 20 let zkušenosti s unixem). Běží to skutečně bezproblémově?
neni to HA, je to neco napul cesty od rucniho spousteni zreplikovane virtualky po plnohodnotne HA, kdy vyskubnes kabel z node1 a virtualky bootujou na node2 (nebo jinde) ze spolecneho uloziste, hlavni vyhodu zde spatruju v tom, ze ti staci lokalni uloziste cili ZFS nad levnyma diskama (plus mozna SSD na cache a/nebo slog), netreba HW raidu takze je to levne reseni .. takze zalezi na tom, o kolik penez prijdes kazdou minutu/hodinu/den, kdyz ti vypadnou sluzby bezici na virtualkach a od teto castky necht se odviji patricne reseni - od zalohovani virtualek z 1 serveru na NAS, pres replikace zsyncem z node1 na node2 a rucni spusteni, dale pres jakoby-HA cili totez ale 3. stroj na fencing az po plnohodnotne HA cili 3 servery, SAN, switche atd. cili se pohybujes v cenach od 10^4 az po 10^6
-
Nějak moc nechápu, pokud máte tak velkou zkušenost na Unixech proč vůbec uvažujete nad Hyper-V - to mi přijde jako blby vtip.
Posledních několik let celkem úspěšně nasazujeme právě KVM/Proxmox u našich zákazníků, většina již má nějakou zkušenost s virtualizací VMware, Hyper-V nebo Xenem - po migraci na Proxmox a další open-sourcové technologie si nikdo na Hyper-V nebo VMware ani nevzpomene :) Všichni si "jednohlasně" pochvalují přehlednou konzoli a celkovou jednoduchou údržbu systému a se stabilitou nemíváme nikde žádné problémy - pokud je vše designováno tak jak má být jede to velmi svižně a spolehlivě. Zkrátka bych se na nějaký Hyper-V nesmysl vykašlal a udělal to na Proxmoxu. Takové malé plus je i podpora kontejnerové virtualizace atd... V pětkové verzi již je integrována ZFS replikace přímo v GUI, takže by to vašim požadavkům mělo vyhovovat. Na HA bych se vykašlal (a všem zákazníkům, kteří ho vyloženě nepotřebují to vždy celkem úspěšně rozmluvím), protože tam můžou nastat dost nehezké stavy a administrátorské chyby se většinou nedají tak lehce opravit + celková údržba není tak triviální.
-
Co to zkusit bez té replikace, například Altaro je dostupný software pro zálohování virtuálních strojů, jak Hyper-V tak VMWare, jedna z jeho funkcí je v případě potřeby nabootovat virtuály okamžitě ze zálohy (onsite, offsite) a zároveň tyto zálohy obnovit do produkčního prostředí, přičemž lze s nabootovanými zálohami v klidu fungovat a pracovat, změněná data se ukládají na diferenční disk na pozadí, po konci obnovení a pracovního klidu lze stisknutím tlačítka dokončit s tím, že se nová data rovnou sloučí s těmi obnovenými.
-
... toho hodně napsal ...
díky za informace, zajímavá je ta poznámka o té paměti - mně teď napadá, ze i ten snapshot té VM asi také ten obsah té RAMky neobsahuje :-) a i ty transakce budou možná problém. Tedy prinejmenším se asi bude muset dělat recovery při startu záložního VM - ale to asi dělají všechny pořádné DB při bootu automaticky.
-
... Výpadek 2 hodiny je u nás asi v pohodě, ...
Asi by som v takom prípade záložným serverom nastavil iné IP adresy, crony vyradil (zakomentoval) a niekde na viditeľnom mieste nechal README ako to zmeniť späť (alternatívne spraviť jednoduchý skript, ktorý sa musí ručne spustiť a ktorý reaktivuje crony a zmení IP adresu). Potom by náhodné spustenie záložných serverov nevadilo.
Btw, nebude ich treba tak či tak občas spustiť kvôli aktualizácii?
tak to teď máme. (tedy na bázi fyzikálních servrů). S tím , že je prakticky nemožné provést rsync na všechno a na potvoru už se několikrát stalo, že se na produkčním servru se změnilo něco, co nebylo pokryté rsyncem a ta informace pak na záložním servru chyběla. Tím , že se zkopíruje VM-image tohle nebezpečí odpadá.
Ano, samozřejmě je třeba zálohu někdy spustit. Kvůli kontrole dat a pod. Jen tak mimo téma, když už jsi to zmínil, my jsme za posledních 10 let žadný server neaktualizovali.
-
díky za informace, zajímavá je ta poznámka o té paměti - mně teď napadá, ze i ten snapshot té VM asi také ten obsah té RAMky neobsahuje :-)
Snapshoty běžícího stroje image RAM obsahují (viz https://pve.proxmox.com/wiki/Live_Snapshots) a je to potřeba i pro live migraci. Jestli to platí i pro zsync, to nevím, zatím jsem to neměl potřebu zkoumat.
a i ty transakce budou možná problém. Tedy prinejmenším se asi bude muset dělat recovery při startu záložního VM - ale to asi dělají všechny pořádné DB při bootu automaticky.
Recovery by měla každá rozumná DB zvládnout dobře, v tom bych problém neviděl. Spíš v tom, jestli se dá opravdu spolehnout na fsyncování změn.
Každopádně ale při tom řešení se zsyncem se z principu věci nějaké transakce ztratí, protože se syncuje jenom jednou za nějakou dobou - tj. všechno, co se zapsalo od posledního synce, je fuč.
-
Nějak moc nechápu, pokud máte tak velkou zkušenost na Unixech proč vůbec uvažujete nad Hyper-V - to mi přijde jako blby vtip.
Posledních několik let ......
já nevím jestli to bylo dobře pochopeno. Já si myslím, že je jedno jaká virtualizační strategie se použije - jako záloha se použije nějaký snapshot produkčního VM, který obsahuje konkrétní nastavení (systémové/aplikační) a když poběží oba VM tak nastanou problémy. Vím , že na toto nejsou snapshoty určeny, ty se normálně odloží na nějaký NAS a v případě havárie se to z té zálohy obnoví. Jestliže se takto chová hyper-V i proxmox podobně, nevidím v tom rozdíl.
Přesto jsem si ten proxmox stáhnul, na netu jsem našel hodně pozitivních reakcí, takže si to vyzkoušíme.
-
Co to zkusit bez té replikace, například Altaro je dostupný software pro zálohování virtuálních strojů, jak Hyper-V tak VMWare, jedna z jeho funkcí je v případě potřeby nabootovat virtuály okamžitě ze zálohy (onsite, offsite) a zároveň tyto zálohy obnovit do produkčního prostředí, přičemž lze s nabootovanými zálohami v klidu fungovat a pracovat, změněná data se ukládají na diferenční disk na pozadí, po konci obnovení a pracovního klidu lze stisknutím tlačítka dokončit s tím, že se nová data rovnou sloučí s těmi obnovenými.
díky, provádím download té free verze. Dám zprávu, jestli by to byla schůdná cesta.
-
Nějak moc nechápu, pokud máte tak velkou zkušenost na Unixech proč vůbec uvažujete nad Hyper-V - to mi přijde jako blby vtip.
Posledních několik let ......
já nevím jestli to bylo dobře pochopeno. Já si myslím, že je jedno jaká virtualizační strategie se použije
tak ono to jedno moc neni, kdyz jsem mel virtualky na VMware, tak jsem byl permanentne nasran bo nektere ficurky sly ladit pouze tlustym windows-only klientem a zase jine pouze pres web-clienta, na nehoz jsi musel mit flash, ale to zase slo kdyz jsi mel vcenterserver a ten si mel zase jenom u placene verze a pak udelali webclienta primo na ESXi ale to padalo a ..... jeste ted mam depku kdyz si na to vzpomenu.
windowsum verim jako loader na aplikace, ale sverovat jim ulohu hypervizora, na to koule nemam a administrace hyper-v taky humus, jak pise kdosi nade mnou, administrace proxmoxu je radost a zazitek a nepotrebuju wokna/flash/licence nybrz mne staci browser...
cili doporucuju proxmox
-
Přesně tak jak píše "milous" - velmi podobnou zkušenost mám já , potažmo naši zákoši. Určitě tomu Proxmoxu dejte šanci, není to nic složitého a uvidíte, že to je opravdu pohoda to nasadit v reálném provozu. Jinak v kombinaci s vhodným síťovým ZFS storagem (a po řádné konfiguraci a plánování) netřeba na zálohy používat žáden soft třetích stran a vše nechat na ZFS snapshotech. Pokud někdo přrjde na toto řešení z Hyper-V/VMWare + VEEAM je to pro něj jak z jineho světa :) Naposledny jsem "obnovoval" virtuál a data v jednom clusteru po zašifrování Ramsonwarem (cca 980 GB dat) a výpadek služby byl necelých 17 minut.... to mi příjde celkem ok :)
Takže za mně taky Proxmox nad ZFS - a co nejvíce RAM. ZFS potřebuje moooc ramky aby vše běželo rychle tak jak má.
M.
-
Přesně tak jak píše "milous" - velmi podobnou zkušenost mám já , potažmo naši zákoši. Určitě tomu Proxmoxu dejte šanci, není to nic složitého a uvidíte, že to je opravdu pohoda to nasadit v reálném provozu. Jinak v kombinaci s vhodným síťovým ZFS storagem (a po řádné konfiguraci a plánování) netřeba na zálohy používat žáden soft třetích stran a vše nechat na ZFS snapshotech. Pokud někdo přrjde na toto řešení z Hyper-V/VMWare + VEEAM je to pro něj jak z jineho světa :) Naposledny jsem "obnovoval" virtuál a data v jednom clusteru po zašifrování Ramsonwarem (cca 980 GB dat) a výpadek služby byl necelých 17 minut.... to mi příjde celkem ok :)
Takže za mně taky Proxmox nad ZFS - a co nejvíce RAM. ZFS potřebuje moooc ramky aby vše běželo rychle tak jak má.
M.
tez neni spatne - mam overeno - 3 nody s ProxMoxem + FreeNAS pres NFS (10gbe switche/kabely/sitovky vse SFP+) pripadne s replikaci na dalsi FreeNAS, vse opensource, vse jednoduse adminovatelne pres http/ssh, zkratka krasa .. a staci relativne slaby/levny HW a nemusim resit pojebane licence, btw pro VMwareFlashReadCache jsem potreboval nejakou hustodemonsky licenci, u proxmoxu vrazim do masiny 2x intel S3610 a pridam zpoolem cache/log a je online vse hotovo.. ja osobne tedy hykam nadsenim
-
kdyz to tak ctu, nebylo by jednodussi to proste (za)hodit ...do cloudu...