Architecture

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.