Vcenter: fysiek of VM?

[mister9]

Goedemorgen,

Even een vraag aan de systeembeheerders (of andere die er ervaring mee hebben).

Ik heb momenteel onze Vcenter fysiek draaien, icm 2 Hosts (ESXi). Op die 2 hosts draaien bij elkaar zo'n 18 vm's.

De support verloopt op deze fysiek server. Ik kan nog deze verlengen, maar ik kan er ook voor kiezen om de Vcenter als vm in te richten en de fysieke server uit te faseren.

Wat is jullie ervaring, fysiek houden of Vcenter als VM draaien?

Mijn grootste pluspunt van een fysieke is dat mocht er een calamiteit net vm-ware omgeving zijn, of om 1 of andere reden vallen beide hosts uit, de Vcenter alsnog beschikbaar is en toegang verleent tot bv het SAN en andere netwerkapparatuur.

Bedankt vast!

[brid]

virtueel

esx host kun je altijd nog via vsphere client benaderen.
Hier alles virtueel(1 VCenter, 3/4 hosts).

[MAX3400]

Ik lees een ander probleem; bij een calamiteit waarbij beide hosts uitvallen, heb je een ander probleem dan je vCenter-omgeving in de lucht houden. Sterker nog; zelfs zonder vCenter (want point & click) moet je de skills hebben om het SAN en de switches/routers te bedienen.

Vergeet even niet dat als je gaat virtualiseren dat je in een aantal gevallen de meest smerige trucs moet uithalen als je de VM op een ander platform moet/wil opstarten? Ik zou bijna zeggen: virtualiseer op generic (goedkope) hardware zoals een standaard HP desktopje van 400 Euro; schaf een tweede desktopje aan en zorg dat de VM tussen de 2 machines gesynchroniseerd kan worden.

Ik hoor graag wat je zelf al had bedacht over de vraagstelling: waarom wil je virtueel of fysiek? Waar komt het op te draaien? Wat mag die oplossing kosten? Sterker nog; wat mag het bedrijfsbreed kosten als je 1 uur, 4 uur of 16 uur niet bij je vCenter kan komen?

Hou je wel de hoofdletters in de gaten van je produkten?

[SirDarkAngel]

MAX3400 schreef op dinsdag 11 augustus 2015 @ 11:44:
Ik lees een ander probleem; bij een calamiteit waarbij beide hosts uitvallen, heb je een ander probleem dan je vCenter-omgeving in de lucht houden. Sterker nog; zelfs zonder vCenter (want point & click) moet je de skills hebben om het SAN en de switches/routers te bedienen.

Vergeet even niet dat als je gaat virtualiseren dat je in een aantal gevallen de meest smerige trucs moet uithalen als je de VM op een ander platform moet/wil opstarten? Ik zou bijna zeggen: virtualiseer op generic (goedkope) hardware zoals een standaard HP desktopje van 400 Euro; schaf een tweede desktopje aan en zorg dat de VM tussen de 2 machines gesynchroniseerd kan worden.

Ik hoor graag wat je zelf al had bedacht over de vraagstelling: waarom wil je virtueel of fysiek? Waar komt het op te draaien? Wat mag die oplossing kosten? Sterker nog; wat mag het bedrijfsbreed kosten als je 1 uur, 4 uur of 16 uur niet bij je vCenter kan komen?

Hou je wel de hoofdletters in de gaten van je produkten?

Ik snap je verhaal maar beperkt, maar zoals ik het verhaal van de topic starter lees heeft hij nu 2 ESXi dozen en een management server waarop ook vCenter staat. Waarom zou je werkstations willen inzetten om een VM in de lucht te houden? En welke smerige trucks moet hij uithalen op welk moment? Hij heeft toch gewoon een standaard VMware omgeving en wil alleen weten waar hij zijn vCenter/management tools moet laten?

Ik zou de vCenter doos virtualiseren als hier capaciteit voor is. Volgens mij al sinds 4.1 ook de aanbeveling van VMware zelf. Je kan ook besluiten te migreren naar een vCenter appliance toe. (afhankelijk van je wensen/eisen/beschikbare Windows licenties)

