SteelEye DataKeeper for Linux offers an alternative for customers who want to build a high availability cluster (using SteelEye LifeKeeper) without shared storage or who simply want to replicate business-critical data in real-time between servers.
SteelEye 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).
SteelEye 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.
Supports point-in-time data rewind to allow recovery of lost or corrupted data.
Built-in network compression allows higher maximum throughput on Wide Area Networks.
Supports all major file systems (see the LifeKeeper 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.
Understanding the differences between synchronous and asynchronous mirroring will help you choose the appropriate mirroring method for your application environment.
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.
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.
© 2012 SIOS Technology Corp., the industry's leading provider of business continuity solutions, data replication for continuous data protection.