- «Зависшая» клиентская сессия beegfs.
В выводе команды beegfs-ctl —listnodes —nodetype=client можно заметить 2 сессии с одного хоста. Сессии имеют разные ID, одна активная, действительная сессия, вторая просто «висит», даже если служба клиента остановлена на самом клиенте, или хост на котором располагается клиент недоступен/выключен.
Для начала необходимо убедиться, что это является неверным поведением в данном случае, поскольку beegfs позволяет запускать несколько клиентов файловой системы с одного хоста, в добавок еще и разных версий.
Далее стоит попробовать перезапустить службу beegfs-mgmtd на управляющем сервере beegfs, затем перезапустить службу beegfs-client на проблемном клиенте.
Если все эти меры не помогли, и после перезапуска служб сессия по прежнему «висит», тогда следует приступить к изучению директории установки вашего инстанса beegfs. Обычно это что-то вроде /beegfs/mgmt/. В этой директории храниться файл clients.nodes это генерируемый бинарник, в котором хранятся действующие сессии файловой системы. Важно сделать бэкап этого файла перед любыми вмешательствами руками
cp /beegfs/mgmt/clients.nodes /backup/
Затем необходимо остановить службу beegfs-mgmtd:
systemctl stop beegfs-mgmtd
Открыв файл редактором вы обнаружите имена клиентов, ID сессий, и некоторые бинарные данные, необходимо отредактировать файл, удалив из него «зависшую» сессию и часть бинарных данных вокруг него. Удалять нужно секцию между разделителями, обычно это символ |. После редактирования файла, сохраните изменения и перезапустите службу, вероятнее всего это поможет.
В случае, если этот метод вам не поможет, то можно попробовать другое решение — удалить данный файл, после чего остановить службу управления beegfs-mgmtd, остановить клиентские службы на всех хостах вашей файловой системы. Затем запустить службу beegfs-mgmtd, и запускать клиентские службы на хостах по очереди. В случае возникновения проблем при подключении клиентов после удаления файла, нужно смотреть в файл логов /var/log/beegfs-mgmtd.log там описывается процесс регистрации новых клиентов, что может указать на наличие проблем.
2. Ошибка синхронизации на metadata node/metadata buddygroup при сбоях в работе файловой системы.
При сбоях в работе файловой системы возможно возникновение неконсистетентного состояния нод файловой системы, состояние нод можно изучить выполнив команду:beegfs-ctl --listtargets --nodetype=meta --state
TargetID Reachability Consistency NodeID
======== ============ =========== ======
1 Online Needs-resync 1
2 Online Needs-resync 2
В таком состоянии невозможна ре-синхронизация нод в автоматическом режиме. Для устранения данной проблемы необходимо прежде всего отключить всех клиентов файловой системы (остановить службу beegfs-client.service на хостах, где она запущена) , при наличии любого количества клиентов синхронизация невозможна.
Затем необходимо принудительно изменить состояние основной ноды на «good» командой, в данном случае основная нода — это нода с ID=2:beegfs-ctl --setstate --nodetype=meta --nodeid=2 --state=good --force
Убедимся, что состояние ноды корректно изменилось:beegfs-ctl --listtargets --nodetype=meta --state
TargetID Reachability Consistency NodeID
======== ============ =========== ======
1 Online Needs-resync 1
2 Online good 2
Изменив состояние ноды, можно приступать к ре-синхронизации, существует два варианта запустить этот процесс в ручном режиме — указать в качестве цели запроса группу нод объединенные между собой (buddygroup), или какую то определенную ноду(nodeid).
В примере ниже мы сначала узнаем есть ли в данном инстансе buddygroup, ID этой группы, если она существует и запустим процесс ресинхронизации в ручном режиме.beegfs-ctl --listmirrorgroups --nodetype=storage
No mirror buddy groups defined.
beegfs-ctl --listmirrorgroups --nodetype=meta
BuddyGroupID PrimaryNodeID SecondaryNodeID
============ ============= ===============
1000 2 1
#Запуск ресинхронизации, через nodeid
beegfs-ctl --startresync --nodetype=meta --nodeid=1
#Запуск ресинхронизации, через mirrorgroupid
Resync request sent.
beegfs-ctl --startresync --nodetype=meta --mirrorgroupid=1000
Resync request sent.
Далее начнется обратный отчет, цель которого — убедиться в отсутствии клиентов и запросов к файловой системе (360 секунд) отбратный отчет будет зафиксирован в логах той службы, которую вы ресинхронизируете — в данному случае в логе /var/log/beegfs-meta.log.
После обратного отчета начнется процесс ресинхронизации, результат которого так же будет записан в лог службы. Во время ресинхронизации можно наблюдать за процессом с помощью команды:beegfs-ctl --resyncrstats --notetype=meta --nodeid=2
Job state: Completed successfully
Job start time: Thu Mar 4 13:38:23 2021
Job end time: Thu Mar 4 13:44:46 2021
of discovered dirs: 648489
of discovery errors: 0
of synced dirs: 648489
of synced files: 4981609
of dir sync errors: 0
of file sync errors: 0
of client sessions to sync: 10
of synced client sessions: 10
session sync error: No
of modification objects synced: 686
of modification sync errors: 0
После завершения этих процедур, можно запускать клиентов, файловая система готова к работе.