When I was a kid, I remember playing the card game known as “B.S.” with my brother. I’d try to expertly get rid of all of my cards while yelling “B.S.” enough correct times so that he was overwhelmed in cards that he had picked up—and he was left with a bunch of cards while I won the game. The card game is known as several other names*, and if you haven’t played it yet with your own kids, I highly recommend it. For our purposes here, though, it means bogus statements.
I was thinking the other day how this particular game is very similar to what customers have to “play” with their IT vendors, every day. Customers need to cut through all of the information that the other players (a.k.a. IT vendors) say and know when to yell “B.S.” at the correct time so that they’re not holding all of the thrown-out cards at the end of the game.
In that light, I thought I would post some of (in my opinion) the common “B.S.”** that we’ve been hearing from Dell EMC in order to set the record straight and to hopefully help people see how they are being played by one of the largest IT vendors out there.
#1 “Built from the ground up”¹ and “End to End NVMe”
#2 “Scale-up and Scale-out”⁴ and “Automated Management of Resources Across the Cluster”
#3 “Active/Active Controller Architecture” is a good thing
#4 AppsON – Run data-intensive demanding workloads directly on the array
#5 PowerStore is designed for six-nines availability
If a system was “built from the ground up,” I’d expect it to look very different from an existing product that was released in April 2019. That is apparently not the case with PowerStore. See Figure 1 and 2 to compare the rear view of a Dell EMC Unity XT 480F to a Dell EMC PowerStore T. They look strikingly similar, don’t they?
Now you might say, “Come on Dennis, they just re-used the chassis, that’s no big deal.” That leads me to the other B.S. claim of “End to End NVMe”. If Dell EMC truly built a platform from the ground up, I’d expect it to support the latest technology—especially technology that has been in use by other vendors for quite some time (take the release of Pure with NVMe in April 2017, for one). While it is true that the PowerStore base appliance has NVMe-based media, the expansion shelves use SAS-based SSDs and are connected to the controllers via SAS⁵. Again, was this because they re-used the platform from Unity XT? I’ll have you draw your own conclusion.
OK, how about some other areas where we can see differentiation from previous models, such as in data resiliency. Did Dell EMC make some giant leaps there? No. PowerStore is locked into using RAID 5 in a 4+1 or 8+1 configuration. Guess what other platform uses those exact RAID configurations? You guessed it: Unity XT⁶. What is also interesting is that Unity XT supports RAID 6, whereas PowerStore does not.
Maybe Dell did something special with encryption? Nope, PowerStore has no native software-based encryption and uses self-encrypting drives (SED). This approach adds to the overall cost of the solution, and supports an internal key manager only (no external KMIP support)⁷.
So, again, is PowerStore a retrofitted Unity XT? From my perspective, the answer is absolutely. Dell EMC appears to have carried forward many parts of Unity XT, which likely limits what it can support from a hardware perspective, instead of truly innovating “from the ground up.”
Pure Storage FlashArray™ was truly built from the ground up with NVMe and other storage technologies in mind. We launched our modular long-life chassis in 2015 with FlashArray//M, which is the same chassis we use today while evolving the storage technologies within it. We also created our own DirectFlash™ modules in 2017, allowing us to implement 100% of our storage functionality in software. This has allowed us to move completely to 100% NVMe for all models of FlashArray//X R3 while also supporting Intel Optane storage-class memory (SCM) in our DirectMemory Cache. FlashArray also supports NVMe over Fabrics (NVMe-oF) via RoCE on the host side, as well as the back-end connecting expansion shelves. When customers combine that technology with our leading data reduction services and always-on encryption with the Evergreen Storage™ business model, they can make individual component non-disruptive upgrades as their business requires them.
The scale-up vs. scale-out B.S. point has been around for a while, mostly when competing against Dell EMC XtremIO and NetApp AFF. In fact, Pure discussed the topic of scale-up or scale-out all of the way back in 2014. Many of that articles’ points are still valid, especially in light of how technology has changed since then. But enough reminiscing, let’s discuss how Dell EMC PowerStore “scales-up and scales-out.”
First and foremost, the PowerStore X cannot “scale-out.” That’s reserved for the PowerStore T model. PowerStore T can “scale-out” to a max of four appliances, which can also be different models with different media types⁹. Dell will make it sound like it’s the best thing since sliced bread¹⁰. Why am I calling B.S.? PowerStore is not a true scale-out system. Data is not striped or placed across the appliances. Volumes are created on a specific appliance while the “Resource Balancer” will (hopefully) provide recommendations on where to place the volume¹¹. Resource Balancer only uses capacity-free space to determine where to place the new volume¹². I’m sorry, but that’s not very useful: “Automatic data placement” should incorporate more analytics other than free space, such as array load, workload type, location, etc. This is why PowerStore can support different models with different capacities in the same “cluster,” because data is located only on one appliance at a time. The industry as a whole refers to this as a management “federation,” not a scale-out cluster. Chris Mellor with Blocks and Files wrote a fantastic article discussing this point.
The benefit of a management federation is to provide flexibility and simplicity. Pure launched our “management federation” solution Pure1® product in 2015 to provide a cloud-hosted flexible simplified management plane for all Pure products. Today, Pure1 can help any type of administrator manage Pure products while providing VM-level and array-level analytics around performance and capacity planning. Look for true “Automatic Data Placement” features sometime in the future. (Ask your Pure Account Team for a roadmap session!).
We see this B.S. item come up a lot, usually surrounded by some half-truths. I love the saying that “Two half-truths don’t make one truth”¹⁴. PowerStore claims “active/active controller architecture where both nodes are servicing I/O simultaneously”¹⁵. Frankly, that has been the legacy over the course of VNX to Unity to now PowerStore. Each controller is “active,” however volumes (LUNs) are owned by a particular single controller. Up through the Unity XT family, it was up to the administrator to determine which controller owned the volumes and to keep things balanced by assigning volumes to “SPA” or “SPB”¹⁶. Now, with PowerStore, the system will choose which controller the volume is owned by (called node affinity¹⁷), and relies on Asymmetric Logical Unit Access (ALUA) to maintain multiple optimized and non-optimized paths for I/O¹⁷. This way, the “non-optimized” path will take over in case of a controller or path failure,. This is more like “asymmetric active/active” as a host can access data only via the peer active-controller only when the owning controller has failed.
This really matters in the performance during a path failover, controller failure, or controller upgrade. If a path is non-optimized, the non-owning controller must pass it off to its peer for actual execution. And this hand-off takes time, incurring at least some amount of latency. If controller A is at >50% utilization and it needs to fail over to controller B, which is also at >50% utilization, you now have a big performance problem.
The front ends of both controllers for FlashArray are active-active, with the paths cross-connected across each controller so that either one can see all paths, and support the performance of all paths. Internally, the two controllers communicate actively and one passes its I/O to a designated primary back-end, where each back-end is sized to handle the workload of the entire system for primary software functions including data compression, deduplication, encryption, snapshots, active-active multi-system clustering, and so on. Since both back ends can individually handle 100% of the system load, there’s no tangible performance impact if there’s ever a controller failover. Because the controllers are “stateless,” this enables online, non-disruptive controller upgrades (one at a time) without impacting performance—effectively abolishing re-zoning/re-mapping and other menial tasks, while eliminating traditional data migrations. In our experience, customers love this feature, and often cite it as one of the key reasons that they replaced their legacy storage with Pure Storage products, particularly in mission-critical environments.
AppsON is a new B.S. item with the launch of PowerStore. AppsON virtualizes the PowerStoreOS into a VM so that other VM workloads can be run on the controllers. While this “feature” sounds convenient, I’d really like to see the use case for it. The only one that I could think of is for remote office/branch office (ROBO) environments with minimal workload. But since Dell EMC states “data-intensive demanding workloads” in its material¹⁸, I’m calling out B.S.. Will it work? I’m sure it will work “technically.” But what about performance? What about cost—especially since storage arrays are a higher-margin product than typical servers? What are the other caveats customers need to watch for with AppsON?
Here are a few of the major ones that I’ve found to warrant the B.S. callout:
I doubt that most organizations will run “data-intensive demanding workloads” on an environment that can’t even replicate the data for protection. Sure, you can use VMware vSphere Replication as a workaround, but why is Dell EMC forcing customers to implement workarounds on a “next-generation, built from the ground up” array? Why indeed.
While getting perceived simplicity by running apps on the storage array, we’ve learned from hyper-converged offerings that while initial implementation might be simple, it comes with a ton of trade-offs (more on that in a future post!).
Six-nines (99.9999%) availability equates to ~31 seconds of downtime per year. I’m calling B.S. on PowerStore to meet that level of availability since even Dell EMC’s flagship storage product (PowerMax) can’t meet that level of availability without the use of SRDF/Metro²⁰. Not to mention that PowerStore uses RAID 5 for data protection, lacks synchronous replication support, utilizes ALUA based failover, and Dell’s own footnotes to the statement¹⁹ say “Actual system availability may vary.”
Pure FlashArray has proven six nines availability across the Pure1 collective installed base—inclusive of maintenance, failures, and generational upgrades. Customer data is always available, always performing, and always protected – without performance loss.
Well, those are just a few of the “B.S.” items coming from Dell EMC for PowerStore. Maybe you’ll see another post outlining a few more! If you have any questions about FlashArray, please reach out to your Pure Storage account team. Thanks for reading!
* More info about the card game
Read what my colleagues Prakash Darji and Scott Baker have to say in their posts:
“Dell PowerStore: Solving Dell Problems vs. Customer Problems”
“Data Storage Decisions Shouldn’t Leave You With Doubts”