So alot of problems that have been with using MCS versus PVS is the load that it puts on the Storages fabric. With the way MCS works we have an golden image which is our master template, when we createa machine catalog or update a machine catalog we have the option to choose a specific snapshot or if we don’t MCS will create a light snapshot for us. Then based upon that snapshot it will copy that snapshot to the storage repository which we have defined in Citrix studio.
Under a folder called MCS-basedisk. Then for each virtual machine that is created we have two additional disks. One Identity disk and one Differecial disk where all writes will be stored. So how is this going to be from a storage perspective?
That MCS base disk will be marked as read-only and will be linked together with the differential disk. Because a differential disk is only a virtual disk you use to isolate changes to a virtual hard disk or the guest operating system by storing them in a separate file.
So for all virtual machine that boot up in that machine catalog is going to be dependant on that MCS-baseddisk. And with Nutanix there could be an issue because, Nutanix is using data locality. Meaning that virtual machine will be served locally on the host they reside on (Where that is possible of course) This is to ensure scaleability and having no bottlenecks for the virtual machines.
And also with a Nutanix platform, we have so called Container which maps up as datastores (In VMware) for a virtual machine. So this will still work pretty well if everything is hosted on the same physical host
Since the MCS-basedisk is located on the same host as the Machine catalog clones the read operations will happen locally on that particular host. But this is not realistics and in all cases we have multiple hosts, where the clones are scattered across different hosts.
Now because of the data locality rule the vdisk (Which is the MCS-baseddisk) will be stored on one of the hosts. All the other clones with their differencial disks which is linked to the MCS-basedisk will generate alot of read-traffic across the network because of this. This is from a Citrix persepctive because it is in theory the same datastore.
But as I mentioned earlier, this COULD be a problem but Nutanix has already placed a solution in place for it, which is called Shadow Clones. This allows the storage fabric to cache an vdisk or VM data which is in a multi-reader scenario. Meaning in this case all the clones which needs to read from the MCS-basedisk. In this scenario the CVMs will monitor read activity across the whole fabric. Once the disk has been marked as immutable, the vDisk can then be cached locally by each CVM making read requests to its cached version of the MCS base-disk (aka Shadow Clones of the base vDisk)
NOTE: One thing to be aware of is that the data will only be migrated on a read request as to not flood the network and allow for efficient cache utilization
In the case where the Base MCS Virtual machine is modified/updated, the Shadow Clones will be dropped and the process will start over.
But this feature will allow us to still leverage data locality and remove any constraints from the network. Now the feature is enabled by default (You can see this by using this command against the CVM
ncli cluster get-params|grep -i shadow
So this is the one of the cool features which makes MCS better to use on Nutanix, also noticed that there might be more to come here as well!