DRBD HOWTO

David Krovich

 
 

HOWTO for DRBD

Table of Contents
1. Introduction
1.1. What is DRBD?
1.2. What is the scope of drbd, what else do I need to build HA clusters?
1.3. How does it work ?
1.4. How is drbd related to current HA clusters ?
2. Installation
2.1. Download the software
2.2. Compile the package
2.3. Test loading the drbd module
2.4. 2.2.x Kernel Considerations
2.5. Unresolved symbols
3. Using drbdsetup
3.1. drbdsetup
3.2. Example of using drbdsetup
4. drbd.conf Sample Configuration
4.1. drbd.conf
4.2. Sample drbd.conf setup
5. Integrating with the heartbeat package
5.1. What is heartbeat?
5.2. drbd heartbeat scripts
5.3. Sample heartbeat integration - web server
5.4. Sample heartbeat integration - NFS server
6. Timeouts
6.1. How do timeouts work?
6.2. Why is a small timeout good?
6.3. Why are small timeouts leading to timeout/resync/connect?
6.4. What are "postpone packets"?
6.5. What should you do if you see this timeout/resync/connect pattern?
7. Miscellaneous
7.1. tl-size
7.2. I'm halfway through a SyncAll, but I realize that it is too slow!
8. Getting Support
8.1. Mailing List

1. Introduction

1.1. What is DRBD?

DRBD is a kernel module and associated scripts that provide a block device which is designed to build high availability clusters. This is done by mirroring a whole block device via (a dedicated) network. You could see it as a network raid

1.2. What is the scope of drbd, what else do I need to build HA clusters?

Drbd takes over the data, writes it to the local disk and sends it to the other host. On the other host, it takes it to the disk there.

The other components needed are a cluster membership service, which is supposed to be heartbeat, and some kind of application that works on top of a block device.

Examples:

  • A filesystem & fsck

  • A journaling FS.

  • A database with recovery capabilities.

1.3. How does it work ?

Each device (drbd provides more than one of these devices) has a state, which can be 'primary' or 'secondary'. On the node with the primary device the application is supposed to run and to access the device (/dev/nbX). Every write is sent to the local 'lower level block device' and to the node with the device in 'secondary' state. The secondary device simply writes the data to its lower level block device. Reads are always carried out locally.

If the primary node fails, heartbeat is switching the secondary device into primary state and starts the application there. (If you are using it with a non-journaling FS this involves running fsck)

If the failed node comes up again, it is a new secondary node and has to synchronise its content to the primary. This, of course, will happen whithout interruption of service in the background.

1.4. How is drbd related to current HA clusters ?

To my knowledge most current HA clusters (HP, Compaq, ...) are using shared storage devices, thus the storage devices are connected to more than one node (This can be done with shared SCSI busses or Fibre Channel).

Drbd gives you about the same semantics as a shared device, but it does not need any uncommon hardware. It runs on top of IP networks, which are to my impression less expensive than special storage networks.

Currently drbd grants read-write access only to one node at a time, which is sufficient for the usual fail-over HA cluster. Although it is currently not on my task list, it would not be a great effort to allow both nodes read-write access. This would be useful with GFS for example.

  Next
  Installation