Share this post

March 10, 2014

Best Practices: Atlantis ILIO and Citrix MCS (Machine Creation Services)

Andrew Wood - Atlantis

Avatar

Citrix Machine Creation Services (MCS) is one of several options open to Citrix XenDesktop admins for image delivery of virtual desktops and application services. It uses the hypervisor APIs (XenServer, Hyper-V, and vSphere) to create, start, stop, and delete virtual machines. While Citrix Provisioning Services (PVS) continues to be a popular choice for image deployment, it is considered a complex solution so many organisations may look to simplify their virtual desktop architecture and implement MCS instead. This is especially true of smaller organisations or environments. Citrix designed MCS to provide many of the benefits of PVS at a lower management cost.

As with Citrix Provisioning Services, Machine Creation Services is used not only to manage the desktop images, but also to reduce the storage capacity requirements of a virtualised XenDesktop or XenApp (7.x) infrastructure. Atlantis ILIO is often used with Citrix MCS to improve performance and further reduce storage requirements.

What are the common questions and best practices for delivering an optimised XenDesktop/App Edition environment when using Atlantis ILIO and Citrix MCS?

 

Citrix Machine Creation Services  (MCS) – A Summary

Citrix MCS uses a master image within your environment to manage virtual machines, enabling you to manage and update target devices through one master image. Machine Creation Services is fully integrated and administered in Citrix Studio: MCS does not require a dedicated database or infrastructure.

However, the options to use virtual machines and Machine Creation Services are disabled if you do not have access to, or have not configured a hosting infrastructure (i.e. connection to a hypervisor). As has been mentioned, Citrix MCS can be integrated with your hypervisor APIs (Citrix XenServer, Microsoft Hyper-V and VMware vSphere) to manage virtual machines. MCS also has a collection of services including AD Identity Service (for managing computer accounts in AD), Provisioning Service, and the Machine Identity Service.

Citrix MCS supports the following deployment types for desktops:

  • Pooled-Random: Desktops are assigned randomly. When they logoff, the desktop is free for another user. When rebooted, any changes made are destroyed.
  • Pooled-Static: Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless of whether the desktop is rebooted. During reboots, any changes made are destroyed.
  • Dedicated: Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless of whether the desktop is rebooted. During reboots, any changes made will persist across subsequent startup

With XenDesktop 7, MCS now supports Windows Server OS (2008 R2, 2012 and 2012 R2), so a single image delivery approach can be taken across your entire virtual desktop infrastructure.

You can find more out about Citrix MCS from Citrix’s excellent three part MCS Primer Part OnePart Two and Part Three.

 

Citrix MCS – Laying the Foundation for a Successful Configuration

The simplicity of the Citrix MCS service setup often leads to interesting questions on how the single image management process works. Understanding the single image management process is key to using Citrix MCS successfully.

As always, I’d recommend you review the very useful Citrix best practice documentation on MCS deployment namely:

  • XenDesktop Planning Guide Storage Best Practices while not a comprehensive planning guide, this document provides a list of best practices, recommendations and performance related tips that cover the most critical areas of storage integration with Citrix XenDesktop.
  • Citrix recommends NFS as the preferred protocol for XenDesktop with MCS – while you can use Fibre Channel, of iSCSI as detailed in Citrix recommends NFS for XenDesktop…huh?. NFS is very simple/easy to manage and supports thin-provisioning by default – key in ensuring that storage requirements are minimised.
  • PVS vs MCS – Revisited, based on testing from Atlantis Computing’s Jim Moyle information debunking the belief that MCS has 60% more IOPS demand compared to PVS.
  • And, as already mentioned there’s an excellent three part MCS Primer
    • Part One –  Machine Types supported by MCS and Image Deployment
    • Part Two –  Intro to image management
    • Part Three – Automation and scripting with MCS

I’d also recommend reviewing Citrix KB articles as a first port of call – they tend to be revised more frequently. Then blogs.. obviously. Blogs, as we’ve established, are cool.

 

Citrix MCS – Where Images Are Stored

Reuse and recycle they say, so I’m going to reuse a useful diagram from Eric Sarakaitis’s Citrix XenDesktop Machine Creation Services Deep-Dive which summarises the deployment process of MCS images to each and every storage volume:

Overview of Image Deployment in XenDesktop

For MCS, the process of image delivery is as follows:

Rollout 1) The Admin creates a VM and installs required software on it. This is the Gold Image.

Rollout 2) A snapshot is taken of the VM. The admin can do this manually, or if you select the image from with Citrix Studio, a snapshot is automatically taken. It is recommended to manually perform the snapshot so you can usefully name it.

Rollout 3) The snapshot is supplied to Citrix MCS, which flattens any delta disk hierarchy and takes a full copy of the VM disk data which is sent to each storage location. Once this is complete the snapshot taken in Rollout 2 is not actively used by XenDesktop/XenAppYou could delete it if desired (all be it you then couldn’t roll back to that particular version).

