11 min read

(For more resources related to this topic, see here.)

Virtual desktops can reside in two locations:

  • Hosted at the data center: In this case, you host the desktop/application at the data center and provide users with these desktops through different types of technologies (remote desktop client and Citrix ReceiverXenDesktop).

  • Hosted at the client-side machine: In this case, users access the virtual desktop or application through a VM that is loaded at the client side through different types of client-side virtualizations (level 1, level 2, or streaming).

Hosted desktops can be provided using:

  • VM or physical PC : In this type, users are accessing the desktop on an OS that is installed to a dedicated VM or physical machine. You typically install the OS to the VM and clone the VM using hypervisor or storage cloning technology, or install the OS to a physical machine using automatic installation technology, enabling users to access the desktop. The problem with this method is that storage consumption is very high since you will have to load the VM/PC with the OS. Additionally, adding/removing/managing the infrastructure is sometimes complex and time consuming.

  • Streamed OS to VM or physical PC : This type is the same as the VM or physical PC type; however, an OS is not installed on the VM or the physical machine but rather streamed to them. Machines (virtual or physical) will boot from the network, and load the required virtual hosted desktop (VHD) over the network and boot from the VHD again. It has a lot of benefits, including simplicity and storage optimization since an OS is not installed. A single VHD can support thousands of users.

  • Hosted shared desktop : In this model, you provide users with access to a desktop that is hosted on the server and published to users. This method is implemented with Microsoft Terminal Services and XenApp plus Terminal services. This provides high scalability in terms of the number of users per server scale but provides limited security and limited environment isolation for the user.

Now that we have visited the different types of DV and how they are delivered and located, let’s see what the pros and cons are of each type:

Virtualization Type

Pros

Cons

Usage

Hosted PC – not streamed

PCs are located at the DC, allowing better control.

Can be used in a consolidation scenario along with refurbished PCs.

Superior performance, since a physical HW provides HW resources to the OS and the OS is preinstalled.

Management/deployment is difficult, especially in large-scale deployment scenarios.

Operating system deployment and maintenance is an overwhelming process.

Low storage optimization and utilization since each OS is preinstalled.

High electricity consumption since all of those PCs (normal or blade) are consuming electricity and HVAC resources.

Requires users to be connected to the DC if they wish to access the VD.

Suitable for refurbished PCs and reusing old PCs.

Suitable for task workers, call center agents, and individuals with similar workloads.

Hosted VM – not streamed

VMs are located at the DC, allowing better control.

Superior performance since the OS is preinstalled, but performance is less than what is provided with physical PCs.

High consolidation scenario using server virtualization; it provides green IT for your DC.

Management/deployment is difficult, especially in large-scale deployment scenarios.

Low storage optimization and utilization since each OS is preinstalled, thus requiring a storage side optimization/de-duplication technique that might add costs for some vendors.

Hypervisor management could add a costs for some vendors.

Requires users to be connected to the DC if they wish to access the VD.

Suitable for task workers and call center agents.

Some organizations use this model to give users access to server-level hardware resources such as rendering and CAD software.

Hosted PC – streamed

PCs are located at the DC, allowing better control.

Can be used in a consolidation scenario along with refurbished PCs.

Superior performance since a physical HW provides HW resources to the OS.

High storage optimization and utilization since each OS is streamed on demand.

Deployment is difficult, especially in large-scale deployment scenarios.

High electricity consumption since all of those PCs (normal or blade) are consuming electricity and HVAC resources.

Requires high storage performance to provide write cache storage for the OS.

Requires the deployment of a streaming technology provider within the architecture.

PCs must be connected to streaming servers over the network to stream the OS’s VHD.

Requires users to be connected to the DC if they wish to access the VD.

Suitable for task workers and call center agents.

Some organizations use this model to give users access to server-level hardware resources such as rendering and CAD software.

Hosted VMs – Streamed

VMs are located at the DC, allowing better control.

Superior performance, but performance less than what is provided with physical PCs.

High consolidation scenario using of server virtualization; it provides green IT for your DC.

High storage optimization and utilization since each OS is streamed on demand.

Requires high storage performance to provide write cache storage for the OS.

Requires the deployment of a streaming technology provider within the architecture.

Hyper-v management could add some costs for some vendors.

VMs must be connected to streaming servers over the network to stream the OS’s VHD.

Requires users to be connected to the DC if they wish to access the VD.

Hosted for users who need hosted environment but do not need powerful resources and isolated environment that is not shared between them.

Hosted shared desktops

Desktop is located in the DC, allowing better control.

High capacity for server/user ratio.

Server consolidation can be achieved by hosting server on top of hypervisor technology.

Easy to manage, deploy, and administrate.

Different types of users will require different types of applications, HW resources, and security, which cannot be fully achieved in HSD mode.

Resource isolation for users cannot be fully achieved as in other models.

Customization for the OS, application, and for profile management could be a little tricky.

Requires users to be connected to the DC if they wish to access the VD.

Suitable for most VDs, task workers, call center agents, and PC users.

Level 1 client hypervisors

Since VMs are hosted on the clients, the load is offloaded from the DC and less HW investments are required.

Users can use their VD without being connected to the network.

Client HW can be utilized, including graphic cards and sound devices.

VD are not located on the DC, thus could be less secure for some organizations.

Might not fit with organizations that allow users to use their own personal computers.

Could require some HW investments at the client HW side to allow adequate performance.

The client is connected to a central storage for the purpose of backing up the company’s data.

