Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Digimer wrote: > > > > 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. Why does the partition only have one source, when both VM's are running ? Why will the inodes not be altered at the same time when i have both VM's running ? > > The risk here, though, is with split-brains. > > Consider this; > > You have two partition on your DRBD; one each for two VMs. In Why do i have two partitions ? I thought, from the VM's point of view, i have one partition. I thought that DRBD makes out of two physical independent devices one logical device, like a RAID1. Right ? Or do you just mean that every VM has one local partition, which is synchronized with the other, remote partition, using DRBD ? > 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. > Currently, i'm totally confused. Single primary means that a resoure is only primary on one node. Write access to the primary node is synchronized via DRBD to the other node. Right ? Dual primary means that a resource is primary on both nodes. That means that write acces to node A is replicated to node B, and vice versa, at hte same time. Right ? Question: can i run two identical VM's, one on node A and one on node B, having DRBD configured as a dual primary ? Please don't forget that i want to install my KVM's into plain LV's, without any filesystem. Sorry for bothering you, but i like to understand the techniques i use. Bernd