This post is more than 5 years old
25 Posts
0
2936
September 17th, 2013 03:00
Rebuild or Migrate RP clusters on new VNX at DR site
Hi all,
First an overview of what we have:
All RPA's: RP 3.3 SP2.P2 (Gen 4)
Production Site "NIN":
Clariion CX-960
2 x RPA in a cluster
Production site "SKL":
Clariion CX-960
2 x RPA in a cluster
DR Site "BRA":
Clariion CX4-240
2 x RPA in a cluster as a target for NIN
2 x RPA in a cluster as a target for SKL
All replication goes over long-distance WAN
Both Clusters in the DR site have their repositories and Journals on a single Clariion CX4-240
We have a RP/SE license. And yes, I realize that means I should have 2 separate arrays on the DR site, somehow EMC allowed our customer to implement a duel RP/SE setup with just that single Clarion CX4-240 on the DR site.
What needs to happen:
Now... our customer has bought themselves a nice and shiny VNX5500 block.
It is my job to migrate both RP clusters from the CX4-240 to the VNX. The CX4 will be phased out.
I am having trouble figuring out what the procedure for this is.
It is acceptable to break down the entire existing clusters and start fresh, but I would rather migrate if possible. If it IS possible.
Our first Replication setup, the replication between NIN and BRA, has already had all CG's removed.
On the VNX the Clariion splitter has been activated and the VNX is zoned with all RPA's
I have a temporary license for RP 3.3 for VNX that should work to re-activate the RPA's, until EMC sorts out new licenses for us.
Not sure what the next step is. There seems to be no way to migrate the cluster repository's to a new LUN on the VNX.
Specific questions:
- Do I need to undo the current clusters in the DR site? If so, how? I can find no guidance for this.
- Is there a way to bring the RPA's back to the state where I can start running the install wizard from the Deployment tool?
- Or do I need to completely wipe the RPA's (reset the raid??) and reinstall from the ISO first?
The deployment tool has a 'system modification wizard' but that only works from RP 3.5 onwards.
- Is it advisable to first upgrade RP to 4.0 or so?
- If so , can I do a clean ISO install using RP 4.0 on Gen4
So any help would be greatly appreciated. Thank you all in advance!
jemimus
25 Posts
0
September 18th, 2013 04:00
Hi Richard,
Thank you for your reply.
Yesterday, after posting the above, I actually got a lot further.
I had indeed been issued temporary licenses, and indeed, I had to request a new activation key from EMC licensing, because after re-creating the repository, it generated a new installation ID.
What I was really running up against is that I could not find anywhere how to recreate the repository. Of all the PDF documents I downloaded for 3.3, no where did it tell me where I could do this. You say "if you perform the activity via box management (boxmgmt)" , but as someone completely new to Recoverpoint, that term was meaningless to me yesterday. I had no idea until yesterday afternoon, that this referred to a useraccount you can use to login to the box with, using ssh. , which then presents you with a plethora of options I had no idea about.
As it is, I came across a reference to boxmgmt login in the Deployment guide, where it is used in combination with the Deployment manager tool. I then hit apon the idea to log into the box with ssh using this login. I had to google for the password (boxmgmt), however I later found it is mentioned in the manual. (I suppose I have to be glad no one ever changed the passwords on our deployment, however shockingly insecure that fact may be!)
I have so far not been able to locate a single document that describes the various menu's and functions of the boxmgmt menu's. Is there one? Where to find it?
Anyway, after that, it did not take me long to find
[2] Setup --> [2] Configure repository volume --> [1] Format a volume as a repository volume
What I also did not know for sure was the sequence of steps to set up this new repository.
By that I mean, it seems you do this per RPA, which led me to wonder if I could create some kind of split brain if both RPA's in the cluster had a different idea about where the repository was located. Helpfully it prevents you from changing the repository if the RPA is still a member of a cluster.
In the end I ended up doing:
[4] Cluster operations --> [2] Detach from cluster. on RPA 1
[4] Cluster operations --> [2] Detach from cluster. on RPA 2
(And then I realized: wait, if both cluster members are 'detached' from the cluster... then what happened to the cluster?.. is it... a spirit cluster? An undead cluster?)
On RPA1:
[2] Setup --> [2] Configure repository volume --> [1] Format a volume as a repository volume on RPA 1, and selected my new 6Gb LUN on the VNX
[5] Shutdown / Reboot operations --> [1] Reboot RPA
(after reboot) [1] Attach to cluster
On RPA2:
[2] Setup --> [2] Configure repository volume --> [2]. Select an existing repository volume
Selected the new 6Gb Repository LUN
[5] Shutdown / Reboot operations --> [1] Reboot RPA
(after reboot) [1] Attach to cluster
This worked ... somewhat to my surprise.
I may have messed up the order of how to do it, and I may have needed to reboot both RPA's one more time, as I remember getting a 'segmentation fault - core dumped' message when I tried various commands. Until I rebooted again.
After that, the cluster seemed back, the logs showed successful re-attach and the world was well again.
And indeed, once in the GUI it detected the mismatch of the repository between the sites, and offered me the option to restore from the production site, which of course I did.
Back in the ordinary admin login in ssh, the get_system_settings command confirmed to me I had a new repository and it was on the VNX.
Once I had arranged a new license, I was able to set up a new CG and use the VNX. I was very happy.
forshr
2 Intern
•
1.1K Posts
1
September 18th, 2013 01:00
Hi Fluffy!
A smalll correction first. A single CX3/4 or VNX can support multiple RP/SE clusters.
They key aspect to this activity is the licensing. By all accounts you have been given temporary RP/EX or RP/CL licenses to help you integrate the new VNX5500 into the existing clusters. Once you have fully configured the RPAs in each cluster to see the VNX5500 array you should consider setting/formatting a new repository for each cluster on the VNX. You can do this without disrupting replication or destroying the existing configuration. If you perform the activity via boxmgmt and then access RP through the UI you will be notified of a conflict of configuration. You simply choose the site with the known configuration, i.e. the Prod sites.
However, this will impact the licensing by changing the installation ID so you will need to go back to licensing to request a new activation code. When you apply this it does impact replication by invoking a full sweep. You will need to repeat the process when you apply your permanent licenses after completing the migration.
Regards,
Richard
forshr
2 Intern
•
1.1K Posts
1
September 18th, 2013 05:00
You'd have to refer to the last revision (rev A09) of version 1.1 of the RP Deployment Guide which has the Installation Manager (boxmgmt) section at the bottom of the doc. From version 2.0 of DM there was a definitive shift away from boxmgmt to using the System Modifications Wizard to perform these type of activities.
However, it seems that you've worked through it realising that any settings change requires a detachment of the RPA from the cluster and then a reattachment which in turn invokes a reboot.
If you need any more help or advice then please let me know.