Horizon on Oracle Cloud 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 architecting VMware Horizon on Oracle Cloud VMware Solution. A companion chapter, Horizon on Oracle Cloud VMware Solution Configuration, provides information about common configuration and deployment tasks for VMware Horizon on Oracle Cloud VMware® Solution.

Introduction

VMware Horizon on Oracle Cloud VMware Solution delivers a seamlessly integrated hybrid cloud for virtual desktops and applications. Oracle Cloud VMware Solution is based on VMware Cloud Foundation and provides a fully supported, customizable cloud environment for VMware deployments and migrations. The solution delivers a full-stack software-defined data center (SDDC), including VMware vCenter, vSphere ESXi, NSX, and vSAN, delivered as a service on Oracle Cloud Infrastructure (OCI).

Oracle Cloud VMware Solution combined with the market-leading capabilities of VMware Horizon gives a simple, secure, and scalable solution, that can easily address use cases such as on-demand capacity, disaster recovery, and cloud co-location without buying additional data center resources.

For customers who are already familiar with Horizon or have Horizon deployed on-premises, deploying Horizon on Oracle Cloud 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 hardware and vSphere platform, you can simplify management of Horizon deployments.

For more information about VMware Horizon on Oracle Cloud VMware Solution, visit the Oracle Cloud VMware Solution.

Figure 1: Horizon on Oracle Cloud VMware Solution

For details on feature parity between Horizon on-premises and Horizon on Oracle Cloud VMware Solution, see the VMware Knowledge Base article VMware Horizon on Oracle Cloud VMware Solution (OCVS) Support (88202).

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

Deployment Options

Horizon on Oracle Cloud VMware Solution has one deployment option:

• All-in-SDDC - A consolidated design with all the Horizon components located inside the SDDC.

SDDC-based

Every component in the All-in-SDDC-based deployment model, including management, is located inside the Oracle Cloud VMware Solution Software-Defined Data Centers (SDDCs).

The following figure shows the high-level logical architecture of this deployment model and all the management components inside the SDDC. There is a customer-provided load balancer that sits in the Oracle Cloud Infrastructure to forward protocol traffic into the SDDC.

Figure 2: All-in-SDDC Logical Architecture

Architectural Overview

In this section, we discuss the various components, including individual server components used for Horizon, single or multiple vSphere Software-Defined Data Centers (SDDC), management and compute components, NSX-T components, and resource pools.

Components

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

Check the Knowledge Base article 88202 for feature parity of Horizon on Oracle Cloud VMware Solution.

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

Software-Defined Data Centers (SDDC)

Oracle Cloud VMware Solution allows you to create vSphere Software-Defined Data Centers (SDDCs) on Oracle Cloud Infrastructure (OCI). These SDDCs 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. Using a connected OCI account, you can access OCI services such as Oracle Cloud Infrastructure Compute and Oracle Cloud Infrastructure File Storage from virtual machines in your SDDC. For more information, see the Oracle Cloud Infrastructure documentation.

After you have deployed an SDDC on Oracle Cloud VMware Solution, you can deploy Horizon in that cloud environment just like you would in an on-premises vSphere environment. For pricing information, see Compute - Oracle Cloud VMware Solution.

Management Component

The management component for the network includes vCenter Server.

Compute Component

The compute component includes the following Horizon infrastructure components:

• Horizon Connection Servers
• Unified Access Gateway appliances
• App Volume Managers
• Virtual machines

NSX-T Components

VMware NSX-T 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.

The maximum number of ports per logical network is 1000. Pools can leverage the multi-VLAN option in Horizon to extend beyond this.

• Tier-0 router – Handles Internet, route- or policy-based IPsec VPN, Oracle Cloud Infrastructure FastConnect, and also serves as an edge firewall for the Tier-1.
• Tier-1 router – Serves as a distributed firewall for all customer internal networks.

Resource Pools

A resource pool is a logical abstraction for flexible management of resources. Resource pools can be grouped into hierarchies and used to hierarchically partition available CPU and memory resources.

Within a Horizon pod on Oracle Cloud VMware Solution, you can use vSphere resource pools to separate management components from virtual desktops or published applications workloads to make sure resources are allocated correctly. 

