You bought a FlashArray//X20—wise choice! You love it; it’s fast, efficient, and feature-rich. The hardware is non-disruptively upgraded every three years, new capabilities come out without licensing costs, and the data reduction is extremely effective. In fact, it’s so cheap to run and upgrade, your boss lets you buy more of them…maybe a newer, high-performance FlashArray//XL™ for your mission-critical applications and a few FlashArray//C™ arrays for business-critical workloads. Suddenly, you’re managing a fleet of Pure Storage arrays.
Eventually, using Pure1®, you start to see your original budget-friendly //X20 is struggling to keep up—increased workload demands are having an effect on the controllers. The //XL, in contrast, is hardly having to work. To add to it, the first //C you bought is also struggling at nearly 95% used capacity, while the new //C is hardly being used.
Ideally, you would simply pick up and migrate workloads to other arrays…use the right tool for the right job; much in the same way you would use your minivan to go to the home improvement store and use your sports car for date night. Or in this example, map the right array to the right workload.
This is easier said than done with data storage—especially if you want to move workloads non-disruptively. It’s tricky—entire applications may need to be shut down to include their hosts and volumes taken offline while data is copied. This means incurred downtime, potential loss of revenue, and general inconvenience for employees and customers. Still, best practices dictate workloads need to be moved regularly. Other legacy vendors have relied on virtualizing the storage network to make this possible, but our approach doesn’t require that overhead.
Enter Pure Storage’s ActiveWorkload, which is built on our proven ActiveCluster™ sync technology. Fast, efficient, easy to configure, ActiveWorkload allows the non-disruptive migration of any workload between different models of FlashArray systems at any time. The strength of ActiveWorkload is its elegance: All ActiveWorkload does is spoof multipath with volume serial numbers. That’s it. Consider the following three-step process:
To recap the above diagrams, connect your workload host to both Array A and Array B, then just like with ActiveCluster, stretch a pod between Array A and Array B. Array B fakes out the host multipath by spoofing volume serial numbers. Once both arrays share the workload, you simply unstretch or deposit from Array A to Array B and the workload will now be on Array B.
Consider this in our original hypothetical situation mentioned above: Mission-critical workloads on the //X array could non-disruptively be moved to the //XL array (don’t worry, it can take it!). You could also identify business-critical workloads and non-disruptively send them over to an available //C array. And when the time comes, you could move workloads off the original //X20 and retire it to a remote office for testing.
ActiveWorkload is perfect for Type A, super-organized types of people because workloads can be easily matched with optimum hardware. Retire that, move this, consolidate this other stuff…you get the idea.
Think of ActiveWorkload as a tesseract from the book A Wrinkle in Time. We just bring one array end to the other array’s end—geography is irrelevant, and because nothing is ever broken, the stretching of workloads to and from is never noticed by any end users. That’s a very powerful tool to have in your tool kit!
