Questions[drbd](server)

The DRBD documentation (in section Integrating DRBD with Pacemaker clusters) recommends that DRBD should be disabled in a Pacemaker cluster:

If you are employing the DRBD OCF resource agent, it is recommended that you defer DRBD startup, shutdown, promotion, and demotion exclusively to the OCF resource agent. That means that you should disable the DRBD init script: chkconfig drbd off.

Under systemd this would amount to systemctl disable drbd.service.

Is there any harm in enabling DRBD despite of this recommendation? The idea would be to enable DRBD, but to disable Corosync and Pacemaker, so that after a cluster node fails and reboots it will continue receiving DRBD-synced data but will otherwise remain "passive". This should allow for the failed node to be analyzed before it can reenter the cluster, but live data still being saved on both cluster nodes in the meantime. What is the rationale behind the recommendation that would outweigh this rationale?

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 ?

I am trying to setup an active/passive (2 nodes) Linux-HA cluster with corosync and pacemaker to hold a PostgreSQL-Database up and running. It works via DRBD and a service-ip. If node1 fails, node2 should take over. The same if PG runs on node2 and it fails. Everything works fine except the STONITH thing.

Between the nodes is an dedicated HA-connection (10.10.10.X), so I have the following interface configuration:

eth0            eth1            host
10.10.10.251    172.10.10.1     node1
10.10.10.252    172.10.10.2     node2

Stonith is enabled and I am testing with a ssh-agent to kill nodes.

crm configure property stonith-enabled=true
crm configure property stonith-action=poweroff
crm configure rsc_defaults resource-stickiness=100
crm configure property no-quorum-policy=ignore

crm configure primitive stonith_postgres stonith:external/ssh \
                params hostlist="node1 node2"
crm configure clone fencing_postgres stonith_postgres

crm_mon -1 shows:

============
Last updated: Mon Mar 19 15:21:11 2012
Stack: openais
Current DC: node2 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
4 Resources configured.
============

Online: [ node2 node1 ]

Full list of resources:

 Master/Slave Set: ms_drbd_postgres
     Masters: [ node1 ]
     Slaves: [ node2 ]
 Resource Group: postgres
     fs_postgres        (ocf::heartbeat:Filesystem):    Started node1
     virtual_ip_postgres        (ocf::heartbeat:IPaddr2):       Started node1
     postgresql (ocf::heartbeat:pgsql): Started node1
 Clone Set: fencing_postgres
     Started: [ node2 node1 ]

Problem is: when I cut the connection between the eth0-interfaces, it kills both nodes. I think it is a problem with the quorum, because there are just 2 nodes. But I don't want to add a 3rd node just for calculation of the right quorum.

Are there any ideas to solve this problem?

I have a Debian Xen DomU which has a DRBD mounted partition. I needed to resize this partition from 46G to 50G. I did the following:

• Stopped DRBD on the secondary node: /etc/init.d/drbd stop
• Increased the underlying LVM dist to 50 GB: lvresize -L 50G /lvm/device
• Started DRBD again and waited for the disk to sync: /etc/init.d/drbd start
• Switched Primaries. And performed the same on the other node.
• Stopped drbd on the now secondary DRBD node: /etc/init.d/drbd stop
• Increased the underlying LVM: lvresize -L 50G /lvm/device
• Started DRBD again and waited for the disk to sync: /etc/init.d/drbd start
• On both nodes issued: drbdadm resize drbd-device
• On the primary node issued a: resize2fs /dev/drbd0

I get this response:

$ resize2fs 1.40-WIP (14-Nov-2006)
The filesystem is already 12058624 blocks long.  Nothing to do!

Using fdisk, both the drbd0 and the sda device drbd is using report the size of the device as 49392123904. Which is consistent with what resize2fs is saying. (12058624x4096 [blocksize]).

My issue is that df isn't reporting the change to the disk size.

$ df -B 4096
/dev/drbd0            11869420  11155652    110968 100% /data

I have done this process before and had no issues. Is there something I am missing?

I'd like to consider the use of DRBD for data replication between a primary and secondary location. The initial plan is to establish a VPN tunnel between the two; the primary end using a slice of a dual T1 link and the secondary location setting on a cable / dsl line.

The secondary will exist for DR only - it will "never" replicate back to the primary.

Has anyone done/tired/using something like this and what are your experiences with it.

Linbit also has a (Paid) DRBD Proxy product that is supposed to be designed for operating across WAN type links (compression, multiple peers). Anyone tried this out?