After the whole MSCS’ed vCenter support discussion VMware Technical Marketing reached out to me. Lets be clear, the intention of this article is not to change support. The intention of this article is to get an idea of how many of you would be interested in seeing a whitepaper on vCenter resiliency with MSCS/VCS which could be supported on best effort by GSS.
I was asked to figure out what would most interest you. I appreciate any comments around this but specifically would love to have answers on the following:
- Based on which technology would you prefer to see a whitepaper? MSCS or Veritas Clustering?
- Would you be looking for a total solution including VMware Update Manager and Orchestrator or just purely vCenter Server? In case of the total package, why?
- Are there any other components that would need to be included in a whitepaper?
Again, any help / answer / comment is very much appreciated.
1. MSCS, I would gather that the majority is not using Veritas
2. Only vCenter (perhaps orchestrator as well) Update Manager is not IMHO a mission critical component and will survive the downtime.
Regarding Orchestrator – I can see the use case of having that this as a important part of the infrastructure and that downtime would be an issue
3. Even though it is not so much in the scope I would go with adding the SQL components (be they local to the vCenter / or on a remote server) as well
I would prefer to see an option much like vCenter Heartbeat. However, VCHB is a bit pricy and the interface is a but klunky. While it does work well, it could use a visual makeover.
My experience is that MSCS works, and works well, but can introduce another layer of complexity, and problems. As a VM, it also reduces the ability to vMotion which in turn, obviously breaks things like DRS.
I would love to see a solution/whitepaper that included vCenter, VUM, and SQL. For many environments, those can all be run on the same VM without performance problems. While it may be considered a “best practice” to separate them, it can lead to having to DR three VMs rather than a single VM.
In my opinion, if VMware reduced the price of VCHB, a lot of the vCenter+MSCS questions/issues would go away.
MSCS here… Only vCenter would probably suffice, but just as long as that included things like the management webservices which is necessary for hardware heath, service status, etc.
Frankly, Id rather see vCenter and VMware in general move away from expensive and fragile Windows dependencies for utility infrastructure rather than further entrench on the platform.
Hi,
In the past I’ve clustered VC 2.5 on Windows 2003 using a Majority Node Set Cluster Quorum with a file share whitness in a 3rd site. The SQL database was on seperate servers and was mirrored over 2 sites with also a SQL whitness server. Although not really documented as supported it worked pretty well. I specially went for this config because it doesn’t give me any dependency on shared storage or replicated shared storage.
With vCenter 4 it all seems more complicated because of ADAM, maybe that’s only a misconception, I don’t know. Some best-effort support doc’s would sure be of great value.
Kind regards,
Koen
1. MSCS as we also use it for Exchange etc.
2. vCenter only, the rest I could do separately and are not as critical to me
3. I’d like to have a working,native alternative to MSCS
1. MSCS for sure. It’s highly used in our environment and likely in that of many others that highly rely on an ability to access vCenter throughout the API.
2. I can’t personally envision a need to cluster or protect other VMware products to the extent that I need vCenter protected…but others might have better use cases.
3. Specifically laying how best to deal with the issues that arise with ADAM would be greatly appreciated by many I’m sure.
Frankly, I also would love to move away from such clustering options and onto a technology such as Heartbeat. That said however, the benefit gained from Heartbeat is not great enough in my mind, as well as many others I’m sure, to justify the inflated cost of the product in most environments when clustering almost gets you there…for less cost. I’d like to hear from an internal perspective about how successful VMware thinks Heartbeat has been as an offering.
The amount of infrastructure requried outside of the vSphere Hypervisor (ESX/ESXi) is getting enormous and unwieldy
You need a couple of clustered Windows based vCenter servers and the same for the SQL boxes as well as VMA appliances for ESXi management – way too much complexity and management overhead.
vCenter either needs to be rolled into a resilient virtual linux appliance (embedded PostgreSQL) that can be load balanced/clustered or the total function of vCenter needs to be injected into each ESX server for availability and resilency
1) MSCS as you’ll have a much higher adoption rate. Fewer use Veritas in general. Neverfail of course is already in vCenter Heartbeat.
2) Not as interested in the auxillary elements (i.e. VUM) as I am unaware of an environment where these would be deemed mission-critical. HA/DRS is what we really want to protect.
3) Databases should be addressed as some use local SQL and others use remote.
Having said that, I would hope that most organizations would look at vCenter Heartbeat which most should be able to get for around $10K US. If your vCenter server is already a VM, it will automatically clone it and begin the replication process. It will also monitor the vCenter server, and even provide an extra level of database protection. If an IT shop has made a significant investment in vSphere, this strikes me as a more complete solution than setting up a manual clustered solution (supported or not).
My main concern is about vCenter Heartbeat w/ oracle rdbms (RAC, 10/11g).
While we chose Heartbeat as our HA solution for vcenter server, we had to dismiss it, because it created more harm than help (issues with db connection left open by the failing VC, etc.). I’m totally fine about using a dedicated product such as vCenter Heartbeat instead of MSCS, VCS etc, but the lack of reliability in our scenario (vcenter server w/ external db on Oracle RAC 10/11g), makes the product useless. Sadly.
So far we’ve been sticking with our phys. vCenter Server, doing a continuous p2v to a vm for “near HA” purposes.
I would love to see a vCenter virtual appliance that can be protected by FT, and even better, using a PSA mirror driver to protect the vCenters VMDK files
Keep it simple ….
In response to PJ’s comment “vCenter Heartbeat w/ oracle” the following KB 1021194 explains how to configure the vCenter connection behaviour when Oracle is remote. The default KeepAlive setting maintains a lock on the database preventing vCenter from restarting whether Heartbeat is installed or not. By adjusting the connection parameters the Oracle lock will be released far sooner, and allow vCenter to restart and reconnect to the database.
Hope this helps, and you can re-eval vCenter Heartbeat for your environment
Stu
I really would like an appliance too.
1. MSCS
2. vCenter Server only
3. supported configurations, best practices
And finally application aware HA for vCenter Server (API is ready in vSphere 4.1) would be nice alternative for SMB’s without budget/need for MSCS. That would be nice and simple 🙂
Best Regards
Andrzej
I would go for:
– MSCS
– vCenter Server only
There is an ongoing project called VMware vCenter Server 2.5 for Linux. I hope redundancy/resiliency features are built-in from the ground up this time!
Rgds,
Didier
Hi all
1. MSCS
2. VCenter server + Vmware Update manager – in my company different team would be responsible for patching servers
1. MSCS
2. vCenter Only.
Also I would like to see an official position of VMware on virtualize vCenter Server. Is it recommended or not ?
tks,
1) MSCS preferred
2) vCenter only, other services are not critical for platform
K.
Ruben,
vmware officially supports physical or virtual vCenter servers. Their stance is,”it’s a matter of personal/organizational perference.”
All vCenter services should be included in an HA design. This seems very challenging though given many of them are recommended to run on separate servers in large environments. Maybe extending the core vcenter heart beat technology for vum, orchestrator, etc…
Interested to see what they come up with though.
It was my understanding that vCenter WAS supported with MSCS ever since 1.4 patch-level 4. So unless the support statement was altered in vCenter 2.x, it is news to me that support statement has changed.
It seems clear to me that VMware have created a management system which has multiple points of failure – VC and stand-alone DB. So it does seems to me odd, that current stance “don’t call us to fix your MSCS problems” is an odd. After it was VMware’s design decisions back in the VC1.x days that have created this availability challenge for customers.
It fairness I don’t think it is for VMware to support a 3rd party (Microsoft) solution, and suspect the change in support is driven by the fact that now VMware has vCHB it no longer feels compelled to support vCenter in a MSCS environment.
So I would like to see MSCS and vCenter whitepaper, and for that configuration to be fully-supported by VMware, along side its vCHB support. From what I’ve heard there is a great deal of strength or depth in vCHB support – its not a product that is wildly used, and therefore peoples exposure is quite small to it.
Vertias is no interest to me…
The way forward out this morrass is a truely federated version of vCenter. An appliance model where this no stand-alone database back end. A kind of AD model for vCenter without the Microsoft component. Something that had inherent availability from the ground up, rather than availability software retro fitted to the product, which is where are currently…
Regards
Mike
ps. been working on 6K word article on vCHB! 😀
Our primary method of application high availability outside of vmware is MSCS. However, I agree that it may be an impediment to virtualizing vCenter given all the various support issues around it. How about something along the lines of Exchange’s CCR. Maybe have primary and secondary vCenter nodes with replication going from the primary to the secondary.
adam
Whatever happened to the Linux-based VCenter? There was a technical preview, and it seems to have just died. VMware really needs to get away from having a Windows dependency. While they are at it, a Linux version of the client would be nice, too 🙂
I know… I know… have asked around internally what is happening on that front but unfortunately I can’t give any details.
I’d like to see:
1 – MCSCS or some type of internal VCenter clustering
2 – VCENTER and Update Manager only.
Will
@ William Sellers – Isn’t that what vCenter Heartbeat is for?
MSCS MNS for vCenter, VUM and SRM
Hi, is there any update on this subject, perhaps with vCenter 4.1. The mentioned kb article 1024051 has been updated and from my view there will be best effort support for third party clustering product, as MSCS. Is there already a VMware white paper for a setup available? I read some private “installation-guides” but always for basic vCenter (plus adam and and tomcat) only, without vum etc.
Regards, Stephan
I agree with the comment from “Dave O.”.
Drop the price on vCenter Heartbeat and then MCS/Veritas become moot.
One of VMware’s Global Alliance Partners will be introducing a “Uptime Appliance” for vCenter at PEX next month. It is rumored to be a fully fault tolerant hardware appliance that can drop right into an existing environment without any modifications. The price is expected to be a fraction of a vCenter Heartb eat deployment and without the clumsiness of clustering.