Rollout 4) VMs are created. Each are given a disk which is their delta/differencing disk which will hold unique writes,  plus an identity disk disk. The size of the identity disk is @16MB. The differencing disk can grow as large as the Gold Image size but will be thin provisioned.

As mentioned, it is possible to configure a XenDesktop storage resource to span multiple storage locations. For example:

 

Assigning multiple storage locations to a host in XenDesktop

 

This can make deployment less time consuming. However, if one of the storage volumes in that resource is offline you will be unable to deploy new images to that entire resource. In addition – by sharing storage volumes it is more difficult to determine which machines to put into maintenance mode should that storage volume require maintenance.

If you create separate machine catalogs mapped to storage resources you have a greater flexibility of management of VMs: albeit with additional work in the Citrix Studio GUI. This is a great opportunity to learn PowerShell by automating the process instead.

 

Citrix MCS – Image Deployment and Management

The administrator must first create a master image to be used as a template for the virtual desktops. This is typically done on storage separate to the datastore where the MCS managed virtual desktops will ultimately reside.

When MCS creates the managed VMs, it coalesces the snapshot you have chosen into a single image and  makes a copy of that master image on the target volume as the base for all other VMs on that volume. This is important to note – the storage volume used for the MCS managed desktop must be sized to handle the initial copy of the base image (or perhaps multiple base images) plus the provisioned virtual desktops.

After MCS copies the base image to all the volumes the next step is to create the files needed for the VMs. Each VM has a differencing and identity (ID) disk. The differencing disk is used to capture changes as the VMs are used and will vary in size (up to a maximum size of the base master template image). As the name implies, the ID disk holds the identity settings specific to the VM.  Each ID disk takes up approximately 16MB of space. It is a recommended best practice to monitor your MCS storage volume as differencing disk growth can cause the storage volume usage to increase. Regularly reboot your MCS images or use Microsoft sdelete as a scheduled task within the image to reclaim NTFS free space and minimise storage requirements.

With MCS, the master image is read-only: so it could be said it would make an ideal candidate for SSDs. However a VDI workload is write intensive. We’ve found IO for desktop VM is typically 80% small block writes, which is a common finding. As MCS master images can only be stored on the same storage location as the difference disks, this makes MCS a frightful candidate for SSDs.

An advantage of hosting your MCS volumes on Atlantis ILIO is that Atlantis ILIO’s storage optimisation can not only reduce the storage requirements through in-line deduplication, but it can also reduce the write operations passed onto physical storage through IO offload of duplication data blocks. Indeed, when hosting MCS volumes in-memory with Atlantis ILIO Diskless, users can experience great performance by using RAM as a primary storage tier.

When considering sizing for MCS deployment bear in mind that each image will need to be stored on every storage volume. Also consider that when a new image is updated there will be at least two images deployed on each storage volume – the original and the updated image (the original image is removed when it is no longer referenced). This may impact sizing and capacity.

For image update, the process is as follows:

Update 1) Admin updates the Gold Image VM  (e.g. service pack, new software, etc.)

Update 2) A new snapshot is taken (as with rollout, the recommendation would be to manually create the snapshot to give it an explicit name)

Update 3) The Gold Image snapshot hierarchy is flattened to get a new base disk. The base disk is copied to each storage location.

Update 4) VMs are updated to reference the new disk (v2) when they next boot.

Update 5) Once all VMs are updated, the old base disk is removed, after a default time period of at least 6 hours.

Studio also has an option to “rollback”. What this action does is select the Snapshot that was previously used, and performs  Update 3 onwards again. It does not use the images already installed.

As the base-disks that MCS uses are full copies of the master disk, they can be quite large. Atlantis ILIO has in-line deduplication which can significantly reduce the storage requirements, although it is good practice to not have redundant base disk references storage volumes as they take up space. Unreferenced base disks will be removed automatically.

To check if VMs are preventing base disks from being removed you can use the Search node in Studio and select the filter option “Pending Updates”: any machines listed in this search are holding old disk images into the system.


Booting them (or rebooting if they are already on) from within Citrix Studio , will apply the update and release the image which will be cleaned up by a background housekeeping task which periodically checks the state of old disks.

The default period for “cleaning” non-referenced base disks is 6 hours. This is configurable in versions of XenDesktop 7.1 and above.  From PowerShell use the Set-ProvServiceConfigurationData cmdlet the set the following values

DiskReaper_retryInterval – defines how often each disk is checked, format is hh:mm:ss.ff, where the seconds (ss) and fractions (ff) are optional. Default is 6 hours.

DiskReaper_heartbeatInterval – defines how often the check process runs to see if there is any pending work, in the same format, this will be constrained to be at most 1/5 of the retry interval so that there are at least 5 checks performed within the larger time space (it also cannot be 0). Default is 1 hour.

The default behavior is that a background process runs every hour and checks if there are any disks that haven’t been checked for more than 6 hours. If there are then those disks are checked to see if it is safe to remove them (i.e. all VMs that were previously using the disk have now been updated to use a newer disk). If there are no VMs remaining for a given disk it will be deleted.

