Horizon 8 on Google Cloud VMware Engine Configuration

This chapter is one of a series that make up the Omnissa Workspace ONE and Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Omnissa Workspace ONE and Omnissa Horizon solutions. This chapter provides information about common configuration and deployment tasks for Omnissa Horizon 8 on Google Cloud VMware Engine (referred to as GCVE throughout this document).

A companion chapter, Horizon 8 on Google Cloud VMware Engine Architecture, provides design guidance.

Prerequisites

Before you begin, you must install and configure the following components:

GCVE resources assigned to you
Google Cloud login
Omnissa Horizon Universal Licensing with access to myvmare.com, required to set up licensing on the Horizon Cloud Connector
If deploying Horizon with the All-in-SDDC Architecture:
- Third-party load balancer to install into GCP to forward Horizon protocol traffic from GCP to GCVE

You should also review the following documentation:

Google Cloud Platform Configuration

This section covers configuration of the Google Cloud Platform (GCP) to prepare for Horizon installation. This information is provided as reference and the official Google docs should be used for your actual configuration.

See the following guides to help you get started:

Following are the steps we went through when creating the Reference Architecture environment. Your configuration might vary, this information is provided as reference. Rely on the official Google quick-start guides referenced previously for your actual configuration.

Google Cloud Console

To get to the Google cloud console, where both Google Cloud Platform and GCVE are managed, go to https://console.cloud.google.com/

Create VPC Network

The first step is to create a Virtual Private Cloud which will contain the networks for your implementation. See Google Cloud VPC Networking Overview for more information.

On the GCP Menu, in the Networking section, select VPC Network > VPC Networks.
Click Create VPC Network on the top.
Enter the subnet details to create the VPC network:

Field	Value
Name	name of network
Description	description
Subnet Creation Mode	Custom
New Subnet > Name	name of subnet
New Subnet > Region	GCP region
New Subnet > IP Address Range	Example: 10.20.0.0/24 (GW: 10.20.0.1)
New Subnet > Private Google Access	Off
New Subnet > Flow Logs	Off
Dynamic Routing Mode	Regional

Configure VPC / GCVE Private Service Connection

A private service connection must be established between any VPC network that needs access to GCVE (for example, Internal DMZ VPC). Additionally, any subnets created inside of GCVE must be manually allocated to allow communication between the GCP and GCVE environments.

See the following documents for more details:

GCVE Documentation for setting up a private service connection and allocating IP ranges
GCVE Prerequisites
Configuring private services access

Figure 1: VPC Network Private Service Connection

Important: After you create segments in NSX for the Horizon infrastructure, you must come back to this section and add those subnets for them to communicate with GCP.

Create Firewall Rules in GCP

Note that by default, they are set to deny all. Make sure to set the ports required for Horizon on both the GCVE Firewall and the VPC Firewall.

Navigate to VPC Network > VPC Networks > **VPC network you created**.
Select the Firewall rules tab.
Click Add firewall rule and add a rule for each subnet created in GCVE to allow traffic to flow in and out of GCP. After segments are created in GCVE, new firewall rules in GCP must be added.
Refer to Network Ports in Horizon 8 for required Horizon ports.

Note: Depending on setup and network requirements, we also recommend creating a firewall rule for the entire range assigned to GCVE. For example, instead of creating multiple /24 rules, create a /22 rule.

See the Google Cloud Platform documentation on setting firewall rules in GCP.

Enable Cloud NAT for Internet Access

Enable Cloud NAT for your VPC to allow internet access. See Using Cloud NAT for details.

Deploy Unified Access Gateway in GCP

In the Federated Architecture of Horizon on GCVE, the Unified Access Gateways (UAG) are in GCP. This prevents Horizon protocol hair-pinning which could happen when the UAG is placed inside the SDDC. This is supported as of UAG 2103. See Deploying Unified Access Gateway on Google Cloud for guidance.

Deploy the Horizon Cloud Connector into GCP

