CSVs (Clustered Shared Volumes) were introduced in Windows Server 2008 R2 for use with Hyper-V which suddenly allowed for you to migrate virtual machines from one node to the other. According to Microsoft the idea of the CSV went from design board to being production ready in around 12 months which is why when it first appeared it was only supported for use with Hyper-V – when you enabled CSVs in 2008 R2 you got the message below:
I don’t want to go into why to use CSVs as that has been covered many times over the past few years but as a high level overview a CSV is a clustered file system that allows multiple nodes in a cluster to have simultaneous access to a LUN. CSVs became popular because not only did it offer a huge improvement in fault tolerance but it also allowed the VM to become the smallest point of failover. Before CSVs if you wanted to move a single VM from one machine to another each VM would need to be on its own LUN – in other words the LUN itself was the smallest point of failover.
CSV provides I/O fault tolerance – A CSV is able to transparently handle a node, network and HBA failure. This is achieved as the app handle is virtualized before being handed to NTFS if there is then a problem the I/O can be appended on the CSVFS filter until the problem has been solved. An example of how this works is if you have a fibre connection to your fibre SAN and you have VMs running on a node utilizing CSVs, you accidentally disconnect the fibre the I/O will be paused, redirected I/O would be established via the coordinator node and then I/O can be resumed via this new path until you reconnect the fibre and everything is OK again. Without CSVs you would instantly have problems with the VMs – you would have downtime!
Now with Server 2012 Microsoft has gone back to its drawing board and has completely rewritten CSVs from scratch to build upon its success. CSVs in Windows Server 2012 are now known as CSVs V2 (imaginative!!)
So why do we need v2 CSVs and what improvements do they bring?
Even more fault tolerance and resiliency for high availability built directly in
- IN CSV v2 SMB multi-channel is used to detect which network should be used as the CSV network. If there are multiple networks available Windows Server will use these channels to multi-channel stream I/O to your SAN.
- CSV Block Cache – This allows Windows to provide a cache of un-buffered I/O. The cache runs at the block level which allows caching of data right inside the VHD file. There have been caching systems like this on the market for a while but they have always been hardware based with SSD this is different as Windows Server 2012 has it built in and it utilizes system RAM (you need to factor this when looking at your hardware although by default the cache level is 512MB as Microsoft have found this gives the optimal level of performance with the minimum cost). This can dramatically improve a VDI deployment on Hyper-V (I plan on doing a demo if this in a future post.)
Les time spent in redirected I/O mode
- Hugely improved backup interoperability. In 2008 R2 (CSV 1.0) when you started a backup the CSV would be moved to the node that started the back and it would have to be accessed by the other nodes in a redirected mode for the duration of the backup. Your backup software would have to understand CSVs and be able to work with CSV APIs – not all backup software was updated to support this. With Server 2012 Microsoft have worked far more closely with vendors to make their software CSV backup aware. With Windows Server 2012 you are only in redirected I/O mode only for the short time the VSS snapshot is taken – for the rest of the time your nodes access the disk in direct mode.
- You can have parallel backups running on the same or different CSV volumes and cluster nodes.
CSVs were originally only supported on Hyper-V workloads originally as Microsoft had to work out what file systems APIs etc. they needed to optimize to work with Hyper-V they did not have time to do this for more than Hyper-V.
In Windows Server 2012 far more workloads are supported including the file server workload which opens up a whole range of possibilities for fault tolerance with your file servers! This is achieved by having multiple levels of CSV I/O redirection. There is the original ‘file system’ redirection and two new levels; file level and block level redirection.
Multi Subnets are now supported.
CSVs are enabled by default unlike with Windows Server 2008 R2 where you had to enable CSV and then you were able to go and assign the disk as a CSV volume you simply right click on the disk and click ‘Enable Cluster Shared Volume’ and unlike with Windows Server 2008 R2 there is no separate area for the CSV disks they all show in the same window.
In CSV 1.0 custom reparse points were used in 2012 standard mount points are used instead which makes it far more readable and easy to understand. E.g. you not now use C:\ClusterStorage\Volume1 when trying to setup a performance count or trying to monitor free space etc. instead of the disk GUID which was not easily understood.
Removed the external authentication dependencies. The dependency on AD has been removed, being replaced by local user accounts which exist on each node of the cluster (they are synchronized).
You may have noticed a slow response when you try to browse the Cluster Volume folder any node other than the coordinator node – this will stop this from happening and it will also mean that there is no longer need to be a domain controller up and running before you can access the CSV volumes.
A mini-filter driver is no longer used it has been replaced by a CSV proxy file system. If you look in disk management you will see that the disks now show as CSVFS formatted (although it is still NTFS when you pull back the covers). This was required because now that CSV supports more than Hyper-V applications needed to know what they were running on. This will allow an application to detect it’s on a CSV volume, this will be useful if a particular bit of software will not be supported for CSV it can have a hard block coded into it. This new approach is also better than the mini-filter as the mini-filter driver sat above the file system and intercepted I/O which means it bypassed things such as AV. With the new file system approach you will be able to attach to this file system as you would with NTFS.
Supports the huge number of improvements made in file server areas such as:
- Bit-Locker is supported on CSV volumes.
- Fully supports Offloaded Data Transfer
- Defrag improvements and check disk Spot Fix features.
- Support for Storage spaces
That was just a very quick overview of some of the new features and improvements made for Cluster Shared Volumes in 2012. Next I’ll look at how VMware’s offering compares to CSV v2!