We’ve released PowerFlex version 4.0.1 which comprises a lot of improvements to the base 4.0 version. If you are currently running version 4.0, I strongly recommend you work with your Dell team to plan an upgrade. Both versions of PowerFlex 4.x still require Dell’s assistance to install, so unfortunately you cannot download the software yourself. If you login to support, you will only see the listed version, but no content:
What I wanted to write about today, however, is just one of the integrations with the new 4.0.1 version and that’s the PowerFlex SRA.
The current version of the PowerFlex SRA you can find on the VMware site is the following:
This is available under SRM 8.3 which includes SRM 8.4 and 8.5. For some reason VMware hasn’t posted it to SRM 8.6, though it is supported (through equivalency). We are trying to get that sorted. In any case this is the same SRA to use with 4.0.1 so if you already have it installed, you’re good.
From this point forward, I'm assuming a knowledge of PowerFlex, PowerFlex replication, and VMware SRM. I did a post last year on PowerFlex replication with SRM if you need a refresher (though it was PowerFlex 3.x), but the following information is only going to be useful if you already understand the concepts and environment.
4.0.1 SRA issue
So no point in sugar-coating this since I’m writing the blog. We have an issue that surfaced with this SRA when using it with version 4.0.1 related to the PowerFlex GUI. After reviewing the severity of it, management decided it was better to support the SRA with 4.0.1 while we work on resolutions in the code. The issue can be managed by a workaround so that was the logic in the decision I believe. But first let’s talk about provisioning.
I wanted to start with auto provisioning which is a functionality in PowerFlex 4.x when creating replication pairs. In version 3.x as detailed in my aforementioned blog post, the user had to create both the source and target volumes before creating a pair. In 4.x, the user can select auto provisioning for the target volume. Therefore, only source volumes are needed. When you start the RCG wizard to add a new consistency group, you will be presented with the option of choosing the provisioning type in 4.x where Auto Provisioning is an option.
After selecting this, you only have to provide the type of volume and storage pool at the target site when adding the pairs:
This makes it very simple to setup replication.
We also still offer manual provisioning so you can setup the volumes ahead of time if that works better for you.
Either method, however, has the same issue. It is impossible to map the volumes read-only to the target hosts at the SRM recovery site in the PowerFlex GUI. There simply is no option to do that in the wizard, nor afterward. If you then run an SRM operation, you’ll get an error like this:
It is self-explanatory – we are missing the mappings. If you try to map normally in the GUI you see this:
This jives with the online documentation which says you should be able to map the volume read-only from the Mapping menu:
But there is no menu:
Clearly a mismatch in the GUI. The documentation will be amended to fix the discrepancy, but that doesn’t help us with the functionality.
There is only one (well maybe one and half – read on) workaround to this and that is you must map the volumes read-only using CLI. This would be the same CLI that was used when setting up replication between the clusters. The syntax to use to do this is the following. Note the flag –allow_multi-map is not required unless you have multiple ESXi hosts that will require mapping (which is usually the case):
scli --map_volume_to_host --volume_name target_SRM_volume --sdc_guid FE5E4FFA-79F0-4EFD-8A5F-29A72DE83D86 --access_mode read_only --allow_multi_map
Obviously this is not ideal, since the VMware administrator may not have access to the CLI and must involve the storage administrator, but currently this is the only workaround for using PowerFlex 4.0.1 with VMware SRM. Once mapped, you won’t have to touch it again, however, as the SRA will take care of changing the permissions on the source/target volumes accordingly.
There is a silver lining here, and that is the ability to map volumes returns when you add new pairs to an RCG. This is true whether you use manual or auto provisioning. When you add the pair you’ll see this new mapping screen:
I also did a quick demo (no audio) walking through adding a pair:
Now because we can map volumes when adding pairs, the other one-half workaround to the first pair is to not create it at all. In other words, create an empty RCG and then you can add all pairs and map them in the GUI. That sounds like the better workaround than CLI mapping right? Well I suppose it would be if you could create an empty RCG in the GUI. You can’t. But you can in CLI. So if you prefer, run the following command to create an empty RCG:
[root@dsib2191 ~]# scli --add_replication_consistency_group --destination_system_name London_PF --rpo 60 --replication_consistency_group_name SRM_Test_2 --protection_domain_name pd1 --remote_protection_domain_name pd1 Successfully created the Replication Consistency Group SRM_Test_2. Object ID 8b69a2ff00000001
Once created, you will see the empty RCG in the GUI and can add pairs and map volumes:
So, as I noted, one and a half workarounds.
This particular issue is something that requires changes to the GUI rather than the SRA, so I suspect it will take some time to fix this, though I will push.
I have this documented in an external KB you can view here: https://www.dell.com/support/kbdoc/en-us/000207227
Leave a Reply