Mirroring with SIOS DataKeeper for Linux

SIOS DataKeeper for Linux offers an alternative for customers who want to build a high availability cluster (using SIOS LifeKeeper) without shared storage or who simply want to replicate business-critical data in real-time between servers.

SIOS DataKeeper uses either synchronous or asynchronous volume-level mirroring to replicate data from the primary server (mirror source) to one or more backup servers (mirror targets).

DataKeeper Features

SIOS DataKeeper includes the following features:

Allows data to be reliably, efficiently and consistently mirrored to remote locations over any TCP/IP-based Local Area Network (LAN) or Wide Area Network (WAN).
Supports synchronous or asynchronous mirroring.
Transparent to the applications involved because replication is done at the block level below the file system.
Supports multiple simultaneous mirror targets including cascading failover to those targets when used with LifeKeeper.
Built-in network compression allows higher maximum throughput on Wide Area Networks.
Supports all major file systems (see the SPS for Linux Release Notes product description for more information regarding journaling file system support).
Provides failover protection for mirrored data.
Integrates into the LifeKeeper Graphical User Interface.
Fully supports other LifeKeeper Application Recovery Kits.
Automatically resynchronizes data between the primary server and backup servers upon system recovery.
Monitors the health of the underlying system components and performs a local recovery in the event of failure.
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

SIOS 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, SIOS DataKeeper makes an entry to an intent log file for every write made to the primary device.If a large amount of data is written, the I/O performance may decrease temporarily because that data takes priority in the queue for transmission to the other nodes.

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.

INFORMATION: When creating async mirrors, DataKeeper uses, by default, write-behind with no value to set the number of outstanding target write operations to the default of 256. If the LKDR_ASYNC_LIMIT value is set in the defaults file to something greater than 2, this value will be used.

Once the number of outstanding write operations to the target reaches this value, the mirror will revert to synchronous mode until the number drops below the set value.

Assuming a 4K block size, if the value is left at the default (asynchronous limit of 256 writes), you would have a maximum of 1MB of data in transit.

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.