Everyone points to the savings that come as a result of server virtualization as the main reason to implement it. However what organizations often fail to consider (and vendors can fail to point out) is how quickly those savings can evaporate as the hidden costs associated with managing a virtualized server environment become known. Among those costs, wasted storage capacity on individual VMs may be the most difficult to control unless an organization puts in place a storage infrastructure that can automate the reclamation of this storage.
A recent article on SearchStorageChannel.com points out that wasted storage capacity is a common problem in virtualized server environments. This issue stems from how administrators allocate storage capacity for new virtual machines (VMs). Most use templates that define the default size of the virtual machine disk image (VMDK) which can be as high as 50 to 100 GBs per VM.
This predetermined amount is allocated because the administrator may not know in advance how much storage capacity the operating system and application on that VM will need. So if the OS and application actually need 40 GBs of storage and are allocated 50 GBs, then he guessed right. But if the VM only needs 20 GBs and it is allocated 100 GBs of storage capacity, it is not only difficult to reclaim that storage capacity, it contributes to the growing, hidden cost associated with virtual server management.
The importance of optimizing storage utilization in virtual server environments should not be underestimated. The majority of virtual servers are now implemented on external storage which exacerbates the cost of virtual server deployments since external, shared storage is far more expensive than internal storage.
Consider an environment that has 100 GBs of external storage allocated to each of 50 VMs. If each VM runs at a 50% utilization rate or less (and the average is far less), that means 2.5 TBs of storage capacity is being wasted. While the actual cost to an organization will depend upon a number of variables (RAID configuration, tier of storage, etc.), the point is that this unutilized capacity becomes wasted storage that eats into the savings that an organization expected when it initially deployed server virtualization.
While organizations can use storage resource management software to monitor, manage and then manually reclaim this storage capacity, this is an ill-advised approach. Administrators will quickly find that they have too many VMs to manage to try to focus on and manage VMs individually plus manually reclaiming allocated storage has always been a risky and time-consuming task.
So what organizations need to do is put in place processes that automate the recapture of this allocated but unutilized storage capacity. One of the best ways that I have seen to accomplish this in VMware environments is the following:
- First, use externally attached storage systems such as the 3PAR InServ Storage Servers that supports thin provisioning. In this way, when the VM is created, the VM only uses as much 3PAR storage as the OS and application actually need for written data.
- Second, only use thin provisioning storage systems that automate the recapture of capacity. In the case of 3PAR’s storage servers, 3PAR provides a thin persistence option. This feature detects when an operating system or application “zeros out” blocks of data that are no longer needed so the underlying storage system can automatically detect and recapture these blocks of unutilized storage capacity.
- Third, if using VMware vSphere, users should take advantage of its eager zeroed thick format. This format has three benefits.
(1) Performance. Every new write in vSphere zeros the block before writing data. With the zeros written at VM creation, ongoing I/O is faster.
(2) Security. If perchance any storage capacity was previously assigned to another VM and still had data on it, this feature zeros out those blocks so no data is accidently compromised.
(3) Efficiency. The eager zeroed thick format can be run on a regular basis to zero out stranded capacity from deleted VMs and VMDKs. With the appropriate storage equipped with capacity reclamation features such as 3PAR and Thin Persistence, the net effect is inline zero detection and instant storage capacity reclamation.
You might be wondering since VMware has its own thin provisioning, is it worth doing going thin on the storage array? The answer is absolutely yes. VMware’s thin provisioning over-allocates file system (VMFS) capacity to VMDKs. However without array-based thin provisioning, the file system must be fully allocated with physical storage capacity.
Consider a 1 terabyte files system with 2 terabytes of VMDKs using VMware thin provisioning. The file system must still have 1 terabyte of physical storage capacity even if data written to the VMDKs is just 500G. Array-based thin provisioning over-allocates storage capacity to VMFS, reducing the storage capacity required up-front and over time.
So the 1 terabyte file system in the example above needs only 500G of storage capacity. In fact, if you use array-based thin provisioning, you will likely find little additional benefit to using VMware thin provisioning. Now if you are using storage that does not support thin provisioning, VMware’s thin provisioning is a great way to reduce storage capacity requirements.
Server virtualization can and does save organizations oodles of money when first implemented. However the costs associated with managing virtual server environments can just as quickly escalate and even over shadow the money that was initially saved unless organizations find ways to automate and optimize the resources allocated to individual VMs.
In the case of storage management in virtualized server environments, storage servers like 3PAR with its thin provisioning and thin persistence features are a must-have if organizations hope to keep their costs down long term. Because even as organizations set up standardized policies within VMware that simplify and expedite the creation of individual VMs, they also need to put in place a storage infrastructure that prevents storage over-allocation while automating the recapture of storage should a VM no longer need it.
Using 3PAR, organizations can accomplish all of these objectives which helps to ensure that the savings – and not the costs – associated with server virtualization keep coming long after server virtualization has been implemented.