American Megatrends ManageTrends 2.7, User Manual

Page: 298 / 367

StorTrends® 1300 User’s Guide (StorTrends iTX version 2.7) 280
Once JAR is created, it will be listed under ‘Replication/Asynchronous/Journal Assisted’.
Select this node to manage JAR. Replication can be scheduled here.
One of the important information that can be seen here is, ‘Current Replication Type’. In
JAR, replication can be either from Journal File (‘Journal Based’) or from DVM
Snapshot (‘Snapshot based’).
In JAR, the source data is always from the Journal File unless Journal File overflow,
Journal failure (due to LD failure), unclean shutdown, CG Rollback happens. When JAR
cannot rely on Journal, it will rely on Snapshot for Source data and change the current
replication type to 'Snapshot based' from 'Journal based'.
Journal File acts as a circular buffer. Journal File overflow happens when new IO
overwrites the existing IO that has not been yet replication. When this happens, JAR will
use Snapshot data until it can safely rely on Journal File for replication.
Journal Failure can happen if underlying LD is failed. If the Journal File is failed, then
JAR will rely on Snapshots to replicate IO.
Unclean Shutdown will cause IO inconsistency between DVM volume and Journal
logged IO. In such cases, JAR will safely ignore IOs that had been logged between
unclean shutdown and a snapshot previous to unclean shutdown. Once the affected region
is replicated through DVM snapshot, it will try to fallback on Journal File.
When a CG rollback happens, all IOs in journal may be invalidated. In such cases, it will
rely on snapshot.