Should I use a seperate Virtual Center for my View Horizon 6 deployment?

[ejward]

I'm in a position where I am starting off fresh with a new View deployment.  New hardware, newest version, etc.  Should I have a separate Virtual Center server dedicated to View?  We have a dedicated one for our old v5 environment and I found it cumbersome to manage a separate VC.  What would be the benefits of having a dedicated VC?

[larsonm]

Best practice is to use a dedicated vCenter for View.  The licensing for vCenter and vSphere for all desktops comes with all flavors of View licensing.  The activity pattern for View is much different than that of a server environment.  Mixing the two patterns can cause bottlenecks, overload the vCenter server or result in provisioning problems.  This is especially true if you are using linked clones that refresh or delete at logoff.

[chulerico]

At first it might seem like a good idea to keep the same vCenter, but the benefits of having it separate out weight having a single one, licensing, upgrade, backup, resources needed are quite different. Sure every environment is different and in yours its up to you, but in mine just makes sense to have it separate makes my deployment more flexible, I can upgrade one when required without disrupting the other, the last thing I need is problems with the whole environment just because of an upgrade.

I think most will say separate for the above reasons too

Separate vcenters for View and Servers? : vmware

though this was a bit different point of view by unsichtbareunsichtbareunsichtbare

"There is a licensing argument in favor of running separate Clusters for Horizon View, but separate vCenters seems excessive and wasteful."

Sam

[unsichtbare]

And I stand by my original point of view on this topic.

vCenter is not a clustered service, therefore having 2 of them does not contribute to the availability of either. Moreover, it is expensive and wasteful of resources (unless you have vCenter licenses to burn, the last time I looked it cost around $5,000 not including support).

In fact, one vCenter in Dallas, for example, would be more than capable of managing clusters is Las Vegas, Atlanta, and New York City.

Another common mis-conception about vCenter is that it somehow tunnels or manages Virtual Machine connectivity. Even if a vCenter were offline completely, that does not change user connections to Horizon View connectivity in any way. The Horizon View connection tunnels at the Security Server, is brokered by the Connection Server and goes directly to the VM. vCenter is not involved, unless the desktop is deployed on demand.

[chulerico]

unsichtbare,

Thanks for the input, shows that every environment is difference.

just a few highlights:

"vCenter is not a clustered service" but it was possible to be clustered it with VMware heartbeat (neverfail), ran this in the past as it made sense for my view setup, not so much for servers - great solution, but currently being phase out in favor or sql always, etc

"Moreover, it is expensive and wasteful of resources (unless you have vCenter licenses to burn" - see plenty of the same situation above, already own vCenter, and is getting another copy included with view, so no extra licenses required unless one considers maintenance (which VMware might have an issue if the *correct* vCenter is not being used).

"capable of managing clusters is Las Vegas, Atlanta, and New York City." Yes see this often, long distance management, but mainly see it with servers, but view does make much more tasks and noise than regular server cluster.

"vCenter is not involved, unless the desktop is deployed on demand." key point here, if the machines are on demand, or if they are off, and users try to connect, no vCenter, brokers cannot turn on the machines unless done manually.

Thanks

Sam

[larsonm]

I like everything you've said, but would like to add that VMware has quietly added MSCS/WSFC support for vCenter with version 5.5 Update 2.

VMware KB: Supported vCenter Server high availability options

[atbnet]

Hi ejward,

I design and implement a lot of Horizon View environments and would always recommend a seperate dedicated vCenter for View.

The pros and cons for a seperate vCenter for View can be viewed as the following:

Pros:

• Seperatation of server/desktop vCenters servers can help with upgrades and remove dependancy issues i.e. you may choose to upgrade View to the latest version which requires a vCenter upgrade but you cant upgrade the server vCenter because the backup solution doesnt support the latest vCenter version yet.
• If you are a larger company seperating desktop/server team permissions at a top level vCenter may be useful
• If the View deployment is going to trigger many re-provisioning/refresh operations this has an effect on the vCenter operaitons for servers (i.e. number of vMotions, clones, snapshots etc).
• If you are going to use View composer you can co-locate it on the dedicated View vCener (but you may not want to if you were using the same vCenter for desktops/servers as an upgrade would require a vCenter restart for servers).
• Does not cost any more in regards to vCenter licensing (because View includes vCenter Server for Desktops)

Cons:

• Its an additional server/vCenter to manage / uppdate / upgrade
• It will require additional compute/stroage resources (somwhat not appliable as you would increase the existing vCenter server specs if you were to use the existing one for desktops/servers anyway)
• It may cost another windows license (and AV etc) depending who you license software
• IT may require another SQL database (if you arent going going to use the appliance or vPostgre DB)

Thats just a few points off the top of my head, but I'd certainly recommend a seperate vCenter for View. So many times I've found support for interdependcies to be a problem. It's usually a backup team hasnt updated to the latest version to support vCenter version x, so we can't upgrade it to support View version x so we can use Windows 8.1 or 10 desktops.

It's just simpler to seperate it, but you would provision the View vCenter VM on the server cluster 🙂

Thanks,

Andy

[six4rm]

I'm in the situation where we've been running with a single vCenter Server for both our Horizon View and Server Virtualisation platform and because we're running View 5.3 I've not updated vCenter beyond 5.5 otherwise it would be unsupported. I'm now architecting a new environment for View 6.2.1 and I'm thinking of standing up a separate vCenter Server specifically for View. It makes total sense to split the workload.

What I'm not sure about is if I'm using two separate Windows vCenter Servers should I provision a separate SQL Server for the VDI elements? I could easily put both VDI and Server databases on one SQL Server but then that's an instant single point of failure, which goes against what we're trying to achieve. What are your thoughts?