Horizon 8 on Azure VMware Solution Architecture

This chapter is one of a series that make up the VMware Workspace ONE and VMware Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of VMware Workspace ONE® and VMware Horizon® solutions. This chapter provides information about VMware Horizon on Azure® VMware Solution. A companion chapter, Horizon on Azure VMware Solution Configuration, provides information about common configuration and deployment tasks for VMware Horizon on Azure VMware® Solution.

Introduction

VMware Horizon for Azure VMware Solution (AVS) delivers a seamlessly integrated hybrid cloud for virtual desktops and applications. It combines the enterprise capabilities of the VMware Software-Defined Data Center (SDDC), delivered as infrastructure as a service (IaaS) on AVS, with the market-leading capabilities of VMware Horizon for a simple, secure, and scalable solution. You can easily address use cases such as on-demand capacity, disaster recovery, and cloud co-location without buying additional data center resources.

Figure 1: Horizon on Azure VMware Solution Overview

For customers who are already familiar with Horizon or have Horizon deployed on-premises, deploying Horizon on Azure VMware Solution lets you leverage a unified architecture and familiar tools. This means that you use the same expertise you know from VMware vSphere® and Horizon for operational consistency and leverage the same rich feature set and flexibility you expect. By outsourcing the management of the vSphere platform to Microsoft, you can simplify management of Horizon deployments.

Note: Horizon 8 2006 and later can be deployed on Azure VMware Solution. Horizon 7.13 cannot be deployed on Azure VMware Solution.

For details on feature parity between Horizon on-premises and Horizon on Azure VMware Solution, as well as interoperability of Horizon and Azure VMware Solution versions, see the VMware Knowledge Base article VMware Horizon on Azure VMware Solution (AVS) Support (80850).

The purpose of this design chapter is to provide a set of best practices on how to design and deploy Horizon on Azure VMware Solution. This chapter is designed to be used in conjunction with Horizon documentation and the Azure VMware Solution documentation.

Architectural Overview

Components

The individual server components used for Horizon, whether deployed on Azure VMware Solution or on-premises, are the same. See the Components section in the Horizon Architecture for details on the common server components.

The components and features that are specific to Horizon on AVS are described in this section.

Software-Defined Data Centers - Azure VMware Solution Private Clouds

Azure VMware Solution allows you to create vSphere Software-Defined Data Centers (SDDCs) on Azure. These are also referred to as Azure VMware Solution Private Clouds. See Azure VMware Solution private cloud and cluster concepts. Throughout this document we will use the term SDDC.

These SDDCs (Azure VMware Solution Private Clouds) include VMware vCenter Server for VM management, VMware vSAN™ for storage, and VMware NSX® for networking.

You can connect an on-premises SDDC to a cloud SDDC and manage both from a single VMware vSphere Web Client interface. Azure VMware Solution is a native Azure service and has native integration with Azure’s broad ecosystem of services including DR, Backup, Azure Active Directory, Azure management and security services, Azure Cognitive Services and more. For more information, see the Azure VMware Solution documentation.

After you have deployed an SDDC on Azure VMware Solution, you can add this SDDC as capacity to your Horizon Connection server to run your VDI workloads such as Desktops or RDSH hosts. This enables Horizon customers to outsource the management of the SDDC infrastructure to Microsoft. There is no requirement to purchase new hardware, and you can use the pay-as-you-go option for hourly billing on Azure VMware Solution. See Azure VMware Solution pricing.

The SDDC compute component is used to run the virtual desktop machines, for VDI, and RDS Hosts, for published applications and shared desktops.

Azure Components

• vNet and subnets for Management and DMZ networks. See Network Configuration.
• Express Route Gateway for Connecting AVS SDDC to VNET
• Azure Load Balancer (ALB) for External /internal Load Balancing
• Azure Traffic Manager (ATM) for Global Load Balancing

Horizon Management Components

To allow scaling beyond a single SDDC, the recommended deployment of Horizon in Azure VMware Solution locates the management components in Azure and not within the SDDCs. By locating the management components, such as the Unified Access Gateways, outside of the SDDC, only network traffic intended for a particular SDDC is routed towards that SDDC.

This includes the following management components:

• Horizon Connection Servers
• Unified Access Gateway appliances
• VMware App Volumes™ Managers
• Load balancer
• Horizon Cloud Connector
• File shares for user data and VMware Dynamic Environment Manager™ configuration data
• Database Server for App Volumes and Horizon events

