One other thing occurs to me - in cases where multicast isn't directly available, an externel helper/replicator would be equally useful for emulating a similar thing. For example, if I have 4 systems on 2Mb pipes (e.g. DSL) and have a system at a colo on a cheal all-I-can-eat 10Mb pipe, it would make sense for each machine to send it's writes ONLY to the colo-ed machine, which can then replicate the write to the 3 other systems. This means that systems on 2Mb pipes would still get 2Mb if write bandwidth. In the classic setup, they would only get (2/3)Mb of write bandwidth. I've been thinking about setting this up as 4 separate AFRs (each between one satellite node and the central node), but I am not sure whether writes would actually propagate. Can any of the devs hazard a guess as to what would happen? Would locking still work if each of the satellite nodes specifies the core replication node in it's AFR node list? The one problem with this that I can see is that the core node would also have to contain all the data - I cannot think of a way around this at the moment. Has anyone got any thoughts on this? Gordan On Thu, 05 Feb 2009 14:47:32 +0000, Gordan Bobic <gordan@xxxxxxxxxx> wrote: > I'm working on putting a WAN AFR setup at the moment, and it occurs to me > that the point-to-point nature of client-to-multiple-servers replication is > extremely inefficient. For example, if I have 4 nodes, that means that > every write has to be done 3 times over the WAN to 3 different remote > servers. > > So, it occurs to me that having multicast support would be very useful > because the writes would be sent out of the local network pipe once and > replicated further up the routing chain. > > Is there any support for this planned in the reasonably near future? > > Gordan > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel
