VMWare View 4.5 Design Best Practices
It recently came to my attention that the VMWare View Architecture Guide does not provide the best design for a fully redundant VMWare View 4.5 deployment. To counteract this lack of documentation I’ve decided to create a document on my own. I call it VMWare View 4.5 Design Best Practices. I don’t care how big or small your environment is, if you are looking into View you need to immediately consider this fact, you are moving all of your desktops (or a portion of them) into a cloud that you maintain. If you are doing this how happy are your users going to be when one service, one server, one switch, one… whatever, knocks out all of these users. In my opinion it is a serious failure to consider moving to any VDI solution unless you have a fully redundant back end. Hopefully this guide will give you the basic building blocks required to have this type of redundancy.
I’m not going to get fancy here, I’m designing a basic View Deployment that will cover 100-500 desktops. To accomplish this goal I’m going to need these components:
vSphere Clusters:
This is a licensing requirement. You are not allowed to run Server VMs on the View Premier license, and let’s face it, if you are building 100+ VMs, you bought the Premier License (if not call your VMWare Partner)
View Connection Servers:
The View Connection Server is the brokering service, they establish the connection to the View Agent.
vCenter Servers:
You’ll need to use vCenter Heartbeat, as it’s the only way I know how to make vCenter Servers redundant, be prepared to freak out a little bit, its expensive. VMWare Documentation doesn’t say that you need to make the vCenter server redundant, however, if you have a linked clone VM shutdown and if this service is not running the VM will not boot!
SQL Servers:
Why make this redundant? Well, my vCenter DB is on this, my Events DB is on this, my View Composer DB is on this. Basically every component of a View setup has a DB, so I want these DBs on a redundant back end, and yes if Composer can’t access the DB you have problems.
Security Servers:
However, I’d hold off on deploying any security server as a future Security Server will support PCoIP over the WAN, if you were at VMWorld you probably saw this.
Everything I listed above I virtualize, this way I take advantage of further redundancies built into ESX (HA/SRM).
The good news is that most of this is simple stuff, you can do an NLB or Round Robin for your VCS Servers, or Security Servers; it really is going to pertain to your environment and what you are trying to accomplish. In the end you should have two clusters that look something like this:
I just wanted to add a comment that this design is now outdated. I plan on posting a full DR design in the "near" future. Whenever I get around to it is near enough. 
