[DRBD-user] Testing new DRBD9 dedicated repo for PVE

Roberto Resoli roberto at resolutions.it
Fri Dec 23 12:22:00 CET 2016

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


Il 23/12/2016 09:48, Roland Kammerer ha scritto:

...

>>> ...There I would need more information. The version
>>> we ship and the one from proxmox are very different. In between these
>>> versions the architecture of DM was changed. Just as an example: If you
>>> have two nodes in your cluster and you started DM only on one node, it
>>> will never start up successfully. Or if only a minority of your overall
>>> nodes is operational, drbdmanage will refuse to start, as it waits for a
>>> majority.
>> For the cluster I will do the test on: it is a three node PVE 4.4-2
>> cluster, vm resides on two main nodes, while the third is dedicated to
>> provide quorum and DRBD9 replication only. I will start the test on this
>> node.
>>
>> First question. Is it possible to mix and match versions of drbdmanage
>> on the cluster?
>> I really would like to update the third node only at first, but now I
>> don't think it is possible, given the differences between proxmox
>> provided drbdmanage and linbit's one.

> The obvious: You could update *all*, there are entries in the control
> volume (the .drbdctrl resource acting as cluster DB) that are not used
> any more, but they are just ignored on the new version.

Ok, nice to know

> A mix-and-match isn't a good idea in that scenario. Let's assume you
> update the 3rd node only, then this would happen:
> 
> Assuming it is a node that has access to the .drbdctrl, it would try to
> become the leader (i.e., switching .drbdctrl to primary). 

ok

> Here it
> depends if the resource 
> is already primary on another node or not. Let's
> assume the "good" case, it loses the leader election and decides to
> become a satellite. The old nodes would not talk to the new node via
> TCP, but the new node expects the leader to talk to it, it would never
> receive it's initial configuration. It would just idle around. In order
> to remove any potential leftover (autogenerated .res files), the first
> thing a node does is to remove all the old autogenerated .res files. So
> by starting the new version, you lost all your DM .res files and can not
> even manually "drbdadm up" them. For completeness the "bad" case: The
> two old nodes idle around and have .drbdctrl as Secondary. The new one
> comes and decides to become the leader and switches .drbdctrl to
> Primary. The old nodes don't expect that, and would try to switch
> .drbdctrl to Primary to store some information (how things worked in the
> old version), but a leader never releases the .drbdctrl (new
> architecture).

Ok, this gives me a good hint about the differences between old and new
behaviour.

> 
> So, this is essentially a stop-the-world and then upgrade scenario.

I agree. Will try directly that.

Bye,
rob




More information about the drbd-user mailing list