A few months back, I setup a Horizon Environment running in our VMC environment used for lab purposes. Since then, I’ve been asked by several people to go through the setup. So, I’ve also decided to create a blog post on the matter.

This blog post will cover the considerations for running VMware Horizon on VMC, and the technical setup itself of the lab environment I created.

Update 4th May: I recorded a session for the London VMUG on this subject, which you can watch here.

Topics covered;

Horizon 7 on VMware Cloud on AWS is not DaaS

Horizon 7 on VMware Cloud on AWS Deployment Guide and Supportability

Feature Support

Horizon on VMC architecture

Platform Considerations Identity Management File Shares Image management

Network Service VMC Network Segments Load Balancing DHCP

Firewall Rules Logging

Horizon Connection Broker Configuration

Some finl considerations

Further Resources

Horizon 7 on VMware Cloud on AWS is not DaaS

I will not cover the details of VMware Cloud on AWS (VMC) in this post, but you can read about it here.

Horizon 7 (or later), running on top of VMC, is not a Desktop-as-a-Service offering. For this, we have our Horizon Cloud offering, which currently supports Azure and IBM Cloud.

Horizon on VMC, acts the same as the on-prem offering, i.e. the same considerations and configurations as you would take, if you deployed Horizon in your own private datacentre.

You can stretch existing Horizon environments to also make use of the compute and storage in VMC, and setup Cloud Pod Architecture between the locations as well. Alternatively, you can run a full Horizon environment solely within VMC itself. By running within VMC, you also ensure your desktops are near in proximity to native AWS services, such as file services, global load balancing services to name some examples.

Horizon 7 on VMware Cloud on AWS Deployment Guide and Supportability

To build our Horizon on VMC lab, I simply read the documentation, so I won’t hide it from you, you can ignore this blog post if you want and simply look at the posts below. However now I’ve written about the high level, the rest of this blog post will cover the technical information, considerations and nuances.

Feature Support

You can use the KB article (58539) above to see the up to date information on full feature support, however below I have called out some of the more necessary considerations;

Not Supported Feature Note View Composer Linked Clones Use Instant Clone instead Content Based Read Cache (CBRC) Not needed for performance on VMware vCloud on AWS Security Servers Use Unified Access Gateway (UAG) instead Unmanaged Desktops Horizon Persona Management

Use Dyanmic Environment Manager

vRealize for Horizon (Monitoring) Support can be granted on individual basis JMP Server (On-Premise) Use JMP on Horizon Cloud Console instead

Horizon on VMC architecture

Below is VMware’s simplified recommended pod architecture when setting up VMC, where cloud pod architecture is not configured.

Essentially if you are scaling out across multiple VMC SDDCs, then a single SDDC will be a single “pod”.

Below is a basic diagram of the architecture setup for the lab environment. As this is environment is not production based. there are a number of components missing, such as load balancing, and HA/Replica of UAG and Connection brokers. For the below configuration, we expect to support only a limited number of users, but have provided HA from a UAG and Connection server point of view.

As the lab environment is fully self contained within VMC, below is the specification I built out.

Active Directory Servers

DNS

DHCP

File Shares

Dynamic Environment Manager

Horizon Components



2 x Unified Access Gateway

2 x Connection Server 2 CPU, 2 Core, 8GB RAM 40GB Hard Drive

Avi Networks 1 x Controller 2 x Service Engines

4 x Remote Desktop Session hosts 2 CPU, 4 Core, 48GB RAM Number of local apps Instant clones



Platform Considerations

Identity Management

Typically, you are going to be using a Microsoft Active Directory, I haven’t seen any environment myself where this is not the case. However it is possible to use AWS Directory Service if you so wanted to.

The top three things you need to think about, (which aren’t specific to VMC on AWS);

Proximity to active directory is key Consider at least Read-Only Domain Controller if stretching from private cloud Configure sites and services correctly



File Shares

Again, the proximity of a user’s documents is key to the users experience.

If using Windows File Services on-prem, consider using Distributed File Systems for replication, and replicate a copy of the data to be local to the Horizon desktops in VMC. There are also options such as FSLogix from Microsoft to manage certain user file environments, but this could make your environment more complex than it needs to be. Finally, as you are running an SDDC in AWS, why not consider native services such as Amazon Fx For Windows Server.

Consider the cost requirements, not only is the cost of storage a factor, but so is network traffic. If the data is outside of your VMC SDDC, then ingress is free, but egress will cost you (If you have a AWS Direct Connect connection, egress will cost you a little less). So, options like using Microsoft DFS to replicate between on-prem and VMC SDDC, may work the best, but any data replicated back to your on-prem datacentre will probably incur a network data transfer cost.

Image Management

Currently Horizon 7.12 is the latest release, and there is no support for content library. Therefore, you have to make careful considerations for your image management strategy, especially if you are extending your on-prem Horizon environment to VMC.

You can build your golden image on-prem, transfer into the content-library and use subscriptions to share to your content-library in VMC. However to use the image in VMC, you will need to export this object from your content-library as a Virtual Machine object accessible within vCenter.

