Time and time again, IT departments have turned to OpenStack for controlling large pools of compute, storage, and networking resources. Have you ever wondered how the opensource powerhouse can be used to build virtual desktop environments or to deploy desktops-as-a-service?
If you’re looking for an alternative to running desktops on dedicated hardware in the data center, open source software may be the name of the game. OpenStack can help mitigate the cost of VDI and is a viable option for hosting desktops. In fact, organizations can improve resource utilization and manage OpenStack VDI/DaaS at scale through a strategic combination of hypervisor, display protocol, and connection broker technologies.
When it comes to leveraging OpenStack clouds to host desktops, there’s a lot to think about and several moving parts. To help you get a better handle on how to execute OpenStack VDI and DaaS, keep reading. In this blog I will cover the basic tools that you need and how they come together.
Which OpenStack Projects come into Play?
The OpenStack software consists of over 10 different projects, each with a focus on a particular aspect of the datacenter. The oldest (and some would argue, most production ready) projects are the items required for DaaS and VDI, and they include the following:
- Nova handles compute. It is the project that ultimately runs your desktops – or servers – if you want to think of them that way. Nova needs to run on somewhere and that somewhere is often a hypervisor, typically KVM.
- Cinder and Swift both handle storage. However, when you’re looking at desktop workloads, Cinder’s block storage is the way to go. Each desktop is a persistent volume that can be attached to a running instance. (Persistent storage is important for desktops. Imagine if your laptop lost all your data every time you rebooted it!)
- The Glance project handles imaging. These are the tools that allow you to create a master image of a customer’s desktop, and then quickly provision new on-demand instances from that image.
- Neutron is a network service for OpenStack. It provides tools that can build per-tenant private networks, which is handy for multi-tenant environments.
- Lastly, Horizon, which is the dashboard project. Horizon provides a UI on top of your OpenStack cloud, where you can create images, instances, networks, and more. Note, that you will not use the Horizon UI to manage VDI or DaaS, you’ll need a connection broker for that. More on connection brokers in the last section of this blog.
Building OpenStack VDI and DaaS in four Steps
At a high level, the process of building out OpenStack VDI/DaaS can be summed up in four steps.
1. Build your OpenStack cloud: First, determine the architecture for your OpenStack cloud. There are a number of very good OpenStack experts, like SUSE, who can help you with this, if you’re not already one of those experts.
2. Create an OpenStack project for each tenant: Then, as you onboard customers, make sure to place each in their own OpenStack project, which means defining the project and the network! If you’re an MSP, you’ll want to chat with your customers in order to enumerate as many use cases or user groups as possible.
3. Build images for each tenant: Next, build a master desktop and image that can be used to provision desktops for those users. After that, it’s time to investigate display protocols.
4. Leverage a connection broker to ease management: The last step is to configure your connection broker to manage the day-to-day.
The Role of a Hypervisor, Display Protocol and Connection Broker
In order to complete the puzzle, you will need to get your hands on a few additional tools: 1) hypervisor, 2) display protocol, and 3) connection broker.
Hypervisor: OpenStack supports a wide range of hypervisors (a program that allows multiple operating systems to share a single hardware host). By and large, most current OpenStack deployments use KVM, which makes sense: open source hypervisor for an open source management stack. KVM is noted in the OpenStack documentation as being the mostly highly tested and supported hypervisor for OpenStack, with commercial hypervisors from the likes of VMware, Citrix, and Microsoft coming in second. But, when it comes to the features you need to successfully manage VDI or DaaS, the feature sets provided by any of the hypervisors are adequate.
Display Protocol: A display protocol provides end users with a graphical interface to view a desktop that resides in the datacenter or cloud. Some of the popular options include Teradici PCoIP, HP RGS, or Microsoft RDP. Choosing a protocol(s) is important and can make or break the end user experience. Complex workloads often require complex visualization and rendering graphics. More importantly, in industries such as semiconductor design or oil-and-gas, one misplaced pixel can cost the enterprise millions of dollars. So, choose wisely! Research your options, but try to use a high performance protocol only when it’s really needed, as they do bring licensing costs into the picture.
Connection Broker: It’s one thing to spin up desktops in your cloud, it’s another to get the user connected to that desktop. That’s the job of a connection broker. The key is to find a broker that handles all your use cases, whether those include Windows or Linux desktops, a mixture of different display protocols, or different types of client devices. Enumerating your brokering needs before you start to build your design will help you choose a broker that future-proofs your deployment. A connection broker focuses on desktop provisioning and connection management. It also provides the interface that your end users will use to log in. When looking at brokers, make sure that the broker supports the OpenStack API.