After an SDDC instance on Oracle Cloud VMware Solution is created, two resource pools exist: 

• A Management Resource Pool with reservations that contain vCenter Server plus NSX-T
• A Workload Resource Pool within which everything is managed by the customer 

When deploying both management components and user resources in the same SDDC, it is recommended to create two sub-resource pools within the Workload Resource Pool for your Horizon deployments:

• A Horizon Management Resource Pool for your Horizon management components, such as connection servers
• A Horizon User Resource Pool for your desktop pools and published apps

Figure 3: Resource Pools for SDDC-based Horizon on Oracle Cloud VMware Solution

Scalability and Availability

In this section, we discuss the concepts and constructs that can be used to provide scalability of Horizon.

Block and Pod

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

Table 1: Block and Pod Strategy

Cloud Pod Architecture

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, build a hybrid cloud, and 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 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 Oracle Cloud VMware Solution, Site 1 and Site 2 might be different OCI availability domains, or Site 1 might be on-premises and Site 2 might be on Oracle Cloud VMware Solution.

Figure 4: Cloud Pod Architecture

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

Linking Horizon Pods on Oracle Cloud VMware Solution

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

• On one Connection Server, initialize CPA 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 Oracle Cloud VMware Solution.
• Optionally, when you use CPA, you can deploy a global load balancer (such as F5, Oracle Cloud Infrastructure DNS, 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 Administering Cloud Pod Architecture in Horizon.  

Use CPA to link any number of Horizon pods on Oracle Cloud VMware Solution. The maximum number of pods must conform to the limits set for pods in CPA. See, the VMware Configuration Maximums page.

When you connect multiple Horizon pods with CPA, the Horizon versions for each of the pods can be different from one another. Additional details can be found in the VMware Horizon documentation.

Using Cloud Pod Architecture 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 or vSphere-based clouds pods. You can easily entitle your users to virtual desktops and RDS-published apps on-premises and/or vSphere-based clouds. You can configure it to connect to whichever site is closest to them geographically as they roam.  

You can also stretch CPA across Horizon pods in two or more Oracle Cloud VMware Solution data centers with the same flexibility to entitle your users to one or multiple pods as desired.

Using Cloud Pod Architecture to Provide Business Continuity and Disaster Recovery 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 Oracle Cloud VMware Solution (secondary site) for BCDR.

During normal operations, keep a small host footprint on Oracle Cloud 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 create 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 will need to 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, AppStacks and file share data will also need to be replicated from the primary site to the secondary site.  

An important consideration in leveraging Oracle Cloud VMware Solution as a secondary site for BCDR involves host availability at the OCI data center when you need your BCDR capacity. Although there are usually spare hosts available that can be used to expand your secondary site, depending on your RPO (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 may require a secondary desktop immediately. You should have desktops created and on standby for them. Other user segments might be able to tolerate longer RTO and may require a secondary desktop within hours rather than minutes. In this case, you can wait for new hosts and desktops to be created.

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

Business Continuity and Disaster Recovery 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 will need to 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 Oracle Cloud VMware Solution, running at all times. You will also need to 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 the 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 will need to ensure that all-important user data resides on a file share. You can then use the sample workflow in the previous section to provision either an instant-clone desktop or a full-clone desktop on the secondary site for BCDR purposes.

Workspace ONE Access

Workspace ONE® Access SaaS can be used to broker Horizon resources. In this case, the entitlements and resources are synced to Workspace ONE Access and Workspace ONE Access knows the FQDN of each pod to properly direct users to their desktop or application resources. 

For more design details, see Horizon and Workspace ONE Access Integration in the Platform Integration chapter.

Figure 5: Syncing Horizon Resources into Workspace ONE Access SaaS

Sizing Horizon on Oracle Cloud VMware Solution

Similar to deploying Horizon on-premises, you will need to size your requirements for deploying Horizon on Oracle Cloud VMware Solution to determine the number of hosts you will need to deploy. Hosts are needed for the following purposes:

• Your virtual desktop or RDS workloads.
• Your Horizon infrastructure components, such as connection servers, Unified Access Gateways, App Volumes managers.
• SDDC infrastructure components on Oracle Cloud VMware Solution. These components are deployed automatically for you by Oracle, but you will need capacity in your SDDC to run them.

The methodology for sizing Horizon on Oracle Cloud VMware Solution is the same as for on-premises deployments. What is different (and simpler) is the fixed hardware configurations on Oracle Cloud VMware Solution. Work with your VMware sales team to determine the correct sizing.

At the time of writing, the minimum number of hosts required per SDDC on Oracle Cloud VMware Solution for production use is 3 nodes (hosts).

Network Configuration

When SDDCs are deployed on Oracle Cloud VMware Solution, NSX-T is used for network configuration.

The recommended network architecture consists of a double DMZ and a separation between Horizon management components and the RDSH and VDI virtual machines.

Figure 6: Network Diagram (Subnets are for Illustrative Purposes Only)

Unified Access Gateway

The Unified Access Gateway appliances are located inside of the Oracle Cloud VMware Solution SDDC. There is no way to forward Horizon protocol traffic from the OCI load balancer into the Unified Access Gateway devices inside of the SDDC. As the connections in OCI VLANs are opaque to the underlying software-defined network (SDN), for devices outside the VLAN to connect to workloads inside it, the workloads must be tagged to help locate them within the VLAN.

Because the OCI Load Balancing service cannot maintain session persistence between the authentication (over TCP) and the protocol (over UDP) phases, we need to ensure each Unified Access Gateway is accessible directly from the Internet. We do this by assigning public IP addresses to the external access virtual IPs and pointing the VLAN’s Route Table default route to an Internet Gateway. See Load Balancing Unified Access Gateway in Horizon Architecture for details on load-balancing the UAG appliances.

Load Balancing

A load balancer such as OCI Load Balancer or VMware NSX Advanced Load Balancer (Avi) must be deployed to allow multiple Unified Access Gateway appliances and Connection Servers to be implemented in a highly available configuration.

Network Configuration and Services for Deploying Horizon on Oracle Cloud VMware Solution

To set up a successful hybrid cloud deployment, ensure that you understand and configure the following network services.

Oracle Cloud VMware Solution Network Connectivity

If connecting an Oracle Cloud VMware Solution SDDC with on-premises datacenters or with another SDDC, the following connection options can be used:

• VPN (policy- or route-based) over public Internet
• VPN (policy- or route-based) over Oracle FastConnect
• Oracle FastConnect

Depending on the requirements one or another option might be the best fit for you. For a predictable networking experience, Oracle FastConnect is recommended. After the connection is established, ensure that routing configuration permits required traffic flow (e.g., all required subnets are correctly announced via BGP to Oracle Cloud VMware Solution and route-based VPNs). Additional network capabilities provided by HCX or L2VPN can be leveraged if needed. For more detail, see NSX-T Networking Concepts section of the Oracle Cloud VMware Solution Product Documentation.

DHCP service

It is critical to ensure that all VDI-enabled desktops have proper assigned IP address. In most cases, you opt for the automatic IP assignment.

Oracle Cloud VMware Solution supports the following ways to assign IP addresses to clients:

• NSX-T based local DHCP service
• DHCP Relay, customer managed

DNS Service

Reliable and correctly configured name resolution is key for a successful hybrid Horizon deployment. When designing your environment, make sure to understand DNS strategies for Oracle Cloud VMware Solution. Your design choice will directly influence the configuration details.

Data Egress Cost

Unlike on-premises deployments, deploying Horizon on Oracle Cloud 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. Refer to the Oracle Pricing documentation for more information.

Understanding Different Types of Data Egress Traffic

Depending on the deployment use case, you may 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 Oracle Cloud VMware Solution remotely via the Internet. Any data leaving the Oracle Cloud 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 Oracle Cloud VMware Solution via your on-premises data center. In this case, you will have to link your data center with the Oracle Cloud VMware Solution data center using VPN or Direct Connect. Any data traffic leaving the Oracle Cloud 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 Oracle Cloud 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 Oracle Cloud VMware Solution must access applications hosted either in your on-premises environment or in another cloud. Any data traffic leaving the Oracle Cloud VMware Solution data center and traveling to these other data centers will incur egress charges.

Note: Data traffic within your Oracle Cloud VMware Solution organization or between the organization and OCI services in that same region is exempt from egress charges. However, any traffic from the organization to another OCI region (after the first 10 TB per month, which is free) will be subject to egress charges. Refer to the Oracle Pricing documentation for more information.

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

Networking to On-Premises

Oracle FastConnect is a cloud service solution that makes it easy to establish a dedicated network connection from your premises to Oracle Cloud Infrastructure. Using Oracle FastConnect, you can establish private connectivity between OCI 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.

Figure 7: Oracle Cloud VMware Solution Networking to On-Premises (SDDC-based Deployment shown)

Table 2: Virtual Private Network Strategy

Table 3: Domain Controller Strategy

Table 4: File Server Strategy

Licensing

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

For a POC or pilot deployment of Horizon on Oracle Cloud VMware Solution, you may use a temporary evaluation license or your existing perpetual license. However, to enable Horizon for production deployment on Oracle Cloud 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, except for 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.

Horizon Cloud Connector

Regardless of whether you are deploying Horizon on-premises or on Oracle Cloud 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 a Horizon subscription license. After you purchase the subscription license, a record will be created in the Horizon Cloud Service using your Customer Connect 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 an email with a link to download the Horizon Cloud Connector as an OVA (open virtual appliance) file. Follow the instructions in the email to deploy the Cloud Connector, using the vSphere web client, alongside your new or existing Horizon pods. After deployment, the Cloud Connector 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.

With a Horizon 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 for Subscription Licenses and Horizon Control Plane Services. You will need a separate Cloud Connector for each Horizon pod.

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: Supported Operating Systems and MSFT Active Directory Domain Functional Levels for VMware Horizon 8 2006 (78652).

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

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

A site should be created in Active Directory Sites and Services and defined to the subnets containing the Domain Controller(s) in Oracle Cloud VMware Solution. This will keep the active directory services traffic local.

Table 5: 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 Oracle Cloud VMware Solutions 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.

Resource Sizing

When resource sizing, make sure to take memory, CPU, and VM-level reservations into consideration, and use CPU shares for different workloads.

Memory Reservations

Because physical memory cannot be shared between virtual machines, and because swapping or ballooning should be avoided at all costs, make sure to reserve all memory for all Horizon virtual machines, including management components, virtual desktops, and RDS hosts.

CPU Reservations

CPU reservations are shared when not used, and a reservation specifies the guaranteed minimum allocation for a virtual machine. For the management components, the reservations should equal the number of vCPUs times the CPU frequency. Any amount of CPU reservations not actively used by the management components will still be available for virtual desktops and RDS hosts when they are deployed in same the SDDC.

Virtual Machine–Level Reservations

As well as setting a reservation on the resource pool, make sure to set a reservation at the virtual machine level. This ensures that any VMs that might later get added to the resource pool will not consume resources that are reserved and required for HA failover. These VM-level reservations do not remove the requirement for reservations on the resource pool. Because VM-level reservations are taken into account only when a VM is powered on, the reservation could be taken by other VMs when one VM is powered off temporarily.

Leveraging CPU Shares for Different Workloads

Because RDS hosts can facilitate more users per vCPU than virtual desktops can, a higher share should be given to them. When desktop VMs and RDS host VMs are run on the same cluster, the share allocation should be adjusted to ensure relative prioritization.

As an example, if an RDS host with 8 vCPUs facilitates 28 users and a virtual desktop with 2 vCPUs facilitates a single user, the RDS host is facilitating 7 times the number of users per vCPU. In that scenario, the desktop VMs should have a default share of 1000, and the RDS host VMs should have a vCPU share of 7000 when deployed on the same cluster. This number should also be adjusted to the required amount of resources, which could be different for a VDI virtual desktop session versus a shared RDSH-published desktop session.

Table 6: Reservations and Shares Overview

Deploying Desktops

With Horizon on Oracle Cloud 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 Oracle Cloud VMware Solution, do the following:

• When adding Oracle Cloud VMware Solution vCenter Server to the Horizon configuration, select the Oracle Cloud VMware Solution check box.

For more information, see Instant Clone Smart Provisioning.

App Volumes

App Volumes provides real-time application delivery and management:

• 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 Oracle Cloud 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 an 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.