Citrix MCS & PVS – Two Avenues of Creation

I usually look at technology as a form of art, which is why in comparing the two available Citrix imaging platforms: Machine Creation Services (MCS) & Provisioning Services (PVS), I thought it would be interesting to compare them to Doodle Sketch & Etch-A-Sketch.

Wouldn’t you agree in saying these are still some really cool toys? Amazingly both can be used to deliver a creation of art, but in different ways.

MCS & PVS are as similar and cool as Doodle Sketch & Etch-A-Sketch, but their utility comes in the form of delivering desktops and applications within a VDI environment. They are also different, as Doodle Sketch & Etch-A-Sketch are, in the methods they use to do this.

Which would you choose?
If you were tasked to create a particular work of art and had to choose from either the Doodle Sketch or the Etch A Sketch to do so, which would you choose?
You would have to first decide what you are going to draw, and then ask yourself some other basic questions:

What shapes are involved?

Where is it going to be displayed?

Who will your audience be?

How much time do you have to create it?

These questions are important for a few reasons. Perhaps the shapes you intend on creating would be easier with one over the other. The artwork could be displayed in an art gallery, or on the wall in a local school. You could have ten minutes to create it, or ten days to develop it. If you can answer these questions and weigh them against the capabilities of both tools, then you can make an intelligent, educated decision. The same goes for MCS & PVS.

A closer look:
Both MCS and PVS deliver RDS & VDI workloads.
Both support pooled and dedicated VDI Desktops.
Both can scale up to thousands of users.
No two works of art can be the same.
PVS requires a dedicated database and infrastructure, while MCS doesn’t.
MCS relies on virtualization to communicate with the hypervisor storage layer APIs (Xen, VMware,) to create, start, stop, and delete. This reliance allows MCS to deploy virtual machines to the cloud (Microsoft Azure and Amazon AWS).
PVS relies on the network, as it streams the master image. Therefore, it is able to deliver the image to virtual and physical machines.
A good user experience in MCS relies on the stability and performance of storage, while PVS is reliant on the stability and performance of the network.
For the longest time it was thought MCS couldn’t scale well. The thought was that MCS generated about 60% more IOPS when compared to PVS, but it was later revealed that MCS actually generates 21.5% more average IOPS compared to PVS in the steady-state. This broke it down to about 8% more write IO and 13% more read IO.
Today, several technologies exist to handle the additional reads. For example, in hypervisors we now have native support for read caching:
VMware has Content Based Read Cache
Hyper-V has Cluster Shared Volumes
XenServer has IntelliCache
Nutanix has it Web-Scale solutions,
and let’s not forget about Windows 2012 R2 system cache, etc.
This leaves us with the write IOPs.
As you may know, PVS is able to capture an image from a master machine, store it as a virtual hard disk (vDisk), and stream it to target devices. In its 7.1 release, a new write cache option (RAM cache with Overflow to Disk) emerged with the ability to utilize target RAM for the cache and overflow to disk when the RAM cache becomes full. This feature was a game changer because it significantly reduced the peak and steady state write costs of VDI.
The concept is simple: leverage memory first and then gracefully spill over to disk.
All writes (mostly random 4K) first hit memory, and then get realigned into 2 MB memory blocks using non-paged pool memory.
The spill over is sent & written to a VHDX file in 2 MB sequential block size, and that’s how you’ll see it grow.
Historically, MCS is able to create virtual machines from a master image snapshot by creating a full copy of the point in time snapshot. It then places the copy on each storage location which is shared across the VMs it creates. Each VM has a unique 16 MB identity disk and a differencing disk that is used to store writes to the VM.
But things certainly have changed.
Within the recent XenApp & XenDesktop 7.9 release:
MCS can now store writes into a write-backed cache disk on hypervisor local storage and utilize a portion of the VMs non-paged pool memory as RAM cache. Therefore, as the VM writes data to disk, the operations are stored within the RAM cache and eventually write the oldest cached data to disk in 2 MB blocks.
PVS now supports Hyper-V generation 2 VMs. This means VMs can now PXE boot without the legacy workarounds. The Boot Device Manager option is now single-stage vs two. Updating the agent is much easier with no reverse imaging required.
Things are beginning to level out, but there are always tradeoffs.
Some may think MCS is simpler, and there is truth to that because MCS doesn’t require as much infrastructure as PVS does. However, on a larger scale it is harder to manage. It lacks the controlled promotional model that PVS has with image life cycle (test, maintenance, & production versions), and updating, or rolling back, machines takes longer.
The recent enhancements of MCS have simplified it enough to make it more attractive, as long as you understand the whereabouts.
What’s right for one environment isn’t for the other. The decision is yours.
Learn more here.
About Anexinet
Anexinet is a leading professional consulting and services company, providing a broad range of services and solutions around digital disruption, analytics (and big data), and hybrid and private cloud strategies. Anexinet brings insight into how technology will impact how business decisions will be made and how our clients interact with their customers in the future.
Josue Molina, [email protected]