This documentation page describes the high availability characteristics of a Horizon Cloud on Microsoft Azure deployment.

Starting with the v2204 service release, new deployments are deployed with high availability (HA) configured by default.

If you have a pod that existed prior to the v2204 release and high availability is not currently enabled on that pod, you can enable it using the steps in Enable High Availability on a Horizon Cloud Pod in Microsoft Azure. The pod's details page reports whether high availability is enabled on a pod.

Brief Introduction

A Horizon Cloud on Microsoft Azure deployment's high availability characteristics are intended to provide for the deployment's standard operations to continue to function in the following scenarios:

  • If one pod manager VM goes down or experiences an issue, the traffic that is meant for that pod manager is automatically routed to the other pod manager VM without any manual intervention.
  • In a gateway configuration, if one Unified Access Gateway VM goes down or experiences an issue, the traffic that is meant for that Unified Access Gateway VM is routed to the other Unified Access Gateway VM without any manual intervention.

Design Elements

The Horizon Cloud on Microsoft Azure deployment's HA design uses the following elements.

The elements provide for resiliency and fail over if one of the paired VMs experiences an issue or goes down.

  • Paired VMs
  • Microsoft Azure availability set per VM pair
  • Microsoft Azure load balancer connecting the VMs in each pair
  • The Azure Database for PostgreSQL Microsoft managed service

Continue reading the following sections in this documentation page for details on how each of these design elements is used in the deployment.

Paired VMs

The Horizon Cloud on Microsoft Azure deployer deploys by default:

  • Two pod manager VMs for each Horizon Cloud on Microsoft Azure deployment
  • Two Unified Access Gateway VMs for each deployed gateway configuration.
Note: In the case of the gateway connector VM that is deployed in the deployment scenario of an external gateway configuration deployed in its own VNet, a single gateway connector VM is deployed. If the gateway connector goes down, the control plane sends an alert to the VMware Horizon Cloud Operations team, which can use API calls to address the state of the gateway connector.

Microsoft Azure Availability Set Per VM Pair

Each of the VM pairs is associated with a Microsoft Azure availability set, an availability set per VM pair.

By using an availability set, the VMs in a pair are each deployed on separate physical hardware within the same Microsoft Azure data center.

By the design of Microsoft Azure availability sets, the availability set enforces the paired VMs to reside on separate physical hardware in that Microsoft Azure data center.

This separation of back end hardware minimizes the likelihood of both VMs experiencing downtime at the same time. Only if the entire Microsoft Azure data center goes down would both VMs in a pair be affected.

Microsoft Azure Load Balancer Connecting Each Pair's VMs

As described in the Paired VMs section, a Horizon Cloud on Microsoft Azure deployment has a pair of pod manager VMs and each deployed gateway configuration has a pair of Unified Access Gateway VMs.

The deployer deploys a Microsoft Azure load balancer for each pair of VMs.

Pod Manager VMs - Load Balancer

The deployer deploys this Azure load balancer during pod deployment. This load balancer routes traffic to the pod manager VMs according to the deployer-configured health probe and rules.

  • The pod manager VMs are added to this load balancer's back end pool.
  • One pod manager VM assumes the active role in facilitating end-user client connections to the pod-provisioned desktops and applications.
  • The load balancer determines which pod manager has the active role based on the defined rules and health probe of the pod manager VMs in the back end pool.
  • Based on its determination, the load balancer routes all connection request traffic seamlessly to the pod manager VM that has the active role until a fail over occurs.
  • Then the other pod manager VM assumes the active role in facilitating the client connections to desktops and applications. At that point, the load balancer routes the connection requests to that VM.
  • When this fail over occurs, a notification is sent to the console to inform you of this change in which pod manager VM has the active role.

The pod manager VMs' deployed Azure load balancer is connected to the VMs' NICs that have IPs on what the New Pod wizard labels as the VM Subnet - Primary, also referred to as the primary tenant subnet.

The pod manager VMs' load balancer sits between the end-user client connection requests and the pod manager VMs.

When the pod is configured with a gateway configuration, traffic from the Unified Access Gateway instances routes to this pod manager VMs' Microsoft Azure load balancer, and the Azure load balancer routes that traffic to the active pod manager VM.

When the pod has no gateway configuration, and you have configured the pod for direct connections, the end-user client connections go to the pod manager VMs' Microsoft Azure load balancer, which routes that traffic to the active pod manager VM.

Gateway Configuration - Load Balancer