This type might fit into smaller environments, but for larger environments, management could be hard or even impossible.

Suitable for mobile users and power users who are not connected to the data center at all times.

Level 2 client hypervisors

Since VMs are hosted on the clients, the load is offloaded from the DC and less HW investments are required.

Users can use their VD without being connected to the network.

Client HW can be utilized, including graphic cards and sound devices.

Allows the users to mix the usage of virtual and physical desktops.

VD are not located on the DC, thus could be less secure for some organizations.

Might not fit with organizations that allows users to use their own personal computers.

Could require some HW investments at the client HW side to allow adequate performance.

The client is connected to a central storage for the purpose of backing up the company’s data backup.

This type might fit into smaller environments, but for larger environments, management could be hard or even impossible.

Suitable for mobile users and power users who are not connected to the data center at all times.

XenDesktop components

Now that we have reviewed the DV delivery methods, let us see the components that are used by XenDesktop to build the DV infrastructure.

The XenDesktop infrastructure can be divided into two major blocks the delivery block and the virtualization block, as shown in the next two sections.

Delivery block

This section is responsible for the VD delivery part, including authenticating users, remote access, redirecting users to the correct servers, and so on. This part consists of the following servers:

The Desktop Delivery Controller

  • Description : The Desktop Delivery Controller (DDC) is the core service within the XenDesktop deployment. Think of it as the glue that holds everything together within the XenDesktop infrastructure. It is responsible for authenticating the user, managing the user’s connections, and redirecting the user to the assigned VD.

  • Workload type: The DDC handles an HTTP/HTTPS connection sent from the web interface services to its XML service, passing the user’s credentials and querying for the user’s assigned VD.

  • High availability: This is achieved by introducing extra DDCs in the infrastructure within the farm. To achieve high availability and load balancing between them, these DDCs will be configured in the web interface that will be loaded to balance them.

Web interface (WI)

  • Description : The web interface is a very critical part of the XenDesktop infrastructure. The web interface has three very important tasks to handle within the XenDesktop infrastructure. They are as follows:

    1. It receives the user credentials either explicitly, by a pass-through, or by other means

    2. It passes the credentials to the DDC

    3. It passes the list of assigned VDs to the user after communicating with the DDC XML service

    4. It passes the connection information to the client inside the ica file so the client can establish the connection

  • Workload type: The WI receives an HTTP/HTTPS connection from users initiating connections to the XenDesktop farm either internally and externally.

  • High availability: This is achieved by installing multiple WI servers and load balancing the traffic between the WI servers, using either Windows NLB or other external hardware load balancer devices, such as Citrix NetScaler.

Licensing server

  • Description : The licensing server is the one responsible for supplying the DDC with the required license when the virtual desktop agent tries to acquire one from the DDC.

  • Workload type: When you install the DDC, a license server is required to be configured to provide the licenses to the DDC. When you install the license server, you import the licenses you purchased from Citrix to the licensing server.

  • High availability: This can be achieved in two ways, by either installing a licensing server on Windows Cluster or installing another offline licensing server that could be brought online in the case of the first server failure.

Database server

  • Description : The Database server is responsible for holding the static and dynamic data as configuration and session information. XenDesktop 5 no longer uses the IMA data store as the central database in which the con figuration information is stored. Instead, a Microsoft SQL Server database is used as the data store for both configuration and session information.

  • Workload type: The database server receives the DB connections from DDC and provisioning servers (PVS), querying for farm/site configuration.

    It is important to note that the XenDesktop creates a DB that is different from a provisioning services farm database; both databases could be located on the same servers, same instance or different instances, or different servers.

  • High availability: This can be achieved by using SQL clustering plus Microsoft Windows or SQL replication.

Virtualization block

The virtualization block provides the VD service to the users through the delivery block; I often see that the virtualization block is referenced as a hypervisor stack, but as you saw previously, this can be done using blade PCs or PCs located in the DC, so don’t miss that.

The virtualization block consists of:

Desktop hosting infrastructure

  • Description : This is the infrastructure that hosts the virtual desktop that is accessed by users. This could be either a virtual machine infrastructure, which could be XenServer, Hyper-v, or VMware VSPHERE ESXI servers, or a physical machine infrastructure, for either regular PCs or blade ones.

  • Workload type: Hosts OSs that will provide the desktops to users that are accessing them from the delivery network. The OS could be running as either installed or streamed and can be either physical or virtual.

  • High availability: Depends on the type of DHI used but can be developed by using clustering for hypervisors or adding extra HW in the case of the physical ones.

Provisioning servers infrastructure

  • Description : The provisioning servers are usually coupled with the XenDesktop deployment. Most of the organizations I worked with never deployed preinstalled OSs to VMs or physical machines, but rather streamed the OSs to physical or virtual machines since they provide huge storage optimization and utilization. Provisioning servers are the servers that actually stream the OS in the form of VHD over the network to the machines requesting the streamed OS.

  • Workload type: Provisioning servers stream the OS as VHD files over the network to the machines, which can be either physical or virtual.

  • High availability: This can be achieved by adding extra PVS servers to the provisioning servers’ farm and configuring them in the DHCP servers or in the bootstrap file.

XenDesktop system requirements

XenDesktop has different components; each has its own requirements. The detailed requirements for these components can be checked and reviewed on the Citrix XenDesktop requirements website: http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-sys-reqs-wrapper-rho.html

Summary

In this article, we saw what the XenDesktop architecture consists of and its various components.

Resources for Article :

Further resources on this subject:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here