Добрый день, коллеги!
Ситуация: 3 ноды в кластере gluster, ОС Centos7:
# gluster --version
glusterfs 9.6
Repository revision: git://git.gluster.org/glusterfs.git
Copyright (c) 2006-2016 Red Hat, Inc. <https://www.gluster.org/>
GlusterFS comes with ABSOLUTELY NO WARRANTY.
It is licensed to you under your choice of the GNU Lesser
General Public License, version 3 or any later version (LGPLv3
or later), or the GNU General Public License, version 2 (GPLv2),
in all cases as published by the Free Software Foundation.
# gluster volume info
Volume Name: gv0
Type: Replicate
Volume ID: 0ce5aeb8-59f0-46a7-8523-7cd2b1cc1d6b
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: bx-app01:/data/brick1/gv0
Brick2: bx-app02:/data/brick1/gv0
Brick3: bx-app03:/data/brick1/gv0
Options Reconfigured:
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off
В познавательных целях, ноду bx-app03 удаляю и пытаюсь восстановить с такими-же сетевыми параметрами и UUID используя такой алгоритм (
статья, см. 10.6.2.):
1. Поднимаю новую (далее по тексту свежая) ноду bx-app03, устанавливаю всё необходимое ПО (glusterfs-server, lvm2), создаю каталог /data/brick1/gv0, если сервис glusterd был запущен останавливаю (systemctl stop glusterd).
2. Получаю UUID вышедшего из строя сервера с другого сервера (bx-app01):
# gluster peer status
Number of Peers: 2
Hostname: bx-app02.org.test
Uuid: 162ebb8c-f055-40df-a4a2-002d6c3baf3b
State: Peer in Cluster (Connected)
Other names:
bx-app02
Hostname: bx-app03
Uuid: 5a9d71f7-d4ab-4945-a1b8-d39c189c3fb2
State: Peer in Cluster (Disconnected)
3. На свежем узле (bx-app03) редактирую файл /var/lib/glusterd/glusterd.info и меняю UUID на старый, полученный на предыдущем шаге (5a9d71f7-d4ab-4945-a1b8-d39c189c3fb2).
4. С оставшихся двух узлов (bx-app01, bx-app02) копирую все файлы из каталога /var/lib/glusterd/peers/ на свежий узел bx-app03 в ту-же папку, за исключением файла с UUID самого узла bx-app03 (5a9d71f7-d4ab-4945-a1b8-d39c189c3fb2), т.е. в папке /var/lib/glusterd/peers/ на bx-app03 должно быть два файла с именами соответствующих UUID узлов bx-app01 и bx-app02.
5. Получаю идентификатор (trusted.glusterfs.volume-id) тома из существующего brick на сервере bx-app01:
# getfattr -d -m. -ehex /data/brick1/gv0
getfattr: Removing leading '/' from absolute path names
# file: data/brick1/gv0
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.gv0-client-2=0x000000000000000200000002
trusted.gfid=0x00000000000000000000000000000001
trusted.glusterfs.mdata=0x0100000000000000000000000064034270000000002d71da40000000006403425900000000033ca8d30000000063ffd45800000000376d7911
trusted.glusterfs.volume-id=0x0ce5aeb859f046a785237cd2b1cc1d6b
6. Устанавливаю этот идентификатор на свежем узле bx-app03:
# setfattr -n trusted.glusterfs.volume-id -v 0x0ce5aeb859f046a785237cd2b1cc1d6b /data/brick1/gv0
7. Монтирую том gluster в /mnt на свежем узле:
# mount -t glusterfs bx-app01:/gv0 /mnt
8. Далее, выполняю операции чтобы изменить расширенные атрибуты автоматической репликации файлов, чтобы процесс восстановления происходил с другого brick (bx-app01:/data/brick1/gv0) на свежий (bx-app03:/data/brick1/gv0). Создаю новую папку, которой не существует:
# mkdir /mnt/test
9. Удаляю папку, и устанавливаю расширенные атрибуты:
# rmdir /mnt/test
# setfattr -n trusted.non-existent-key -v abc /mnt
# setfattr -x trusted.non-existent-key /mnt
10. Убеждаюсь, что расширенный атрибут trusted.afr.gv0-client-0 на других репликах не равен 0 (нулю):
# getfattr -d -m. -e hex /data/brick1/gv0
getfattr: Removing leading '/' from absolute path names
# file: data/brick1/gv0
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.gv0-client-2=0x000000000000000200000002
trusted.gfid=0x00000000000000000000000000000001
trusted.glusterfs.mdata=0x0100000000000000000000000064034270000000002d71da40000000006403425900000000033ca8d30000000063ffd45800000000376d7911
trusted.glusterfs.volume-id=0x0ce5aeb859f046a785237cd2b1cc1d6b
11. Вроде-бы все ок, запускаю сервис на свежем узле:
# systemctl start glusterd
# gluster volume heal gv0
Launching heal operation to perform index self heal on volume gv0 has been unsuccessful:
Self-heal daemon is not running. Check self-heal daemon log file.
Собственно в этом вопрос и состоит. Как это разрешить?
Средний
Средний