Last week Pure Storage introduced the latest iteration in the FlashArray product line: the FlashArray //m. While Pure Storage has traditionally focused on software innovation from a technical standpoint, we decided that the only way to stay ahead of (and lead) the curve was to innovate in the hardware realm as well. Therefore, for the last few years, development on producing a hardware platform that could keep up with compute and storage speed and capacity leaps has been at full tilt. This produced the brand new FlashArray //m.
The FlashArray //m is more than a new storage array, it is a chassis that is meant to last ten years or more while providing a home for non-disruptive hardware upgrades throughout. This means newer, faster controllers and bigger (capacity-wise) and denser SSDs.
Technical specifications can be found here.
There have been plenty of other posts concerning the //m so I won’t delve into that again. The main point of this post is to review how this affects our VMware integration. This has come up to me a couple times since launch.
The answer is very few changes are required. Most of our current integration will work right out of the box with the FlashArray //m. Arguably all of it. So whether you buy a new //m or perform a non-disruptive upgrade from a FlashArray 4xx, most of the existing integration will work without re-configuration.
The FlashArray //m will still run Purity of course, the same Purity that can run on the 4xx (it will of course be a new version that isn’t out yet, but it will be supported on both platforms). The version that will debut with //m will have some changes to leverage new capabilities of //m. But the software integration will not change–it will still run the REST APIs on the controllers etc.
The current Web Client Plugin? Works with //m. Current Log Insight Content Pack? Works with //m. Upcoming vRealize Operations Adapter? Works with //m. PowerCLI scripts? Will still work great. VMware best practices? Don’t change with //m. VAAI? All good.
The one change will be for VMware vCenter Site Recovery Manager–if you are replicating from let’s say a 420 to a 405 today and you upgrade the 420 to a //m50 you will need to update your SRA. The array manager though does not need to be altered, making this SRA upgrade and hardware change essentially non-disruptive in SRM. Upgrade the SRA, rescan the SRAs and you will be fine. The current SRA will actually probably work with //m. But arrays (new hardware) need to officially qualified with SRAs so we will release a new version that is fully tested and compatible with //m.
So anyways, rest assured, an upgrade to //m will not break things upstream and will not require all kinds of software integration updates.