Server-side caching or tiering systems essentially augment hard disk drive (HDD) performance; they don’t replace disk drive arrays. This means they need to run a process to analyze and determine which data sets should be on flash and then move those data at the appropriate time. The net effect of these processes can be increased system complexity and reduced overall performance.

For tiering systems, this analysis is typically applied only after data’s been written to the HDD tier and can involve a “warming” period where multiple accesses are analyzed. Moving those data at the appropriate time also creates storage controller overhead, especially on the hard disk array that it’s supporting.

But there’s another issue: flash endurance. As we covered in the first blog post of this series, “Server-side flash implementation explainer,” flash memory can support a finite number of write and erase cycles. The data turnover of caching or tiering consumes more of these cycles, shortening the effective useful life of flash devices.

All-flash arrays are an alternative to caching and tiering systems that can address these issues.

All-flash arrays are complete storage systems with storage controllers, modular flash capacity and storage services (RAID, snapshots, cloning, replication, etc.). They also can support multiple storage protocols — either block storage or both block and file storage. They use storage controllers that are designed for flash’s performance, breaking free from the limitations of putting flash in legacy disk arrays that used HDD controllers designed around the latency of spinning disk drives.

These modular systems implement like traditional disk arrays, providing data centers with flash performance without the complexity and potential side effects of caching or tiering. They also leverage flash’s performance to bring acquisition costs closer to that of the high-performance HDD arrays they’re replacing.

All-flash arrays also include data reduction technologies like thin provisioning, deduplication and compression to decrease the amount of capacity they need to store a given data set. Unlike HDD arrays, flash-only systems have plenty of performance to accommodate the CPU load of these processes. This can bring typical data reduction rates up to 10 times or more, driving down their effective cost per gigabyte. When compared with the disk drive arrays they’re replacing, typically high-performance SAS or Fibre Channel systems in high-spindle-count configurations, flash-only arrays can be more than cost-competitive.

Nimbus Data Systems was one of the first on the market with an all-flash array but has been joined more recently by others, like Pure Storage. All-flash systems are not for every environment but are certainly a product that should get serious line-card consideration for VARs interested in embracing flash as part of their storage go-to-market strategies. As a disruptive alternative to legacy high-performance storage arrays, they can be an ideal way to get into a new account or unseat an incumbent vendor.

Follow me on Twitter: EricSSwiss

Flash is getting more affordable but is still several times the cost per gigabyte of hard disk drives (HDDs). Because of the cost disparity, it’s often used to augment HDD performance: The more performance-critical data sets are placed on flash, sometimes temporarily, to take advantage of its orders-of-magnitude better performance, especially IOPS.

Read caching involves placing a copy of the most frequently used data objects into SSD to speed access times by applications or users. When data’s changing, it’s more complicated (write caching) since the primary data set must be kept updated and writes must be protected against system failures until they’re committed to nonvolatile storage. But there are algorithms that can do this too, as part of the OS or application or as a part of a PCIe card that houses the flash storage itself.

Caching can be the simplest to implement, since it leaves the primary copy of data intact on existing disk storage, often operating transparently to the application. It can also be implemented with a relatively small amount of SSD capacity, since data can be moved into and out of the cache area rapidly.

Tiering is like caching except it involves moving an entire application or data set into cache and then copying back to primary storage when the period of high activity is over. For this reason, tiering typically requires more SSD capacity than caching and may involve configuration changes to the application.

Server-side flash implementations can be done with PCIe flash devices, which can have up to a terabyte or more of flash capacity and may include caching software as well. Flash can also be in SAS or SATA drive form-factor packages, which plug into 3.5-inch, 2.5-inch or 1.8-inch drive slots. There are also SSDs that plug into an empty DDR3 memory slot on the motherboard and connect via a SATA cable.

Server-side flash is dedicated to the server it’s installed in, meaning less flash capacity is required than with array- or network-based flash devices and implementation is simpler than in those shared storage scenarios. Although flash capacity is significantly more expensive than HDDs, SSDs caching or tiering can actually provide a lower-cost alternative, with better performance.

For VARs, server-side SSD implementation can be an ideal way to break into a new account or capture new business in an existing account that’s currently going to an array vendor. Whether implemented as a cache or tier or just a high-performance storage area, server-side flash can provide an immediate solution for a slow application.  For other use cases, an all-flash array or flash appliance may be a better alternative. We’ll look at those in another post.

Follow me on Twitter: EricSSwiss