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 .