In part 4 of our VCAP7-DTM design study guide, the network design will be discussed.
This section will be broken down into some key topics that will guide you in your design and study for the VCAP7-DTM design exam.
As before if you have missed any of the previous parts. Following index provides a nice overview:
VCAP7-DTM Design study guide Part 1 – phase 1 & 2: logical design
VCAP7-DTM Design study guide Part 2 – phase 3: physical design
VCAP7-DTM Design study guide Part 3 – phase 4: physical design
VCAP7-DTM Design study guide Part 4 – phase 5: network design
Section 5 – Create a network Design for Horizon solutions
For me, the networking design of a Horizon Solution must always be as simple as possible.
One of the most used diagrams that I use is the Network and port overview for a Horizon 7 deployment that can be found on Techzone.
This is an excellent piece of documentation that provides a clear and granular overview of all different types of network flows.
Networking for Horizon components
As a Horizon environment is build consisting out of the different blocks, the same network requirements can be maintained.
So let’s start with the essentials and basics. A Horizon environment as mentioned consists out of multiple individual components.
As mentioned above the basic setup of a Horizon environment is nicely described in the networks and port overview.
I will highlight some components as these may vary in complexity depending on the setup.
Cloud Pod Architecture
The core components of a Horizon Solution is the connection servers. This can be a standalone server, a single pod with multiple connection servers federated together. Or a global deployment using multiple sites and pods that stretch the entire globe.
With a single pod, up to seven connection servers are replicating their local ADAM LDS database.
This is done using the Java Messaging Service (JMS): TCP 4001 and TCP 4104.
When using multiple pods, this changes a little bit as now a global ADAM database needs to be replicated as well.
As seen above we have a Cloud pod architecture, where the global LDAP replication occurs between the two pods.
This is done using the ADLDS replication on TCP 22389 and TCP 22636.
Interpod communication is done using the VIPA protocol on port TCP 8472.
External Access – UAG
When making a Horizon environment externally available, the necessary networking security needs to be in place.
The Unified Access Gateway (UAG) is a photon-based appliance that will be used as a reverse proxy between the horizon environment and the worldwide web.
A UAG can be deployed in different deployment types: single, dual en triple nic deployment.
|Deployment type||NIC Usage||Best practice|
|Single NIC||Unauthenticated, authenticated and management run on the same NIC||Good for proof of concepts|
|Dual NIC||Unauthenticated on 1 NIC and authenticated & mgmt on other NIC||Good for single DMZ implementations|
|Triple NIC||Unauthenticated on 1 NIC, 1 for authenticated and one mgmt on the 3rd NIC||Good for dual DMZ implementations|
Each UAG deployment type does have other prerequisites on the network infrastructure and implementation.
A pair of UAGs can be implemented with the builtin load balancer functionality or a 3rd party load balancer like an NSX, F5, Avi networks LB or Netscaler. Configuring these will provide additional configuration options compared to the built-in functionality.
A well-written configuration example of UAG’s using a Netscaler for load balancing is Carl Stalhood’s article.
External Access – IDM
Workspace ONE Access or previously known as Identity Manager (IDM) can also be integrated into the Solution to provide a single user portal/catalog and unified way of accessing the environment. The implementation of IDM will have some implications on the networking design as well. Depending on the type of IDM, SAAS based, or on-prem, networking will be different.
The SAAS deployment will require an outbound 443 connection between the WS1 Connector and the SAAS Tennant.
With an on-prem implementation, the network traffic will be going directly to an IDM appliance located in the DMZ. A high-available setup will replace the single node with a three-node cluster using a load balancer in front of the cluster.
It is clear that the SAAS deployment is the simplest in setup. But for example, certain companies can have a no SAAS company policy.
When we talk about vSphere and Networking, NSX automatically comes to mind. A nice blog post on the high-level overview of the NSX architecture was written by a friend of mine: Timothy De Wolf. You can read the article over here: vblog-dewolf
When designing a Horizon solution, the NSX functionalities can be fully incorporated into the design. Micro-segmentation and load-balancing are some nice examples of use-cases. Micro-segmentation allows the isolation of specific desktop pools and only allow certain network flows to be permitted.
Vmware had created an NSX for EUC Design guide which can be found here on the VMTN forums
I won’t go into much detail about the multi-cloud possibilities as this is not part of the exam blueprint.
But with solutions like VMC on AWS and AZURE, the true hybrid cloud platforms are becoming more and more frequent.
This has in its turn implications on the networking perspective. I will be creating a separate blog post on this.
But VMware HCX, is the perfect solution to couple everything together nicely.
In the next part of the VCAP7-DTM study guide series, we will continue with the network design.
We will discuss the different protocols, capacity requirements and GPO configuration.
One comment on “VCAP7-DTM Design study guide Part 4”