Je kan de huidige vCenter server (zonder vCenter) laten draaien met de management tools om het SAN en netwerk apparatuur te beheren. Hiervoor hoef je geen nieuw support contract af te sluiten. Je kan dezelfde tools ook op 1 of meerdere werkstations plaatsen en voor het gevla dat documenteren hoe te installeren en configureren.

[StarWing]

Ik heb 'm virtueel en als het aan mij lag, komt 'ie direct fysiek.
3 esx'en op een MSA2324 + 2FC switches.

[MAX3400]

SirDarkAngel schreef op dinsdag 11 augustus 2015 @ 14:09:
[...]


Ik snap je verhaal maar beperkt, maar zoals ik het verhaal van de topic starter lees heeft hij nu 2 ESXi dozen en een management server waarop ook vCenter staat. Waarom zou je werkstations willen inzetten om een VM in de lucht te houden? En welke smerige trucks moet hij uithalen op welk moment? Hij heeft toch gewoon een standaard VMware omgeving en wil alleen weten waar hij zijn vCenter/management tools moet laten?

Als ik kies voor een VM, dan wil ik wel graag dat die VM er is als mijn ESXi-hosts omvallen zoals toevallig allebei dezelfde kernel-panic door een slechte update. Vandaar dat ik ook al zei dat het hebben van vCenter helemaal niet interessant is zolang je niet de commando's kent om op de commandline de hosts of het SAN te bedienen. Daarnaast, je wil toch niet virtualiseren op het platform wat je wil bedienen? Of ben ik nou heel vreemd dat ik een "centrale" management-machine niet op dezelfde hardware/software wil zetten als het spul wat ik moet managen?

Vandaar dat ik aangaf lekker goedkoop een VM te maken voor vCenter op standaard-hardware. Hierdoor kan de hardware desnoods uitbranden maar de VM kan je makkelijker migreren naar de 2e standaard-hardware. Op het moment dat je deze standaard hardware niet meer kan krijgen en de VM op een nieuwe machine moet zetten (zeg even, van een Dell werkstation naar een Lenovo werkstation), heb je kans dat je hardware layer volledig anders is en mogelijk de hypervisor anders wordt ingericht waardoor je je VM moet herconfigureren. Dat noem ik "smerige trucs'; de meningen kunnen hierover verdeeld zijn maar waarom heeft VMware anders een HCL om te weten/zorgen dat je je hypervisor op hardware X of Y wel draaiend kan krijgen?

[DukeBox]

