<html><head/><body><html><head></head><body>There are only two translators that use the network, server and client. I'm unclear how these communication groups would get applied.<br>
<br>
I lean a little bit toward being against solving network problems with application complexity. Can't these problems be solved with split horizon DNS and/or static routing?<br><br><div class="gmail_quote">Justin Clift <jclift@redhat.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px">Hey all,<br /><br />This is an idea that's been on my mind for a while, to overcome a<br />fundamental problem Gluster has with some network common topologies.<br />(thanks to Niels de Vos for letting me bounce ideas off him btw)<br /><br />Most corp places I've worked have multiple network interfaces on their<br />storage boxes, each for a specific purpose (eg backup interface, client<br />interface, general connectivity interface, and more).<br /><br />At present Gluster can't really make use of this kind of topology<br />effectively. Having some interfaces only for client traffic, other<br />interfaces for peer replication traffic just isn't how it's designed.<br /><br />To address this, we could introduce "connection groups".<br /><br />Whereby we let the Gluster sysadmin define "connection groups"<br />(eg "client-group" "replication-group"), and the list of<br />host+interfaces
that belong to each group.<br /><br />On the command line, it could look something like this:<br /><br />$ sudo gluster connection-group create client-group gluster1:eth0 gluster2:eth0 gluster3:eth0 gluster4:eth0<br />(being the first ethernet interface on 4 gluster boxes)<br />$ sudo gluster connection-group create replication-group gluster1:ib0 gluster2:ib0 gluster3:ib0 gluster4:ib0<br />(being the first Infiniband interface on 4 gluster boxes)<br />$ sudo gluster connection-group create mygroup1 gluster1:ib1 gluster2:ib1 gluster3:ib1 gluster4:ib1<br />(some other group the Sysadmin wants)<br /><br />We'll probably need to add an option to the peer probe command<br />so a connection group can be specified. Something like:<br /><br />$ sudo gluster peer probe gluster3 --conngroup=mygroup1<br /><br />Note - I'm not sure if $hostname:$interface is really a crash hot idea here.<br />We might want to do $hostname:$IP instead, so we don't get confused by<br />not-straight-forward
interfaces such as bonding, IP aliasing, and maybe<br />IPoIB/RDMA.<br /><br />When a client mounts a volume, it should specify a group. Gluster then<br />gives it the connection details for the hosts:interfaces in its group.<br /><br />The Sysadmin would then associate connection groups to their volumes:<br /><br />$ sudo gluster volume groupadd somevolume client-group<br />$ sudo gluster volume groupadd othervolume mygroup1<br /><br />We could also set one of the groups as a default (for clients that<br />don't say what their group is):<br /><br />$ sudo gluster volume groupdefault somevolume client-group<br /><br />Client's could specify which group it belongs to on the mount command<br />line:<br /><br />$ sudo mount -t glusterfs -o conngroup=XXX gluster1:somevol /my/mount/point<br /><br />2nd note - We might also need to have a distinction of "peer groups"<br />and "volume groups". Not sure atm, and I'm falling asleep at the<br />keyboard but want to get this sent. :)<br
/><br />Thoughts? :)<br /><br />Regards and best wishes,<br /><br />Justin Clift<br /><br />--<br />Open Source and Standards @ Red Hat<br /><br /><a href="http://twitter.com/realjustinclift">twitter.com/realjustinclift</a><br /><br /><br /><hr /><br />Gluster-devel mailing list<br />Gluster-devel@nongnu.org<br /><a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br /></pre></blockquote></div></body></html></body></html>