As of Horizon 2103, the Horizon Cloud Connector is supported for installation into GCP using version 1.10 or later. There is a disk.raw version zipped as a tar.gz file. This is a requirement for importing an existing image into GCP. See the Google documentation on importing existing image.

For the latest guidance on sizing the Horizon Cloud Connector when deploying on GCVE, see Horizon 8 Pods with First-Gen Horizon Control Plane - Requirements Checklist - Starting November 2, 2023.

After you deploy the cloud connector image, and before you start it up the first time, you will need to create a startup script on the VM to update the hosts files with the names of your connection servers and virtual centers. It should look like the image below. After you have started up the system and bound your cloud connector to the Horizon Control Plane, you can delete the startup script.

Figure 2: GCP Startup Script used on first startup of Horizon Cloud Connector

VPC Peering

When a Virtual Private Cloud (VPC) network is created, it is essentially an island. There is no connectivity by default to other VPC networks. We need to use VPC Peering to connect two separate VPC networks and allow them to communicate internally. See the Google documentation on VPC Peering for an overview and Using VCP Network Peering for directions on configuration. We need to use VPC peering in the Federated Architecture to connect the Internal DMZ network used for UAG to the VPC network where the Horizon management components are located. A private service connection between the Internal DMZ VPC and each GCVE SDDC where desktop and RDS capacity will be used. See Network Configuration for more details on networking requirements.

Figure 3: Horizon on GCVE Federated Architecture Networking

GCVE Configuration

This section covers configuration of the GCVE environment to prepare for Horizon installation. This information is provided as reference and the official Google docs should be used for your actual configuration.

To get to the GCVE console:

In the GCVE console, browse to Compute in the GCP menu and select VMware Engine.
In the GCVE console, select Resources and then select the name of your private cloud.
Now, select Summary and make note of the Private Cloud DNS Server addresses, which are required for setting up conditional forwarding.

Deploying Multiple GCVE SDDCs

When you deploy additional SDDCs in GCVE make sure to use unique CIDR ranges (a method for IP addresses and routing) for the Management Network. Otherwise with the default settings, each vSphere / NSX server will have the same IP address and you will not be able to use them with Horizon. See How to Create a Private Cloud for details.

Configure DNS

You must define settings on your DNS server for gve.goog pointing to the IP addresses of the Private Cloud DNS servers captured in the previous step, or create a forward lookup zone for gve.goog. This will allow name resolution for the vCenter and NSX appliances.

Single GCVE SDDC:

For this design, you can use a conditional forwarder to have your local DNS server use the DNS servers in the SDDC to do name lookup of management appliances. See Create a Conditional Forwarder for details.

Multiple GCVE SDDCs:

When multiple SDDCs are deployed, you cannot use a conditional forwarder. One way to accomplish the name resolution needed by Horizon is to create a forward lookup zone for gve.goog in the DNS server you are using for your Horizon infrastructure.

Figure 4: vCenter and NSX Manager FQDNs in GCVE Admin Console

You would add A records for the fully qualified names and IPs of each vCenter and NSX appliance.

Figure 5: gve.goog forward lookup zone in DNS

See Configuring DNS for vCenter access for more details on the process.

NSX

Networking for your SDDC must be created in the NSX admin console. When you are in the GCVE management console, select vSphere Management Network, and then click the link for the NSX Manager under FQDN.

Figure 6: NSX Manager FQDN in GCVE Admin Console

Log in to the NSX Manager using the default login credentials:

Username: admin
Password: VMwareEngine123!

Create segments for Desktops, Management, and Internal and External DMZ.
Enable DHCP on the desktops segment and optionally the management segment.
See the NSX Installation Guide for more information on how this is done.
Update the GCVE Firewall for communication to/from GCP for newly created segments.

vSphere Console

In the same section that the NSX console was launched, you can launch the vSphere console. This is where the Horizon infrastructure is created and managed.

Click the link under FQDN for the vCenter Server Appliance.
Log in to vCenter using the default login:

