Ha Кластер в двух дата -центрах

[casperonius]

Добрый день!

Есть задача построить отказоустойчивый кластер в двух дата -центрах.

По маршрутизации завернуть L2 в L3 не получится, соответственно Virtual IP c поднятием/тушением сервисов не получится в разных подсетях.

Нагрузки ожидаются довольно высокие. Порядка 50 000 проверок с 5 000 хостов со старта.

Помогите разобраться в следующих вопросах:

1) Какую open source БД лучше выбрать (PostgreSQL, MySQL: MariaDB, InnoDB, etc ...). Соответственно нужно построить кластер. Карие решения кластеризации выбрать (Galera, Percona, etc ...) ? (Сам БД не знаю, но придётся разбираться. Буду признателен если укажите в готовую how-to!

2) При потери связи каждый сервер в отдельном ДЦ будет писать активные и пассивные проверки в БД. Что будет с репликацией БД при восстановлении связи? split-brain или дублирование данных при использовании инкрементов? (взято отсюда: https://www.zabbix.com/forum/showthread.php?t=26051 )

Гуглю, но однозначного ответа пока так и не нашел. Думал как нибудь HAproxy прикрутить, но по ходу он тоже не поможет.

В общем, помогите советом пожалуйста. =(

Спасибо.

[gescheit]

Самое кондовое решение - делать два инстанса заббикса сервера и виртуальный сервис через keepalived например.

[casperonius]

По маршрутизации завернуть l2 в l3 не получится, соответственно virtual ip c поднятием/тушением сервисов не получится в разных подсетях.

Не получится. =(

[gescheit]

А общий l2 и не нужен. Типичная схема работы балансировщиков такова: в каждом ДЦ стоит балансер который анонсирует один и тот же адрес в таблицу маршрутизации. А трафик от клиентов будет попадать на тот или иной балансер в зависимости от метрик и машрутов и живости балансеров и сервисов.

[casperonius]

Не совсем понимаю ... Вопрос как раз в том, что при потере связи между ДЦ, каждый из них думает что он единственный выживший, вот тут и грабли. То есть не проблема, если они пишут в свои локальные БД. Проблема возникает при репликации БД между ДЦ при восстановлении связи между ДЦ. Либо разрыв мозга либо задвоение данных при дополнительном инкременте в идентификаторах.

[gescheit]

В том варианте который я предлагаю, каждая инсталляция заббикса считает себя главноей. Она, собственно, ничего не знает про другой заббикс сервер. У каждого заббикса своя БД. Заббикс-агенты подключены одновременно к двум серверам. Набор данных у обоих заббикс серверов одинаковый.
При потере связи между ДЦ каждый забикс сервер будет видеть что один из ДЦ пропал. Люди же которые смотрят в заббикс увидят заббикс сервер из доступного ДЦ.
А так как БД у каждого своя, то нет никаких проблем с репликацией так как ее нет.

[casperonius]

Ок, не вопрос. Такая схема конечно же работает. Но теперь предположим что связь с серверами забикса поочерёдно пропадает. Соответственно сгенерировать отчёт с рваными графиками и понести руководству чревато вопросами "Шо за ... ?" А собрать данные с обоих серверов и склеить воедино не реально.

+ дублирование оповещений

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

[gescheit]

Ок, не вопрос. Такая схема конечно же работает. Но теперь предположим что связь с серверами забикса поочередно пропадает. Соответственно сгенерировать отчёт с рваными графиками и понести руководству чревато вопросами "Шо за ... ?" А собрать данные с обоих серверов и склеить воедино не реально.

А что значит пропадает связь между серверами? У каждого заббикса будет своя точка зрения на происходящее. Один видит что отвались ДЦ1, другой видит что отвалился ДЦ2. Какая точка зрения руководства больше нравиться, ту и нести.

+ дублирование оповещений

Есть такая проблема. Но нужно учесть что, скорей всего, система нотификации(почтовый сервер, смс-шлюз, жаббер-сервер и тп) будет доступна только из одного ДЦ и тогда проблемы со второго сервера просто не смогут быть отправлены. Это справедливо если мы говорим про проблему недоступности ДЦ, а не каких-то более мелких проблем.
Но даже если оба сервера заббикса могут слать нотификацию независимо от доступности других ДЦ, то можно просто выключить нотификацию на одном из серверов, мнение которого не интересно.

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

А вот это самая сложная проблема. К сожалению в заббиксе так и не сделали нормальный экспорт/импорт всех настроек. Поэтому простым копирование с настроек с одного сервера на другой не получится обойтись.
Как вариант можно вносить настройки в один заббикс. А в другой копировать БД по мере надобности.
А самый правильный вариант это - автоматика которая сама создает узлы, проверки и прочие на основании данных из системы документации сети. Тогда в мониторинге всегда будут актуальные данные.

[casperonius]

Ок, большое спасибо!

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

[smith]

Для схожих целей мы использовали LB MariaDB 10.0.14 + Galera Cluster. Для HA - UCARP. Нагрузка - около 10000 хостов, 700000 элементов. Решение жизнеспособно. Но, как я предполагаю, для HA нужно Л2. Плюс есть проблемы с партиционированием и желательно наличие 3х нод для кворума. Также есть пока не решенная проблема размазывания активных подключений по всем серверам для прозрачного переключения.

[casperonius]

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

А можно подробнее о сути проблемы ?

Спасибо большое!