Ti melyiket ajánlanátok / választanátok egy új VMware vSphere környezet kialakításakor?

Vélemény

vCenter Server egy dedikált gépen fusson (Windows + MSSQL) akár natívan, akár önálló ESXi felett VM-ben.
10% (26 szavazat)
vCenter Server egy menedzsmentre fenntartott (másik vCenter Server által menedzselt) clusteren fusson egy Windowsos VM-en.
3% (9 szavazat)
vCenter Server az általa kezelt clusteren fusson egy Windowsos VM-en.
4% (11 szavazat)
vCenter Server Appliance egy önálló ESXi felett fusson.
3% (8 szavazat)
vCenter Server Appliance egy menedzsmentre fenntartott (másik vCenter Server által menedzselt) clusteren fusson.
3% (7 szavazat)
vCenter Server Appliance az általa kezelt clusteren fusson.
8% (22 szavazat)
Egyéb (hozzászólásban leírom)
1% (3 szavazat)
Nem nyilatkozom / Nem érdekel / Nem foglalkozom ilyesmivel
67% (178 szavazat)
Összes szavazat: 264

Ha annyi ezresem lenne, ahány olyan projekten dolgoztam, ami megkívánt volna sok mindent, de szinte semmire sem volt pénz... :D Sok sört vehetnék belőle.

Vagyis, sokszor hiába kívánja a projekt, pénz az nincs, de a problémát valahogy (akárhogy, vagy bárhogy) meg kell oldani.

--
trey @ gépház

Ez nem projektfuggo. En szivtam mar meg azt, hogy volt vCenter, de nem volt Live Migration, es ha valamiert modositani kell a vCentert futtato gep parametereit, az szopas.

Egyebkent a vCenternek nincsenek extra igenyei, szinte barhonnan lehet kukazni egy gepet, amin elfut.
--
Blog | @hron84
Üzemeltető macik

volt vCenter, de nem volt Live Migration,

valamit nagyon el kellett baltaznod. A vmotion (amire valojaban gondoltal) elegge basic feature (mar a standard edition-ben is benne van).

ha valamiert modositani kell a vCentert futtato gep parametereit, az szopas.

ha modositani kell a parametereit, akkor detto elcsesztel valamit. Bar a cluster tuleli, ha le kell allitani a vcenter-t, pl. windows upgrade miatti reboot. Te lattal mar kozelrol vmware-t? Csak azert kerdem, mert elegge olyan a relaciod vele, mint csiganak az F1-hez...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"valamit nagyon el kellett baltaznod. A vmotion (amire valojaban gondoltal) elegge basic feature (mar a standard edition-ben is benne van)."

Volt, de nem tudott mukodni, mert a mogottes storage infra nem ugy lett kialakitva, hogy ezt lehetove tegye.

"ha modositani kell a parametereit, akkor detto elcsesztel valamit."

Imadom, hogy te mindig mindent jobban tudsz, es ezaltal en is sokat tanulhatok toled #irony. Figyelj, en elhiszem, hogy ertesz hozza, viszont gozod nincs, en milyen infrakat uzemeltetek, orulnek, ha nem jatszanad itt a rogtonitelo birosagot anelkul, hogy barmit is tudnal az altalam uzemeltetett rendszerrol (melynek reszleteit okkal nem osztom meg). Legyszives kezdd mar felvenni azt az attitudot, hogy ha barki random ember mond valamit, annak lehet, hogy oka van, amit nem akar/nem tud megosztani veled, mert egy ido utan senki nem fog akarni veled erdemben kommunikalni. Tudom, hogy ez neked nem faj - de azoknak, akiket lehulyezel, azoknak meg igenis problema.

"Bar a cluster tuleli, ha le kell allitani a vcenter-t, pl. windows upgrade miatti reboot."
ikr

"Te lattal mar kozelrol vmware-t? Csak azert kerdem, mert elegge olyan a relaciod vele, mint csiganak az F1-hez..."

