Storage VMWare-hez

Merevlemezek, vezérlők

Szeretnék egy egyszerű VMWare infrastruktúrát, 2 VMWare Esxi hosttal, és egy közös storage-al. Elsősorban arra kellene, hogyha az egyik host gép fizikailag meghal, a guest VM el tudjon indulni a másik hoston. Jó lenne az atomatikus átállás is, de nem legfőbb szempont, ingyenes VMWare-el szeretném megoldani, ha lehetséges. Az sem lenne rossz, ha esetleg a két host egyszerre is tudná használni a storage-ot. Hogy szokás ezt mostanában? Addig már eljutottam hogy valami iSCSI vagy SAS tároló kellene nekem, melyiket jobb? Esetleg konkrét típusok?

  • 8889 megtekintés

( _ventura_ v | 2015. 02. 06., p – 13:01 )

Amit láttam legolcsóbb storage, az synolog 300+AFA ért, igaz csak SATA disket kezel, de abból 8-at, van benne SSD cache lehetőség, valamint 10GbE interface. Szerintem ez egy jó ajánlat érte. Viszont az ingyenes vmware-el sokat nem fogsz kezdeni.

Erről beszéltem:
https://www.synology.com/hu-hu/products/DS2015xs

Fedora 21, Thinkpad x220

Én pénzkidobásnak érzem az összes nem soho/smb kategóriás Synologyt. Gyakorlatilag azt látom, hogy az irodába és otthonra szánt termékeik nagyon jók, de amint fentebb megyünk a rack és szerver kategóriába, már nagyon csalóka a dolog. Laikus azt hinné, hogy "storaget" vesz, ráadásul Synology felirattal, de ezek csak mezei PC-k, szép házban, intel cpu-val (a rackeseknél), 1db tápegységgel. Akkor már inkább építenék, vagy ha több pénzem van, akkora a Syonlogynál nagyobb tapasztalattal rendelkező gyártótól vásárolnék (Dell, Fujitsu, HP, IBM, etc.. kinek mi tetszik), redundáns táppal, tisztességes vezérlővel (ami szintén lehet redundáns, ellentétben a synology megoldásaival, ahol nem hogy nem az, de még csak vezérlő sincs, swraid-et használnak). Ha meg még ennél is több pénzem lenne, akkor vásárolnék normális céleszközt.

Persze a DSM jó dolog, de ilyen környezetben szerintem semmi értelme.

FYI van több tápegységgel bíró modell is.
Szerintem ár/érték arányban eléggé jó, ha valaki nem ért hozzá, hogy építsen magának, ebből egészen olcsón meg tudja oldani a tényleges HA clustert.

A legfájóbb pont, hogy nem veszik a fáradtságot a HW raid támogatására.

Nem tartom valószínűnek, hogy publikusan elérhető lenne az árlista.

Nekem az a tapasztalatom, hogy közel sem az EMC a legnagyobb zsebmetsző a tároló piacon, például az itt említett Dell MD tároló 2,5M-ért sem egyértelműen olcsó egy EMC-hez képest (úgy fogalmaznék, hogy ennyi és ilyen lemezzel EMC-t is lehet kapni, de nyilván meg kell nézni a pontos támogatási stb tartalmat adott konkrét esetben).

Köszi a választ.
Jól gondolom, hogy 2 ilyennel HA-t építve megoldható, hogy pl. 8x1TB - 8x1TB -ből 2 VPS kiszolgáló táplálkozik, de úgy, hogy egyik az egyikről, másik a másikról? Így a 2 kiszolgáló nem terheli le diszk téren egymást. Hogy maradjon hely a HA tükrözésre, kevesebb, mint a fele lenne kihasználva.
Ez működik igy?

Kérdés mit akarsz HA-ba rakni. Mert ahogy mondod úgy nem lesz HA-ban a storage. Max a hypervisorok és a VPS-ek, de ehhez nem kell 2 storage. 1 storage + 2 hypervisorral, már könnyen megy a HA, a VPS felé. Storage replikációval (amit nem tudom támogat-e a synology sw-je), pedig egyik storage pusztulása esetén nem lesz gond.

