Demartek Evaluation of Violin Flash Storage Platform … · AFA Testing Guidelines The goal of the...

demartek.com © 2016 Demartek

November 2016

Evaluation of the Violin Flash Storage Platform

7650

This storage system delivers consistent low latency.

Executive Summary

Large enterprises choose all-flash arrays to power their

most demanding workloads, including online transaction

processing (OLTP), big data analytics and dense

virtualization deployments. Many enterprises are now

specifying all-flash arrays as the first choice for new

storage arrays, as these all-flash arrays have become the

enterprise storage workhorses for a variety of

workloads.

Violin Memory commissioned Demartek to evaluate its

Flash Storage Platform 7650 with synthetic and real-

world workloads. We measured the performance of this

new storage platform with a special focus on IOPS and

latency, especially noting the performance while

maintaining low latency.

Our tests included a combination of synthetic workloads

with single-block sizes and mixed-block sizes for read

and write workloads. These tests were based on the

guidelines described in the “IDC AFA Performance

Testing Framework”1 that describe an initial fill, pre-

conditioning, basic workload and “soak” tests.

We pushed this storage system until the latencies began

to significantly climb. All of our measurements were

taken at the host servers running the tests.

1 IDC AFA Performance Testing Framework,

http://idcdocserv.com/AFA_Performance_Testing_Framework_I

DC_251951, accessed September 1, 2016

Key Findings

> The Violin Flash Storage Platform 7650

maintained sub-millisecond latency (measured

from the host application server) as it

approached two million IOPS in our 4K block

100% read tests.


maintained sub-millisecond latency (measured

from the host application server) as it

approached one million IOPS in our 8K block

100% read tests.


maintained low latency for the mixed block size

tests even as we pushed the queue depth to as

high as 700.

http://www.demartek.com/

http://idcdocserv.com/AFA_Performance_Testing_Framework_IDC_251951

http://idcdocserv.com/AFA_Performance_Testing_Framework_IDC_251951

Evaluation of Violin Flash Storage Platform 7650


Violin Flash Storage Platform 7650

The Violin Flash Storage Platform 7650 is an all-flash

array that uses the Violin Flash Fabric Architecture and

the Violin Intelligent Memory Modules (VIMM). The

Violin Flash Storage Platform 7650 is designed to

maximize performance while maintaining consistent

low-latency for a variety of workloads.

The Violin Flash Storage Platform is available in three

models, with the model numbers representing the

maximum raw capacity in terabytes.

> FSP 7650-26

> FSP 7650-70

> FSP 7650-140

Enterprise-class features available on the FSP 7650

include data at rest encryption, asynchronous

replication, thick and thin provisioning, snapshots and

thick and thin clones. The FSP 7650 also supports

consistency groups.

The FSP 7650 comes with eight ports of native 16 Gb

Fibre Channel or eight ports of 10 Gb iSCSI in a 3 rack

unit (RU) system. The model we tested included eight

Fibre Channel host ports.

AFA Testing Guidelines

The goal of the all-flash array testing guidelines is to

demonstrate the type of performance a flash storage

system can produce after it has been in use for a while.

This is because the flash storage “fresh out of box”

experience on unused NAND flash performs much

better initially because no garbage collection is

required. However, after a flash storage system has had

data written on it and had a chance to “age,” the normal

background processes including garbage collection will

begin to be executed. This results in a relatively steady

level of performance that can be expected on a regular

basis. This steady state performance is lower than the

fresh out of box performance.

The testing we performed included the following steps:

> Pre-fill

> Aging

> Individual workload tests, 4 – 7 hours each

> Soak tests – 4 x 12 hours, 48 hours total

The individual workload tests included a combination of

block sizes and read/write ratios all while incrementing

the thread counts until the latency reached

approximately two milliseconds.

The soak tests were a continuous series of individual

workload tests concatenated together for 48 hours.

Corner Cases

We also ran some tests that isolated corner cases in

order to determine some maximum performance

numbers. We ran these in a similar fashion as the

individual workload tests described above, but only for

specific I/O parameters and thread counts.

Workload Environment

All the Vdbench tests were run with Vdbench 5.04.06 on

CentOS 7.1 across 32 physical LUNs.




Test Results – Corner Cases

The corner case workloads highlighted the maximum

performance possible under very specific conditions.

Violin makes various IOPS claims at different latencies,

and our test results are consistent with those claims.




Test Results – Mixed Block Sizes

For the mixed block size tests, we used the following

combination of block sizes:

For these tests, we ran the following sets of I/O

parameters with the mixed block sizes:

> Random I/O, 35% read (65% write)



> Sequential I/O, 20% read (80% write)



Running each test at least four hours, we increased the

thread counts, forcing the queue depth to increase, until

the latency began to climb significantly, as measured by