Kozelrol szerencsere keveset kell latnom ilyet (a fizikai konzolos menedzsmentje egy csoppet katasztrofa), altalaban tavolrol uzemeltetek kozepes meretu VMware infrastrukturakat. Sajnos nem tudok annyi idot forditani a tema megismeresere, mint amennyit szeretnek, igy a vCenter belso mukodeserol is viszonylag keveset tudok (egyik vagyam lerakni valami VMware-s vizsgat, aminek a kereteben dedikaltan tudok a temaval foglalkozni), de ahhoz eleget tudok, hogy tisztaban legyek a rendszer alapveto mukodesevel. Amiket leirkalok itt, azok tapasztalaton (az enyemen vagy masoken) alapulo velemenyek, fenntartom, hogy adott esetben nem pontosak, vagy tevesek. En azonban igyekszek mindenhez ugy hozzaallni, hogy ha lehet, akkor probaljak elkerulni minden lehetseges hibalehetoseget - az adott korulmenyek kozott. Ehhez hozzatartozik az is, hogy ha valamiben nem vagyok biztos, hogy hogyan mukodne egy adott szituacioban, akkor a legrosszabbat feltetelezem (jelen esetben azt, hogy ha a vCenter hibas adatbazissal dolgozik, akkor elboki a clustert), igy legfeljebb csak kellemes meglepetes erhet (ha adott esetben megsem boki el), igy legalabb a nyilvanvalo hibakat el tudom kerulni.
--
Blog | @hron84
Üzemeltető macik

mert a mogottes storage infra nem ugy lett kialakitva, hogy ezt lehetove tegye.

f*cked by design

En azonban igyekszek mindenhez ugy hozzaallni, hogy ha lehet, akkor probaljak elkerulni minden lehetseges hibalehetoseget - az adott korulmenyek kozott.

ez dicseretes, de ha nem koveted a vmware ajanlasait (pl. vcenter deploy-ra), akkor biza elcseszted, meg ha titkosak is a reszletek...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"f*cked by design"

Ikr, de nem valogathatok, azt kell uzemeltetnem, amit a kezem ala adnak. Egy elbokott infra atalakitasa lassu es faradsagos munka, es ebbol az ugyfellel valo egyeztetes a lassu resze. Elvben meg lesz oldva... valamikor... egyszer.

Mindenesetre az infrat igy vettuk at, ez van, ezt lehet szeretni es utalni, izlestol fuggoen.

"ez dicseretes, de ha nem koveted a vmware ajanlasait"

Altalaban szoktam kovetni - ahol mod es lehetoseg van erre. De, again, uzemeltetokent meg kell tanulni az idealistol nagyon messze levo kornyezetben is dolgozni - meg ha ez azzal jar, hogy minden erzekszerved berzenkedik az ellen, ami a kepernyodon latszik.
--
Blog | @hron84
Üzemeltető macik

A 6.0-nál majdnem mindegy. Ízlés, tapasztalat, rendelkezésre álló licencek (Windows Server + nagy telepítés esetén fizetős MS SQL vagy egyéb támogatott SQL server licenc), illetve bizalom (van-e olyan kiforrott, mint a windowsos, hiszen az volt előbb) kérdése.

Ha van linuxos tapasztalat, akkor appliance. Én saját rendszernél 5.1-nél tartok Windows vCenter-rel. Ha állok át, erősen valószínű, hogy appliance lesz.

--
trey @ gépház

Azert, hogy megmaradjanak a vCenterben tarolt objektumok, mint pl. HA/DRS beallitasok, resource poolok, tagek, stb. Nyilvan ez kis kornyezetben kevesbe fajo dolgok.
Sot, vDS hasznalatakor annak a konfigjara is vigyazni kell, egy uj vCenterrel nem lehet csak ugy felismertetni az aktualis allapotot (ez nem probaltam, csak sejtem). Mondjuk arra van export/import funkcio. Csak akkor van baj, ha mar nem elerheto a regi vCenter, hogy kiexportaljuk belole a vDS konfigot.

Van szamos olyan applikacio, ami a vCenter objektumait hasznalja:
- vCloud (Director): nem lehet csak ugy eldobni a clustert es ujraepiteni egy masik vCenterrel, mert akkor a Provider VDC (resouce pool) is torlodik (ezzel az egesz cloud lenyegeben)
- regi vCNS (aka vShield) vagy az uj NSX: ezek is fuggenek a clustertol
- VDP: uj vCenterre valo atregisztralaskor eldobodik az osszes eddigi backup (ha jol remlik)

Úgyértettem, hogy nem váltja ki az appliance a windows-os vcentert. Ha van windows-os vcentered, akkor nyilván rakhatsz mellé appliance-t és megmarad az update manager, ill a scan állapotát is látod az appliance felületén, de még mindig igaz, hogy az appliance egy crippled termék a windows-os vcenterhez képest. (ami egyébként egy vicc ennyi év igérgetés után, a mai napig nem nagyon érdemes windows nélkül vmware környezetet üzemeltetni)

