SQL Server and the WFA: Part 1 - Lots of I/O

Posted by VIOLIN SYSTEMS on Jul 31, 2014 6:39:40 PM


As you probably already know, Violin Systems has announced all-flash arrays integrated with Windows Storage Server 2012 R2, dubbed the Windows Flash Array. If you’ve had a chance to give them the once over, it’s obvious that they are a far cry from a white box server with JBOD attached running Windows Storage Server.

The WFA is all about high throughput, consistent low latency, scalability, and balanced performance. It’s a true enterprise solution. Of course, this does not happen by generic technology combinations; rather it requires differentiated hardware, the tightest possible software integration, and solution-focused engineering with a vision to excel, or is that accel? Well OK, it’s both.

The unique performance of WFA is compelling for SQL Server workloads. For example, a common database application such as OLTP generates lots of random I/O, which makes sense as it’s driven by copious ad hoc inquiries from all across the enterprise. However, such a workload is a mismatch with legacy storage’s linear read/write focus. This results in high latency and poor application performance. Yet these queries are often associated with high-value real-time applications such as customer support, sales, inventory control, etc. As a result, storage professionals have tried their best to coax more performance from their cylinders of spinning rust but their success has been limited at best.

The Violin Windows Flash Array (WFA) combines Violin Systems’s patented Flash Fabric Architecture™ (FFA), Microsoft’s fast SMB Direct protocol, and Microsoft Windows Storage Server 2012 R2. That sounds very nice, but what does it mean? Look inside of a WFA, and you’ll note that there are no disks of any type (HDD or SSD). As a result, there is no need for striping techniques and optimization algorithms, nor is there a need to over provision storage or add cache to controllers in an attempt to garner enough I/O capacity. The FFA delivers fast consistent access to our all-flash storage so you don’t have to continuously monitor data hot spots and tune accordingly. In other words, it’s fast without your constant worry and attention.


How is fast is fast? Pretty darn fast. We did some SQLIO Load testing on a WFA-64 equipped with 56GBb FDR InfiniBand connectivity at a customer site; here’s the performance we observed:

The WFA delivered over 1.2 million IOPS on SQL reads. That’s up to 50% higher performance compared with an industry-standard all-flash array connected through Fibre Channel.

The WFA delivered 1.2 million IOPS on SQL writes, which was proportionally even more impressive. That’s up to twice the throughput compared with an industry standard all-flash array with Fibre Channel.

From these numbers you can see that the WFA is up to the task of delivering the sustained performance for short block random read/write workloads. And, there is no ongoing tuning required. But did you know that this performance was achieved over a file-based solution, not block?

The WFA delivers DAS-like performance due to its support for SMB Direct, also known as SMB over RDMA. You can have simplicity of a file-based environment but without sacrificing the performance you’re accustomed to with block-based solutions. The advantages of file over block can fundamentally change your ease of use and efficiency. So much so, this is worthy of a discussion of its own; we’ll dive in depth on this in a future blog.

From an I/O perspective, we can do a lot in 3U to boost your SQL Server performance. But just attaining a high IOPS number does not guarantee balanced performance for a mix of multiple workloads. Achieving consistent low latency is essential, as this will transform how your SQL database and related apps perform, and your expectations! We’ll continue on this theme the next time.


Learn how Violin and Microsoft collaboratively optimized this solution to leverage WFA’s unique performance profile so you can run your SQL Server environment in a Flash.

For more information on the WFA and SQL Server, download our solution brief.

> NEXT: Part 2 of SQL Server and the WFA — Latency Matters

Topics: Databases, Products, SQL