We have a lot of data being replicated by RecoverPoint. In fact we have well over a PB of storage behind RP on a Global scale. This represents a lot of RP clusters and Consistency Groups. We have well over 200 CGs. Keeping up with the replication and ensuring we have everything correctly configured for disaster recovery is a challenge, especially when you have a lot of change with luns being added and taken away from hosts.

Fortunately RecoverPoint has a very nice and comprehensive RESTful interface to help. I wanted to cover some of the basics of the implementation and demonstrate how this data can be collected holistically to help drive greater visibility and insights into replication. Your DR team will really appreciate this ;)

I personally use PERL for most of my processing, but other REST clients will work fine. I'll try to keep this fairly generic so it can be applied to other client implementations.

First we need to authenticate. We use BASIC HTTPS authentication for each call. Also note it uses Base64 encoding. You'll need to encode your username and password separated with a colon. It should look something like this:

my $auth = { Authorization => 'Basic ' . encode_base64($u . ':' . $p) };

Next we need to have the endpoint defined. We'll look at just one endpoint for now, group settings. This is the biggie and contains most of the information you'll want. You'll need the IP/Hostname of one of the RPAs in the cluster. It doesn't matter. You can use the same one you use for the web browser. Default port is 7225. The full path of the endpoint (/fapi/rest/4_4/) can vary by the RPA code installed. Our installation looks like this:

https://$ip:7225/fapi/rest/4_4/groups/settings

So now we can make a GET call with the authentication information to the endpoint defined above. If it all works correctly (response code 200), you'll get a JSON response with all the group settings information. This can be a large response as it is in our case.

The response will be a array of Consistency Groups called innerSet. There's a huge amount of nesting, so we'll focus on just a few key areas. You can alway use a JSON viewer for your favorite browser to explore. I use Data::Dumper in Perl to view the structures.

Within the innerSet, we'll need to grab data from the groupCopiesSettings array. This section will contain all the group name, state, copies ids/names and journal volumes for the group.

VAR1 = {
          'innerSet' => [
                          {
                            'groupCopiesSettings' => [
...

The next section we need information for the actual replicated volume information will come from the replicationSetsSettings array. Here we'll gather information such as: rset name, copy id, volume name/naa number and the copy role (i.e. ACTIVE or REPLICA).

VAR1 = {
          'innerSet' => [
                          {
                            'replicationSetsSettings' => [
...

With this information, we can build a relationship of all the array volumes used in replication. We can map an naa to a cluster, consistency group, what copy it is in and what RSet it has to associate copy relationships. The naa/wwid will link you back to a specific array/vplex lun. Now linking a VPlex lun to BE array lun(s) is another conversation ( I do this too, but another post I suppose...).

Hopefully this will help encourage you to explore the RPA REST interface if you have not already done so. This just scratches the surface. Whether you have 9, 90, 9000+ luns (as in our case) under RecoverPoint control, this will help drive visibility into the configuration and and no more manual spreadsheet tracking!

Send me a note if you want to discuss more.

Comments

There are no comments on this post.

Recent Posts

Archives


Contact Cecil