Storage Virtualization typically refers to storage abstraction. In other words, there’s a software layer sitting between the server (usually a VM, but not always), and this software layer provides the server with a different view of the underlying storage than what actually exists in the physical world. This allows the full storage capacity to be combined or sub divided on an as-needed basis.
Suppose, for example, that a physical host contained five 1TB drives. A storage virtualization component might make it appear as though the host contains a single 5TB volume, rather than five separate disks.
But you must be thinking that you don’t need software-defined storage for that. You can accomplish the same thing with a RAID controller.” This is very true. A RAID controller can be used to manipulate disks so they appear as one. Keep in mind, however, that disk consolidation is really only one example of how storage virtualization can be used.
Before I get into a discussion of some of the other things that can be done with storage virtualization, I want to point out that storage virtualization and RAID controllers can sometimes be at odds with one another. Typically, the job of storage virtualization is to create a pool of physical resources that can be used on an as-needed basis, with tremendous flexibility. A RAID controller, on the other hand, links disks together at the hardware level.
Recently, VMware released a new Virtual SAN (vSAN) feature. In spite of the feature’s name, the vSAN feature is really a storage virtualization feature. What’s interesting about it is that VMware recommends RAID controllers be configured to provide JBOD storage so that the vSAN can control each disk independently, as opposed to provisioning storage at the hardware RAID level.
To give you a more concrete example of how storage virtualization works, think about how Microsoft has implemented storage virtualization in Windows Server 2012 R2. Windows Server 2012 R2 provides storage virtualization support, even without Hyper-V being installed.
The Windows Server 2012 R2 storage virtualization feature is exposed through the Server Manager. You can access it by clicking on File and Storage Services, followed by Storage Pools. Incidentally, the File and Storage Services role is installed by default when you deploy Windows Server 2012 R2.
The Storage Spaces container allows you to create a collection of storage pools. A storage pool is really nothing more than a logical grouping of physical storage devices. For example, if you look at Figure 1 , you can see I’ve created a storage pool called MyPool. This pool contains four physical drives.
There are a few things worth paying attention to in the figure. First, even though the screen capture only contains a single storage pool, Windows allows you to create multiple storage pools. You can create different pools for different purposes. For instance, you might create a pool of high-speed disks for use with applications that require a high rate of disk I/O. Similarly, you could create a pool of commodity storage for use in situations where a lot of capacity is needed, but not a lot of performance.
It’s also important to keep in mind each physical disk can only belong to a single storage pool. In the case of the server shown, I would not be able to create another storage pool because all of the disks within the server have already been assigned to the existing storage pool.
Something else I want to point out in Figure 1 is that the disks installed in the system match one another. Even so, it doesn’t have to be this way. You can mix and match disks of different sizes and different capabilities within a storage pool. In fact, it’s quite common for a single storage pool to contain a combination of traditional hard disks and solid-state disks. I’ll talk more about that later.
The reason why you can mix and match disks of various capacities within a single storage pool is because of the way the Windows OS uses the disks. Remember, Windows Storage Spaces is a storage virtualization feature. This means with the exception of some relatively obscure Windows PowerShell cmdlets, this is the only place in the entire OS where the raw physical disks are exposed (unless you choose not to include the disks in a storage pool, then they’re visible throughout the system).
Rather than making direct use of the disks included within the storage pool, Windows requires the administrator to create virtual disks on top of the storage pool. It’s the virtual disks that serve as a layer of abstraction between the physical storage and the rest of the OS.
Throughout much of its history, Windows virtual disks have been associated with VMs. Even though there’s a way to associate a virtual disk with a Hyper-V VM, the virtual disks created through Windows Storage Spaces aren’t specifically intended for use with VMs. In fact, if you look at Figure 1, you’ll notice a drive letter has been assigned to the existing virtual disk. If you open Windows Explorer, you’ll see that this virtual disk is treated as a physical disk by the rest of the OS. It’s very difficult to tell the difference between a virtual disk and a physical disk outside the interface shown.
To show you what I mean, take a look at Figure 2. Here, Windows Explorer displays all of the disks within the system. Windows Explorer makes no distinction between physical and virtual disks. In the figure, disk C: is a physical disk and F: is a virtual disk, and yet they look and behave similarly to one another.
So, why does Windows use virtual disks? As the figures show, Windows allows you to combine the capacity of multiple physical hard disks into a single virtual hard disk (or into a collection of virtual hard disks). There’s more to it than that, however. When you create a virtual hard disk through the interface shown in Figure 1, you’re able to define the virtual hard disk structure at the software level. Windows allows you to create virtual disks that use underlying stripe sets, two-way mirrors, three-way mirrors or parity sets.
When you create a virtual disk, Windows provides options for the underlying virtual disk structure based on the disks present within the storage pool. For example, if the storage pool contains only two physical disks, then you obviously wouldn’t be able to create a parity set, but you could create a two-way mirror.
Similarly, if a storage pool contains three disks of varying capacities, then it would be possible to create a parity set, but the size of the parity set would be limited by the size of the smallest disk within the storage pool. The remaining capacity on the larger disks wouldn’t be wasted, however. You could create additional virtual hard disks within the remaining capacity.