[DRBD-user] master/master over WAN with GFS

Brian R. Hellman brian at linbit.com
Tue Jul 14 19:22:57 CEST 2009

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

*lose their emails... o key got stuck.

Brian R. Hellman wrote:
> I could be done, but again like Lars said, performance will be very bad
> (unusable) and the likelihood/risk of split brain high.  As soon as your
> Internet providers link goes down, and it will, you'll have two
> different data sets without a way to merge them. Then you get the fun
> chore of deciding who gets to lose* their emails :)
> LINBIT - Your Way to High Availability
> 8152 SW Hall Blvd., Suite #209 : Beaverton, OR 97008
> http://www.linbit.com
> Mikel Jimenez wrote:
>> Ok Thnaks for the answers!!
>> So... there is not a way to have to machines synchronized over WAN and
>> the two machines with the filesystem mounted in RW ?
>> Thanks
>> Lars Ellenberg wrote:
>>> On Tue, Jul 14, 2009 at 05:58:14PM +0200, Lars Marowsky-Bree wrote:
>>>> On 2009-07-06T20:16:26, Mikel Jimenez <mikel at irontec.com> wrote:
>>>>> The users in LAN of A would access to server A and the users in LAN
>>>>> of B would access to server B.
>>>>> When I user access to the webmail or A looks the same that looks
>>>>> from B.
>>>>> We have a simetrical VPN between two sites.
>>>>> How does DRBD result    in this type of environment?
>>>>> I think that the best is "Protocol A" and Im looking for use
>>>>> DRBD-Proxy for compression, or Openvpn + LZO.
>>>>> Opinions?
>>>> The latency overhead - both DRBD and at the locking layer - will kill
>>>> the file system performance.
>>> appart from that, with dual-primary you _MUST_ replicate syncronously,
>>> thus: DRBD protocol C.
>>> for (hopefully) obvious reasons.
>>> I still have this idea of implementing a replication aware
>>> cluster file system locking layer mode, where lock _requests_ would be
>>> inserted into (or at least in order with) the replicated data stream, so
>>> it could be replicated asynchronously in theory.
>>> IFF it can be made to work, that is probably several manyears
>>> developement, though -- roughly estimated ;)
>> _______________________________________________
>> drbd-user mailing list
>> drbd-user at lists.linbit.com
>> http://lists.linbit.com/mailman/listinfo/drbd-user
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user

More information about the drbd-user mailing list