[Gluster-users] Issues with Geo-replication (GlusterFS 6.3 on Ubuntu 18.04)

Aravinda Vishwanathapura Krishna Murthy avishwan at redhat.com
Thu Oct 17 15:32:42 UTC 2019


On Thu, Oct 17, 2019 at 12:54 PM Alexander Iliev <ailiev+gluster at mamul.org>
wrote:

> Thanks, Aravinda.
>
> Does this mean that my scenario is currently unsupported?
>

Please try by providing external IP while creating Geo-rep session. We will
work on the enhancement if it didn't work.


> It seems that I need to make sure that the nodes in the two clusters can
> see each-other (some kind of VPN would work I guess).
>
> Is this be documented somewhere? I think I've read the geo-replication
> documentation several times now, but somehow it wasn't obvious to me
> that you need access to the slave nodes from the master ones (apart from
> the SSH access).
>
> Thanks!
>
> Best regards,
> --
> alexander iliev
>
> On 10/17/19 5:25 AM, Aravinda Vishwanathapura Krishna Murthy wrote:
> > Got it.
> >
> > Geo-replication uses slave nodes IP in the following cases,
> >
> > - Verification during Session creation - It tries to mount the Slave
> > volume using the hostname/IP provided in Geo-rep create command. Try
> > Geo-rep create by specifying the external IP which is accessible from
> > the master node.
> > - Once Geo-replication is started, it gets the list of Slave nodes
> > IP/hostname from Slave volume info and connects to those IPs. But in
> > this case, those are internal IP addresses that are not accessible from
> > Master nodes. - We need to enhance Geo-replication to accept external IP
> > and internal IP map details so that for all connections it can use
> > external IP.
> >
> > On Wed, Oct 16, 2019 at 10:29 PM Alexander Iliev
> > <ailiev+gluster at mamul.org <mailto:ailiev%2Bgluster at mamul.org>> wrote:
> >
> >     Hi Aravinda,
> >
> >     All volume brick on the slave volume are up and the volume seems
> >     functional.
> >
> >     Your suggestion about trying to mount the slave volume on a master
> node
> >     brings up my question about network connectivity again - the
> GlusterFS
> >     documentation[1] says:
> >
> >       > The server specified in the mount command is only used to fetch
> the
> >     gluster configuration volfile describing the volume name.
> Subsequently,
> >     the client will communicate directly with the servers mentioned in
> the
> >     volfile (which might not even include the one used for mount).
> >
> >     To me this means that the masternode from your example is expected to
> >     have connectivity to the network where the slave volume runs, i.e. to
> >     have network access to the slave nodes. In my geo-replication
> scenario
> >     this is definitely not the case. The two cluster are running in two
> >     completely different networks that are not interconnected.
> >
> >     So my question is - how is the slave volume mount expected to happen
> if
> >     the client host cannot access the GlusterFS nodes? Or is the
> >     connectivity a requirement even for geo-replication?
> >
> >     I'm not sure if I'm missing something, but any help will be highly
> >     appreciated!
> >
> >     Thanks!
> >
> >     Links:
> >     [1]
> >
> https://gluster.readthedocs.io/en/latest/Administrator%20Guide/Setting%20Up%20Clients/
> >     --
> >     alexander iliev
> >
> >     On 10/16/19 6:03 AM, Aravinda Vishwanathapura Krishna Murthy wrote:
> >      > Hi Alexander,
> >      >
> >      > Please check the status of Volume. Looks like the Slave volume
> >     mount is
> >      > failing because bricks are down or not reachable. If Volume
> >     status shows
> >      > all bricks are up then try mounting the slave volume using mount
> >     command.
> >      >
> >      > ```
> >      > masternode$ mkdir /mnt/vol
> >      > masternode$ mount -t glusterfs <slavehost>:<slavevol> /mnt/vol
> >      > ```
> >      >
> >      > On Fri, Oct 11, 2019 at 4:03 AM Alexander Iliev
> >      > <ailiev+gluster at mamul.org <mailto:ailiev%2Bgluster at mamul.org>
> >     <mailto:ailiev%2Bgluster at mamul.org
> >     <mailto:ailiev%252Bgluster at mamul.org>>> wrote:
> >      >
> >      >     Hi all,
> >      >
> >      >     I ended up reinstalling the nodes with CentOS 7.5 and
> >     GlusterFS 6.5
> >      >     (installed from the SIG.)
> >      >
> >      >     Now when I try to create a replication session I get the
> >     following:
> >      >
> >      >       > # gluster volume geo-replication store1
> >     <slave-host>::store2 create
> >      >     push-pem
> >      >       > Unable to mount and fetch slave volume details. Please
> >     check the
> >      >     log:
> >      >     /var/log/glusterfs/geo-replication/gverify-slavemnt.log
> >      >       > geo-replication command failed
> >      >
> >      >     You can find the contents of gverify-slavemnt.log below, but
> the
> >      >     initial
> >      >     error seems to be:
> >      >
> >      >       > [2019-10-10 22:07:51.578519] E
> >      >     [fuse-bridge.c:5211:fuse_first_lookup]
> >      >     0-fuse: first lookup on root failed (Transport endpoint is not
> >      >     connected)
> >      >
> >      >     I only found
> >      >     [this](https://bugzilla.redhat.com/show_bug.cgi?id=1659824)
> >      >     bug report which doesn't seem to help. The reported issue is
> >     failure to
> >      >     mount a volume on a GlusterFS client, but in my case I need
> >      >     geo-replication which implies the client (geo-replication
> >     master) being
> >      >     on a different network.
> >      >
> >      >     Any help will be appreciated.
> >      >
> >      >     Thanks!
> >      >
> >      >     gverify-slavemnt.log:
> >      >
> >      >       > [2019-10-10 22:07:40.571256] I [MSGID: 100030]
> >      >     [glusterfsd.c:2847:main] 0-glusterfs: Started running
> >     glusterfs version
> >      >     6.5 (args: glusterfs --xlator-option=*dht.lookup-unhashed=off
> >      >     --volfile-server <slave-host> --volfile-id store2 -l
> >      >     /var/log/glusterfs/geo-replication/gverify-slavemnt.log
> >      >     /tmp/gverify.sh.5nFlRh)
> >      >       > [2019-10-10 22:07:40.575438] I
> [glusterfsd.c:2556:daemonize]
> >      >     0-glusterfs: Pid of current running process is 6021
> >      >       > [2019-10-10 22:07:40.584282] I [MSGID: 101190]
> >      >     [event-epoll.c:680:event_dispatch_epoll_worker] 0-epoll:
> >     Started thread
> >      >     with index 0
> >      >       > [2019-10-10 22:07:40.584299] I [MSGID: 101190]
> >      >     [event-epoll.c:680:event_dispatch_epoll_worker] 0-epoll:
> >     Started thread
> >      >     with index 1
> >      >       > [2019-10-10 22:07:40.928094] I [MSGID: 114020]
> >      >     [client.c:2393:notify]
> >      >     0-store2-client-0: parent translators are ready, attempting
> >     connect on
> >      >     transport
> >      >       > [2019-10-10 22:07:40.931121] I [MSGID: 114020]
> >      >     [client.c:2393:notify]
> >      >     0-store2-client-1: parent translators are ready, attempting
> >     connect on
> >      >     transport
> >      >       > [2019-10-10 22:07:40.933976] I [MSGID: 114020]
> >      >     [client.c:2393:notify]
> >      >     0-store2-client-2: parent translators are ready, attempting
> >     connect on
> >      >     transport
> >      >       > Final graph:
> >      >       >
> >      >
> >
>  +------------------------------------------------------------------------------+
> >      >       >   1: volume store2-client-0
> >      >       >   2:     type protocol/client
> >      >       >   3:     option ping-timeout 42
> >      >       >   4:     option remote-host 172.31.36.11
> >      >       >   5:     option remote-subvolume
> >     /data/gfs/store1/1/brick-store2
> >      >       >   6:     option transport-type socket
> >      >       >   7:     option transport.address-family inet
> >      >       >   8:     option transport.socket.ssl-enabled off
> >      >       >   9:     option transport.tcp-user-timeout 0
> >      >       >  10:     option transport.socket.keepalive-time 20
> >      >       >  11:     option transport.socket.keepalive-interval 2
> >      >       >  12:     option transport.socket.keepalive-count 9
> >      >       >  13:     option send-gids true
> >      >       >  14: end-volume
> >      >       >  15:
> >      >       >  16: volume store2-client-1
> >      >       >  17:     type protocol/client
> >      >       >  18:     option ping-timeout 42
> >      >       >  19:     option remote-host 172.31.36.12
> >      >       >  20:     option remote-subvolume
> >     /data/gfs/store1/1/brick-store2
> >      >       >  21:     option transport-type socket
> >      >       >  22:     option transport.address-family inet
> >      >       >  23:     option transport.socket.ssl-enabled off
> >      >       >  24:     option transport.tcp-user-timeout 0
> >      >       >  25:     option transport.socket.keepalive-time 20
> >      >       >  26:     option transport.socket.keepalive-interval 2
> >      >       >  27:     option transport.socket.keepalive-count 9
> >      >       >  28:     option send-gids true
> >      >       >  29: end-volume
> >      >       >  30:
> >      >       >  31: volume store2-client-2
> >      >       >  32:     type protocol/client
> >      >       >  33:     option ping-timeout 42
> >      >       >  34:     option remote-host 172.31.36.13
> >      >       >  35:     option remote-subvolume
> >     /data/gfs/store1/1/brick-store2
> >      >       >  36:     option transport-type socket
> >      >       >  37:     option transport.address-family inet
> >      >       >  38:     option transport.socket.ssl-enabled off
> >      >       >  39:     option transport.tcp-user-timeout 0
> >      >       >  40:     option transport.socket.keepalive-time 20
> >      >       >  41:     option transport.socket.keepalive-interval 2
> >      >       >  42:     option transport.socket.keepalive-count 9
> >      >       >  43:     option send-gids true
> >      >       >  44: end-volume
> >      >       >  45:
> >      >       >  46: volume store2-replicate-0
> >      >       >  47:     type cluster/replicate
> >      >       >  48:     option afr-pending-xattr
> >      >     store2-client-0,store2-client-1,store2-client-2
> >      >       >  49:     option use-compound-fops off
> >      >       >  50:     subvolumes store2-client-0 store2-client-1
> >     store2-client-2
> >      >       >  51: end-volume
> >      >       >  52:
> >      >       >  53: volume store2-dht
> >      >       >  54:     type cluster/distribute
> >      >       >  55:     option lookup-unhashed off
> >      >       >  56:     option lock-migration off
> >      >       >  57:     option force-migration off
> >      >       >  58:     subvolumes store2-replicate-0
> >      >       >  59: end-volume
> >      >       >  60:
> >      >       >  61: volume store2-write-behind
> >      >       >  62:     type performance/write-behind
> >      >       >  63:     subvolumes store2-dht
> >      >       >  64: end-volume
> >      >       >  65:
> >      >       >  66: volume store2-read-ahead
> >      >       >  67:     type performance/read-ahead
> >      >       >  68:     subvolumes store2-write-behind
> >      >       >  69: end-volume
> >      >       >  70:
> >      >       >  71: volume store2-readdir-ahead
> >      >       >  72:     type performance/readdir-ahead
> >      >       >  73:     option parallel-readdir off
> >      >       >  74:     option rda-request-size 131072
> >      >       >  75:     option rda-cache-limit 10MB
> >      >       >  76:     subvolumes store2-read-ahead
> >      >       >  77: end-volume
> >      >       >  78:
> >      >       >  79: volume store2-io-cache
> >      >       >  80:     type performance/io-cache
> >      >       >  81:     subvolumes store2-readdir-ahead
> >      >       >  82: end-volume
> >      >       >  83:
> >      >       >  84: volume store2-open-behind
> >      >       >  85:     type performance/open-behind
> >      >       >  86:     subvolumes store2-io-cache
> >      >       >  87: end-volume
> >      >       >  88:
> >      >       >  89: volume store2-quick-read
> >      >       >  90:     type performance/quick-read
> >      >       >  91:     subvolumes store2-open-behind
> >      >       >  92: end-volume
> >      >       >  93:
> >      >       >  94: volume store2-md-cache
> >      >       >  95:     type performance/md-cache
> >      >       >  96:     subvolumes store2-quick-read
> >      >       >  97: end-volume
> >      >       >  98:
> >      >       >  99: volume store2
> >      >       > 100:     type debug/io-stats
> >      >       > 101:     option log-level INFO
> >      >       > 102:     option latency-measurement off
> >      >       > 103:     option count-fop-hits off
> >      >       > 104:     subvolumes store2-md-cache
> >      >       > 105: end-volume
> >      >       > 106:
> >      >       > 107: volume meta-autoload
> >      >       > 108:     type meta
> >      >       > 109:     subvolumes store2
> >      >       > 110: end-volume
> >      >       > 111:
> >      >       >
> >      >
> >
>  +------------------------------------------------------------------------------+
> >      >       > [2019-10-10 22:07:51.578287] I
> [fuse-bridge.c:5142:fuse_init]
> >      >     0-glusterfs-fuse: FUSE inited with protocol versions:
> >     glusterfs 7.24
> >      >     kernel 7.22
> >      >       > [2019-10-10 22:07:51.578356] I
> >     [fuse-bridge.c:5753:fuse_graph_sync]
> >      >     0-fuse: switched to graph 0
> >      >       > [2019-10-10 22:07:51.578467] I [MSGID: 108006]
> >      >     [afr-common.c:5666:afr_local_init] 0-store2-replicate-0: no
> >      >     subvolumes up
> >      >       > [2019-10-10 22:07:51.578519] E
> >      >     [fuse-bridge.c:5211:fuse_first_lookup]
> >      >     0-fuse: first lookup on root failed (Transport endpoint is not
> >      >     connected)
> >      >       > [2019-10-10 22:07:51.578709] W
> >     [fuse-bridge.c:1266:fuse_attr_cbk]
> >      >     0-glusterfs-fuse: 2: LOOKUP() / => -1 (Transport endpoint is
> not
> >      >     connected)
> >      >       > [2019-10-10 22:07:51.578687] I [MSGID: 108006]
> >      >     [afr-common.c:5666:afr_local_init] 0-store2-replicate-0: no
> >      >     subvolumes up
> >      >       > [2019-10-10 22:09:48.222459] E [MSGID: 108006]
> >      >     [afr-common.c:5318:__afr_handle_child_down_event]
> >     0-store2-replicate-0:
> >      >     All subvolumes are down. Going offline until at least one of
> >     them comes
> >      >     back up.
> >      >       > The message "E [MSGID: 108006]
> >      >     [afr-common.c:5318:__afr_handle_child_down_event]
> >     0-store2-replicate-0:
> >      >     All subvolumes are down. Going offline until at least one of
> >     them comes
> >      >     back up." repeated 2 times between [2019-10-10
> >     22:09:48.222459] and
> >      >     [2019-10-10 22:09:48.222891]
> >      >       >
> >      >
> >      >     alexander iliev
> >      >
> >      >     On 9/8/19 4:50 PM, Alexander Iliev wrote:
> >      >      > Hi all,
> >      >      >
> >      >      > Sunny, thank you for the update.
> >      >      >
> >      >      > I have applied the patch locally on my slave system and
> >     now the
> >      >      > mountbroker setup is successful.
> >      >      >
> >      >      > I am facing another issue though - when I try to create a
> >      >     replication
> >      >      > session between the two sites I am getting:
> >      >      >
> >      >      >          # gluster volume geo-replication store1
> >      >      > glustergeorep@<slave-host>::store1 create push-pem
> >      >      >          Error : Request timed out
> >      >      >          geo-replication command failed
> >      >      >
> >      >      > It is still unclear to me if my setup is expected to work
> >     at all.
> >      >      >
> >      >      > Reading the geo-replication documentation at [1] I see this
> >      >     paragraph:
> >      >      >
> >      >      >  > A password-less SSH connection is also required for
> gsyncd
> >      >     between
> >      >      > every node in the master to every node in the slave. The
> >     gluster
> >      >      > system:: execute gsec_create command creates secret-pem
> >     files on
> >      >     all the
> >      >      > nodes in the master, and is used to implement the
> >     password-less SSH
> >      >      > connection. The push-pem option in the geo-replication
> create
> >      >     command
> >      >      > pushes these keys to all the nodes in the slave.
> >      >      >
> >      >      > It is not clear to me whether connectivity from each
> >     master node
> >      >     to each
> >      >      > slave node is a requirement in terms of networking. In my
> >     setup the
> >      >      > slave nodes form the Gluster pool over a private network
> >     which is
> >      >     not
> >      >      > reachable from the master site.
> >      >      >
> >      >      > Any ideas how to proceed from here will be greatly
> >     appreciated.
> >      >      >
> >      >      > Thanks!
> >      >      >
> >      >      > Links:
> >      >      > [1]
> >      >      >
> >      >
> >
> https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3/html/administration_guide/sect-preparing_to_deploy_geo-replication
> >      >
> >      >      >
> >      >      >
> >      >      > Best regards,
> >      >      > --
> >      >      > alexander iliev
> >      >      >
> >      >      > On 9/3/19 2:50 PM, Sunny Kumar wrote:
> >      >      >> Thank you for the explanation Kaleb.
> >      >      >>
> >      >      >> Alexander,
> >      >      >>
> >      >      >> This fix will be available with next release for all
> >     supported
> >      >     versions.
> >      >      >>
> >      >      >> /sunny
> >      >      >>
> >      >      >> On Mon, Sep 2, 2019 at 6:47 PM Kaleb Keithley
> >      >     <kkeithle at redhat.com <mailto:kkeithle at redhat.com>
> >     <mailto:kkeithle at redhat.com <mailto:kkeithle at redhat.com>>>
> >      >      >> wrote:
> >      >      >>>
> >      >      >>> Fixes on master (before or after the release-7 branch
> >     was taken)
> >      >      >>> almost certainly warrant a backport IMO to at least
> >     release-6, and
> >      >      >>> probably release-5 as well.
> >      >      >>>
> >      >      >>> We used to have a "tracker" BZ for each minor release
> (e.g.
> >      >     6.6) to
> >      >      >>> keep track of backports by cloning the original BZ and
> >     changing
> >      >     the
> >      >      >>> Version, and adding that BZ to the tracker. I'm not sure
> >     what
> >      >      >>> happened to that practice. The last ones I can find are
> >     for 6.3
> >      >     and
> >      >      >>> 5.7;
> >     https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-6.3 and
> >      >      >>>
> https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-5.7
> >      >      >>>
> >      >      >>> It isn't enough to just backport recent fixes on master
> to
> >      >     release-7.
> >      >      >>> We are supposedly continuing to maintain release-6 and
> >     release-5
> >      >      >>> after release-7 GAs. If that has changed, I haven't seen
> an
> >      >      >>> announcement to that effect. I don't know why our
> >     developers don't
> >      >      >>> automatically backport to all the actively maintained
> >     releases.
> >      >      >>>
> >      >      >>> Even if there isn't a tracker BZ, you can always create a
> >      >     backport BZ
> >      >      >>> by cloning the original BZ and change the release to 6.
> >     That'd
> >      >     be a
> >      >      >>> good place to start.
> >      >      >>>
> >      >      >>> On Sun, Sep 1, 2019 at 8:45 AM Alexander Iliev
> >      >      >>> <ailiev+gluster at mamul.org
> >     <mailto:ailiev%2Bgluster at mamul.org>
> >     <mailto:ailiev%2Bgluster at mamul.org
> >     <mailto:ailiev%252Bgluster at mamul.org>>>
> >      >     wrote:
> >      >      >>>>
> >      >      >>>> Hi Strahil,
> >      >      >>>>
> >      >      >>>> Yes, this might be right, but I would still expect
> >     fixes like
> >      >     this
> >      >      >>>> to be
> >      >      >>>> released for all supported major versions (which should
> >      >     include 6.) At
> >      >      >>>> least that's how I understand
> >      >      >>>> https://www.gluster.org/release-schedule/.
> >      >      >>>>
> >      >      >>>> Anyway, let's wait for Sunny to clarify.
> >      >      >>>>
> >      >      >>>> Best regards,
> >      >      >>>> alexander iliev
> >      >      >>>>
> >      >      >>>> On 9/1/19 2:07 PM, Strahil Nikolov wrote:
> >      >      >>>>> Hi Alex,
> >      >      >>>>>
> >      >      >>>>> I'm not very deep into bugzilla stuff, but for me
> >     NEXTRELEASE
> >      >     means
> >      >      >>>>> v7.
> >      >      >>>>>
> >      >      >>>>> Sunny,
> >      >      >>>>> Am I understanding it correctly ?
> >      >      >>>>>
> >      >      >>>>> Best Regards,
> >      >      >>>>> Strahil Nikolov
> >      >      >>>>>
> >      >      >>>>> В неделя, 1 септември 2019 г., 14:27:32 ч. Гринуич+3,
> >      >     Alexander Iliev
> >      >      >>>>> <ailiev+gluster at mamul.org
> >     <mailto:ailiev%2Bgluster at mamul.org>
> >      >     <mailto:ailiev%2Bgluster at mamul.org
> >     <mailto:ailiev%252Bgluster at mamul.org>>> написа:
> >      >      >>>>>
> >      >      >>>>>
> >      >      >>>>> Hi Sunny,
> >      >      >>>>>
> >      >      >>>>> Thank you for the quick response.
> >      >      >>>>>
> >      >      >>>>> It's not clear to me however if the fix has been
> already
> >      >     released
> >      >      >>>>> or not.
> >      >      >>>>>
> >      >      >>>>> The bug status is CLOSED NEXTRELEASE and according to
> >     [1] the
> >      >      >>>>> NEXTRELEASE resolution means that the fix will be
> >     included in
> >      >     the next
> >      >      >>>>> supported release. The bug is logged against the
> >     mainline version
> >      >      >>>>> though, so I'm not sure what this means exactly.
> >      >      >>>>>
> >      >      >>>>>   From the 6.4[2] and 6.5[3] release notes it seems it
> >     hasn't
> >      >     been
> >      >      >>>>> released yet.
> >      >      >>>>>
> >      >      >>>>> Ideally I would not like to patch my systems locally,
> >     so if you
> >      >      >>>>> have an
> >      >      >>>>> ETA on when this will be out officially I would really
> >      >     appreciate it.
> >      >      >>>>>
> >      >      >>>>> Links:
> >      >      >>>>> [1]
> >      > https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_status
> >      >      >>>>> [2]
> https://docs.gluster.org/en/latest/release-notes/6.4/
> >      >      >>>>> [3]
> https://docs.gluster.org/en/latest/release-notes/6.5/
> >      >      >>>>>
> >      >      >>>>> Thank you!
> >      >      >>>>>
> >      >      >>>>> Best regards,
> >      >      >>>>>
> >      >      >>>>> alexander iliev
> >      >      >>>>>
> >      >      >>>>> On 8/30/19 9:22 AM, Sunny Kumar wrote:
> >      >      >>>>>   > Hi Alexander,
> >      >      >>>>>   >
> >      >      >>>>>   > Thanks for pointing that out!
> >      >      >>>>>   >
> >      >      >>>>>   > But this issue is fixed now you can see below link
> for
> >      >     bz-link
> >      >      >>>>> and patch.
> >      >      >>>>>   >
> >      >      >>>>>   > BZ -
> >     https://bugzilla.redhat.com/show_bug.cgi?id=1709248
> >      >      >>>>>   >
> >      >      >>>>>   > Patch -
> >     https://review.gluster.org/#/c/glusterfs/+/22716/
> >      >      >>>>>   >
> >      >      >>>>>   > Hope this helps.
> >      >      >>>>>   >
> >      >      >>>>>   > /sunny
> >      >      >>>>>   >
> >      >      >>>>>   > On Fri, Aug 30, 2019 at 2:30 AM Alexander Iliev
> >      >      >>>>>   > <ailiev+gluster at mamul.org
> >     <mailto:ailiev%2Bgluster at mamul.org>
> >      >     <mailto:ailiev%2Bgluster at mamul.org
> >     <mailto:ailiev%252Bgluster at mamul.org>> <mailto:gluster at mamul.org
> >     <mailto:gluster at mamul.org>
> >      >     <mailto:gluster at mamul.org <mailto:gluster at mamul.org>>>>
> wrote:
> >      >      >>>>>   >>
> >      >      >>>>>   >> Hello dear GlusterFS users list,
> >      >      >>>>>   >>
> >      >      >>>>>   >> I have been trying to set up geo-replication
> >     between two
> >      >      >>>>> clusters for
> >      >      >>>>>   >> some time now. The desired state is (Cluster #1)
> >     being
> >      >      >>>>> replicated to
> >      >      >>>>>   >> (Cluster #2).
> >      >      >>>>>   >>
> >      >      >>>>>   >> Here are some details about the setup:
> >      >      >>>>>   >>
> >      >      >>>>>   >> Cluster #1: three nodes connected via a local
> network
> >      >      >>>>> (172.31.35.0/24 <http://172.31.35.0/24>
> >     <http://172.31.35.0/24>),
> >      >      >>>>>   >> one replicated (3 replica) volume.
> >      >      >>>>>   >>
> >      >      >>>>>   >> Cluster #2: three nodes connected via a local
> network
> >      >      >>>>> (172.31.36.0/24 <http://172.31.36.0/24>
> >     <http://172.31.36.0/24>),
> >      >      >>>>>   >> one replicated (3 replica) volume.
> >      >      >>>>>   >>
> >      >      >>>>>   >> The two clusters are connected to the Internet
> >     via separate
> >      >      >>>>> network
> >      >      >>>>>   >> adapters.
> >      >      >>>>>   >>
> >      >      >>>>>   >> Only SSH (port 22) is open on cluster #2 nodes'
> >     adapters
> >      >      >>>>> connected to
> >      >      >>>>>   >> the Internet.
> >      >      >>>>>   >>
> >      >      >>>>>   >> All nodes are running Ubuntu 18.04 and GlusterFS
> 6.3
> >      >     installed
> >      >      >>>>> from [1].
> >      >      >>>>>   >>
> >      >      >>>>>   >> The first time I followed the guide[2] everything
> >     went
> >      >     fine up
> >      >      >>>>> until I
> >      >      >>>>>   >> reached the "Create the session" step. That was
> >     like a
> >      >     month
> >      >      >>>>> ago, then I
> >      >      >>>>>   >> had to temporarily stop working in this and now I
> >     am coming
> >      >      >>>>> back to it.
> >      >      >>>>>   >>
> >      >      >>>>>   >> Currently, if I try to see the mountbroker status
> >     I get the
> >      >      >>>>> following:
> >      >      >>>>>   >>
> >      >      >>>>>   >>> # gluster-mountbroker status
> >      >      >>>>>   >>> Traceback (most recent call last):
> >      >      >>>>>   >>>    File "/usr/sbin/gluster-mountbroker", line
> >     396, in
> >      >     <module>
> >      >      >>>>>   >>>      runcli()
> >      >      >>>>>   >>>    File
> >      >      >>>>>
> >      >
> >       "/usr/lib/python3/dist-packages/gluster/cliutils/cliutils.py", line
> >      >      >>>>> 225,
> >      >      >>>>> in runcli
> >      >      >>>>>   >>>      cls.run(args)
> >      >      >>>>>   >>>    File "/usr/sbin/gluster-mountbroker", line
> >     275, in run
> >      >      >>>>>   >>>      out = execute_in_peers("node-status")
> >      >      >>>>>   >>>    File
> >      >      >>>>>
> >     "/usr/lib/python3/dist-packages/gluster/cliutils/cliutils.py",
> >      >      >>>>>   >> line 127, in execute_in_peers
> >      >      >>>>>   >>>      raise GlusterCmdException((rc, out, err, "
> >      >     ".join(cmd)))
> >      >      >>>>>   >>> gluster.cliutils.cliutils.GlusterCmdException:
> >     (1, '',
> >      >      >>>>> 'Unable to
> >      >      >>>>>   >> end. Error : Success\n', 'gluster system:: execute
> >      >     mountbroker.py
> >      >      >>>>>   >> node-status')
> >      >      >>>>>   >>
> >      >      >>>>>   >> And in /var/log/gluster/glusterd.log I have:
> >      >      >>>>>   >>
> >      >      >>>>>   >>> [2019-08-10 15:24:21.418834] E [MSGID: 106336]
> >      >      >>>>>   >> [glusterd-geo-rep.c:5413:glusterd_op_sys_exec]
> >      >     0-management:
> >      >      >>>>> Unable to
> >      >      >>>>>   >> end. Error : Success
> >      >      >>>>>   >>> [2019-08-10 15:24:21.418908] E [MSGID: 106122]
> >      >    �� >>>>>   >> [glusterd-syncop.c:1445:gd_commit_op_phase]
> >     0-management:
> >      >      >>>>> Commit of
> >      >      >>>>>   >> operation 'Volume Execute system commands' failed
> on
> >      >     localhost
> >      >      >>>>> : Unable
> >      >      >>>>>   >> to end. Error : Success
> >      >      >>>>>   >>
> >      >      >>>>>   >> So, I have two questions right now:
> >      >      >>>>>   >>
> >      >      >>>>>   >> 1) Is there anything wrong with my setup
> >     (networking, open
> >      >      >>>>> ports, etc.)?
> >      >      >>>>>   >> Is it expected to work with this setup or should
> >     I redo
> >      >     it in a
> >      >      >>>>>   >> different way?
> >      >      >>>>>   >> 2) How can I troubleshoot the current status of my
> >      >     setup? Can
> >      >      >>>>> I find out
> >      >      >>>>>   >> what's missing/wrong and continue from there or
> >     should I
> >      >     just
> >      >      >>>>> start from
> >      >      >>>>>   >> scratch?
> >      >      >>>>>   >>
> >      >      >>>>>   >> Links:
> >      >      >>>>>   >> [1]
> >     http://ppa.launchpad.net/gluster/glusterfs-6/ubuntu
> >      >      >>>>>   >> [2]
> >      >      >>>>>   >>
> >      >      >>>>>
> >      >
> >
> https://docs.gluster.org/en/latest/Administrator%20Guide/Geo%20Replication/
> >      >
> >      >      >>>>>
> >      >      >>>>>   >>
> >      >      >>>>>   >> Thank you!
> >      >      >>>>>   >>
> >      >      >>>>>   >> Best regards,
> >      >      >>>>>   >> --
> >      >      >>>>>   >> alexander iliev
> >      >      >>>>>   >> _______________________________________________
> >      >      >>>>>   >> Gluster-users mailing list
> >      >      >>>>>   >> Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org>
> >      >     <mailto:Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org>>
> >     <mailto:Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
> >      >     <mailto:Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org>>>
> >      >      >>>>>   >>
> >     https://lists.gluster.org/mailman/listinfo/gluster-users
> >      >      >>>>> _______________________________________________
> >      >      >>>>> Gluster-users mailing list
> >      >      >>>>> Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org> <mailto:Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org>>
> >      >     <mailto:Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org> <mailto:Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org>>>
> >      >      >>>>>
> https://lists.gluster.org/mailman/listinfo/gluster-users
> >      >      >>>> _______________________________________________
> >      >      >>>> Gluster-users mailing list
> >      >      >>>> Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org> <mailto:Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org>>
> >      >      >>>>
> https://lists.gluster.org/mailman/listinfo/gluster-users
> >      >      > _______________________________________________
> >      >      > Gluster-users mailing list
> >      >      > Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org> <mailto:Gluster-users at gluster.org
> >     <mailto:Gluster-users at gluster.org>>
> >      >      > https://lists.gluster.org/mailman/listinfo/gluster-users
> >      >     ________
> >      >
> >      >     Community Meeting Calendar:
> >      >
> >      >     APAC Schedule -
> >      >     Every 2nd and 4th Tuesday at 11:30 AM IST
> >      >     Bridge: https://bluejeans.com/118564314
> >      >
> >      >     NA/EMEA Schedule -
> >      >     Every 1st and 3rd Tuesday at 01:00 PM EDT
> >      >     Bridge: https://bluejeans.com/118564314
> >      >
> >      >     Gluster-users mailing list
> >      > Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
> >     <mailto:Gluster-users at gluster.org <mailto:Gluster-users at gluster.org
> >>
> >      > https://lists.gluster.org/mailman/listinfo/gluster-users
> >      >
> >      >
> >      >
> >      > --
> >      > regards
> >      > Aravinda VK
> >
> >
> >
> > --
> > regards
> > Aravinda VK
>


-- 
regards
Aravinda VK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20191017/9bac07d3/attachment.html>


More information about the Gluster-users mailing list