Zolang je maar je procedure getest hebt om de boel op te starten (denk aan lokale wachtwoorden voor je hosts, hostname/ip's e.d.) zou ik ook gewoon voor virtueel gaan.
Is ook makkelijker voor disaster recovery (replicatie) e.d.

[Question Mark]

StarWing schreef op zondag 16 augustus 2015 @ 18:12:
Ik heb 'm virtueel en als het aan mij lag, komt 'ie direct fysiek.

Waarom?

Ik kom eigenlijk niet anders meer tegen dan virtueel. Wel stel ik altijd even een affinity-rule in die de VCenter server "vastzet" op een bepaalde host.

[Razwer]

Fysiek is niet meer van deze tijd. Er zijn zat (simpele) middelen om de issues op te lossen wanneer de omgeving in zijn geheel down is (waarbij veel al in dit topic genoemd is).

Redenen waarom ik nog wel eens physicals tegen kom is ivm de Tomcat instance van vCenter welke ruk performance kan geven bij een bak met slechte specs. Gezien de webclient meer leidend is sinds vCenter 5 kom je daar ook niet meer omheen. De redenatie hier voor is uiteraard per omgeving verschillend. Puur vanuit DR zie ik de noodzaak er niet van in.

_{offtopic: sup Duke! long time}

[Wim-Bart]

Uit ervaring wil ik hem zelf ook altijd Fysiek hebben. Zelfs al zitten de procedures goed in elkaar dan nog is het altijd een gezeur wanneer je omgeving plat is. Wel eens op 32 hosts moeten zoeken waar dat ding stond en de daarbij behorende SQL Server. Zeker in een omgeving waar Hostnamen en CI namen niet overeen komen.

Aan de andere kant ben je met Virtueel veel flexibeler en niet afhankelijk van een losse machine die ook uit kan vallen. Maar wanneer je een deftige management server hebt met al je tooling en een lokale SQL Database (genoeg voor VC) dan schiet het veel beter op met beheer, zeker bij een behoorlijk infra probleem en wanneer alles gehost is in een extern datacentrum waar je niet zo maar even fysiek toegang hebt.

[Wim-Bart]

Question Mark schreef op maandag 17 augustus 2015 @ 15:14:
[...]

Waarom?

Ik kom eigenlijk niet anders meer tegen dan virtueel. Wel stel ik altijd even een affinity-rule in die de VCenter server "vastzet" op een bepaalde host.

Maakt beheer complexer, vooral als je er niet altijd zelf bij bent en een ander maintenance moet uitvoeren. En je bent gelijk je flexibiliteit kwijt.

[KillerAce_NL]

Wim-Bart schreef op maandag 17 augustus 2015 @ 17:26:
Uit ervaring wil ik hem zelf ook altijd Fysiek hebben. Zelfs al zitten de procedures goed in elkaar dan nog is het altijd een gezeur wanneer je omgeving plat is. Wel eens op 32 hosts moeten zoeken waar dat ding stond en de daarbij behorende SQL Server. Zeker in een omgeving waar Hostnamen en CI namen niet overeen komen.

Aan de andere kant ben je met Virtueel veel flexibeler en niet afhankelijk van een losse machine die ook uit kan vallen. Maar wanneer je een deftige management server hebt met al je tooling en een lokale SQL Database (genoeg voor VC) dan schiet het veel beter op met beheer, zeker bij een behoorlijk infra probleem en wanneer alles gehost is in een extern datacentrum waar je niet zo maar even fysiek toegang hebt.

Wat een onzin, daily report en je weet precies waar alles staat. Als je als vm admin niet weet wat je sql server is, dan is er iets goed mis.
Vm to go, for sure.. Zelfs een calamiteit is geen belemmering.

[Wim-Bart]

KillerAce_NL schreef op maandag 17 augustus 2015 @ 17:38:
[...]

Wat een onzin, daily report en je weet precies waar alles staat. Als je als vm admin niet weet wat je sql server is, dan is er iets goed mis.
Vm to go, for sure.. Zelfs een calamiteit is geen belemmering.

Ben ik niet geheel met je eens. Ik heb deze discussie ook een paar keer met VMWare engineers gehad toen een grote klant omgeving plat lag. Ze wilden via een werkplek/beheer server toegang hebben tot de console van een ESX omgeving. Jammer, 100% virtualisatie (VDI) en alleen de nodige poorten open naar het datacentrum vanaf locaties. Dus met een laptop kon je ook niks als je niet fysiek in Equinix zat. En firewall's waren ook niet aan te passen want de beheer tooling en ACL's wezen naar de Virtuele Beheer server die ook plat lag, dus niks was te doen, maar ook helemaal niks. Sinds dien, altijd een fysieke bak voor beheer er naast welke geen afhankelijkheid heeft van SAN en Blade Enclosures. Net zoals er altijd een Fysieke DC is.

[KillerAce_NL]

Dat heeft dus niks met je availability te maken maar met je overige beheer zoals firewalling en je disaster planning en testing. Ook jouw specifieke omgeving had erop aangepast kunnen worden.

Je moet het zo zien, je vm's staan op shared storage dus als je fysieke bakken onderuit gaan, ben je in no time weer up and running zelfs met virtuele dc's en virtuele vcenters.
Niets ontslaat van van je plicht om je disaster plannen in orde en getest te hebben.


Voor TS geldt hetzelfde, VM of fysiek maakt niet uit (ik stel dat virtueel mits goed ingericht je grotere availability geeft), als je maar je beheer erop aanpast.

[ Voor 15% gewijzigd door KillerAce_NL op 17-08-2015 18:24 ]

[StarWing]

Goh... Een van de redenen. Als er niet genoeg budget is om de full option aan te schaffen, en je dus een versie hebt zonder storage vmotion.
Indien je dan de vcenter moet verhuizen van LUN gaat dit niet via de GUI en moet je in de CLI zitten kutten.

Een andere reden.. shared storage gaat down (of fabric), vcenter gaat down, en daar zit je dus. Moet je gaan restoren zonder vcenter

Is allemaal wel doenbaar, maar ik zou 'm niet meer virtueel nemen.

[DukeBox]

StarWing schreef op maandag 17 augustus 2015 @ 19:14:
Indien je dan de vcenter moet verhuizen van LUN gaat dit niet via de GUI en moet je in de CLI zitten kutten.

Gewoon cut en paste

[Question Mark]

Wim-Bart schreef op maandag 17 augustus 2015 @ 17:28:
[...]


Maakt beheer complexer, vooral als je er niet altijd zelf bij bent en een ander maintenance moet uitvoeren. En je bent gelijk je flexibiliteit kwijt.

Kun je dit eens toelichten? Waarom maakt een virtuele VCenter mijn beheer complexer?

En je bent je flexibiliteit niet kwijt, je wilt in dit geval juist dat je vcenter server niet over je hele cluster "schuift". Die wil je juist vanwege disaster recovery snel terug kunnen vinden, vandaar de affinity rule.

[ Voor 23% gewijzigd door Question Mark op 18-08-2015 15:16 ]

[mister9]

Ik heb ook navraag gedaan bij VMware zelf, en zij geven aan dat de Vcenter als VM best practice is. Maar als ik vraag waarom blijft het erg vaag. Zaken zoals: Je wil je Vcenter zo dicht mogelijk bij je omgeving hebben staan, dus niet via fysiek en dan via glas naar je hosts, maar gewoon óp je hosts...

Best practice prima, maar heb nog geen argument gehoord dat me omver blaast. Overigens denk ik wel dat ik 'm als VM ga neerzetten. Ik vond altijd het argument "als beide hosts in elkaar ploffen, kan ik via m'n fysieke Vcenter nog bij m'n SAN, NAS, Switches, etc. Maar ik denk ook dat ik wel iets anders aan mn hoofd heb als beide host in elkaar geploft zijn.

[Wim-Bart]

Question Mark schreef op dinsdag 18 augustus 2015 @ 14:51:
[...]
Kun je dit eens toelichten? Waarom maakt een virtuele VCenter mijn beheer complexer?

En je bent je flexibiliteit niet kwijt, je wilt in dit geval juist dat je vcenter server niet over je hele cluster "schuift". Die wil je juist vanwege disaster recovery snel terug kunnen vinden, vandaar de affinity rule.

Het gebruik van afinity Rules, DRS rules en andere machine specifieke Rules binnen je ESX cluster maakt het allemaal complexer. Net zoals specifieke start Rules (die je per host moet definiëren).

Het instellen is niet zo moeilijk, gebruik het zelf ook voor omgevingen waarbij je Rules maakt dat bepaalde VM's binnen de zelfde host draaien, of juist Rules waarbij je expliciet wil dat twee servers niet op de zelfde host draaien. Maar hoe meer van deze Rules, waarbij je VM's gaat "pinnen" op een host, hoe complexer het beheer. Uit ervaring mee gemaakt dat een beheerder een paar uur bezig was om een VM te moven omdat ie de host in maintenance wilde hebben maar het maar niet lukte omdat iemand anders een rule had aangemaakt dat hij niet op een andere host mocht draaien, maar hij dat niet in de gaten had, ondanks de meldingen, dat hij eerst de rulle moest aanpassen.

Omgevingen zijn eenvoudig te beheren mits je zelf het volledige beheer doet tijdens, normale tijden en ziekte en vakanties en je geen rekening hoeft te houden met andere beheerders. En de kennis van andere beheerders.

Zelf ga ik er van uit dat iedereen zonder moeite en diepgaande kennis de omgeving moet kunnen lezen en beheren. En daarbij niet geconfronteerd worden met situaties dat een ander een rule weg haalt, je VM machine begint te zweven over je cluster en er in een noodsituatie na een paar uur achter moet komen dat iemand op een dergelijk niveau een config aanpassing heeft gedaan. Daarnaast niks lulliger als je denkt dat je bijvoorbeeld een infra startplan hebt gemaakt, hosts hebt geconfigureerd en bij de eerste beste power-down er achter komt dat machines niet gestart zijn doordat iemand "even" wat gedaan heeft om iets anders te doen.

Daarom zijn er in mijn opinie gewoon ten minste twee machines welke fysiek uitgevoerd moeten worden in een data center, een beheerserver, dan weet je altijd welke dat is, desnoods een basis machine met de belangrijkste infra-tooling (VC, browser, putty, et cetera) en de PDC emulator van je AD correct (overigens is een andere opzet NON supporter door MS onder 2008R2 en lager).

[ Voor 0% gewijzigd door Wim-Bart op 18-08-2015 19:29 . Reden: textuele aanpassingen ]

[marcop82]

In het KMO'tje hier met 2 ESXi 5.x hosts hebben we ook de vCenter op een fysieke host (HP MicroServer) draaien. Om dezelfde voordelen als genoemd worden (als je niet meer aan je hosts kan bv.) zodat je een wel bereikbare fallback hebt, evenals een extra check om te zien of het aan je hosts of je netwerk/stroom ligt.

Aangezien we hier niet praten over DL380's ofzo voor een vCenter, lijkt me dit geen zware issue. Gaat ie later toch virtueel, heb je meteen een leuke DIY NAS erbij in geval van bv. een MicroServer !

[ Voor 10% gewijzigd door marcop82 op 19-08-2015 08:52 ]

[Question Mark]

Wim-Bart schreef op dinsdag 18 augustus 2015 @ 19:23:
[...]
Daarom zijn er in mijn opinie gewoon ten minste twee machines welke fysiek uitgevoerd moeten worden in een data center, een beheerserver, dan weet je altijd welke dat is, desnoods een basis machine met de belangrijkste infra-tooling (VC, browser, putty, et cetera) en de PDC emulator van je AD correct (overigens is een andere opzet NON supporter door MS onder 2008R2 en lager).

Complexiteit werkt twee kanten op.... Je verhaal dat (noodzakelijke) affinity-rules je ook dwars kunnen zitten klopt, maar door het introduceren van Fysieke systemen stap je af van een standaard inrichting.

Naast virtuele systemen, zul je nu ook fysieke systemen moeten gaan beheren wat impact heeft op onderhoud, backupmethodiek en disaster recovery technieken.

Veel van je beheersdocumentatie en disaster recovery procedures zul je dan ook dubbel moet bijhouden en regelmatig moeten testen. Dat wordt nog wel eens vergeten door veel partijen.

Een virtuele VCenter, maar wel één standaard is in mijn ogen dan ook vele malen minder complex dan een fysieke inrichting en meerdere standaarden. Het blijft een persoonlijk keuze, maar vergeet ook niet dat VMWare momenteel erg hard hun virtuele VCenter appliance aan het pushen is.

[Wim-Bart]

Question Mark schreef op woensdag 19 augustus 2015 @ 10:24:
[...]

Complexiteit werkt twee kanten op.... Je verhaal dat (noodzakelijke) affinity-rules je ook dwars kunnen zitten klopt, maar door het introduceren van Fysieke systemen stap je af van een standaard inrichting.

Naast virtuele systemen, zul je nu ook fysieke systemen moeten gaan beheren wat impact heeft op onderhoud, backupmethodiek en disaster recovery technieken.

Veel van je beheersdocumentatie en disaster recovery procedures zul je dan ook dubbel moet bijhouden en regelmatig moeten testen. Dat wordt nog wel eens vergeten door veel partijen.

Een virtuele VCenter, maar wel één standaard is in mijn ogen dan ook vele malen minder complex dan een fysieke inrichting en meerdere standaarden. Het blijft een persoonlijk keuze, maar vergeet ook niet dat VMWare momenteel erg hard hun virtuele VCenter appliance aan het pushen is.

Ik zie dat bij veel fabrikanten dat we de richting van vergaande virtualisatie hebben. Kijk maar eens naar Citrix met hun Netscalers bijvoorbeeld. Kregen we eerst de VPX nu zelfs complete SDX appliances.

Het jammere van VMware is dat ze veelal beargumenteren dat je je VC zo dicht mogelijk bij je infrastructuur moet hebben dus is de beste plaats binnen je ESX farm zelf als VM. Maar dat vind ik persoonlijk een drogreden, vooral als je meerdere datacenter's en clusters binnen datacenters hebt. Hoe dichter bij de ene host/cluster/datacenter, hoe verder van de andere af.

Natuurlijk is het een kwestie van procedures, testen van de procedures en alles goed op orde hebben. Bij veel bedrijven is het ook zo, maar bij vooral wat kleinere bedrijven merk ik dat daar juist de crux zit, dat doen ze niet. Ik heb in de jaren dat ik met VMware werk gewoon de meest rare zaken mee gemaakt die hierdoor grote problemen met zich mee brachten en erger werden naar mate men meer koos voor off-site virtualisatie waar complete omgevingen niet meer te managen waren omdat een ESX host de geest gaf.

Wanneer je vanuit de consolidatie visie de zaken benaderd en je naar een totale virtualisatie over gaat valt en staat alles bij een goede implementatie en weten hoe je met de omgeving om moet gaan en de documentatie daar van. Helaas is de praktijk anders want iedereen kan bijna een ESX datacenter aan elkaar klikken tegenwoordig, tot er problemen zijn die zie niet verwachtten. Daarom raad ik, vooral aan, wanneer de procedures niet helder zijn, en niet goed onderhouden worden, meer een conservatieve benadering aan, gewoon een enkele 1U beheerserver met daarop al je tooling, ook je VCenter omgeving, niet omdat het mooier is, maar meer uit veiligheid. Zelfs de database trek ik hiervan niet los, want dan kweek je weer een afhankelijkheid. En wil je toch virtualiseren, dan gewoon een datacenterloze enkele host met local storage met daarop VC en beheer componenten in 1 of meerdere virtuele machines.

Met name beheer- en monitoring fuck-up's liggen voor mijn gevoel daar aan ten grondslag. Om maar eens met wat voorbeelden te komen.

Klant had VC in een VM op een SAN. Overprovisioned storage op ESX niveau. SAN was alleen via Virtuele beheer (Citrix) server benaderbaar evenals de VC omgeving en de ILO's. ESX volume liep vol, VC database server gepauseerd, net zoals de beheer Citrix server. Firewall was niet te managen (ACL's), VC was niet te benaderen, geen ssh mogelijk naar ESX hosts, totale beheer liep vast. Enige oplossing was om naar datacentrum te rijden en met een console kabel eerst naar SAN te gaan, volume uitbreiden, daarna via console op ESX in CLI volume extenden wat gelukkig nog mogelijk was en daarna de beheer omgeving opbrengen om de rest van de omgeving op te brengen. Met een beheerserver met VPN toegang was dit nooit gebeurd.

