New vVol Replication PowerShell Cmdlets

Happy New Year everyone! Let’s work to make 2021 a better year.

In furtherance of that goal, I have put out a few new vVol-related PowerShell cmdlets! So baby steps I guess.

The following are the new cmdlets:

Basics:

• Get-PfaVvolStorageArray

Replication:

• Get-PfaVvolReplicationGroup
• Get-PfaVvolReplicationGroupPartner
• Get-PfaVvolFaultDomain

Storage Policy Management:

• Build-PfaVvolStoragePolicyConfig
• Edit-PfaVvolStoragePolicy
• Get-PfaVvolStoragePolicy
• New-PfaVvolStoragePolicy
• Set-PfaVvolVmStoragePolicy

Now to walk through how to use them. This post will talk about the basics and the replication cmdlets. The next post will talk about the profile cmdlets.

As always, to install run:

Install-Module PureStorage.FlashArray.VMware

Or to upgrade:

Update-Module PureStorage.FlashArray.VMware

These modules are open source, so if you just want to use my code or open an RFE or issue go here:

https://github.com/PureStorage-OpenConnect/PureStorage.FlashArray.VMware/

For detailed help on a cmdlet, run Get-Help

Get-PfaVvolStorageArray

In the VMware vVol API there is an object that represents an underlying array, they refer to it as a storage array or a VASA array. VMware has a native cmdlet that does this for you called Get-VasaStorageArray. This cmdlet wraps that one and makes it a bit simpler:

Native cmdlet:

Pure cmdlet:

As you can see it only returns the Pure objects. You can also filter by FlashArray name or serial with the -arrayname or -arrayserial property.

The array object has some useful properties and can be used for other cmdlets later:

Get-PfaVvolFaultDomain

In a vVol world a fault domain this is a grouping of resources that failover together and can be nested–this does not represent a logical group but a physical one. Today, a fault domain = an array but that will likely expand in the future. This filters down the existing Get-SpbmFaultDomain cmdlet to Get-PfaVvolFaultDomain. Similar options to Get-PfaVvolStorageArray.

Get-PfaVvolReplicationGroup

This is a helpful cmdlet when dealing with vVol replication. When you configure replication for a vVol VM, you assign a replication policy to it via VMware storage policies and then also a specific replication group. A replication group is essentially a consistency group and the unit of failover for vVol VMs. When VMware runs a disaster recovery event, it is run against the replication group, not a specific VM. So all VMs in that group are recovered together. While it is possible to manually recover one VM through tooling, VMware acts upon the replication group.

So when assigning replication, you must also specify the replication group. VMware also has a cmdlet that does this, Get-SpbmReplicationGroup. This cmdlet wraps and enhances it for Pure customers.

There are also filters for the status of the groups: -target, -source, -testFailover, -failedOver:

Furthermore, you can pass in a VM, datastore, fault domain, or policy to see the replication groups that are applicable for that object (either assigned to the VM, or applicable for that datastore, fault domain, or policy)

Get-PfaVvolReplicationGroupPartner

In Virtual Volumes, there are two separate yet equally important parts, source replication groups and target replication groups. These are their details.

A source replication group is on a fault domain and is a grouping of vVols that are replicated together, consistently, and in the same configuration: RPO, concurrency, etc. A source replication group implies they are of course replicating to a target. A source replication group has one or more corresponding target replication groups, each representing a single fault domain.

Let’s review some points:

• A FlashArray is a fault domain
• A FlashArray protection group is a source replication group
• A FlashArray can have many protection groups and therefore a corresponding number of source protection groups
• A source replication group is always on one fault domain
• A source replication group replicates to one or more target replication groups.
• For each FlashArray configured as a replication target in a FlashArray protection group, there will be one target replication group
• A target replication group is always on one fault domain
• On a FlashArray a target protection group is a target replication group.
• When you run a failover or a test failover you run it against a TARGET protection group

VMware has a default cmdlet called Get-SpbmReplicationPair that is related but serves a slightly different purpose. Get-SpbmReplicationPair returns all identified pairs, so the source group and the corresponding target group. The source will returned multiple times if there is more than one target. The problem though is if your array is in-use by more than one vCenter and you are not authenticated to all of them in PowerCLI and/or they are replicated to/from an array not known by the connected vCenters it will throw some errors:

There is nothing “wrong” with this, it is just saying it can’t find the paired group. But it is annoying if you are using it interactively. Furthermore, it returns some information I don’t need–the source and the target. I just want the corresponding target(s). Or the corresponding source.

So I made a wrapper cmdlet called Get-PfaVvolReplicationGroupPartner.

Essentially you pass in one replication group and it returns the corresponding partner. If you want a specific partner you can pass in the fault domain as well.

So let’s say I grab all of my replication groups and store them in $Groups:

I will take my replication group called flasharray-m50-1:Rep1hrNolocal (note that source replication groups are named with the FlashArray name, then a colon, then the protection group name).

Then pass it into Get-PfaVvolReplicationGroupPartner:

This returns the target groups. If we were to store that target group and pass it back:

It will return the source. This makes it simpler to pass into commands like Start-SpbmReplicationFailover.

If a source group has more than one target associated with it, the cmdlet will return all of them:

If you look at them in closer detail, you can see they have the same IDs but different fault domains: