View Full Version : Отказоусточивый мониторинг на основе zabbix.
Хочется два равноправных сервера, которые получают данные от одних и тех же агентов и рассылают алерты.
При этом, в случае падения любого из серверов система продолжает работать, исправно собирать метрики и слать ругательные письма.
Как такого рода схему реализовать на zabbix ?
Общее соображения.
Используемые пакеты: 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
02-11-2009, 15:13
Хочется два равноправных сервера, которые получают данные от одних и тех же агентов и рассылают алерты.
При этом, в случае падения любого из серверов система продолжает работать, исправно собирать метрики и слать ругательные письма.
Как такого рода схему реализовать на zabbix ?
два заббикс сервера могут собирать данные с одних и тех-же клиентов. Апишники серверов в агентах записываются через запятую
два заббикс сервера могут собирать данные с одних и тех-же клиентов. Апишники серверов в агентах записываются через запятую
Спасибо, я не знал этого. И при этом могут писать в общую базу или при таком решении у каждого zabbix-сервера она своя ?
den_crane
02-11-2009, 15:25
Спасибо, я не знал этого. И при этом могут писать в общую базу или при таком решении у каждого zabbix-сервера она своя ?
у каждого своя, и смс-ки и письма будут двоится :).
Надо искать на английском уже обсуждались эти варианты.
ЗЫЖ Я вообще не понимаю зачем нужна отказоустойчивая система мониторинга.
у каждого своя, и смс-ки и письма будут двоится :).
Надо искать на английском уже обсуждались эти варианты.
ЗЫЖ Я вообще не понимаю зачем нужна отказоустойчивая система мониторинга.
Тогда я, пожалуй, больше за свой вариант с heartbeat.
А отказоустойчивость ее - для нас, напимер, очень важна, т.к. если она "падает" - не приходят оповещения о возможных других проблемах. Особенно в ночное время.
den_crane
02-11-2009, 15:41
Тогда я, пожалуй, больше за свой вариант с 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
Спасибо за ответы!
Варианты с drbd, отказоустойчивыми виртуалками, никогда не ломающимися брендовыми серверами т.п. живут ровно до первого прямого попадания пионэра в корневые коммутаторы ДЦ.
В настощий момент у меня шкафы в 3 ДЦ, две пары dmz+lan и некоторое количество всякой хрени в других местах.
Так что мониторинг должен быть отказоусточивым и распределенным...
Пока что я вижу вариант с двумя "идентичными" серверами, один из которых просто не рассылает алерты, пока жив второй.
1) Есть ли какие встроенные средства включения/выключения отправки алертов по триггеру? Если нет - то где чего надо подкрутить в БД, что, скажем, юзеру userid начали приходить сообщения?
2) Как синхронизировать конфигурации серверов - хостов много, изменения в мониторинг вносятся довольно часто, процент ошибок при ручной синхронизации будет весьма высоким.
3) Чего почитать в основном форуме на эту тему?
Вариант с drbd не очень удачный, идея в корне правильна, но... drbd не очень подходит для зеркалирования СУБД MySQL при наличии таблиц InnoDB, важно понимать что зеркалирование происходить на уровне блочного устройства и в данном случаее не обеспечивает 100% целостности таблиц, это равносильно копированию файлов таблиц со всеми вытекающими последствиями.
В качесте схемы иожно отлакиваться от наличия двух пар серверов, тоесть MySQL+Zabbix (где mysq это primary сервер выполняющий репликацию данных на другой сервер (slave) и дополнительный сервер Zabbix натроенный на работу со вторым сервером MySQL (slave), heartbeat в этой схеме необходим для запуска второго Zabbix сервера с тем же IP что был и у основного (дабы не заниматься приседанием с настройкой клиентов), по репликации MySQL (мастер-слейв, мастер-мастер) найдёте много информации, ну и сами определитесь какой вариант для вас лучше.
Резернове копировнаие базы zabbix то же осуществляется обычно с сервера (mysql slave) который развёрнут посредством реплики, если Вас конечно беспокоят даунтаймы.
В качесте схемы иожно отлакиваться от наличия двух пар серверов, тоесть mysql+zabbix (где mysq это primary сервер выполняющий репликацию данных на другой сервер (slave) и дополнительный сервер zabbix натроенный на работу со вторым сервером mysql (slave), heartbeat в этой схеме необходим для запуска второго zabbix сервера с тем же ip что был и у основного (дабы не заниматься приседанием с настройкой клиентов), по репликации mysql (мастер-слейв, мастер-мастер) найдёте много информации, ну и сами определитесь какой вариант для вас лучше.
Заведомо проигрышный вариант - куча железа, которая оказывается не нужна сразу после того, как в в данном конкретном месте закончится интернет.
Заведомо проигрышный вариант - куча железа, которая оказывается не нужна сразу после того, как в в данном конкретном месте закончится интернет.
Если в данном конкретном месте закончится интернет то думаю с таким качеством связи не требуется мониторинг, на счёт варината - это типичное решение уровня Enterprise, всё зависит от маштабов сети, если мониторинг предполагается на пару тройку серверов, то соответсвенно возможно и смысла нет думать об отказоустойчивости сервиса, бюджет в данном случаее определяет выбор решения, но DRBD в любом виде не решает проблему с сохранением целостности данных для СУБД.
Так у вас база на кластере и два сервера с забиксом?
Забикс сервер это не кластер?
Просто не совсем понятно зачем делать второй забикс без отдельной базы?
Я вообще могу прикинуть примерно так: (у нас выход на смс и почту через один сервер, забикс закрыт от интернета), на этом шлюзе можно фильтровать одинаковые смски, и держать два отдельных сервер со своими же базами данных, а всех агентов отнастраивать на два сервера.
Видимо, придется синхронизировать таблицы настроек БД отдельной командой
типичное решение уровня Enterprise
Не, ну может у вас какой-то особенный энтерпрайз :)
В моем энтерпрайзе фрагментарная потеря связаности ДЦ со внешним миром, вплоть до полной недоступности. Причем случается такое с различными ДЦ. Это не говоря уже о проблемах с окружающей средой которые для России - суровая реальность.
Ставить zabbix в одну точку - совсем не вариант.
Нужно два независимых сервер с автоматической синхронизацией конфигурации...
Не, ну может у вас какой-то особенный энтерпрайз :)
В моем энтерпрайзе фрагментарная потеря связаности ДЦ со внешним миром, вплоть до полной недоступности. Причем случается такое с различными ДЦ. Это не говоря уже о проблемах с окружающей средой которые для России - суровая реальность.
Ставить zabbix в одну точку - совсем не вариант.
Нужно два независимых сервер с автоматической синхронизацией конфигурации...
Прошу прощенья, у меня датацентр в Европе, для Росси соглашусь, что отсутствие связи вполне может быть обычным явлением встречающимся довольно часто. Для такой суровой реальности врят ли возможно сделать отказоустойчивый сервис, для отказоустойчивости сервиса как минимум нужно выполнить обязательное условие со стороны аппаратной части в том числе обеспечить нормальную работу сети на физическом уровне. Любая схема будет изначально провальной в случае отказа со стороны сети.
Так у вас база на кластере и два сервера с забиксом?
Забикс сервер это не кластер?
Просто не совсем понятно зачем делать второй забикс без отдельной базы?
Я вообще могу прикинуть примерно так: (у нас выход на смс и почту через один сервер, забикс закрыт от интернета), на этом шлюзе можно фильтровать одинаковые смски, и держать два отдельных сервер со своими же базами данных, а всех агентов отнастраивать на два сервера.
Видимо, придется синхронизировать таблицы настроек БД отдельной командой
О базе на кластере речи не было, была речь о репликации master-slave, изначально тут было предложенно использовать Linux-HA кластер работающий на drbd, никто не мешает использовать Heartbeat по его прямому назначению без дополнительных преседаний с drbd, соответственно вы получите два отдельных сервера zabbix с одинаковыми настройками (hostname, ipaddr, etc.) и две базы, остальное за Вас сделает Heartbeat.
В качестве альтернативы Heartbeat можно посмотреть в сторону Keepalived Linux, реализация конечно разная и возможности то же.