What should you ask your All Flash Array Vendor

I was just traveling back from a client, where the customer just bought into the concept of an all flash array for their database and VDI workloads.  They had asked me to help out where I can.  So I started pondering the things this customer (or any customers/buyers) should think through…..

At first I was going to do a comparative analysis (table) of the All Flash Arrays out on the market.  However, since the AFA market is constantly changing anyways… why bother with a comparison.

Thus, I changed my approach to aiding the buyer/architect in positioning the appropriate questions to the vendor.  Thus the approach became more of  “What to consider when considering” when purchasing a AFA.

Now note, I’m not stating some earth shattering thought leadership here or a new dimension of looking at this issue,   I’m merely sharing what I was going to present to the customer

Anyways……As with most storage decisions, its very hard to bucketize considerations into the performance, costs and manageability categories, because they are so intertwined.  Also, I specifically did not address Cost separately, since Cost traverses every layer and topic, whether for cost-performance, cost- supportability or feature-cost usage.

1. Performance is king! – We know AFA performance is awesome, but think thru and ask the following:

a. How does the AFA fair with the differing workloads; i.e., degree of sequential to random, and read/write ratios of 80/20, 70/30,  and 50/50.  And especially when the array is near capacity -> 70% or 80%

b. How is garbage collection handled.  Is it using ASIC/SSD or controller based garbage collection.  Regardless, the buyer shouldn’t have to understand the bowels of garbage collection, so the question to the vendor should be simply what is the performance consistency, or better stated “consistency of performance” –  specifically during steady state/peak workloads or during flash maintenance operations (garbage collection, flash overwrites, wear leveling, etc.).

c.  I wasn’t sure if I should even add this entry, but for completeness I will.  AFAs  on the market today use a type or combination of  SSD drives: SLC, MLC, (cMLC), eMLC, etc.  As with the above, buyers should not concern themselves with this level of detail, but one should ascertain the performance they should expect.  This category really needs to go in the costing Category – cost per IOP, cost per GB, etc.

2. Manageability

a. How does the array handle non-disruptive upgrades (NDU).  AFA occasional patches, updates and even field replaceable changes, thus, need to determine what is the impact of making these changes; i.e., is it an online transparent change, online change with a reboot (outage),  or destructive change?  For example, how is a AFA OS patch handled or how is SSD firmware changes handled?

b. Scalability –  What I mean here is really AFA expansion without disruption.  Ask whether you can add another array, another set of controllers, etc, without having to export the array data contents, add in new array, and load back data. It should be mainframe class scale.

c. Storage Array simplicity – How usable are the GUI tools to manage the operational array tasks; e.g.,  create volumes, measure performance, effective-ness of Data Services, and alert notication on failing components

3. Features (Data Services) – By now most AFA will incorporate snapshots, replication, compression, and of course de-duplication. But the real question is what is impact when using these services concurrently, what about selectively using features (by LUN/volume), and overall performance  impact of these services.

This just get you started on the things to think through !!!