<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi David,<div class=""><br class=""></div><div class="">I like the Strahil’s idea of adding remote IPs in /etc/hosts with same name as used in B cluster. Since Geo-replication uses ssh for syncing it should work. Only issue I can think about is if the hostname of cluster B conflicts with hostnames of Cluster A.</div><div class=""><br class=""></div><div class="">—</div><div class="">regards</div><div class="">Aravinda Vishwanathapura</div><div class=""><a href="https://kadalu" class="">https://kadalu</a>.io<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 04-Mar-2020, at 4:13 AM, David Cunningham &lt;<a href="mailto:dcunningham@voisonics.com" class="">dcunningham@voisonics.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi Strahil,</div><div class=""><br class=""></div><div class="">The B cluster are communicating with each other via a LAN, and it seems the A cluster has got B's LAN addresses (which aren't accessible from the internet including the A cluster) through the geo-replication process. That being the case, I think we'll have to re-do the B cluster to replicate using public addresses instead of the LAN.</div><div class=""><br class=""></div><div class="">Thank you.</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 3 Mar 2020 at 18:07, Strahil Nikolov &lt;<a href="mailto:hunter86_bg@yahoo.com" class="">hunter86_bg@yahoo.com</a>&gt; wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On March 3, 2020 4:13:38 AM GMT+02:00, David Cunningham &lt;<a href="mailto:dcunningham@voisonics.com" target="_blank" class="">dcunningham@voisonics.com</a>&gt; wrote:<br class="">
&gt;Hello,<br class="">
&gt;<br class="">
&gt;Thanks for that. When we re-tried with push-pem from cafs10 (on the<br class="">
&gt;A/master cluster) it failed with "Unable to mount and fetch slave<br class="">
&gt;volume<br class="">
&gt;details." and in the logs we see:<br class="">
&gt;<br class="">
&gt;[2020-03-03 02:07:42.614911] E<br class="">
&gt;[name.c:258:af_inet_client_get_remote_sockaddr] 0-gvol0-client-0: DNS<br class="">
&gt;resolution failed on host nvfs10.local<br class="">
&gt;[2020-03-03 02:07:42.638824] E<br class="">
&gt;[name.c:258:af_inet_client_get_remote_sockaddr] 0-gvol0-client-1: DNS<br class="">
&gt;resolution failed on host nvfs20.local<br class="">
&gt;[2020-03-03 02:07:42.664493] E<br class="">
&gt;[name.c:258:af_inet_client_get_remote_sockaddr] 0-gvol0-client-2: DNS<br class="">
&gt;resolution failed on host nvfs30.local<br class="">
&gt;<br class="">
&gt;These .local addresses are the LAN addresses that B/slave nodes nvfs10,<br class="">
&gt;nvfs20, and nvfs30 replicate with. It seems that the A/master needs to<br class="">
&gt;be<br class="">
&gt;able to contact those addresses. Is that right? If it is then we'll<br class="">
&gt;need to<br class="">
&gt;re-do the B cluster to replicate using publicly accessible IP addresses<br class="">
&gt;instead of their LAN.<br class="">
&gt;<br class="">
&gt;Thank you.<br class="">
&gt;<br class="">
&gt;<br class="">
&gt;On Mon, 2 Mar 2020 at 20:53, Aravinda VK &lt;<a href="mailto:aravinda@kadalu.io" target="_blank" class="">aravinda@kadalu.io</a>&gt; wrote:<br class="">
&gt;<br class="">
&gt;&gt; Looks like setup issue to me. Copying SSH keys manually is not<br class="">
&gt;required.<br class="">
&gt;&gt;<br class="">
&gt;&gt; Command prefix is required while adding to authorized_keys file in<br class="">
&gt;each<br class="">
&gt;&gt; remote nodes. That will not be available if ssh keys are added<br class="">
&gt;manually.<br class="">
&gt;&gt;<br class="">
&gt;&gt; Geo-rep specifies /nonexisting/gsyncd in the command to make sure it<br class="">
&gt;&gt; connects via the actual command specified in authorized_keys file, in<br class="">
&gt;your<br class="">
&gt;&gt; case Geo-replication is actually looking for gsyncd command in<br class="">
&gt;&gt; /nonexisting/gsyncd path.<br class="">
&gt;&gt;<br class="">
&gt;&gt; Please try with push-pem option during Geo-rep create command.<br class="">
&gt;&gt;<br class="">
&gt;&gt; —<br class="">
&gt;&gt; regards<br class="">
&gt;&gt; Aravinda Vishwanathapura<br class="">
&gt;&gt; <a href="https://kadalu.io/" rel="noreferrer" target="_blank" class="">https://kadalu.io</a><br class="">
&gt;&gt;<br class="">
&gt;&gt;<br class="">
&gt;&gt; On 02-Mar-2020, at 6:03 AM, David Cunningham<br class="">
&gt;&lt;<a href="mailto:dcunningham@voisonics.com" target="_blank" class="">dcunningham@voisonics.com</a>&gt;<br class="">
&gt;&gt; wrote:<br class="">
&gt;&gt;<br class="">
&gt;&gt; Hello,<br class="">
&gt;&gt;<br class="">
&gt;&gt; We've set up geo-replication but it isn't actually syncing. Scenario<br class="">
&gt;is<br class="">
&gt;&gt; that we have two GFS clusters. Cluster A has nodes cafs10, cafs20,<br class="">
&gt;and<br class="">
&gt;&gt; cafs30, replicating with each other over a LAN. Cluster B has nodes<br class="">
&gt;nvfs10,<br class="">
&gt;&gt; nvfs20, and nvfs30 also replicating with each other over a LAN. We<br class="">
&gt;are<br class="">
&gt;&gt; geo-replicating data from the A cluster to the B cluster over the<br class="">
&gt;internet.<br class="">
&gt;&gt; SSH key access is set up, allowing all the A nodes password-less<br class="">
&gt;access to<br class="">
&gt;&gt; root on nvfs10<br class="">
&gt;&gt;<br class="">
&gt;&gt; Geo-replication was set up using these commands, run on cafs10:<br class="">
&gt;&gt;<br class="">
&gt;&gt; gluster volume geo-replication gvol0 <a href="http://nvfs10.example.com" class="">nvfs10.example.com</a>::gvol0 create<br class="">
&gt;&gt; ssh-port 8822 no-verify<br class="">
&gt;&gt; gluster volume geo-replication gvol0 <a href="http://nvfs10.example.com" class="">nvfs10.example.com</a>::gvol0 config<br class="">
&gt;&gt; remote-gsyncd /usr/lib/x86_64-linux-gnu/glusterfs/gsyncd<br class="">
&gt;&gt; gluster volume geo-replication gvol0 <a href="http://nvfs10.example.com" class="">nvfs10.example.com</a>::gvol0 start<br class="">
&gt;&gt;<br class="">
&gt;&gt; However after a very short period of the status being<br class="">
&gt;"Initializing..."<br class="">
&gt;&gt; the status then sits on "Passive":<br class="">
&gt;&gt;<br class="">
&gt;&gt; # gluster volume geo-replication gvol0 <a href="http://nvfs10.example.com" class="">nvfs10.example.com</a>::gvol0<br class="">
&gt;status<br class="">
&gt;&gt; MASTER NODE&nbsp; &nbsp; MASTER VOL&nbsp; &nbsp; MASTER BRICK&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br class="">
&gt;SLAVE<br class="">
&gt;&gt; USER&nbsp; &nbsp; SLAVE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;SLAVE NODE&nbsp; &nbsp; &nbsp; STATUS&nbsp; &nbsp; <br class="">
&gt;CRAWL<br class="">
&gt;&gt; STATUS&nbsp; &nbsp; LAST_SYNCED<br class="">
&gt;&gt;<br class="">
&gt;&gt;<br class="">
&gt;------------------------------------------------------------------------------------------------------------------------------------------------------------------<br class="">
&gt;&gt; cafs10&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;gvol0&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/nodirectwritedata/gluster/gvol0&nbsp; &nbsp; root<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp; <a href="http://nvfs10.example.com" class="">nvfs10.example.com</a>::gvol0&nbsp; &nbsp; nvfs30.local&nbsp; &nbsp; Passive&nbsp; &nbsp; N/A<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp;N/A<br class="">
&gt;&gt; cafs30&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;gvol0&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/nodirectwritedata/gluster/gvol0&nbsp; &nbsp; root<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp; <a href="http://nvfs10.example.com" class="">nvfs10.example.com</a>::gvol0&nbsp; &nbsp; N/A&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Created&nbsp; &nbsp; N/A<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp;N/A<br class="">
&gt;&gt; cafs20&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;gvol0&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/nodirectwritedata/gluster/gvol0&nbsp; &nbsp; root<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp; <a href="http://nvfs10.example.com" class="">nvfs10.example.com</a>::gvol0&nbsp; &nbsp; N/A&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Created&nbsp; &nbsp; N/A<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp;N/A<br class="">
&gt;&gt;<br class="">
&gt;&gt; So my questions are:<br class="">
&gt;&gt; 1. Why does the status on cafs10 mention "nvfs30.local"? That's the<br class="">
&gt;LAN<br class="">
&gt;&gt; address that nvfs10 replicates with nvfs30 using. It's not accessible<br class="">
&gt;from<br class="">
&gt;&gt; the A cluster, and I didn't use it when configuring geo-replication.<br class="">
&gt;&gt; 2. Why does geo-replication sit in Passive status?<br class="">
&gt;&gt;<br class="">
&gt;&gt; Thanks very much for any assistance.<br class="">
&gt;&gt;<br class="">
&gt;&gt;<br class="">
&gt;&gt; On Tue, 25 Feb 2020 at 15:46, David Cunningham<br class="">
&gt;&lt;<a href="mailto:dcunningham@voisonics.com" target="_blank" class="">dcunningham@voisonics.com</a>&gt;<br class="">
&gt;&gt; wrote:<br class="">
&gt;&gt;<br class="">
&gt;&gt;&gt; Hi Aravinda and Sunny,<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt; Thank you for the replies. We have 3 replicating nodes on the master<br class="">
&gt;&gt;&gt; side, and want to geo-replicate their data to the remote slave side.<br class="">
&gt;As I<br class="">
&gt;&gt;&gt; understand it if the master node which had the geo-replication<br class="">
&gt;create<br class="">
&gt;&gt;&gt; command run goes down then another node will take over pushing<br class="">
&gt;updates to<br class="">
&gt;&gt;&gt; the remote slave. Is that right?<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt; We have already taken care of adding all master node's SSH keys to<br class="">
&gt;the<br class="">
&gt;&gt;&gt; remote slave's authorized_keys externally, so won't include the<br class="">
&gt;push-pem<br class="">
&gt;&gt;&gt; part of the create command.<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt; Mostly I wanted to confirm the geo-replication behaviour on the<br class="">
&gt;&gt;&gt; replicating master nodes if one of them goes down.<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt; Thank you!<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt; On Tue, 25 Feb 2020 at 14:32, Aravinda VK &lt;<a href="mailto:aravinda@kadalu.io" target="_blank" class="">aravinda@kadalu.io</a>&gt;<br class="">
&gt;wrote:<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Hi David,<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; On 25-Feb-2020, at 3:45 AM, David Cunningham<br class="">
&gt;&lt;<a href="mailto:dcunningham@voisonics.com" target="_blank" class="">dcunningham@voisonics.com</a>&gt;<br class="">
&gt;&gt;&gt;&gt; wrote:<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Hello,<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; I've a couple of questions on geo-replication that hopefully<br class="">
&gt;someone can<br class="">
&gt;&gt;&gt;&gt; help with:<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; 1. If there are multiple nodes in a cluster on the master side<br class="">
&gt;(pushing<br class="">
&gt;&gt;&gt;&gt; updates to the geo-replication slave), which node actually does the<br class="">
&gt;&gt;&gt;&gt; pushing? Does GlusterFS decide itself automatically?<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Once Geo-replication session is started, one worker will be started<br class="">
&gt;&gt;&gt;&gt; corresponding to each Master bricks. Each worker identifies the<br class="">
&gt;changes<br class="">
&gt;&gt;&gt;&gt; happened in respective brick and sync those changes via Mount. This<br class="">
&gt;way<br class="">
&gt;&gt;&gt;&gt; load is distributed among Master nodes. In case of Replica sub<br class="">
&gt;volume, one<br class="">
&gt;&gt;&gt;&gt; worker among the Replica group will become active and participate<br class="">
&gt;in the<br class="">
&gt;&gt;&gt;&gt; syncing. Other bricks in that Replica group will remain Passive.<br class="">
&gt;Passive<br class="">
&gt;&gt;&gt;&gt; worker will become Active if the previously Active brick goes down<br class="">
&gt;(This is<br class="">
&gt;&gt;&gt;&gt; because all Replica bricks will have the same set of changes,<br class="">
&gt;syncing from<br class="">
&gt;&gt;&gt;&gt; each worker is redundant).<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; 2.With regard to copying SSH keys, presumably the SSH key of all<br class="">
&gt;master<br class="">
&gt;&gt;&gt;&gt; nodes should be authorized on the geo-replication client side?<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Geo-replication session is established between one master node and<br class="">
&gt;one<br class="">
&gt;&gt;&gt;&gt; remote node. If Geo-rep create command is successful then,<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; - SSH keys generated in all master nodes<br class="">
&gt;&gt;&gt;&gt; - Public keys from all master nodes are copied to initiator Master<br class="">
&gt;node<br class="">
&gt;&gt;&gt;&gt; - Public keys copied to the Remote node specified in the create<br class="">
&gt;command<br class="">
&gt;&gt;&gt;&gt; - Master public keys are distributed to all nodes of remote Cluster<br class="">
&gt;and<br class="">
&gt;&gt;&gt;&gt; added to respective ~/.ssh/authorized_keys<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; After successful Geo-rep create command, any Master node can<br class="">
&gt;connect to<br class="">
&gt;&gt;&gt;&gt; any remote node via ssh.<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Security: Command prefix is added while adding public key to remote<br class="">
&gt;&gt;&gt;&gt; node’s authorized_keys file, So that if anyone gain access using<br class="">
&gt;this key<br class="">
&gt;&gt;&gt;&gt; can access only gsyncd command.<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; ```<br class="">
&gt;&gt;&gt;&gt; command=gsyncd ssh-key….<br class="">
&gt;&gt;&gt;&gt; ```<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Thanks for your help.<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; --<br class="">
&gt;&gt;&gt;&gt; David Cunningham, Voisonics Limited<br class="">
&gt;&gt;&gt;&gt; <a href="http://voisonics.com/" rel="noreferrer" target="_blank" class="">http://voisonics.com/</a><br class="">
&gt;&gt;&gt;&gt; USA: +1 213 221 1092<br class="">
&gt;&gt;&gt;&gt; New Zealand: +64 (0)28 2558 3782<br class="">
&gt;&gt;&gt;&gt; ________<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Community Meeting Calendar:<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Schedule -<br class="">
&gt;&gt;&gt;&gt; Every Tuesday at 14:30 IST / 09:00 UTC<br class="">
&gt;&gt;&gt;&gt; Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank" class="">https://bluejeans.com/441850968</a><br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Gluster-users mailing list<br class="">
&gt;&gt;&gt;&gt; <a href="mailto:Gluster-users@gluster.org" target="_blank" class="">Gluster-users@gluster.org</a><br class="">
&gt;&gt;&gt;&gt; <a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank" class="">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; —<br class="">
&gt;&gt;&gt;&gt; regards<br class="">
&gt;&gt;&gt;&gt; Aravinda Vishwanathapura<br class="">
&gt;&gt;&gt;&gt; <a href="https://kadalu.io/" rel="noreferrer" target="_blank" class="">https://kadalu.io</a><br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt; --<br class="">
&gt;&gt;&gt; David Cunningham, Voisonics Limited<br class="">
&gt;&gt;&gt; <a href="http://voisonics.com/" rel="noreferrer" target="_blank" class="">http://voisonics.com/</a><br class="">
&gt;&gt;&gt; USA: +1 213 221 1092<br class="">
&gt;&gt;&gt; New Zealand: +64 (0)28 2558 3782<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;<br class="">
&gt;&gt;<br class="">
&gt;&gt; --<br class="">
&gt;&gt; David Cunningham, Voisonics Limited<br class="">
&gt;&gt; <a href="http://voisonics.com/" rel="noreferrer" target="_blank" class="">http://voisonics.com/</a><br class="">
&gt;&gt; USA: +1 213 221 1092<br class="">
&gt;&gt; New Zealand: +64 (0)28 2558 3782<br class="">
&gt;&gt;<br class="">
&gt;&gt;<br class="">
&gt;&gt;<br class="">
<br class="">
Hey David,<br class="">
<br class="">
Why don't you set the B cluster's hostnames in /etc/hosts of all A cluster nodes ?<br class="">
<br class="">
Maybe you won't need to rebuild&nbsp; the whole B cluster.<br class="">
<br class="">
I guess the A cluster nodes nees to be able to reach all nodes from B cluster, so you might need to change the firewall settings.<br class="">
<br class="">
<br class="">
Best Regards,<br class="">
Strahil Nikolov<br class="">
</blockquote></div><br clear="all" class=""><br class="">-- <br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">David Cunningham, Voisonics Limited<br class=""><a href="http://voisonics.com/" target="_blank" class="">http://voisonics.com/</a><br class="">USA: +1 213 221 1092<br class="">New Zealand: +64 (0)28 2558 3782</div></div></div></div></div></div></div></div></div></div></div>
</div></blockquote></div><br class=""></div></body></html>