On 27/06/2013, at 10:13 AM, Kaushal M wrote: <snip> > I'm right now leaning towards a hybrid approach of using a translation > layer and using connection groups. We could use any of the addresses > associated with a peer, with the commands. Internally, we will be > maintaining a list of addresses associated with peers which will make > the internal translation easier. We will use UUIDs exclusively > internally, this includes the volfiles and other generated config > files. > I'll write a detailed description of this and send it here for comments soon. Cool. :) As a thought (maybe for a later implementation so the bar isn't too high at the start) it would also be useful to be able to specify a connection group to be used just for server-server replication traffic. (at least for self heal traffic, unsure about geo-replication) Something like this: Create two connection groups **************************** $ sudo gluster connection-group create somegroup1 gluster1:172.16.101.1 gluster2:172.16.101.2 gluster3:172.16.101.3 connection-group created: somegroup1 (creates a group using the 1st Infiniband interface IP on my 3 gluster dev boxes) $ sudo gluster connection-group create somegroup2 gluster1:172.16.102.1 gluster2:172.16.102.2 gluster3:172.16.102.3 connection-group created: somegroup2 (creates a group using the 2nd Infiniband interface IP on my 3 gluster dev boxes) Associate the new connection groups with volumes ************************************************ $ sudo gluster volume groupreplication myfirstvolume somegroup1 volume myfirstvolume replication group: somegroup1 (self heal traffic for "myfirstvolume" will now use the first IB interface's IP for my boxes) $ sudo gluster volume groupreplication mysecondvolume somegroup2 volume mysecondvolume replication group: somegroup2 (self heal traffic for "mysecondvolume" will now use the second IB interface's IP for my boxes) Seems like a sensible approach (thus far). :) + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift
