Table of Contents
Advertisement
Journal Assisted Replication
With respect to management, JAR is same as Snap Assisted Replication. JAR too
supports Failover, Fail back and Rollback etc. In JAR, it replicates the IO from the
Journal File instead of Snapshot. As mentioned earlier, IOs are logged into journal with a
snapshot event as base. It means, all IOs that happened between two snapshots are logged
sequentially into Journal File with leading and trailing snap event. Hence replicating all
IOs from between such two snap event has similar effect of replicating data between two
snapshots of a volume. JAR is preferred over SAR when Recovery Point Objective
(RPO) has to be very minimal. JAR also provides another benefit with compare to SAR.
In JAR, remote volume can be in-sync with Primary volume. SAR always relies on
volume's snapshot in order to replicate data. Unless snapshots are created continuously,
SAR replication cannot happen. Hence, the remote volume always at least lags to
Primary volume by a time last snapshot is created in Primary Volume. In JAR, since
replication happened by the same order at which IOs happened to Primary volume, even
the last IO replicated to Secondary is valid. JAR does not need a closing snapshot in
secondary in order to access Secondary volume.
Create Journal Assisted Replication (JAR)
In order to create JAR, Journal File must have been already created. All the volumes (and
only those volumes) used to create Journal File should be used to create JAR. Thus
Consistency Group is not broken. Select 'Replication\Asynchronous' note to proceed to
Replication Wizard
Appendix E : Replication Overview 227
Advertisement
Table of Contents