Szerintem sok értelme nincsen 2 storagenak, azért hogy egyik VPS egyiken másik másikon legyen, hacsak nem több száz VPS-t akarsz. :>

Fedora 21, Thinkpad x220

definitely not.
Syno esetén, ha HA-van akkor az egyik Master a másik Slave. a szolgálatás pedig a VIP-IP-n fut.
viszont olyat tudsz csinálni, hogy van 2 iSCSI volume-d, az egyik az első 4 lemezen, a másik a 2. 4 lemezen, így
nem tudnak IO szinten konkurrálni egymással.

Feltételezem egyébként, ha a setup a következő:
6x1T WD black
2xN SSD cache
2xGiga "downlink"
2xGiga Sync

akkor nem lesz IO szintű bottleneck. Ha meg igen, akkor úgyis komolyabb storage kell majd.

Ezek szerint olyan, mint a drdb aktív-passzív felállás, ahol a passzívot sosem tudod használni, csak van és csendben szinkronizál, hogy majd egyszer...talán 5 év múlva szükség legyen rá. Addig meg mennek benne a vinyók, kihasználatlanul (leszámítva a node szinkronizációt).
Ezen kihasználatlanságon szeretnék változtatni.
Nem tudom mennyire jött át az ötletem, kicsit szemléletesebben:
"A" storage 2db lvm vagy partíció vagy iSCSI lun vagy bármi: A1, A2
"B" storage 2db "bármi" szintén: B1, B2

A1-gyel (aktív) szinkronban van B1 (passzív)
B2-vel (aktív) szinkronban van A2 (passzív)

Mindkét node felét aktívan, felét passzívan használom. Bármelyik storage node elhasal, a párja át tudja venni a szerepét. A node passzív fele csak az írást viszi át, ami jellemzően kevesebb, bőven ráér az aktív felét olvasni.

Sosem építettem HA storage-t, de hamarosan elő fog kerülni. Hogyan, mivel lehetne a fentit megoldani? Egyáltalán életszerű amit én erőltetni próbálok?:)

Köszi

nem mondom, h nem életszerű, csak a Syno (és más VIP-IP-t használó megoldás) "elveivel" ütközik,
uis itt éppen az a lényeg, hogy 1 IP van, amire csatlakozol, és ha megáll az aktív master, akkor a backup veszi át a helyét.

Ha két gépes clustered van, akkor pl Ganeti-vel (v egyéb "épített" megoldással) meg tudod oldani gond nélkül, hogy minden virtuális gép tükrözve van, és a "tartalék" gép is aktívan van használva.
Nyilván erőforrás-kihasználás tekintetében jobban jársz, üzemeltetés szintjén nem biztos.

ha valamivel meg tudod oldani hogy egy "lemez" teruletet csak egyik node ir, akkor drbd lehet aktiv/aktiv is.

proxmoxnal pl vm-hez tartozo lvm volumet "kikapcsolja" a sajat manager cucca, igy csak 1 helyen tortenik adott blokk irasa.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( f0xhu v | 2015. 02. 06., p – 13:10 )

A fenti feature-höz azért szerintem kelleni fog egy vCenter. Abban egy DC és benne egy cluster, mert a VM-eidet csak így fogja tudni host kiesése esetén máshol felindítani. VM-ek számától függően azért jó lenne még egy spare host...

A storage-ot vagy FC-n, FCoE-n vagy iSCSI-n el tudod érni, csak a prezentációtól/zónázástól és a storage tudásától függ.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

Nem szeretnék nagy vitákba folyni, de raktál már össze HA proxmox clustert multipath-el, fencing-el, stb?
Én sajnos igen, egész egyszerűen hiába volt ott az új releaseban (is) pl. az ILO2 támogatás, mégsem működött...
A multipath egy más tészta, az sem egy enterspájz megoldás, inkább vízilabdáznék jeges vízben krokodilokkal legközelebb...
A botrányos NFS sebességről nem is beszélnék, ugyanolyan vason ugyanaz a rendszer nagyságrendekkel gyorsabb xenserveren.(tapasztalat)
Aranyos, szép dolog a proxmox, arra hogy fusson rajta 1-2 vm még el is tudom képzelni, de így 2+ év tapasztalattal, én köszönöm de nem foglalkozok vele ennél komolyabban sehol, ahol volt, ott is lecseréltem xenserverre...
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Én jobban favorizálom a webes felületeket, ma már abban szinte mindent meg lehet csinálni. A külön telepíthető kliensekkel csak a gond van (ezt sajnos tapasztalom a munkahelyemen a különböző bankok és más cégek windows-os klienseikkel, na az agyrém).

