Отказоустойчивость ядра с RAFT

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт:

Поддерживается в KUMA с версии 4.0

Кластер RAFT позволяет обеспечить доступность компонентов ядра KUMA в случае сбоя работы одного из компонентов.

Допустимо развертывать только нечетное количество сервисов Ядра KUMA.

Теория

В кластере Raft каждый из серверов в каждый момент времени находится в одном из трёх состояний:

Leader (лидер) – обрабатывает все клиентские запросы, является source of truth всех данных в логе, поддерживает лог фоловеров.
Follower (фоловер) – пассивный сервер, который только «слушает» новые записи в лог от лидера и редиректит все входящие запросы от клиентов на лидера. По сути, является hot-standby репликой лидера.
Candidate (кандидат) – специальное состояние сервера, возможное только во время выбора нового лидера.

Во время нормальной работы в кластере только один сервер является лидером, все остальные – его фоловеры.

Полезная ссылка: https://thesecretlivesofdata.com/raft/

Расширение кластера Raft

Сценарии установки с установкой Ядра в кластере Raft смотреть можно тут

Можно реализовать данный сценарий, если KUMA уже в инсталяции All-in-one. Для этого необходимо подготовить дополнительные целевые машины для установки сервисов, а также на контрольной машинке настроить обмен ключами

После необходимо скопировать файл на контрольной машинке expand.inventory.yml.template и создать его копию

cp expand.inventory.yml.template expand.inventory.yml

Далее необходимо отредактировать файл expand.inventory.yml

Например, только для распределения ядра:

В хостах указываем FQDN и проверяем их доступность с контрольной машинки, если нет, нужно добавить записи в /etc/hosts

На всех компонентах ядра должно быть единое время, настройте на всех машинах NTP

Далее на контрольной машине с доступом root из папки с распакованным установщиком (скриншот выше) выполните следующую команду для начала установки:

./expand.sh expand.inventory.yml

В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки дополнительных сервисов Ядра KUMA, для этого проверьте наличие директории /opt/kaspersky/kuma/kuma

Создание и установка дополнительных сервисов Ядра KUMA.

Поскольку сервисы Ядра KUMA состоят из двух частей, клиентской и серверной, сервисы создаются в два этапа:

Создание клиентской части сервиса Ядра KUMA в веб-интерфейсе на контрольной машинке.

1. В разделе Ресурсы → Активные сервисы нажмите Добавить и в раскрывающемся списке выберите Добавить сервис Ядро.
2. В открывшемся окне Добавить сервис Ядро укажите имя сервиса в поле Имя сервиса Ядро и нажмите Добавить. Добавленный сервис появится в списке Сервисы.
  1. Установите флажок рядом с добавленным сервисом Ядра KUMA и на панели инструментов нажмите , в открывшемся меню нажмите Копировать идентификатор. Идентификатор сервиса Ядра KUMA понадобится для установки сервиса на сервере.

2. Создание серверной части сервиса Ядра KUMA.

На целевой машине выполните следующую команду.

sudo /opt/kaspersky/kuma/kuma core --raft.join <FQDN хоста из секции kuma_core, где запущен первый сервис Ядра KUMA>:7210 --id <идентификатор сервиса Ядра KUMA, скопированный в веб-интерфейсе> --install

Повторите создание клиентской и серверной части сервиса Ядра KUMA для каждого хоста из группы kuma_core_peers.

На каждом хосте может быть установлен только один сервис Ядра KUMA.

После успешной установки в веб-интерфейсе KUMA, вы увидеть статус сервисов Вкл

Если ведущий узел выходит из строя, сервер будет следовать за новым ведущим, обеспечивая непрерывный доступ к интерфейсу SIEM или API.

Журналы Ядра KUMA хранятся в директории /opt/kaspersky/kuma/core/<идентификатор сервиса Ядра KUMA>/log/core.

Установка балансировщика

Установим балансировщик нагрузки nginx для удобства работы с кластером Raft, а именно обращение по единому hostname / IP-адресу.

Когда одна из нод кластера отказывает, балансировщик перенаправляет запросы на активные ноды

Для установки балансировщика поднимем отдельный сервер и на него установим nginx, далее необходимо отредактировать файл /etc/nginx/nginx.conf и добавить конфиг в конец файла

stream {
    upstream raft_backend {
        server kuma-test.local:7220 max_fails=1 fail_timeout=5s;
        server kuma-core-2.local:7220 backup;
        server kuma-core-3.local:7220 backup;
    }

    server {
        listen 443;
        proxy_pass raft_backend;
        ssl_preread on;
    }
}

Далее перезапустить сервис systemctl restart nginx.service

Для проверки работоспособности отключаем сервис ядра на kuma-test командой systemctl stop kuma-core-<идентификатор-ядра>.service. В браузере вводим https://<ip-балансировщика>, появится форма входа в интерфейс.

Далее нужно перейти в "Ресурсы" -> "Активные сервисы". Увидим, что сервис ядра отключен, но независимые компоненты имеют Статус: "Вкл"

Не забудьте запустить службу отключенного компонента, ядра systemctl start kuma-core-<идентификатор-ядра>.service

В данном случае в кластере всего три ноды, и больше одного выведенного из строя компонента ядра нельзя себе позволить, поскольку с менее чем 2 рабочими нодами теряется доступ к системе и перестает работать кластер

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

В нашем случае, если останется 1 живая нода - не сработает. Нода не образует кворум, а если захочет стать лидером, это никто не подтвердит

Возможные ошибки кластера ядра

Если вы столкнулись с ошибками после установки балансировщика, примеры:

request dropped as the cluster is not ready

failed to lookup: can't serve requests, not enough healthy nodes

Убедитесь, что у вас достаточное количество рабочих нод в кластере для его работы.