Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Apr 04, 2011 at 04:55:27PM -0500, Nathan Cerny wrote: > On Mon, Apr 4, 2011 at 11:33 AM, pberton <pascal.berton3 at free.fr> wrote: > > > > > Hi folks! > > I've read a few posts talking about DRBD vs. VMFS3, but none seem to answer > > my question. May be someone can help. Here's the picture : > > I'm thinking of a primary/primary config, with ESXs on both sides. If > > hosted > > VMs do snapshots or make use of thin disks on both sides, corresponding > > files will grow step by step or should I say, block by block, each new > > block > > allocation being securized using SCSI reservations from the host running > > that VM. > > Now, guess 2 VMs on different sides of the replication chain make a new > > block request at the same time. What would happen ? I suppose SCSI > > reservations are not replicated by DRBD, therefore, each host will make its > > own reservation and potentially allow the same block to both VMs leading to > > corruption ? > > Has anyone already played with this kind of architecture ? Is > > primary/primary definitely a no-no for such architectures or is there some > > magic feature that can help me out build something safe ? > > Thanks by advance! > > Best regards, > > Pascal. > > > You have to run Protocol C to do primary/primary. Protocol C ensures both > nodes know of each block write before it's reported as complete. So in your > instance, one VM would get the block, and another would get a different > block. There is no chance of them both reserving the same block. > > At least that's how I understand Protocol C. I'm sure someone else will > correct me if I'm mistaken! DRBD is not SCSI. So if you need to talk SCSI, and to SCSI reservations, and want to involve DRBD somewhere somehow, you'd have put an iSCSI target on top of DRBD. To the best of my knowledge, there is no "cluster aware" iSCSI target, so please do not try to run two independent iSCSI targets on dual-Primary DRBD. They don't know of each other, and will happily give out concurrent reservations, or corrupt your data, and there is nothing DRBD could do about that. Which establishes that we have only _one_ iSCSI target on top of DRBD, and this becomes a "classical" Single-Primary DRBD failover solution. And now, if that iSCSI target supports the flavour of reservations required by your use case, you are good. If not, too bad, find an other target that does. But that's still nothing DRBD could do anything about, not in Single/Dual/no-Primary at all mode, and regardless of wire protocol. Now, if this is not about SCSI reservations, but something else, please give more details what exactly would be the requirements. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com