About a year and a half ago OCZ announced the acquisition of Sanrad, an enterprise storage solutions company with experience in flash caching. Today we see some of the fruits of that acquisition with the announcement of OCZ's first SQL accelerator card: the ZD-XL. 

Enterprise accelerator cards are effectively very high performance SSD caching solutions. Some enterprise applications and/or databases can have extremely large footprints (think many TBs or PBs), making moving to a Flash-only server environment undesirable or impossible. The next best solution is use a NAND based SSD cache. You won't get full data coverage, but if you size the cache appropriately you might get a considerable speedup.

OCZ's ZD-XL is specifically targeted at servers running Microsoft SQL. Although technically the solution caches all IOs to a given volume, OCZ's ZD-XL software is specifically tuned/optimized for SQL server workloads. The ZD-XL only supports a physical Windows Server environment, OCZ offers a separate line of products for accelerating virtualized environments.

The ZD-XL SSD itself is based on OCZ's Z-Drive r4, featuring 4 or 8 SF-2000 series controllers on a single PCIe Gen 2 x8 card, depending on capacity. OCZ doesn't make the NAND or controller, but the card is built in-house. The ZD-XL implementation comes with a custom firmware and software solution, courtesy of OCZ's Sanrad team. The architecture, at least on paper, looks quite sensible.

The ZD-XL card comes with a special firmware that enables support for the ZD-XL software layer, preventing Z-Drive r4 owners from simply downloading the ZD-XL caching software and rolling their own solution. The software layer is really where the magic happens. All IOs directed at a target volume (e.g. where your SQL database is stored) are intercepted by a thin driver (cache splitter) and passed along to the target volume. An out-of-band analysis engine takes a look at the stream of IOs and determines which ones are best suited for caching. Frequently accessed data is copied over to the ZD-XL card, and whenever the cache splitter sees a request for data that's stored on the ZD-XL it's served from the very fast PCIe SSD rather than from a presumably slower array of hard drives or high latency SAN.

The analysis engine supports multiple caching policies that it can dynamically switch between, depending on workload, to avoid thrashing the cache. There's even cache policy support for deployment in a SQL AlwaysOn environment.

OCZ's software supports automated pre-warming of the cache. For example, if you have a large query that runs between 9AM and 11:30AM every day the ZD-XL can look at the access patterns generated during that period and ensure that as much of the accessed data is available in the cache as possible during that time period. 

OCZ's ZD-XL can be partitioned into cache and native storage volumes. In other words you don't have to use the entire capacity of the card as cache, you can treat parts of it as a static volume (e.g. for your log files) and other parts of it as a cache for a much larger database. 

The large capacities OCZ offers with the ZD-XL (600GB, 800GB, 1.6TB) will likely help ensure good cache utilization, although there's no pre-purchase way of figuring out what the ideal cache size would be for your workload. This seems to be a problem with enterprise SSDs in general - IT administrators have to do a lot of work to determine the best SSD (or SSD caching) solution for their specific environment, there aren't many tools out there to help categorize/characterize a workload.

OCZ published a white paper showing performance gains for simulated workloads with and without the ZD-XL accelerator. In all of OCZ's test cases the improvements were tremendous, which is what you'd expect when introducing a giant PCIe SSD into a server that previously only had big arrays of mechanical hard drives. Queries complete quicker, servers that aren't CPU bound can support more users, etc... 

Just as we've seen in the client space, SSD caching can work - the trick is ensuring you have a large enough cache to have a meaningful impact on performance. Given that the smallest ZD-XL is already 600GB, I don't think this will be an issue.

The only other requirement is that the caching software itself needs to be intelligent enough to make good use of the cache. OCZ's internal test data obviously shows the cache doing its job well in caching very long queries. Building good caching software isn't too difficult, it's just a matter of implementing well understood caching algorithms and having the benefit of a large enough cache to use.

The ZD-XL is priced at $7800, $9800 and $15,200 for 600GB, 800GB and 1.6TB capacities. The prices include software and drivers.