Отказоусточивый мониторинг на основе zabbix.

[bogdar]

Хочется два равноправных сервера, которые получают данные от одних и тех же агентов и рассылают алерты.
При этом, в случае падения любого из серверов система продолжает работать, исправно собирать метрики и слать ругательные письма.
Как такого рода схему реализовать на zabbix ?

[csf]

Общее соображения.

Используемые пакеты: drbd, heartbeat. Отказоустойчивый кластер.

Принцип работы. zabbix-a (активный) имеет два сетевых интерфейса, один работает только на синхронизацию данных, стоит постоянно. Второй (может быть и несколько) "виртуальный" работает только на активном сервере.
База данных (в моем случае это Mysql) стоит на drbd-диске, который синхронизирован с zabbix-b. На zabbix-b этот диск не смонтиирован.
В случае "падения" zabbix-a heartbeat автоматически делает:


На Zabbix-a:

1. Останавливает zabbix_server
2. останавливает Mysql
3. Размонтирует /dev/drbdX/Каталог_с_базой_данных
4. Выключает виртуальные сетевые интерфейсы.
5. Последний раз (если сможет) посылает E-mail и SMS.

На Zabbix-b

1. Монтирует /dev/drbdX/Каталог_с_базой_данных
2. Включает виртуальные сетевые интерфейсы.
3. Стартует mysql
4. Cтартует zabbix_server.

[den_crane]

Originally Posted by bogdar

Хочется два равноправных сервера, которые получают данные от одних и тех же агентов и рассылают алерты.
При этом, в случае падения любого из серверов система продолжает работать, исправно собирать метрики и слать ругательные письма.
Как такого рода схему реализовать на zabbix ?

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

[csf]

Originally Posted by den_crane

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

Спасибо, я не знал этого. И при этом могут писать в общую базу или при таком решении у каждого zabbix-сервера она своя ?

[den_crane]

Originally Posted by csf

Спасибо, я не знал этого. И при этом могут писать в общую базу или при таком решении у каждого zabbix-сервера она своя ?

у каждого своя, и смс-ки и письма будут двоится .
Надо искать на английском уже обсуждались эти варианты.

ЗЫЖ Я вообще не понимаю зачем нужна отказоустойчивая система мониторинга.

[csf]

Originally Posted by den_crane

у каждого своя, и смс-ки и письма будут двоится .
Надо искать на английском уже обсуждались эти варианты.

ЗЫЖ Я вообще не понимаю зачем нужна отказоустойчивая система мониторинга.

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

[den_crane]

Originally Posted by csf

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

тогда вместо drbd стоит использовать репликацию бд.


Я просто видимо не понимаю слово "падает"

nag:~ # uptime
5:37pm включен 307 дней 22:09, 1 пользователь, средняя загруженность: 0,20, 0,36, 0,27

nag:~ # ps -ef|grep zabb|head -2
root 6232 6189 0 17:38 pts/1 00:00:00 grep zabb
zabbix 15306 1 0 Jun18 ? 00:00:03 /usr/local/sbin/zabbix_server

[bogdar]

Спасибо за ответы!

Варианты с drbd, отказоустойчивыми виртуалками, никогда не ломающимися брендовыми серверами т.п. живут ровно до первого прямого попадания пионэра в корневые коммутаторы ДЦ.
В настощий момент у меня шкафы в 3 ДЦ, две пары dmz+lan и некоторое количество всякой хрени в других местах.

Так что мониторинг должен быть отказоусточивым и распределенным...
Пока что я вижу вариант с двумя "идентичными" серверами, один из которых просто не рассылает алерты, пока жив второй.

1) Есть ли какие встроенные средства включения/выключения отправки алертов по триггеру? Если нет - то где чего надо подкрутить в БД, что, скажем, юзеру userid начали приходить сообщения?

2) Как синхронизировать конфигурации серверов - хостов много, изменения в мониторинг вносятся довольно часто, процент ошибок при ручной синхронизации будет весьма высоким.

3) Чего почитать в основном форуме на эту тему?

[costas]

Вариант с drbd не очень удачный, идея в корне правильна, но... drbd не очень подходит для зеркалирования СУБД MySQL при наличии таблиц InnoDB, важно понимать что зеркалирование происходить на уровне блочного устройства и в данном случаее не обеспечивает 100% целостности таблиц, это равносильно копированию файлов таблиц со всеми вытекающими последствиями.

В качесте схемы иожно отлакиваться от наличия двух пар серверов, тоесть MySQL+Zabbix (где mysq это primary сервер выполняющий репликацию данных на другой сервер (slave) и дополнительный сервер Zabbix натроенный на работу со вторым сервером MySQL (slave), heartbeat в этой схеме необходим для запуска второго Zabbix сервера с тем же IP что был и у основного (дабы не заниматься приседанием с настройкой клиентов), по репликации MySQL (мастер-слейв, мастер-мастер) найдёте много информации, ну и сами определитесь какой вариант для вас лучше.

Резернове копировнаие базы zabbix то же осуществляется обычно с сервера (mysql slave) который развёрнут посредством реплики, если Вас конечно беспокоят даунтаймы.

[bogdar]

Originally Posted by costas

В качесте схемы иожно отлакиваться от наличия двух пар серверов, тоесть mysql+zabbix (где mysq это primary сервер выполняющий репликацию данных на другой сервер (slave) и дополнительный сервер zabbix натроенный на работу со вторым сервером mysql (slave), heartbeat в этой схеме необходим для запуска второго zabbix сервера с тем же ip что был и у основного (дабы не заниматься приседанием с настройкой клиентов), по репликации mysql (мастер-слейв, мастер-мастер) найдёте много информации, ну и сами определитесь какой вариант для вас лучше.

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