Andere klant, vergat om netjes een NetApp down te brengen, ook geen out of band beheerserver beschikbaar, even een ritje van Maastricht met laptoppie naar Amsterdam toe omdat de omgeving niet op kwam doordat de NetApp een start commando wilde.

Andere klant, kwam omgeving niet op, bleek dat de primaire DC en VC inmiddels op een andere host stonden, 41 ESX servers aflopen met een laptoppie in het datacentrum, en je zal altijd zien dat ze op de laatste staan. Beheerder was vergeten na onderhoud de VM's terug te zetten op de host waardoor autostart niet werkte. Zonde van de tijd.

Daarom zegt mijn gevoel, bepaalde zaken kun je door conservativiteit oplossen en ik denk dat er voor alle scenario's ook wel wat te bedenken valt, zowel een losse fysieke VC als een gevirtualiseerde.

[KillerAce_NL]

Incompetentie en slechte procedures vang je niet op met een fysieke bak. Als men als een prutszooi heeft, dan kun je er vanuit gaan dat dan ook de disaster recovery voor die enkele bak niet in orde is.
Ben je nog harder genaaid.

Als je zorgt dat je beheer ook bij je storage kan, dan kun je desnoods in no time je vcenter op je beheer pc draaien als vm. dat is juist het mooie van een vm, ultra portable, 100% vervangbaar.

