DRBD – Setup DRBD on Raw Disk Block Device

drbdraw-disk

I try to setup DRBD on a raw disk device /dev/sdb without partition table, nor LVM stack PV/VG/LV

As this disk is virtual and hypervisor I use allow on-the-fly disk extension, I do not want to bother with LVM operations or re-partitioning when comes time to extend my DRBD file system

My resource definition cannot be simpler

resource data {
  device  /dev/drbd1;
  meta-disk internal;
  disk    /dev/sdb;
  on node1 {
    address 10.10.10.16:7789;
  }
  on node2 {
    address 10.10.10.17:7789;
  }
}

Create metadata works

# drbdadm create-md data
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.

But attach operation fails

 # drbdadm attach data
 1: Failure: (127) Device minor not allocated
 additional info from kernel:
 unknown minor
 Command 'drbdsetup-84 attach 1 /dev/sdb /dev/sdb internal' terminated with exit code 10

Error message really sounds like command expect a partition table index as device minor code.

How should I attach a raw device to DRBD resource ?

Best Answer

drbdadm attach data isn't the only command you want to be using after creating the metadata.

One of the following procedures should work for getting your device up:

drbdadm create-md data
drbdadm up data

-- or --

drbdadm create-md data
drbdsetup-84 new-resource data
drbdsetup-84 new-minor data 1 0 
drbdmeta 1 v08 /dev/sdb internal apply-al 
drbdsetup-84 attach 1 /dev/sdb /dev/sdb internal
drbdsetup-84 connect data ipv4:10.10.10.16:7789 ipv4:10.10.10.17:7789 --protocol=C

Once you've done that, you'll have a device with a connection state of "Connected" and a disk state of "Inconsistent/ Inconsistent"; this will always/ only be the case after you create brand new meta-data on both nodes.

From there, simply pick one node to promote to Primary, which will cause DRBD to sync from Primary => Secondary:

# drbdadm primary data --force 

You should never under normal circumstances need to use --force to promote your DRBD device from here on out.

However, you also said:

As this disk is virtual and hypervisor I use allow on-the-fly disk extension, I do not want to bother with LVM operations or re-partitioning when comes time to extend my DRBD file system

That probably isn't going to work with DRBD. DRBD puts it's metadata at the end of the block device, and in that metadata the number of blocks (and other things) are tracked. Dynamically extending the backing block device is likely going to cause problems for you.

Related Topic