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.<!--more-->

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:

<strong>2 vSphere Clusters:</strong>

This is a licensing requirement.  You are not allowed to run Server VMs on the View Premier license, and lets face it, if you are building 100+ VMs, you bought the Premier License (if not call your VMWare Partner)

<strong>2 View Connection Servers:</strong>

The View Connection Server is the brokering service, they establish the connection to the View Agent.

<strong>2 vCenter Servers:</strong>

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 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!

<strong>2 SQL Servers:</strong>

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.

<strong>2 Security Servers:</strong>

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).
<p style="text-align: center"><a href="http://blogs.eGroup-us.com/wp-content/uploads/2010/10/View-Design-2.jpg"><img class="size-full wp-image-2809 aligncenter" src="http://blogs.eGroup-us.com/wp-content/uploads/2010/10/View-Design-2.jpg" alt="" width="603" height="444" /></a></p>
<p style="text-align: left">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:</p>
<p style="text-align: center"><a href="http://blogs.eGroup-us.com/wp-content/uploads/2010/10/ESX-Server-Cluster.jpg"><img class="size-full wp-image-2810 aligncenter" src="http://blogs.eGroup-us.com/wp-content/uploads/2010/10/ESX-Server-Cluster.jpg" alt="" width="603" height="444" /></a></p>
<p style="text-align: center"><a href="http://blogs.eGroup-us.com/wp-content/uploads/2010/10/ESX-Desktop-Cluster.jpg"><img class="alignnone size-full wp-image-2811" src="http://blogs.eGroup-us.com/wp-content/uploads/2010/10/ESX-Desktop-Cluster.jpg" alt="" width="603" height="444" /></a></p>