<div dir="ltr"><div><div><div>Hi Atin,<br><br></div>You are right!!! I was using the version 3.5 in production. And when I&#39;ve checked the Gluster source code, I checked the wrong commit (not the latest commit in the master branch).<br><br></div>Currently, you&#39;ve already implemented my the proposed solution. It was done at the function gd_peerinfo_find_from_addrinfo, file xlators/mgmt/glusterd/src/glusterd-peer-utils.c.<br><br></div><div class="gmail_extra">Thanks for your tip! And sorry for any inconvenience.<br><div><div class="gmail_signature"><div dir="ltr"><br>--<br><b>Rarylson Freitas</b><br></div></div></div>
<br><div class="gmail_quote">On Thu, Jul 2, 2015 at 2:01 AM, Atin Mukherjee <span dir="ltr">&lt;<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Which gluster version are you using? Better peer identification feature<br>
(available 3.6 onwards) should tackle this problem IMO.<br>
<br>
~Atin<br>
<div><div class="h5"><br>
On 07/02/2015 10:05 AM, Rarylson Freitas wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; Recently, my company needed to change our hostnames used in the Gluster<br>
&gt; Pool.<br>
&gt;<br>
&gt; In a first moment, we have two Gluster Nodes called storage1 and storage2.<br>
&gt; Our volumes used two bricks: storage1:/MYVOLYME and storage2:/MYVOLUME. We<br>
&gt; put the storage1 and storage2 IPs in the /etc/hosts file of our nodes and<br>
&gt; in our client servers.<br>
&gt;<br>
&gt; After some time, more client servers started to using Gluster and we<br>
&gt; discovered that using hostnames without domain (using /etc/hosts) in all<br>
&gt; client servers is a pain in the a$$ :(. So, we decided to change them to<br>
&gt; something like <a href="http://storage1.mydomain.com" rel="noreferrer" target="_blank">storage1.mydomain.com</a> and <a href="http://storage2.mydomain.com" rel="noreferrer" target="_blank">storage2.mydomain.com</a>.<br>
&gt;<br>
&gt; Remember that, at this point, we had already some volumes (with bricks):<br>
&gt;<br>
&gt; $ gluster volume info MYVOL<br>
&gt; [...]<br>
&gt; Brick1: storage1:/MYDIR<br>
&gt; Brick1: storage2:/MYDIR<br>
&gt;<br>
&gt; For simplicity, let&#39;s consider that we had two Gluster Nodes, each one with<br>
&gt; the following entries in /etc/hosts:<br>
&gt;<br>
&gt; 10.10.10.1  storage1<br>
&gt; 10.10.10.2  storage2<br>
&gt;<br>
&gt; To implement the hostname changes, we&#39;ve changed the etc hosts file to:<br>
&gt;<br>
&gt; 10.10.10.1  storage1 <a href="http://storage1.mydomain.com" rel="noreferrer" target="_blank">storage1.mydomain.com</a><br>
&gt; 10.10.10.2  storage2 <a href="http://storage2.mydomain.com" rel="noreferrer" target="_blank">storage2.mydomain.com</a><br>
&gt;<br>
&gt; And we&#39;ve run in storage1:<br>
&gt;<br>
&gt; $ gluster peer probe <a href="http://storage2.mydomain.com" rel="noreferrer" target="_blank">storage2.mydomain.com</a><br>
&gt; peer probe: success<br>
&gt;<br>
&gt; Everything works well during some time, but the glusterd starts to fail<br>
&gt; after any reboot:<br>
&gt;<br>
&gt; $ service glusterfs-server status<br>
&gt; glusterfs-server start/running, process 14714<br>
&gt; $ service glusterfs-server restart<br>
&gt; glusterfs-server stop/waiting<br>
&gt; glusterfs-server start/running, process 14860<br>
&gt; $ service glusterfs-server status<br>
&gt; glusterfs-server stop/waiting<br>
&gt;<br>
&gt; To start the service again, it was necessary to rollback the hostname1<br>
&gt; config to storage2 in /var/lib/glusterd/peers/OUR_UUID.<br>
&gt;<br>
&gt; After some try and error, we discovered that if we change the order of the<br>
&gt; entries in /etc/hosts and repeat the process, everything worked.<br>
&gt;<br>
&gt; It is, from:<br>
&gt;<br>
&gt; 10.10.10.1  storage1 <a href="http://storage1.mydomain.com" rel="noreferrer" target="_blank">storage1.mydomain.com</a><br>
&gt; 10.10.10.2  storage2 <a href="http://storage2.mydomain.com" rel="noreferrer" target="_blank">storage2.mydomain.com</a><br>
&gt;<br>
&gt; To:<br>
&gt;<br>
&gt; 10.10.10.1  <a href="http://storage1.mydomain.com" rel="noreferrer" target="_blank">storage1.mydomain.com</a> storage1<br>
&gt; 10.10.10.2  <a href="http://storage2.mydomain.com" rel="noreferrer" target="_blank">storage2.mydomain.com</a> storage2<br>
&gt;<br>
&gt; And run:<br>
&gt;<br>
&gt; gluster peer probe <a href="http://storage2.mydomain.com" rel="noreferrer" target="_blank">storage2.mydomain.com</a><br>
&gt; service glusterfs-server restart<br>
&gt;<br>
&gt; So we&#39;ve checked the Glusterd debug log and checked the GlusterFS source<br>
&gt; code and discovered that the big secret was the function<br>
&gt; glusterd_friend_find_by_hostname, in the file<br>
&gt; xlators/mgmt/glusterd/src/glusterd-utils.c. This function is called for<br>
&gt; each brick that isn&#39;t a local brick and does the following things:<br>
&gt;<br>
</div></div>&gt;    - It checks if the brick hostname is equal to some peer hostname;<br>
&gt;    - If it&#39;s, this peer is our wanted friend;<br>
&gt;    - If not, it gets the brick IP (resolves the hostname using the function<br>
<span class="">&gt;    getaddrinfo) and checks if the brick IP is equal to the peer hostname;<br>
</span>&gt;       - It is, we could run gluster peer probe 10.10.10.2. Once the brick<br>
<span class="">&gt;       IP (storage2 resolves to 10.10.10.2) would have equal to the peer<br>
&gt;       &quot;hostname&quot; (10.10.10.2);<br>
</span>&gt;    - If it&#39;s, this peer is our wanted friend;<br>
&gt;    - If not, gets the reverse of the brick IP (using the function<br>
<span class="">&gt;    getnameinfo) and checks if the brick reverse is equal to the peer<br>
&gt;    hostname;<br>
</span>&gt;       - This is why changing the order of the entries in /etc/hosts worked<br>
<span class="">&gt;       as an workaround for us;<br>
</span>&gt;    - If not, returns and error (and Glusterd will fail).<br>
<span class="">&gt;<br>
&gt; However, we think that comparing the brick IP (resolving the brick<br>
&gt; hostname) and the peer IP (resolving the peer hostname) would be a simpler<br>
&gt; and more comprehensive solution. Once both brick and peer will have<br>
&gt; difference hostnames, but the same IP, it would work.<br>
&gt;<br>
&gt; The solution could be:<br>
&gt;<br>
</span>&gt;    - It checks if the brick hostname is equal to some peer hostname;<br>
&gt;    - If it&#39;s, this peer is our wanted friend;<br>
&gt;    - If not, it gets both the brick IP (resolves the hostname using the<br>
<span class="">&gt;    function getaddrinfo) and the peer IP (resolves the peer hostname) and,<br>
&gt;    for each IP pair, check if a brick IP is equal to a peer IP;<br>
</span>&gt;    - If it&#39;s, this peer is our wanted friend;<br>
&gt;    - If not, returns and error (and Glusterd will fail).<br>
<span class="">&gt;<br>
&gt; What do you think about it?<br>
&gt; --<br>
&gt;<br>
</span>&gt; *Rarylson Freitas*<br>
&gt; Computer Engineer<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Gluster-devel mailing list<br>
&gt; <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
&gt; <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
&gt;<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
~Atin<br>
</font></span></blockquote></div><br></div></div>