Figure 2: Horizon Components and Logical Architecture

Table 1: Management Component Placement

NSX-T Components

VMware NSX-T™ Data Center is the network virtualization platform for the Software-Defined Data Center (SDDC), delivering networking and security entirely in software, abstracted from the underlying physical infrastructure. See the Understand NSX-T activity path for more information.

The maximum number of ports per logical network is 1000, you can also use multiple logical networks per pool with Horizon by leveraging the Multi VLAN functionality.

• Tier-0 router – Handles Internet, route or policy based IPSEC VPN, and serves as an edge firewall for the Tier-1 Compute Gateway (CGW).
• Tier-1 Compute Gateway (CGW) – Serves as a distributed firewall for all customer internal networks.
• The Tier-1 Management Gateway (MGW) – Serves as a firewall for the Microsoft maintained components like vCenter and NSX.

NSX Edge virtual appliances are automatically deployed to run the Tier-0 and Tier-1 gateways when the SDDC is created. These virtual appliances use the NSX Edge Large sizing. See NSX Edge VM System Requirements.

Scalability and Availability

Like deploying Horizon on-premises, you must size your requirements for deploying Horizon.

Block and Pod

A key concept of Horizon, whether deployed on Azure VMware Solution or on-premises is the use of blocks and pods. See the Pod and Block section in Horizon Architecture.

Table 2: Block and Pod Strategy

Cloud Pod Architecture

You can use Cloud Pod Architecture (CPA) to federate multiple Horizon pods either in the same location or across different locations to unite management and user consumption. CPA introduces the concept of a global entitlement (GE) through joining multiple pods together into a federation. This feature allows you to provide users and groups with a global entitlement that can contain desktop pools or RDSH-published applications from multiple different pods that are members of this federation construct.

You can deploy Horizon in a hybrid cloud environment when you use CPA to federate Horizon on-premises pods and Horizon on Azure VMware Solution pods. You can also stretch CPA across two or more Azure VMware Solution data centers.

Important: A single pod and the Connection Servers in it must be located within a single data center and cannot span locations. Multiple locations must have their own separate pods. These pods can be managed individually or interconnected using Cloud Pod Architecture (CPA).

Note that when using multiple data centers, you must use a storage replication mechanism, such as DFS-R in a hub-spoke topology, for replicating user data

Of course, use of CPA is optional. You can choose to deploy Horizon exclusively in a single Azure VMware Solution data center without linking it to any other Horizon pod.

For more details, see the Cloud Pod Architecture section in Horizon Architecture.

Cloud Pod Architecture for Azure VMware Solution

Cloud Pod Architecture (CPA) is a standard Horizon feature that allows you to connect your Horizon deployment across multiple pods and sites for federated management. It can be used to scale up your deployment, to build hybrid cloud, and to provide redundancy for business continuity and disaster recovery. CPA introduces the concept of a global entitlement (GE) that spans the federation of multiple Horizon pods and sites.  Any users or user groups belonging to the global entitlement are entitled to access virtual desktops and RDS published apps on multiple Horizon pods that are part of the CPA.

Important: CPA is not a stretched deployment; each Horizon pod is distinct and all Connection Servers belonging to each of the individual pods are required to be located in a single location and run on the same broadcast domain from a network perspective.

Here is a logical overview of a basic two site/two pod CPA implementation.  For Azure VMware Solution, Site 1 and Site 2 might be different AVS Regions, or Site 1 might be on-premises or another supported cloud provider and Site 2 might be on Azure VMware Solution.

Figure 3: Cloud Pod Architecture

For the full documentation on how to set up and configure CPA, refer to Cloud Pod Architecture in Horizon and the Cloud Pod Architecture section in Horizon Configuration.

Linking Horizon Pods on Azure VMware Solution

You can use the Cloud Pod Architecture feature to connect Horizon pods regardless of whether the pods are on-premises or on Azure VMware Solution. When you deploy two or more Horizon pods on Azure VMware Solution, you can manage them independently or manage them together by linking them with Cloud Pod Architecture.