A good practice would be to reduce the retry interval (e.g. to 2 hours) – this will ensure that the non-referenced disks are removed more quickly.

Citrix Intellicache

IntelliCache is a Citrix XenServer technology that was developed to ease the I/O traffic that VDI environments place on shared storage. It is used in conjunction with XenDesktop Machine Creation Services. With the advent of XenServer 5.6 SP2 and XenDesktop 5 SP1, IntelliCache became a configurable and supported feature for the Citrix VDI stack. There is a more complete explanation of IntelliCache in this Citrix blog article: XenDesktop and local storage + IntelliCache.

IntelliCache is designed to use the local storage of the server transparently to offload IO. With IntelliCache the write caches will be stored onto local storage. As a result the shared storage is touched only during the initial read of the base image to get the cached data.

However, a limitation that results from using pooled desktops and IntelliCache is that it is not possible to perform live migration (XenMotion) for your VMs. This means VMs must be powered down for routine maintenance.

When using storage resource hosted on ILIO ensure that the ‘Use Intellicache to reduce load on the shared storage device’ is unchecked (i.e. IntelliCache is disabled) – this allows you to XenMotion VMs if required.

You may of course, not be using XenServer. While it is possible VMware’s Content Based Read Cache work for MCS it isn’t officially supported yet .

With all platforms Atlantis ILIO allows you to utilise the host CPU and memory to drive great performance for users by optimising storage not only for reads, but for writes.

Citrix MCS with Atlantis ILIO – Optimizing Performance and Scalability

With a PVS service, you have the option of having the write cache file running in memory of the target virtual desktop. Citrix MCS does not natively support using RAM as a storage tier. However, with Atlantis ILIO it is possible to use host all VDI workload that is managed and delivered using MCS on an NFS (or iSCSI) storage volume, in RAM.

To drive performance, it is best practice to use Atlantis ILIO to optimise the storage of the VMs. Atlantis ILIO appliances are validated to support both XenApp and XenDesktop workloads in either Pooled/Non-Persistent mode or Persistent mode.

Citrix MCS with Atlantis ILIO – Stateless/Non-Persistent Desktops

For deployments with MCS where the workload is typically considered as Non-Persistent our Atlantis ILIO Diskless architecture would be recommended when deploying Atlantis ILIO. For example, if you are considering selecting the desktop experience options as shown in the diagrams below: 

  Atlantis ILIO Diskless recommended for Stateless desktops


What happens when you want to deploy stateless XenApp workloads with Citrix MCS (as available in XenApp 7.x, or XenDesktop App Edition) and you have Atlantis ILIO? Atlantis ILIO for XenApp Standard Edition can be used here to drive the performance of those multi-user workloads.

 

Citrix MCS with Atlantis ILIO – Persistent Desktops

For deployments with MCS where the workload is typically considered as Persistent and you have Atlantis ILIO, our Atlantis ILIO Diskbacked architecture would be recommended. For example, if you are considering the following options within Citrix MCS you have a persistent desktop environment:

  Atlantis ILIO Persistent recommended for Persistent workloads


MCS does allow you to separate Personal vDisk storage from VM storage. It is recommended that the Personal vDisk storage is held on persistent storage. While it is possible to split the storage between in memory and persistent, it is generally recommend for performance and capacity that Atlantis ILIO Persistent be used.

Selecting the storage location for Citrix Personal vDisk

If using persistent desktops without Personal vDisks, bear in mind you will need tools to manage the image once it is deployed, Citrix MCS can not be used to dynamically change static desktop images once they are deployed.  Also consider when using Personal  vDisks and updating the base image that this is a complex process with a large amount of Processing and IO which can put additional demands on your VM hosts.

Again, what is recommended when you decide you want to deploy persistent XenApp workloads with MCS? Atlantis ILIO for XenApp Enterprise Edition should be used to drive the performance of those multi-user workloads and reducing the demand on your shared storage.

It is not a supported configuration to host the XenDesktop Controller services or databases on Atlantis ILIO. Delivering optimised performance for infrastructure server workloads is the goal of our recently released Atlantis ILIO USX product.

 

Citrix MCS with Atlantis ILIO – Optimised Performance

While it is common to find that as user load increases, user experience degrades. By hosting MCS images on Atlantis ILIO optimised storage, you can not only reduce the capacity required for the MCS images, but provide a great user experience and consistent level of performance.

Atlantis ILIO provides for great performance. Citrix MCS does not offer an In-RAM option for storage, MCS also does not have the ability itself to offload reads or hold the image centrally as PVS does.  This means that when using traditional storage, it will take the full weight of the VDI I/O workload. With Atlantis ILIO Diskless you can have the performance that storage in RAM provides and and still provide great storage capacity.

To lower physical infrastructure costs, guarantee great user experience and reduce the storage and IOPS demand on shared storage associated with MCS deployments, consider implementing Atlantis ILIO Diskless for your MCS stateless storage and Atlantis ILIO Persistent for your persistent desktops.

12345
Current rating: 4.3 (6 ratings)