[Gluster-devel] client config to access (mirrored) storage cluster

Daniel Maher dma+gluster at witbe.net
Wed Apr 2 10:12:20 UTC 2008


Hello all,

Consider the HA w/ Gluster document here :
http://www.gluster.org/docs/index.php/GlusterFS_1.3_High_Availability_Storage_with_GlusterFS

The description of the client spec file provided in the example notes :
"Currently we are using DNS Round Robin to connect to the cluster until
the High Availability Translator in version 1.4 is available."

And, of course, the spec file itself has :
option remote-host roundrobin.gluster.local       # DNS Round Robin

In this case, "roundrobin.gluster.local" points to three servers
(192.168.252.[123]), which is fine assuming each of those servers are
functional.  What would happen, however, if one of those servers
suffered a critical failure ?

Does Gluster cache all of the responses from a DNS query, or does it
just pick the first one ?  If the first usable response fails, will
Gluster attempt to resolve again ?  What if the refresh time for that
DNS entry is set high enough that the DNS server provides the same
response again and again ?

Or, put another way, if ClientA (by chance) resolves
roundrobin.gluster.local to 192.168.252.1, but .1 is currently down -
what happens ?

Is there a way to define multiple hosts in the volume declaration in
the client config ?  For example :
volume santa
  type protocol/client
  option transport-type tcp/client
  #option remote-host 192.168.252.1,192.168.252.2,192.16.252.3
  # OR SOMETHING LIKE
  option remote-host 192.168.252.1
  option remote-host 192.168.252.2
  option remote-host 192.168.252.3
  option remote-subvolume mailspool
end-volume

Ultimately, the big question i'm attempting to resolve is as follows :
What is the best practise method to define client connectivity to an HA
Gluster cluster ?

Thank you all.



-- 
Daniel Maher <dma AT witbe.net>





More information about the Gluster-devel mailing list