The title of this entry, “Which All-flash Architecture Do You Prefer?”, was actually a question asked on the LinkedIn group, “Storage: SAN, NAS“, a couple of days ago. It was in response to a recent post by Calvin Zito @HPStorageGuy that was also discussing the importance of good architecture design. It was a great question that I responded to right away and below is a more organized version of my response.
When I am asked what storage, backup or flash architecture I prefer, the first answer is nearly always “it depends”. The determining factor may be “does it matter?”. In other words, do you require enough performance to push any flash architecture hard enough? In many cases, the answer is going to be “no”. Now this may not get you a lot of free vendor lunches, but it will save your IT budget.
For example, if you need less than 50k IOPS, and that encompasses a lot of data centers, than the architecture, at least from a flash performance perspective, probably doesn’t matter at all. The exception would be if you need somewhat high performance, and you need a lot of capacity. Then the scalability, in terms of capacity, of the all-flash architecture matters. The type of data also has an impact on the architecture. For example, if your data is highly redundant, like it would be in a virtual environment, then some of that capacity scale concern is diminished. But it is replaced with the concern over the integrity of the deduplication engine. As stated above, your environment has a lot to say about what the best flash architecture is for your environment.
If you need more then 70k IOPS then the architecture starts to matter. The first thing to ask is if those IOPS are from a single workload or multiple workloads: that matters. Some scale-out architectures are limited on their per workload or per volume performance capabilities. If that 70k+ is spread out across dozens (hundreds) of workloads, then an architecture that can scale to meet a variety of workload types and deliver consistent parallel performance matters.
The Flash Purchasing Reality
What I find is that most all-flash systems are initially bought to solve one specific problem. Generally, but not always, it solves that problem. Let’s call that phase 1. Once phase 1 is complete and proclaimed a success, then phase 2 starts. Which typically means more workloads are added to that flash array and the phase 1 flash architecture sometimes breaks down. It either can’t meet the overall performance or capacity demand, the mixture of workloads, or affordably deliver capacity. In some cases, phase 2 of flash adoption requires a fork-lift upgrade of the original array.
In the end, you need to keep two types of goals in mind. First solve the first problem, that is the one that people are hounding you about. But try to solve the first problem while keeping in mind the additional workloads that may also get installed on the flash array. In short, look for an architecture that can scale small, scale up AND scale out.
For more information:
As usual, we have covered all sides of the debate.
Below is an article that discussed the advantages of a scale up architecture:
This is an article where we covered the advantages of a scale out architectures:
Here is the article that we wrote which covers some of the topics we discussed in the video that Calvin mentions:
Finally, our most recent post covers a trend I think we will see more of. Architectures that can scale up and scale out. These allow you to start small and then scale big as you broaden the flash use case:
One More Thing
Stay tuned as we begin to announce cities for our workshop “Designing a Flash Strategy for 2015“. An intensive workshop where you will walk away with a specific flash strategy for your data center. If you want to make sure we come to your city, leave a comment.