Fórumok
Sziasztok,
Adott 2 db, viszonylag combosabb kiépítésű Dell PowerEdge R520-s szerver, belső PERC RAID vezérlőkkel, közös storage nélkül.
Szoftveres oldalon (hypervisor-nak) 2 db Server 2012 R2 Standard vagy free ESXi 5.5.
4.0-s ESXi-eken levő gépeket kellene migrálni, de mivel a Server 2012 Standard már tartalmazza a Failover Clustert és a HyperV már SMB 3.0-n is képes tárolni, elgondolkodtam azon, hogy ezt vajon magas rendelkezésre állással, shared storage nélkül meg lehetne oldani.
Van valakinek ilyen irányú tapasztalata?
Hozzászólások
Linux + drbd vel megoldható. Nem tudom a vmware/windows támogat-e hasonlót.
Fedora 20, Thinkpad x220
A Windows 2012 R2 lesz a jó megoldás Neked.
Magas rendelkezésre állás shared storage nélkül meglehetőst érdekes elképzelés. Hogyan is venné át a kieső node szolgáltatását a működő node, ha a kieső node-on futó guest adatai nem shared storage-n vannak meg? A már emlegetett drbd erre alkalmas eszköz lehet, pláne hogy tud master-master módban is gurulni - viszont a vmware saját kernelt használ. Nem mondom, hogy lehetetlen hackelni hozzá drbd modult, de annyira azért nem is lesz egyszerű.
Ami működő megoldást én erre láttam, az egy két gépes ProxMox cluster volt: egy viszonylag kis saját kötet, majd drbd-n a "nagy" lvm. Itt ha egy guest létre jött, akkor az akár live migration módon is gyorsan áttehető volt a két gép között, mert csak a konfig + memória adatoknak kellett átkerülnie egyik node-ról a másikra és máris futott tovább a guest, szinte csuklás nélkül.
Ahol ez a felállás macera tud lenni, az az, amikor emergency poweroff van mindkét node-on. Ilyenkor a drbd-n lévő adatok egyik fele az egyik node-on érvényes, a másik fele meg a másikon, mert ugye amelyik guest az egyik node-on fut, ott az az érvényes adat, ami esetleg nem ért át a másik node-ra, viszont a másik node-on futó guest adata a másik node-on érvényes és esetleg nem ért át az egyik node-ra. Ilyenkor van szívás, mert mindkét helyen fel kell hozni standalone-ban a drbd-t, majd ahol kevesebb a mentendő adat, ott lementeni az érvényesnek tekintett adatokat. Ezek után jöhet az összeszinkronizálás úgy, hogy ahonnan mentettünk, az a kiesett node, oda kell mindent visszahozni a másikról - majd ha ez megvan, akkor a mentett területet vissza kell állítani, hogy mégis az itt érvényes jusson vissza még a másik gépre is. Ez ellen úgy lehet védekezni, hogy nem egy, hanem két drbd kötet készül: az egyiken az egyik node guest-jei vannak, a másikon a másik node guestjei. Ilyen esetben nem kell mentegetni, mert az elso drbd kötetet úgy kell szinkronba hozni, hogy a node1 az érvényes és a node2 a kiesett tag, a második kötetet meg pont fordítva: a node2 az érvényes, a node1-et kell szinkronizálni. Persze ennek is ára van: az egy közös nagy tárterület szétesik két kisebbre, így ha kell egy nagyobb terület, akkor azt esetleg egy helyről nem tudjuk kiszakítani, ha viszont két helyről kell merítenünk, akkor pont az előbb leírt előnyt veszítettük el, illetve a másik fele, hogy ha később a terhelés elosztás alapján az jön ki, hogy pl. a guest3-at mégis inkább a node1-re kéne tenni, akkor megint probléma lesz abból, hogy a drbd2-n lévő lvm2-n van az adata. Szóval azért ez sem tökéletes megoldás...
"Magas rendelkezésre állás shared storage nélkül meglehetőst érdekes elképzelés. Hogyan is venné át a kieső node szolgáltatását a működő node, ha a kieső node-on futó guest adatai nem shared storage-n vannak meg?"
Nyilván úgy, ha (konzisztensen) tükrözve vannak az adatok mindkét node-on.
Köszönöm a kimerítő választ!
Azt ugye vágod, hogy ez az architektúra milyen performanciát fog eredményezni? A diszk latency a béka segge alatt lesz.
az uj proxmoxban mar van ceph tamogatas is: a proxmox node-ok a master (*), osd meg lehet kulso gep de akar sajat maguk is.
szvsz a split brain annyira nem veszes: hacsak nem vagy olyan marha, hogy egy vm-et ket helyen is elinditasz, a ceph monitor majd megoldja a szinkronba hozast, hogy melyik chunkot kell hova masolnia.
* itt is kell a paratlan szamu gep a szavazashoz, de meglehet csinalni hogy ket gep futtatja a vmeket tobbi gep csak a szavazasban vesz reszt.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Fájintos.
A kundénak 2db gépen van.
Prox, ceph és egyéb baszása, minimum 5db gép.
szuper. ezt elmondtad a proxmoxosoknak is?
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Bassza+!
Igazad van. 2 node-on is lehet futtatni a nagyon nem javallott, minimális 3 node-os konfigot.
De őszintén. Csak olvasgatsz, vagy élesben használod is ezt a konfigurációt?
gyoztel!
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
valszin neki van gyakorlati tapasztalata... te hogy allsz ezzel?
ha az a gep hal el, amin a ceph-mon fut, akkor mit csinalsz? persze, azt is tukrozod, es majd elinditod a masik oldalon, igaz? ha meg nem, akkor 2 monitort _nem_ ajanlott futtatni, egy jo kis split-brain utan bucsut inthetsz (legalabb) a delta alatt letrejott adatoknak.
" a ceph monitor majd megoldja a szinkronba hozast"
Jok ezek a finom jovo idok... es ha nem? Es ha igen, akkor mennyi ido alatt tudja abszolvalni? Mennyi ido a teljes helyreallas?
--
Elvileg VMware-hez is létezik egy saját VSA cluster appliance (https://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vsa.doc/GUID-4E…) ami megoldja az ESXi host-ok local storage-ainak egymásra tükrüzését, így akár a VMotion is működhet.
ui.: Részletes tapasztalatom (még) nincsen róla, de érdemes lehet megnézni
min 3 gep kell hozza.
es a VSA mar EOL, vSAN van helyette, amihez minimum 4 gepet ajanlanak (nalam megy prodban, szuper)
+1
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
De mit akarsz igazából? Mi az minek redundáns elérhetőséget kell biztosítani?
ERP, de nem alkalmazásszinten.
A hypervisor elérhetősége lenne jó, ha redundáns lenne .
Ha rendundáns rendszert akarsz ahhoz kevés egy hypervisor, az csak arra lehet jó, hogy ha az egyik oldal elesik akkor újraindítja a másik oldalon, ehhez az async data replikációt a Windows képes megcsinálni, így a storage már nem létkérdés.
DRBD jó megoldás, ha nem ragaszkodsz esxi vagy hyperv-hez nézd meg a ganeti-t: linux-kvm-drbd-livemigration. Stabil, van scriptelhető parancssoros interface, és csili-vili webes felület(kis kézimunkát igényel a telepítése).
--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...
Hello,
Ezt érdemes elolvasni: http://aka.ms/hup-hvsmb
Amit szeretnél, ahhoz kevés a két host: az SMB3 cluster nem lehet azonos hardveren a Hyper-V host clusterrel.
Egyébként 2 szerverrel mit oldasz meg vele? El tudnád mondani, hogy minek nőne a rendelkezésre állása ettől és hogyan?
Üdv,
Marci
" az SMB3 cluster nem lehet azonos hardveren a Hyper-V host clusterrel."
Köszi, ha ez így van, akkor ezzel válaszoltál is a kérdésemre.
Azt akkor rosszul tettem, mert még mindig nem értem, hogyan növelnéd ezzel a rendelkezésre állást. :)
De ha el nem is mondtad, van egy sejtésem.
Olvass utána a Hyper-V replica megoldásnak, esetlegesen kiegészítve Hyper-V recovery managerrel.
Üdv,
Marci
Remek sejtés, utánaolvasva, a lehetőségekhez mérten valószínűleg ezzel tudom a legegyszerűbben növelni a rendelkezésre állást.
Thx :)
Szívesen!
Üdv,
Marci
Teljesen mindegy, milyen technologiat hasznalsz, nekem a kovetkezo a tapasztalatom:
Nem javaslom, hogy 2 gepbol kozos storage nelkuli clustert epits. Miert? Mert ket gep eseten nem tud tobbsegi szavazat arrol kialakulni, hogy kie a kozos eroforras (ezt hivjak quorumnak), ergo eloallhat, amit split brainnek hivunk, hogy a ket gep mindegyike nem tud a masikrol semmit es azt gondolja, hogy o a master. Ez IP cimek eseten meg kevesbe kritikus, mivel ott max nem mukodik a szolgaltatas, de adat eseten inkonzisztencia fog fellepni, amit nem fogsz tudni egykonnyen osszefesulni.
A masik amivel ismerkedj meg ezzel kapcsolatban, az a STONITH, avagy lojuk fejbe a hibas node-ot. Ezt legtobbszor a hibas node remote management konzoljan vagy egy dedikalt STONITH-device-on keresztul mukodik, azonban ez szinten csak minimum 3 gep eseten tud mukodni, mivel 2 gep eseten egymast fogjak leloni, szerencsetlen esetben egyszerre.
Elgondolkozhatsz azon, hogy bevonsz egy harmadik cluster membert, pl a default gatewayt, de azt tartsd szem elott, hogy a halozati eszkozok elsodleges feladata nem az, hogy pingre valaszoljanak, igy terhelt CPU eseten siman hiheted azt, hogy meghalt, holott csak dolgozik. Ezen felul eloallhat az az allapot, hogy mindket gep latja a gatewayt, de egymast nem, innentol kezdve megint split brain allapotban vagy.
Ezek sajnos alapigazgasok a cluster epitessel kapcsolatban es nem is tudod athagni: amit nem tudsz, azt nem tudod, a masik node attol hogy elerhetetlen, siman mukodhet es generalhat adatot. Ha ket gepbol epitesz barmilyen kozos adattal rendelkezo clustert, eroteljesen haladsz abba az iranyba, hogy a rendelkezesre allasod alacsonyabb legyen, nem pedig magasabb.
Aki mast allit, az vagy nem latott meg eleg clustert osszeborulni, vagy tud valamit amit en nem es ossza meg velem.
+1!
(És épp ezért lehet jó a Hyper-V Replica)
Üdv,
Marci
Egy hét távlatában abszolút pozitív tapasztalatom van a Replica-val és 2012 R2 HyperV-vel kapcsolatban is, köszönöm a tippet! :)
Remélem, 5 év távlatából sem romlik majd a véleményed ;-)
Üdv,
Marci
Egy technikai jellegű kérdés: úgy tűnik, hogy a forrás hardverváltozásai (plusz cpu magok, memória) nem kerülnek át a replikára.
Van ötleted arra, hogy ezek is replikálódjanak?
Hello,
ilyen mély technikai ismereteim nincsenek. Javaslom, hogy a kérdést tedd fel a közösségi terméktámogatásnál a Server Virtualization témakörbe: http://social.msdn.microsoft.com/Forums/en-US/home?forum=servervirtuali…
Üdv,
Marci
A 2 gep valoban nem jo megoldas, de bizonyos esetben (peldaul virtualis gepek eseten) kielegito lehet.
Marmint kezi failoverrel, ugy erted. Vagy ha van mentesed es splitbrain eseten backupbol allsz vissza.
Hello,
Windowson nem értem, mi tehet szükségessé splitbrain esetén restore-t, ami a nélkül nem fordulhat elő. Tudsz rá példát?
Üdv,
Marci
Nem azt mondta hogy a backup segít a splitbrainen, hanem azt, hogy ha spb van akkor legyen backup amit vissza tud tölteni. :)
Csakhogy én meg azt kérdeztem, hogy Windows-on splitbrain esetén mi következhet be, ami olyan sérülést okoz a szolgáltatás adataiban, hogy visszatoltest tesz szükségessé. Erre kértem példát, mert hirtelen nem jut eszembe ilyen eset.
Rövidebben: Mi történhet Windowson spb esetén, hogy adatot kell visszatolteni?
Üdv,
Marci
Replikált VM itt egyébként automatikusan elindul?
Hopp ezt a kérdést nem értem. Megpróbálom megfogalmazni:
-az érdekel, hogy egy VM cluster erőforrásként automatikusan el tud-e indulni a másik hoston egy nem tervezett failover esetén?
-vagy az, hogy két standalone (nem cluster) host közti Hyper-V Replica esetén automatizálható-e a site failover?
Üdv,
Marci
A másodikra vonatkozott a kérdés.
Abban biztos vagyok, hogy távolról indítható, a kérdés, hogy janoszem által felvázoltak tükrében érdemes-e.
Alapból a site failover egy kézzel indított folyamat.
Mivel az indítást megteheted scriptből is, így megvalósítható az automatizálás is.
Olvasnivaló: http://blogs.technet.com/b/keithmayer/archive/2012/10/05/automate-disas…
A Te környezeted esetében én személyesen győződnék meg az adott vas tényleges haláláról, indíthatatlanságáról, zárnám ki a véletlen elindulását és végezném el a site failovert.
Üdv,
Marci
A hardveres STONITH 2 géppel is megoldás a split-brainre. Annak igen kicsi az esélye, hogy egyszerre lőjjék ki egymást, hiszen ha az egyik picit is előbb áll meg, akkor nincs aki a másikat kilőjje, megakad a folyamat.
A redundáns kommunikáció és a hardveres STONITH ami 2 géppel nagyon fontos, ha az megvan, akkor szerintem okés a dolog.
Igen? Nekem anno amikor kezdtem a 2. probalkozasra sikerult olyat eloideznem hogy egymast lovoldozte ki a ket gep. Probald meg a ketto kozott kihuzni a halokabelt, esetleg egy kis packet losst betenni, ne adj isten szetterhelni a gepeket CPU-ban vagy IO-ban, kivancsi vagyok, meddig tartod fenn az allitasodat. Nyilvan nem akkor fog eloallni, amikor laborkorulmenyek kozott vadi uj kabelekkel vadi uj vasat tesztelsz, hanem mondjuk 2 ev mulva amikor valaki a Te geped folotti gepet rackeli ki es veletlenul sikerul meglazitani a mar elgyalazott kabelt.
Hát nyilván fejre lehet állítani ezt is, ahogy a quorum-os clustert is, egyik sem véd minden hiba ellen. Vannak 2 node-os és quorumos DRBD clustereim is, volt már mindenféle zűrzavar itt is ott is, nem mondanám, hogy a quorum silver bullet. Inkább a redundáns heartbeat és a jól beállított STONITH a lényeges.
Azért csendben megsúgom, hogy bírtak már emberek értelmes cluster szoftvert írni, aminek nincsenek ilyen dolgai, hogy "egyik sem véd minden hiba ellen".
Az az elvárás szerintem abszolút reális, hogy bármilyen egyszeres hiba ellen védett legyen a cluster (azaz bármilyen egy darab alkatrész megdöglik, bármilyen kábel elpusztul, bármelyik betáp megmurdel), a szolgáltatás menjen tovább. Az is elvárás, hogy semmilyen esetben (többszörös hiba esetén) se lehessen split-brain, azaz inkább álljon le mindkét node, minthogy párhuzamosan menjenek egymás mellett.
Egy korrekt, külső diszkes SCSI3 rezerválásos quorum abszolút korrektül képes ezt a funkciót ellátni.
Emberi hiba..? Vagy 1% network pkt loss, 10% IO teljesítmény csökkenés egy diszk miatt - mind okozhatja az alkalmazás bizonyos mértékű leállását, ami végsősoron a HA, a cluster kudarca lesz.
A HA soha nem fekete-fehér, bizonyos szkenáriókra felkészülsz és bízol abban, hogy a többi nem üt be..
Varj, nem azt mondta, hogy az alkalmazas nem allhat le. Azt mondta, hogy ha hiba van, inkabb legyen egy komplett leallas, minthogy a hibas rendszer tovabbra is mukodni akarjon.
Egy cluster eseteben fontosabb az integritas, mint az elerhetoseg (rendelkezesreallas).
--
A hibas mukodes nem noveli a rendelkezesre allast egy picivel sem.
De nem is kell neki. Viszont egy serult integritasu rendszer talpraallitasa sokkal nagyobb kiesest okoz, mint egy tobbe-kevesbe tisztan leallt cluster ujra osszelovese.
--
Azaz a rendelkezesre allas az integritas biztositasaval erheto el, igy nem fontosabb, hanem a ketto osszefugg.
Igen, de a merleg az integritas fele dol el. Vagyis, amikor azt kell eldonteni, hogy legyen elerheto a rendszer, vagy legyen stabil az integritas, akkor mindig a masodik fele kell donteni.
--
"hardveres STONITH"
Erre mondanál egy példát?
IPMI
Harmadik cluster member nem feltetlenul csak annyit jelent, hogy pingre valaszol, lehet quorum-al biro de szolgaltatasban nem reszt vevo node is. Vagyis adatot nem szinkronizal, nem tudja atvenni a szolgaltatast, de quorum szavasban tud segiteni a masik 2 node-nak hogy meglegyen az egyertelmu tobbseg. Erre pedig nem kell nagy eroforras, akar elferhet egy masik gepen is ami egyeb feladatot lat el.
Nem építettem még semmilyen clustert, még csak ötlet szintjén merült fel. Jókat mondasz, de nekem az a bajom, hogy a közös storage egy SPOF. Lehet venni nagyon jó rendelkezésre állású és redundanciát is tudó storage-et, de az jó drága. Ha nem nagyon kritikus dologról van szó, akkor még akár a manuális failover is teljesen jó lehet, és nincs split brain probléma.
--
Igy van, nagy rajongoja vagyok a kezi failovernek, plane azert mert annyival problemamentesebb es legtobbszor senkit nem vag agyon egy 10 perces downtime.
EGYETÉRTEK.
Sajnos az eszetlenül konfigurált, szétszállt clustermegoldásokból felállás sokkal több időt vett már el az életemből mint a manual failover.
És a legtöbbször nincs is rá szükség, szükségtelenül bonyolítja az üzemeltetést, roppant kellemetlen problémákat generálva (pl. spb effektus).
Hajnali kettőkor is a gépek mellett ülsz? Vagy még nem üzemeltettél magas rendelkezésreállást igénylő rendszert?
Nem kell, hogy hajnali kettő legyen ahhoz, hogy probléma legyen egy átállás levezénylése.
Bőven akad olyan elfoglaltság az ember életében, amikor alkalmatlan ilyennel foglalkozni. Persze 1 ember nem ember, de főleg "egyszerűbb" környezetek esetén azért nem ritkán előfordul, hogy nincs kompetens helyettesítő és mindenki bízik abban, hogy remélhetőleg nem történik semmi a távollét/elérhetetlenség alatt...
Akár az is jobb megoldás lehet, hogy a két vas közül az egyik hidegen pihen, gond esetén a vinyókat kvázi bárki át tudja tenni.
Nyilvan nem, erre valo a monitoring rendszer ami csipog hogy hello, para van. Felkel az ember es megreszeli. Ugye ertelmes helyeken van out of bound management amivel meg lehet olni a gepet ha kell. Amikor meg nem en nalam csipog a keszulek, akkor mas zsebeben csipog.
És a monitoring rendszer magas rendelkezésre állását mi vagy ki biztosítja?
Azért ha jobban belegondolsz... hat kilences SLA-t ritkán látni. A 98-99%-os rendelkezésre állás meg elég sok kiesést elbír.
:)
Hogy tobb van belole. :) Komoly gondolt helyeken sztem erdemes legalabb egy off site monitoring rendszert uzemeltetni pluszban. Kb semmibe nem kerul, egy kisebb virtualis gep is el tudja latni a feladatot.
meg tudom számolni kb egy újamon, hogy az elmúlt években összesen hányszor állt le a monitoring rendszerünk
Senkit nem erdekel az, hogy hanyszor allt le valami. Egy cluster eseteben ha valamibol csak egy van, az SPOF, mert ha egyszer elszall akarmiert, nincs potlasa neki. Es ez nem feltetlen az adott cucc hibaja lehet, ha pl. elszakad a monitoring gep halozati kabele, az is lehet hiba, holott maga a monitoring rendszer granitszilardsaguan fut tovabb a romok felett.
--
J, a monitoring se csodamegoldas, nekem volt mar egy csomoszor, hogy notifikalt, de eppen akkor se tudtam volna erte barmit tenni, ha akartam volna. Egy rendszerben legyen mar annyi automatizmus, hogy legalabb onmukodoen osszeomlik, nem kell meg nekem is besegitenem neki.
Raadasul manualis failovernel a rendszergazda valik SPOF-fe, mert ha barmiert nincs internete, akkor bizony senki nem fog failovert csinalni.
--
Sőt. Csináltam democlustert két barebone-ból, meg külön kis switch, soros kábel HB, miegyéb, aktív-passzív felállásban, drbd, miegyéb. Azzal demóztuk, hogy milyen, ha a cluster egyik lábából kirántom a delejt. Mókának, tapasztalatnak jó volt.
Az éles rendszernél maradtam a kézi failovernél, részben a földrajzi távolság miatt, részben pedig azért, mert felkacagtam, amikor kiszámoltam, hogy hány óra egy év egy százaléka.
A "jó drága" és a "nem nagyon kritikus" túlságosan relatív fogalmak. Célszerű egyeztetni az üzleti oldallal, hogy mennyi pénzért milyen kompromisszumot fogad el.
Manuális failover: honnan hova? Mi van az adatokkal? RTO-t és RPO-t mindenképpen tisztázni kell.
Ez nem akkora probléma, mivel meglepő módon egy HA cluster software-nek nem a szolgáltatás nyújtása az elsődleges feladata, hanem az adatok integritásának megőrzése, a brainsplit helyzet előállásának megakadályozása. Ha másképp nem megy, akkor inkább álljon le minden. Legfeljebb az üzemeltetők elkezdenek gondolkozni némi plusz redundancia előállításán.
BTW, tapasztalatom szerint egy quorum server praktikusabb bír lenni mint egy shared storage-n kialakított lock disk. Egy quorum server jellegéből adódóan garantálja, hogy az a server maradjon talpon, amelynek a hálózati kapcsolatai működnek.
Ave, Saabi.
ilyet (shared storage nelkul) akkor lehet csinalni ha nem allapot szintu a szolgaltatas mint pl mail relay, dns, proxy
ha mar mast akarsz HA-ban oda mar nagyon kell a shared storage
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
Pontosan, ilyen jellegű szolgáltatásokra használtuk (proxy, ERP front-end), így a HyperV Replica megoldotta a kérdést.
- replikálsz egyik vasról a másikra, ekkor RPO praktikusan a replikációs gyakoriság, az RTO annyi, amennyi idő alatt el tudod indítani a replikát
- szoftveres közös tár, stormagic.com ("olcsóbb"), VMware vSAN (mérettől függően olcsóbb lehet ennél egy fizikai redundáns tároló) vagy egyéb hasonló megoldások
Ha "nagy" tároló terhelésed van, akkor biztosan mélyebben zsebbe kell nyúlni (ha GbE nem elegendő).
Persze igaz az, hogy jobb egy fizikai redundáns tároló és/vagy 3 csomópont, de általában a pénzen múlnak a dolgok és lehet kompromisszumot kötni: nem nulla a kavarodás esélye, de azért kellően alacsony, hogy annak a kockázatát be lehessen vállalni (nyilván megfelelő konfigurációval, két switch is alap a vasak mellé, esetleg a vasakat közvetlenül is célszerű összekötni).
Persze mindettől függetlenül nem árt valami normális mentés megfelelő helyre, javaslom a Veeam Backup and Replicationt, ezzel replikálni is tudsz egyébként.
vegyel egy NAS-t/epits valami shared storaget. fillerekbol ossze lehet rakni ha csak tarhely kell, es meg az is jobb megoldas, mint 2 gepbol ganyolni valamit.
nem ertem 2 geppel es az ingyenes esxi-vel mit akarsz csinalni amugy. vmotion nincs, dvs nincs, drs nincs, vcenter nincs...
HyperV lett a megoldás.
Végül a shared storage-t milyen megoldással tudtad kiváltani hogy valóban két node elég legyen?
HyperV Replica-val, az összes free ESXi hosztot migráltuk HV-re.
Migrálást követően ugyan csak két hónapig dolgoztam még az érintett cégnél, de addig hibamentesen működött (az összeomlást szimulálva sem volt gond a replikált VM-ek elindulásával).
DRBD vagy valamilyen ahhoz hasonló megoldással oldják meg az adatok szinkronban tartását? Mekkora forgalom volt a node-okon?