Configuration of the deployed vRPAs is performed with the RecoverPoint Deployment Manager. This is a tool on your laptop that, using a multi-step process, assigns IP addresses to the RecoverPoint appliances and their various networks and connects these appliances to the VNX array. The previous part of this series discussed the first steps to get into the tool: now it’s time to start entering some configuration data.
Section 3 “Environment Settings” covers several cluster wide settings like NTP, DNS and the cluster name.
Select the number of RPAs you’ll be deploying and fill in all the other field; pretty straightforward…
Section 4 “RPA Discovery” gives you two options: let the Deployment Manager scan for RPAs in the network, or if you’ve set the IP addresses manually, skip the scan. Since we’ve configured the “Temporary” IP adresses during the OVF deployment phase, we’ll skip the scan and go straight towards the IP and Connectivity settings (section 5).
Specify the cluster management IP address (this is on the LAN/management subnet!), the netmasks for both the LAN and the WAN and the IP addresses for the vRPAs. These can be the same as the temporary IP addresses you’ve specified in the OVF deployment.
The default gateway refers to the gateway on the LAN/local subnet; if you need to specify an additional gateway for the WAN subnet, you can do that with the “Add Route” button.
In sections 6 and 7 the deployment manager will try connecting to the IP addresses you’ve specified in the previous screen. You will have to enter credentials: boxmgmt with the identical password will get you into a default installation. You can (and should!) change this once the cluster is up and running…
Section 8 (iSCSI) contains two parts: cluster wide settings like the MTU and CHAP settings, and RPA-specific settings like IP addresses. In this deployment the network limited the max MTU to the default of 1500 bytes and CHAP wasn’t used, so that’s an easy “Next!”.
Enter the IP addresses for the iSCSI networks of the vRPAs. This should correspond with the virtual networks you’ve selected when you deployed the OVF files into your VMware vSphere environment. Just make sure the configuration is consistent on the RecoverPoint side: if you’ve accidentally put the iSCSI vNICs in the wrong VLAN, you can change it afterwards on the VM with the vSphere (Web) Client.
In this install we did not use any gateways for the iSCSI networks, hence no additional gateways needed to be configured.
Section 9 will ask you for your support.emc.com credentials to download a Change Management file (more on that in section 12). Section 10 will offer you the chance to update the RecoverPoint version on the vRPAs. If you’re sure you downloaded the latest version from the support.emc.com website, you should be safe to skip this step.
Fast forward to section 12: if there are any known issues with the Deployment Manager or VNX/RecoverPoint software, it will be shown in this screen. Read the procedures and perform them (or at the very least verify that they do not apply to your environment): then check them and continue. The deployment manager will now apply all the networking settings and if you did select an RP upgrade, update the RecoverPoint software.
In section 14 you can select the cluster security level. There are three options, with Authenticated being the default option:
- Accessible: Communication between RPAs is not authenticated or encrypted. RPAs can communicate with each other only by adhering to the RecoverPoint proprietary protocol.
- Authenticated: RPA clusters use certificates to authenticate each other before communicating. This option minimally impacts RPA performance.
- Authenticated and encrypted: RPA clusters use certificates to authenticate each other before communicating. All communication between RPA clusters is also encrypted. This option moderately impacts RPA performance. This security level is FIPS compliant.
As you can see there’s an RPA performance impact if you start encrypting the traffic. Our traffic is crossing an on-site, inter building dark fiber so encryption wasn’t a necessity: I kept it at Authenticated.
In section 15 we’ll connect the vRPAs to the VNX storage. The first part is easy: give the RPAs some credentials to log into the VNX. These will be used to create the necessary storage groups and LUNs.
Clicking next will result in a test login to the storage system, displaying (hopefully!) an “All RPAs are connected to the storage.” If you don’t get this message there’s probably a network problem between RPAs and VNX SPs or the VNX doesn’t have the RecoverPoint splitter installed.
Next, give the array a fancy name, enable CHAP (in our case, not configured) and enter a couple of IP adresses the vRPAs can use to connect to the storage. Pressing Next will apply these settings, followed with a SAN diagnostic at step 15.5. If you did everything right (no MirrorView enabler, 4 paths to the storage per RPA, etc), this will show “SAN diagnostics test completed successfully”. Congratulations, almost there!
The last step is selecting a repository volume where the RecoverPoint cluster will store its configuration data. This is a 6GB LUN; you can let RecoverPoint provision it automatically, or you can create a 6GB LUN yourself and select that one. I chose to do the latter. Click Next, wait for the entire configuration process to complete (this can take a while) and finish the configuration. Congrats: one cluster down, one more to go! Repeat these steps on the second cluster, then use the “Connect Cluster” wizard option to join both clusters together.
Log in to the cluster(s) using https://<cluster_management_ip> and follow the steps in the Getting Started wizard. These include adding the RecoverPoint licenses, enabling the support options (including ESRS), and registering the clusters with EMC for proper support.
I’m hoping this is patched in current releases, but during all previous vRPA deployments we received the following error:
ERROR Cluster control RPA at <clustername> received an empty or invalid key.
The second vRPA would be unreachable. Several options were tried, including contacting EMC support whom detached and reattached the RPA to the cluster. I’ve found that the easiest and fastest fix is to just reboot the site control vRPA (vRPA1).
Don’t forget to change the default passwords for the three default accounts. Then create some consistency groups and use those RecoverPoint clusters!