Skip to main content

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

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

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

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

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

Допустимо развертывать только нечетное количество сервисов Ядра 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 и проверяем их доступность с контрольной машинки, если нет, нужно добавить записи в /etc/hosts

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

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

./expand.sh expand.inventory.yml

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

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

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

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

      image.png

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

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

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

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


Back to top