Форум русскоязычного сообщества Ubuntu


Хотите сделать посильный вклад в развитие Ubuntu и русскоязычного сообщества?
Помогите нам с документацией!

Автор Тема: DRBD самопроизвольно переключился с primary role на secondary  (Прочитано 1249 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн 027

  • Автор темы
  • Участник
  • *
  • Сообщений: 108
  • Cinnamon
    • Просмотр профиля
Столкнулся к крайне неприятным явлением. После планового отключения электроэнергии (сервер был погашен штатно), при включении сервера вечером, он откликался только на пинг. Пришлось тащить к нему монитор и клаву.
Оказалось, что Ubuntu впадает в emergency mode, в котором не работает даже sshd.
Причиной впадения сервера в ужос явилась невозможность автомонтирования (через fstab) ресурса drbd, который служит для складирования бэкапов.
Закомментировал строку в fstab, сервер поднялся штатно, запустились контейнеры, и все заколосилось.

При ближайшем рассмотрении оказалось, что drbd-ресурс по непонятной причине сменил роль на secondary:
drbdadm role r0
Secondary/Secondary
а должно быть:
Primary/SecondaryРесурс в такой роли не может быть смонтирован никак (хоть и пишут, что в ридонли якобы можно).
После пинка в афедрон
drbdadm primary r0ресурс нормально примонтировался и стал доступен полноценно.
По данным смарт, hdd в отличном состоянии, бэдов ноль. Свободного места на разделе полно, 99% не занято.

Что это было?  :-\

Костыльно-огородные меры принял: убрал запись в fstab, монтирование теперь по крону из основного скрипта бэкапа, заодно написал всяческие проверки с попытками автоматического исправления, ну и подробное логирование. Но что это было?..
Разовый глюк, или я не умею читать маны есть какой-то секрет в конфигурировании?
Настраивал тупо по оф. доке, простейший вариант, никаких извращений (с двумя мастерами и пр.), нагрузка на сервис drbd микроскопическая — раз в сутки синхронизировать поштучно формируемые файлы суммарно на пару сотен мегабайт.

ubuntu server 16.04
drbd 8.9.6 из штатного репо
Железо, правда, десктопное, но за полгода работы никаких претензий не было.
Общая нагрузка на железо низкая.
« Последнее редактирование: 17 Июль 2017, 21:13:11 от 027 »
Если бы было достаточно man bash, не было бы ABS.

Punko

  • Гость
027, в логах ничего интересного?
Насколько я знаю, то drbd завязывается на hostname.
С сетью никаких изменений не было?

Оффлайн 027

  • Автор темы
  • Участник
  • *
  • Сообщений: 108
  • Cinnamon
    • Просмотр профиля
027, в логах ничего интересного?
inetadmin@web-node:~$ journalctl -q -u drbd
июл 14 18:25:34 web-node systemd[1]: Starting LSB: Control drbd resources....
июл 14 18:25:35 web-node drbd[1353]:  * Starting DRBD resources
июл 14 18:25:36 web-node drbd[1353]: [
июл 14 18:25:36 web-node drbd[1353]:      create res: r0 r1
июл 14 18:25:36 web-node drbd[1353]:    prepare disk: r0 r1
июл 14 18:25:38 web-node drbd[1353]:     adjust disk: r0 r1
июл 14 18:25:38 web-node drbd[1353]:      adjust net: r0 r1
июл 14 18:25:38 web-node drbd[1353]: ]
июл 14 18:26:00 web-node drbd[1353]: WARN: stdin/stdout is not a TTY; using /dev/console
июл 14 18:26:00 web-node drbd[1353]:    ...done.
июл 14 18:26:00 web-node systemd[1]: Started LSB: Control drbd resources..
Это последний запуск, после закомментирования строки в fstab и перезагрузки.
Насколько я знаю, то drbd завязывается на hostname.
Да, hostname прописаны на обоих компах и в конфиге drbd.
С сетью никаких изменений не было?
Никаких рулений сетью не производилось. Вечером в четверг выключили все, что не требовалось для обеспечения работы веб- и мыл-серверов. Утром 14 июля я остановил штатно оставшееся, выключил UPSы и отрубил ввод на щитке. Вечером включил юпсы поштучно, четыре сервера автозапустились при появлении питания, один нет (резервный контроллер мелкомягкого домена). Но этот сервер, web-node, к микрософт домену никаким боком, да и ко всем другим участникам сети. Мне думается, не должно быть никакого влияния чего-то-там-не-того в сети на DRBD дивайс в роли мастера (он же праймари), оно как бы рассчитано на всевозможные сетевые катаклизмы. Да и перезагружал я его потом два раза, наблюдая за выводом на подключенном мониторе.

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


Пользователь добавил сообщение 19 Июль 2017, 19:56:27:
...обвешал скрипт бэкапа всяческими проверялками и стучалками по мылу... будем наблюдать.

Пользователь добавил сообщение 19 Июль 2017, 20:11:37:
Совсем забыл, после успешного старта в пятницу на мониторе вылезло это:
 

ХЗ, что за пир имеется в виду.
« Последнее редактирование: 19 Июль 2017, 20:11:37 от 027 »
Если бы было достаточно man bash, не было бы ABS.

Punko

  • Гость
Тут я помочь не смогу, нет знаний глубоких по DRBD, к сожалению.

оно как бы рассчитано на всевозможные сетевые катаклизмы

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

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 27412
    • Просмотр профиля
drbd завязывается на hostname.
Я вот подумал… А насколько эта привязка жёсткая?
Можно ли это настроить?
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Punko

  • Гость
AnrDaemon, насколько я знаю - нет. И это как-то странно, потому что идёт завязка на ДНС.

Оффлайн 027

  • Автор темы
  • Участник
  • *
  • Сообщений: 108
  • Cinnamon
    • Просмотр профиля
А при чем тут днс?
Если бы было достаточно man bash, не было бы ABS.

Оффлайн 027

  • Автор темы
  • Участник
  • *
  • Сообщений: 108
  • Cinnamon
    • Просмотр профиля
Опять.
На это раз аварийное отключение электроэнергии. Выключил штатно, командой по ssh.
После включения:
root@web-node:~# journalctl -u drbd
-- Logs begin at Пт 2017-07-28 11:35:39 +03, end at Пт 2017-07-28 19:00:52 +03. --
июл 28 11:35:51 web-node systemd[1]: Starting LSB: Control drbd resources....
июл 28 11:35:52 web-node drbd[1321]:  * Starting DRBD resources
июл 28 11:35:52 web-node drbd[1321]: [
июл 28 11:35:52 web-node drbd[1321]:      create res: r0 r1
июл 28 11:35:52 web-node drbd[1321]:    prepare disk: r0 r1
июл 28 11:35:54 web-node drbd[1321]:     adjust disk: r0 r1
июл 28 11:35:54 web-node drbd[1321]:      adjust net: r0 r1
июл 28 11:35:54 web-node drbd[1321]: ]
июл 28 11:40:51 web-node systemd[1]: drbd.service: Start operation timed out. Terminating.
июл 28 11:40:51 web-node systemd[1]: Failed to start LSB: Control drbd resources..
июл 28 11:40:51 web-node systemd[1]: drbd.service: Unit entered failed state.
июл 28 11:40:51 web-node systemd[1]: drbd.service: Failed with result 'timeout'.
июл 28 11:53:12 web-node drbd[1321]: WARN: stdin/stdout is not a TTY; using /dev/console
Проверяю роль:
root@web-node:~# drbdadm role r0
Secondary/Secondary
Включаю правильную роль:
root@web-node:~# drbdadm primary r0

root@web-node:~# drbdadm role r0
Primary/Secondary

root@web-node:~# cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
srcversion: 4B3E2E2CD48CAE5280B5205

 1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:749568 nr:0 dw:0 dr:750208 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Перед вводом в эксплуатацию проверял поднятие drbd несколькими перезагрузками и полными отключениями. Проработал несколько месяцев, и нате вам.

Если бы было достаточно man bash, не было бы ABS.

 

Страница сгенерирована за 0.23 секунд. Запросов: 25.