The Operational Efficiencies Gained as a Result of 3PAR's New Adaptive Optimization Feature

Since the beginning of March 2010, I have been blogging about 3PAR's new Adaptive Optimization (AO) feature as well as the addition of an SSD tier to its InServ Storage Servers. But the more I study how the AO feature leverages the underlying units of data (called "regions") with 3PAR systems, the more I understand its practical application in data center environments. Specifically, it does more than just automate the placement of data on the appropriate storage tier but automates it in such a way that it creates new operational efficiencies for IT managers.

To grasp the new power of 3PAR's new AO feature, it is important to first understand in detail how it works. Probably the best description I have found to date appeared in a recent Wikibon Announcement Brief. In that brief by David Floyer, he writes:

"The unit of data written in the 3PAR system is a "Chunklet," which is only 256MB long. 3PAR leverages these chunklets, which are held in a common storage pool, as a key component of its virtualization approach. In addition to chunklets, 3PAR has always had an additional construct in place called 'regions' that manage groups of chunklets and all the metadata (e.g., RAID type) associated with them.

3PAR has taken advantage of this structure to add more metadata to the region to track frequency of access, block size, access patterns, etc...all useful data to decide what should go into SSD. Ideal candidates to place on SSD are random, hot, mostly read data.

The secret sauce is the 3PAR software that chooses which blocks to place onto SSD. <Emphasis is mine.> The nice thing about the 3PAR implementation is that all its virtualization tables are already in place and utilized. The system simply points these references at another location (i.e. the flash)."

I highlight that specific sentence in Floyer's description because it succinctly captures what now makes AO stand out from competitive solutions. Other storage systems use performance management software that automates the movement of application data to the appropriate tier of disk but they are only able to do so at a LUN level so they must move an entire LUN.

However there is an inherent problem with this technique when managing applications that require tens, hundreds or even thousands of GBs of data which are found in many environments. To meet the storage request for that application, the storage administrator must do one of two things: either create one extremely large LUN and assign it to the application server or tens or hundreds of smaller LUNs and assign them to the application server.

Neither option is particularly desirable. On the surface, the large LUN appears to be the most desirable since the LUN is easy to create and manage on both the storage system and application host to which it is assigned. The only problem with this configuration is that if you are going to place the volume on the appropriate tier of storage, the entire volume must be moved when performance optimization is introduced.
 
So if one creates and assigns a 500 GB LUN to an application and this LUN needs to be moved to another tier of storage due to performance considerations, it now needs 500 GB of storage capacity on whatever tier it is going to be moved to. This creates numerous issues.
 
First, storage capacity problems may emerge as the storage system needs to temporarily reserve 1 TB of disk - 500 GB for the source volume plus 500 GB of space on the target volume. Second, overhead on the storage system increases as it moves the data from the existing LUN to the new LUN. Third, even the timing of the movement of the LUN becomes an issue as by time the LUN is moved, it may be too late for the application to take advantage of it.

It is for these reasons storage administrators often take the approach of creating and assigning multiple smaller volumes (10 and 20 GB LUNs) when performance-intensive applications need large amounts of storage capacity. Using smaller LUNs, if a specific LUN needs to be moved to a higher performing tier of disk, less storage capacity needs to be held in reserve, the move occurs more quickly and the storage system incurs less overhead.

The downside here is that LUN management once again re-emerges as an issue. Assigning all of the LUNs to the server means volume management has to be done on the server side. Further, since these LUNs are often used by servers in clustered configurations, the process of assigning and managing LUN security for all of these smaller LUNs becomes much more complex and risky.

Creating volume groups (a volume that appears as a single LUN to the application host but consists of multiple LUNs on the storage system) on the storage system is not always ideal either. If the volume group is striped (the recommended configuration for most performance intensive application deployments), it stripes the data across all of the LUNs in the volume.
 
If a certain striped dataset goes hot, the data is striped across all of the LUNs in the volume group. In this case, the entire volume group needs to be moved and you are right back to the initial scenario with large single LUNs.

The ability of 3PAR's AO to move blocks of data at a very granular level (128 MB) addresses all of these concerns.
 

• Large LUNs can now be created on the 3PAR InServ Storage Server and assigned to the host(s) since any hot block of data within that LUN can be moved to the appropriate tier of storage.
• Overhead on the InServ Storage Server is also minimized since it does not need to move 10, 20, 100 or 500 GB LUNs but only 128 MB blocks of data within those LUNs.
• LUN management is simplified since storage administrators do not need to worry about making trade-offs between ease of storage management and their ability to easily manage the performance of the application.
• Manual performance management work to determine when and where to move a block of data can now be done by the system, or "autonomically" in 3PAR terminology.  Threshold alerts are captured and handled on-demand (or on a schedule chosen by the user) for small amounts of application data.  

3PAR's Adaptive Optimization is a really cool feature but for reasons that go much deeper than just its ability to facilitate the economical deployment of SSDs in enterprise data centers. While it certainly accomplishes that objective, organizations are also looking for practical ways to make their current methods of storage management and performance tuning more efficient without subjecting their current staff to greater workloads. Because of how Adaptive Optimization leverages 3PAR's underlying chunklet and regions technologies, organizations do more than just drive their storage costs down while improving application performance, they also gain new operational efficiencies.