On Tue, 10 Feb 2009 15:56:21 +0530, Anand Avati <avati@xxxxxxxxxxxxx> wrote: >> 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? > > GlusterFS relies upon the transport being reliable. Using multicast > for reliable transfers is quite tricky and would need considerable > redesign of the current codebase atleast. What about using an external high-bandwidth helper/hub node to do the (inverse) multiplexing for writes? This wouldn't require using UDP multicast. Gordan
