Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и **НЕ** является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в [Онлайн-справке](https://support.kaspersky.ru/help/KUMA/4.0/ru-RU/303366.htm) на продукт.
Кластер RAFT **поддерживается в KUMA с версии 4.0** и позволяет обеспечить доступность компонентов ядра KUMA, в случае сбоя работы одного из компонентов. Допустимо развертывать только нечетное количество сервисов Ядра KUMA. **Схема ядра в RAFT (хранилище представлено с двумя репликами, т.е. с копией данных)** [](https://kb.kuma-community.ru/uploads/images/gallery/2026-03/sxema-setevogo-vzaimodeistviia-kuma-4-raft-drawio.png) #### Теория В кластере Raft каждый из серверов в каждый момент времени находится в одном из трёх состояний: - Leader (лидер) – обрабатывает все клиентские запросы, является source of truth всех данных в логе, поддерживает лог фоловеров. - Follower (фоловер) – пассивный сервер, который только «слушает» новые записи в лог от лидера и редиректит все входящие запросы от клиентов на лидера. По сути, является hot-standby репликой лидера. - Candidate (кандидат) – специальное состояние сервера, возможное только во время выбора нового лидера. Во время нормальной работы в кластере только один сервер является лидером, все остальные – его фоловеры. Например, в случае 3 компонентов ядра из строя может выйти толкьо 1 компонент, для иного количества компонентов - пока работает формула **(n+1)/2**. Полезная ссылка для понимания механизма работы: [https://thesecretlivesofdata.com/raft/](https://thesecretlivesofdata.com/raft/) Сетевые задержки не должны превышать 150 мс. #### Расширение ядра до кластера в RaftСценарии установки с установкой Ядра в кластере Raft смотреть можно [тут](https://support.kaspersky.ru/help/KUMA/4.0/ru-RU/303370.htm)
Данный сценарий реализуется, если KUMA находится в инсталяции, где одно ядро (standalone). Для этого необходимо [подготовить](https://support.kaspersky.com/help/KUMA/3.4/ru-RU/231034.htm) дополнительные целевые машины для установки сервисов, а также на контрольной машинке настроить обмен SSH [ключами](https://support.kaspersky.ru/help/KUMA/4.0/ru-RU/222083.htm). После создать копию файла на контрольной машине (с которой предполагается развертывание) **expand.inventory.yml.template** из распакованного архива KUMA ```bash cp expand.inventory.yml.template expand.inventory.yml ``` Далее отредактировать файл **expand.inventory.yml** (разворачиваем дополнительные ядра 2 и 3):  В хостах указываем FQDN и проверяем их доступность с контрольной машины, а также на всех компонентах ядра должно быть единое время, настройте на всех машинах NTP. Далее на контрольной машине с доступом root из папки с распакованным установщиком (скриншот выше) выполните следующую команду для начала установки: ```bash ./expand.sh expand.inventory.yml ``` В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки дополнительных сервисов Ядра KUMA, для этого проверьте **наличие директории /opt/kaspersky/kuma/kuma** В разделе **Ресурсы → Активные сервисы** нажмите **Добавить** и в раскрывающемся списке выберите **Добавить сервис Ядро.** #####  В открывшемся окне Добавить сервис Ядро укажите имя сервиса в поле Имя сервиса Ядро и нажмите Добавить. Добавленный сервис появится в списке Сервисы. #####  Установите флажок рядом с добавленным сервисом Ядра KUMA и на панели инструментов нажмите , в открывшемся меню нажмите Копировать идентификатор. Идентификатор сервиса Ядра KUMA понадобится для установки сервиса на сервере. Далее на целевой машине необходимо установить службу специальным образом: ```bash sudo /opt/kaspersky/kuma/kuma core --raft.joinНа каждом хосте может быть установлен только один сервис Ядра KUMA.
После успешной установки в веб-интерфейсе KUMA, вы увидеть статус сервисов **Вкл** ##### [](https://kb.kuma-community.ru/uploads/images/gallery/2025-08/1gsimage.png) Если ведущий узел выходит из строя, сервер будет следовать за новым ведущим, обеспечивая непрерывный доступ к интерфейсу SIEM или API.Журналы Ядра KUMA хранятся в директории /opt/kaspersky/kuma/core/<`идентификатор сервиса Ядра KUMA`>/log/core.
#### Установка балансировщика - nginx Установим балансировщик нагрузки nginx для удобства работы с кластером Raft, а именно обращение по единому hostname / IP-адресу.Когда одна из нод кластера отказывает, балансировщик перенаправляет запросы на активные ноды
Для установки балансировщика поднимем отдельный сервер и на него установим **nginx,** далее необходимо отредактировать файл `/etc/nginx/nginx.conf` и добавить конфиг в конец файла ```json 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://В основу алгоритма Raft заложено понятие кворум - минимальное количество нод, необходимое для принятия решений, или большинство. При большинстве рабочих нод в кластере можно проводить голосование, выбирать лидера и принимать изменения
В нашем случае, если останется 1 живая нода - не сработает. Нода не образует кворум, а если захочет стать лидером, это никто не подтвердит. ##### Возможные ошибки кластера ядра: Если вы столкнулись с ошибками после установки балансировщика, примеры: ``` request dropped as the cluster is not ready failed to lookup: can't serve requests, not enough healthy nodes ``` Убедитесь, что у вас достаточное количество рабочих нод в кластере для его работы. #### Альтернатива балансировщику - установка keepalived В основу данного способа заложена интеграция виртуального IP-адреса (VIP) с использованием функции keepalived для предоставления единой точки доступа. Такая конфигурация обеспечивает автоматическое переключение между узлами при отказе. На каждом запускается скрипт для мониторинга состояния соответствующей службы ядра. Все узлы обслуживают веб-интерфейс через собственные полные доменные имена (FQDN), но VIP обеспечивает унифицированный и стабильный доступ, обеспечивая доступность без вмешательства пользователя. [](https://kb.kuma-community.ru/uploads/images/gallery/2025-09/iUWimage.png) Детализация демонстрационных машин [](https://kb.kuma-community.ru/uploads/images/gallery/2025-09/mdb2a55985b-9f21-43df-a1cf-00c60b34e330.png) Мы также рекомендуем предоставлять отдельный сервера для каждого компонента. После подготовки файла distributed.inventory.yml, необходимо сконфигурировать VIP для всех нод Установка Keepalived на все основные узлы: `dnf install -y keepalived` Для каждого узла требуется собственный скрипт для мониторинга локальной службы KUMA Core. Сохраните скрипт как `/etc/keepalived/check_kuma.sh.` Пример для Core1 (ksiem-core1): ```bash #!/bin/bash if systemctl is-active --quiet kuma-core-00000000-0000-0000-0000-000000000000; then exit 0 else exit 1 fi ``` Настройте имя службы для каждого узла (каждый имеет уникальное имя). Вы можете найти основную службу KUMA, выполнив команду на каждом узле: `systemctl list-units --type=service | grep kuma-core` Сделайте скрипт исполняемым: `chmod +x /etc/keepalived/check_kuma.sh` Далее настройте keepalived. Создайте или отредактируйте файл /etc/keepalived/keepalived.conf на каждом узле. Ниже представлена адаптированная конфигурация. **Core -1** ```json vrrp_script chk_kuma { script "/etc/keepalived/check_kuma.sh" interval 2 timeout 3 fall 2 rise 3 } vrrp_instance VI_1 { state MASTER interface ens34 #необходимо поменять в соотетсвии со своей конфигурацией virtual_router_id 51 priority 110 advert_int 1 authentication { auth_type PASS auth_pass secretpass } virtual_ipaddress { 192.168.100.200 } track_script { chk_kuma } } ``` **Core -2 ** ```json vrrp_script chk_kuma { script "/etc/keepalived/check_kuma.sh" interval 2 timeout 3 fall 2 rise 3 } vrrp_instance VI_1 { state BACKUP interface ens34 #поменяйте в соответcвии со своими параметрами virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass secretpass } virtual_ipaddress { 192.168.100.200 } track_script { chk_kuma } } ``` **Core - 3** ```json vrrp_script chk_kuma { script "/etc/keepalived/check_kuma.sh" interval 2 timeout 3 fall 2 rise 3 } vrrp_instance VI_1 { state BACKUP interface ens34 #поменяйте в соответcвии со своими сетевыми параметрами virtual_router_id 51 priority 90 advert_int 1 authentication { auth_type PASS auth_pass secretpass } virtual_ipaddress { 192.168.100.200 } track_script { chk_kuma } } ``` Далее выполните команды ```bash systemctl enable keepalived systemctl start keepalived ``` Зайдите в веб-интерфейс KUMA через VIP FKDN (ksiem.demo.lab) активируйте KUMA и убедитесь, что все ноды сервисов установлены и их статус "зеленый" [](https://kb.kuma-community.ru/uploads/images/gallery/2025-09/Trtimage.png) #### Возможные проблемы ##### Проблема 1 Когда устанавливается сервис хранилища или другие ноды хранилища, необходимо указать все FQDN ядер в команде, ниже представлен пример того, как установить хранилище в Raft -е ( 2 replica и 3 keeper) [](https://kb.kuma-community.ru/uploads/images/gallery/2025-09/QeHimage.png) ##### Проблема 2. Как коллектор и коррелятор будут работать в этом режиме? Когда вы создаете коллектор или коррелятор, все 3 ноды автоматически добавятся в скрипт, запустите этот скрипт на сервере (коллектора или коррелятора), в этом случае, если core1 упадет, то вы все равно будете иметь доступ к настройкам коррелятора или коллектора [](https://kb.kuma-community.ru/uploads/images/gallery/2025-09/J3uimage.png) [](https://kb.kuma-community.ru/uploads/images/gallery/2025-09/7Yfimage.png)