Starting with the September 2019 quarterly service release, the architecture of a Horizon Cloud pod in Microsoft Azure supports having high availability for the pod. New pods deployed by the pod deployer after the September 2019 service release and older pods updated to manifest versions 1600 or later will all get this latest pod architecture. This pod architecture includes a Microsoft Azure Database for PostgreSQL server resource, a Microsoft Azure load balancer, and a Microsoft Azure availability set. When high availability is enabled on a pod of this architecture, an extra pod manager VM is added to the pod, for a total of two pod manager VMs, connected to the Microsoft Azure load balancer. This configuration enables the pod to continue to operate even if one manager VM experiences an issue. If one manager VM goes down, all traffic is automatically routed to the other manager VM without any manual intervention.

For new pods, you can deploy the pod with high availability enabled from the start, or deploy the pod with high availability turned off and enable it later. For existing pods that are updated to a pod manifest that gets this latest pod architecture, the update process does not automatically enable high availability on the pod. You can enable high availability on an updated pod after both these items are in place:

  • The pod update process is completed on that pod
  • The agents are updated on all of the pod's existing image VMs, farm RDSH-capable VMs, and VDI desktop VMs to the agent version that is compatible with the updated pod

The pod's details page reports whether high availability is enabled or switched off for that pod. For the steps to enable high availability on a pod where it is not currently enabled, see Enable High Availability on a Horizon Cloud Pod in Microsoft Azure.

High Availability Design for a Pod in Microsoft Azure

In addition to having two pod manager VMs, the pod also has a Microsoft Azure load balancer resource, a Microsoft Azure availability set, and a Microsoft Azure Database for PostgreSQL server resource. This design provides for overall pod resiliency and fail over if one of the pod manager VMs experiences an issue or goes down.

Important: A pod created new in the September 2019 release level is always deployed with a Microsoft Azure Database for PostgreSQL server resource, the Microsoft Azure load balancer, and availability set. Even when you toggle off the High Availability option in the pod deployment wizard, the resulting pod has those new pod architecture's elements. Also, a pod created in a prior release and then updated to the September 2019 release level results in a pod with this new design: the Microsoft Azure Database for PostgreSQL server resource, the Microsoft Azure load balancer, and availability set, even though high availability is not automatically enabled in the update process. Standardizing on this pod design for all pods with manifest versions 1600 or later allows for the ease of enabling high availability on an already deployed pod. The second pod manager VM is only deployed when the high availability feature is enabled on the pod.

These resources reside in the pod's resource group and you can view their details in your subscription when you log in to the Microsoft Azure portal. For information about identifying the pod's resource groups, see Resource Groups Created For a Pod Deployed In Microsoft Azure.

Microsoft Azure availability set
As described in the Microsoft Azure documentation, a combination of a Microsoft Azure load balancer with availability sets provides the highest application resiliency. An availability set, or availability zone as it is sometimes referred to in the Microsoft Azure documentation, in each Microsoft Azure region is a combination of a fault domain and an update domain. By using an availability set, each of the pod's manager VMs is deployed on separate physical hardware within the same Microsoft Azure data center. The availability set enforces the manager VMs to reside on separate physical hardware. This separation of back end hardware minimizes the likelihood of both manager VMs experiencing downtime at the same time. Only if the entire Microsoft Azure data center goes down would both manager VMs be affected.
Microsoft Azure load balancer
The deployed load balancer resource is connected to the pod's tenant subnet. This load balancer is used to route traffic to the pod manager VMs within the pod according to the pod-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 load balancer sits between the end-user client connection requests and the pod manager VMs within the pod. When the pod is configured with a gateway configuration, traffic from the Unified Access Gateway instances routes to the pod's Microsoft Azure load balancer. That 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, such as over VPN, the end-user client connections go to the pod's Microsoft Azure load balancer, which routes that traffic to the active pod manager VM.

Microsoft Azure Database for PostgreSQL - Single Server
The pod has a Microsoft Azure Database for PostgreSQL server that uses the Single Server deployment option. Use of this server 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 following configuration is used:
  • PostgreSQL version 10
  • Memory Optimized
  • Compute generation: Gen 5
  • vCores: 2
  • Storage: 10 GB
  • Auto-growth: No
  • Backup Storage: Locally redundant
See 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. All pods created new at this release level and pods updated to this release level incur a cost for the managed Microsoft Azure Database for PostgreSQL server. A pod enabled with high availability also incurs a cost for running the additional manager VM. As of this writing, there are no costs for use of the Azure Load Balancer or availability set that are deployed for all pods created at, or updated to, this release level.

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/.