Ja és ugye új vmware környezet kialakitásáról szól az egész topic, igy nem elhanyagolható tény, hogy windows-os vcenter nélkül nem lesz update managered.

Ez nem igaz. vCSA melle eleg egy VM Windows-zal (nem windowsos vCenter), amire felrakhatjuk a VUM szoftvert es install kozben a vCSA-t adjuk meg mint vCenter Server. Tehat nem windowsos vCenter fuggese van, hanem csak egy Windows licence kell pluszban (vagy egy meglevo windowsos SW melle telepitheto).
VUM-mal a masik gond pedig az, hogy a teljes funkcionalitasat csak a vastagkliensen erhetjuk el. Mindekozben minden mas mar a webclienten van.

Ez mind igaz, de akkor is ugyanott vagy, hogy kell windows a vmware környezethez. Nyilván lehet az egy vm is, akkor is kell windows-od legyen.
Én általában akkor már windowsos vcenterre rakom, de kétség kivül rakhatod másik windows-ra is a vum-ot, ha az jobban tetszik, de a lényegen nem változtat.

( sj | 2015. 09. 05., szo – 20:23 )

kisebb kornyezetbe az appliance-et, nagyobb kornyezetbe a windows-os vcentert, de mindket esetben a clusteren fusson.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

az altala kezelt clusteren, igy ertettem.

Viszont igy tipikusan kozos a datastore/storage, azaz halozati/SAN leallas eseten egyutt hal le az egesz.

ez igaz, de egyreszt miert allna le a halozat (vagy a san), masreszt jobb az a lelkednek, ha leall minden VM, de legalabb a vcenter megy? Szerintem strapabirobb az (a vcenter szempontjabol is), ha tobb hostod van egy redundans (storage + halozat) komboval, mint ha 1 (kulonallo) gepen futtatnad a vcentert...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

masreszt jobb az a lelkednek, ha leall minden VM, de legalabb a vcenter megy

Sokan ezért nem akartak virtualizált vCentert(a legdurvább az volt, amikor az appliance-t heggesztették fizikai vasra). Sokszor mondtam én is, ha a tároló lehal az egész infra alatt, az a legkevesebb, ha nem megy a vCenter.

Ez igaz, de ha pl. leáll a központi storage és azon volt a vCenter, akkor nem lesz használható VDP-d a régebbi VDP verziókkal, így egy másik storage-ra nehezen tudnál virtuális gépeket visszaállítani. A régebbi VDP-k csak vCenter-rel akartak menni. Most már van emergency restore (VDP 5.5-től), de nem tudom, hogy az mennyire kiforrott (főleg, hogy VDP esetén a kiforrottságról amúgy is csak idézőjelesen lehet beszélni). Ráadásul az emergency restore-nak van egy csomó limitációja és követelménye.

Mondjuk az is megérne egy szavazást, hogy ha leáll a storage, akkor mit csinálnál?

( ) megvárom a szervizt, gyártót, amíg helyrepofozza a storage-ot, nem kezdek mentésből visszaállításhoz
( ) nem várok a szervizre, azonnal hozzálátok a kritikus szolgáltatások visszaállításához a virtuális gépek mentésből visszahúzásával
( ) fogom a táskám és elmegyek 2 hét szabira
( ) felkötöm magam

:)

--
trey @ gépház

Tudom, hogy mindenki magából indul ki, de nálunk például a VDP elenyésző mértékben van jelen. A legtöbb VMware kompatibilis backup megoldással lehetséges standalone hostra visszaállni. Persze ha van hova, mert már működik a storage. Ugye nem feltétlen kell a tároló megsemmisülésére gondolni, előfordulhat csak az SP-kel is probléma(bár tapasztalataim alapján a tárolórendszerekkel szokott a legkevesebb probléma lenni).
A felvetett szavazásoddal kapcsolatban pedig kérdés, hogy van-e hova visszaállni? Van másik tároló, ha van lehetséges-e beletenni a másik fabricba. A legfontosabb viszont, hogy érzéket kell kifejleszteni arra, hogy pont olyankor legyünk szabadságon és legyen ez a kollégák problémája. :)

