<div dir="ltr"><div><div><div>Hi,<br><br></div>Recently, my company needed to change our hostnames used in the Gluster Pool.<br><br></div><div>In a first moment, we have two Gluster Nodes called <span style="font-family:monospace,monospace">storage1</span> and <span style="font-family:monospace,monospace">storage2</span>. Our volumes used two bricks: <span style="font-family:monospace,monospace">storage1:/MYVOLYME</span> and <span style="font-family:monospace,monospace">storage2:/MYVOLUME</span>. We put the <span style="font-family:monospace,monospace">storage1</span> and <span style="font-family:monospace,monospace">storage2</span> IPs in the <span style="font-family:monospace,monospace">/etc/hosts</span> file of our nodes and in our client servers.<br></div><div><br></div><div>After some time, more client servers started to using Gluster and we discovered that using hostnames without domain (using <span style="font-family:monospace,monospace">/etc/hosts</span>) in all client servers is a pain in the a$$ :(. So, we decided to change them to something like <span style="font-family:monospace,monospace"><a href="http://storage1.mydomain.com" target="_blank">storage1.mydomain.com</a></span> and <span style="font-family:monospace,monospace"><a href="http://storage2.mydomain.com" target="_blank">storage2.mydomain.com</a></span>.<br></div><div><br></div><div>Remember that, at this point, we had already some volumes (with bricks):<br><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">$ gluster volume info MYVOL<br>[...]<br>Brick1: storage1:/MYDIR<br>Brick1: storage2:/MYDIR</span><br></div><div><br></div>For simplicity, let&#39;s consider that we had two Gluster Nodes, each one with the following entries in <span style="font-family:monospace,monospace">/etc/hosts</span>:<br><span style="font-family:monospace,monospace"><br></span></div><span style="font-family:monospace,monospace">10.10.10.1  storage1<br></span><div><span style="font-family:monospace,monospace">10.10.10.2  storage2</span><br><br clear="all"><div><div><div><div><div><div><div>To implement the hostname changes, we&#39;ve changed the etc hosts file to:<br><br><span style="font-family:monospace,monospace">10.10.10.1  storage1 </span><span style="font-family:monospace,monospace"><a href="http://storage1.mydomain.com" target="_blank">storage1.mydomain.com</a><br></span><span style="font-family:monospace,monospace">10.10.10.2  storage2</span><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace"><a href="http://storage2.mydomain.com" target="_blank">storage2.mydomain.com</a></span><br><br></div><div>And we&#39;ve run in <span style="font-family:monospace,monospace">storage1</span>:<br><br></div><div><span style="font-family:monospace,monospace">$ gluster peer probe <a href="http://storage2.mydomain.com">storage2.mydomain.com</a><br>peer probe: success<br></span></div><div dir="ltr"><br></div><div>Everything works well during some time, but the glusterd starts to fail after any reboot:<br><br></div><div><span style="font-family:monospace,monospace">$ service glusterfs-server status<br></span></div><div dir="ltr"><span style="font-family:monospace,monospace">glusterfs-server start/running, process 14714<br></span><span style="font-family:monospace,monospace">$ service glusterfs-server restart<br>glusterfs-server stop/waiting<br>glusterfs-server start/running, process 14860<br>$ service glusterfs-server status<br>glusterfs-server stop/waiting</span><br><br></div><div dir="ltr">To start the service again, it was necessary to rollback the <span style="font-family:monospace,monospace">hostname1</span> config to <span style="font-family:monospace,monospace">storage2</span> in <span style="font-family:monospace,monospace">/var/lib/glusterd/peers/OUR_UUID</span>.<br><br></div><div>After some try and error, we discovered that if we change the order of the entries in /etc/hosts and repeat the process, everything worked.<br><br></div><div>It is, from:<br><br><span style="font-family:monospace,monospace">10.10.10.1  storage1 </span><span style="font-family:monospace,monospace"><a href="http://storage1.mydomain.com" target="_blank">storage1.mydomain.com</a><br></span><span style="font-family:monospace,monospace">10.10.10.2  storage2</span><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace"><a href="http://storage2.mydomain.com" target="_blank">storage2.mydomain.com</a></span><br><br></div><div>To:<br><br><span style="font-family:monospace,monospace">10.10.10.1  </span><span style="font-family:monospace,monospace"><a href="http://storage1.mydomain.com">storage1.mydomain.com</a> storage1<br></span><span style="font-family:monospace,monospace">10.10.10.2  </span><span style="font-family:monospace,monospace"></span><span style="font-family:monospace,monospace"><a href="http://storage2.mydomain.com">storage2.mydomain.com</a> storage2</span> <br><br></div><div>And run:<br><br><span style="font-family:monospace,monospace">gluster peer probe <a href="http://storage2.mydomain.com">storage2.mydomain.com</a></span><br><span style="font-family:monospace,monospace">service glusterfs-server restart<br></span></div><div dir="ltr"><br></div><div dir="ltr">So we&#39;ve checked the Glusterd debug log and checked the GlusterFS source code and discovered that the big secret was the functio<code>n glusterd_friend_find_by_hostname</code>, in the file <span style="font-family:monospace,monospace">xlators/mgmt/glusterd/src/glusterd-utils.c</span>. This function is called for each brick that isn&#39;t a local brick and does the following things:<br><ul><li>It checks if the brick hostname is equal to some peer hostname;</li><li>If it&#39;s, this peer is our wanted friend;</li><li>If not, it gets the brick IP (resolves the hostname using the function<code> getaddrinfo</code>) and checks if the brick IP is equal to the peer hostname;</li><ul><li>It is, we could run <span style="font-family:monospace,monospace">gluster peer probe 10.10.10.2</span><span style="font-family:arial,helvetica,sans-serif">. Once </span><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">the brick IP (</font>storage2<font face="arial,helvetica,sans-serif"> resolves to </font></span><span style="font-family:arial,helvetica,sans-serif">10.10.10.2</span><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">)</font> </span><span style="font-family:arial,helvetica,sans-serif">would have equal to the peer &quot;hostname&quot; (10.10.10.2);</span></li></ul><li><span style="font-family:arial,helvetica,sans-serif">If it&#39;s, </span>this peer is our wanted friend;</li><li>If not, gets the reverse of the brick IP (using the function <code>getnameinfo</code>) and checks if the brick reverse is equal to the peer hostname;</li><ul><li>This is why changing the order of the entries in <span style="font-family:monospace,monospace">/etc/hosts</span> worked as an workaround for us;</li></ul><li>If not, returns and error (and Glusterd will fail).</li></ul><p>However, we think that comparing the brick IP (resolving the brick hostname) and the peer IP (resolving the peer hostname) would be a simpler and more comprehensive solution. Once both brick and peer will have difference hostnames, but the same IP, it would work.</p><p>The solution could be:</p><ul><li>It checks if the brick hostname is equal to some peer hostname;</li><li>If it&#39;s, this peer is our wanted friend;</li><li>If not, it gets both the brick IP (resolves the hostname using the function<code> getaddrinfo</code>) and the peer IP (resolves the peer hostname) and, for each IP pair, check if a brick IP is equal to a peer IP;</li><li><span style="font-family:arial,helvetica,sans-serif">If it&#39;s, </span>this peer is our wanted friend;</li><li>If not, returns and error (and Glusterd will fail).</li></ul><p>What do you think about it?<br></p>--<br><b>Rarylson Freitas<br></b></div><div>Computer Engineer<br></div></div></div>
</div></div></div></div></div></div>