Joshua,<div> You are right. Even though GlusterFS native client provides redundancy and high availability, the act of mounting itself is from a single server. Standard way to work around this is to have a ucarp based VIP just for the purpose of mounting. Other ways include techniques mentioned above to detect mount failures in rc.local etc. The volumes must always be created by specifying bricks with real IP.</div>
<div><br></div><div>Avati<br><br><div class="gmail_quote">On Thu, Jun 9, 2011 at 2:50 AM, Joshua Baker-LePain <span dir="ltr"><<a href="mailto:jlb17@duke.edu">jlb17@duke.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Wed, 8 Jun 2011 at 4:44pm, Joe Landman wrote<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06/08/2011 04:37 PM, Joshua Baker-LePain wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BTW: You need a virtual ip for ucarp<br>
</blockquote>
<br>
As I said, that's what I'm doing now -- using the virtual IP address<br>
managed by ucarp in my fstab line. But Craig Carl from Gluster told the<br>
OP in this thread specifically to mount using the real IP address of a<br>
server when using the GlusterFS client, *not* to use the ucarp VIP.<br>
<br>
So I'm officially confused.<br>
</blockquote>
<br>
GlusterFS client side gets its config from the server, and makes connections to each server. Any of the GlusterFS servers may be used for the mount, and the client will connect to all of them. If one of the servers goes away, and you have a replicated or HA setup, you shouldn't see any client side issues.<br>
</blockquote>
<br></div>
Hrm, apparently I'm not making myself clear. I fully understand the redundancy of a replicated glusterfs volume mounted on a client. After the mount, the client will not see any issues unless both members of a replica pair (or all 4 members of a replica quad, etc) go down.<br>
<br>
My concern is at mount time. Mounting via the glusterfs client (at the command line or via fstab) requires a single IP address. That server is contacted to get the volume config (which inclues the IP addresses of the rest of the servers). If that IP address is a regular IP address that points at a single server and that server is down *at client mount time*, then the mount will fail.<br>
<br>
I have setup ucarp for the sole purpose of using the ucarp managed VIP in my fstab lines, so that mounts will succeed even if some of the servers are down. All the "gluster" commands to create the volumes were done using real IP addresses. Does Craig Carl's advice not to use ucarp with the native glusterfs client apply in my siuation?<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ucarp would be needed for the NFS side of the equation. round robin DNS is useful in both cases.<br>
</blockquote>
<br></div>
Again, I don't use DNS for my cluster, so that solution is out.<div class="im"><br>
<br>
-- <br>
Joshua Baker-LePain<br>
QB3 Shared Cluster Sysadmin<br>
UCSF<br></div><div><div></div><div class="h5">
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://gluster.org/cgi-bin/mailman/listinfo/gluster-users</a><br>
</div></div></blockquote></div><br></div>