Database en vcenter op 1 fysieke bak vind ik juist weer een enorm risico.
Maakt mij het wat uit als mijn vcenter kapot gaat ? Nee, ff een restore en klaar (desnoods naar heel andere storage of zelfs met een simpele storage snapshot), database untouched en up to date. Vooral als je third party backup gebruikt van je vm's wil je niet dat je DB verrot gaat, je moet rebuilden en al je vm's weer een andere guid krijgen, kun je je backups weer helemaal instellen...
Ik wil geen DB op hardware


We zijn vergaand gevirtualiseerd en moet er niet aan denken om weer een stap terug te moeten zetten en weer op hardware te moeten vertrouwen. Teveel server hardware issue's meegemaakt, dat is nu geen probleem, hooguit korte tijd wat mindere performance (in zeer zeldzame gevallen)

[MAX3400]

KillerAce_NL schreef op woensdag 19 augustus 2015 @ 20:09:
Incompetentie en slechte procedures vang je niet op met een fysieke bak.

Nee, je vangt het inderdaad niet op maar je voorkomt wel dat "sommige mensen" teveel gewend zijn aan icoontje ipv commandline en op sommige momenten nergens meer bij kunnen omdat de VM en hypervisor het niet meer doen. Dat jij & ik weten hoe we ook op ESX kunnen komen zonder vCenter, is niet voor iedereen weggelegd.

