Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Horizon Enterprise now supports deployment of Horizon Agents (running in desktops and RDS hosts) in a remote location from the Horizon Connection Servers, as long as Horizon Agents / desktops and RDSH hosts are within 120 ms of latency from the Horizon Connection Servers. This article provides more details on this feature.
There are two common use cases where this feature would be helpful. Use Case 1: Consolidation of Horizon Pods across private data centersIn a scenario where Horizon desktops and RDS hosts are deployed across multiple geographic locations, instead of having to deploy and manage a separate Horizon Pod next to the desktop / RDS capacity in each geographic location, you can now consolidate down to fewer Horizon Pods. Note the following: For the purpose of disaster recovery, we recommend at least 2 Horizon Pods set up in a CPA configuration. So while you can consolidate multiple Horizon Pods down to a single Pod using this feature, consider the impact on DR and proceed accordingly.As you consolidate, keep in mind that each Horizon Pod can have a max of 20,000 sessions and up to 5 vCenters. Check VMware Configuration Maximums for the up-to-date max supported. Horizon Connection Servers within a single Pod must remain in a single location and cannot be spread across multiple locationsLatency between the Horizon Connection Servers and every single remote location where the Horizon Agents are deployed must be 120 ms or lessUAG must be deployed in the same location as the Horizon Connection ServersFor this use case, since there was no code change necessary, this feature applies to any currently supported version of Horizon 8.x and Horizon 7.x.Horizon Control Plane SaaS services are not yet able to differentiate that capacity is deployed across multiple sites. IMS functionality will fail when used on the remote vCenter Use Case 2: Extending Horizon Pod in private data centers to manage capacity deployed in the cloudIn a scenario where you have one or multiple Horizon Pods in your private data centers and you want to burst out to public cloud without having to create and manage a new Horizon Pod in the cloud, you can extend one of your existing Horizon Pods to manage the cloud capacity. To do so: Use your cloud subscription and create a new SDDC (VMC on AWS, AVS, GCVE, OCVS, VMC on Dell EMC) with the number of desired hostsEnsure that there is connection between your private data center and your desired cloud data center and that latency is within 120 msAdd the vCenter of the newly created SDDC to your existing Horizon PodYour Horizon Pod can start managing the cloud capacity as if it were on-premise Here are some caveats to keep in mind for this use case: The best use case for this feature is to enable you to more easily set up cloud burst capacity and extend your existing private data center desktop environment. We recommend this feature for when your intended cloud capacity is small to medium (up to 1000 VMs in the cloud). If you decide to burst a larger number of VMs in the cloud, while this feature would still work, your scale in the cloud may be large enough to warrant a separate Horizon Pod and the associated management overhead. If your goal in going to the cloud is to provide a DR solution for your primary desktops, then this feature is not a fit. For the purpose of disaster recovery, we recommend that you set up a separate Horizon Pod in the cloud and link it with your private data center Horizon Pods in CPA configurationKeep in mind that each Horizon Pod can have a max of 20,000 sessions and up to 5 vCenters. So if your private data center Horizon Pod is already maxing out, it is not advisable to extend it to manage cloud capacity. Check VMware Configuration Maximums for the up-to-date max supported. Horizon Connection Servers within a single Pod must remain in a single location and cannot be spread across private data center and cloud data center. However, as long as you keep the Horizon Connection Servers in a single location, you can deploy them in the cloud data center and extend them back onto your private data center to manage desktop and RDSH capacity thereLatency between your private data center where your connection servers are deployed and the cloud data center where the Horizon Agents are deployed must be 120 ms or less. Networking connection between private data centers and cloud data centers vary depending on the cloud provider, we recommend that you work with your VMware technical team as well as your cloud provider for optimal configurationUAG must be deployed in the same location as the Horizon Connection ServersFor this use case, your private data center pod must be on Horizon 8 2006 or later: If you are on Horizon 2106 and later, when you add the cloud vCenter, you must select the correct deployment type. If this is selected incorrectly, instant clones may not provision properly. For more details, see https://docs.vmware.com/en/VMware-Horizon/2106/horizon-installation/GUID-1E975233-5D4C-4685-A6B6-6E5FC15D6B4A.htmlIf you are on Horizon 2103 or earlier, you can set the deployment type of the cloud vCenter in the ADAM DB. For details, see [find link] Horizon Control Plane SaaS services are not yet able to differentiate that capacity is deployed across multiple sites. IMS functionality will fail when used on the remote vCenterApp Volumes can be used with Horizon Remote Agent Architecture. App Volumes Manager needs to be co-located with the Horizon Connection Servers and the App Volumes Database. App Volumes packages need to be replicated to the remote SDDC. Licensing All Horizon customers, regardless of license type currently use, can use the Remote Agent feature to burst to another on-premises site or burst to a public cloud. If commercial Perpetual License or Term License customer wants to use this feature to burst into a public cloud, then they have to follow the licensing guidelines in the the official Licensing Terms and Condition and agree to upgrade to a subscription license when their existing perpetual SnS or Term License is up for renewal. Specifically mentioned in the Terms and Conditions document – “Perpetual Licenses on Public Cloud Infrastructure. VMware agrees that you may use and install on Public Cloud Infrastructure any Horizon perpetual license that you identify as a license that you will upgrade using the SUP for Horizon once your prepaid support services contract for that license expires. “Public Cloud Infrastructure” means infrastructure computing services whereby the provider makes necessary resources, such as hardware, software and other supporting infrastructure available for rent to customers (whether accessible by customers or not), and on which customers may install applications.”If a government Perpetual License customer wants to use this feature to burst into a public cloud, then they have to agree to upgrade to Term license when their existing perpetual SnS is up for renewal. A government Term License customer can use this feature to bust into the cloud without having to do any upgrade.