• On one Connection Server, initialize Cloud Pod Architecture and join the Connection Server to a pod federation.
• After CPA is initialized, you can create a global entitlement across your Horizon pods on-premises and on Azure VMware Solution.
• Optionally, when you use Cloud Pod Architecture, you can deploy a global load balancer (such as Azure Traffic Manager, AVI, F5, or others) between the pods. The global load balancer provides a single-namespace capability that allows the use of a common global namespace when referring to Horizon CPA. Using CPA with a global load balancer provides your end users with a single connection method and desktop icon in their Horizon Client or Workspace ONE console.  

Without the global load balancer and the ability to have a single namespace for multiple environments, end users will be presented with a possibly confusing array of desktop icons (corresponding to the number of pods on which desktops have been provisioned for them). For more information on how to set up Cloud Pod Architecture, see the Setting Up Cloud Pod Architecture in Horizon Console.  

Use Cloud Pod Architecture to link any number of Horizon pods on Azure VMware Solution. The maximum number of pods must conform to the limits set for pods in Cloud Pod Architecture. See, the VMware Configuration Maximums tool Horizon 8 2206 Configuration Limits.

When you connect multiple Horizon pods together with Cloud Pod Architecture, the Horizon versions for each of the pods can be different from one another.

Using CPA to Build Hybrid Cloud and Scale for Horizon

You can deploy Horizon in a hybrid cloud environment when you use CPA to interconnect Horizon on-premises and Horizon pods on Azure VMware Solution. You can easily entitle your users to virtual desktop and RDS published apps on-premises and/or on Azure VMware Solution. You can configure it such that they can connect to whichever site is closest to them geographically as they roam.  

You can also stretch CPA across Horizon pods in two or more Azure VMware Solution regions with the same flexibility to entitle your users to one or multiple pods as required.

Using CPA to Provide BC and DR for Horizon

Unlike traditional BCDR (business continuity and disaster recovery) solutions for apps, where replication of all data from the primary site to the secondary site is needed, we recommend a different approach for Horizon, using CPA. Because the majority of VDI and RDS deployments use non-persistent and stateless virtual machines that can be created and recreated very quickly, it is senseless to replicate them across sites. CPA can be used across on-premises Horizon pods (primary site) and Horizon pods on Azure VMware Solution (secondary site) for the purpose of BCDR. By using Azure VMware Solution as a secondary site for BCDR, you can take advantage of the hourly billing option and the pay-as-you-go benefit.

During normal operations, keep a small host footprint on Azure VMware Solution where you will deploy your Horizon instance, store your updated golden images, and create a small pool of VMs. Note that there is a minimum number of hosts requirement per SDDC. When the primary site goes down, you can simply create the new virtual desktops as well as new hosts on the secondary site from the very same golden image. Use Global Entitlements to ensure that your end users can access desktops on the secondary site.

You must keep persistent data such as user profiles, user data, and golden images synced between the two sites by using a storage replication mechanism, such as DFS-R in a hub-spoke topology or another third-party file share technology. If you also use App Volumes and Dynamic Environment Manager, then Packages and file share data will also need to be replicated from the primary site to the secondary site.  

An important consideration in leveraging Azure VMware Solution as a secondary site for BCDR involves host availability at the AVS data center when you need your BCDR capacity. Although there might be hosts available that can be used to expand your secondary site, depending on your RTO (Recovery Point Objective) and growth requirement, you might not be able to reach your target number right away. The only way to guarantee the number of hosts you need right away is to reserve them ahead of time, but the tradeoff is the high cost. There are things you can do to optimize your availability and cost:

• Segment end-user populations into tiers in terms of RTO (recovery time objective). Some user segments might require a secondary desktop right away. You should have desktops created and on standby for them.
• Other user segments might be able to tolerate longer RTO and might require a secondary desktop within hours rather than minutes. In this case, you can wait for new hosts and desktops to be created.
• Each new host takes time to create, assuming the data center has an available physical server.  

Work with your Microsoft sales representative to ensure that you will have adequate BCDR capacity when you need it.  

BC and DR for Horizon Full-Clone Desktops

The BCDR (business continuity and disaster recovery) workflow recommended in the previous section works well for non-persistent instant clones. There are some additional considerations for protection of persistent full-clone desktops.

First, consider whether your users require the mirror image desktops after a primary site failure? If the answer is yes, you must replicate your primary full-clone desktops periodically to the secondary site. This is the most expensive type of protection for every primary full-clone desktop; you will need an equivalent secondary full-clone desktop on Azure VMware Solution, always running. You must also script the import of secondary desktops into the Connection Servers on the secondary site as a manual full-clone pool.  

