Specifications
Synchronous vs. Asynchronous Mirroring
l Provides failover protection for mirrored data.
l Integrates into the LifeKeeper Graphical User Interface.
l Fully supports other LifeKeeper Application Recovery Kits.
l Automatically resynchronizes data between the primary server and backup servers upon
system recovery.
l Monitors the health of the underlying system components and performs a local recovery in the
event of failure.
l Supports Stonith devices for I/O fencing. For details, refer to the STONITH topic.
Synchronous vs. Asynchronous Mirroring
Understanding the differences between synchronous and asynchronous mirroring will help you
choose the appropriate mirroring method for your application environment.
Synchronous Mirroring
SteelEye DataKeeper provides real-time mirroring by employing a synchronous mirroring technique in
which data is written simultaneously on the primary and backup servers. For each write operation,
DataKeeper forwards the write to the target device(s) and awaits remote confirmation before signaling
I/O completion. The advantage of synchronous mirroring is a high level of data protection because it
ensures that all copies of the data are always identical. However, the performance may suffer due to
the wait for remote confirmation, particularly in a WAN environment.
Asynchronous Mirroring
With asynchronous mirroring, each write is made to the source device and then a copy is queued to
be transmitted to the target device(s). This means that at any given time, there may be numerous
committed write transactions that are waiting to be sent from the source to the target device. The
advantage of asynchronous mirroring is better performance because writes are acknowledged when
they reach the primary disk, but it can be less reliable because if the primary system fails, any writes
that are in the asynchronous write queue will not be transmitted to the target. To mitigate this issue,
SteelEye DataKeeper makes an entry to an intent log file for every write made to the primary device.
The intent log is a bitmap file indicating which data blocks are out of sync between the primary and
target mirrors. In the event of a server failure, the intent log can be used to avoid a full
resynchronization (or resync) of the data.
Note: The intent log can be used in both asynchronous and synchronous mirroring modes, but the
intent log with asynchronous mirroring is supported only with a 2.6.16 or higher Linux kernel.
How SteelEye DataKeeper Works
SteelEye DataKeeper creates and protects NetRAID devices. A NetRAID device is a RAID1 device
256Introduction