Configure Azure NetApp Files with Azure VMware Solution running VMware Horizon - (Part 2)

[Raj_Sharma3]

Written by: Husam Hilal 

(posted by Raj.Sharma@netapp.com)

original link: Using Azure NetApp Files to Address App Volume Replication Concerns in Multi-Site VMware Horizon Deployment with Azure VMware Solution (microsoft.com)

 

Overview

Cloud bursting is one of the common use-cases for Azure VMware Solution (AVS). It could be in the form of extending VDI solution, such as VMware Horizon, to AVS. This article explains a solution that addresses one of the concerns related to App Volume Replication when implementing multi-site Horizon deployment where AVS Private Cloud is one of the sites.

Background

When customers decide to expand their existing Horizon infrastructure to Cloud, VMware recommends a multi-site Horizon implementation using a multi-instance model with separate instances per site. Each instance works independently, with its own set of App Volumes Managers and its own database instance. Using separate instances per site is simple to implement and allows for easy scaling. Moreover, it provides resiliency therefore in case of outage, the remaining instance in the running sites can provide access to Packages and AppStacks with no intervention needed.

VMware Horizon leverages App Volumes to provide real-time application delivery and lifecycle management. In multi-site implementation App Volume Replication uses Storage Groups as a solution that can synchronize Packages and AppStacks across sites. Storage Groups, which define logical groupings of datastores, makes this possible by looking at anything that resides in one datastore (i.e., on-premises) within the Storage Group and making sure that it exists in all the datastores within that Storage Group. Thus, if the same datastore is part of two different Storage Groups at two different sites (on-premises and AVS), then this will guarantee that Packages and AppStacks are being replicated across multiple (two) sites.

Storage groups containing a shared, non-attachable datastore can be used to automatically replicate packages from one instance of App Volumes to another. As this shared datastore is configured to be non-attachable, it will not be used to deliver attachments to user machines, so does not need to be overly performant, and often a low-cost NFS share is used to provide this.

Problem

One of the questions that needs an answer when configuring Storage Groups for App Volume Replication in a multi-site Horizon deployment is: What is the datastore that can be part of the Storage Group at AVS in Azure (Site 2) and, at the same time, part of on-premises (Site 1) Storage Group?

 

Solution

First, let’s understand the requirements; notice that the datastore needs to be part of two separate Storage Groups, each configured at both Horizon infrastructure sites. Thus, technically we need a datastore that we can mount to VMware vSphere stack in Azure (AVS) and, at the same time, mount it to VMware vSphere stack at on-premises.

This is where Azure NetApp Files (ANF) volume as a datastore comes in (see diagram below). ANF is a fully managed Cloud service that provides high-performance file storage. With Azure NetApp Files, you can create a high-performance NFS datastore that can be used as a storage solution for your AVS Private Cloud. Currently, ANF volume is the only feasible and economical solution that allows adding additional datastore for expanding AVS Private Cloud cluster storage without scaling up with additional hosts.

Now, keep in mind that, ANF account uses a concept in Azure networking known as delegated subnet. To simplify things a bit, you can imagine that the ANF account is connected to a network subnet in an Azure Virtual Network (vNet). Thus, this allows customers to get a predictable private address for the ANF volume once created. Thus, in addition to mounting that NFS datastore to AVS cluster, which is a feature, you can also mount it to on-premises VMware vSphere environment as long as connectivity is established either through Azure ExpressRoute or Site-to-Site VPN.

Implementation

The instructions below help you achieve the solution discussed above. Also, make sure to follow the Best Practices section in this article:

1. Create Azure NetApp Files account. More details here.
2. After creating an ANF account in Azure, create a Capacity Pool with minimum of 2 TB capacity, with Standard storage tier. You may keep QoS as Auto.
3. Create a Volume inside the Capacity Pool created in the previous step. You may set the Quota to 2048 GB. If it was not done before, you may need to create a designated subnet in existing Azure vNet that is connected to AVS Private Cloud through an Azure ExpressRoute Connection. Make sure the selected Protocol Type is NFS and uses version 3. Lastly, check Azure VMware Solution Datastore checkbox (Enabled).
4. Mount the Volume to AVS Private Cloud, as explained here.
   
5. Mount the Volume to On-Premises vCenter, assuming you have the line of sight (connectivity) from on-premises to Azure vNet where ANF subnet delegation is configured. You’ll need the private IP address of the Volume with the mounting path. 
6. Test by uploading a file to the datastore at one of the sites (i.e., on-premises). Now, you may notice that the file is immediately shown on the other site (AVS). Technically, that is because it is the same datastore.
   
7. The last step would be configuring VMware App Volumes, by creating Storage Group at both sites, and selecting the ANF Volume datastore in each of the Storage Groups, so it becomes the common ground for replication.

 

Best Practices

To achieve the best results, make sure you follow the best practices when configuring AVS and creating ANF account as documented here. For example:

• Make sure to use UltraPerformance or ErGw3Az SKU for the Azure ExpressRoute Gateway when connecting between AVS Private Cloud and Azure Virtual Network (vNet).
• Make sure to enable FastPath on the Azure ExpressRoute Connection.

• Make sure to place ANF account in the same region and same availability zone (AZ) of AVS Private Cloud.
• Make sure to choose the proper storage tier for ANF Capacity Pool. For this specific use-case (Horizon/App Volume Replication), Standard storage tier should be fine.

  • Note: During the initial setup of a new cluster, if you are transferring all AppStacks, consider enhancing the throughput and performance of your volume by opting for either the premium or ultra service level. Alternatively, you can initially create a capacity pool with the premium or ultra service level. Once the data transfer is complete, you can scale back the volume to the standard service level after the 24-hour cool-down period.

  • When changing the service level for an Azure NetApp Files volume mounted on AVS, you must also run an Azure CLI command to synchronize the metadata. This process does not affect the data plane.

• Make sure to choose Standard network features when creating the ANF volume to enable optimized connectivity from AVS Private Cloud.
• Make sure to maximize Volume size to Capacity Pool size. Keep in mind that customers will pay for the Capacity Pool size not the Volume capacity. Moreover, capacity and performance in ANF accounts are proportional. In other words, the higher capacity the higher performance. For example, if you create a 2 TB Capacity Pool, then create 2 TB volume as well if you are not using that Capacity Pool for other purposes.

Summary

In this article, we addressed a concern at configuring App Volume Replication leveraging Storage Groups when implementing VMware Horizon multi-site design where AVS is one of the sites. We also explained how Azure NetApp Files service was used to provide a datastore that is mounted to AVS Private Cloud cluster and mounted to on-premises environment, and best practices associated with that.