Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Ok... so in real world it is not possible GFS + DRBD only in LAN Brian R. Hellman wrote: > *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 >> > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user >