Most customers find that, given the cost of providing a fully mirrored desktop, it is acceptable to give their persistent full-clone desktop users a secondary desktop that is a pristine copy of same golden image. Any user customization or data not saved in a file share and replicated to the secondary site will be lost, so you must ensure that all important user data resides on a file share. You can then use the sample workflow in the previous section (Using CPA to Provide BC and DR for Horizon) to provision either an instant-clone desktop or a full-clone desktop on the secondary site for BCDR purposes.

Horizon Universal Broker

At the time we built the Reference Architecture implementation, the Universal Broker was not supported with Horizon on Azure VMware Solution.

Table 3: Horizon on Azure VMware Solution Strategy

AVS SDDC Sizing

The overall methodology for sizing Horizon on Azure VMware Solution is the same as for on-premises deployments. You must size your requirements for deploying Horizon on Azure VMware Solution to determine the number of hosts you must deploy for the following purposes:

• Your virtual desktop or RDS workloads.
• SDDC infrastructure components on Azure VMware Solution. These components are deployed and managed automatically for you by Microsoft, but you will require capacity in your SDDC.

At the time of this update, the minimum number of hosts required per SDDC on Azure VMware Solution for production use is 3 nodes (hosts). See Hosts for the RAM, CPU, and disk capacities of the hardware in Azure VMware Solution.

One design consideration is sizing an SDDC is the throughput capability of the SDDC networking and the NSX edge gateways. Each user session will generate a certain amount of traffic that needs to pass through the NSX edge gateways.

Each SDDC can handle up to 4,000 desktop or application sessions, assuming:

• The workload traffic aligns with the LoginVSI task worker profile.
• Only protocol traffic is considered, no user data.
• NSX Edge gateways are configured to be large.

Your workload profile and needs may be different, and therefore results may vary based on your use case. User data volumes may lower scale limits in the context of your workload. Size and plan your deployment accordingly. Work with your VMware team to help determine the correct sizing.

Network Configuration

Azure ExpressRoutes with Fast Path are used between on-premises (or Exchange provider facility), customer vNet, and Azure VMware Solution Private Cloud (SDDC). See Configuring Azure ExpressRoute, for more detail. Global Reach is also required for routing between ExpressRoute circuits, like on-premises towards SDDCs or between SDDCs. See about ExpressRoute Global Reach for more detail.

Figure 4: Azure ExpressRoute between Azure and On-Premises Locations

From on-premises or between Azure VNet Horizon PODs Active Directory, fileservers and Horizon Cloud Pod Architecture are replicated. In this reference architecture separate FQDNs were used per site, but when a single FQDN is used the Unified Access Gateways need protocol connectivity to the desktop’s subnets in a many-to-many configuration.

Figure 5: Replication between Horizon Azure VMware Solution and On-Premises Deployments

The Unified Access Gateways are deployed in a dual NIC configuration, each NIC residing in a different DMZ, acting as a gatekeeper between them. Only after authentication is successful, access to anything beyond the login page is allowed.

Figure 6: Logical Network Diagram

Table 4: Networking Strategy

Table 5: Unified Access Gateway Deployment Strategy

Load Balancing

A third-party load balancer such as Azure Load Balancer, AVI, or F5 LTM must be deployed to allow multiple Unified Access Gateway appliances and Connection Servers to be implemented in a highly available configuration. Azure Load Balancer can be used to load Balance UAG and Connection servers. See Azure Load Balancer for more information.

Table 6: Load Balancing Strategy

External Networking

When direct external access for virtual desktops and published apps is required, configure a public IP address with Network Address Translation towards the Unified Access Gateway virtual IP of the load balancer.

For external management or access to external resources, create an ExpressRoute to the tier 0 router.

Azure Express Route is a cloud service solution that makes it easy to establish a dedicated network connection from your on-premises to Azure. Using ExpressRoute, you can establish private connectivity between Azure and your data center, office, or co-location environment, which in many cases can reduce your network costs, increase bandwidth throughput, and provide a more consistent network experience than Internet-based connections.

Azure ExpressRoute lets you establish a dedicated network connection between your network and one of the connectivity provider locations. Using industry standard 802.1q VLANs, this dedicated connection can be partitioned into multiple virtual interfaces.

Table 7: Networking to On-Premises

Data Egress Cost

