Unsolved
This post is more than 5 years old
388 Posts
0
809
Additional Disk Space for Replica for RP
Hi,
We are using CX4 CLARiiON SAN at both main and remote site. We are planning to use VMware SRM with synchronous replication (via optical fibre).
We understand that we can make use of MirrorView and RecoverPoint. And we are looking into features / performance of these 2 products.
From the web, we find that it appears that we have to create local replica at the main (protected site) as well as replica at the remote (recovery site). Just wonder how large will the replica required ? Can it be run on SATA disk ?
Your advice is sought.
forshr
1.1K Posts
1
June 6th, 2014 06:00
Hi Tony,
RecoverPont has multiple features and scalability advantages over MirrorView plus MirrowView hasn't been developed now for several years, nor is it likely to be.
Protecting the same production/source volume using both technologies is not supported and if you were intending to use both technlologies they would have to be enabled on separate FC or iSCSI ports.
For remote replication with RecoverPoint all you need to do is provision a local journal volume(s) for the production/source copy (which contains the production/source volume(s)) and a remote volume(s) (which will be the remote replica copy) and likewise a journal volume(s) for the remote replica copy. These components form the consistency group.
Now like any replication technology we have to size all the components, RPA nodes, bandwidth vs. RPO and journal (for both rollback history and distribution performance). This can be done using EMC's internal BCSD tool and it doesn;t necessarily mean that you cannot use SATA disks. However, SATA disk won;t perform as well as SAS or NL-SAS disks and the distribution process to the journal relies on an element of performance that has to be catered for. In short, it will most liklely mean that you willl need more disks if you use SATA.
Having said all that, you might compare the two technologies and be thinking that with MirrorView you don't need the journal and is it really necessary when I'm replicating synchronously. However, please don't fall into that trap and consider what would happen if you where replicating corrupted data or if data was deleted. The advantage of RecoverPoint over MirrorView, of which there are too many to mention, is that the journal plays out like a DVR and you can access the data prior to the corruption or deletion from the journal by accessing it via image access from the rollback history and having the luxury of data integrity checking it without ncessarily impacting on-going replication. Obviously the journal would have to be sized according to your rollback requirements based on write throughput vs. the size of the journal. MirrorView does not have this capability amongst others.
Moreover, you mention SRM. RecoverPoint is the only replication capability which allows SRM to use a retrospective snapshotfrom the journal by leveraging the VSI plug-in.
Regards,
Rich Forshaw
Consultant Corporate Systems Engineer - RecoverPoint & VPLEX (EMEA)
Data Protection & Availability Division