We have started looking into RecoverPoint for our long-term replication solution to reduce our reliance on SRDF and Mirrorview. Mainly becasue we replicate between many different storage subsystems and would like to employ a standard replication technique agnostic to the subsystem.

If you have Cisco MDS switches, you can use SANTap (SSM module) and the fabric does the IO splits on a lun by lun basis - No host agents are required.

In theory it sounds really great - We hope practice works out the same.

We deployed RecoverPoint earlier this year using the Cisco SANTap protocol. We are currently replicating two SQL clusters, about 8TB total, across a T3 link and the data stays up to date within minutes sometimes, depending on WAN traffic and the rate of change of the data.

The product does work well and delivers an array agnostic, agentless replication. But the data that is replicated is crash consistent only, meaning there is no application consistency only write order consistency across the set of LUNs being replicated. To achieve application consistent data we had to deploy a script on the sql servers that created "'bookmarks" in the data being replicated. Those bookmarks are the only guaranteed sql consistent data.

Another issue is that the SSM module is a 32port 2Gb card, which you would be tempted to put a lot of your production systems on. But if there are any problems with the protocol you have to reload the module which disrupts access to all those ports and the ports that are mapped to the front-end VSAN used for replication, which includes storage ports. Yes reloading the module or a crash of the protocol will bring down the storage ports mapped to the hosts being replicated. It happened to us.

If you are interested I can talk more on the subject, it has been a long deployment but we are finally seeing the benefits of the product.

Aran

AranH...

Our main problem right now with the SSM module is the fact it's a G1 card.
Since we have 9513's we'll limit our port count by half by installing a G1 card.
Not that it's a problem now as we only have 120 ports, but I don't like what I'm giving up in return. There aren't many upgrade options either once the G2 card is released (rumor to occur Q2-08)...

So, we wait, put up with the limitation and upgrade when the new one comes out, or purchase a smaller Cisco switch (9200) and ISL into the 9513's, etc.

You are spot on with regards to generating bookmarks. We'll have to do the same thing with Solaris running Oracle, HPUX running a Progress database and Exchange and SQL on Windows. I'm sure this will be fun. One of our SAN guys said he heard it works great with Unix shops, but hear it's not all that great with Windows??? Have you experienced any issues with Windows?

Thanks...

RecoverPoint is former Kashya ?

I haven't experienced any issues that were related to Windows since we deployed RecoverPoint. Since we deployed it four months ago the majority of problems we found had more to do with the SANTap protocol and RecoverPoint itself. Cisco and EMC fixed issues with both products that were discovered in our deployment. Make sure you have RecoverPoint 2.4 with the latest SP deployed and Cisco SAN-OS 3.1.2b with SSI image 3.1.2m.

The only gotcha that we discovered was that to begin replicating a Microsoft cluster you have to take the Physical Disk resources offline in the cluster for RecoverPoint to be able to begin replicating the LUNs. Once the replication begins you can bring the Physical Disk resources back online. The whole process only took about 10 minutes at the most, but that was downtime for a production application that needed to be scheduled during a maintenance window.

Other than that, RecoverPoint replication has been mostly transparent to our sql clusters. We also nightly clone the source LUNs within the array for in-site DR and use snapshots of the clones for development and the RecoverPoint deployment has been completely transparent to that as well.


Aran

Yep, EMC bought them in early 2006 I think. Same product, new name.

Aran,

Thank you for your feedback on this question. Recoverpoint (formerly Kasha) is one option and has its advantages and limitations.

Victor,

You might want to contact your EMC Customer Engineer to set up someone from EMC coming out to provide you with an overview of the options you have and their advantages and disadvantages so you can make an informed decision on what you want to use.

Thank you.

We were told if the buffer fills and replication is subsequently halted, we would need to do a full initialization. This seems concerning. Is this truly the case?

Thank you very much.

I don't know if that is an issue with older versions of RecoverPoint but on 3.0 and above when replication is paused due to either high change rate or high i/o it does not require a full initialization.

Because of the high amount of i/o and change rate on some of our SQL clusters, RecoverPoint has to pause replication a couple of times a day usually for 5-10 minutes, but then starts up again and is able to sync up quickly.