Horizon will build its desktop pools from the snapshots of powered off Virtual Machines (even VM templates are not supported). If you have a single image in use, then you could easily just have a second image located in SDDC, and you build your standard operating procedure to update and push out the two images in lock step. But if you have serveral images, then this becomes more complicated.

There is also the ability to leverage 3rd party products for this, such as your backup software, for example using Veeam Backup and Replication, to copy your VM images between on-prem and VMC.

Network Services



For me, the biggest differences between deploying Horizon on-prem to deploying Horizon on VMC, is the networking and security aspects.

VMC Network Segments

At minimum you will need two Internal LAN DMZ



See below for the firewall setup.

Load Balancing

Although VMC uses NSX for networking and security, the load balancing features found in an on-prem setup of NSX-T, are not available.

Hence, this is a bring your own load balancer situation. Example options;

NSX Advance Load Balancer (formerly AVI Networks)

Kemp virtual appliance

F5 virtual appliance

AWS Elastic Load Balancer

AWS Route53 global LB Blog post: Global Load Balancing with VMware Horizon and Amazon Route 53



Nico Vibert wrote a great article looking at load balancing options for VMC.

DHCP

As per the limitations above, Horizon in VMC uses on Instant Clone technology, which means your images will boot and use DHCP.

The DHCP functionality in VMC is quite limited, you are unable to set lease times, or expire DHCP allocations when troubleshooting.

I would say it is mandatory you setup a DHCP server for use in your environment, even if it is just used for your Horizon desktops.

In the lab environment, I achieved this by setting up a second network adapter on the Domain Controller, configured for the logical switch used for my Horizon desktops, and binding the DHCP service to this single adapter/network range.

Firewall Rules

This is the critical piece to get right. VMC offers two kinds of Firewall;

Gateway Firewall

North/South traffic

Everything leaving the clusters to the outside world

Distributed Firewall

East / West Traffic

Rule set for VM to VM traffic

You need this to create your DMZ for the UAG

If you do not setup the distributed firewall, you just have internal network segments that can talk to one another so long as they are routed. From a security point of view, this is not what you want.

When creating Distributed Firewall Rules, there are a couple of items you should be aware of;

Like a normal firewall, rules are processed top down, so placement of the rule matters!

You can create rule sections ( Red ), and then the rules themselves ( Yellow ) within each section

), and then the rules themselves ( ) within each section Distributed Firewall has a default allow all If the traffic is not matched to an existing rule, your traffic is allowed!



Based on the above, if we just look at created a DMZ for the Unified Appliance Gateway component, then we need to end our firewall section for this component with two Deny rules. One for all traffic leaving the UAG (Purple), and one for all traffic going to the UAG (Blue).

This ensures that if the traffic is specified in a previous rule, the traffic is blocked.

Firewall rule logging

As you can see in the above image, I have enabled logging for any traffic going to the UAG that is not allowed by the previous rules.

You can view these logs using “VMware vRealize Log Insight Cloud“, which is accessible from your VMware Cloud Services homepage.

There are limitations with the Log Insight instance you get as part of your VMC on AWS subscription versus paying for the full subscription, such as 1GB of logs per day ingestion, lack of content packs, and only 7 days historical logs.

To view the logged firewall rules, you can simple filter by;

Log_Type = nsxt-firewall

Horizon Connection Broker Configuration

I’ve left this piece until last, simply because when we get into Horizon itself, pretty much everything remains the same as you know and love (or hate) from an on-prem deployment.

When adding in your vCenter connection details, you simply tick the box stating that the vCenter is part of a VMware Cloud on AWS setup. You will find when using the interface, certain options will not be available for deploying desktop pools to this vCenter, as per the limitations listed earlier in this blog.

Some final considerations

So I like to end on some open ramblings about possible environment factors you need to consider or question of your designs and deployments.

Use case

DC Evac – on-prem Horizon environment running on aging hardware Will you be using cloud pod architecture? Network connectivity will be key Run separate Horizon instances? How will you balance users between environments?



What are your constraints?

How many users will you need to support? Basic Horizon planning and sizing applies even for running in VMC for your Horizon component architecture

VMC Maximums – soft limits / hard limits Something to be aware of, you might want to run a single SDDC with one cluster, but your Desktop:Host ration means you need more than

Desktop:Host Ratio Do your users run intense workloads? Do they need multi-monitor support The lower your ration, the more hosts you need, potentially multiple clusters

Networking What’s your connectivity to VMC? IPSEC VPN – overhead on traffic Direct connect – high costs involved, will you use that full pipe? Public Internet connectivity to environment, no on-prem requirement?



Resolutions

Scale out across multiple SDDCs Reduce over-subscription of the IPSec VPN tunnels to the TGW Utilize Cloud Pod Architecture

Clusters provided for different workload cases Small cluster will limited number of hosts running VDI machines that support multi-monitor Larger cluster will high number of hosts running VDI machines for a more standardised regular workload.



Further Resources

Thanks for reading!

Follow @Saintdle

Found this useful? Then share: Twitter

LinkedIn

Email

Facebook

Reddit

Print



Like this: Like Loading...