Author Archives: Ray Heffer

About Ray Heffer

Ray Heffer is a Staff Cloud Solutions Architect and End-User Computing (EUC) lead for VMware. He has over 20 years experience in the industry and has been awarded vExpert 2011-2017 including vExpert-Cloud. Ray is also a Double VCDX certification holder #122 (Desktop and Data Center Virtualization) and a panelist on the VCDX program. Follow Ray on Twitter @rayheffer

VMware Hybrid Cloud Extension (HCX) Network Ports

I’d like to share a high-resolution network ports diagram of VMware Hybrid Cloud Extension service (previously known as HCX) that I have been working on this week. If you are considering using Hybrid Cloud Extension to solve your hybrid cloud challenges then this PDF would look great on any 4k monitor or perhaps printed for the office wall!

Download the diagram here: VMware HCX Network Ports 1.1

The first thing to notice is that HCX abstracts the underlying vSphere architecture which means that between the source and destination data centers, there is no direct communication (E.g. vMotion) between vSphere ESXi hosts.

VMware Hybrid Cloud Extension allows enterprises to overcome some of the challenges with moving to the cloud. Cloud Providers with the VMware Hybrid Cloud Extension (HCX) service can provide a true hybrid-cloud experience for workload portability, agility, disaster recovery and business continuity. This allows cloud providers to take the lead with hybrid cloud solutions, abstracting customer on-premises and cloud resources as one seamless cloud. No changes are required on the source network infrastructure, eliminating complexity for tenants of the cloud platform.

Don’t just think of Hybrid Cloud Extension as just a workload migration tool. One of the fundamental components of Hybrid Cloud Extension is the ability to provide a layer 2 extension of the customer data center to the cloud. This provides the basis for cross-cloud mobility allowing for any-to-any vSphere zero downtime migrations, seamless disaster recovery, and enabling hybrid architecture.

While migration is probably the most common use-case, there are many other challenges that are solved. Firstly, unlike professional services led migrations that often require costly and time-consuming workload assessments, cloud providers can provide an end-to-end service without the much of the additional complexity involved in the past. Another use-case allows migrations from legacy to next-generation environments, that are complex due to different versions of the underlying infrastructure (vSphere).

To learn more about Hybrid Cloud Service, visit https://cloud.vmware.com or contact your VMware partner business manager.

Also available in the VMware HCX User Manual.

 

VMware Horizon 7.4 Network Ports for Cloud Pod Architecture


Earlier this month (January 2018) VMware released Horizon 7.4, and with that I wanted to share some updates in regard to the network port requirements. My good colleagues over in the EUC Technical Marketing team are doing a fine job of maintaining the diagram and have recently published a white paper PDF which you’ll find here. It’s a beast of a document and highly recommended if you are deploying a VMware Horizon architecture in your environment.

An important consideration when using this network ports diagram, is that it doesn’t necessarily contain all non-VMware related ports such as Active Directory, DNS, NTP, SMB and so on. In fact one of my colleagues in the Office of the CTO mentioned this, since one of his customers ran into an issue where TCP port 135 was blocked, but this was required when joining a Pod to a federation (Cloud Pod Architecture). I thought this would be a good opportunity to describe what Cloud Pod Architecture is doing behind the scenes and provide some updates. Continue reading

Cloud Momentum: VMware Cross-Cloud Architecture

We’re just days away from another VMworld in Las Vegas, and it’s going to be another amazing year, with a packed agenda crammed with sessions on our SDDC stack, including vSAN, NSX and vSphere, in addition to VMware on AWS and Cloud Foundation, all being my favorite topics at the moment. You’ll also find me discussing Cross-Cloud Architecture along with Adrian Roberts and Victor Sandoval, in the Ask the vCloud Air Network Cloud Experts [LHC1566PU] session which is on Monday at 12.30 so feel free to bring something to eat and drink for an hour of technical discussion!

I was also fortunate enough to be invited to the Virtustream Global Developer conference in Florida last week, and one of the topics I presented was titled ‘Cloud Momentum: Cross-Cloud Services and Architecture’. I must say that the team at Virtustream have some amazing talent so be sure to check them out at VMworld!