Unlike on-premises deployments, deploying Horizon on Azure VMware Solution incurs data egress costs based on the amount of data egress traffic the environment will generate. It is important to understand and estimate the data egress traffic.  

Understanding Different Types Data Egress Traffic

Depending on the deployment use case, you might be incurring costs for some or all of the following types of data egress traffic:

• End-user traffic via the Internet – You have configured your environment where your end users will connect to their virtual desktops on Azure VMware Solution remotely via the Internet. Any data leaving the Azure VMware Solution data center will incur egress charges. Egress data consists of the following components: outbound data from Horizon protocols and outbound data from remote experience features (for example, remote printing). Although the former is typically predictable, the latter has more variance and depends on the exact activity of the user.
• End-user traffic via the on-premises data center – You have configured your environment where your end users will connect to their virtual desktops on Azure VMware Solution via your on-premises data center. In this case, you will have to link your data center with the Azure VMware Solution data center using ExpressRoute. Any data traffic leaving the Azure VMware Solution data center and traveling back to your data center will incur egress charges. And if you have Cloud Pod Architecture (CPA) configured between the on-premises environment and the Azure VMware Solution environment, you will incur egress charges for any CPA traffic between the two pods (although CPA traffic is typically fairly light).
• External application traffic – You have configured your environment where your virtual desktops on Azure VMware Solution must access applications hosted either in your on-premises environment or in another cloud. Any data traffic leaving the Azure VMware Solution data center and traveling to these other data centers will incur egress charges.

Note: Data traffic within your Azure VMware Solution organization or between the organization and Azure services in that same region is exempt from egress charges. However, any traffic from the organization to another availability zone or to another AVS region will be subject to egress charges.

Data ingress (that is, data flowing into the Azure VMware Solution data center) is free of charge.

Estimating Data Egress Traffic

Because the data egress cost is priced per GB, the best way to estimate your data egress cost is to estimate your likely data egress traffic by using a monitoring tool in your existing on-premises environment (whether it is already virtualized or not). Make sure you estimate the different types of data egress traffic listed previously separately as applicable. One such monitoring tool is SysTrack from Lakeside Software.  

Scaling Deployments

In this section, we will discuss scaling options for scaling out Horizon on AVS. Following are the design decisions for a single SDDC and for multiple SDCCs.

Single SDDC

In a single SDDC deployment, it is recommended to locate the Horizon Management components in the Azure vNet, outside of the SDDC. This allows easier future scaling of capacity through the addition of more SDDCs to the pod, without having to relocate the management components.

Figure 7: Logical Architecture of a Single SDDC Deployment

Table 8: Networking to On-Premises

Table 9: Connection Server Strategy

Table 10: Unified Access Gateway Strategy

Table 11: App Volumes Manager Strategy

Table 12: Horizon Cloud Connector Strategy

Table 13: Workspace ONE Access Connector Strategy

Table 14: Dynamic Environment Manager Strategy

Table 15: SQL Server Strategy

Connecting to On-Premises

If you already have an on-premises environment, you can scale out this environment by adding one or more SDDCs on Azure VMware Solution and forming a new Horizon Pod.

Figure 8: AVS Deployment with Networking to On-Premises

Multiple SDDC

An existing Horizon Pod based on AVS can be extended with multiple SDDCs to scale the pod out.

Each SDDC uses an ExpressRoute with FastPath circuit to connect the SDDC to the vNet. A connection to an on-premises or co-location site also uses an ExpressRoute circuit. Currently, you can link a single virtual network (vNet) with up to four ExpressRoute circuits in either the same or different peering locations. See ExpressRoute FAQ.

You can extend beyond a single Horizon Pod by creating separate Horizon Pods in new Azure vNets. The vNets and Horizon Pods can be in the same Azure region or in different Azure regions.

Figure 9: Multiple SDDC Deployment with Networking

Licensing

Enabling Horizon to run on Azure VMware Solution requires two separate licenses: a capacity license for Azure VMware Solution and a Horizon subscription license. 

For a POC or pilot deployment of Horizon on Azure VMware Solution, you can use a temporary evaluation license or your existing perpetual license. However, to enable Horizon for production deployment on Azure VMware Solution you must purchase a Horizon subscription license. To obtain a Horizon subscription license or for more information on how to upgrade your existing perpetual license to a subscription license and associated discounts, contact your VMware representative.

