SAN Cache: SSD In The SAN - Technology Information

Computer Technology Review, April, 2000 by Michael Casey

For many transaction-intensive applications, it is possible to identify a small set of files that consume most of the I/O activity and place those files in a high-performance cache. This approach typically uses Solid-State Disk (SSD) for file caching and increases overall transaction performance by a factor of 200% or more on the existing servers.

File caching differs from block caching in several respects. RAID cache--"block caching" in a RAID controller--is based on data blocks. Each block is identified by a SCSI block address (for example) and the RAID controller has no knowledge of which blocks are part of which file. It chooses what to cache (and what to flush from cache) based on historical usage statistics on the individual blocks (or disk tracks, in the case of EMC). The caching algorithm looks at the usage history and tries to determine what will be needed next by the application. Since the controller cache is much smaller than the total amount of data stored on the disk drives, only a small percentage of the data can be kept in the cache. A given data block may reside in cache for only a few seconds or minutes before it is flushed from cache.

The effectiveness of block caching depends on the application and, usually, an application will reach a point of diminishing returns--a point where adding more cache will not deliver much additional performance improvement. Once the application reaches that point, the next step is to start caching entire files based on an understanding of application structure.

File caching depends on an understanding of the application structure--the identification of "hot files." Once the hot files have been identified, selected files are moved to the file cache--as a policy decision, not a statistical extrapolation. The hot files may reside on the SSD for days, weeks, or months. The "hit ratio" on data in the file cache is always 100%, since the entire file is always in the cache and available for access.

Two conditions are necessary to make solid-state file caching a good bet: (1) the application server must be I/O bound; (2) the I/Os must be skewed: a small percentage of the files must drive a large percentage of the I/O activity. For example, in many e-mail and messaging applications, the message queues represent a high percentage of the total I/O on a small percentage of the data. They are also very write-intensive files. This skewed I/O distribution is a feature of the application design and, thus, the application is a good fit for architectural adoption of solid-state file caching. Typically, a small, I/O-intensive fraction of the data is moved from cached RAID to a separate, non-volatile file cache.

In suitable applications, addition of a solid-state file cache to an existing server configuration can boost throughput by a factor of four or even eight. This enables the system administrator to deliver the required performance and service levels without purchasing and managing several additional servers and their associated storage.