The deployer deploys this Azure load balancer during deployment of a gateway configuration. This load balancer routes traffic to the deployment's Unified Access Gateway VMs according to the deployer-configured health probe and rules.

  • The Unified Access Gateway VMs are added to this load balancer's back end pool.
  • Each Unified Access Gateway VM has an active role in the end-user client traffic. Each of the Unified Access Gateway VMs is intended to manage up to the pod's concurrent connected sessions up to the limits as stated in the Horizon Cloud Service on Microsoft Azure Service Limits page.
  • The load balancer determines whether a Unified Access Gateway VM in the backend pool is healthy to receive connections based on the defined rules and health probe of the VMs.
  • Based on its determination, the load balancer routes connection request traffic seamlessly to the VMs that satisfy the health probe.
  • If a VM in the back end pool has an issue or goes down, the load balancer routes any new connection requests to the healthy VM.
  • For existing connections to the VM experiencing the issue or has gone down, those connections are disconnected. Those users have to manually reconnect their client sessions, and the load balancer connects those to the healthy Unified Access Gateway VM.
  • When the unhealthy VM returns to a healthy state and satisfies the load balancer's rules and health probe, the load balancer allows new connection requests to that VM.

A gateway configuration's load balancer sits between the end-user client connection requests and the configuration's Unified Access Gateway VMs.

For an external gateway configuration, its deployed Azure load balancer is connected to the VMs' NICs that have IPs on what the deployer wizard labels as the DMZ Subnet. When the wizard is used to deploy an external gateway configuration in its own VNet, the wizard labels this subnet as Front-end Subnet.

For an internal gateway configuration, its deployed Azure load balancer is connected to the VMs' NICs that have IPs on the pod's primary tenant subnet (labelled VM Subnet - Primary in the deployer wizard).

The Deployment's Azure Database for PostgreSQL Microsoft Managed Service

The deployment uses the Azure Database for PostgreSQL Microsoft managed service, and its Single Server deployment option.

Use of this Microsoft managed service provides for centralizing data needed for pod operations and eliminates the need to use data replication across the manager VMs. In the current release, the deployer uses the following configuration:

  • PostgreSQL version 11
  • Memory Optimized
  • Compute generation: Gen 5
  • vCores: 2
  • Storage: 10 GB
  • Auto-growth: No
  • Backup Storage: Locally redundant

Refer to the Microsoft documentation for information about their Memory Optimized configuration:

Cost Impact in Your Microsoft Azure Subscription for Pods Created in or Updated to This Release Level

The elements required to support high availability in this release have some cost implications in your Microsoft Azure subscription, for use of the Azure Database for PostgreSQL and running the VM pairs. As of this writing, there are no costs for use of the Azure Load Balancers or availability sets.

For pricing estimates of the Microsoft Azure Database for PostgreSQL configuration described above that is used in the current release, see https://azure.microsoft.com/en-us/pricing/details/postgresql/server/.

Related Resource Groups

The pod managers' HA-related resources reside in the same resource group as the pod manager VMs

A gateway configuration's HA-related resources reside in the same gateway configuration's resource group as that gateway configuration's Unified Access Gateway VMs.

The pod manager's resource group also reflects the deployment's use of the Microsoft Azure Database for PostgreSQLMicrosoft managed service.

You can view the resources' details in your subscription when you log in to the Microsoft Azure portal and navigate to those resource groups.

For information about identifying the pod's resource groups, see Resource Groups Created For a Horizon Cloud on Microsoft Azure Deployment .

Enable High Availability on a Horizon Cloud Pod in Microsoft Azure

For a pod that does not have high availability enabled on it, you can enable high availability by following these steps.

This page is intended solely for those administrators who have a pod or pods on which high availability is not yet enabled.

Starting with the v2204 service release, new Horizon Cloud on Microsoft Azure deployments are deployed with high availability already configured by default. When high availability is already configured on the pod, this page's steps are not applicable.

If a pod's details page indicates that high availability is not enabled, you can edit the pod to enable high availability on it. In this process, a second pod manager VM is deployed to the pod's resource group, and that VM is configured in the pod's Microsoft Azure load balancer and availability set.

Important: Enabling the pod for high availability is a one-time action. After a pod is enabled for high availability, you cannot later revert the configuration and deactivate the feature on the pod.

After you perform the Edit Pod workflow steps and confirm the update, the service instantiates the second pod manager VM in your pod's Microsoft Azure subscription and makes the appropriate connections between that VM to the existing Azure load balancer, Azure PostgreSQL database, and other necessary pod-related tasks. The overall process can take approximately 30 minutes to complete.

Prerequisites

Verify you meet these criteria before using the Horizon Universal Console to perform the workflow steps.

  • The pod software must be at manifest version 1600 or later to be enabled for high availability. You can see a pod's manifest version by navigating to the pod's details page from the Capacity page.
  • Ensure your subscription has enough quota and cores to accommodate creation of the additional pod manager VM.
  • If the pod was updated from a manifest version earlier than 1600, before you can enable it for high availability, you must ensure:

Procedure

  1. Navigate to the pod's details page from the Capacity page.
  2. Click Edit.
  3. In the High Availability section, switch on the toggle for Enabled.
  4. Click Save & Exit.
  5. Confirm the update.

Results

On the pod's details page, the cluster status shows Pending state. When the configuration activity is finished, the cluster status shows Ready state. The overall process takes approximately 30 minutes to complete.