Hello, We've set up geo-replication but it isn't actually syncing. Scenario is that we have two GFS clusters. Cluster A has nodes cafs10, cafs20, and cafs30, replicating with each other over a LAN. Cluster B has nodes nvfs10, nvfs20, and nvfs30 also replicating with each other over a LAN. We are geo-replicating data from the A cluster to the B cluster over the internet. SSH key access is set up, allowing all the A nodes password-less access to root on nvfs10
Geo-replication was set up using these commands, run on cafs10: gluster volume geo-replication gvol0 nvfs10.example.com::gvol0 create ssh-port 8822 no-verify gluster volume geo-replication gvol0 nvfs10.example.com::gvol0 config remote-gsyncd /usr/lib/x86_64-linux-gnu/glusterfs/gsyncd gluster volume geo-replication gvol0 nvfs10.example.com::gvol0 start However after a very short period of the status being "Initializing..." the status then sits on "Passive": # gluster volume geo-replication gvol0 nvfs10.example.com::gvol0 status MASTER NODE MASTER VOL MASTER BRICK SLAVE USER SLAVE SLAVE NODE STATUS CRAWL STATUS LAST_SYNCED ------------------------------------------------------------------------------------------------------------------------------------------------------------------ cafs10 gvol0 /nodirectwritedata/gluster/gvol0 root nvfs10.example.com::gvol0 nvfs30.local Passive N/A N/A cafs30 gvol0 /nodirectwritedata/gluster/gvol0 root nvfs10.example.com::gvol0 N/A Created N/A N/A cafs20 gvol0 /nodirectwritedata/gluster/gvol0 root nvfs10.example.com::gvol0 N/A Created N/A N/A So my questions are: 1. Why does the status on cafs10 mention "nvfs30.local"? That's the LAN address that nvfs10 replicates with nvfs30 using. It's not accessible from the A cluster, and I didn't use it when configuring geo-replication. 2. Why does geo-replication sit in Passive status? Thanks very much for any assistance. On Tue, 25 Feb 2020 at 15:46, David Cunningham <dcunning...@voisonics.com> wrote: > Hi Aravinda and Sunny, > > Thank you for the replies. We have 3 replicating nodes on the master side, > and want to geo-replicate their data to the remote slave side. As I > understand it if the master node which had the geo-replication create > command run goes down then another node will take over pushing updates to > the remote slave. Is that right? > > We have already taken care of adding all master node's SSH keys to the > remote slave's authorized_keys externally, so won't include the push-pem > part of the create command. > > Mostly I wanted to confirm the geo-replication behaviour on the > replicating master nodes if one of them goes down. > > Thank you! > > > On Tue, 25 Feb 2020 at 14:32, Aravinda VK <aravi...@kadalu.io> wrote: > >> Hi David, >> >> >> On 25-Feb-2020, at 3:45 AM, David Cunningham <dcunning...@voisonics.com> >> wrote: >> >> Hello, >> >> I've a couple of questions on geo-replication that hopefully someone can >> help with: >> >> 1. If there are multiple nodes in a cluster on the master side (pushing >> updates to the geo-replication slave), which node actually does the >> pushing? Does GlusterFS decide itself automatically? >> >> >> Once Geo-replication session is started, one worker will be started >> corresponding to each Master bricks. Each worker identifies the changes >> happened in respective brick and sync those changes via Mount. This way >> load is distributed among Master nodes. In case of Replica sub volume, one >> worker among the Replica group will become active and participate in the >> syncing. Other bricks in that Replica group will remain Passive. Passive >> worker will become Active if the previously Active brick goes down (This is >> because all Replica bricks will have the same set of changes, syncing from >> each worker is redundant). >> >> >> 2.With regard to copying SSH keys, presumably the SSH key of all master >> nodes should be authorized on the geo-replication client side? >> >> >> Geo-replication session is established between one master node and one >> remote node. If Geo-rep create command is successful then, >> >> - SSH keys generated in all master nodes >> - Public keys from all master nodes are copied to initiator Master node >> - Public keys copied to the Remote node specified in the create command >> - Master public keys are distributed to all nodes of remote Cluster and >> added to respective ~/.ssh/authorized_keys >> >> After successful Geo-rep create command, any Master node can connect to >> any remote node via ssh. >> >> Security: Command prefix is added while adding public key to remote >> node’s authorized_keys file, So that if anyone gain access using this key >> can access only gsyncd command. >> >> ``` >> command=gsyncd ssh-key…. >> ``` >> >> >> >> Thanks for your help. >> >> -- >> David Cunningham, Voisonics Limited >> http://voisonics.com/ >> USA: +1 213 221 1092 >> New Zealand: +64 (0)28 2558 3782 >> ________ >> >> >> >> Community Meeting Calendar: >> >> Schedule - >> Every Tuesday at 14:30 IST / 09:00 UTC >> Bridge: https://bluejeans.com/441850968 >> >> Gluster-users mailing list >> Gluster-users@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-users >> >> >> >> — >> regards >> Aravinda Vishwanathapura >> https://kadalu.io >> >> > > -- > David Cunningham, Voisonics Limited > http://voisonics.com/ > USA: +1 213 221 1092 > New Zealand: +64 (0)28 2558 3782 > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782
________ Community Meeting Calendar: Schedule - Every Tuesday at 14:30 IST / 09:00 UTC Bridge: https://bluejeans.com/441850968 Gluster-users mailing list Gluster-users@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-users