Generally, the probability that needed data will be immediately available improves as you increase the amount of RAM as well as the size of the cache. Sooner or later, however, a fetch to the storage subsystem will be required to get needed data.
Even with more SSD cache, it is still somewhat a matter of fortunate timing if the data is cache-resident when needed. To optimize performance, software intelligence is needed to increase the odds that needed data is available. SSD software products accomplish this by using sophisticated algorithms that detect what data is “hot” and move it from HDD systems to the cache and make sure that it stays there until something hotter comes along. This software is installed on the server itself.
SSD software vendors almost uniformly claim an improvement from 5X to 10X in performance over using SSD cache alone. These products are marketed as simple to install, easy to use and hardware independent. Beyond that, differentiation evolves rapidly.
Some products can be described as general purpose in nature, such as FlashSoft’s FlashSoft SE product (now owned by SanDisk). FlashSoft SE elevates data based on access patterns. This is contrast to Nevex’s CacheWorks “selective optimized caching,” which seeks to elevate data based on “popularity,” not most recently accessed. That is, data accessed thousands of times would not be bumped by data accessed just a few times, even though recent access might make the latter appear “hot.” Velobit’s HyperCache differs further with a block-level caching algorithm. Some blocks may be common to multiple files, and HyperCache seeks to elevate these blocks rather than whole files.
For all of the strength of SSD technology related to read operations, it is notoriously poor on write operations. Velobit minimizes the need for writes using compression and its block-level caching as well as allowing user settings for write activity thresholds. FlashSoft uses a “circular buffer design” to write sequentially to cache.
Because a large amount of data can be resident in SSD cache, failover, and data integrity protection are paramount. These issues can be complicated by virtual machine failover, cache rebuild times, and the like. It is important for IT users to match their data failover architecture with the vendor’s capabilities.
The driving force behind SSD software designs is the intended use cases. The use cases determine the assumptions made during product engineering. Looking at the use cases that vendors cite on their web pages and relating them to the situation at hand will assist in selecting the appropriate product, or at least creating a short list.
Users who need better processing performance and suspect I/O contention is a problem can get started evaluating SSD software products using the following checklist:
- Start with the basics. Determine which products support your environment, and whether they include Windows, a hypervisor, or Linux.
- Know your application mix. If high-write activity occurs, a product that optimizes write performance may have an edge.
- Examine use cases. Determine which vendors support the way you will be deploying the product.
- Consider data integrity. Learn how the products you are interested in manage data integrity and failover to assure that they will meet your SLAs.
- Try before you buy. Most vendors offer downloadable trial versions and there’s nothing like seeing it to believe it. You’ll learn a lot about ease of use, performance, and technical support.
Most SSD software is SSD hardware-agnostic, but not all, so be sure to check this compatibility as well.
Phil Goodwin is a storage consultant and freelance writer.
This story was originally published on SearchSolidStateStorage.com.
This was first published in March 2012