Hey,
Maybe late than never... and perhaps you moved on. The reason for having 2 DRDB volumes is that you in a 2 node cluster practically always need to resolve split-brain scenarios manually. You need to decide, which side holds the best or most accurate data if you like, and which sides holds data that will be discarded.
The author of that article says, that is is easier to discard a side, if you have one volume normally used by VMs on one node. And another volume for VMs on the node. IF you were to experience a disconnect between the 2 nodes, we know that VMs are running on a specific node using a specific DRDB volume. So it is easier to point at a DRDB node that holds the most recent data.
If you have 1 volume for nodes on both nodes, then this works fine when both nodes are up and connected, and changes are synchronised between the nodes. But as soon as a split brain occurs, you will have changes unique on each side of the pond for the same DRDB volume, because you have active nodes on both sides in the same DRDB volume. To restore the DRDB cluster, you will have to decide which side to keep, until then, the DRDB cluster is "broken" and running in standalone mode.
As I'm working though the mechanics of this, I realise that under normal circumstances I can move a single VM to the other node, and not move DRDB volume. But I would be putting myself at risk, when the cluster breaks while I have VMs on both nodes using the same DRDB volume. It would be best to move ALL VMs using a DRDM volume to the other node, so you again would be able to point to a single side, from which we will keep the changes. If you want to move all VMs for service for example, I guess that would be safe enough. You can also start all VMs on the other node, if a node is physically down, because again, you know all the recent changes are on one side or the other.
The thing you don't want, is some VMs on one node, and some on the other node, using the SAME DRDB volume, when the synchronisation breaks. Simply because you might be forced to make a choice which changes (certain VMs) you want to keep and which to discard (other VMs). If you want to move a VM permanently to the other node, you would need to storage migrate it to the other DRDB volume. This would also be the case, if you chose to use a single DRDB volume, as you were asking about.
Hope this helps... even though it is an old post.
The ultimate solution for this type of HA setup would be 3 nodes or some other tiebreaker, this also applies to Proxmox itself. With 3 you can have a majority to determine who is down and who is not, and you will be able to establish an automatic failover and recovery.
