[DRBD-user] Fwd: DRBD primary/primary vs. VMFS3 ?

pberton pascal.berton3 at free.fr
Fri Apr 8 19:45:36 CEST 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Thank you all, guys!

Lars, that's what I was afraid of. Your explanation makes sense, I keep it
for future use.
Patrick, this cross-replicated architecture is what I was planning first,
and obviously I'll keep my plans. :-)

Just curious : Does anyone know how folks such as FalconStore and DataCore,
who AFAIK claim that they do support fully active/active replication, do
implement their stuff ? Or is it just "well-packed" cross-replication just
like Patrick talks about ?

Thanks to all 3 however!

Best regards,

Pascal.


Nathan Cerny wrote:
> 
> Helps if I send this to the list...
> 
> ---------- Forwarded message ----------
> From: Nathan Cerny <ncerny at gmail.com>
> Date: Mon, Apr 4, 2011 at 4:54 PM
> Subject: Re: [DRBD-user] DRBD primary/primary vs. VMFS3 ?
> To: pberton <pascal.berton3 at free.fr>
> 
> 
> 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!
> 
> 
> 
> 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.
>> --
>> View this message in context:
>> http://old.nabble.com/DRBD-primary-primary-vs.-VMFS3---tp31315179p31315179.html
>> Sent from the DRBD - User mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> drbd-user mailing list
>> drbd-user at lists.linbit.com
>> http://lists.linbit.com/mailman/listinfo/drbd-user
>>
> 
> 
> 
> -- 
> Nathan Cerny
> 
> -------------------------------------------------------------------------------
> "I have always wished that my computer would be as easy to use as my
> telephone. My wish has come true. I no longer know how to use my
> telephone."
> --Bjarne Stroustrup, Danish computer scientist
> -------------------------------------------------------------------------------
> 
> 
> 
> 
> -- 
> Nathan Cerny
> 
> -------------------------------------------------------------------------------
> "I have always wished that my computer would be as easy to use as my
> telephone. My wish has come true. I no longer know how to use my
> telephone."
> --Bjarne Stroustrup, Danish computer scientist
> -------------------------------------------------------------------------------
> 
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
> 
> 

-- 
View this message in context: http://old.nabble.com/DRBD-primary-primary-vs.-VMFS3---tp31315179p31354081.html
Sent from the DRBD - User mailing list archive at Nabble.com.




More information about the drbd-user mailing list