Data synchronous replication between node and brain fissure repair using DRBD

Distributed replicated Block Device (DRBD) is a software-free, shared-sharing, storage-replication solution that mirrors the contents of a piece of equipment between servers.

Data mirroring: Real-time, transparent, synchronous (returned after all successful servers), asynchronous (returned after the local server succeeds)

DRBD's core functionality is implemented through the Linux kernel, closest to the system's IO stack, but it does not magically add features such as the crash of the EXT3 file system.

The DRBD location is below the file system and is closer to the OS kernel and IO stack than the filesystem.

Tools:

DRBDADM: Advanced management tools, managing/etc/drbd.conf, sending instructions to Drbdsetup and Drbdmeta,

Drbdsetup: Configure the DRBD module to be loaded into the kernel, usually rarely used directly

Drbdmeta: Manage meta data structures, usually rarely used directly.

In DRBD, resources are specific to all aspects of a replicated storage device. including resource names, DRBD devices (/DEV/DRBDM, where m is the device minimum, maximum can to 147), disk configuration (so that local data can be used for DRBD), network configuration (communication with the other)

Each resource has a role, which is primary or secondary, hereinafter referred to as "master" and "standby"

The primary role's DRBD devices can be read and written without restriction, such as creating and mapping file systems, raw or direct IO access to block devices.

The DRBD device of the standby accepts all modifications from the other, but cannot be read or written by the application, or even read-only.

Roles can change.

The DRBD is composed of kernel modules and related scripts to build high-availability clusters. It is implemented through the network to mirror the entire device. You can think of it as a network RAID;DRBD responsible for receiving data, writing data to a local disk, and sending it to another host. The other host then saves the data to its own disk.

Principle:

Each device (DRBD

Provides more than one device) has a state that may be a ' primary ' state or ' auxiliary ' state. On a node with a major device, the application should be able to run and access the set

Prepared (/DEV/NBX). Each write is sent to a local low-level device and to a node with a ' secondary ' state device. A secondary device can simply write data to its lower-level block device.

Read data is usually done locally.

If the primary node fails, the heartbeat converts the secondary device to the main state and launches the application on it. (If you use it with no log FS, you need to run fsck).

If the failed node recovers, it becomes a new secondary node and must keep its content synchronized with the contents of the primary node. Of course, these operations do not interfere with the service in the background.

Environment: centos6.0 Modified hosts

node1:192.168.182.128

node2:192.168.182.131

Each node is a blank partition (without creating any partitions) or new disk; This is the new disk (8G)

1, yum-y install GCC kernel-devel kernel-headers Flex