If you would like to read the other parts in this article series please go to:
- Shared Storage Considerations for Hyper-V (Part 1)
- Shared Storage Considerations for Hyper-V (Part 2)
So far I have spent the bulk of this article series talking about some important considerations for planning a shared storage architecture for use with Hyper-V. In Hyper-V 3.0 (which is soon to be released with Windows Server 2012) however, the requirement for shared storage goes away. That being the case, I wanted to conclude this series by talking about how Hyper-V 3.0 works differently from previous versions in terms of shared storage.
In previous versions of Hyper-V, shared storage was required for virtual machine failover and for live migrations. Hyper-V 3.0 abandons this requirement in favor of what Microsoft calls a shared nothing architecture. This is simply a fancy way of saying that shared storage is not required. Instead, virtual machines can be live migrated across an Ethernet cable.
Being that Hyper-V 3.0 does not require the use of shared storage, one might wonder what has happened to Hyper-V clustering. Like its predecessors however, Hyper-V 3.0 can function in either a clustered or a non-clustered environment. In either case however, the underlying storage considerations have changed dramatically.
It is easy to assume that because shared storage is no longer required that virtual machine files are stored locally on each Hyper-V host server. Although the use of local storage is indeed supported, it is not the only option. For the first time, Microsoft is also allowing virtual machines to be stored on file servers. The only catch is that the file server must support the use of Server Message Blocks (SMB) 3.0, which is being introduced with Windows Server 2012.
Cluster Shared Volume Support
Although Microsoft has understandably hyped the fact that Hyper-V no longer depends on the use of shared storage, those organizations that have already invested in hardware to support shared storage for their existing Hyper-V deployments may wonder if Hyper-V 3.0 will continue to support the use of Cluster Shared Volumes, or if Microsoft is abandoning the concept completely.
I am happy to report that not only are Cluster Shared Volumes still supported, but Microsoft has actually made a number of enhancements to them. The most significant of these new features is a brand new file system called CSVFS. This file system is similar to NTFS, but is specifically designed for use on cluster shared volumes. This new file system actually allows supported applications to discover that they are running on a cluster shared volume.
Microsoft has also made a number of improvements around the backup and restoration of cluster shared volumes and has begun supporting multiple subnet configurations.
Another enhancement is that failover clustering will support BitLocker Drive Encryption for cluster shared volumes. The individual cluster nodes are able to decrypt and access the encrypted cluster shared volume by using the Cluster Name Object.
Virtual Machine Replication
Another new Hyper-V 3.0 feature that will impact your overall storage planning is virtual machine replication. Virtual machine replication is a brand-new Hyper-V 3.0 feature that allows running virtual machines to be replicated to standby servers or even Hyper-V hosts in an offsite data center.
As is the case with many of the new Hyper-V 3.0 features, virtual machine replication does not require the use of shared storage. Instead, virtual machines are replicated across the network. That being the case, there are at least two major considerations that must be taken into account with regard to virtual machine replication.
First, organizations must consider the storage architecture that will be used both in the primary site and in the replica site. It might be tempting to use low end hardware and the replica site since the replicas do not typically service a user workload. However, the hardware that is used within the replica site needs to be capable of delivering adequate performance for the virtual machines. The reason for this has to do with the ways in which replicas might be used.
Some organizations are considering using Hyper-V replica sites as a part of their backup scheme. The basic idea is that backups can be taken of replica virtual machines rather than running the backups against the production virtual machines. This prevents production hardware from having to bear the burden of allocating hardware resources to the backup process. In other words, by offloading the backup process to non-production hardware, the end user experience is not impacted by the backup.
Of course one of the main reasons for implementing Hyper-V replicas will be continuity of business. If a host server in the primary data center were to fail then user workload could be redirected to the replica virtual machines. That being the case, the hardware within the replica data center needs to be sufficient to delivering adequate end user experience. In terms of storage this means making sure that the storage architecture not only has sufficient capacity to store the virtual machine replicas, but also that the hardware can deliver sufficient IOPS.
The other aspect of virtual machine replication that will require a high degree of planning is the impact that the replication process will have on the network. If a virtual machine contains large quantities of rapidly changing data then replicating that virtual machine could potentially congest the network.
For most virtual machines the amount of traffic generated by the ongoing replication process probably won’t be enough to cause major problems. This is particularly true given the fact that Microsoft will allow you to create a custom replication schedule that allows virtual machine contents to be replicated during nonpeak periods of time.
The initial replication however, tends to be quite large and may consume a significant amount of network bandwidth. Fortunately, Microsoft does give you some options. Rather than replicating an entire virtual machine across the network, you can use one of your backups or a copy of the virtual machine to initially build the replica VM. From that point, you only have to worry about replicating the deltas.
Virtual Fibre Channel
Another new storage related feature in Hyper-V 3.0 is virtual Fibre Channel. This feature allows VMs to communicate directly with Fibre Channel storage. One of the big questions that is often asked with regard to virtual Fibre Channel is if VMs that use virtual Fibre Channel can be live migrated.
VMs that use virtual Fibre Channel can be live migrated. In order to do so, each virtual Fibre Channel adapter must be configured to use two separate World Wide Names. This use of two separate names allows for a brief period in which the virtual machine is running on two separate hosts (its original host and the host to which it is being moved). During this short transition period, both copies of the VM maintain Fibre Channel connectivity. Each copy of the VM uses a separate World Wide Name. By using this approach, it is possible to live migrate the virtual machine without losing Fibre Channel connectivity.
Conclusion
Although Hyper-V 3.0 still supports the use of cluster shared volumes, it is sure to be a game changer for Microsoft in that most features can be used without shared storage. This will make redundancy and fault tolerance more accessible to smaller organizations.
If you would like to read the other parts in this article series please go to:
