[DRBD-user] Proxmox 4.2 with DRBD9 (.drbdctrl Primary/Secondary)

Robert Altnoeder robert.altnoeder at linbit.com
Fri Jun 10 11:34:06 CEST 2016

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

drbdmanage not working if the .drbdctrl resource is explicitly set to
Primary mode is actually the expected behavior, but the .drbdctrl
resource is normally in auto-promote mode after creation by drbdmanage.

It might be the case that it had been set to Primary by accident, e.g.
by a buggy script in Proxmox 4.2 (however, I am not aware of such a bug
as of today) or by running something like 'drbdadm primary all'.

The reason for this is how drbdmanage communicates changes:

The control volumes are used by drbdmanage to exchange information. For
example, when a node is added to the drbdmanage cluster, the node entry
is written to the control volumes, which involves an auto-promotion to
Primary caused by opening the control volumes for writing. As soon as
the control volumes are closed again, an auto-demotion to Secondary
takes place, a DRBD event is sent to existing/connected drbdmanage
nodes, and this event will trigger loading of the changes on all
drbdmanage nodes. If a new node joins, then the join command will also
read the information on the control volume.

Additionally, the Primary/Secondary switching is used as a means of
serialization (locking) between drbdmanage nodes. There can be either
only one writer (Primary) and no readers, or multiple readers
(Secondary) and no writers (basically an rw-lock). This is necessary to
prevent other nodes from reading incomplete/partial updates while
another node is still in the process of writing those updates.

If the .drbdctrl resource ends up being explicitly set to Primary, it
will never auto-demote after drbdmanage closes the control volumes, but
will instead stay in Primary mode, thereby locking out all readers. As
the join process on any other nodes needs to read, and potentially even
write, information from/to the control volumes, it will hang waiting for
the lock required to read the information, and in the meantime the D-Bus
connection between the drbdmanage client and the drbdmanage server on
the joining node will time out, causing the D-Bus error to appear.

For this reason, the .drbdctrl resource containing the control volumes
must not stay in Primary mode permanently on any node, because this will
prevent all other drbdmanage nodes from receiving any new information.


On 06/09/2016 08:43 PM, Jason Romo wrote:
> Ok LinBit found a bug that was causing DRBD9 not to work.  You will
> find you get pending actions or DBus error when using drbdmanage.  To
> resolve this set:
> Set Volume 0 & 1 to secondary.  If set to Primary it breaks.  This
> could be just with the code on Proxmox 4.2.
> drbdadm secondary .drbdctrl
> This will get you working that you can use DRBD9 with Proxmox 4.2.
> LinBit did a great job resolving the issue.  Sure a patch is coming.
> Regards,
> Jason
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20160610/6a934252/attachment.htm>

More information about the drbd-user mailing list