High availability enables a Horizon Cloud on Microsoft Azure deployment to continue to operate when one of the pod's pod manager VM experiences an issue. If one pod manager VM goes down, all traffic is automatically routed to the other pod manager VM without any manual intervention.
Starting with the v2204 service release, new deployments are deployed with high availability 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.
The architecture design is based on the combination of two pod manager VMs, a Microsoft Azure load balancer, a Microsoft Azure availability set, and a Microsoft Azure Database for PostgreSQL server resource. The Microsoft Azure load balancer connects to the two pod manager VMs.
This design provides for overall pod resiliency and fail over if one of the pod manager VMs experiences an issue or goes down.
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 Horizon CloudPod 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
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/.