Delphix – Defender of your SAN

One of the less obvious advantages of database virtualization is a reduction in the read I/O issued against the underlying physical storage (henceforth called “the SAN”) that ultimately stores the data for virtual databases.

In practice, Delphix prevents around 60% of all non-production database I/O from ever being issued to the SAN with the Delphix cache.

This is possible because Delphix Server accommodates large amounts of RAM, which is used as an auxiliary cache above and beyond the database buffer cache that resides on the database server.  When the database needs to read some data that is not present in the database buffer cache, an I/O is issued to the Delphix Server. Delphix then checks its own cache, and only passes the I/O request down to the SAN if the necessary data is not already in the Delphix cache.

Delphix cache hits bring dual performance benefits:

• Virtual databases I/O service times for reads are fast: in the range of a few hundred microseconds plus network latency.  These ~1 millisecond latencies are 5-20 times faster than traditional SAN random read access times.

• By serving these I/O requests from Delphix cache, the load on the SAN is reduced

Delphix’s minimum system configuration requires 16 GB of RAM, however most customers configure their Delphix Servers with 64 GB or more.  Thanks to these large caches, Delphix Servers consistently have a 60-70% cache hit ratio.

In the last two years, I’ve collected database I/O statistics from 469 production and non-production Oracle databases across 25 companies in a variety of industries and with diverse applications.  Studying these statistics gives the following findings for this particular sample:

• Non-production databases account for 70% of all databases

Focusing on these non-production databases, which are the first candidates for database virtualization:

• Reads accounted for 87% of database I/O, writes for only 13%.

• Grouped by company, the highest read proportion observed was 97%, the lowest 61%

• With Delphix’s typical 60-70% cache hit ratio, this means full virtualization of non-production environments would eliminate between:

  • 52.2 and 60.9% of total database I/O from the SAN

To give those findings a sense of scope, in the two years I’ve been working at Delphix, eliminating 60% of non-production I/O would amount to eliminating 59 petabytes of I/O.

To put that into perspective, Amazon Elastic Block Store charges $0.10 per million I/O requests.  Assuming an average I/O request size of 8 kilobytes it would cost you around $800,000 to do 59 petabytes of I/O in Amazon EBS.

That’s a truckload of I/O – literally: it takes around 120 milliwatt hours of energy to read 256 megabytes of data from disk, reading 59 petabytes would require around 29 megawatt hours – roughly equivalent to the energy in 2.55 tons of oil (or 25 tons of TNT if that’s more your style).

By using inexpensive server RAM as a secondary cache for virtual databases, Delphix can dramatically improve database read I/O performance, and eliminate 50-60% of non-production database I/O from the SAN.  This improves performance of virtual databases, and allows other applications to get more out of a shared SAN.

Footnotes:

* Delphix eliminates around 60% of I/O associated with the operation of non-production databases.  It also eliminates huge amounts of I/O on both production and non-production systems formerly used to create, copy, and restore full backups – although this is not quantified in this blog post.

** The upper bound on RAM assignable the Delphix Server is constrained by limitations of the hypervisor or underlying physical host long before it approaches limits inherent in the Delphix OS.

*** https://en.wikipedia.org/wiki/Tonne_of_oil_equivalent, https://en.wikipedia.org/wiki/Tons_of_TNT