Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Dec 22, 2016 at 10:48:48PM +0100, Roberto Resoli wrote: > (Bad start, forget the message with the wrong title...) > > I start a new thread, as suggested in [1]; > > I would like to test the new Linbit repositorry for Proxmox Virtual > Environment [2], and I need some preliminary information before starting. > > I refer to these statments from [1]: > > > For the second thing: 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. 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). 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). So, this is essentially a stop-the-world and then upgrade scenario. Regards, rck