Köszim, ezt az Orchestra-t majd meglesem.

Egyébként én nem éreztem, hogy a Proxmox lassabb lenne virtualizációban mint a Xenserver. Jelenleg nálunk mind a kettő fut.

( Ritter | 2015. 02. 06., p – 13:30 )

Ingyenes VMWare és jó drága hardver biztos, hogy optimális párosítás?
Szerintem célravezetőbb megoldás ha 2GB-ra darabolt VMDK fájlokat használsz a virtuális gépekhez amiket természetesen helyi háttértárolón tartasz, és ezeket szinkronizálod egy másik gépre. Ha "A" gép megdöglik elindítod a virtuális gépet az átszinkronizált fájlokból "B" gépen.
Arra nem árt gondolnod, hogy a megdöglő host gép kiszámíthatatlan következményekkel járhat a rajta futó guest(ek)re. Hibás állapotba kerülhet a guest és akkor a még valamennyire működő hostról átszinkronizálódik a meghibásodott guest a "B" gépre is. Ezért párhuzamosan szükség van valamilyen snapshot+backup megoldásra is.

Kár ha nem, mert a host rendszerről gigabites hálózaton 20 másodperc alatt átszinkronizálható egy 2GB-os szelet a másik szerverre. Még az egybe több száz gigabyte-os méretű image fájlt folyamatosan lehet szinkronizálni jelentősen terhelve még egy gyors belső hálózatot is, mert a nagy image változásánál lehet szinkronizálni újra az egészet. Így ezt a módszert már nem is éri meg alkalmazni. Feldarabolt 2GB-os vmdk fájlok mellett viszont jól működik, noatime itt is jól jön.

Ilyenkor "szokták" megkérdezni, hogy mennyi idő áll rendelkezésre a helyreállításra? Ha van 1-2 órád (2 évente megy csak szét), akkor felesleges állandó szinkron. A napi 4 mentés (heti 1 full + incr) is elég lehet.

--------------------------------
last project: www.ekaer-feladas.hu

( secretx v | 2015. 02. 06., p – 13:39 )

Egy tól-ig összeget mindenképpen írjál szerintem amennyit rászánnál, mert így nehézkes lesz segíteni.
:)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Nekünk van több Dell MD3200 SAS storage is, nem rosszak, Xenserver-el használjuk őket, megy prímán a HA velük :)
Van egy megörökölt Synology RS812+ -os active/passive cluster, ezt már csak mentésre fogjuk használni.
Relatíve olcsón is megoldható, ha építesz egyet, csak arra figyeljetek hogy az ilyen rendszereknek jellemzően a storage a gyenge pontja, ott fel kell készülni minden negatív dologra (szerintem).
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( hassan | 2015. 02. 06., p – 16:57 )

Ha nem kell HA, vMotion és elég a manuális "failover", akkor két standalone host megfelelő lehet. Storage pénztárcától függően akárt Freenastól kezdve az említett Synologyn át sok minden belefér.

FYI: Synology HA-val is megcsinálja. Teszteltem olyan setup-ot, ahol a két Syno iSCSI HA cluster volt.
Az egyikből kihúztam a delejt, a másikra szó nélkül átállt.
A működés feltételei:
- 2 uolyan Syno (lemezek is azonos konfig! de nem muszáj típusazonosnak lennie, csak méret)
- ennek megfelelő Syno (talán a 2 v 4 eth kell hozzá)

( bognarattila | 2015. 02. 06., p – 17:43 )

Ha nem redundáns tárolót veszel, akkor nem sokat csináltál: hiába van két szervered, ha elérhetetlen az adat. Akkor már jobban jársz egyetlen szerverrel, mert kevesebb a láncszem.

