Today was storage day at Build for me. I attended 1.5 Hyper-V networking sessions and filled out the rest of the day with clustering and storage (which are pretty much one and the same now). The highlights:
- CSV backup in Windows Server 8 does not use Redirected I/O
- The storage vendors were warned to increase the size of their iSCSI 3 tables (much bigger cluster support now from Microsoft, and more opportunity to use the SAN)
- Storage Pool and File Share Clustering … well let me dig deeper ….
Investing in a virtualisation cluster is a pricey deal, for anyone because of the cost of SAS/iSCSI/FC SANs. Even a start kit with just a few TB of disk will be the biggest investment in IT that most small/medium businesses will ever make. And it requires a bunch of new skills, management systems, and procedures. The operations of LUN deployment can slow down a cloud’s ability to respond to business demands.
Microsoft obviously recognised this several years ago and started working on Storage Pools and Spaces. The idea here is that you can take a JBOD (just a bunch of disks, which can be internal or DAS) or disks on an existing SAN, and create a storage pool. That is an aggregation of disks. You can have many of these for isolation of storage class, administrative delegation, and so on. From the pool, you create Storage Spaces. These are VHDX files AFAIK on the disk, and they can be mounted as volumes by servers.
In this new style of Hyper-V cluster design, you can create a highly available File Server cluster with transparent failover. That means failover is instant, thanks to a Witness (informs the server connecting to the cluster if a node fails and to connect to an alternative). For something like Hyper-V, you can set your cluster up with active-active clustering of the file shares, and this uses CSV (CSV is no longer just for storing Hyper-V VMs). The connecting clients (which are servers) can be load balanced using PowerShell scripting (could be a scheduled task).
Note: active/passive file share clustering (not using CSV) is recommended when there are lots of little files, when implementing end user file shares, and when there is a lot of file metadata activity.
Now you can create a Hyper-V cluster which uses the UNC paths of the file share cluster to store VMs.
This is all made possible by native NIC teaming, SMB 2.2, RDMA, and offloading technologies.
The result is actually a much cheaper storage solution than you could get with a starter kit SAN, and probably would include much more storage space. It is more flexible, and more economic. One of the examples we were shown had the file server cluster also hosting other shares for SQL Server files and end user file shares.
Brian Ehlert (@BrianEh) said it best: file servers are now cool.
Asymmetric Hyper-V Cluster
Elden Christensen briefly mentioned this one in his talk and I asked him about it at Ask The Experts. The idea is that you take the above design, but only a single Windows cluster is used. It is used to cluster the VMs and to cluster the file share(s). This flattens the infrastructure, reduces the number of servers, and thus reduces the cost. This one would be of great interest to small and medium businesses, as well as corporate branch offices.
Self Healing CSV
Myself and Didier van Hoye (@workinghardinit) once had a chat about sizing of CSV. He brought up the point that no one wanted to take a CSV offline for a weekend to chkdsk a multi-terabye CSV volume. True!
Microsoft have now implemented this solution in Windows Server 8:
- Every 60 seconds, the health of the CSV volume is assessed.
- If a fault is found, Windows will target that fault for a fix.
- Windows will dismount the volume, and start caching VM write activity.
- With the CSV offline, Windows will start fixing the fault. It has an 8 second window.
- If the fault is fixed the volume is brought back online and the storage activity cache is pushed out.
- If the fault is not fixed, the volume is brought back online, and Windows will take a later 8 second break at continuing to fix the fault. Eventually the fault is fixed with a one or more 8 second cumulative attempts.
VDI Changes
It seems like the VDI management/broker architecture will be getting much simpler. We’re also getting some performance boosts to deal with the 9am disk storm. Pooled VMs will be based on a single VHD. Each created pooled VM will actually be a differencing disk. When a pooled VM is booted up on a host, a differencing disk is created and cached on the host. The disk is stored on an SSD in the host. Because it’s a differencing disk, it should be tiny, holding probably no more than the user’s state. Using local high IOPS SSD massively improves performance over accessing AVHDs on the SAN, and takes care of the 9am storage storm.