Taking a Different Look at Performance for vSphere Storage Appliance

I've been working with and doing performance testing with the new vSphere Storage Appliance (VSA) for most of this year.  The white paper was published last week and I encourage you to read it if you are interested in getting a deeper understanding of VSA.

I've also done a lot of performance work with Oracle RAC, SAP, and SQL Server this year, and there is a big difference between that and VSA testing.

When testing with big databases and the applications that go along with them, the storage requirements to achieve the needed performance levels are usually pretty high.  I've used big EMC, NetApp, HP Lefthand, and Dell Equallogic storage to support thousands of IOPs while maintaining low latency.  In these tests we are analyzing the storage usage in each test to ensure that we get the performance that we need. These big storage systems are necessary to meet the requirements of the applications being tested.

VSA is designed to be a simple to install, simple to use, and simple to manage storage solution for small environments.  It can be the first "SAN" for environments where it was not possible to have a SAN before.  It is not designed to support or be used with the types of workloads at the stress levels that I normally test with.  So approaching a performance study of VSA required something different.

Instead of trying to push as many IOPS as possible or getting as many users as possible, I focused on providing some insights into the key factors of VSA performance.  This includes a couple of test scenarios designed to show two different things.

The first used the VMmark2 workload to show that enterprise apps can run with good performance on VSA.  Specifically, it showed that Exchange, a webstore front and backend, and a Java based interactive website could all run very well, at the same time, while supporting the workload equivalent of over 1000 users.

The second test used IOBlazer (a cool and easy to use IO generator tool) to show how the VSA's Network RAID (or replication) traffic impacts the performance across the cluster as load is spread across the VSA cluster. This test illustrates how as you put load one datastore the network RAID that is ensuring the data is always available causes some load to also occur on a secondary node in the VSA cluster.  The graphs are cool in this section.

I think that most customers will probably not need the additional performance information that I have included with these scenarios because of how easy VSA is to use and manage, but it will help those that are interested in getting a more advanced understanding or want to get into a more detailed level of performance monitoring.  Most will not have need for this additional detail, but many geeks like me will be interested anyway.

So this approach is a bit different from the usual type of performance work that you see.  This isn't the million IOPS test or an Oracle RAC performance study.  It's meant for a different environment.  One that is getting it's first taste of shared storage and cool things like vMotion, DRS, and HA.

Todd