VDP azota ingyenes lett (advanced is), igy egyre tobben fogjak hasznalni.
Nyilvan a VDP datastore-jait nem ugyanazon a storage-on tartjuk, amin a mentendo VMek futnak. Eleg ha a VDP datastore-jan (ami akar a host local datastore-ja is lehet) van meg annyi hely, hogy a legkritikusabb VM-eket oda restore-oljuk.

mondjuk en *redundans* storage-ot felteteleztem, ami (legalabbis elmeletileg) nem all meg. Ha nem ilyen van, es megall, akkor arra - nyilvan - van terve a menedzsmentnek (hiszen a kockazatokrol es mellekhatasokrol megkerdeztek gyogyszer...rendszergazdajukat, beszallitojukat, akik elmondtak mindent).

Btw. nem csak vdp letezik, mas megoldas is van a virtualizalt kornyezet mentesere...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Saját szememmel láttam full redundáns storage-ot firmware hiba miatt úgy lekönyökölni, hogy csak a gyártótól kapott firmware frissítés javította meg a bugot. A probléma az volt, hogy RAID6 tömbből kiesett egy diszk. Nyilván ilyenkor semminek sem kéne történnie a LUN prezentáció szempontjából. Itt viszont történt. A VMware hostok felé a LUN prezentáció megszűnt (a storage úgy döntött, hogy lekapcsolja) és egészen addig ott úgy is maradt, amíg a kiesett diszket ki nem cserélted egy újra és a rebuild meg nem kezdődött. Onnantól minden ment tovább.

--
trey @ gépház

"miert allna le a halozat" -> ezt ugy irod mintha ilyen sose tortenne

Nehany ok, hogy miert jo ha tuleli a vCenter:
- lesz alert
- logokbol ki lehet nezni, hogy pontosan mi tortent
- VDP hasznalataval menni fog a normal restore, nincs szukseg "emergency restore" muveletre
- ha megjavul a storage/SAN/halozat, akkor maris lehet a hostokkal dolgozni, nem kell a vCenter lelket apolgatni (fsck/scandisk, db recovery, stb.)

+sok

Sajnos a vCenter az nem csak egy app, hanem van vele egy SQL szerver, amire szinten gondot kell forditani, plusz ez az egesz egy ruhes cluster management tool, a fene tudja mit tud a hostokbol kiolvasni, es mit eroltet a sajat DB-je alapjan, inkabb nem probalnam ki, hogy mi van, ha a hostokon levo valosag meg a db nem ugyanazt mutatjak.
--
Blog | @hron84
Üzemeltető macik

ahogy fentebb irtam, redundans halozatot felteteleztem. Amit kozelebbrol is latok, az (eddig) meg nem is allt meg.

- lesz alert

ehhez nem must have a vcenter

- logokbol ki lehet nezni, hogy pontosan mi tortent

hogy pontosan mi tortent a halozati eszkozokkel?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Eros naivsag azt hinni, hogy ha vmi redundans, akkor az soha az eletben nem all le.
Csak nehany pelda:
- felresikerult FW upgrade, ami magaval rantja a masik kontrollert is
- FW bug, ami mindket kontrollert rebootolja
- thin LUNok megtelitik a poolt ezaltal offline-ba kerulnek a LUNok (nyilvan ez monitoringozassal elkerulheto)
- emberi tenyezo: vki rossz dolgot torol, elallit, stb.

Nyilvan vCenter logokban az latszik, amit a hostok reportalnak magukrol. Van ugy, hogy hasznos ez az informacio is. Bar sok esetben inkabb a host oldali logok a lenyegesek.

Bar sok esetben inkabb a host oldali logok a lenyegesek.

amit viszont nem latsz, hiszen halozati hibat vizionaltal. Szoval fenntartom, hogy ha kidolnek a host-jaid, de a kulonallo vcentered halozati hibanal talpon marad (dafuq?), akkor max arra jo, hogy azt mondhasd a cio-nak, van egy rossz, meg egy jo hirem...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( hassan | 2015. 09. 05., szo – 23:06 )

