Symantec’s recent announcement that it will support its Veritas Storage Foundation
for Windows (SFW) 5.1 in the Microsoft Hyper-V parent tremendously increases the breadth of functionality available to the child virtual machines (VMs) of Microsoft Hyper-V environments. Immediate new benefits that child VMs will realize include the restoration of full path and storage management capabilities that often were severely handicapped once physical servers were virtualized. But other benefits that also come along with moving SFW 5.1 into the Hyper-V parent
include better utilization of thinly provisioned storage volumes assigned to the Hyper-V parent along with an attractive SFW licensing option for Hyper-V servers.
Fully realizing the benefits of thinly provisioned volumes assigned to Hyper-V servers is a major value that organizations gain from SFW’s move into the Hyper-V parent. One of the historical problems of Windows servers (physical or virtual) is the storage over-allocation that
occurs on Windows servers with storage utilization rates in the 20% range fairly common.
Organizations can become excited by the prospect of virtualizing their Windows servers since they know this storage over allocation exists and, once virtualized, they only need to buy a fraction of the storage that their Windows servers are using now. Further, by putting thinly provisioned volumes behind their virtualized child Windows servers, the Windows Hyper-V servers still think they are getting their full allocation of storage even though beneath the covers the only storage they are using on the array is what is actually utilized.
However managing storage assigned to a child VM of a Hyper-V server is a much
more complicated process than managing it on a physical server. In the case of “fat” volumes (non-thinly provisioned volumes), all fat volumes are first provisioned on the Hyper-V parent before the Hyper-V provisions VHDs on top of those volumes and presents those VHDs to the
child. The problem with this approach is that there is no easy way to expand that volume in the child VM’s storage pool when storage growth occurs.
This is partly the motivation behind using dynamically expanding VHDs and
array based thin provisioned volumes in virtualized server environments. Both of these, in theory, should solve this problem because as a child VM’s needs for storage increase, the dynamically
expanding VHD would grow and the thinly provisioned volume assigned to it should also increase in size. While it does do that, the flaw with this approach is two-fold.
- First, the use of dynamically expanding VHDs could have unforeseen performance impacts for those applications running in the child that have both a
higher workload and data change rate. - Second,
regardless of the type of VHD located on a volume in the parent, the Windows NTFS file system has a tendency to “wander”. As it wanders, it writes bits of data to unused components of the thinly provisioned volume. As a result the storage consumed on the thinly provisioned volume increases disproportionately to the actual amount of storage that the child VM actually needs.
To account for this behavior of NTFS, best practices for the allocation of thinly provisioned storage volumes containing the VHDs assigned to child VMs call for provisioning volumes that are minimal in size. But by doing this, it recreates the storage management problem that thin
provisioning was supposed to alleviate since using small thinly provisioned volumes precludes the ability for the thinly provisioned volume to provide on-demand, dynamic storage growth.
Moving SFW into the Hyper-V parent addresses these storage management issues and allows for the more aggressive use of thinly provisioned volumes in
Hyper-V environments. Because SFW now manages the storage associated with each Hyper-V child VM through the parent, organizations can leverage SFW’s Autogrow feature to automatically add more space to the volumes that contain VHDs for one to multiple child VM’s as specific utilization thresholds are crossed on individual VMs.
For example, if storage utilization on volume containing VHDs for a child
VM reaches 80%, an alert can be sent to the administrator and, if the storage utilization reaches 95%, SFW can automatically grow what essentially can be referred to as the child VM’s storage pool– the volume that contains that child VM’s VHDs. This is possible because,
again, SFW now resides at the Hyper-V parent level so it can grab more storage from the Hyper-V parent’s storage pool and add more space to that volume that contains one to many VHDs for a single or multiple child VMs.
What
organizations will find equally encouraging is that Symantec is licensing SFW for the Hyper-V Server using the same licensing and pricing model that it uses for other Microsoft Windows Server products. This will allow organizations to more affordably offer baseline storage
management functionality to all child VMs hosted by a Hyper-V server and potentially offer automated storage management all the way up into each Hyper-V’s child VM.
As I have said in a previous blog and which I want to reiterate here, moving SFW into the Hyper-V parent opens up all sorts of new server virtualization possibilities that were simply not possible before now on file-based server virtualization platforms. Not only does it make it possible to offer high availability and path management capabilities to all child VMs but organizations can now take advantage of other technologies like thin provisioning while mitigating the adverse behavior of NTFS without breaking the bank. Granted, there are still
some automation features that Symantec needs to build into SFW for organizations to fully leverage it but no doubt this represents a big step forward in the automation of management of virtualized server environments.
Part 1
of this three part series examines how file based server virtualization
operating systems have failed to address high availability and
performance requirements of certain applications and how Symantec
Storage Foundation for Windows is addressing that in Microsoft Windows
Hyper-V.
Part 2
of this three part series examines how moving Storage Foundation for
Windows into the Hyper-V parent provides enhanced path and storage
management functionality for Hyper-V child VMs.