The process to get this up and running on the FlashArray is super easy:
Create a “synchronous” connection between FlashArrays:
One one FlashArray go to first get a connection key (doesnt matter which array)
Now go to the other array and enter in the connection key and management address of the array you got the key from and choose “Sync Replication”.
Arrays are now connected!
The next step is to create a pod. What is a pod? Well a pod is a namespace, but also a replication group. A pod is first created on a FlashArray, then a second FlashArray is added to it. This is called “stretching a pod”. When a pod is first stretched the initial synchronization of the data starts. When everything is in sync, the volumes are now available on both sides. They can be read from or written to on either array at the same time.
Now create a pod.
Go to the Pods tab and create a new one and name it something that makes sense.
The pod is now ready.
At this point add any pre-existing volumes you would like to the pod. This is called a volume “move”. The volume is not literally moved, nor is any data copied. The volume is just moved into the pod namespace. So if my pod is named “codypod” and my volume is currently called “codyvolume”, when the volume is moved into the pod, it will be called “codypod::codyvolume”.
Choose a volume:
Choose move:
Chose where to move it to (the pod):
Confirm:
It is now in the pod:
This process is of course non-disruptive to any host I/O to that volume.
When you have finished adding any volumes, you can now stretch the pod to the second FlashArray.
Go to add a FlashArray:
Choose a FlashArray that is synchronously connected:
It syncs:
It finishes:
The volume is now available on both FlashArrays!
That is really it.
There are two other options:
- Use cloud mediator or deploy and internal one. The default behavior is for the FlashArrays to use the cloud mediator. This is the preferred option in general (it ensures it is on a third site for instance). But if you want to deploy an internal mediator, we do offer a vApp.
- Set an array as preferred for a host. If hosts only have access to the volume through one FlashArray, there is no need for this (called non-uniform configuration). If hosts in both sides have storage access to a volume through both FlashArrays, you might want to set a preferred array. When you set a preferred array for a host, Purity automatically tells the host that its paths are optimized or not optimized. The preferred array paths will be marked optimized and therefore a host will only use those paths. If you do not set this, and there is a latency difference across sites, reads and writes might go to the remote FlashArray instead of the local one, which will add unnecessary latency. I will go more into this in another blog post.
Once a pod is created, you can control the pod and volumes from either FlashArray. If you create a snapshot, that snapshot is created on both sides. If you have snapshots before putting a volume in a pod, then you put the volume in, those snapshots will be copied over too.
If you create a new volume in a stretched pod, it is immediately available in both sides.
So ActiveCluster is not just an active-active solution, it can also be a very simple means to move a volume and its snapshots over to a different array, Put a volume in a pod, stretch it, let it sync, then unstretch it.
For more info, see below:
https://www.purestorage.com/products.htmlstorage-software/purity/active-cluster.html
Written By:
