Storage planning for Hyper-V Hosts (Part 1)

If you would like to read the other parts in this article series please go to:

A key aspect of planning a virtualization environment–for example, one based on Windows Server Hyper-V, with or without System Center Virtual Machine Manager–is designing the fabric, an umbrella term that includes the physical servers, switches, cards, connections and other infrastructure hardware that allows storage resources to be accessed by hosts and by the virtual machines running on these hosts.

Storage is fundamental to any virtualization environment and can take different forms ranging from block-level storage solutions like Fibre Channel or iSCSI SANs to local or network file-based storage solutions. Each of these different types of storage can be a valid choice in different virtualization scenarios depending on your budget room and the degree of reliability, availability and workload performance you need in your environment.

Before proceeding further with this article I’d like to suggest some background reading for you–especially if you’re not familiar with some of these storage solutions–in which case you can learn more about them by reading the following articles here on WindowsNetworking.com:

Configuring iSCSI Storage – a four-part series by Mitch Tulloch
A Crash Course in Storage Area Networking – a six-part series by Brien M. Posey
Getting Used to Using Windows Storage Spaces – a three-part series by Brien M. Posey
Windows Server 2012 R2 Storage Spaces – two-part series by Scott D. Lowe

You might also want to check out the following articles:

A First Look at Windows Server 2012 R2 Storage – a three-part series by Brien M. Posey
Choosing a storage solution – an article by Mitch Tulloch
Enterprise storage best practices – an article by Mitch Tulloch
Avoiding storage failures – an article by Mitch Tulloch
Enterprise hard drives – an article by Mitch Tulloch

In addition, my book Optimizing and Troubleshooting Hyper-V Storage (Microsoft Press, 2013) may be of use to you when you implement storage solutions for Hyper-V virtualization environments:

A companion title Optimizing and Troubleshooting Hyper-V Networking (Microsoft Press, 2013) is also available:

These two books consist of recommendations and tips contributed by Hyper-V experts working at Microsoft and they can also be helpful when planning the storage fabric for your virtualization environment.

Now let’s proceed by discussing some considerations when contemplating the use of solid state drives (SSDs) for storage on Hyper-V hosts.

Choosing the right kind of SSD

A key consideration when contemplating the use of SSDs for Hyper-V hosts is what type of SSD you should use. The answer is to always use enterprise class SSDs, not consumer SSDs, for these kinds of scenarios. In particular you should use SAS (Serial Attached SCSI) SSDs rather than SATA (Serial ATA) SSDs in your hosts for the following reasons:

Their controller is more powerful
Their write latency is much smaller
Their endurance cycle (number of writes before failure) is much longer
Their reservation (free) space is much larger
Their garbage collection algorithm as implemented in their firmware is more effective

SSDs may use either single-level cell (SLC) or multi-level cell (MLC) flash technologies, and enterprise SSDs generally use eMLC (enterprise MLC) which enhances MLC with wear-levelling, deduplication, redundancy and write optimization technologies. A good explanation of the differences between these various technologies can be found in the article MLC vs SLC: Which flash SSD is right for you?

SAS SSDs are ideal for hosting operating system volumes as they can increase manageability by making operating systems faster and more responsive. SATA SSDs can still have a place however in your Hyper-V environment, particularly in scenarios where no writes are involved. For example, if you are going to use a parent virtual hard disk (VHD) to create differencing disks, you need to set the parent VHD as read-only to prevent it from being modified. You could therefore opt to use cheaper SATA SSDs for storing such parent VHDs.

When not to use a SSD

Although SAS SSDs have a long endurance cycle, there are some scenarios where you may want to use enterprise hard disk drives (HDDs) instead. That’s because the total write lifetime of an SSD is basically finite even when advanced write-optimization and wear-levelling algorithms are factored. By contrast, the write lifetime of an HDD is limited mainly by the mechanical failure of the bearings.

So for workloads where almost continuous writes occur it’s generally wise to use enterprise HDDs in a RAID10 configuration instead of SSDs. Examples of such workloads could include SQL Server databases, Exchange servers, IIS webservers, and so on. If any of the virtual machines on your Hyper-V hosts need to run such workloads, a good approach might be to split the virtual machine over two volumes as follows:

C: on a SAS SSD to host the guest operating system of the virtual machine
D: on a HDD RAID 10 volume to host the database, application code, transaction logs, and so on.

But if your virtual machine is running applications or services that are not write-intensive, such as a DHCP server or DNS server, then you could host the guest operating system and application or service on a single volume on a SAS SSD.

Taking the long view

Using SSDs can drastically boost the performance of applications and services running in virtual machines on Hyper-V hosts. And the price of enterprise SSDs continues to drop as their capacity, reliability and write lifetime steadily increase. As a result you might opt to use SAS SSDs even for running your write-intensive applications such as SQL Server databases with the idea that although your SSDs might wear out in 18-24 months of almost continuous use, by the time you need to replace them the price of an equivalent SSD will likely have significantly dropped to the point that the long term amortization of the cost of running your database application makes SSDs more affordable than HDDs over the long term.

Using SSDs for network storage

So far we’ve been focusing on using SSDs for local storage or direct attached storage (DAS) on Hyper-V hosts to boost operating systems and application performance and responsiveness. But SSDs can also be used for network storage for Hyper-V hosts, and a good example would be using Storage Spaces on a Scale-out File Server (SoFS) to create pools of storage that combine SSDs and HDDs, with or without data tiering, for access over the network by the Hyper-V hosts using Server Message Block (SMB) 3.0 protocol. For more information on this kind of storage solution, download my free ebook Introducing Windows Server 2012 R2 Technical Overview (Microsoft Press, 2013) available in PDF, EPUB and MOBI format from the Microsoft Virtual Academy Free eBooks landing page.