I’ve been getting a lot of questions lately around MCS vs PVS and which protocols work “best” with which technologies. And then just a couple weeks ago I was reading this lovely whitepaper put out by NetApp and I saw this statement on page 8:
“Best Practice: Citrix recommends NFS as the preferred protocol for XenDesktop 5”
Huh? Come again? We recommend NFS for XD5? You might be left wondering (as I was) after reading that statement, but then you probably saw the little “(R)” next to NFS in our official product documentation (which means it’s the “recommended protocol”). So it has to be true right? Not quite. Keep reading because I’m going to attempt to set the record straight.
We first need to understand that “Citrix recommends NFS for XD” is taken out of context. The NetApp WP was using MCS as opposed to PVS in their pooled desktop scenario. And our eDocs page that says NFS is recommended is the “Requirements for MCS” page. I really cringe when I see blanket statements like that with little to no justification (and we are just as guilty as NetApp here!), so I think it’s important to understand the context and realize that we are talking about MCS.
So you might be asking yourself…does Citrix recommend NFS for PVS as well? And why on earth would we say NFS is recommended for MCS? Let’s start with that first question.
You can certainly use NFS (or CIFS) to serve up vDisks to PVS. And the beauty of those file-based protocols is easier management and we don’t need to carve out separate LUNs in a distributed PVS HA configuration (so less disk space is required as a result as well). But the disadvantages of using CIFS or NFS is they require some tuning or tweaking in order for PVS to cache the contents of the vDisks in it’s system cache. If you’re scratching your head at this point, please read Dan Allen’s article on this subject and then come back to this article. But even if you are properly tuning your NetApp filers or tweaking all the right LanMan parameters for SMB, we still might not get as good as performance compared to hardware iSCSI or FC. The advantages of using these block-based protocols with PVS is inherent caching and performance. And even though this killer performance comes with additional cost (HBAs, etc.) and might eat up a little more disk space, this is what most customers choose. I’ve been doing this stuff every day since we acquired Ardence and I’ve seen no less than 50 production XD deployments with PVS to date – and of those, 95% are using a block-based protocol (typically FC) and I’ve only seen a couple that use NFS or CIFS. The other option is storage local to PVS itself…no expensive SAN, cables, cards or protocols required. Simply use the local storage on the PVS box(es) to serve up vDisks. And since PVS sees the vDisk store as a local drive, it offers the same inherent caching capabilities as iSCSI or FC. So I’m not going to explicitly say “Citrix recommends local storage or block-based protocols for XD deployments with PVS”, but I can tell you that’s what most people are doing out there and it offers exceptional performance if PVS is running on a 64-bit operating system and ample file cache is available.
Now onto the next question….why do we say NFS is recommended for XD deployments with MCS? Well you need to understand the properties of all the different virtual disk data formats and SR types. I highly recommend reading chapter 4 of our XS Admin Guide (specifically sections 4.1.6 and 4.2) if you don’t know what the difference is between file-based VHDs and LVM-based VHDs. Because this stuff is extremely important and it’s partly how we arrive at statements like “NFS is recommended for XD with MCS”. But to summarize, there are 2 (well technically 3 but I’m not going to talk about LUN per VDI or any RDM stuff here today) different types of mappings of physical storage to a virtual disk image (VDI). And it really comes down to block-based vs. file-based storage as I alluded to above. The default XS block device-based storage inserts a Logical Volume Manager (LVM) on a disk, which can be either local (“LVM” type SR) or a SAN attached LUN over FC or iSCSI (“LVMoHBA” or “LVMoISCSI” SR types in XS). Compare these LVM-based SRs to file-based VHDs and we have more options – EXT for local storage and NFS for shared storage. And it’s important to realize that LVM-based formats have different properties than file-based VHDs (coalescing, agility, sparseness, etc.). There are pros and cons and you have to decide which is best for you based on things like the ability to resize SRs, fast-clone and/or thin-provision. But one of the primary advantages of using EXT3 or NFS is they are “sparse”! And that means that the image file is allocated as the VM writes data into the disk (aka “thin provisioning”). This is much different from the LVM-based SR types we described above which fully inflate the disk and, in contrast, are not sparse. (Quick note – I’m not going to get into LVM vs. LVHD and what’s changed in XS 5.6 FP1…I’m trying to keep it simple).
So the fact that NFS is a shared storage repository, is very simple/easy to manage and supports thin-provisioning by default is why we are saying it’s the “recommended protocol” for XD deployments with MCS. OK…now it’s making more sense. 😉 But can I also use block-based storage and protocols such as FC or iSCSI with MCS? You bet! You just won’t get thin-provisioning and it’s not as easy to configure or manage because now you have to carve out LUNs and worry about fun things like locking, SCSI reservations and the number of VDIs/LUN. But if you know how to size LUNs properly (this will actually be the topic of one of my next blogs so stay tuned) and want optimal performance, then using block-based protocols and storage would be recommended in my humble opinion.
So I hope this clears things up. To summarize, NFS makes things very easy and supports thin-provisioning, so that’s the reason why we say it’s “recommended” when doing XD deployments with MCS. But if you are using PVS (which is what most people are using), it can be a different story. And you can certainly use block-based protocols with MCS as well, but it just requires a little more careful planning and disk space.
Now you know, and knowing is half the battle. Go Joe!