Are you an SSD?

Violin Memory took a “blank piece of paper” approach to flash memory aggregation and developed a flash Memory Array aimed squarely at enterprise application acceleration. SSD vendors are limited to the form factor and protocols of HDDs and performance is adequate for laptop computers. PCIe SSDs expose more of the performance but lock it in a single server with no clear way to scale. Violin took a “systems approach” and designed a system for the 7x24x365 enterprise datacenter without any of the sustainability problems or latency spikes encountered when trying to use SSD’s in enterprise applications.

Who are your customers?

Anyone who is stacking servers to get as much I/O out of their performance storage (SAN, DAS, etc) as possible.  Do you want 20 servers running at five percent utilization or 3 running at eighty percent?  That is the kind of server compression and application acceleration possible using an enterprise class flash Memory Array.

Why not just use a PCIe Flash card?

The biggest reason is that these are not highly available products; no matter what the SSD vendor does they cannot provide access to the data if the server that’s powering it is down. This generally forces customers to synchronously mirror their writes to another card in another server resulting in double the cost and high write latencies. When a card or server does fail the mirror must be recreated on a new device, creating a huge write spike over the network that must be completed before normal performance can be restored.

The next reason is that cards don’t scale very far in terms of capacity; 800GB is typically the largest form factor because these cards are power limited by the PCIe standard.

Finally, these cards are subject to the write cliff, making their performance unpredictable.

What is the write cliff and why do I care?

With all Flash devices you can only write to areas that have previously been erased, except when you start with a new card. To make their product look better many vendors quote write performance based on the first few minutes of a card’s lifetime, even though this can only be sustained for a short time before write performance “falls off the cliff”. Once the card has been in use, the lower write performance is what you will see for the remaining years of its lifetime. Violin has patent-pending technology that prevents the write cliff; our write performance stays the same for the lifetime of the product.

What applications benefit the most from Violin?

Any application that generates high random read/write IOPS will benefit greatly from using Violin. Oracle, SQLServer, MySQL, and DB2 are just some of the databases that Violin has accelerated to record breaking performance levels. Violin is also very powerful as the storage layer behind the BigData file systems like GPFS, again yielding recording breaking performance. In virtualized environments where multiple VMs are collocated on physical servers, the IO mix is generally highly random and performance is greatly improved by using a Violin memory array.

I’ve heard that Flash wears out, how long will this array last?

The Violin SLC memory array is designed to allow the entire array to be written every hour of every day for 10 years. The MLC version is designed to allow the entire array to be written every day for 5 years.

What do you mean by Enterprise Class?

The system must be reliable with all data are RAID-protected against card, chip, die, or even cell level failures. The system must be highly availability with 5 nines being the Enterprise class standard, built in spares add greatly to delivering this guarantee. The system must be serviceable with all parts being hot swappable.

Why not just use Flash as a read cache in front of spinning disks?

Flash caches do not provide predictable high performance, some read IO is fast and some is 100x slower. Even infrequent cache misses are going to dominate your application performance and create visible stalls. If you try to size your cache to hold the entire application working set there is still the ever increasing cache warmup time; a 1TB cache will take at least 30min to warm up and you pay this penalty on every cache reset and every working set change. Finally, caches do nothing to help write performance. Violin arrays address both sides of the problem and have predictable performance from the start.

Why is I/O latency important?

Most applications have pieces of software which are single threaded; a particular process must complete a sequence of operations before other process can continue or start. If these operations include I/O operations, it’s very common for the application performance to be severely impacted by I/O latency (or response time). If the latency drops from 5ms to 0.5ms, there can be a 10x acceleration of the application. Instead of doing an I/O every 5ms (200 IOPS), the process can do an I/O every 0.5ms (2000 IOPS).

Does flash memory guarantee low latency?

Most flash memory or SSD vendors tout the low latency of doing a read from a flash memory device. It takes only 0.050ms compared with a typical 15K HDD of 4ms. However, if an SSD is put into an enterprise storage array, the latency is typically greater than 2ms. The discrepancy comes from two primary sources;

1. The enterprise storage array adds latency through RAID controllers and shelf interconnects and caching controllers.
2. Flash memory has higher latencies under load. Writes (Programs) and Erases typically take 0.4ms and 2ms. If a Read is queued behind these, the Read takes 2ms or longer.

Violin has a patent-pending RAID algorithm which eliminates Erase latencies (spikes) and minimizes the RAID, caching and shelf interconnects. Latencies between 0.1ms and 0.5ms are normal with no millisecond spikes.

How is this better than disk arrays with tiering?

Tiering solutions have many of the same problems of using Flash as a read cache. Read performance is still unpredictable and depends on how good the tiering software is at predicting future reads by past behavior. Write performance can be very good but is subject to multiple write cliffs; as the higher tiers fill up the write performance drops off like a stair case. What’s needed by applications is predictably high read/write performance.

What’s better for my applications, SLC or MLC?

SLC is fundamentally faster than MLC, an SLC-based array provides about 5 times the IOPS per terabyte and its IO latency is about 3 times better. SLC is also better for applications that have very high write rates relative to the entire size of the array because it doesn’t wear out as fast. On the other had MLC-based arrays have twice the density so for higher capacity per rack U, MLC is the way to go.

Contact us