Unsolved
This post is more than 5 years old
19 Posts
0
1287
RecoverPoint integration with SRM and large journals
Hello All,
I am using RP to replicate between 2 x CX4-960 Disk Arrays. I have a number for ESX Servers with MS Windows Guests. We also have VMware SRM with RecoverPoint SRA.
We need to do DR Tests for prolonged periods of time e.g. 20 days. The DR tests for ESX must be managed by VMware SRM.
For our physical Windows and UNIX Servers we use SnapView Clone to make independant clones (not snaps) of the RecoverPoint CRR LUNs. This means we can do DR tests for as long as we like without affecting RecoverPoints replication.
Unfortunately VMware SRM with RecoverPoint SRA doesn't support SnapView Clones. So my proposal is to increase RP Journal sizes to something like 40% of the source LUN sizes and to increase the target side processing tunings on the RP Journal. This is also called "Proportion of journal allocated for image access log" in RP GUI.
Can anyone see any issues with this? The only issue I can see is after the DR Test is complete RP will have some work to roll the journals back into CRR LUN. That is to catch-up on distribution of the RP journal images.
Anyone got any experience with this scenario? Any comments?
Best Regards,
Kevin.
etaljic81
1K Posts
0
April 26th, 2012 09:00
How many LUNs are we talking about?
Even though you are expanding the journal LUNs and allocating more space to image access that doesn't mean that you will not run into space issues. 20 days is a long time to keep RP in image access mode.
What about running SRM Test and then cloning the LUNs at the DR site? Once the clone completes abort the test and your production stays as is. Present the clone LUNs to the DR host and perform any tests you want. You won't be able to replicate the changes from DR to PROD but it doesn't sound like you want that anyways.
KSmith1691
19 Posts
0
April 26th, 2012 15:00
Hi,
First thanks for reply to my question. I am talking about approx 10 LUNS - totat size approx 6TB. Will confirm when back in the office.
I did think of SRM in test mode and then using SnapView Clone to do long DR Test. However I believe this will cause SRM and virtual centre problems. Perhaps I am incorrect but will it mean that the SRM protected machines will have to be manually removed from VC and re-added from the clone and/or renamed in the VC? Will this break future SRM protection of these machines? Will it mean the SRM jobs will have to be set-up from scratch again?
From Storage viewpoint your solution is best but I am not sure about from VC / SRM viewpoint. You are correct I am not worried about failing the long term DR tests back from DR to PROD.
Thanks again,
Kevin.
etaljic81
1K Posts
1
April 26th, 2012 16:00
Let's take this scenario. You have LUN1 with 2 VMs, vm1 and vm2. You perform a SRM Test and take a clone of LUN1. Once the clone is finished you cancel the SRM Test. At that point you take the clone and present it to the DR ESX servers. You perform a disk rescan in vCenter and you see the clone LUN. At that point you browse the datastore of the clone and locate vm1. Right-click on the vmx file and select "Add to Inventory." Name the VM whatever you want, just don't name it the same name that SRM is using (i.e. vm1). For example, name it vm1-clone. Do the same for vm2, vm2-clone.
The above steps should work just fine and it will not cause any issue with SRM. You don't have to reconfigure SRM. Once you are all done with the clone remove the VM from inventory.