Skip to main content

Установка KUMA с отказоустойчивым ядром - RAFT.

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

Кластер RAFT поддерживается в KUMA с версии 4.0 и позволяет обеспечить доступность компонентов ядра 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

image.png

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

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

конфигурациоонный файл.png

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

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

./expand.sh expand.inventory.yml

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

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

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

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

В разделе Ресурсы → Активные сервисы нажмите Добавить и в раскрывающемся списке выберите Добавить сервис Ядро.

image.png

В открывшемся окне Добавить сервис Ядро укажите имя сервиса в поле Имя сервиса Ядро и нажмите Добавить. Добавленный сервис появится в списке Сервисы.

image.png

 Установите флажок рядом с добавленным сервисом Ядра KUMA и на панели инструментов нажмите more_vertical, в открывшемся меню нажмите Копировать идентификатор. Идентификатор сервиса Ядра KUMA понадобится для установки сервиса на сервере.

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

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

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

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

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

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

image.png

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

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


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

Установим балансировщик нагрузки 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-балансировщика>, появится форма входа в интерфейс.

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

image.png

Не забудьте запустить службу отключенного компонента, ядра 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

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

 

Вариант 2.  Установка, использующая параметр keepalived 

В основу данного способа заложена  интеграция виртуального IP-адреса (VIP) с использованием функции keepalived для предоставления единой точки доступа. Такая конфигурация обеспечивает автоматическое переключение между узлами при отказе, при этом VIP динамически переключается на активный ведущий узел кластера.

В данной демонстрации система состоит из трёх выделенных узлов:

ksiem-core1.demo.lab – 192.168.100.201

ksiem-core2.demo.lab – 192.168.100.202

ksiem-core3.demo.lab – 192.168.100.203

Далее  мы назначили кластеру виртуальный IP-адрес (VIP):  ksiem.demo.lab – 192.168.100.200

Этот VIP управляется с помощью функции keepalived на всех узлах. На каждом запускается скрипт для мониторинга состояния соответствующей службы ядра. Когда ведущий узел активен, VIP привязан к его сетевому интерфейсу. Все узлы обслуживают веб-интерфейс через собственные полные доменные имена (FQDN), но VIP обеспечивает унифицированный и стабильный доступ, обеспечивая доступность без вмешательства пользователя.Мы также рекомендуем предоставлять отдельный сервера для каждого компонента.

image.png

Детализация демонстрационных машин 


Hostname

IP address

OS

Role



ksiem.demo.lab

192.168.100.200

N/A

VIP



ksiem-core1.demo.lab

192.168.100.201

Oracle 9.2

Core1-Leader, Storage, collector, Correlator



ksiem-core2.demo.lab

192.168.100.202

Oracle 9.2

Core2-Folower, Storage raplica2



ksiem-core3.demo.lab

192.168.100.203

Oracle 9.2

Core3- quorum, Storage keeper3
Back to top