Назад | Перейти на главную страницу

GlusterFS разбивает мозг без пути, что это значит?

Я только что проверял состояние моих томов glusterfs, и у меня есть один с разделенными записями, у которых нет пути:

# gluster volume heal private_uploads info
Brick server01:/var/lib/glusterfs/brick01/uploads/
<gfid:4c0edafb-0c28-427c-a162-e530280b3396> - Is in split-brain
<gfid:42d62418-1be9-4f96-96c4-268230316869> - Is in split-brain
Number of entries: 2

Brick server02:/var/lib/glusterfs/brick01/uploads/
<gfid:42d62418-1be9-4f96-96c4-268230316869> - Is in split-brain
<gfid:4c0edafb-0c28-427c-a162-e530280b3396> - Is in split-brain
Number of entries: 2

Что это означает? Как мне это исправить?

Я использую GlusterFS 3.5.9:

# gluster --version
glusterfs 3.5.9 built on Mar 28 2016 07:10:17
Repository revision: git://git.gluster.com/glusterfs.git

Что такое разделенный мозг?

Как упоминалось в Официальная документация по управлению разделенным мозгом предоставлено RedHat, раздвоение мозга - это состояние, когда данные или несоответствия доступности возникают из-за обслуживания двух отдельных наборов данных с перекрытием в области действия, либо из-за серверов в структуре сети, либо из-за состояния отказа, основанного на том, что серверы не обмениваются данными и не синхронизируют свои данные друг с другом. И это термин, применимый к репликации конфигурации.

Обратите внимание, что сказано «состояние отказа, основанное на том, что серверы не обмениваются данными и не синхронизируют свои данные друг с другом» - из-за любой вероятности - но это не означает, что ваши узлы могут потерять соединение. Партнер может быть еще в кластере и подключен.

Типы разделенного мозга:

У нас есть три различных типа разделенного мозга, и, насколько я могу судить, ваш - это входной разделенный мозг. Чтобы объяснить три типа расщепленного мозга:

  • Разделение данных на мозг: Содержимое файла в разделенном мозге различается в разных парах реплик, и автоматическое лечение невозможно.

  • Разделенный мозг метаданных:, Метаданные файлов (например, определяемый пользователем расширенный атрибут) отличаются, и автоматическое лечение невозможно.

  • Вступительный разделенный мозг: Это случается, когда файл имеет разные gfid для каждой пары реплик.


Что такое GFID?

Внутренний идентификатор файла GlusterFS (GFID) - это uuid, уникальный для каждого файла во всем кластере. Это аналог номера inode в нормальной файловой системе. GFID файла хранится в его xattr с именем trusted.gfid. Чтобы найти путь от GFID, настоятельно рекомендую прочитать эта официальная статья предоставлено GlusterFS.


Как разрешить запись с разделенным мозгом?

Существует несколько методов предотвращения возникновения раздвоения мозга, но для его решения необходимо удалить соответствующие файлы gfid-link. Файлы gfid-link находятся в каталоге .glusterfs в каталоге верхнего уровня блока. Кстати, имейте в виду, что перед удалением gfid-ссылок вы должны убедиться, что на этом кирпичике нет жестких ссылок на файлы. Если жесткие ссылки существуют, вы также должны их удалить. Затем вы можете использовать процесс самовосстановления, выполнив следующие команды.

А пока для просмотра списка файлов на томе, которые находятся в состоянии разделения мозга, вы можете использовать:

# gluster volume heal VOLNAME info split-brain

Вы также должны знать, что для реплицированных томов, когда кирпич отключается и возвращается в оперативный режим, требуется самовосстановление для повторной синхронизации всех реплик.

Чтобы проверить состояние восстановления томов и файлов, вы можете использовать:

# gluster volume heal VOLNAME info

Поскольку вы используете версию 3.5, у вас нет автоматического лечения. Итак, после выполнения шагов, упомянутых ранее, Вам нужно запустить самовосстановление. Для этого:

  • Только для файлов, требующих лечения:

    # gluster volume heal VOLNAME

  • По всем файлам:

    # gluster volume heal VOLNAME full

Надеюсь, это поможет вам решить вашу проблему. Пожалуйста, прочтите официальную документацию для получения дополнительной информации. Ура.

думаю документ достаточно ясно, он даже дал вам аналогичный пример.

И для целительных команд Gluesterfs, таких как

gluster volume heal **VOLNAME** split-brain latest-mtime **FILE**

ФАЙЛ может быть либо полным именем файла, как видно из корня тома (или) представление файла в виде строки gfid

Так что вам не о чем беспокоиться.

И, как преобразовать GFID в путь говорит:

Внутренний идентификатор файла GlusterFS (GFID) - это uuid, уникальный для каждого файла во всем кластере.

этот сценарий может сказать вам, какое имя файла принадлежит какому gfid, но произошло разделение мозга, возможно, у него нет имени файла.

Вы используете 3.5 и у вас нет команды полуавтоматического лечения, поэтому вам может потребоваться исправить конфликт вручную, что обычно означает решение, какой файл gfid необходимо удалить.

Как мне это исправить?

Разрешение разделенного мозга можно найти либо Вот. В случае, если это не поможет, инструкция по эксплуатации Вот должен делать свою работу. По делу я вижу статья тоже полезно.

Как избежать Split-brain.

Защита от сетевых разделов осуществляется с помощью алгоритма голосования кворума. В случае отказа хоста или сценария с разделенным мозгом, когда узлы продолжают работать, но больше не могут связываться друг с другом, оставшийся узел или узлы в гонке кластера размещают резервирование SCSI на диске-свидетеле. В случае с разделенным мозгом свидетель поможет решить, какой из хостов, хранящих копию данных, должен взять на себя управление.

Некоторые примеры.

VMware VSAN позволяет запускать кластер с двумя узлами, когда диск-свидетель работает на третьем хосте или в облаке. Источник

StarWind Virtual SAN запускается только в двухузловой настройке с использованием службы отказоустойчивого кластера Microsoft, которая также содержит механизм голосования кворума, чтобы избежать проблемы разделения функций. Источник

В обоих случаях сеть Heartbeat используется для обслуживания / мониторинга связи между узлами и кворумом. Я считаю, что во избежание раздвоения мозга обязательно использовать избыточные каналы Heartbeat.

split-brain возникает, когда два узла кластера отключены. Каждый узел считает, что другой не работает.

Чтобы исправить это, вы должны понять, почему два ваших узла больше не разговаривают друг с другом.