Het topic lijkt een beetje ja/nee-spelletje en ik blijf gewillig meelezen maar denk dat elke beheerder voor zichzelf de afweging het beste kan maken of, hoe & waar je je management gaat inrichten.

[DukeBox]

mister9 schreef op dinsdag 18 augustus 2015 @ 17:54:
...kan ik via m'n fysieke Vcenter nog bij m'n SAN, NAS, Switches, etc.

Dat is hoe dan ook niet correct, dat loopt altijd via een host.

[Question Mark]

Wim-Bart schreef op woensdag 19 augustus 2015 @ 19:40:
[...]
Het jammere van VMware is dat ze veelal beargumenteren dat je je VC zo dicht mogelijk bij je infrastructuur moet hebben dus is de beste plaats binnen je ESX farm zelf als VM.

Heb je hier artikelen over dan? Dat komt mij helemaal niet bekend voor. Sterker nog, met hun nieuwe VCloud producten beargumenteren ze zelfs dat je een public (V)cloud kunt managen vanaf je lokaal gehoste VCenter instance. Dat staat lijnrecht tegenover wat jij nu beweerd.

Ik kan overigens je redenatie prima volgen hoor. In een omgeving met weinig kennis en waar de procedures niet op orde zijn is een fysieke VCenter prima te verantwoorden (en waarschijnlijk de beste oplossing). In een fatsoenlijke Enterprise omgeving zou ik echter altijd kiezen voor virtueel.

