Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 01/06/2011 06:25 PM, Lentes, Bernd wrote: > > Digimer wrote: > > On 01/06/2011 03:14 PM, Lentes, Bernd wrote: >>> How can a dual primary solution works, when i install the VM's in a plain lv ? Don't i need a cluster aware filesystem (like OCFS2) for a dual primary solution ? >>> >>> Bernd > >> Dual-Primary does not require a cluster. The LVM is below the DRBD >> device, as you've described your implementation, so it has no expose to >> the cluster. > >> Each LV is, ultimately, an OS and totally independent. The data on each >> LV will not be modified from both nodes at the same time, so cluster >> locking is not needed (unless you tried to start the VM on both nodes, >> which would fail for many other reasons, too). > > Hi, > > i thought dual primary means, that i have services (like a VM) running on both nodes. Am i wrong ? > > > Bernd That is a use for dual-primary, but not technically the same thing. All that dual-primary gives you is block-level write ability from both nodes. What you run on top of it and whether or not that can be run from both nodes at the same time is a separate question. Ideally, it *should* be, but doesn't necessarily need to be. So in your case where each LV hosts a VM, locking is not needed. This is because the entirety of the partition has only one source. So the inodes contained in that partition will never be altered by two sources at the same time. The risk here, though, is with split-brains. Consider this; You have two partition on your DRBD; one each for two VMs. In the course of normal operation you have one VM running on NodeA and the other VM running on NodeB. DRBD Primary/Primary will allow this. Then though, you have a split brain. At the moment of the split brain, unless you've configured a stonith device in DRBD, either side will go off on their own and your VMs will continue to run. From this point on, both sides are "more up to date" than the other. This is because both are writing to their VM's partition. Now you are faced with a dilemma... In order to recover from a split-brain, you neen to manually invalidate one side and then sync from the other. How do you decide which is better to lose? The only option now is to 'dd' the partition from the active VM over to the other side, and then invalidate it and let it sync back. This will be very time consuming. So if you want to run Primary/Primary, be very sure that you have a properly configured stonith device (aka, fence device). This way, the moment there is a split brain, one of the nodes will die. This is harsh, but at least you can then start the VM up on the surviving node and avoid the massive head-ache of manually ensuring the one Node's DRBD resource is fully up to date across both partitions. -- Digimer E-Mail: digimer at alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org