SRM - Scheduled / triggered replication

[slatemine]

Questions:

I have an application that runs a large batch process that churns data. I am trying to work out what the best approach would be using Site Recovery Manager would be. Please help.

How to do triggered replication with SRM?

Is SRM the right tool for the job?

Problem:

4TB of data, which is churned during processing, so many blocks may change repeatedly. The application is only consistent (and useful) before and after processing. Snapshots during processing are of little use. The acheivable RPO is inherently defined by the time it takes to complete the processing.

What is the best way to do this in SRM? and what is the best way of minimising useless / potentially failed snapshots / replicas?

I've seen some information on how to avoid replicating certain datastores that will help but there is still quite a bit of churn.

Reference

Avoiding replication of paging files and other transient data in Site Recovery Manager

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2009324&sl...

[jeff9565]

Slatemine,

With an application that size, you will have to use array based replication (which will be managed at the storage level, not VMware).  That being said, SRM will not help you get a "crash consistent" copy of your data at your DR site but will help you fail over your virtual machine in the event of a disaster. 

The only way to ensure that your data goes across could be a full synchronous mirroring or scripts that initiate a mirrored job before the processing and after.

Hope this helps.

Jeff

[vMario156]

The only case where SRM helps (also with array replication) is the planed migration function, which is used if you want to perfom a planed move of one data center to another for example.

In this case SRM is going to start the sync process on the array (and wait until its finished) before failing over.

Regards,

Mario