Deep Dive Comparison of DaaS & VDI Architecture Part 1
Posted on 04 May 2016 by Ray Heffer
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.
Quick Comparison
| Horizon DaaS | Horizon 7 |
|---|---|
| Multi-tenant architecture | Single-tenant architecture |
| Massive scale for thousands of desktops and tenants | Massive scale for thousands of desktops and tentant sites |
| Multi data center federation with CPA | Single data center deployments |
| Full desktop and Session-based (RDSH) | Full desktop and Session-based (RDSH) |
| Published applications (RemoteApp) | Published applications (RDSH) |
| VSPP Licensing (Service Provider) | Named user or concurrent connection licensing |
As you can see in the table above, they look very similar. Thanks Ray, that helps a bunch! – Hey, no problem ;)
Horizon DaaS has been built from the ground up to be consumed by multiple tenants. This makes it attractive to service providers wanting to offer a consumption based desktop model for their customers (OPEX).
Horizon 7 on the other hand, which is also designed for massive scale (up to 50,000 sessions in a cloud pod), provides a single tenant architecture for multiple data centers. This suits organizations of any size hosting their own infrastructure.
It’s all well and good that we can host tens of thousands of desktops, but you are probably thinking “What about me? I only want to start with thirty desktops, maybe one hundred, but not thousands!”. We hear you loud and clear. Horizon DaaS scales for both the service provider infrastructure and tenants joining the service. Once the DaaS platform is deployed you can start with just a handful of desktops. Horizon 7, while a single-tenant solution uses a building block approach so you can scale from just a few to thousands of desktops. More on that later.
For customers that want to host infrastructure in their own data centers, but take advantage of the cloud then we have Horizon Air Hybrid-Mode. You may remember the announcement at VMworld 2015 with Project Enzo. You can also read more about Horizon Air Hybrid-Mode with [this blog] (https://blogs.vmware.com/euc/2016/02/introducing-horizon-air-hybrid-mode.html) from Shikha Mittal, Snr. Product Line Manager.
Microsoft Licensing
I really don’t want to get into licensing, but I feel I need to dispel some myths that surround DaaS and VDI. Regardless of DaaS or VDI, if you are hosting a Windows desktop virtual machine (e.g. Windows 10) and want to provide remote access, then the Windows VM must be licensed. For that you have two options; Microsoft VDA (Virtual Desktop Access) or Software Assurance with Microsoft Volume licensing.
The VDA license is aimed at users with thin-clients that don’t have an existing Windows desktop PC, but want to remotely connect to a virtual desktop. The VDA license is tied to the client device.
In my opinion, the better option is Software Assurance (SA) which is part of a Microsoft Volume license agreement and is licensed per-user or per-device. Software Assurance includes virtual desktop access rights, so a VDA license is not required.
Now back in the day with ye old VDI, we only had support for virtual desktops, but for some time now Horizon supports both desktop virtual machines and Remote Desktop Session Host (RDSH) sessions. So regardless of DaaS or VDI, if you are a service provider offering session based desktops or applications then you can use the Microsoft SPLA (Service Provider Licensing Agreement) which is a monthly cost.
Horizon Architecture
At the core of any VDI solution are the desktop brokers, and for Horizon 7 we call these Connection servers. A single Connection server can support up to 2,000 desktop or application sessions. Notice I said ‘up to‘, so you could run just a handful of desktops, being brokered by a single Connection server in the knowledge that you can scale this to 2,000 desktop or application sessions without adding more servers. That said, I really wouldn’t recommend deploying just a single Connection server outside of a demo, lab or PoC environment. If that server were to fail then your entire Horizon solution (we call that a Pod) can’t broker any more connections. I mentioned Pod, let’s take a look at some of the terminology used with Horizon 7.
A single pod supports up to 7 Connection servers, and we support up to 10,000 sessions per Pod. An entire Cloud Pod can handle up to 50,000 sessions. Looking back at a smaller deployment, adding two or more Connection servers provides resilience should a Connection server fail, and most smaller Horizon deployments typically start with two Connection servers for availability.
The diagram below represents what a single Pod may look like. Management components such as vCenter, Horizon servers and virtual appliances are hosted in a dedicated management cluster. Each desktop Block is delineated by a dedicated vCenter server, each hosting one or more desktop resource clusters.
I mentioned that a ‘Cloud Pod’ supports up to 50,000 sessions. Put simply, VMware recommend that each desktop Block (vCenter) hosts up to 2,000 desktop or application sessions. A single ‘Pod’ as shown in the diagram above can contain multiple desktop ‘Blocks’ in addition to the management Block, up to a maximum of 10,000 sessions.
Cloud Pod Architecture is a technology introduced in Horizon 6 that allows for multiple ‘Pods’ to be linked using VIPA (View Inter-Pod API). Users (or groups) can be assigned to virtual desktop or application pools using Global Entitlements. Therefore a ‘Cloud Pod’ can host up to 50,000 desktop or application sessions.
Remote Access
Remote access to the virtual desktop or application is catered for in two ways with Horizon 7. The first option is to use Security servers as shown in the diagram below. Think of these as a DMZ gateway service that facilitates external connections. Like the Connection server, a Security server is installed on a Windows Server OS. Each Security server you deploy must be paired with a Connection server. It is not recommended that you use Connection servers that are paired for external access, for internal access as well. Always dedicate Connection servers for your internal connections, and use Security/Connection server pairs for external connections.
In the diagram above, internal connections either via VPN or within the company network will connect via a load-balancer. I’ve used an NSX load-balancer in this example, which sits in front of a pair of Connection servers. Once the user has authenticated via one of the Connection servers, the actual connection is direct from the Horizon Client to the virtual desktop or application. This is called direct-mode.
Using the same example above, external connections also hit the load-balancer first which sits in front of two or more Security servers. Once the user authenticates and selects a desktop or application, the Security server responds with its external URL. The Horizon Client will connect to the Security server’s external URL (public facing IP address). The remote display protocol is then forwarded from the Security server to the virtual desktop or application (not direct from the Horizon Client). This is called tunneled-mode.
Access Point is another option and can be used instead of Security servers. These are virtual appliances that have some major advantages, including the fact it doesn’t require pairing with the Connection server, and also its running a hardened Linux distribution. Many service providers are keen to use virtual appliances where possible as this avoids using additional Windows Server licenses, but also favors the use of Linux virtual appliances in the DMZ rather than Windows Servers.
Desktop Deployment Options
Horizon offers full clones, linked clones, and new with Horizon 7 are Instant Clones. Full clones use a template virtual machine in vCenter (our master) and a full clone desktop pool will contain a number of desktops that are full copies of the master (or parent) VM. They will have their own MAC address, computer name and IP address, but are otherwise full copies of the parent virtual machine. This is a good option for providing a dedicated desktop to someone that wants complete control, such as installing their own applications. However, it’s not the only option for the dedicated desktop.
Next we have ‘linked clones’. These are ideal for the non-persistent desktop where a master image is maintained and a number of linked clones are created based of the master. This differs to full clones in a number of ways. First, the linked clone technology is extremely efficient on storage space. Rather than simply cloning the master VM each time, it is linked, meaning that the linked clone VM contains the unique delta changes.
To make this possible, Horizon uses View Composer which is typically hosted on a dedicated Windows Server virtual machine.
The virtual machine disk is also constructed differently. When a linked clone desktop pool is created, the master virtual machine is cloned to a ‘replica’ virtual machine. The replica is a essentially a virtual disk that is used for read operations. As data is changed, the data is written to the delta virtual disk, unique to each virtual desktop.
The other advantage to linked clones is you have the option to refresh or even delete the virtual machine at log off. Next time the user logs in they get a fresh copy of the mater desktop image. This is a great option for maintaining corporate desktop standards.
Horizon 7 introduces another new technology called Instant Clones which when used in combination with App Volumes and User Environment Manager, allows for Just-in-Time desktops. You may remember at VMworld 2014 we announced VM Fork (aka Project Fargo), an exciting new technology that creates desktops in seconds. Providing you have vSphere 6 U1 or higher, Horizon 7 leverages this technology for Instant Clones. Instant Clones do not require View Composer.
RDSH Sessions
I mentioned earlier in this post about RDSH (Remote Desktop Session Host) sessions. Please don’t think of these as a second class citizen, apart from the obvious benefits of licensing, RDSH sessions can also provide the same rich user experience. In fact I recorded a video of 3D applications on RDSH recently, which you can see below.
RDSH sessions can be deployed into both desktop or application pools, meaning that the end-user doesn’t necessarily have to launch a desktop session to access their applications. With further integration with Workspace ONE, end-users can open applications on any device with single sign-on (True SSO). You can learn more about Workspace ONE here.
Horizon 7 Terminology
| Terminology | Description |
|---|---|
| Desktop | Virtual desktops for end users |
| Connection Server | Provides brokering and configuration of desktops, applications and RDSH sessions. The Connection server is also used to authenticate users, and configure the Horizon infrastructure through the web UI (View Administrator) |
| Security Server | Provides remote access via the DMZ using a number of gateways, including the PCoIP Secure Gateway, HTML Access, HTTPS Secure Tunnel, and Blast Secure Gateway |
| Replica | Linked clone (read-only) replica, cloned from the master virtual machine |
| Linked Clone | Virtual desktop delta copy |
| Full Clone | Full copy of the master virtual machine |
| Instant Clone | Virtual desktop clone using VM Fork technology with vSphere 6 |
| Pod | Instance of Horizon Connection servers, Security Servers and / or Access Point, with multiple blocks (vCenter) and desktop resource clusters |
| Block | A block consists of a vCenter server and one or more vSphere clusters for management or desktops. Management blocks are separate from desktop resource blocks |
| Cloud Pod | One or Pods can be initialized as a Cloud Pod which provides global entitlements to multiple pods at different sites. This provides options for disaster recovery and roaming users |
Conclusion
I have introduced you to the Horizon 7 architecture and a typical single-tenant deployment using Pods and Blocks. In part 2, I will discuss the Horizon DaaS platform architecture and how this offers massive scale for multiple tenants in a service provider environment.