Я установил ha-кластер pacemaker / corosync в конфигурации аварийного переключения с двумя узлами: производительным и резервным. Есть три раздела DRBD. Пока все работает нормально.
Я использую Nagios NRPE на обоих узлах для мониторинга сервера с помощью icinga2 в качестве инструмента отчетности и визуализации. Теперь, когда разделы DRBD на резервном узле не монтируются до тех пор, пока не будет переключателя аварийного переключения, я всегда получаю критические предупреждения для них:
Следовательно, это ложное предупреждение. Я уже наткнулся на DISABLE_SVC_CHECK и пробовал его реализовать, вот пример:
echo "[`date +%s`] DISABLE_SVC_CHECK;$host_name;$service_name" >> "/var/run/icinga2/cmd/icinga2.cmd"
Разве нет простого способа / наилучшей практики отключить эту проверку DRBD на резервном узле в Nagios или Icinga2? Конечно, я хочу, чтобы эта проверка вступила в силу для резервного сервера после аварийного переключения.
В моей среде мы управляем несколькими службами, работающими поверх устройств drbd (традиционные, контейнеры lxc, контейнеры докеров, базы данных и т. Д.). Мы используем стек opensvc (https://www.opensvc.com), который является бесплатным, с открытым исходным кодом и предоставляет функции автоматического переключения при отказе. Ниже представлена тестовая служба с drbd и приложение Redis (в примере отключено)
Сначала на уровне кластера мы можем увидеть в svcmon
вывод что:
На уровне обслуживания svcmgr -s servdrbd print status
, мы можем увидеть :
Чтобы смоделировать проблему, я отключил устройство drbd на вторичном узле, и это привело к следующему предупреждения
Важно видеть, что статус доступности сервиса по-прежнему вверх, но общий статус службы снижается до предупреждать, что означает "хорошо, производство все еще идет нормально, но что-то идет не так, посмотрите"
Как только вы знаете, что все команды opensvc можно использовать с селектором вывода json (nodemgr daemon status --format json
или svcmgr -s servdrbd print status --format json
), его легко подключить к сценарию NRPE и просто отслеживать состояние службы. И, как вы видели, любая проблема на первичном или вторичном уровне оказывается в ловушке.
В nodemgr daemon status
лучше, потому что это один и тот же вывод на всех узлах кластера, и вся информация о службах openvc отображается в одном вызове команды.
Если вас интересует файл конфигурации службы для этой установки, я разместил его на pastebin Вот
Я бы посоветовал не отслеживать это напрямую на хосте. В нашей среде мы используем Pacemaker для автоматизации отработки отказа. Одна из вещей, которые Pacemaker делает для нас, - перемещает IP-адрес при переключении. Это гарантирует, что наши клиенты всегда указывают на основной, и помогает сделать переключение на отказ прозрачным со стороны клиента.
Для Nagios мы отслеживаем множество сервисов на каждом хосте, чтобы следить за происходящим, но затем у нас есть дополнительный «хост», настроенный для виртуального / плавающего IP-адреса для мониторинга устройств и сервисов DRBD, которые работают только на первичном.
Вы могли бы использовать check_multi чтобы запустить обе проверки DRBD как одну проверку Nagios, и настроить его так, чтобы он возвращал ОК, если ровно один дополнительных проверок в порядке.
Однако становится сложно решить, к какому хосту прикрепить чек. Вы можете прикрепить его к хосту с помощью VIP или прикрепить чек к обоим хостам и использовать NRPE / ssh на каждом для проверки другого и т. Д.