Licenses are available as Concurrent User or Named User, with the exception of Workspace ONE, which only offers Named User licensing.

You can use different licenses (including perpetual licenses) on different Horizon pods, regardless of whether the pods are connected by CPA. You cannot mix different licenses within a pod because each pod only takes one type of license. For example, you cannot use both a perpetual license and a subscription license for a single pod. You also cannot use both the Horizon Apps Universal Subscription license and the Horizon Universal Subscription license in a single pod.

Cloud Connector

Regardless of whether you are deploying Horizon on-premises or on Azure VMware Solution, if you are using any of the subscription licenses, you must install the Horizon Cloud Connector to enable subscription license management for Horizon. The Horizon Cloud Connector is a virtual appliance that connects a Horizon pod with Horizon Cloud Service features.

A VMware Customer Connect account from https://customerconnect.vmware.com/ is required for Horizon subscription licenses. Once you purchase the subscription license, a record will be created in the Horizon Cloud Service using your Customer Connect account email address, and your subscription license information will be visible to the Horizon Administrator console.

As part of the subscription license fulfillment process, you will receive email with a link to download the Horizon Cloud Connector and can follow the instructions from the product documentation. After the Cloud Connector is deployed, it is paired with a Connection Server in the Horizon pod, and this pod is connected to the Horizon Cloud Service. The Horizon Cloud Service manages the Horizon subscription license between connected Horizon pods.

Unlike the Horizon perpetual license, with a subscription license, you do not need to retrieve or manually enter a license key for Horizon product activation. However, supporting component license keys, such as the license keys for vSphere, App Volumes, and others, will be delivered separately, and the administrator must manually enter them to activate the product.

Review the Horizon documentation for more details on Enabling VMware Horizon 8 for Subscription Licenses and Horizon Control Plane Services. You will need a separate Cloud Connector for each Horizon pod.

Table 16: Horizon Connector Strategy

Preparing Active Directory

Horizon requires Active Directory services. For supported Active Directory Domain Services (AD DS) domain functional levels, see the VMware Knowledge Base (KB) article https://kb.vmware.com/s/article/78652.

If you are deploying Horizon in a hybrid cloud environment by linking an on-premises environment with an Azure VMware Solution Horizon pod, you should extend the on-premises Microsoft Active Directory (AD) to Azure VMware Solution.

Although you could access on-premises active directory services and not locate new domain controllers in AVS, this could introduce undesirable latency.

Table 17: Active Directory Strategy

Shared Content Library

Content Libraries are container objects for VM, vApp, and OVF templates and other types of files, such as templates, ISO images, text files, and so on. vSphere administrators can use the templates in the library to deploy virtual machines and vApps in the vSphere inventory. Sharing golden images across multiple vCenter Server instances, between multiple Azure VMware Solution and/or on-premises SDDCs guarantees consistency, compliance, efficiency, and automation in deploying workloads at scale.

For more information, see Using Content Libraries in the vSphere Virtual Machine Administration guide in the VMware vSphere documentation.

Storing User Data

To cost-effectively provide high performance file shares that can securely store and protect user data for Horizon desktops and applications, consider a modern cloud-based file data service solution such as Nasuni.  Nasuni has certified their platform to work with VMware Horizon on AVS.

Nasuni File Data Platform

Nasuni is a modern file services platform built to provide enterprise file shares for cloud and hybrid cloud environments and can provide VMware Horizon virtual desktops with file storage for user data. including home drives, project shares, and group directories.

Nasuni consolidates file data in durable, scalable, and economical cloud object storage such as Azure Blob. The Nasuni UniFS global file system resides natively in object storage and organizes the file data, snapshots, and metadata in immutable, encrypted format. Nasuni Edge virtual machines, deployed in the cloud or on-premises, cache copies of the frequently accessed files from object storage and enable the data to be accessed by users and applications through standard SMB (CIFS) and NFS file sharing protocols. Every Nasuni Edge is kept in sync by Nasuni’s cloud orchestration service, enabling the same file shares to be presented in multiple edge locations, including Horizon pods in different SDDCs. With this software-defined architecture, Nasuni can offer unlimited file storage capacity on-demand, high-performance file access at any edge location, and a true global file namespace for multi-site file sharing.