Username: CloudOwner@gve.local
Password: VMwareEngine123!

External Access

Optionally, set up VPN or Cloud Interconnect for backhaul to on-premises. In this reference architecture, we created a VPN connection from GCP back to our on-premises data center. This allowed us to extend our domain into the GCVE environment and provide file server replication via DFS-R for Dynamic Environment Manager.

See the following documents for configuring external access into GCP:

Load Balancing in the All-In-SDDC Architecture

If deploying the All-in-SDDC architecture where all Horizon resources, including the Unified Access Gateways, are located in the GCVE SDDC, there is no way to directly route Horizon protocol traffic from GCP into the SDDC. We need a load balancer in native GCP to forward the protocol traffic from the Internet to the UAGs inside of the GCVE SDDC.

One option is to use the Avi Load Balancer on GCP, which can integrate with GCP via a cloud integration and perform all these configurations automatically.

Additionally, see Load Balancing Unified Access Gateway in Horizon 8 Architecture.

Forwarding Traffic to Third-Party Load Balancer in GCP

A third-party load balancer is required inside of GCP to route protocol traffic into the SDDC. It can be any type of load balancer which does HTTP, Layer 4, and Layer 7 load balancing. If the load balancer does not have integration with GCP like the NSX Advanced load balancer does, some manual steps are required to forward the external IP address into the load balancer. The GCP Load Balancer needs to be configured to forward TCP and UDP from the public IP address that is tied to your FQDN to the third-party load balancer. These steps are detailed below.

Create Static External IP Address

First, we will create a static external IP address inside the GCP VPC networking. This IP will be used by the load balancer and should be assigned a public DNS entry for users to connect to desktop resources. For example, gcve-horizon.domain.com.

Go to VPC network > External IP Addresses.
Note the External IP address. You will need it in the next steps.

Create Load Balancer in GCP

We will now create a load balancer in GCP that will be used to forward external traffic (TCP/UDP) from the external IP address to our third-party load balancer. We cannot use the GCP load balancer for systems inside GCVE, so we need to use the third-party load balancer.

Before you perform this step, your third-party load balancer should be installed into native GCP.

Navigate to Networking > Network Services in the GCP Console.
Select Load Balancing.
Navigate to the Advanced Menu.

Create Target Pool

Create a target pool to put the third-party load balancer into.
Configure the target pool by providing the following information:

Provide a name and description.
Select the GCP region where your load balancer is located.
Select No health check.
Select None for session affinity.
Add your existing load balancer instances from GCP into the pool (can be multiple).
Select None for Backup pool.
Click Create.

Create TCP Forwarding Rule

We will now create forwarding rules, to forward TCP and UDP traffic from the external IP address to the pool we just created.

Click Create Forwarding Rule to start creating the TCP forwarding rule.
Configure the TCP forwarding rule by providing the following information:

Enter a name and description (add the protocol being forwarded).
Select the region where your load balancers are.
Select the external IP you created earlier.
Select the protocol as TCP.
Leave Port/range blank to forward all rules.
Select the target pool you created in the previous step containing your load balancer(s).

Create UDP Forwarding Rule

Create a second forwarding rule for UDP.
Enter a name and description and include UDP in the name.
Select the region where your load balancers are located.
Select the external IP you created earlier.
Select UDP as the protocol.
Leave the Port range blank to forward all UDP traffic.
Select the pool you created earlier containing your load balancers.
Review the load balancer forwarding rules that were created.

Review Load Balancer and External IP

If you select Load Balancing, you will see a new TCP/UDP load balancer created to forward external traffic to your load balancers.

Navigate to VPC network > External IP Addresses.
Review the External IP Address you just created for the load balancer created in GCP. It will now have the forwarding rules attached to it for TCP and UDP.

Load Balancing in the Federated Architecture

In the Federated Architecture, the Google Load Balancer can be used to load balance the Unified Access Gateway appliances. There is no need for a third-party load balancer like in the All-in-SDDC Architecture.