KillerAce_NL schreef op woensdag 19 augustus 2015 @ 20:09:
Incompetentie en slechte procedures vang je niet op met een fysieke bak. Als men als een prutszooi heeft, dan kun je er vanuit gaan dat dan ook de disaster recovery voor die enkele bak niet in orde is.
Ben je nog harder genaaid.

MAX3400 schreef op woensdag 19 augustus 2015 @ 20:40:
[...]
Het topic lijkt een beetje ja/nee-spelletje en ik blijf gewillig meelezen maar denk dat elke beheerder voor zichzelf de afweging het beste kan maken of, hoe & waar je je management gaat inrichten.

Eens met bovenstaande. In de voorbeelden van Wim-Bart lijkt hier compleet aan voorbij gegaan te zijn. Het vervelende is vaak alleen dat je dit als externe consultant niet op kunt lossen, zeker niet als je maar voor een relatief kleine klus ingehuurd wordt. Dan moet je de beste oplossing zoeken die op dat moment het beste past bij de klant.

[paulhekje]

In een kleine omgeving adviseer ik meestal 1 fysieke management server met backup, vCenter, monitoring e.d.
Is voor een gemiddelde beheerder, of zijn vakantievervanging het eenvoudigst te begrijpen, en zo worden er minder fouten gemaakt bij storingen.

[mister9]

DukeBox schreef op woensdag 19 augustus 2015 @ 21:25:
[...]

Dat is hoe dan ook niet correct, dat loopt altijd via een host.

Hoezo? Tuurlijk is de SAN, switch etc op de host aangesloten, maar deze zijn natuurlijk wel gewoon los van de hosts te benaderen.

[DukeBox]

mister9 schreef op donderdag 20 augustus 2015 @ 12:25:
Hoezo? Tuurlijk is de SAN, switch etc op de host aangesloten, maar deze zijn natuurlijk wel gewoon los van de hosts te benaderen.

Dan moet je wel daar ook directe verbinding naar hebben.. dus offsite wordt dan al lastiger als je (native) FC gebruikt.

[Question Mark]

Een beetje SAN heeft natuurlijk dedicated management interfaces. Dat voorkomt dat je managementtaken moet gaan uitvoeren over je storagenetwerk.

Security-technisch wel zo fijn....