We will examine the use case of small offices and remote office deployments for VMware View. Typically, this revolves around small companies who do not possess large datacenters. We are looking at deploying servers on a small budget and are looking for ways to cut costs as much as possible. This is also applicable for small satellite offices or locations where VMware Horizon View over the Internet is not feasible.

This environment will have less than 50 VMs, 2 ESXi hosts, local storage only, along with vSphere replication.

This is a typical environment for small VMware View deployments with the minimal size. Here, we will utilize vCenter licensed with vSphere Remote Office Branch Office Standard or vSphere Essentials Plus. ESXi hosts have locally attached hard drives or SSDs or both. We have several options for deploying vCenter. We can install vCenter on a single VM with a collocated database and View Composer. To protect this VM, we utilize VMware Replication Appliance to copy the vCenter to the other host frequently. In this situation, we simply power on the vCenter replica on the other host in the event of a host failure. Note that data loss from the vCenter may occur since the replication may be out of sync. This can be acceptable for some View scenarios, since vCenter configurations rarely change. Note that a failure and recovery from the replicated vCenter may require VMware technical support to recover. This is due to the databases potentially being out of sync with ESXi hosts and other VMware products.

We can also utilize an alternative configuration using SQL Replication instead of relying on vSphere Replication. This configuration requires two licenses of the chosen database (Microsoft Standard or Enterprise Edition or Oracle database). This scenario is suitable for small offices, satellite offices, and offices where Horizon View over the Internet isn't an option. This configuration has a higher reliability than the scenario above at the cost of an extra database license.

This environment will have less than 50 VMs with 2 ESXi hosts, local storage only, and SQL replication.

Here, we install the vCenter database and the View Composer database on the chosen database cluster.

The vCenter server will host our View Composer. We can either replicate the vCenter VM using the vSphere Replication Appliance, take frequent backups using VMware Data Protection, or use a third-party backup solution. This solution benefits from not losing any database data. In the event of a host failure, recovery can be configured to be automated in with Application Clustering solutions.

With vCenter Server 5.5 Update 3 and later, Windows Server Failover Cluster is supported as an option for providing vCenter Server availability. Two instances of vCenter Server are in a MSCS cluster, but only one instance is active at a time. VMware only supports two node clusters.

We can also utilize a third-party application clustering to manage the services on two vSphere hosts such as Symantec ApplicationHA using an Active Backup configuration.

Here, we examine use cases for medium-sized offices where we will be running more than 50 virtual desktops and utilizing three or more hosts to maintain the load. This deployment is typical of companies with dedicated datacenters who want to deploy a centralized virtual desktop scenario, remote medium-size offices, small schools, and so on. We can save the cost of shared storage and simplify the recovery scenario by utilizing Virtual SAN to replicate copies of all the VMs onto separate hosts. This scenario can be scaled up to the Virtual SAN maximums of 64 hosts in 6.0 and 32 hosts in 5.5.

In this scenario, we have more than 50 VMs and will deploy three or more ESXi hosts with local storage and VMware Virtual SAN.

In a 3+ node cluster, we open up the option to use VMware Virtual SAN to protect the data stores of the ESXi hosts. By placing vCenter on the Virtual SAN datastore, we can utilize VMware High Availability to protect the vCenter server in the event of a host failure. While a second View Connection server is somewhat redundant in this scenario, I recommend two so that one will always be running in the event of a host failure. Virtual desktops can be stored on the Virtual SAN or on local storage depending on the High Availability and data requirements for the virtual desktops.

In case of shared storage deployments, we opt for a shared storage solution for our ESXi cluster. Shared storage can be required for applications that are not designed with High Availability in mind to provide redundancy or to simplify the failover scenario where high percentage uptime is not a large concern. This could be Fibre Channel SAN, NFS, and iSCSI. With three or more hosts, we can utilize Virtual SAN as our shares storage as outlined in the previous scenario.

Shared storage simplifies the High Availability plan, since it is often as easy as turning on VMware High Availability to protect the cluster and ensuring there is enough capacity to work in a failover scenario. When using shared storage, make sure to configure DRS on the cluster to ensure that redundant VMs are kept on separate hosts.

Here, we have two or more ESXi hosts with shared storage:

The shared storage scenario shares much of the same topology as the Virtual SAN scenario. By placing vCenter on the shared data stores, we can utilize VMware High Availability to protect the vCenter server in the event of a host failure. While a second View Connection server is somewhat redundant in this scenario, I recommend two so that one will always be running in the event of a host failure. Virtual desktops can be stored on shared or local storage, depending on the High Availability and data requirements for the virtual desktops.