While I’m on the subject of Cross-Cloud architecture, there is a real challenge that I think customers are trying to solve. Firstly, cloud consumers have choice, but with that it’s inevitable that things don’t always turn out to be clear-cut. For example, let’s say we have a customer that wants to migrate their workload to the cloud. Most of their applications today have a traditional deployment with a database back-end, reliance on certain versions of Microsoft SQL and legacy dependencies which makes scale difficult. These traditional applications are not going to suit Azure, AWS or Google Cloud, but with VMware on AWS they can expand their existing vSphere infrastructure that they have on-premises, to an AWS data center.

As customers then introduce cloud native applications to their organization, they can take advantage of AWS services such as S3 and DynamoDB. What makes this relationship so unique is there traditional workloads can be placed side-by-side in the same AWS region and availability zone (AZ). This avoids network traffic having to occur over a VPN or Direct Connect, and they can keep the traffic internal to the AWS network. Taking things one step further, workloads can easily be moved using vMotion from their on-premises data center to AWS and visa-versa.

There will be much more to reveal at VMworld where you’ll hear the latest news on Cross-Cloud services and architecture.

See you in Las Vegas!

Architecting the Digital Workspace for Service Providers with Horizon 7

I recently published a white paper aimed at service providers offering VMware Horizon 7 for tenants adopting the digital workspace. Horizon 7 is a single-tenanted VDI and application platform, allowing IT administrators to manage not only desktop pools, but application delivery to their end-users.

The ‘digital workspace’ provides a “consumer simple” digital platform for end-users accessing their day to day and most critical applications. Underneath the hood is a VDI architecture that has evolved and long since the days of the traditional desktop broker.

This white paper breaks down the digital workspace into five distinct layers, which have a direct correlation to tenant-facing functionality, service provider boundaries (for instance, firewall ports, user portal integration), core and management infrastructure.

digital-workspace-layers
Continue reading

VMware Horizon Client (PCoIP & Blast) Connection Workflow

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)

VMware Horizon PCoIP Connection Flow
Continue reading

Deep Dive Architecture Comparison of DaaS & VDI, Part 2

In part 1 of this blog series, I discussed the Horizon 7 architecture and a typical single-tenant deployment using Pods and Blocks. In this post I will discuss the Horizon DaaS platform architecture and how this offers massive scale for multiple tenants in a service provider environment.

Horizon DaaS Architecture

The fundamental difference with the Horizon DaaS platform is multi-tenancy architecture. There are no Connection or Security servers, but there are some commonalities. I mentioned Access Point previously, this was originally developed for Horizon Air, and is now a key component for both Horizon 7 and DaaS for remote access.

 

Horizon DaaS Architecture

If you take a look at the diagram above you’ll see these key differences. Let’s start with the management appliances.
Continue reading

Deep Dive Architecture Comparison of DaaS & VDI, Part 1

In this two part blog series, I introduce the architecture behind Horizon DaaS and the recently announced Horizon 7. From a service provider point of view, the Horizon® family of products offers massive scale from both single-tenant deployments and multi-tenanted service offerings.

Many of you are very familiar with the term Virtual Desktop Infrastructure (VDI), but I don’t think the term does any justice to the evolution of the virtual desktop. VDI can have very different meanings depending on who you are talking to. Back in 2007 when VMware acquired Propero, which soon became VDM (then View and Horizon), VDI was very much about brokering virtual machines running a desktop OS to end-users using a remote display protocol. Almost a decade later, VMware Horizon is vastly different and it has matured into an enterprise desktop and application delivery platform for any device. Really… Horizon 7 is the ultimate supercar of VDI compared to what it was a decade ago.

I’ve read articles that compare VDI to DaaS but they all seem to skip this evolution of VDI and compare it to the traditional desktop broker of the past. DaaS on the other hand provides the platform of choice for service providers offering Desktops as a Service. DaaS was acquired in October 2013 (formerly Desktone). In fact I remember the day of the announcement because I was working on a large VMware Horizon deployment for a service provider at the time.

For this blog post I’d like to start our comparisons on the fundamental architecture of the Horizon DaaS platform to Horizon 7 which was announced in February 2016. This article is aimed at consultants and architects wishing to learn more about the DaaS platform.
Continue reading