a) redundáns tároló 1,5-2m forinttól alatt ne reménykedj, vSphere Essentials Plus célszerű (közel 1,1m)

b) két szerver merevlemezekkel, vSphere Essentials + Veeam Backup and Replication (Essentials) replikálja (a kettő ~350e) a VM-eket, itt előfordulhat adatvesztés.

Mind az a), mind a b) variációt meg lehet valahogyan csinálni ingyenes ESXi-vel, de elég sokat kell vele dolgozni és nyilván lesznek korlátai a megoldásnak.

Valaki biztosan Hyper-V-t is fog javasolni, ingyen van.

( zrubi v | 2015. 02. 06., p – 22:35 )

Szeretnék egy egyszerű VMWare infrastruktúrát, 2 VMWare Esxi hosttal, és egy közös storage-al.
...ingyenes VMWare-el szeretném megoldani

több probléma is van ezzel:

- 2 node-os cluster nagyon nem ideális. 3+ node-tól van értelme ilyesmit csinálni szerintem.
- Az ingyenes ESXi nem támogat semmilyen közös storage megoldást.

Tehát vagy mindenképp költened kell rá nem keveset (storage + VMware licenc) vagy valamilyen fapados megoldást választasz. (tehát neked kell összebarkácsolni)

ingyenes ESXi esetén a kezed eléggé meg lesz kötve, mert minden értelmes (cluster) megoldás licenc + vCenter 'köteles'.

Viszont bámilyen technikai tervezés előtt világosan kell(ene) látni a célokat:

- hardverhiba esetén mekkora kiesés engedhető meg a szolgáltatásban? (tehát milyen gyorsan kell átállni)
Persze erre mindenki azt mondja, hogy semekkora, szóval jobb kérdés az, hogy óránként mennyibe kerül, ha nem megy a szolgáltatás?

- hardverhiba esetén esetén mennyi adatveszteség engedhető meg? (tehát milyen sűrűn kell szinkronizálni a vm imageket)
Általában erre sem tud értelmesen válaszolni az ügyfél, így itt is a mennyibe kerül 1 óra/nap/hét adatveszteség? a legjobb kérdés.

- backup hogyan, hová, milyen sűrűn?

- és a legfontosabb: mennyi pénz/erőforrás van rá?
A szükséges és reális ráfordítás kiszámolásában segítenek a fenti pényzügyi vonzatú kérdésekre kapott válaszok ;)

--
zrubi.hu

Nem feltétlen 100%-os cluster szerű megoldásra gondoltam.

Nem foglalkoztam eddig storage-al de szerintem nem lehetetlen gondolat, hogy két fizikai gép egy közös diszket lásson, azt használja, egy online, a másik offline módon. (Akár kikapcsolva.) Meghibásodás esetén az offline gép elindul a diszken lévő, (esetleg a meghibásodott gép leállása miatt inkonzisztens) filerendszerrel (egy fsck belefér). Így nem kell vm immage szinkoronizáció.

A vmware esetén a storage miatt kellene vCenter, és hogy automatikusan működjön vMotion, ez licenszben már nem kis összeg, másrészt a storage meghibásodása eseténminden adatnak lőtek.

Ha kicsi a keret rá nézd meg a ganeti-t, kvm és drbd alapon működik, produktív környezetben is bizonyított már

--
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...

Nos akkor egy szóban: Kiforratlan
Pár mondatban: Volt szerencsém üzemeltetni 1,5 évig az előző munkahelyemen jópár nodeot ganetivel, mert ezt örököltem meg az elődöktől.
Legjellemzőbb és legordítóbb akkori hibák, amikre emlékszem, vagy előtudtam kotorni a magán levelezésemből:
Queue beragadása, innentől kezdve a mentések (gnt-export) orosz rulett szerűen műkdödtek, amíg nem áltam át barkács mentésre.
A queue miatt, egy esetleges sürgős migrálás is sokszor nem futott le, kézzel kellett a queue-ban gányolni.
Sokszor előfordult hogy kiadtam valamilyen parancsot, status ok, közben ugyanúgy futott a dolog még :)
A cluster beállítása is igen fura, elvileg mindent toolal kell, de ha nagy gáz van, túrd meg a configot, ami természetesen értelmezhetetlen nagyjából.
Auto fault tolerance hiánya, majd (számomra logikátlan) bevezetése alfa szinten
Host reboot utána drbd sync nem folytatódik, kézzel kell ganeti alól elindítani.
Ezek még a 2.6.2 rendszer alatti fejlemények, arról már nem is beszélek hogy megpróbálni frissíteni homokozóban a 2.6.2-ről a 2.7.0 beta2-re jópárnapos szívás volt, és nem is sikerült, csak beta1-re anno.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Ahogy már emlytettem külső storage-et nem használhatsz ingyenes ESXi licenc esetén.

