In this first chapter, we'll start with defining some basic XenDesktop architectures and the different components involved. We'll also visit some terminology and concepts that are important to understand as a baseline before addressing performance. As your XenDesktop sites grow, performance will be impacted, so getting the blueprint right first time is critical. One thing we often say in our business is "measure twice, and cut once". In this chapter, we will cover the following:
Introduction
Architecture
Terminology and concepts
Components
XenDesktop is a desktop virtualization and Virtual Desktop Infrastructure (VDI) solution that delivers a Windows desktop experience as an on-demand service to any user, anytime, anywhere. It suits all types of workers, from task workers or knowledge workers, to mobile workshifting workers. XenDesktop quickly and securely delivers complete desktops or applications while providing a high-definition user experience.
XenDesktop is a desktop virtualization solution that optimizes the delivery of desktops, applications, and data to end users. It includes all the capabilities to deliver desktops, applications, and data securely to every type of user in an enterprise. Instead of managing thousands of static desktop images, you can manage and update the desktop OS and applications once, from one location.
My other book, Getting Started with XenDesktop® 7.x, Packt Publishing, provides comprehensive details on how to design, implement, and maintain a desktop delivery site using XenDesktop. It also includes topics on management, policies, printing, USB support, storage and backup, the High Definition User Experience (HDX), application delivery, the XenDesktop SDK, the Citrix Receiver, and running XenDesktop from the cloud.
If you are reading this book, you have most likely heard of the desktop virtualization concept. You may have done some basic research on the topic or installed a previous version of XenDesktop. If you are a desktop virtualization veteran or new to the game and starting your proof of concept, this book will be helpful. In this book, we will assume you already have a XenDesktop environment or are planning one. We will help you understand the different topics surrounding XenDesktop performance.
Before we get started, you will need to understand what a hypervisor is. A hypervisor is a thin operating system that hosts multiple instances of disparate operating systems. It can also be defined as software that can create and run virtual machines. The hypervisor software runs on server hardware that is enabled for virtualization. Once this is installed, you can install several instances of different operating systems onto the hypervisor. The hypervisor was game-changing, because instead of running one operating system per server, you could now run X number of operating systems on one server, saving space and money.
There are several vendors that make hypervisors, such as Citrix XenServer, VMware ESXi, Microsoft Hyper-V, and the Linux open source Kernel Virtual Machine (KVM). There are two types of hypervisors:
As you can imagine, the Type 1 hypervisors have been touted to have better performance as they interact directly with the server hardware resources.
Citrix XenServer and VMware ESXi are Type 1 hypervisors. Microsoft Hyper-V is presumably a Type 1 hypervisor. There has been debate over whether Hyper-V is a Type 1 or Type 2 hypervisor mainly because you first install the Windows server operating system and then turn on the Hyper-V role, giving the perception that Hyper-V is running on top of or with the help of the Windows Server operating system. Obviously, XenDesktop runs on Citrix XenServer, but it can also run on VMware ESXi and Microsoft Hyper-V.
Note
At the time of this writing, XenDesktop does not run on KVM. You could probably make it work. Citrix does not officially support KVM. Tribal Knowledge says you could run XenDesktop on KVM, but you would not be able to use MCS or PVS automation for creating VMs.
The following diagram gives you a visual idea of the differences between the types of hypervisors compared to traditional servers. It also shows how the interaction between these components contends for hardware resources and ultimately affects performance and sizing of hardware resources:
Before we can start designing the XenDesktop infrastructure, we need to understand the core components that go into building it. XenDesktop can support all types of workers, from task workers that run Microsoft Office applications, to knowledge users that host business applications, to mobile workshifting users, to high-end 3D application users. XenDesktop scales from a small business supporting five to ten users up to large enterprises supporting thousands of users.
In the XenDesktop architecture, there are several sections called layers that are used to group certain functions together. Each layer is comprised of logical groupings of resources to help you better understand the roles each type of component plays.
The following is a simple diagram to illustrate the components that make up the XenDesktop architecture:
Referring to this diagram, you now have a visual representation of how a simple site will look when finished. Let's take a look at each individual component so you understand the role of each one.
The Clients layer contains all the clients. It seems simple, and it is. Citrix Receiver is device-agnostic, so it will run on any device. You name it, and it will be capable of connecting to a XenDesktop.
One of the benefits of XenDesktop is that it creates a light network load for the client connections. However, we call out the Network layer because this is a potential pinch point in large XenDesktop deployments—a place where performance can be degraded or bottlenecked. The network layer is a general term and refers to every piece of the network, from the client device, through the wide area network, the cloud, and into the datacenter where XenDesktop is being hosted.
The Access layer is where you place the NetScaler to frontend your XenDesktop site. You can also place the StoreFront servers here. This layer contains resources that provide a portal for your clients to connect to the XenDesktop site. This layer is similar to DMZ computing in traditional network architectures.
Citrix NetScaler provides a SSL encryption frontend for XenDesktop. It is discussed at length in my companion book, Getting Started with XenDesktop® 7.x, Packt Publishing.
The Control layer contains all the components critical to controlling, managing, monitoring, storing, licensing, and delivering the desktops to the users.
The Services layer contains components that are not Citrix products but are essential to the deployment of the XenDesktop site; for example, the Microsoft Active Directory / Domain Controller, DHCP, and DNS.
The Resources layer contains all the XenDesktop consumable resources such as desktops and applications. All the resources to power desktops and applications live here, including vCPUs, vMem, and storage for vDisks and PvDisks.
We call out the Storage System layer only because storage is increasingly being detached from the servers and could be a pinch point in itself. Conceptually, storage resources could be its own layer.
The Hypervisors layer is not really a layer, but you could refer to it as that. Some abstraction needs to be made regarding the hardware that all this stuff is running on top of. Each layer could conceptually be its own piece of hardware or server with a hypervisor running on top of it, with virtual machines to host XenDesktop components on top of that.
In this section, we will cover some commonly used terminology and concepts used with XenDesktop.
Most physical servers designed to be used with a hypervisor include physical CPUs that are capable of hyperthreading. Hyperthreading allows a CPU to be used by more than one process or task at a time. Hyperthreading allows multiple threads to run on each processor core. Simple math would indicate that hyperthreading effectively doubles the CPU count. However, Tribal Knowledge says the extra amount of performance varies, and it is more like a 1.5:1 ratio providing a 20 to 30 percent performance improvement, and not 2:1 with 100 percent performance improvement. A virtual CPU (vCPU) or multiple vCPUs are assigned to VMs. Hyperthreading doubles the number of available vCPUs that can be assigned with the caveat mentioned in the preceding section.
It is important to understand terminology and concepts as they apply to the server side of the XenDesktop architecture. The server side refers to any term, concept, or component to the right of the network cloud.
The client side refers to any term, concept, or component to the left of the network cloud. To have a complete end-to-end solution, you need to consider an important part of the architecture—the end user device or client. There isn't much to consider here; however, the client devices can range from high-powered Windows desktops to low-end thin clients or mobile devices. There is a software component called Citrix Receiver that is necessary to complete the connection to XenDesktop that runs on the client hardware.
A virtual machine is a software-implemented version of the hardware. For example, Windows Server 2012 R2 can be installed as a virtual machine running in XenServer, VMware ESX, and Hyper-V. In fact, every server and desktop in this book's examples can be installed as a VM with the exception of the hypervisor itself, which obviously needs to be installed on the server hardware before we can install any VMs.
Note
Technically, you could run a hypervisor inside another hypervisor, known as a nested hypervisor, but there is no reason to do this as the performance would not be good.
Server VMs are based on a Windows Server operating system used for delivering applications or hosted desktops to users.
Desktops VMs are based on the Windows desktop operating system used for delivering personalized desktops to users or for delivering applications from desktop operating systems.
Citrix XenApp is an on-demand application delivery solution that enables any Windows application to be virtualized, centralized, and managed in the datacenter and instantly delivered as a service. Prior to XenDesktop 7.x, XenApp delivered applications, server-based and hosted shared desktops (server desktops), and XenDesktop delivered only Windows desktops. Now, with the release of XenDesktop 7.x, it delivers both desktops and applications. XenApp as a standalone product is still available.
Citrix EdgeSight is a performance and availability management solution for XenDesktop, XenApp, and endpoint systems. EdgeSight monitors applications, devices, sessions, license usage, and the network in real time. EdgeSight will be phased out as a product, and its functionality will be incorporated into Citrix Director and the HDX Insight Appliance.
Don't let the term "FlexCast" confuse you. FlexCast is a term designed to encompass all of the different architectures in which XenDesktop can be deployed. FlexCast allows you to deliver virtual desktops and applications according to the needs of diverse performance, security, and flexibility requirements of every type of user in your organization. FlexCast is a way of describing the different ways to deploy XenDesktop. For example, task workers using low-end thin clients at remote offices will use a different FlexCast model than, say, a group of HDX 3D high-end graphics users. The following are the FlexCast models you may want to consider:
The resource layers in the architecture are a way to group resources according to general functionality. Within each resource layer are specific XenDesktop components. Each component has a function and plays a role in the XenDesktop infrastructure. These components and their roles are discussed in the following section.
Citrix Receiver is a universal software client that provides secure, high-performance delivery of virtual desktops and applications to any device anywhere. Citrix Receiver is platform-agnostic, meaning that there is a receiver for just about every device out there, from Windows- to Linux-based thin clients to mobile devices including iOS and Android. In fact, some thin client vendors have performed close integration with the Citrix Ready program to embed the Citrix Receiver code directly into their homegrown operating system for seamless operation with XenDesktop.
Citrix Receiver must be installed on the end user client device in order to receive the desktop and applications from XenDesktop. It must also be installed on the virtual desktop in order to receive applications from the application servers (XenApp or XenDesktop), and this is taken care of for you automatically when installing the VDA on the virtual desktop machine.
Citrix Receiver provides users with self-service access to resources published on XenDesktop or XenApp servers. This software combines ease of deployment and uses and offers quick, secure access to hosted applications, desktops, and data.
A hypervisor is a thin operating system that hosts multiple instances of other operating systems. This concept of one hosting many is the fulcrum of the value of virtualization. XenDesktop is supported on three hypervisors—Citrix XenServer, VMware ESXi, and Microsoft Hyper-V.
Citrix NetScaler provides the frontend to XenDesktop resources. NetScaler is primarily an Application Delivery Controller (ADC) that can also perform load balancing. Its primary purpose for XenDesktop, however, is to provide the security for all communications using Secure Sockets Layer (SSL). Think of it this way: for those organizations that want to secure their communications, traffic comes into the NetScaler using encrypted SSL. You can choose not to use SSL, but it is not recommended.
Citrix StoreFront is the portal that authenticates users to site(s) hosting XenDesktop resources and manages stores of desktops and applications that users access. Active Directory does the actual authentication and interacts with StoreFront.
The Citrix Delivery Controller brokers access to desktops and applications and manages user access. Each site has one or more Delivery Controllers.
Citrix Studio is the management console that enables you to configure and manage your XenDesktop and XenApp deployment, eliminating the need for two separate management consoles for managing the delivery of desktops and applications.
Note
If you use provisioning services, also included in XenDesktop, then you need to use the provisioning server console to deploy the VMs on the hosting platform.
Studio provides various wizards to guide you through the process of setting up your environment, creating your workloads to host and assign applications and desktops, and assigning applications and desktops to users.
The Citrix License Server serves licenses. Every Citrix product and every XenDesktop user requires a Citrix license. Studio consults the License Server to check out and check in licenses.
The only exception is NetScaler, which is licensed from within NetScaler itself.
In XenDesktop, we use Microsoft SQL Server. The database is sometimes referred to as the data store. Almost everything in XenDesktop is database driven and the SQL database holds all state information, in addition to session and configuration information.
If the database server fails, existing connections to virtual desktops will continue to function until the user either logs off or disconnects from their virtual desktop. In XenDesktop version 7.6, Citrix introduced the Connection Leasing feature, which allows new connections to occur even if the database is unavailable. Citrix recommends you to implement SQL mirroring and clustering for high availability.
Microsoft Active Directory is required for authentication and authorization. Active Directory can also be used for controller discovery by desktops to discover the controllers within a site. Desktops determine which controllers are available by referring to information that controllers publish in Active Directory.
Note
If you don't want to use Active Directory for authentication, you can create an anonymous store in StoreFront and use local authentication.
Active Directory's built-in security infrastructure is used by desktops to verify that communications between controllers come from authorized controllers on the appropriate site. Active Directory's security infrastructure also ensures that the data exchanged by desktops and controllers is confidential.
Every machine in this architecture—virtual or physical, client, desktop, or server—requires an IP address. XenDesktop uses the Microsoft DHCP service to centrally manage IP addresses.
Every machine and service in XenDesktop needs a way to convert Fully Qualified Domain Names (FQDNs) into IP addresses so they can send packets out on the network and reach their destination. XenDesktop uses the Microsoft DNS service to do this.
A desktop is the instantiation of a complete Windows operating system, typically Windows XP, 7, or 8. In XenDesktop, we create the desktop VM and add the VDA to it so that it can work with XenDesktop and be delivered to clients. This will become the end user's virtual desktop.
A server is a virtual machine dedicated to performing one or more specific tasks on the XenDesktop site, for example, brokering connections (Delivery Controller). These virtual machines can be used to host applications. More importantly, these servers are used to host the important XenDesktop components such as StoreFront, Delivery Controller, Studio, Director, License Server, SQL Server, Active Directory, DHCP, and DNS.
All the XenDesktop components use storage. There are two types of storage in this architecture. First, there is SQL Server, which is used as the database for the XenDesktop components. Then, there are Virtual Disks (vDisks) and Personal Virtual Disks (PvDisks).
In a dedicated model, each user gets their own vDisk, which hosts the desktop OS. As you can imagine, the storage requirements for a dedicated vDisk model can grow quite substantially. In a pooled/shared model, several users share the same vDisk. There are other types of vDisk deployment models. The different types of vDisks are explained in the following table:
The concept of the PvDisk is powerful for the users. PvDisk provides a personalization feature for storing personal data from virtual desktops. Each user gets their own Personal vDisk that stores their user profile, data, and applications that are unique to them. They are smaller than OS vDisks. They allow you to scale by pooling and sharing vDisks among many users and giving them each their own smaller Personal vDisk. PvDisks are merged with vDisks at runtime—the appearance to the end user is seamless.
The Virtual Desktop Agent (VDA) has to be installed on the virtual machine to which users will be connecting. It enables the machines to register with controllers and manages the connection between the machines and the user devices. The VDA is installed on the operating system VM, such as Windows XP, 7, or 8, which gets served to the client. The VDA maintains a heartbeat with the Delivery Controller, updates policies, and registers with the Delivery Controller.
You now have a good grasp of the logical grouping of XenDesktop components and the terminology used in XenDesktop. This chapter also serves as a good reference to look back on as you move forward.
You now know what a XenDesktop site will look like from the network diagram, components, terminology, and concepts. In the next chapter, we'll look at system requirements for XenDesktop components, compatible hypervisor hosts, and the most important topic of the sizing. Using the sizing techniques and calculations in the next chapter will give you a solid blueprint for your VDI deployment from small to extra large XenDesktop sites.
