Tags: Zones

XenDesktop 7.11 – Zones

Introduction

Many XenApp administrators will remember the Zone Preference Failover (ZPF) features available in previous versions. For those unaware, this allows resources to be served from Hosts within a logical group (a Zone), unless a failure/maintenance condition exists, in which case resources are served from a Secondary Zone.

Using Zones we can provide applications from a single Zone, with failover to another Zone in the event of an issue. This is useful for a great many reasons:

  • Automatic failover to a DR site if there are issues with the Primary Zone’s Session Hosts
  • Automatic placement of users into a Zone that is nearest their location – useful for those with geographically disparate environments.
  • Capacity management – we can seamlessly “spill” users across to a secondary zone in the event that the primary zone reaches capacity.

zones00

Zones are configured using the Zones option, under Configuration, within Citrix Studio:

zone03

Lab Environment

For the purposes of this demonstration, I have considered a fictional environment shown below. We have two Geographical sites, linked via a wide area network. We have Active Directory Services across both sites, and a replicated SQL Environment. XenDesktop has been configured as a single site, with two Delivery Controllers, and two Session Hosts.

zone02

Goals

For this demonstration I will show how user preferences can be assigned to resources in a zone, and then seamlessly failed over in the event of a fault or issue.

zone01

Creation of Zones

We begin with two Delivery Controllers configured for this farm – obviously in a production environment we would be working with N+1, so at least two Controllers per Zone.

zones04

We can then create the Zone Configuration – this is done using the Zones pane in Citrix Studio:

zone03

As you can see, the default configuration places all controllers in the Primary Zone (the only zone within the Farm):

zones05

To begin, I will create a secondary zone called “Zone 2” and also rename “Primary” to “Zone 1” – in a production environment these could be physical locations, or different Data Centers. To create a new Zone, click on the “Create Zone” within the Actions pane:

zones06

You will then be presented with a new window which can be name as required. Note – I have selected my Zone 2 Delivery Controller (Z2XD01) to be added to this Zone:

zones07

When the details have been populated and Controllers selected, click on “Save”. The new Zone is then created:

zones08

After this I updated the Primary zone by right clicking on the Zone and selecting “Edit Zone”:

zones09

My Zone configuration is now as follows:

zones10

Machine Catalogue Setup

Next I will create two new machine catalogues, each with a single session host, and assign these machine catalogues to Zone 1 and 2. The creation of these is done as you would any other machine catalogue – except we can now select a zone to add the machines to:

zones11

I’ve created two catalogues now – one for Zone 1 and one for Zone 2:

zones12

Now we will create a single Delivery Group – in this scenario, the Delivery Group spans across the Zones, and contains machines from both Zones:

zones13

Note: Create the Delivery Group with machines from one Zone first, and then add in the machines from the 2nd Machine Catalogue after.

Zone Configuration

Before we can assign users to a Zone, we need two new AD Groups to define the users home Zone:

zones14

Next – we can assign these Groups to Zones within the Console. We do this with the “Add Users to Zone” option:

zones15

Adding a user Group to a Zone:

zones16

Now – we can see the user configuration for each Zone:

zones17

zones18

Testing

To test this setup I created 5 Test User accounts, and added them all to the Users_Zone_1 AD Group. This will mean that when these users launch a session from our Delivery Group, it will be served by Session Hosts in Zone 1 (as we have associated these users to that Zone). I logged all of the users into StoreFront and launched a session – the result was all users launched desktops from Zone 1 Resources:

zones19

Next – I will remove Test User 5 from Zone 1, and place them into a Zone 2 Group. Then I will log them off and back on. The result is shown below – note how a change in the Zone Assignment changes the Session Host used:

zones20

Practical Use – Failover!

Having users log into different Session Hosts based on an AD Group is all well and good – but this is not unique to Zone Configuration. What’s great about the Zoning in XenDesktop is that we can automatically fail over between the zones. In the example below, all 5 Users are assigned, by AD Group, to Zone 1.

But – if there’s an issue with the Session Hosts in Zone 1, perhaps a failure or outage, we don’t want to manually have to fail this over. When setting up the Delivery Group, this option was not selected:

zones21

This means that because both Machine Catalogues (in each Zone) are members of the same Delivery Group (which spans the Zone), we can have user sessions automatically launch in Secondary Zone for the Users. To test this, I placed all Machines in Zone 1 into Maintenance Mode, and then logged on all 5 Test Users. The result – Users are logged onto Machines in Zone 2:

zones22

Essentially, we now have a solution that automatically connects users into their primary resource, based on Zone Assignment, but in the event of an issue with that Zone, connects them into resources in a Secondary Zone.

Obviously there many other elements to consider with a design like this – particularly around the SQL, StoreFront, and NetScaler infrastructure. But for a simple and automatic failover solution – this works really well.