VMware Horizon View High Availability

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.

A View Connection server only needs access to the View Composer for recomposing images and refreshing VMs. View only needs access to vCenter to power on/off VMs and to complete any operation that the View Composer is required for.

For small environments, it is often acceptable to have outages on the View Composer or vCenter server in the 5-30 minute range as logins and access to the View environment are not immediately affected by View Composer downtime. System administrators should be aware that this situation can eventually cause a login outage. If desktops are configured to refresh or recompose after a logoff, in the absence of a functional View Composer, the pool of desktops will eventually be exhausted. Users will not be able to start new sessions when the pool of available desktops is exhausted.

For View environments with dedicated desktops, it is possible to operate without the View Composer for days as it is very rare to require Recompose or Refresh operations.

First, we determine whether we are going to install the View Composer on a dedicated machine or on the vCenter.

The View Composer currently can only be installed on a Windows 2008 R2 or higher version server. If you are using a vCenter appliance, you cannot install the View Composer on that appliance and you will require a separate Window Server VM for the View Composer.

When vCenter is installed on a Windows server, the View Composer can be co-installed on that server. In practice, the performance requirements for the View Composer are much smaller than the vCenter Server. Since vCenter and the View Composer have similar High Availability requirements, in practice co-location should be considered best practice unless dealing with a very large View environment.

The following steps need to be performed:

Next, we will install the View Replica Server:

Next, we will configure the View Connection servers for use with our environment:

We have now configured two View Connection servers in a redundant pair. The ADAM database stored on each View Connection server will now automatically replicate any changes made to the rest of the cluster.

Our first task is to set up a DNS round robin. In this scenario, we are going to configure a DNS entry for each View Connection server and then a shared DNS entry for DNS load balancing. We also need to install a certificate on both View Connection servers that match the DNS entries we will be using.

Configure the following on the DNS server:

After this is set up, all View clients should be configured to use the shared FQDN. The client will automatically switch View Connection servers in the event of an outage. Note that the outage will still cause a client to disconnect in most cases.

Once DNS is set up, we can move ahead and configure the certificates on the View Connection servers. We can set up the certificates in one of the following manners:

For each method used, install the certificate in the Computer Certificate Store of each of the View Connection servers. Make sure to set the friendly name of the certificate to vdm. Once the certificate is installed, restart the View Connection server and HTML Access services. You can verify that the certificate is correctly installed by navigating a web browser to the Administration Interface of each View Connection server. The certificate presented to the web browser should match the one installed.

Once all our services are in place, we need to configure vCenter to run our systems in a High Availability aware manner. Note that for systems that are configured only with local storage, we can skip these steps; High Availability and DRS don't apply to systems that only have local storage.

We will configure the following in the next steps:

We will now walk through the steps to configure vCenter:

For hosts that only have local storage, having properly configured startup and shutdown rules is essential as there is no way to migrate VMs off the host during the event of a power failure or host failure. You should configure the host so as to power on the VMs with local storage to ensure that they re-join the cluster. Note that while ESXi clusters with High Availability and shared storage make this step optional, it is best practice to have this configured anyway.

We will configure the VM startup/shutdown rules for the hosts now: