Purity//FA 6.4.5 Delivers Non-disruptive Workload Migration Between Different FlashArray Models

Purity//FA 6.4.5 enhances ActiveWorkload so that applications and data can be migrated between FlashArray systems non-disruptively.

Purity//FA 6.4.5

image_pdfimage_print

As they say, the only constant is change. The needs of businesses certainly do change and those changes often necessitate data and applications being moved and migrated to support new and changing business priorities. Abstraction through storage virtualization has gone a long way in mitigating the headaches in migrating data, but there are still applications that may require maintenance windows so they can be shut down and volumes taken offline while their data is moved to a new home. Until now.

Purity//FA 6.4.5 enhances ActiveWorkload so that applications and data can be migrated between FlashArray systems non-disruptively using a synchronous replication engine. This replication engine enables fully symmetric active-active bidirectional replication between a pair of FlashArray systems to create a disaster-resilient enterprise storage cluster.

Building on top of the replication engine, ActiveWorkload in Purity//FA 6.4.5 can now work across different FlashArray models. For example, a production application may change from being business-critical to mission-critical which requires being moved from a FlashArray//C system to a FlashArray//XL system. No problem! Purity//FA 6.4.5 and ActiveWorkload use a simple connect, stretch, and deposit process to get your data where you need it all while keeping your applications and business online and operating. 

Before now, setting up such data mobility meant that you likely needed two of the exact same array, complex networking, additional licenses, and lots of time spent scripting, sitting, and watching to make sure data goes where it’s supposed to. With Purity//FA 6.4.5, it’s as simple as connecting two arrays which can be done regardless of generation or class as long as they’re running Purity//FA 6.4.5 (or later). Then choose the volume(s) to stretch, and last, enable the data to start being deposited (or copied) to the other array. And this is all done online, non-disruptively, with no extra licenses needed. And, it’s all done using standard, open, and well-known protocols so there’s not black boxes to obfuscate what’s going on with your data.

For more details on ActiveWorkload in Purity//FA 6.4.5, check out this blog post

purity
Figure 1: Purity//FA 6.4.5 using ActiveWorkload to connect, stretch, and deposit across FlashArray models.

Snapshot Replication – Limit Increased to Support More Flexible Disaster Recovery

Snapshots are the primary way in which data is protected within Purity//FA and FlashArray. As a review, Pure uses copy-on-write methodology to create low overhead, space-efficient, point-in-time sets of metadata called snapshots that creates a way to easily and quickly restore access to data. Since Purity snapshots are composed of only pointers to data and are running on an all-flash architecture, restoration of snapshots is incredibly fast. And to protect against rising cyberthreats like ransomware, snapshots-which are already immutable-can be prevented from being maliciously deleted using SafeMode to add another layer of protection.

Purity//FA 6.4.5 uncorks snapshots by enabling replication of all 400,000 snapshots that could be taken on a FlashArray system. This brings a massive amount of flexibility by enabling enterprises to replicate more of their snapshots to other FlashArray systems. For example, a single FlashArray//C system could be the replication target for multiple FlashArray//X or //XL systems for a fan-in approach. Or, take advantage of the cloud and replicate snapshots to Pure Cloud Block Store™. To learn more about snapshots in Purity//FA 6.4.5, take a look at our technical blog post.

Expanded Networking – Increase VLAN Tag Limit to 500 and VLAN Subnet Interfaces to 2000

In addition to its ActiveWorkload capabilities, Purity//FA 6.4.5 also beefs up support for VLAN tagging to enable FlashArray compatibility with even more complex storage fabrics. By increasing the VLAN tagging limit to 500 and VLAN subnet interfaces to 2000, customers can get connected to even more applications across the enterprise. More virtualization in your data centers means more networks and more layers. Increasing the Purity//FA VLAN scalability reduces the need for additional routing and complex networking to get your hypervisors and their workloads connected to your FlashArray systems. To learn more, take a look at our technical blog post.

flash array test drive

Written By: