[ovirt-users] ovirt 4.1 hosted engine hyper converged on glusterfs 3.8.10 : "engine" storage domain alway complain about "unsynced" elements

Ravishankar N ravishankar at redhat.com
Sat Jul 22 06:13:29 UTC 2017


On 07/21/2017 11:41 PM, yayo (j) wrote:
> Hi,
>
> Sorry for follow up again, but, checking the ovirt interface I've 
> found that ovirt report the "engine" volume as an "arbiter" 
> configuration and the "data" volume as full replicated volume. Check 
> these screenshots:

This is probably some refresh bug in the UI, Sahina might be able to 
tell you.
>
> https://drive.google.com/drive/folders/0ByUV7xQtP1gCTE8tUTFfVmR5aDQ?usp=sharing
>
> But the "gluster volume info" command report that all 2 volume are 
> full replicated:
>
>
>     /Volume Name: data/
>     /Type: Replicate/
>     /Volume ID: c7a5dfc9-3e72-4ea1-843e-c8275d4a7c2d/
>     /Status: Started/
>     /Snapshot Count: 0/
>     /Number of Bricks: 1 x 3 = 3/
>     /Transport-type: tcp/
>     /Bricks:/
>     /Brick1: gdnode01:/gluster/data/brick/
>     /Brick2: gdnode02:/gluster/data/brick/
>     /Brick3: gdnode04:/gluster/data/brick/
>     /Options Reconfigured:/
>     /nfs.disable: on/
>     /performance.readdir-ahead: on/
>     /transport.address-family: inet/
>     /storage.owner-uid: 36/
>     /performance.quick-read: off/
>     /performance.read-ahead: off/
>     /performance.io-cache: off/
>     /performance.stat-prefetch: off/
>     /performance.low-prio-threads: 32/
>     /network.remote-dio: enable/
>     /cluster.eager-lock: enable/
>     /cluster.quorum-type: auto/
>     /cluster.server-quorum-type: server/
>     /cluster.data-self-heal-algorithm: full/
>     /cluster.locking-scheme: granular/
>     /cluster.shd-max-threads: 8/
>     /cluster.shd-wait-qlength: 10000/
>     /features.shard: on/
>     /user.cifs: off/
>     /storage.owner-gid: 36/
>     /features.shard-block-size: 512MB/
>     /network.ping-timeout: 30/
>     /performance.strict-o-direct: on/
>     /cluster.granular-entry-heal: on/
>     /auth.allow: */
>     /server.allow-insecure: on/
>
>
>
>
>
>     /Volume Name: engine/
>     /Type: Replicate/
>     /Volume ID: d19c19e3-910d-437b-8ba7-4f2a23d17515/
>     /Status: Started/
>     /Snapshot Count: 0/
>     /Number of Bricks: 1 x 3 = 3/
>     /Transport-type: tcp/
>     /Bricks:/
>     /Brick1: gdnode01:/gluster/engine/brick/
>     /Brick2: gdnode02:/gluster/engine/brick/
>     /Brick3: gdnode04:/gluster/engine/brick/
>     /Options Reconfigured:/
>     /nfs.disable: on/
>     /performance.readdir-ahead: on/
>     /transport.address-family: inet/
>     /storage.owner-uid: 36/
>     /performance.quick-read: off/
>     /performance.read-ahead: off/
>     /performance.io-cache: off/
>     /performance.stat-prefetch: off/
>     /performance.low-prio-threads: 32/
>     /network.remote-dio: off/
>     /cluster.eager-lock: enable/
>     /cluster.quorum-type: auto/
>     /cluster.server-quorum-type: server/
>     /cluster.data-self-heal-algorithm: full/
>     /cluster.locking-scheme: granular/
>     /cluster.shd-max-threads: 8/
>     /cluster.shd-wait-qlength: 10000/
>     /features.shard: on/
>     /user.cifs: off/
>     /storage.owner-gid: 36/
>     /features.shard-block-size: 512MB/
>     /network.ping-timeout: 30/
>     /performance.strict-o-direct: on/
>     /cluster.granular-entry-heal: on/
>     /auth.allow: */
>
>           server.allow-insecure: on
>
>
> 2017-07-21 19:13 GMT+02:00 yayo (j) <jaganz at gmail.com 
> <mailto:jaganz at gmail.com>>:
>
>     2017-07-20 14:48 GMT+02:00 Ravishankar N <ravishankar at redhat.com
>     <mailto:ravishankar at redhat.com>>:
>
>
>         But it does  say something. All these gfids of completed heals
>         in the log below are the for the ones that you have given the
>         getfattr output of. So what is likely happening is there is an
>         intermittent connection problem between your mount and the
>         brick process, leading to pending heals again after the heal
>         gets completed, which is why the numbers are varying each
>         time. You would need to check why that is the case.
>         Hope this helps,
>         Ravi
>
>
>>
>>             /[2017-07-20 09:58:46.573079] I [MSGID: 108026]
>>             [afr-self-heal-common.c:1254:afr_log_selfheal]
>>             0-engine-replicate-0: Completed data selfheal on
>>             e6dfd556-340b-4b76-b47b-7b6f5bd74327. sources=[0] 1  sinks=2/
>>             /[2017-07-20 09:59:22.995003] I [MSGID: 108026]
>>             [afr-self-heal-metadata.c:51:__afr_selfheal_metadata_do]
>>             0-engine-replicate-0: performing metadata selfheal on
>>             f05b9742-2771-484a-85fc-5b6974bcef81/
>>             /[2017-07-20 09:59:22.999372] I [MSGID: 108026]
>>             [afr-self-heal-common.c:1254:afr_log_selfheal]
>>             0-engine-replicate-0: Completed metadata selfheal on
>>             f05b9742-2771-484a-85fc-5b6974bcef81. sources=[0] 1  sinks=2/
>>
>
>
>     Hi,
>
>     following your suggestion, I've checked the "peer" status and I
>     found that there is too many name for the hosts, I don't know if
>     this can be the problem or part of it:
>
>         /*gluster peer status on NODE01:*/
>         /Number of Peers: 2/
>         /
>         /
>         /Hostname: dnode02.localdomain.local/
>         /Uuid: 7c0ebfa3-5676-4d3f-9bfa-7fff6afea0dd/
>         /State: Peer in Cluster (Connected)/
>         /Other names:/
>         /192.168.10.52/
>         /dnode02.localdomain.local/
>         /10.10.20.90/
>         /10.10.10.20/
>         /
>         /
>         /
>         /
>         /
>         /
>         /
>         /
>         */gluster peer status on //NODE02:/*
>         /Number of Peers: 2/
>         /
>         /
>         /Hostname: dnode01.localdomain.local/
>         /Uuid: a568bd60-b3e4-4432-a9bc-996c52eaaa12/
>         /State: Peer in Cluster (Connected)/
>         /Other names:/
>         /gdnode01/
>         /10.10.10.10/
>         /
>         /
>         /Hostname: gdnode04/
>         /Uuid: ce6e0f6b-12cf-4e40-8f01-d1609dfc5828/
>         /State: Peer in Cluster (Connected)/
>         /Other names:/
>         /192.168.10.54/
>         /10.10.10.40/
>         /
>         /
>         /*
>         */
>         */gluster peer status on //NODE04:/*
>         /Number of Peers: 2/
>         /
>         /
>         /Hostname: dnode02.neridom.dom/
>         /Uuid: 7c0ebfa3-5676-4d3f-9bfa-7fff6afea0dd/
>         /State: Peer in Cluster (Connected)/
>         /Other names:/
>         /10.10.20.90/
>         /gdnode02/
>         /192.168.10.52/
>         /10.10.10.20/
>         /
>         /
>         /Hostname: dnode01.localdomain.local/
>         /Uuid: a568bd60-b3e4-4432-a9bc-996c52eaaa12/
>         /State: Peer in Cluster (Connected)/
>         /Other names:/
>         /gdnode01/
>         /10.10.10.10/
>
>     /
>     /
>     /
>     /
>     All these ip are pingable and hosts resolvible across all 3 nodes
>     but, only the 10.10.10.0 network is the decidated network for
>     gluster  (rosolved using gdnode* host names) ... You think that
>     remove other entries can fix the problem? So, sorry, but, how can
>     I remove other entries?
>
I don't think having extra entries could be a problem. Did you check the 
fuse mount logs for disconnect messages that I referred to in the other 
email?
>
>
>     And, what about the selinux?
>
Not sure about this. See if there are disconnect messages in the mount 
logs first.
-Ravi
>
>
>     Thank you
>
>
>
>
>
> -- 
> Linux User: 369739 http://counter.li.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170722/d43218ed/attachment-0001.html>


More information about the Users mailing list