Nasuni’s architecture makes it ideally suited for VMware Horizon on AVS. Once file shares are consolidated by Nasuni in Azure Blob object storage, Nasuni Edges can be deployed as Azure virtual machines in the same Azure regions as the Horizon desktops and published applications to deliver economical, high-performance file access to a single global namespace. Since the desktops and file shares are co-located in the same Azure datacenter, VMware Horizon users will experience a local file sharing experience. Nasuni Continuous File Versioning technology takes frequent snapshots of file system changes on every Nasuni Edge VM and stores them as immutable versions in Azure Blob object storage. With recovery points as often as every few minutes and no limit to the number of snapshots that can be retained, the cost and complexity of file backup is eliminated, protection against ransomware is greatly improved, and IT resources can be freed up for other IT projects.

Use Nasuni when you require:

• Two or more locations that need to share the same user data - Nasuni can present the same global file system at each location and offers file locking to help prevent version conflict, ideal for when you have Horizon pods in multiple SDDCs or when you need to share the same data across Horizon desktops in AVS and on-premises desktops.
• Ransomware protection - Nasuni offers unlimited snapshots (recovery points) that can outwait patient ransomware, recovery points as often as every few minutes to minimize data loss after a restore, immutability to ensure that there is always a healthy version of a file that cannot be corrupted, and rapid recovery to restore petabytes of file data and millions of files in seconds.
• Complex applications (like Autodesk AutoCAD and Revit and Adobe InDesign) - Nasuni offers special configurations for these types of applications and supports unlimited file and directory sizes, an important consideration for apps that generate very large files.
• File share capacity on-demand - Nasuni uses Azure Blob (or other cloud object storage) as its back end, so adding capacity for user data simply requires increasing your object storage subscription.
• Multi-protocol support - Nasuni supports SMB (CIFS), NFS, and mixed protocol environments. These features are useful when the same user data needs to be shared across Horizon on AVS desktops and on-premises desktop environments.

For more information on how to use Nasuni with Horizon on AVS, refer to the Nasuni technical documentation, Nasuni Reference Architecture: VMware Horizon on Azure VMware Solution.

Deploying Desktops

With Horizon on Azure VMware Solution both instant clones and full clones can be used. Instant clones coupled with App Volumes and Dynamic Environment Manager helps accelerate the delivery of user-customized and fully personalized desktops.

Instant Clone

Dramatically reduce infrastructure requirements while enhancing security by delivering a brand-new personalized desktop and application services to end users every time they log in:

• Reap the economic benefits of stateless, nonpersistent virtual desktops served up to date upon each login.
• Deliver a pristine, high-performance personalized desktop every time a user logs in.
• Improve security by destroying desktops every time a user logs out.

When you install and configure Horizon for instant clone for deployment on Azure VMware Solution, do the following:

When adding Azure VMware Solution vCenter Server to the Horizon configuration, be sure to select the Azure VMware Solution check box.

• CBRC is not supported or needed on Azure VMware Solution. CBRC has been turned off by default.
• On the golden image VM, add the domain’s DNS to avoid customization failures.
• Instant clone pools and farms, on AVS, are created without parent VMs. See Instant Clone Smart Provisioning.

App Volumes

App Volumes provides real-time application delivery and management, now for on-premises and on Azure VMware Solution:

• Quickly provision applications at scale.
• Dynamically attach applications to users, groups, or devices, even when users are already logged in to their desktop.
• Provision, deliver, update, and retire applications in real time.
• Provide a user-writable volume, allowing users to install applications that follow them across desktops.
• Provide end users with quick access to a Windows workspace and applications, with a personalized and consistent experience across devices and locations.
• Simplify end-user profile management by providing organizations with a single and scalable solution that leverages the existing infrastructure.
• Speed up the login process by applying configuration and environment settings in an asynchronous process instead of all at login.
• Provide a dynamic environment configuration, such as drive or printer mappings, when a user launches an application.

For design guidance, see App Volumes Architecture.

Dynamic Environment Manager

Use VMware Dynamic Environment Manager for application personalization and dynamic policy configuration across any virtual, physical, and cloud-based environment. Install and configure Dynamic Environment Manager on Azure VMware Solution just like you would install it on-premises.

See Dynamic Environment Manager Architecture.

What’s Next?

Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:

• Overview chapters provide understanding of business drivers, use cases, and service definitions.
• Architecture chapters explore the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
• Integration chapters cover the integration of components and services you need to create the platform capable of delivering what you want.
• Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Horizon, App Volumes, Dynamic Environment Management, and more.