Fórumok
Sziasztok!
Adott 2 egyforma gép (i5, 32GB RAM, 2x500GB sata, 2 GiB hálókártya), ebből szeretnék kialakítani egy HA cluster-t virtualizáláshoz, live migration nagyon jó lenne. A vendég 1-2 windows 10 rendszer lenne, nincs nagy erőforrás igényük. Milyen virtualizációs megoldással lehetne megoldani? Persze pénz nincs, tehát ingyenes kellene.
Hyper-V-t néztem, itt az a gond, hogy AD kell neki. Vmware ESXI-vel régebben játszottam, nem tudom az ingyenes hypervisor elég lenne-e hozzá. Proxmox szimpatikus, de ha jól láttam, ahhoz 3 node kell. Xenserver-t nem ismerem, még nem találkoztam vele.
Hozzászólások
Keress ra: KVM live migration
Ha azonban komoly dologrol van szo es nem csak tesztelesrol, akkor en inkabb fizetnek.
Free ESXi csak standalone gépre jó. Live migration-höz (vMotion) és HA-hoz "fizetős" ESXi és vCenter licenc kell. (Abból sem mindegy, milyen.)
Döntsd el, hogy HA-t akarsz, vagy live migrationt. Utóbbihoz elég két gép. A HA kicsit más történet. Technikailag megoldható két géppel, de IMHO két géppel nem akarsz olyat.
A 2 GiB (gibibájt) hálókártya az gondolom 2x1 Gb (gigabit) hálókártya akart lenni.
A hálókártya az 2x1 Gb, elírtam. Live migration lenne a fontos. Elolvastam egy csomó Hyper-V doksit, de nem áll össze a dolog. Hyperconverged, HA, live migration...
Szep osszefoglalo, +1 :)
Az a 2x500 SATA ~10 VM-re az HDD vagy SSD? Ha HDD akkor I/O gondjaid lesznek, az kb. 100iops per host
ESXi-nek kell shared storage a HA-hoz.
--
"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."
1-2 Windows 10. Nem 10 windows.
1-2 db Windows 10-et említett. De először és is tizet láttam. :)
De egyébként, HDD már egy win10-hez is gyötrelmes, virtualizáció nélkül is.
--
"Sose a gép a hülye."
Két gépből HA-t csinálni nem jó ötlet. Több vele a baj, és instabilabb lesz, mintha 1 géped lenne. Az LA lesz. :)
--
"Sose a gép a hülye."
Ez kb minden clusterre igaz, ha nem ertesz hozza.
Szerintem a split-brain helyzet kezelésére gondolt, hogy nem ártana, ha az a 2 inkább 3 lenne. Vagy valami shared 'quorum witness' device kell. Ha manuális failover elég, akkor nem fáj.
---
Régóta vágyok én, az androidok mezonkincsére már!
Kár, hogy ezt anno nem tudtuk. Minden clusterünk kétgépes volt. A két gépből sosem volt baj, a clusterre nem teljesen felkészült szoftverekkel már inkább.
Igaz, op.rendszert használtunk játékszerek helyett. :D
(VMS, AIX - a Solarisos és HPUX-os clusterekről már nem mernék így nyilatkozni :) )
Utoljára bő 5 éve foglalkoztam ilyesmivel, de akkor teljesen jól tudott működni Solaris alapokon ez a felállás is, amennyiben át volt gondolva a környezet és megfelelően volt kivitelezve. _Nem_ hitvita, csak tapasztalat. AIX-szel minimális tapasztalatom van csak, VMS-sel pedig sajnos semmi.
------------------------
{0} ok boto
boto ?
Félreértesz:
AIX-en inkább csak felhasználó voltam, de az a rendszer úgy ment, hogy rá se kellett nézni. Solaris, HPUX terén meg alig van tapasztalatom, azokra nem mernék semmi komolyabb kinelentést tenni, habár a sysadmin tanfolyamot végigültem mindkét rendszerrel.
VMS viszont mondhatni, atomstabil volt e téren.
Manuális failovernél ez nem olyan nagy gond (live migrálni úgysem tudsz automatikusan - ha lehalt az aktív, akkor már nem live). Van ilyenem, drbd, kvm. Ha kell, manuálisan primaryba rakom a backup gépen a drbd-t, és elindítom rajta a VM-et.
Elég sok 2 ESXi-s VMware vSphere fürt futkorászik szerte a világban. Mi ezzel a probléma?
Pacemaker, LOM fencing, DRBD, libvirtd. Ezek az epitokockak. Kesz tutorialt hirtelen nem talaltam de biztos van valahol. Mindenesetre egy csomo dolgot meg kell hozza tanulnod maskepp szivas lesz. Osszekattingatos megoldast nem tudok.
Én anno próbáltam corsync-kel, nem csinálnám még egyszer. Bármi gebax történik valamelyik géppel, annak a hálókártyájával, a köztük lévő kapcsolattal, ami miatt egyik nem fogja látni a másikat, és kész a split brain.
--
"Sose a gép a hülye."
A fencing megakadalyozza a split-braint. Mellesleg a link lehet tobbszorosen redundans.
Ja, csak ha pont egyszerre lesz STONITH, akkor ugrott a HA :D
Erre az esely gyakorlatilag nulla. A DC a fencinget elobb fogja megkezdeni (miutan a tobbszorosen redundans link elszakadt).
Alapvetoen onnan johet ez a mitosz, hogy a redundans linket, a robusztus fencinget (es azok folyamatos monitorozasat) sokan kihagyjak, folosleges sallangnak gondolva, hiszen a nelkul is mukodik a cluster az egybites, de latvanyos teszteken. Amig nem jon egy valodi hiba. Es akkor a hibas nyilvan a cluster lesz. :)
+1
https://rarforge.com/w/index.php/2_Node_Cluster:_Dual_Primary_DRBD_%2B_…
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Köszi, átrágom magam rajta. Kicsit melós, de legalább betekintést nyerek a "motorháztető" alá.
clvm lehet tulzas, talan HA-LVM eleg https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… .
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
ha a HA alatt azt erted, hogy el tudd inditani a windows 10-et masik hoston (kezzel), es nemkell automatika, akkor proxmox+drbd mukodik.
az automata pakolgatashoz kell a 3 node hogy meglegyen itt is a 2/3-ad :)
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ovirt.
Kezeli a HA Clustert, van live migration is, sot tudsz beallitani parametereket auto live migration-hoz (Scheduling Policy) is (proc. hasznalat, op-rendszer tipusa, altalanos leterheltseg, etc...)
Ketgepes megoldashoz kulso storage kell (NFS, iSCSI, FCP, GlusterFS...)
Ha 3 Node-od lenne, akkor egybol tudnal Gluster storage-ot is csinalni, akkor nem kell kulso storage. De szerintem egy NAS olcsobb :)
Full ingyenes, lenyegeben az RHV free valtozata.
Szerk: Most latom, alegujabb ovirt mar tud single Node-os Gluster storage-al is menni, ami nagy kiralysag! (ki is fogom probalni! :) )
BZ 1479714 [RFE] - HE should support Gluster replica 1 or 3.
Feature: Support running HE on a replica 1 gluster volume
Reason: This will enable single node hyperconverged deployments.
Milyen követelménynek köszönhető, hogy a Quick Migration nem elegendő?
Üdv,
Marci
Az volna a jó, ha a VM megállás nélkül költözne másik node-ra, ha az alatta lévő kidől. Ha jól értelmeztem, akkor a quick migration esetén van kiesés.
Ha kidolt, akkor mar hogy koltozne? Prefail eseten lehet live migralni, utana mar halottnak a csok. Neked mindennek szinkronban kell lennie allandoan, hogy kieses nelkul folytathasd..
Mi konkretan a use case, amit meg szeretnel oldani?
Direkt v. indirekt modon emlitettel mar sok dolgot itt, az az erzesem, hogy ossze is mododnak nalad a fogalmak.
HA, live migracio, shared storage stb.
Mi konkretan, amit el akarsz erni, mennyi kieses engedheto meg, miert akarod, hogy legyen live migration stb.?
Szinte mindent lehet, csak ara van. Jellemzoen penzugyi, teljesitmenybeli v. funkcionalitasbeli kompromisszumot kell kotnod.
Igen, lehetséges, hogy keverem a dolgokat. Most ismerkedek vele, ezért kérdeztem. Tanulás célzattal álltam neki.
Ezt a VMWare Fault Tolerance-nak hívja. A Hyper-V live replikát tud, de ott lesz valamennyi lauf. Hogy mennyire kell ehhez manapság közös storage azt nem tudom.
Az i5 és 32GB RAM egy szem SATA diszkpárral nem sejtet túl komoly büdzsét sajnos. Az üzemelés helyét nem írtad, de gondolom külön UPS az megoldott. A redundáns táp és ECC memória sem ártana, bár ez utóbbi i5-tel nem lesz nyerő. Ezek azért lennének jók, hogy mindenféle banális hiba miatt jöjjön a failover.
+1 meg azért a hálózatot sem ártana kivesézni - dupla switch, lacp, meg egy pár vlan, hogy legalábblogikailag elválasztható legyen a fürt belső forgalma a szolgáltatás(ok) forgalmától a két (gondolom alaplapi), illendően összefogott ethernet interfészen.
Egyik részről, már fent írták, hogy ez a VMWare Fault Tolerance, nem pedig a Live Migration.
Meglepne, ha tényleg erre lenne szükséged.
Már csak azért, mert akármi is legyen desktop Windows-on, azt havonta patchelni kell, az amiatti kiesés pedig nagyságrendekkel haladja meg a Quick Migration miattit, szóval nem áll össze a kép.
Javaslom, hogy mondd el előlről, hogy mid van, mije fáj most, mit várnak tőle: rugaszkodj el még a megoldástól, hogy érdemben tudjunk segíteni.
Üdv,
Marci
"Javaslom, hogy mondd el előlről, hogy mid van, mije fáj most, mit várnak tőle: rugaszkodj el még a megoldástól, hogy érdemben tudjunk segíteni."
+1
Ilyen cuccok esetén örülj ha nem USB-n kell mozgatnod a VM-eket.
A live migration megoldások csak annyira akasztják meg a rendszert amíg egy utolsó delta szingront átvisznek és etherneten átjelentik a gépet a másik hostra. Ez shared storage esetén 1-2 mp, egy ilyen felállásban 5-10 mp lehet max amíg elhallgat a gépet de utána megy tovább a buli.
:)))
Hyperv Replica-nak nézzen utána.
Nem kell AD.
Replikához nem kell AD, live migration-höz kell.
Replikánál x percnyi adat elveszik (alapértelmezetten 5) átálláskor és bár filerendszer szinten tranzakcionálisan konzisztens állapot van, de úgy indul a vm, mintha szabálytalanul állt volna le, hiszen memóriatartalom nem megy át replikációval.
Szóval a két technológia teljesen másra való, igényektől függ, hogy melyik a jó, vagy lehet ötvözni a kettőt failover clustering-ként.
Hyperv esetén shared nothing esetén sem akad meg a VM. Amig másolja a hdd tartalmát egyik gépről a másikra, addig ugyanúgy üzemel tovább a forrás gép, akárcsak a memóriatartalom átmásolása idején (jegyzi, hogy mi változik másolás közben mind hdd, mind memória kapcsán).
Messze nincs az 5-10 mp leállás, 1-2 mp tapasztalatom szerint (még ping sem veszik el) és nem kell ehhez shared storage. Csak ki kell várni, mig átér a másik gépre minden adat.
Ez a szándékos migrálás esetén oké, de a kérdező "HA"-t írt, tehát akkor mi van, ha a vm.et futtató gépből nemes egyszerűséggel kihúzom mind a kettő tápkábelt? (mert ugye HA-nak dupla táp nélkül nem (sem) állunk neki...)
Nem mondtam, hogy ez HA, a megakadásra és a shared storage-re reagáltam.
Sziasztok, Compute esetén nem Létezik szinkron HA. Rettentően drága. A felsorolt hardverekkel nem is megoldható. Nincs memória szinkron, RDMA.
Ilyen clusterből compute szinten csak failovert lehet csinálni. Disaster Recovery. Azaz helyreáll a tartalék node-on. Ezt lehet elérni. A halott node memóriájába került, de még diszkre ki nem írt adat sorsa gyakorlatilag kuka.
Üdv,
[Feliratkozás]
+1
"I'd rather be hated for who I am, than loved for who I am not."Nem azt akarom, hogy más oldja meg helyettem, jelenleg is tesztelek megoldásokat, most éppen Hyper-V-vel. A kérdés/kérés arra irányult, hogy ezzel a felállással lehet-e ilyet csinálni? Vagy ha nem, akkor mit lehet kihozni belőle? Vagy ne akarjam "megerőszakolni" a fizikát?!
További eszközök beszerzése nem lehetséges, ebből a büdzséből kell építkezni. A projekt egyelőre tanulás céllal megy, szeretnék kicsit képbe kerülni, főleg a hyperconverged téma érdekel. Emiatt is kezdtem el foglalkozni vele.
Én biztosan nem oldom meg helyetted.
Főleg azért, mert a feladatot nem ismerjük, homályosan sem.
Eddig csak egy ismeretlen feladatra megoldásnak vélt dologgal kapcsolatos kérdést hallottunk...
Üdv,
Marci
Nem tudom ezt, hogy lehetne leírni még... Melyik része nem világos?! Van 2 gép, ezen szeretnék valamilyen virtualizációs megoldást futtatni, ami lehetővé teszi, hogy a vendég rendszer az egyik gép kiesése esetén automatikusan átköltözzön a másikra. Lehetőleg megállás nélkül, vagy minimális kieséssel, beavatkozás nélkül.
Nem kötelező válaszolni! Elég lett volna, ha linkelsz pár MSDN oldalt, vagy más cégét, hogy tessék nyomorult olvassál!
Köszi a segítséget!
Mi fut rajtuk, milyen folyamatban milyen szerepet töltenek be?
Mi indokolja ezt az extrém magas rendelkezésre-állás igényt?
Mennyi pénz múlik azon, ha nem magas a rendelkezésre állás vagy milyen egyéb kockázat (életveszély? tömeges felhasználói elégedetlenség?) van?
Mi köti a dolgot Windows 10-hez?
Miért akarod ezt az egészet: Éles feladat ez? Hobbi? Tanulás?
Szóval kéne pár konkrétum a feladatról, nem pedig az Általad választott megoldás kivitelezésének a feladatáról. Ez utóbbiról is lehet beszélni, később.
Üdv,
Marci
Mi fut rajtuk, milyen folyamatban milyen szerepet töltenek be?
Jelenleg Hyper-V 2016. De ez az egyik kérdés, hogy mivel?
Mi indokolja ezt az extrém magas rendelkezésre-állás igényt?
A feladat megoldásához miért kellene tudni?
Mennyi pénz múlik azon, ha nem magas a rendelkezésre állás vagy milyen egyéb kockázat (életveszély? tömeges felhasználói elégedetlenség?) van?
Megint nem releváns infó.
Mi köti a dolgot Windows 10-hez?
Ebből van 2 OEM licenc a fiókban.
Szóval kéne pár konkrétum a feladatról, nem pedig az Általad választott megoldás kivitelezésének a feladatáról. Ez utóbbiról is lehet beszélni, később.
Nincs általam választott megoldás. Keresem a lehetséges megoldást!
Mi fut rajtuk? - Mármint a Windows 10 guestekben mi fut? Nem kell szó szerint érteni, de ahhoz, hogy a magas rendelkezésre állásra megfelelő megoldást válasszunk, sokkal többet kell tudni.
"A feladat megoldásához miért kellene tudni?"
Mert a feladat nem a live migration vagy a fault tolerance. Ezek eszközök.
A feladat az, ami miatt az egészet csinálod.
És ha a budapesti reptér közelkörzetét kiszolgáló radarrendszer kiszolgálását végző alkalmazás magas rendelkezésre állását kell megoldanod, akkor más a megoldás is, mint ha isiben hallottál a HA-ról és egyszer végre szeretnél látni is olyat.
Üdv,
Marci
Egyszerűsítem, az általad említett radarrendszer kiszolgálását végző alkalmazás magas rendelkezésre állását mivel oldanád meg? Lehet nekem is megfelel.
Az isiben hallott HA-t szeretném kipróbálni, mivel kezdjem?
Úgy hallottam, kiszálltál.
Üdv,
Marci
Várok még kicsit, hátha érkezik még valami ajánlat. Közben újrarúgom a "Feladatátvevőfürt-kezelőt".
-1
Én kiszálltam. Ez a stílus nem megfelelő.
A hyper-v free* jó lesz neked annyira amennyire. Ebből többet nem lehet kihozni. Többhöz pénz fog kelleni.
Esetleg proxmox meg drdb ha okosságokkal lehet még próbálkozni.
Én is kiszálltam :-D A kukacoskodáson kívül sok értelmes hozzászólás nem érkezett... A tiédben legalább említesz 2 lehetséges eszközt. Ill. előtte volt még egy oVirt is.
Véletlen épp eszembe jutott, mit mondott volna erre Poncius Pilátus a Brian életéből.
Üdv,
Marci
Onelzet, batolsag, vagy inkabb meleszseg?:)
Jut eszembe, 2 OEM licenc nem elegendő a feladathoz, ha a virtuális gépeket akárhogy is, de mozgatni akarod a hosztok közt.
Ha két virtuális Win 10-et két hoszt közt akarsz mozgatni, úgy OEM-ből 4-re van szükséged.
"Megint nem releváns infó." De igen, kockázatarányos védelem miatt.
Üdv,
Marci
Van 2 gép, ezen szeretnék valamilyen virtualizációs megoldást futtatni, ami lehetővé teszi, hogy a vendég rendszer az egyik gép kiesése esetén automatikusan átköltözzön a másikra.
Már bukta! Ha össz-vissz van két géped, és semmi más, akkor a büdös életben nem lesz automatikusan redundáns és konzisztens rendszered. Ez elméletileg van kizárva. A fogalom, amiket keresel: quorum, split-brain.
Vagy arról kell lemondanod, hogy nem lesz adatvesztésed (szerintem ezt akarod a legkevésbé elengedni), vagy a teljesen automatikus működésről, vagy arról, hogy a két gépen kívül semmid nincs: kell egy harmadik eszköz, vagy egy gép, vagy egy külső storage.
Mondjuk tök jó, hogy ezt kb. évente kell elmagyarázni valami cluster-newbie-nak... :(
Nem kell! Elég lett volna ennyi is, hogy 2 géppel ne akard megváltani a világot. Vagy az előző magyarázatot belinkeled, az is elég. Tudom használni a keresőt is, de erre vonatkozó témát, ahol hasznos infót találtam volna, nem leltem.
https://hup.hu/node/158841#comment-2219747
Volt quorum, esély sem volt split-brain állapotra.
Csak megfelelő szoftver és hardver kellett.
Hagyjuk már ezt, hogy _általában_ nem lehet két node-os cluster!
Lehet, működött is, egy részük a kezeim közt, jó tíz éven át.
Csak ugye ennek voltak hardveres vonzatai is.
De ugye tudod, hogy a quorum azt jelenti, hogy "döntés képes többség"? A kettő ezt hogy oldotta meg? (nem kötözködésből írom, érdekel). Valami külső eszköz kellett hozzá gondolom. (pl. egy SAN, aki látott rajta valamit, az tudta, hogy ő még játékban van, stb.)
Igen, egy közös elérésű, általában használaton kívüli diszk.
A DEC egykori és néhai mérnökeinek valahogy el tudtam hinni, hogy ez így működik.
Volt olyan is, hogy két gép közé olyan SCSI doboz volt kötve, amelyik két gép kiszolgálására alkalmas volt. Ha elment a CI kommunikáció, akkor próbálták lockolni a quorum diszket. Amelyiknek sikerült, az élt tovább.
Normál esetben persze valami olyasmi doboz volt köztük, amit ma NAS-nak neveznének. (HSC, HSD, HSJ stb.)
Magyarazhatod a vegtelensegig, akkor sem lesz igaz, ld pl STONITH.
A masik, amit szinten sokan elfelejtenek, hogy a quorum fencing nelkul gyakran semmit sem er: hiaba dont a tobbseg, ha azt nem tudja ervenyre juttatni.
Találtam egy jó dokumentumot, ebben egész jól le vannak írva a dolgok. Quorum, STONITH...
Na azt hiszem a Microsoft elesett: "Microsoft Management Console működése leállt" A program helyes működése hiba miatt megszakadt. A Windows bezárja a programot és értesíteni fogja Önt, ha megoldást talál a problémára. Cluster létrehozásakor...
A Xenserver-nek adnék egy esélyt, illetve van vmi patch-el verziója a Xen-nek (aminek a neve nem ugrik most be),
itt a VM gyakorlatilag mindkét gépen párhuzamosan fut.
Szerintem a HA-Lizard-ra gondolsz. Ez lesz szerintem a következő versenyző.
xen ganeti volt amire gondoltam
proxmoxhoz sem kell feltétlenül 3 node, lehet csökkenteni a quorumot.
Persze nem túl jó ötlet, nem véletlenül találták ki ezt így.
A kvm live migration-höz kell egy HA tároló, tipikusan egy NAS.
Alternatíva lehet persze egy glusterfs-t összehozni a 2 node-on, de ez se nem egyszerű se nem túl robusztus megoldás.
Az biztos hogy nem kezdőnek való.
--
Gábriel Ákos
Egy glusterfs-es példa:
https://logout.hu/cikk/vmware_es_glusterfs/bevezetes.html
--
Légy derűs, tégy mindent örömmel!
Hello,
Sajnos 2 gépből nem lesz HA de FailOvert simán össze tudsz rakni, ajánlom a Proxmox-ot egyszerű és nagyszerű, és később könyeddén tudod bővíteni valódi HA-ba min3 gép.
Most ezen gondolkodtam, hogy a fent említett két gépre teszek Proxmox-ot, és ezen fog futni a vendég Windows. Aztán később azt a gépet, amin jelenleg fut, felveszem 3. node-nak, ez egy gyengébb vas, nem fog futni rajta semmi, csak a quorum miatt.
Viszont így felvet még egy kérdést, a shared storage... Azt láttam, hogy a Proxmox-ban van Ceph is, az jó lesz alá vajon? Így lesz egy hyperconverged cluster.
És veszel még két Windowst?
Üdv,
Marci
Veszek! Neked is kell egy? Tudomásul vettem a lentebb leírt licenc dolgot. Ebben az esetben 1 VM lesz, és akkor stimmel a 2 licenc a 2 node-hoz.
ha nincs szukseged az automata pakolgatasra, hanem eleg ha kezzel teszed-at/inditod-el a vm-et, akkor eleg a ket node. a shared storage meg megoldhatod barmivel, vagy kulso nas vagy drbd. (cephet is hasznalhatsz, a cephmon-nak viszont kell a 3 node, de osd-t tarthatod a csak a ket host nodeon)
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
A HA-t két node-al nem érdemes egy mondatban emlegetni.
Proxmox+ceph jó lehet (3 node, vagy legalább egy quorum biszbasz mellett). De az automata pakolás Proxmoxnál asszem fizetős fícsör. Fixme!
---
"A megoldásra kell koncentrálni nem a problémára."
VirtualBox-ban összeraktam egy 3 node-ból álló cluster-t, Ceph tárolóval. Idáig jól néz ki a dolog, még a failover-t kellene letesztelnem.
Kernelbe gyógyított heartbeat nélkül sem érdemes "HA"-t emlegetni... :-P Na ez körülbelül olyan túlzás, mint hogy két node-ból nem lehet ha-fürtöt csinálni. Lehet, csak vannak hátulütői, amit alaposan át kell gondolni, hogy vállalható-e, vagy sem.
Sziasztok,
Én is cluster építésére adtam a fejem. Egyelőre semmi elvárás, csak labor szinten. A választott disztribúció RedHat.
A tervek közt elsősorban a HA megoldások megismerése szerepel. Szeretném megismerni a technikák alapjait, gondolva itt a szinkronra, erőforrás managementre és többire. (Corosync, Pacemaker, PCS, RDMA) erőforrások, DLM, CLVMD, stb..
Fencing, és Stonith megoldások. Alapból egy shared storage(SAS SAN) alpon nyugvó adat kiszolgáló(block eszköz szinten, pl. iScsi) építése a cél. Elsősorban doksikat, illetve a témával foglalkozó szakirodalmat keresek. Akinek van tapasztalata benne szívesen meghalgatnám.
Köszi,