Отказоустойчивость ядра с RAFT
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Поддерживается KUMA с версии 4.0
Официальная документация по данному разделу приведена в Онлайн-справке на продукт:
В данной статье можно ознакомиться с решением KUMA, основанное на кластерах RAFT, что позволяет обеспечить доступность компонентов ядра даже в случае сбоя работы нод.
Допустимо развертывать только нечетное количество сервисов Ядра KUMA.
Теория
Состояния серверов. В кластере Raft каждый из серверов в каждый момент времени находится в одном из трёх состояний:
- Leader (лидер) – обрабатывает все клиентские запросы, является source of truth всех данных в логе, поддерживает лог фоловеров.
- Follower (фоловер) – пассивный сервер, который только «слушает» новые записи в лог от лидера и редиректит все входящие запросы от клиентов на лидера. По сути, является hot-standby репликой лидера.
- Candidate (кандидат) – специальное состояние сервера, возможное только во время выбора нового лидера.
Во время нормальной работы в кластере только один сервер является лидером, все остальные – его фоловеры.
полезные ссылки: https://thesecretlivesofdata.com/raft/
Если ведущий узел выходит из строя, сервер будет следовать за новым ведущим, обеспечивая непрерывный доступ к интерфейсу SIEM или API.
Установка KUMA в кластере Raft с нуля
Распределенная установка с Ядром KUMA в кластере Raft
На всех компонентах ядра должно быть единое время, настройте на всех машинах NTP
Журналы Ядра KUMA хранятся в директории /opt/kaspersky/kuma/core/<идентификатор сервиса Ядра KUMA>/log/core.
Сценарии установки с установкой Ядра в кластере Raft смотреть можно тут