Solving Storage and Application Performance Issues

… and bridging the chasm between infrastructure and applications teams. One of the reason why people choose to run Pure Storage arrays it because it solves performance issues and in my experience there are 3 types of performance issues that can arise in a storage environment that I describe as “storage-centric”, “application-centric” or “service delivery” […]


… and bridging the chasm between infrastructure and applications teams.

One of the reason why people choose to run Pure Storage arrays it because it solves performance issues and in my experience there are 3 types of performance issues that can arise in a storage environment that I describe as “storage-centric”, “application-centric” or “service delivery”

In this first post on the topic of performance issues, I would like to discuss the first 2 types and the people they impact…

Edit : the second post on this topic is available here, where I discuss service-delivery performance issues and how Pure can help enabling Private Clouds

Storage-centric performance issues

Storage-centric performance issues are visible by the infrastructure team. The storage administrators can observe high latencies at times (or all the time!) and are usually the result of the workload having increased past what the storage array was sized for. These issues will of course have an impact outside of the infrastructure team (the applications will slow down) but my benchmark of classifying a performance issue as “storage-centric” is that the storage administrator will say “yes, there is a performance issue

These issues can arise because predicting the future is very hard. For example your storage array might have been sized for a 20% increase in IOPS year over year and the truth might have been closer to 50%. Then suddenly after a year and a half you suddenly find yourself with an undersized storage array and very visible storage performance issues.

Or it might be that a change in the requirements makes the performance of your current storage system simply not enough. For example you might have started a VDI project (which can put a lot of strain on disk storage systems) or your company might have acquired other companies and the number of users / IOPS required simply doubled overnight.

These issues usually have a simple solution : increase the number of IOPS that the storage system can handle (or replace the storage system by one which can handle more IOPS). The challenge is that with disk storage arrays, the spinning disks ends up being the bottleneck in terms of (random) IOPS. Depending on the type of disk and how you count, you might get 150 to 250 IOPS per disk. Suddenly, these 20000 IOPS for this new VDI environment might not be an easy requirement to satisfy!

Obviously a Flash array will help : Flash arrays support hundreds of thousands of IOPS, making these IOPS challenges simply go away. Of course it doesn’t mean that by going to a Flash array you will remove all bottlenecks, it simply means that your new bottleneck will not be storage related! When removing a bottleneck, you simply find out what the next bottleneck is…

For example a customer of ours had a portfolio management system that would not scale past 150 users because it was limited by the storage system. By moving this application (and all other applications actually) to a Pure array, they have been able to increase the scalability of the application by 4x (it can now support up to 600 users)

Application-centric performance issues

Application-centric performance issues are usually more controversial : the application owner will typically blame the storage system for his application performance issues, but the storage administrator will argue that everything is working fine as far as he is concerned. The storage system is behaving normally, with no visible sign of having reached a bottleneck. The performance tools provided by the storage vendor show green lights everywhere, but the users are still unhappy…

This is the sort of issue that often impacts decision support systems / analytics, and translate into a simple statement : “I cannot provide data fast enough and/or often enough to my business users“.

These issues can create a chasm between the infrastructure teams and the application teams : the application teams and DBAs can clearly see that their servers spend a lot of time waiting for data to be served by the storage hardware, but when they ask the infrastructure team to solve the issue, they are being told that everything is working as expected and that maybe they should optimise their applications or queries…

And this is where the infrastructure team is right : everything is working as expected… because disk latency can be expected to be slow.

Yes, the main culprit here is (almost always) latency. It simply takes too long (several milliseconds) to read data from a spinning disk.And when this disk is used by multiple applications it gets worse : mixing different workloads on the same disk and increasing the range of the data the disk needs to fetch will result in this latency simply going up, with the performance of the application usually decreasing proportionally with the latency increase.

An All-Flash array here will help thanks to the consistent low latency it delivers. Low latency is just natural to Flash. Moreover, there is no difference between a random read and a sequential read as far as the media is concerned, so the latency will not increase just because of IO locality issues.

We have countless examples of customers who migrated their applications on Pure Storage FlashArrays and suddenly experienced an improvement of 5x to 20x in how fast they can make data available to the business users, or calculate a result that the business needs to operate.

For example a customer of ours had a weekly tasks essential to their business that took 24 hours to complete. By moving the application to a Pure array and without changing anything at the application level, they have been able to reduce the time to complete this task down to 4 hours, enabling them to run it on a daily basis rather than on a weekly basis.

More importantly, where a Pure Storage FlashArray will help (as opposed to any Flash device) is that there is no tuning required as far as the server or application is concerned : just create a volume of any size, move the application using any method, don’t bother tuning anything (application block size, file system block size or alignment) and suddenly it will become faster (provided it’s not limited by something else of course)

Bridging the chasm between the application and infrastructure teams

Whether the storage performance issue is storage-centric or application-centric, the Pure Storage FlashArray will provide an answer.

Our Flash arrays :

  • Have plenty of IOPS to enable scalability and support future workloads, in order to satisfy the requirements of the infrastructure teams
  • Deliver consistent low latency to provide instant application acceleration and satisfy business users and application owners
  • Deliver all of these benefits simply and with no tuning

If that sounds too good to be true, well… don’t just take my word for it :

Order a POC today and see for yourself how you can get both the infrastructure and application teams to be successful together.