Control, control, you must learn control! – Yoda

The control layer is about creating a single, cohesive foundation for the solution that supports the user-layers (users, access and resources).

091113_1305_Doyouhaveyo1.png

You can NOT do the control layer if you haven’t defined your user layer, access layer and resource layer. The control layer of the XenDesktop 7 blueprint is subdivided into

  1. Access Controllers – responsible for providing the connectivity to the resources as defined by the Access Layer
  2. Desktop Controllers – manage and maintain the virtualized resources for the environment
  3. Infrastructure Controllers – standard infrastructure components

The point of the control layer is to define what and how many servers/devices you need to support the user layers. This is based on the size of the user groups as well as the overall design for those user groups.

The first part of the control layer focuses on the access controllers, which should not be confused with the access layer. The access layer defines the access policies, which are associated with each user group. The access controllers are the devices that allows you to implement those policies. If all of your users are local and you do not require a remote access policy, then there you will not require a NetScaler Gateway access controller.

The second part is on the desktop delivery controllers. The delivery controllers make sure you are assigned to the right resource. They make sure the resource is ready. And they make sure the resources are updated appropriately. With XenDesktop 7, this bucket of controllers was reduced in size. You will no longer see XenApp controllers (zone data collectors) because the “XenApp servers” in XenDesktop 7 utilize the same framework. This means XenDesktop users and XenApp users rely on the same desktop delivery controller!

And finally, the last part of the control layer deals with the other components, the supporting cast of characters which includes database servers, licensing server and hypervisor controller servers (vCenter, SCVMM, XenServer) Note: XenServer doesn’t really have a dedicated controller like vSphere and Hyper-V.

When we update the conceptual architecture to now include our control layer, you get the following:

As you see, almost everything begins with 2 instances so that we have some level of fault tolerance in that if one instance fails, we have a second instance to handle the load. Licensing only has 1 instance because there is a built in 30 day grace period, so who cares if it fails. You got 30 days to get licensing running again before users notice.
Daniel – Lead Architect