[DRBD-user] DRBD 9 auto-promote not changing role to Primary, but is writable

[Doug Cahill]

I'm configuring a two node setup with drbd 9.0.20-1 on CentOS 7
(3.10.0-957.1.3.el7.x86_64) with a single resource backed by an SSDs.  I've
explicitly enabled auto-promote in my resource configuration to use this
feature.

The drbd device is being used in a single-primary configuration as a zpool
SLOG device.  The zpool is only ever imported on one node at a time and the
import is successful during cluster failover events between nodes.  I
confirmed through zdb that the zpool includes the configured drbd device
path.

My concern is that the drbdadm status output shows the Role of the drbd
resource as "Secondary" on both sides.  The documentations reads that the
drbd resource will be auto promoted to primary when it is opened for
writing.

drbdadm status
r0 role:Secondary
  disk:UpToDate
  dccdx0 role:Secondary
    peer-disk:UpToDate

My device should be opened for writing when the zpool is imported.  I've
even tested writing to the pool with "dd oflag=sync" to force sync writes
to the SLOG which is the drbd resource.  The drbd device never changes the
reported state but it appears to be writable.

Have I misconfigured my drbd resource for an auto-promote configuration
and/or is my use case to obscure for auto-promote to detect the device is
being written to when used in a zpool?

=========== /etc/drbd.d/r0.res
resource r0 {
    disk "/dev/disk/by-path/pci-0000:18:00.0-scsi-0:0:2:0-part1";
    meta-disk internal;
    device minor 0;

    on dccdx0 {
        address 192.0.2.10:7000;
    }

    on dccdx1 {
        address 192.0.2.20:7000;
    }

    disk {
        read-balancing when-congested-remote;
        no-disk-flushes;
        no-md-flushes;
        # al-updates no; # turn off al-tracking; requires full sync on crash
        c-fill-target 4M;
        resync-rate 500M;
        c-max-rate 1000M;
        c-min-rate 700M;
    }

    net {
        sndbuf-size 10M;
        rcvbuf-size 10M;
        max-buffers 20000;
        fencing resource-and-stonith;
    }
}

-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20191113/89deabc3/attachment.htm>