the host application server.

For each set of mixed-block workloads, we show:

> Response time vs. IOPS

These metrics provide a good measure of the strength

of the storage system with respect to IOPS and latency.

By increasing the thread counts, we increased the

queue depth, putting an increasing load onto the

storage system. As expected, as the queue depths

increased, the IOPS increased and the latencies

increased.

Response times shown include the average response

time, which is an average of the read and write

response times. We also show the read and write

response times separately.

These workload test results are the baseline workload

results after several hours of preconditioning.




Random 35% Read

Random 50% Read

Random 90% Read

Sequential 20% Read

Sequential 50% Read

Sequential 80% Read




Oracle Database OLTP Workload

In addition to synthetic workloads, it is important to test

new storage systems with real-world applications

running in their native environments to see how

perform, because these are the environments that

customers have.

One of these real-world environments uses the Oracle

12c database running on the Linux operating system.

Oracle Database 12c is an enterprise database

management system (DBMS) that delivers performance,

scalability, high availability, data optimization, data

security and ease of management to support the most

demanding online transaction processing (OLTP), Data

Warehousing and Big Data requirements.

We ran an Oracle database OLTP workload simulating

an order-entry environment that has a variety of

transaction types and multiple tables in its database.

The transactions performed include typical database

functions of insert, update and delete across the

database tables. This workload is good for highlighting

IOPS and latency, and it has a read/write ratio of

approximately 75% read and 25% write.

The best practices are for the database files to be placed

on different storage volumes than the log files. This

practice aids in recovery of the database in the event

that one storage volume is lost. The required capacity

for the log files is usually relatively small. For these tests,

the combined size of the database and log files was

approximately 1 TB spread across one logical volume

for the database and a separate logical volume for the

log files.

This OLTP workload was run three times, each with a

different number of simultaneous database users. The

number of users is a measure of the load on the

system.

The OLTP workload test was run for 30 minutes (1800

seconds) for each of the users settings (25, 50 and 60

users). The best performance in this configuration was

with 60 database users. As we increased the user count

above 60, we observed a lower transaction per minute

rate and what appears to be a bit more thrashing in the

host CPU.

We limited the amount of memory available to the

Oracle database to 15 GB. This reduced the amount of

data that the database could place in cache, forcing

more I/O activity out to the storage system under test.




Oracle Database Latency Results

The Violin Flash Storage Platform 7650 provided very

good latency and very consistent latency.

Latencies shown are for read and write activity to the

database files, separately and combined.

Occasionally, database

applications perform

checkpoints or other

functions that can briefly

affect latency, sometimes

positively and sometimes

negatively.




Test Environment

Servers (load and database servers)

> Vdbench master:

2x Intel Xeon E5-2670v3, 2.3 GHz, 24 total

cores, 48 total threads, 384 GB RAM, 4x 16GFC

host ports,

CentOS 7.1.1503, Vdbench 5.04.06

> Vdbench slave-1:

2x Intel Xeon E5-2683v3, 2.0 GHz, 28 total


host ports,

CentOS 7.1.1503, Vdbench 5.04.06

> Oracle database:

2x Intel Xeon E5-2690 v2, 3.0 GHz, 20 total


host ports,

Oracle: Oracle 12c on Oracle Linux 7

Fibre Channel Switch

> Brocade 6510 16GFC Switch, 48 ports

Storage System

> Violin Flash Storage Platform 7650-70

> 44 TB usable capacity

> 8x 16GFC target ports




Summary and Conclusion

We found that the Violin Flash Storage Platform 7650

was a very strong performer, achieving consistently low

latency in a variety of workloads with single block sizes

and mixed block sizes. The mixed block sizes represent

block sizes found in real-world applications. This low

latency was also observed with the Oracle database

OLTP workload.

For the single block size tests, the Violin Flash Storage

Platform 7650 achieved the best IOPS and latency

results we have seen in our lab for a SAN-attached all-

flash array.

For the multiple block size tests, the Violin Flash Storage

Platform 7650 achieved consistently low latency even as

the workloads were pushed to high levels.

As customers move towards an all flash datacenter, we

recommend that customers consider the Violin Flash

Storage Platform 7650 for their storage needs.

The most current version of this report is available at www.demartek.com/FSP7650 on the Demartek website.

Violin Memory is a registered trademark and Flash Storage Platform is a trademark of Violin Memory, Inc. in the United

States and/or other jurisdictions.

Demartek is a registered trademark of Demartek, LLC.

All other trademarks are the property of their respective owners.


http://www.demartek.com/FSP7650

Demartek Evaluation of Violin Flash Storage Platform … · AFA Testing Guidelines The goal of the...

Documents

Transcript of Demartek Evaluation of Violin Flash Storage Platform … · AFA Testing Guidelines The goal of the...