Over one and a half year ago I wrote a follow up on an article by Citrix architect Daniel Feller. The original article by Daniel Feller needed an update and now mine is getting pretty outdated as well.
I’m writing this in such a way you won’t be needing to read the earlier articles but of course you are free to do so anyway.
After Daniel posted his decision tree over two years ago a lot has happened. New Citrix features like XenServer Intellicache and MCS for “XenApp on XenDesktop 7″ have been released and are changing the whole decision making process.
On top of that vendors started to work on solving the whole storage IO issue.
- Hardware vendors like FusionIO who are delivering local flash based storage with IO figures up top 500.000 IOPS.
- Software vendors like Atlantis ILIO who are creating highly optimized and deduplicated memory based local storage.
New features and devices are not the only thing that changed over the last few years, our knowledge of Windows IOPS usage and how to handle that load has grown as well. Mostly thanks to Jim Moyle, the guy who doesn’t like to be called Mr IOPS but in essence actually is. One example is the “MCS uses more than 1.6 times the amount of IOPS over PVS” discussion, although this is true we are talking about read operations which are mostly cached anyway.
All of this combined completely changes the decision making process and with this article I’m going to share my take on this. Is the always right, probably not and even if it is right now it will probably change over time. Keep your eyes open and be smart!
Before focusing on the why and how let’s start with looking at the original decision tree.
Now that we have seen the decision tree it’s interesting reevaluate certain decisions. I will finalize everything in the end conclusion where a new decision tree is included.
Mix and match
Let’s start with the first decision in the tree in which we ask the question about using a XenDesktop only, XenApp only or mixed platform. The reason for this is that, before XenDesktop 7, it wasn’t possible to do MCS for XenApp load. With XenDesktop 7 it’s actually possible to use MCS for XenApp load.
In the old days we were worried about boot and logoff storms because of the amount of IOPS this generated on our expensive shared storage systems. If so we would advise to use PVS because of better IOPS caching possibilities.
Lots has changed in the past few years but the IOPS load is pretty much still the same, yet the decision making process changed. The reason for this change is that we now have more knowledge about the amount of IOPS and vendors created local storage based solutions for this. These solutions handle massive amount of IOPS and this pretty much solves our issues.
On the hypervisor level we are now able to do live storage migrations which helps us when we need to perform management tasks and don’t have the time to wait for all of the users to logoff their sessions.
Another decision is about the need for dedicated VDI desktops. If you need persistency you were forced to use Machine Creation Services. The reason for this decision was based on the fact that Provisioning Services falls back to Server Side caching when the cache has to be persistent. This method of caching ends in performance issues.
With Provisioning Services 6 we are able to do client side caching of persistent caches and pretty much solves this issue so we can use both.
Physical vs Virtual
When we are going to implement physical targets for both VDI and RDS we need PVS. MCS integrates on the hypervisor storage layer and therefor can’t be used on physical targets. This is the simplest decision of them all!
So here we go let’s help you decide between MCS and PVS
Because so many things changed over the last few years I decided to recreate the whole decision tree. Remember that this is just me sharing my decisions and everyone is entitled to their own ideas. When you disagree on a decision please let me know in a comment, when I agree I will change the decision tree and if not…… everyone else can at least think about your ideas.
One last thing before I’ll show you the decision tree. If there is a decision that ends up in either PVS or MCS this doesn’t necessarily mean you should use either one of them. You can still use PVS as well as MCS. I like my designs to be as simple as possible so I would advise on just one of them but as always, it’s up to you!
While looking at the decision tree there is one thing that you should know. When the decision is PVS that’s that and MCS is not possible, at least for the reason why it pointed you to PVS. When the decision is MCS you can use both MCS and PVS my advice however is to use MCS. PVS runs on dedicated servers (VM or physical) and is pretty heavy on network io and should be designed properly while MCS needs nothing more than hypervisor snapshots which, by know, we already have.
If this was a movie I would now say cut and wrap it all up. But with every movie there are some names at the end of it with names of people who contributed to the movie in some way. I’d like to thank some of the guys who shared their thoughts with me and with that helped me to be able to share this information.
Jim Moyle for his terrifying knowledge on IOPS
Shawn Bass for sometimes making me think I’ve got it all wrong:)
Daniel Feller obviously for writing the first ever article on deciding between provisioning services vs machine creation services .
Kees Baggerman for challenging me on a daily level and reviewing this article