单个 Gluster 对等节点重新平衡不一致

单个 Gluster 对等节点重新平衡不一致

我有一个由 5 台 Gluster 服务器组成的池,这些服务器具有独立的砖块,用于以分散模式运行的卷,我在另一个数据中心添加了另外 5 个具有独立砖块的对等服务器,使此卷模式变为“分布式分散式”,砖块公式为 2 x(3 + 2)= 10。

在完全重新平衡 10 个对等节点的集群后,我注意到在一些测试中,当池 2 中的所有 5 个对等节点都与集群断开连接时,第一个池(我们称之为池 1)上的一些文件会丢失。据我所知,这种情况不应该发生,因为每个单独的池都应该有自己的分散格式的完整数据集。如果我错了,请纠正我!

我在初始重新平衡期间注意到的一件事(我假设与此相关,但没有 Gluster 专业知识来证明)是,池 #2 的节点 #4 在几秒钟内进入重新平衡的“完成”阶段,尽管每个其他节点甚至需要 24 小时以上才能完成扫描部分。此节点还列出了恰好 2 个“已扫描”文件,没有重新平衡、跳过或失败的文件:

                                    Node Rebalanced-files          size       scanned      failures       skipped               status  run time in h:m:s
                               ---------      -----------   -----------   -----------   -----------   -----------         ------------     --------------
                               localhost              159       231.4MB        269931             0             0          in progress        3:10:26
                               pool-1-2                 0        0Bytes             0             0             0          in progress        3:10:26
                               pool-1-3                 0        0Bytes             0             0             0          in progress        3:10:25
                               pool-1-4                 0        0Bytes             0             0             0          in progress        3:10:26
                               pool-1-5                 0        0Bytes             0             0             0          in progress        3:10:26
                               pool-2-1                 0        0Bytes             0             0             0          in progress        3:10:26
                               pool-2-2                 0        0Bytes             0             0             0          in progress        3:10:26
                               pool-2-3                 0        0Bytes             0             0             0          in progress        3:10:26
                               pool-2-4                 0        0Bytes             2             0             0            completed        0:00:18
                               pool-2-5                 0        0Bytes             0             0             0          in progress        3:10:26
Estimated time left for rebalance to complete :       15:08:05
volume rebalance: dev-volume: success

深入研究pool-2-4的重新平衡日志,我发现了以下有趣的消息:

[2020-08-20 21:24:20.623006] I [MSGID: 109081] [dht-common.c:4209:dht_setxattr] 0-dev-volume-dht: fixing the layout of /
...
[2020-08-20 21:24:29.720716] I [MSGID: 0] [dht-rebalance.c:3737:gf_defrag_total_file_cnt] 0-dev-volume-dht: Total number of files = 1684196
[2020-08-20 21:24:29.720725] E [MSGID: 0] [dht-rebalance.c:3900:gf_defrag_start_crawl] 0-dev-volume-dht: Failed to get the total number of files. Unable to estimate time to complete rebalance.
...
[2020-08-20 21:24:29.725724] I [dht-rebalance.c:2745:gf_defrag_process_dir] 0-dev-volume-dht: migrate data called on /
[2020-08-20 21:24:29.725828] W [dict.c:416:dict_set] (-->/usr/lib64/glusterfs/3.10.1/xlator/cluster/distribute.so(+0x42f51) [0x7fed71172f51] -->/lib64/libglusterfs.so.0(dict_set_int32+0x2b) [0x7fed78af14eb] -->/lib64/libglusterfs.so.0(dict_set+0xe6) [0x7fed78aefc56] ) 0-dict: !this || !value for key=readdir-filter-directories [Invalid argument]
[2020-08-20 21:24:29.725845] E [MSGID: 109003] [dht-common.c:4917:dht_opendir] 0-dev-volume-dht: Failed to set dictionary value :key = readdir-filter-directories, ret:-1
[2020-08-20 21:24:32.718807] I [dht-rebalance.c:2959:gf_defrag_process_dir] 0-dev-volume-dht: Migration operation on dir / took 2.99 secs
[2020-08-20 21:24:32.718898] W [dict.c:416:dict_set] (-->/usr/lib64/glusterfs/3.10.1/xlator/cluster/distribute.so(+0x42f51) [0x7fed71172f51] -->/lib64/libglusterfs.so.0(dict_set_int32+0x2b) [0x7fed78af14eb] -->/lib64/libglusterfs.so.0(dict_set+0xe6) [0x7fed78aefc56] ) 0-dict: !this || !value for key=readdir-filter-directories [Invalid argument]
[2020-08-20 21:24:32.723301] I [dht-rebalance.c:3994:gf_defrag_start_crawl] 0-DHT: crawling file-system completed
...
[2020-08-20 21:24:32.723730] I [MSGID: 109028] [dht-rebalance.c:4277:gf_defrag_status_get] 0-dev-volume-dht: Files migrated: 0, size: 0, lookups: 2, failures: 0, skipped: 0
[2020-08-20 21:24:32.723894] W [glusterfsd.c:1329:cleanup_and_exit] (-->/lib64/libpthread.so.0(+0x7dc5) [0x7fed77958dc5] -->/usr/sbin/glusterfs(glusterfs_sigwaiter+0xe5) [0x556351afaf85] -->/usr/sbin/glusterfs(cleanup_and_exit+0x6b) [0x556351afadfb] ) 0-: received signum (15), shutting down

我的其他每个节点都以等于 0 的“文件总数”开始,并且可以清楚地看到每个子文件夹中的每个文件都通过一条消息进行重新平衡:

[2020-08-12 19:56:49.614327] I [dht-rebalance.c:2745:gf_defrag_process_dir] 0-dev-volume-dht: migrate data called on /data/jobs
[2020-08-12 19:56:49.820702] I [MSGID: 109081] [dht-common.c:4209:dht_setxattr] 0-dev-volume-dht: fixing the layout of /data/jobs/201501
[2020-08-12 19:56:50.294380] I [dht-rebalance.c:2745:gf_defrag_process_dir] 0-dev-volume-dht: migrate data called on /data/jobs/201501
[2020-08-12 19:56:50.518000] I [MSGID: 109081] [dht-common.c:4209:dht_setxattr] 0-dev-volume-dht: fixing the layout of /data/jobs/201501/00
[2020-08-12 19:56:50.863319] I [dht-rebalance.c:2745:gf_defrag_process_dir] 0-dev-volume-dht: migrate data called on /data/jobs/201501/00
[2020-08-12 19:56:51.116676] I [MSGID: 109081] [dht-common.c:4209:dht_setxattr] 0-dev-volume-dht: fixing the layout of /data/jobs/201501/02

!value for key=readdir-filter-directories [Invalid argument]我也没有在任何其他节点收到任何消息。

如果我检查 gluster mount 的数据目录内所有文件的大小总和(分散因此不是数据的完整表示),我可以看到它显然包含大量内容:

[root@pool-2-4 dev-volume]# du -csh *
8.0K    backups
158G    data
25M     etc
8.0K    lost+found
38G     static
783M    bin
196G    total

我在重新平衡日志中看到的错误是否表明池 2 脱机时池 1 丢失文件的问题?这可能是一个完全独立的问题吗?我对此的整个理解是否不正确?

对于这个问题的稍微模糊性,我深感抱歉,并向任何能够提供见解的人表示感谢。

相关内容