was successfully added to your cart.

Acheive the Cost and Performance Benefits of In-Server Flash with None of Its Drawbacks

By December 9, 2013Symantec

Enterprises view in-server flash with more than a wary eye. On one hand, they see how it tremendously accelerates application performance at a fraction of what flash on storage arrays costs. Yet on the other hand, data on in-server flash is no longer centrally stored so it must be managed as a “one-off” which detracts from its appeal. Leveraging the new SmartIO feature in Storage Foundation 6.1, organizations can begin to realize the best of what in-server flash offers while eliminating this drawback.

Enterprises are coming to grips with the realities that flash is going to appear at all layers in their storage network infrastructure: the server, the storage array and even in network appliances. Yet of these three layers in which flash may appear, none may be more appealing – and more elusive – than effectively deploying and managing it on the server.

Most enterprises already have a pretty good handle on deploying and managing flash at either the network or storage array layer as they manage it in much the same way as existing storage capacity. They may share it among multiple applications, scale and manage it independently of the application and use array-based utilities to backup and protect data stored to its flash.

The issues that organizations encounter with deploying flash at either the network or storage array level are the performance hit and its cost. While reading data from flash at either of the network or storage array level outperforms disk, more organizations are starting to measure flash performance in nanoseconds. When flash is measured in these layers of the infrastructure according to that benchmark, it is challenged to meet them. Further, flash is more costly to deploy at either of these two levels.

Despite these issues, in-server flash is selectively deployed for two reasons. Organizations cannot easily:

  • Optimize data placement and then manage data stored on in-server flash
  • Share in-server flash among multiple servers

The Symantec Storage Foundation Suite 6.1 release addresses both of these issues. The philosophy Symantec Storage Foundation espouses when it comes to in-server flash closely mirrors what most enterprises now embrace. Rather than trying to store all application data on flash (which is often too expensive, unnecessary and results in wasted capacity,) Storage Foundation uses its new SmartIO feature to treat in-server flash as a cache while using disk to permanently store production data.

SmartIO Caching Techniques.JPGSource: Symantec

To optimize data placement and then manage it on in-server flash, SmartIO provides three options:

  • Volume Manager Read Cache. Many organizations that run Oracle databases use raw storage volumes with no file system. By presenting the Oracle database with a Storage Foundation volume (comprised of local, direct-attached or SAN-attached storage,) SmartIO recognizes that Oracle is the application accessing the volume by analyzing and recognizing the type of application IO..

Due to the level of application integration that has been developed over the years between Storage Foundation and Oracle, Storage Foundation possesses a great deal of insight into the type of IO that Oracle generates. SmartIO leverages this insight to forecast what data to keep on the in-server flash. This technique optimizes the read performance of the Oracle database as it keeps the frequently read data on the in-server flash cache to accelerate Oracle’s performance while storing the rest of the data out to whatever type of disk is presented to the application.

  • File System Read Cache. The file system read cache works in a similar manner as the volume manager read cache by keeping the most frequently read file system data in the in-server flash cache. However unlike the volume manager read cache, SmartIO gives organizations a number of options to define exactly what file system data should permanently remain on the in-server flash cache. Organizations may specify that an entire file system, an entire directory or even just a specific file on the in-server flash to expedite its read performance.
  • File System Write-Back Cache. Writing to in-server cache appeals to organizations as they can significantly accelerate the write performance of an application. The risk that companies have historically run is that when using write-back cache, if a server fails before the data is de-staged to disk, any written data residing on the in-server cache may be lost.

In-server flash retains data even should a server fail helps to mitigate the risk of data loss but it only partially addresses this concern with write-back flash cache. Even though data is theoretically safe using in-server flash, depending on the reason for the server failure, it can take a long time for the server to recover the data as in-server flash is not highly available. Using SmartIO plus Symantec Cluster File System organizations get write-back flash cache with high availability.

SmartIO provides two ways for organizations to implement it. First, an application write occurs to the in-server flash with SmartIO sending an acknowledgement back to the application that the write was completed. SmartIO then de-stages this data to disk at a later time (usually only moments later under normal conditions.)

Second, this write-back capability extends to the Symantec Cluster File System. In this scenario, as a write to the in-server flash of node A in a cluster occurs, SmartIO mirrors that write to Node B of that same cluster. The mirrored write completes before the write is acknowledged back to the application. In this way should node A of the cluster fail or go off-line, node B still has a copy of the data in its in-server flash cache and access to it so the application can continue functioning.

Using SmartIO, organizations realize a three-fold set of benefits. First, organizations may do targeted deployments of in-server flash without exposing themselves to the risk of having a single copy of data on the server. By keeping a permanent copy of data on a hard disk drive (internal, direct-attached or SAN-attached,) they can manage and protect this data using established backup practices.

Second, organizations get the performance benefits of in-server flash. Using SmartIO, organizations can realistically expect to achieve read IO response times in as fast as 50 microseconds (as compared to  2 milliseconds or longer using HDDs) and write IO response times in as fast as 150 microseconds (as opposed to 5 milliseconds or longer using HDDs.)

Finally, organizations may even opt to use in-server flash on a larger scale by deploying it in conjunction with Tier 2 storage arrays. In recent tests that Symantec conducted, it found that applications running with SmartIO and a Tier 2 array outperformed a more robust Tier 1 array.
SmartIO vs Array IO.JPGSource:Symantec

Storage Foundation with this new SmartIO feature functionality is immediately available for shops running Linux in their environment. Included with Storage Foundation, organizations may gain access to the SmartIO feature by either doing a net new install of Storage Foundation 6.1 or upgrading their current release of Storage Foundation to 6.1.

Yet despite all of these benefits that SmartIO offers in terms of enabling enterprises to effectively deploy and utilize in-server flash, it does not answer another common criticism of in-server flash: the inability to share unused or unneeded in-server flash capacity on one server with other servers in their environment. While SmartIO itself does not address that criticism, another feature called Flexible Storage Sharing (FSS) which is also found in Storage Foundation 6.1 does. DCIG covers that new feature included in Storage Foundation 6.1 in this separate blog entry.

Jerome M. Wendt

About Jerome M. Wendt

President & Lead Analyst of DCIG, Inc. Jerome Wendt is the President and Lead Analyst of DCIG Inc., an independent storage analyst and consulting firm. Mr. Wendt founded the company in September 2006.

Leave a Reply