I’m going to be writing a series of blogs on ActiveDR (Active Disaster Recovery) with NFS datastores over the next couple of posts. Some of the other posts I have planned in the near future are:
- Failover scenarios where the ESXi hosts are connected to both arrays
- Failover scenarios where the ESXi hosts are only connected to one array
In this blog I will do an introduction to the technologies and I will give some high level information on how you might want to use them together.
Replication Options on FlashArray
This post will be covering FlashArray specific replication techniques that you may or may not be familiar with. If it is the latter, my colleague Cody Hosterman has a great primer on our technologies that might be worth a read for you.
ActiveDR is Pure’s continuous replication solution for block workloads; for file on FlashArray workloads, ActiveDR is currently asynchronous. ActiveDR is different from traditional asynchronous replication solutions (including Pure’s). ActiveDR has more functionality to reduce the complexity of disaster recovery solutions, including the ability to rapidly test a failover WITHOUT impacting your production environment and current replication processes in the process. ActiveDR has been carefully designed with disaster recovery solutions in mind.
Because it is continuous, it differs from synchronous replication solutions like ActiveCluster as the source array does not wait for the target array to acknowledge writes. This gives more flexibility vs ActiveCluster because you aren’t limited to 11 ms of latency between the two arrays; you can have arrays on opposite ends of the planet with ActiveDR enabled and still replicate your data safely. However unlike ActiveCluster, ActiveDR offers a near zero Recovery Point Objective (RPO) for block as there is no guarantee that in-flight writes have been received on the target array prior to there being a failure; array, site, network, etc.
NFS (Network File System)
NFS stands for Network File System. A file system is a way of grouping data into often more meaningful units: files! You’ve likely heard of some of the many different file systems available today- Linux-based operating systems generally use ext4, Windows-based operating systems generally use NTFS; in ESXi, VMFS is common. In these three examples, the file system is specific to the operating system and not all operating systems have the ability to understand the other’s file systems by default. If you try to mount a VMFS file system on an Ubuntu machine without the vmfs-tools package, Ubuntu doesn’t know what the VMFS file system is or what to do with it.
A network file system is as simple as the name sounds: a file system that’s available over a network. Luckily, with most modern operating systems, NFS support is available by default or through a package installation. With ESXi, mounting NFS exports and creating NFS datastores from those exports is native.
NFS Datastores on FlashArray
NFS datastores are nothing new from a VMware perspective, but they are new from a FlashArray perspective. FlashArray supports NFS v3 datastores (v4.1 coming soon) and has a number of NFS enhancements available today:
- VAAI plugin to get the benefit of offloading storage specific tasks to the FlashArray that can generally handle the storage tasks more efficiently than the vSphere environment
- Automatic directory management (autodir) can be enabled on a FlashArray to give VM granular management
- vSphere plugin to more rapidly deploy NFS. We have additional NFS datastore features planned in the next 6 months for the vSphere plugin
- File snapshot policy management that enables multiple fine-tuned snapshot frequencies and schedules per directory
When automatic directory management (autodir) is enabled on a FlashArray that has NFS-backed file systems on it, the host(s) gain the ability to manage the directory structure on the NFS file system and additionally gives the array insight into the directory structure on the NFS file system. In the case of ESXi, this means that your FlashArray is VM-aware. Autodir gives you the ability to create VM granular snapshot policies, greatly reducing the complexity and time required for snapshot restoration and backup. With these VM granular snapshot policies you can add multiple policies to the same VM with entirely different schedules. Dev/test VMs and workloads don’t need the same amount of protection or the same snapshot schedule as the production VMs do.
Autodir also gives you the ability to more easily troubleshoot issues when they come up- if a VM owner complains about poor performance, you can look at that specific VM in the FlashArray and/or Pure1 GUI to quickly get a good idea of where you need to focus your attention.
ActiveDR with NFS Datastores
What do these two technologies look like when combined on FlashArray? With ActiveDR being available for block workloads on FlashArray for 3 years now, you get the comfort of a well-tested, resilient and reliable DR tool native on FlashArray that works with NFS datastores.
For NFS datastores in your environment, you now have more options and flexibility for restoration. Maybe you’re coming from block on FlashArray. You have an NFS datastore-backed workload you’ve been waiting to migrate to FlashArray that needs the resiliency of a continuous replication solution. You can now take advantage of this today by migrating those NFS workloads to a FlashArray with ActiveDR enabled by simply storage vMotioning the VMs to a FlashArray-backed NFS datastore.
If you have been considering FlashArray but were concerned about the ability to easily recover in a DR situation with NFS datastores backed by FlashArray, the resiliency of a tried-and-true ActiveDR backed solution can be a versatile tool in your disaster recovery toolbelt.
The next couple of blogs I wrote in this series cover what these recovery scenarios look like with NFS datastores and ActiveDR. Part 2 can be found at this page.