Pure Storage has completed all qualification and all test cases that it is aware of that are required to support the FlashArray behind EMC VPLEX. In fact, Pure received a confirmatory email from EMC stating that.
As part of the VPLEX qualification process, our Purity Operating Environment (4.0.20 or later) passed the requirements to be supported behind VPLEX meaning that the FlashArray can be supported provided it runs the same Purity Operating Environment even with underlying hardware changes.
Here is the current Support Statement provided by EMC:
Below are some example scenarios for approved supportability without an EMC RPQ required:
Due to a known VPLEX issue called “dual array name”, in very rare cases VPLEX could recognize different arrays as being a single backend array, which could lead to confusion in provisioning and handling devices from both backend arrays. This is a display issue and not any functional failure as noted within the “conditions statement” provided by EMC. Note: Proper mapping file creation is a simple work around to prevent this confusion.
Known Issue: dual array-name identification
Cause of the issue: VPLEX is currently recognizing new backend storage arrays by the Node WWN, which is a 16 digit WWN unique to each storage frame. Due to a limitation in the code, VPLEX is only utilizing 6 digits of the 16 digits Node WWN number to identify the array, like in the below example:
VPLEX: storage-array: PURE-FlashArray-9374bb
In very rare cases distinct Pure Storage arrays could be recognized as the same backend array, leading to confusion in storage provisioning if not properly discovered. In an effort to understand what the likelihood of this condition is, we quickly looked within Pure1 and determined that less than 1% of our total customer population would potentially encounter this known issue. Due to this extremely rare case, EMC is restricting the addition of Pure Storage as a supported platform on the VPLEX Simple Support Matrix, and requires an official RPQ for environments with multiple backend arrays to validate the backend arrays are uniquely discovered by VPLEX.
Despite the fact that single arrays per site have no restrictions and do not require an EMC RPQ as they are not susceptible to the dual array name issue, EMC is not adding those to the Simple Support Matrix and taking the position that no exceptions or limitations are to be added to the supported statement, though all other storage platforms have different limitation statements.
Even in the very rare case of hitting the dual array identification issue, properly discovering devices in VPLEX will allow working in this configuration with no restrictions. As with any other 3rd party array, VPLEX will require the creation of a mapping file to properly name the configured and mapped devices. In the case of a dual array name identification issue, customers will have to provision volumes out of one array at a time, running the discovery on VPLEX and creation of the mapping file. This way the unique naming will allow customers to identify those devices and connect them to the correct Pure Storage array on the backend. We have several customers running multiple Pure Storage FlashArrays behind VPLEX today without the dual array name issue. This is specifically due to properly discovering these FlashArrays via the mapping file.
How to identify the Dual Array Identification issue?
How to create a mapping file in case of a dual array name issue?
We don’t understand why EMC is unwilling to place Pure Storage on the VPLEX Support Matrix for configurations that don’t require an RPQ today. Nor do we understand for the multi-array configurations where a proper mapping file creation as a simple workaround, cannot be specified as a limitation like other third party arrays within the VPLEX Support Matrix.
This whole process has spawned a few additional thoughts:
- If the fix to the dual array name issue is to use [array SN] for EMC and IBM arrays, why not use the same procedure for every new discovered device?
- The fact that the [array SN] change was made for other arrays (including EMC arrays), why didn’t someone start thinking – why not change it generally on how VPLEX recognizes backend arrays?
- Is it not easier to make this a general change rather than an exception every time they discover new backend storage?
- If simple changes like this aren’t possible in VPLEX, how can you adapt to the rapid changes in storage right now and more importantly to the customers needs?
- How does this benefit our joint customers who want a dual vendor strategy when they are met with the delays of an RPQ process for something that is a minor fix as addressed with other “now” supported storage arrays?
- There are several open RPQ’s that are still pending approvals. Hopefully EMC can work towards getting these approved in short order for our joint customers. I’m sure they would be happy to know they can proceed with their current projects requiring BOTH of our technologies.
In closing, I want to thank everyone involved with working towards this qualification process. Thank you to Kumar, Tanya, Maharishi, and Haring from the EMC qualification team for working with our team during this qualification process.