[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