Blog

Horizon Virtual Desktops: A Guide to Your DaaS Architecture

Posted on October 25, 2017 in VMWare, VDI, VDI-as-a-Service, Branch in a Box, vCenter by Dirk Arends

Beginning Architecture Considerations

VMWare Horizon offers 2 Pool Types, 2 User Assignment Options, and 2 Desktop Provisioning Methods. So, Horizon users have 8 basic architectures and myriad variations from which they can create the ideal VDI architecture for their business.

Whether you are new to an exploration of VDI or you’ve been executing VDI for years, it’s always a great practice to take a high-level view and ask yourself if there are better ways to architect and execute your infrastructure solutions. Read on for some basic framework options in VMWare Horizon and when those options might be the right choice.

Virtual Systems is one of the only cloud infrastructure partners in the world that offers VMWare Horizon in a Desktop-as-a-Service model with no minimum attainment tiers, making VDI attainable and affordable in the SMB and Mid-Size business space.

Basic Architecture

Traditional VDI architecture requires a pod of 10 or more Virtual Desktops that utilize a small security server, a connection server, and a domain controller in the data center with the desktops.

The connection server facilitates connections from users on the thick client or web to the desktop they’ll be assigned to. The security server is located in the DMZ of the network to pass only secure traffic to the connection server. Application servers may also be hosted in the data center or, alternatively, a VPN configuration might be utilized so desktops can talk to application servers and/or data stored in your own environment.

Older conventional wisdom suggested the hybrid cloud model could introduce unnecessary lag to the user experience but improvements to VMWare’s VDI architecture over the last 24 months have remedied that problem to an almost imperceptible level.

Depending on workloads, desktop pods benefit from additional connection/security servers at around the 50-100 level. These pods can be spread across data centers (to mitigate single-point-of-failure risk) or they may be contained in the same data center. As we examine further architecture options, start with this basic framework in mind.

Pool Types: Automated & Manual

With an Automated pool, vCenter Server is used to create the virtual machines automatically from a master image. An automated pool will almost always be used in every deployment. Horizon will then use vCenter to manage the VMs, such as power them on, delete them, re-create them, and so on.

With a Manual pool, the desktop(s) already exist and could be a virtual machine both managed and unmanaged by vCenter or even a physical desktop. This pool type is atypical but it’s important you’re aware of it if you see the need for a Manual Pool arise in your work environment.

Assignment Options: Dedicated & Floating

Dedicated user assignment is just that, a named user is assigned a specific desktop in the pool. No other users may use that desktop, even if the assigned user is not logged on and there are no spare desktops in the pool. Additionally, with dedicated assignment users may be either assigned a desktop before they logon, or the first time the logon an unused desktop will be allocated to them to use from that point forward. (e.g DOMAIN\jane.doe is assigned to desktop VDI-W8-123).

Floating user assignment allows a user to logon to any desktop that is available within the desktop pool. Each time a user logs off and on, they will get a different randomly selected desktop each time. Users retain their unique profiles and application sets even though they’re assigned different desktop resources.

(e.g. Logon 1: DOMAIN\jane.doe assigned desktop VDI-W8-001

Logon 2: DOMAIN\jane.doe assigned desktop VDI-W8-321)

Desktop Provisioning Methods: Full Clones & Linked Clones (Horizon Composer)

Full Clones use a master image in template format. The master image is built exactly as required and the template is cloned by vCenter the required number of times to the exact same size as the virtual machine. So if the virtual machine is 25GB in size and you have 100 VMs, that is 2.5TB. This of course requires a large amount of storage and to provision that many VMs may take some time. Once the desktops are created, they are completely independent copies of the master image which must be managed and updated by another tool such as Altiris, WSUS, SCCM and various scripts as required.

Linked Clones use a feature called Horizon Composer which decreases the storage space required and improves management. Linked clones utilize a master image in virtual machine format with at least one snapshot which represents the version instance of the master image you wish to create the desktops in the pool from. When a linked clone desktop pool is created, a replica VM (parent) is first provisioned, then the required number of desktops are created as a child VM of the replica VM. These linked clone desktops read from the replica disk and write changes to a different disk. Initially before being powered on are KBs in size and during daily use can range from 1-5GB depending on OS, apps, page file and usage. However, they represent around an 80% storage space saving on full clones. Furthermore, with linked clones, it is possible to configure the pool to refresh or delete the desktop at logoff, ensure the desktop is exactly as per the master image, and discard the different disk changes that have occurred.

ThinApping to supplement your desktop pool type

You might already be able to see that Automated Linked Clone Floating Pools have strong benefits (and are a typical configuration). While it’s a strong architecture, it may not always be the best for every user group. Your solution may likely include both full clones and linked clones. Understanding the user groups that may be departmental and what applications they use will inform your direction in this. In most cases all users require a standard application stack such as Windows 10, O365, Adobe Reader, Flash, etc.

However, in addition to this, you may find a department which this standard stack suffices but a couple of users that also require another 3rd party application. In this case rather than creating a separate pool just for this small requirement, ThinApp could be utilized to capture the application and make it available to those 2 users in the desktop pool. This saves having to clone the master image, install the 2 applications and manage 2 master images.

It would not be good practice to create the desktop pool as full clones because of a few requirements such as this. Doing that might have a dramatic effect on the underlying storage requirements and costs.

If you do have a scenario where an application cannot be ThinApp’d and a group of users must be able to for example install their own applications, this is a requirement for an automated full clone pool. However, a desktop in this pool might have a higher cost associated with it due to increased storage (e.g. 25GB to 75GB) and also increased management (e.g. solution required to update/manage desktop – Altiris, SCCM)

Conclusion 

The options you’ll find in Horizon should spark some dialogue on your IT team about the strategies that best fit user groups in your organization. Keep the dialogue going with your Virtual Systems account team to figure out which methods might apply to your work groups and how best to deploy them! Interested in exploring VDI-as-a-Service with Virtual Systems? Check out our page here for more info and a contact form. Our Account Team will be in touch!

Got new insights or feedback on these architecture considerations? Comment Below!

Or check out our page about VDI-as-a-Service for more information: www.info.vsystems.com/vdi-as-a-service