Since I published the Horizon 7 Network Ports diagram with the latest release of Horizon 7, I’ve been frequently asked about the connection flow between the Horizon Client and the virtual desktop. VMware Horizon supports RDP, PCoIP and now Blast Extreme. I’ll start with PCoIP and then we’ll look at Blast Extreme.
The connection flow of the Horizon Client is largely the same with Horizon 7, Horizon Air or Horizon DaaS. There may be differences in external load-balancing, Security Server or Access Point, and external URL configuration, but for this post I’ll focus on the Horizon Client itself and the aforementioned protocols.
A colleague asked me a very good question which I’d also like to address. How does Access Point know which VM to connect to?
Access Point doesn’t need to know which ESXi host is running the VM. When the entitled desktops are returned to the client(see 1b below) it also receives the external URL of the Access Point appliance, this is where the Horizon Client > Access Point connection is established on HTTPS (TCP 443). This could be a VIP on the load-balancer, or an external facing IP for each of the Access Point appliances, depending on the configuration (see Method 3 of Mark’s article).
When the user launches the chosen desktop pool, Access Point will communicate on HTTPS (TCP 443) to receive the desktop IP from the Connection server. The role of the PCoIP Gateway on the Access Point appliance is to then forward the PCoIP connection to the IP address of the Horizon Agent.
Note: In the past, Security Server used JMS, IPsec and AJP13, but Access Point doesn’t use these protocols (JMS is still used on the Connection Servers). If you refer to my Horizon 7 Network Ports diagram, you’ll see I’ve put these in a dotted line to show this.
Tunneled Connections (PCoIP)
When looking at the adoption of public or hybrid cloud, one of the primary considerations must be how to migrate existing workloads to the target platform. Choosing the right migration tool(s) will prove critical in the coaching of customers, mainly their IT and application owners, to address this challenge. There are many VMware vCloud® Air™ Network architectures that can provide workload mobility where capabilities, like hybrid cloud networking enabled by VMware NSX®, and other solutions, such as VMware Site Recovery Manager™, might be in place. Enterprise migration technologies however, span a much broader scope than that of moving applications hosted on physical or virtual infrastructure to a cloud architecture. Specifically, these tools address the enterprise architecture features required to discover, plan, and execute migration, while allowing for scheduling and systems level dependencies.
VMware offers tools that address many of these needs and some have been described in the VMware vCloud Architecture Toolkit™ for Service Providers (vCAT-SP) blog and white paper. As stated in the vCAT-SP documentation for migration, offerings will not meet all requirements for migrating workloads to the cloud, and the purpose of this series of blogs is to allow VMware Technology Partners to discuss their solutions and advocate for why they might be the best choice in many situations. Many standard forms of analysis will apply to the evaluation of enterprise migration technologies, including common items such as pricing, support, or strategic direction. This series of blogs will focus on the more technical aspects, such as ease of deployment/usage, versatility, reliability, scalability, and security. The blog entries will also cover optimal use cases addressed by the partner solutions, often with customer references.
The first blog in this series is with VMware Technology Partner ATADATA. In particular, their enterprise migration solution focusing on their ATAvision and ATAmotion products. The combination of these two offerings fits into the “Discover & Assess, Job Scheduling, Workload Migration, Application Verification” lifecycle described in the blog and vCAT-SP documentation referenced above. The first three letters of the ATADATA name are an acronym for “any to any” and their deployment model, shown in the following figure, indicates their abstraction from the underlying physical, virtual, or cloud infrastructures that are part of an enterprise migration. This capability enables their technology to not only support many platforms (see ATADATA supported platforms), but to provide a consistent abstraction of underlying details for migrating between sources and targets of any supported type.