Storage capacity requirements are growing in almost every data center causing many IT managers to look for ways to ‘bend the growth curve‘ and keep the IT budget from being consumed by the storage budget. In fact, a small bend in that curve, less than even 5%, can save the medium to large sized data center millions of dollars per year in their storage total cost of ownership (TCO). Most data centers can increase storage efficiency by more than that 5% by addressing surprisingly easy-to-fix storage provisioning problems, without having to go to an elaborate tiered storage strategy. However, the biggest challenge for the large enterprise is simply identifying these provisioning problems.
Cutting storage expenditures is near the top of every IT manager’s project list but most companies still tend to think that buying more storage is preferable to embarking on a storage reclamation project. This is because most storage managers equate reclamation with archiving or tiered storage, which is the IT version of a quagmire.
First, storage reclamation is more about storage efficiency than it is about identifying and archiving or deleting old data. Similarly, storage reclamation projects shouldn’t initially focus on archiving data from the primary set. Instead they should focus on storage that has been incorrectly provisioned to servers and is being used inefficiently, if at all. While a few of the more difficult reclamation steps can require potential server downtime, most do not. The most basic of reclamation projects can be significantly easier to complete than a typical tiered storage project and many can be implemented without impacting user access to data. Implementing just the ‘easy’ reclamation steps can frequently provide more than that 5% bend in the storage growth curve, eliminating potentially millions of dollars in storage expenditures.
Storage Reclamation Process
The first step in the storage reclamation process is to identify storage that has been improperly provisioned. If it can be done quickly and without hours of manual inspection this step can more than pay for a storage resource management software investment and set up the potential for an even bigger return as the tool is further leveraged to establish best practices.
To some extent storage reclamation could potentially be done by manual inspection of each LUN to determine how it is assigned to each server. In reality the storage administrator is better served by having a tool like APTARE’s StorageConsole Capacity Manager to identify these provisioning issues. There is simply too much abstraction and too little direct correlation between servers and storage for these resources to be manually inventoried and assessed on a continual basis.
In the typical storage system, drives are identified and put into array groups. Each of those groups are divided up into various LUNS and each LUN is assigned to one or more servers. Then that server needs to partition the LUN and lay a file system onto each partition. Finally, with a file system in place, data can be written. Each step in the above process must be completed for effective utilization of the assigned capacity and each step has a potential for error. Tracking each one of these steps across every array group and server in the data center may be too daunting a task to be done manually, even once. And the likelihood of a lengthy, manual process being repeated is very slim. For true efficiency to be realized the inspection has to be something that can be done quickly and regularly.
Software solutions need to monitor the infrastructure from end-to-end to be effective. Only seeing the server-side view or the storage-side view will not lead to a complete and accurate audit. The software solution has to be able to report on storage usage on the server’s operating system and, potentially, the application itself, to fully understand actual storage utilization. The ideal way to capture this data, both in terms of reporting accuracy and timeliness, is to perform host-side and array-side data tracking, as found in software solutions like APTARE’s Storage Console Capacity Manager. These tools allow for an automated, routine inspection of the environment to make sure any storage inefficiency is identified quickly.
The basic objective is to use a software analysis tool to help identify wasted resources in the storage provisioning effort and to take corrective action on these provisioned volumes. Surprisingly, many of the configuration problems can be fixed with no server or application downtime. The hard part is actually uncovering the provisioning problems in a large enterprise, which can simply be automated through employing a software analysis tool with host and storage discovery capabilities. Many data centers may never need to go beyond these easy fixes to see a 5% or greater increase in storage efficiency and, as a result, experience significant reductions in their cost of their storage.
Fixing The Easy Provisioning Problems
The number one provisioning problem is identifying LUNs which have been created on the array but for some reason were never assigned to a server or are no longer assigned to a server. Addressing this problem requires correlating all the LUNS in the storage infrastructure to their assigned server(s). The result of this exercise is a list of orphaned LUNS that can be subjected to reclamation. These LUNs can be deleted with no further work making the capacity they were consuming instantly available to the entire array. While this may sound incredibly simple it’s not uncommon in a large enterprise to find terabytes of captive capacity that are not assigned to a server.
The second provisioning problem is identifying LUNs that have been allocated to a server but have not yet been discovered by that server. This means the array has provisioned the capacity but the assigned server has not even scanned for the available LUN. Similar to this is the case where a LUN has been discovered but has not been put in to use, meaning that the disk partitioning software has identified the LUN but no file system or data has been placed on it. Identifying these problems requires finding those LUNs from the server perspective that are undiscovered or unused. As was the case with orphaned LUNs, all that needs to happen in these situations is to delete those LUNs and reclaim this storage capacity. There are no interruptions to the servers or applications and this once-captive capacity is now available to the entire storage array.
Most of these provisioning problems are caused by the increased demand on and speed with which IT is forced to operate. The rush to bring applications online often results in the allocation of storage with no time to check and see if that allocation was actually used. Ironically, as shown above, these errors are very easy to fix, often by just deleting the LUN. The problem is finding these LUNs in a large data center. Storage inspection products like StorageConsole Capacity Manager enable storage administrators to easily identify these problems on a routine basis. Often these ‘easy’ fixes can lead to the recovery of high single-digit percentages of storage capacity and the savings of millions of dollars over the course of just a few years.
The next step, though, is understanding the true cost of storage. While most IT managers agree that it’s more than simply the cost of the physical assets, there is confusion and disagreement around which calculations should actually go into determining total storage cost. In our next article Storage Switzerland will cover how to determine the data center’s true cost of storage.