Ettől függetlenül, ha mégis ilyen megoldást csinálsz az - véleményem szerint - több problémát okoz, mint amennyit megold.

És ahogy már lentebb is kifejtettem drága lesz, mert egyik hardvered kihasználatlanul áll az esetek ~98%-ban.

Ilyen kis erőforrás igény esetén én inkább vennék az igényeknek megfelelő szolgáltatást.
pl. az amazon-tól.

--
zrubi.hu

Ez nem VMware specifikus, bármelyik megoldás esetén érvényes.

- Nagyon drága, hiszen az egyik node üresjáratban kell hogy menjen.

- 2 node nem tudja hitelt érdemlően eldönteni, hogy melyik a hibás, így nagyon könnyen teljes szolgáltatás kiesést kapsz a redundancia helyett.

3+ node esetén a hardvereid sokkal jobban kihasználhatóak, lehetőséged lesz üzem közben is hardvert/hypervisort/biost frissíteni/javítani. És a HA fícsör is megbízhatóan fog működni.

Nem véletlen, hogy a VMware legkisebb cluster csomagja is 3 node +vCenter licenceket tartalmaz.

--
zrubi.hu

- 2 node nem tudja hitelt érdemlően eldönteni, hogy melyik a hibás, így nagyon könnyen teljes szolgáltatás kiesést kapsz a redundancia helyett.

Gondolkodom:

Mind a két node-on van pár különböző VM, amik csinálnak amit akarnak. Ha az egyik node hibát érzékel, harakirit követ el. Van valamilyen heartbeat a 2 node között, amik egyébként elérik a shared storage-t. Ha a heartbeat elfogy, akkor X idő eltelte után mind a két node megpróbálja a közös storage ugyanazon pontját lockolni. Aki meghalt, az nyilván nem tud zárolni. Aki él de nem tud zárolni, az X+Y idő után harakirit követ el (split-brain elleni védelem). Aki él és zárolni is tudott, az X+Z idő után ( Z > Y ) feloldja a lockolást és egyedüliként magához vonja a másik node VM-jeinek futtatási feladatát is.

Hol a hiba, ami miatt nem tudják hitelt érdemlően eldönteni, hogy melyik a hibás? Vagy elesik a gép és kiesik a heartbeat, vagy ha meghal a heartbeat háló, akkor sincs split-brain.

Javaslom, hogy olvasd el a VMware HA dokumentációt és gondold át a 2 és 3 közötti különbséget.

Nem világos, hogy 3+ gép mennyivel jobban kihasznált abban az esetben, ha például mindössze egyetlen VM-ed van.

Az igaz, hogy 3 gép esetén 33% a tartalék és 66% a használt, míg 2 gép esetén 50-50% az arány. De ehhez az kell, hogy 3 gyengébb gépet (amiből 2 elbírja a terhelést) olcsóbb legyen venni, mint kettőt (amiből 1 elbírja a terhelést) - licenceket és minden egyebet beleszámolva.

( NagyZ v | 2015. 02. 08., v – 16:19 )

IBM v3700-as storage fillerekbol megvan, teljesen redundans, es imadni fogod az UI-t.

a nap kozepen, jelentos IO mellett szoktam fw upgradet csinalni, mindenfele kieses nelkul. (ilyenkor megcsinalja elosszor az egyik kontrollert, rebootolja, majd a masikat, es azt is reboot).

persze ehhez kell az, hogy a vmware hostjaink mind a 4 IP-hez csatlakozzanak (4x10Gbiten van), aktiv/aktiv-ban.