VMWare View 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.  I found this out the hard way by having a single service fail all of my desktops.  To counteract this lack of documentation I've decided to create a document on my own.  I call it VMWare View 4.5 Design and Deployment 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 you users going to be when one service, one server, one switch, knocks out all of these users.  IMO 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 (I'm not incorporating offline desktops at this point).  To accomplish this goal I'm going to need these components:
  • 2 vSphere Clusters
    • I think its very short sited to run one vSphere cluster for both your server infrastructure and your desktop infrastructure.  You really should have purchased the View Premier license which comes with free ESXi anyway, if this is hte case then seperating the clusters comes at no license cost.  Also, keep in mind you are not allowed to use the View ESXi license to host servers (except those that are used to run the View environment).  In any case, don't be cheap, separate these clusters.
  • 2 View Connection Servers
    • The View Connection Server is the brokering server, they establish the connection to the View Agent.  Redunancy is built into the product, all you have to do is install a second "replica server".  Also, keep in mind if you want to do external PCoIP connections you will need 4 View Connection Servers (I don't like it anymore than you do).  Two of these servers will be used for internal redundancy, two will be used for external.
  • 2 vCenter Servers
    • You'll need to use vCenter Heartbeat, as its the only way I know how to make vCenter Servers redundant, be prepared to freak out a little bit, its expensive.  VMWare doesn't say that you need to make the vCenter server redundant, however my vCenter service being down was the reason why I had an entire department unable to connect early one morning.  For the most part you don't need vCenter, except when you need to boot a linked clone VM... if this server fails at night and you VMs are down (or being rebooted) you can expect a very bad morning.  Again, build for redundancy, and get VMWare to add Heartbeat to the Premier license!!!
  • 2 SQL Servers
    • I won't go into detail on this.  I use SQL 2008 with Microsoft Failover Clustering.  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.
  • 1 PCoIP Management Console
    • This requirement is if you are using the Teradici Zero Clients.  This appliance doesn't need redundacy because without it everything continues to work.  I just dropped it in here to evangelize the product, I like Zero Clients.