Category: Testing

Citrix Workspace Environment Management – Memory Management

After testing out the excellent CPU management features in Citrix Workspace Environment Management (WEM), I wanted to test out how well it handled applications that were particularly greedy with RAM consumption.

To start – I have a single Windows Server 2012R2 Session Host, with 4GB of RAM, and a single vCPU, running on vSphere:

wem1

Limitations for this VM have been individually configured as follows:

RAM:

wem2

CPU:

wem3

I wanted to use limitations to give a performance baseline. Although this is much lower than most Session Hosts would likely be – it will prove the concept for this test.

Next I configured the Session Host with the WEM Agent and imported the default baselines as per Citrix documentation. Within the Console, we can then see the Memory Management options:

wem4

According to the Administration Guide, this enables the following:

wem5

For the purposes of this test, I am going to set the idle limit time to 5 minutes. I will be using TestLimit, a command line tool to simulate high memory usage, available here:

https://blogs.msdn.microsoft.com/vijaysk/2012/10/26/tools-to-simulate-cpu-memory-disk-load/

I’ve configured a batch file that will start TestLimit64.exe, and consume 3.5GB of RAM (from a total of 4GB assigned to the session host).

Prior to any WEM configuration being applied, running this batch file causes Memory Usage to rise as expected:

wem6

This remains until the process is closed manually.

Next, I ran the same process but for a user logged on with active WEM Settings – including Memory Management. Initially we saw the same rise in memory:

wem7

I then waited 5 minutes (the time limit we set earlier), with the application running in the background, and then checked the stats again:

wem8

As you can see the excess memory consumed by this application has been released – and is now available to other processes running on the Session Host. I tested this multiple times on different machines and session hosts, and saw the same result each time.

This potentially very useful for situations where a single user may be using a program that runs periodically, but sits with high RAM consumption in the background. Releasing under-utilized RAM will improve the session experience in the event that RAM capacity is being reached.

 

 

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.