- clusteren fusson a vCenter, hogy egy külön management clusteren vagy "produktív" clusteren az már pénz/licence kérdés. Viszont ha már áldoztok külön mgmt clusterre az _szerintem_ legyen másik vCenter alatt
- VCSA vagy nem: egész eddig Windows párti voltam, de 5.5-től már inkább VCSA-t telepítenék, ezek kevesebb nyűggel járnak adminisztráció szempontjából és már ugyanolyan megbízhatóak és funkcióba gazdagok mint a windowsos társuk
- a kérdésre talán egyszerűbb lenne válaszolni annak tudatában, hogy mik az igények, költségek, az esetlegesen már rendelkezésre álló infrastruktúra és még rengeteg tényező. Ezek nélkül kb. azt is kérdezhetted volna, hogy hogyan és mivel juss el Debrecenből Lentibe.

En semmkepp se tennem a produktiv clusterre, foleg, ha nincs Live Migration valamiert. Inkabb akkor kukazok neki egy vasat valahonnan, meg ha igy SPOF is lesz, egy alig bantott gep jobban tulel, mint egy produktiv cluster, ahol porognek az adatok a diszkeken meg a memoriaban.
--
Blog | @hron84
Üzemeltető macik

Semmi. A windowsos is annyi (főleg, hogy két service is delayed start-ra van állítva gyárilag). A vCenter nem kritikus olyan szempontból, ha éppen nem kell valamiért, akkor nyugodtan kieshet ennyi (de akár több) időre is.

De egyébként kellhet. Pl. a VDP nap közben futtat egy csomó background taskot. Ilyen pl. a blackout window-ban futó garbage coll, az integrity check vagy a checkpoint készítés. A (régebbi) VDP egyből a vCenter-t keresi és ha azt nem találja, meg is állnak a taskok. Persze ez nem kritikus, mindegyik le fog futni a következő maintenance és blackout window-ban. De nem egészséges ezeket napokig nem futni hagyni.

5 perc bármikor belefér.

--
trey @ gépház

Az egy dolog, hogy a cluster tulel a vCenter atyaskodasa nelkul is, vegulis a vCenter nem szol bele az VM-ek mukodesebe, miert ne elhetne tul.

Ezzel egyutt azonban nem kulonoskeppen szivelem, ha nincs konzol eleresem a gepekhez, mert 5-10 perc alatt is tortenhetnek olyan dolgok a rendszerben, amik instant beavatkozast igenyelnek, es van, ahol a vCenter az egyetlen lehetoseg arra, hogy a gepekhez "fizikai" konzolt szerezzek (ha peldaul magaba fordul a gep). Es van olyan rendszer, ahol 5-10 perc kieses mar nagyon soknak szamit. Nem minden kornyezet olyan, hogy elturjon 20-40 perces kieseseket. Tekintve, hogy raadasul a vCenter az egyetlen dolog, ami problema eseten automatikusan be tud aktivan avatkozni, a rendelkezesreallasa kulcsfontossagu.
--
Blog | @hron84
Üzemeltető macik

( uid_4656 v | 2015. 09. 06., v – 09:43 )

Jól el tudja bonyolítani a helyzetet, ha egynél több adatközpontod van és van olyan clustered, amelynek mindkét adatközpontban vannak hostjai. Pl. így: 


|============ DC A ============|============ DC B ============|
|                              |                              |
|        ==== Cluster A ====   |   ==== Cluster B ====        |
|                              |                              |
|                     ==== Cluster S ====                     |
|                              |                              |
|  = Standalone A =            |           = Standalone A =   |
|                              |                              |
|=============================================================|

Ilyenkor mennyi vCentert és hova telepítenétek?

Egy clustert csak egy vCenter menedzselhet, ergo egynel tobb vCenternek nem latom ertelmet, csak szettordelne a menedzselhetoseget. Ilyen szimmetrikus esetben mindegy melyik DC-ben fut, gyakorlatban inkabb van primary es secondary site, akkor nyilvan a primaryn fusson. En az egyik standalone hostra tennem local datastore-ra.

Lehet nem extrém, de ha nincs külön mgmt cluster ésszerű és logikus valamint nem best-practice ellen való rátenni az általa menedszelt clusterre.
- lesz HA, míg egy standalone hoston nem
- lesz vMotion

Független az általa menedzsel infrastruktúrától? Akkor hogy kapcsolódnak hozzá a hostok a menedzsment vmkernel interfacen? Ha az alatta lévő clusterre teszed akkor elég a vCenternek azon az uplinken egy portgroup amin a hostok mgmt interface van.

Komolyan, Te láttál már VMware-s infrát?

Biztosíthatlak róla, hogy látott. :)

