Read on:
Beginners’ Guide for Microsoft Hyper-V: Overview of Hyper-V Part 1
Beginners’ Guide for Microsoft Hyper-V: How to Install Microsoft Hyper-V Using Server Manager – Part 2
Beginners’ Guide for Microsoft Hyper-V: How to Install Microsoft Hyper-V with PowerShell – Part 3
Beginners Guide for Microsoft Hyper-V: How to Install Microsoft Hyper-V in Windows Server Core – Part 4
Beginners Guide for Microsoft Hyper-V: Remote Management of Hyper-V – Part 5
Beginners Guide for Microsoft Hyper-V: How to Install Hyper-V Server – Part 6
Beginner’s Guide for Microsoft Hyper-V: What is Azure Stack HCI – Part 7
Beginner’s Guide for Microsoft Hyper-V: Windows Admin Center Hyper-V Management – Part 8
Beginner’s Guide for Microsoft Hyper-V: Configuration of Hyper-V Networking Best Practices – Part 9
Introduction
One of the fundamental areas of learning Hyper-V or any other hypervisor is understanding the storage configuration. Hyper-V, like other hypervisors, stores virtual machine disks as simple files on the storage subsystem. This architecture provides many advantages when working with VMs and the underlying storage they consume. Let’s look at Hyper-V storage basics for beginners and see how we can get started with Hyper-V storage for virtual machines.
Local vs Shared storage
At a high level, there are two types of storage consumed by Hyper-V hosts, local storage and shared storage. While “local” storage can become “shared storage” in specialized HCI configuration, to talk about Hyper-V storage for beginners, we will assume that local storage is not configured in an HCI configuration. Instead, it is consumed only by the physical Hyper-V host to which it is attached. As a note, we will discuss a Hyper-V HCI configuration in a continuation of our Hyper-V for beginners series.
A Hyper-V server’s most basic storage configuration is to have a local disk or disks physically attached to the Hyper-V host. The Hyper-V host can consume the local disks for virtual machine storage as it would store any other type of data, including files, folders, shares, etc.
Below is a high-level conceptual example of a single Hyper-V server with local storage.
Why do you choose one configuration over the other? The choice between local and shared storage generally relates to availability, redundancy, and scalability. With truly local storage that is only available to one Hyper-V server, workloads housed on the locally attached storage are tied to a specific Hyper-V host.
When thinking about high availability, if workloads are running on a Hyper-V server running local storage, if something happens to the Hyper-V host, the workloads will be taken down with the host. However, with shared storage configurations, two or more Hyper-V hosts are generally connected to the shared storage (SAN, NAS, etc.). The virtual machines are stored on the shared storage device. Hyper-V servers are configured in a cluster configuration, which pools resources together and provides failover capabilities for virtual machine resources.
It is important to note that Hyper-V servers can have local and shared storage, despite being part of a Hyper-V cluster. However, even if a Hyper-V host is part of a cluster connected with shared storage, if virtual machines are placed on the local storage only available to a specific Hyper-V host, these VMs are not protected. It is because they don’t assume the benefits of the Hyper-V cluster capabilities, since their storage location is not available to the other Hyper-V hosts in the cluster.
The traditional Hyper-V shared storage configuration, like VMware and others, will generally be configured in what is known as the “3-2-1” configuration. This configuration refers to 3 hosts, 2 SAN switches, and 1 storage unit. In addition, the storage unit will typically have many levels of redundancy built into the solution, such as RAID to protect the data, multiple storage controllers to have redundancy at the controller level, and multiple power supplies.
Pros and cons of Local vs Shared storage
What are the pros and cons of local vs. shared storage? While the below is not an exhaustive list, it provides a basic comparison between the two options.
Local storage:
Pros:
- Easy to get started
- Cheap
- No additional configuration involved
- Great for lab, dev/test
- Easier to troubleshoot
Cons:
- Provides no failover capabilities
- Redundancy is limited to the storage redundancy configured on the host
- Does not scale well
- Does not allow maintenance operations on the host without VM downtime
Shared storage:
Pros:
- Provides high availability for virtual machines
- Allows taking hosts down for maintenance without affecting VMs
- Allows easy scalability – simply add more hosts to the shared storage for more compute resources
- It aligns with best practices when configuring Hyper-V for production use cases
- Hosts can contribute compute power without local storage attached
Cons:
- Typically more expensive to purchase enterprise-grade SAN storage
- More tedious to configure properly
- Greater risk for misconfiguration
- More difficult to troubleshoot
- Can sometimes result in vendor lock-in with vendor-specific features and capabilities
Hyper-V HCI storage configuration
Over the past several years, enterprise organizations have been transitioning from the classic 3-2-1 architecture described above to a hyper-converged infrastructure (HCI) solution. Hyper-converged infrastructure has taken the enterprise datacenter by storm over the past few years. Generally speaking, businesses looking at on-premises hardware refresh cycles are typically considering HCI for their refresh.
HCI configurations provide many benefits as they eliminate the external storage device. Instead, using local storage, HCI utilizes software-defined storage technologies to pool local storage into a single logical storage pool shared between the hypervisor hosts.
Hyper-V HCI storage is known as Storage Spaces Direct (S2D) and allows aggregating locally attached hard drives installed in your Hyper-V hosts and pooling these into logical software-defined storage. Microsoft has a new solution enabled through an Azure subscription for HCI, called Azure Stack HCI. It provides a purpose-built operating system for running Hyper-V virtual machines on top of software-defined storage, which uses Storage Spaces Direct.
While Storage Spaces Direct is a feature of Azure Stack HCI, you can still enable Storage Spaces Direct as part of Windows Server implementation. It allows aggregating internal storage drives on a cluster of 2 to 16 cluster hosts in a software-defined pool. The storage pool has tiered storage with caching and capacity tiers. It uses erasure coding to configure and protect data across the software-defined storage pool.
It provides many features as part of S2D that allow organizations to run virtual machines in a way that takes advantage of the underlying benefits of S2D, such as Resilient File System (ReFS), cluster shared volumes, storage pooling, etc.
Wrapping up
Hyper-V storage options provide many configurations that fit different use cases and configuration needs. You can use local storage, providing a quick and easy storage location to house dev/test and lab VMs, but it does not provide any redundancy. It does not offer any high availability capabilities. Any virtual machines housed on local storage are affected by maintenance operations and other events that take down the Hyper-V host. Traditional shared storage allows configuring shared storage presented to Hyper-V cluster hosts, allowing admins to have multiple hosts capable of running critical workloads. In addition, it enables performing maintenance operations without taking down essential VMs. Storage Spaces Direct (S2D) is Microsoft’s software-defined storage solution that provides a hybrid approach using locally attached storage pooled together in a logical storage pool.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
