Access Your Desktop From Anywhere, on any Device With Virtual Desktop Infrastructure
As businesses respond to our increasingly BYOD (bring your own device) and work-from-anywhere world, many are turning to DaaS (desktops as a service) offerings or solutions. VMware’s Horizon DaaS platform can help you launch a VDI (virtual desktop infrastructure) rapidly and securely.
In this article, our IT professionals discuss essential issues that you’ll need to consider when implementing Horizon DaaS platform’s cloud-first architecture.
Why We’re Fans of Horizon Virtual Desktops
When VMware created its desktop as a service offering, it built a cloud-first solution that is scalable, efficient, and secure. With Horizon, your team can access their desktops from anywhere in the world, on any device, whether it’s a thin client, PC, Mac, smartphone, Chromebook, or tablet. It also supports a wide range of operating systems, including Microsoft Windows and Linux.
Other features include:
- Multi-tenancy: all tenants receive a dedicated VLAN, Filer, access portal, and access gateway.
- Role separation: because Horizon supports full role separation for service providers, IT, and end users, you’ll enjoy an exceptional management or end-user experience.
- Multiple datacenters: go beyond scaling within a single datacenter. With Horizon DaaS, you can scale across multiple datacenters, ensuring business continuity, no matter where your users are located.
When you work with Virtual Systems, we’ll manage and monitor your DaaS backend, while you and your team enjoy the user-friendly Horizon interface’s functionality and power. Even better, you might not have to buy additional hardware to take advantage of the Horizon DaaS platform, streamlining your implementation—and making it more cost-effective.
RELATED: VDI and the Digital Workspace
Preliminary Architecture Considerations With the Horizon DaaS Platform
VMWare Horizon offers two Pool Types, two User Assignment Options, and two Desktop Provisioning Methods. So, Horizon users have eight 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.
The Basic Architecture of Horizon DaaS
Traditional VDI architecture requires a pod of ten 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 and passes 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 suggests the hybrid cloud model could introduce unnecessary lag to the user experience but improvements to VMWare’s VDI architecture 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 and 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 and 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 and 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, and Flash.
However, in addition to this, you may find a department which this standard stack suffices but a couple of users that also require another third-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 two users in the desktop pool. This saves having to clone the master image, install the two applications and manage two 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 needed to update/manage desktop – Altiris, SCCM)
RELATED: VDI Is Your Next Play for Desktop Disaster Recovery and Business Continuity
Want to Learn More About the VMware Horizon DaaS Platform?
The options you’ll find in VMware Horizon DaaS 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!
You can also check out our VDI-as-a-Service page for more information.
Leave a Reply