Introduction
High availability is a hot topic for service companies which offer their
services via electronic networks. As Linux is in a position to gain a
market share in newly build systems, there is a lot of interest in HA
solutions for Linux based systems.
Quite a number of conventional HA solutions are brought to Linux these
days and most of them are based on a shared storage device.
DRBD, however, is a more Linux-like approach to the field. As
Linux brought PC hardware into the server market, DRBD brings HA
clustering to the PC hardware. High availability in storage is realized
by replicating the storage via off-the-shelf networking equipment to a
second machine.
Since prices for gigabit ethernet hardware have declined and since 10
GB ethernet has become the standard, currently available off-the-shelf
hardware offers the required performance.
Basic problems and algorithms
In this abstract only the areas of interest are mentioned, the complete
algorithms are described in the final paper:
In order to achieve shared-disk like semantics over a networking protocol,
DRBD has to guarantee not to violate write-ordering constraints imposed
by upper software layers like journaling-file-systems.
In the event of a cluster restart, the nodes have to find the node with
the up-to-date data (or the fact that all nodes are up-to-date).
Background resynchronization in case of a node joining a degraded cluster.
New requirements in DRBD 0.7
Quicker resynchronization. If no bitmap of out-of-date blocks is available,
use hash values of blocks to speed up resynchronization.
In embedded applications and unmonitored installations, the remaining
node must be able to continue to offer the service if a node is
permanently damaged.
Decoupling of resynchronization from the node's role-assignment. Real-world
use shows that this is often required and eases the interaction between
DRBD and the cluster manager. This of course requires that DRBD offers
a consistent view of the data even if the node's backing storage is the
target of a resynchronization process.
Shared disk mode for use with openGFS. Although the block operation will
support active/active configuration, it will turn out if it is usable
without a common view of the cluster membership.
Conclusion
DRBD 0.6 proved its applicability for a number of purposes, mainly
deployments in data-centers. Its replication performance was sufficient,
but resynchronization was too slow.
DRBD 0.7 will be applicable in embedded environments as well and will
increase the possible storage size by speeding up resynchronization.
|