Nyilván úgy érti a leírtakat, hogy fizikai storage és fizikai kiszolgálótól legyen független, vagyis ne az általa menedzselt infrán fussom a vCenter. Ezzel én sem értek egyet, nyugodtan futtatnám a vCentert egy általa menedzselt ESXi hoszton, de néhány dolgot biztosítanék:
- a VDP backup ne arra a storage-ra történjen, amin a mentett környezet is fut; erre jó megoldás a dedikált fizikai kiszolgáló
- kerülni kell a distributed switch menedzsmentre való használatát (vagyis a vCenter ne VDS-re kapcsolódjon). Ephemeral mode ide vagy oda, nem tennék bele ilyen szintű függést

Mellesleg, +1 a HA és vMotion-ra.

A vCenter(néhány kivételtől eltekintve) nem managel tárolót. Ha a VM-eket hostoló tárolód meghal, nem az lesz az első gondod, hogy nem fut a vCentered(feltételezve, hogy arról is van aktuális mentésed). Az azért még a legtöbb helyen(és itt nem csak kis hazánkra gondolok) elég nagy luxus fenntartani egy külön tárolót, hogy legyen a vCenternek HA.
Nem tudom, miért csak VDP-ben tudtok gondolkozni. Annak ellenére, hogy szerintem jobb, mint az EMC saját Avamar appliance megoldása, eléggé soho kategória. Valamint ki említette, hogy ugyanott tárolná a mentéseket ahol a VM-ek vannak?
vCenter a VDS-en: blade keretekben sokszor szükséges.

Ha VDP-vel készült a mentés, a restore-hoz kelleni fog a vCenter (kivéve az emergency restore-t, de azt a vCenter helyreállítására szokták használni). Tegyük fel, hogy vCloud Director is bejön a képbe. Ott is szükséged lesz a vCenter-re, mert a vApp-ok elindítása kihívásokba ütközhet nélküle (nem látod a RP-ket, nem tudod, melyik host-on mely VM-ek alkotják a vApp-ot, azokat milyen sorrendben kell elindítani, stb).

Azért van a VDP terítéken, mert része a vSphere-nek (Essential Plus és felette) és vCloud Suite-nak, nem kell rá külön költeni, és az egyszerű backup feladatokra (napi inkrementális mentése az infrastruktúra-menedzsment VM-eknek) teljesen megfelel.

Arra szerettem volna utalni, hogy nem ördögtől való olyan ESXi-n futtatni a vCenter-t, melyet menedzsel, de ahhoz, hogy egy komolyabb meghibásodás esetén könnyen vissza lehessen állítani, figyelni kell a környezet kialakítására. Erre hoztam fel példaként a vDS-t és a backup-ot tároló storage-ot.

( zrubi v | 2015. 09. 07., h – 09:07 )

Szerintem:

1 db vCSA, ami ideális esetben egy management clusteren fut. De ezt a management clustert is nyugodtan kezelheti maga alatt, nem lesz vele probléma.

Mi ezt annak idején (5.0-tól) még AutoDeploy-jal is megfejeltük, a management cluster tagjaihoz meg volt 'vészindító' pendrive.

bővebben:
http://zrubi.hu/2011/vcenter-server-appliance-eles-uzemben/
+ a kapcsolódó írások.

Többen emlegették itt storage halált. Na, azellen SEMMI nem véd.
A VMware cluster számára a megbízható közös storage olyan szükséglet mint az áram:
Ha az van, akkor minden megy. Ha az nincs, akkor meg semmi.

(persze tudom, hogy már van mindenféle 'okosmegoldás' igazi storage helyett, de szvsz csak az szívjon azzal akinek nagyon nincs más lehetősége)

Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion

--
zrubi.hu

( bognarattila | 2015. 09. 12., szo – 23:24 )

Sok mindentől függ, többek között:
- összesen hány ESXi van
- milyen jellegű a környezet, például biztonsági követelmények
- Windows-ra más okból kifolyólag lehet-e szükség (például mentés vagy egyéb felügyeleti szolgáltatások)
- céges OS preferencia
- mennyi pénz áll rendelkezésre

Ami biztos: ha lehet, legyen valamilyen redundancia, azaz 1. és 4. opció majdnem biztosan nem.

Az 5.-nek kevésbé látom létjogosultságát, mert ilyen esetben valószínűleg sok ESXi van, amihez nem árt UpdateManager.