Pure Storage® ActiveDR™, one of my favorite new features in Purity 6.0, delivers continuous replication with near-zero recovery point objective (RPO). And both Microsoft Hyper-V and SQL Server can leverage it.
ActiveDR enables global disaster recovery with Pure FlashArray™ without impacting latency or causing distance limitations. There’s a ton of great information for all solutions on VMware. Be sure to start with Demoting an ActiveDR Pod in a VMware Environment if you’re VMware-based. I recently wrote the ActiveDR and Microsoft Solutions guide on the Pure Storage Microsoft Platform Guide which focuses on both Hyper-V and SQL Servers (physical and virtual).
The core of ActiveDR is storage replication and I have used it all: third-party software replication, OS and hypervisor replication, SAN replication, log shipping, and both SQL and Exchange Availability Groups. Most of the solutions are difficult to configure, make it complex to invoke a failover, and cause failover testing to be difficult—often requiring a custom set of scripts just for the test. This is why many companies mandate forced production-failover tests to ensure that the process will work in the event of emergency. This causes an availability hit and increases vulnerability during the failover. And it’s often costly to “reset” the environment after the failover test is complete.
Take SQL Server to the Next Level
Pure Storage provides a wide portfolio of built-in modern data-protection features that don’t require additional software licenses. Each offering provides different technical and availability capabilities.
- FlashArray has offered replication utilizing protection groups for a long time.
- With FlashBlade®, you can get faster backup and rapid restore.
- You can offload to an NFS Server or a cloud target with Snap to NFS and Purity CloudSnap™.
- If you have fast networks and stretched-hypervisor clusters, you can utilize ActiveCluster™ for metro-distance business continuity with zero RPO and zero RTO.
So why ActiveDR? Not every network is fast enough with low round-trip latency for ActiveCluster™, and not everyone is willing to accept the additional write latency that synchronous replication causes. Backup will always have a larger RPO. Utilizing protection groups and FlashArray replication also has a larger RPO and can require custom scripting to “replicate now” if you’re not relying on the protection-group schedule and it’s only a one-way replication. You’ll need a new configuration to reverse the replication if production is moved to the DR site.
With ActiveDR, you can configure it once and use the same scripts to both test and invoke an actual failover. The act of demoting and promoting a pod, or the container holding the volumes to replicate, instantly reconfigures the replication traffic direction. It’s simple, reliable, testable, and easily automatable. When the time is right, an administrator can activate this disaster-recovery solution.
You can promote and demote a pod in the FlashArray UI. This only enables the storage at the DR site, and most users are going to automate the entire process. This would include bringing drives and then databases online, and if the other site is accessible, bringing down databases and drives in the original production site.
For the initial setup, simply promote the DR pod without touching the production pod. Replication will continue, and the DR site will become writable so that you can connect the drives to the DR infrastructure, bring them online, attach databases, and configure everything. Then, you simply bring all your databases and drives offline, demote the DR Pod, and you’re ready to go.
To show how fast the failover can occur, I scripted the failover of my production SQL database and recorded it in this video.
I hope the video demonstrates how easy it is to failover and failback a production SQL database. To see the automation examples used in the video, refer to the ActiveDR and Microsoft Solutions guide.