Установка 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

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

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

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

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

./expand.sh expand.inventory.yml

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

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

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

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

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

Создание серверной части сервиса Ядра 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.

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

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

Не забудьте запустить службу отключенного компонента, ядра 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 для предоставления единой точки доступа. Такая конфигурация обеспечивает автоматическое переключение между узлами при отказе.  На каждом запускается скрипт для мониторинга состояния соответствующей службы ядра.  Все узлы обслуживают веб-интерфейс через собственные полные доменные имена (FQDN), но VIP обеспечивает унифицированный и стабильный доступ, обеспечивая доступность без вмешательства пользователя.

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

Мы также рекомендуем предоставлять отдельный сервера для каждого компонента.

После подготовки файла  distributed.inventory.yml, необходимо сконфигурировать VIP для всех нод

Установка Keepalived на все основные узлы:

dnf install -y keepalived

Для каждого узла требуется собственный скрипт для мониторинга локальной службы KUMA Core. Сохраните скрипт как /etc/keepalived/check_kuma.sh.

Пример для Core1 (ksiem-core1):

#!/bin/bashif systemctl is-active --quiet kuma-core-00000000-0000-0000-0000-000000000000; then  exit 0else  exit 1fi

Настройте имя службы для каждого узла (каждый имеет уникальное имя). Вы можете найти основную службу KUMA, выполнив команду на каждом узле:

systemctl list-units --type=service | grep kuma-core

Сделайте скрипт исполняемым

chmod +x /etc/keepalived/check_kuma.sh

далее настройте keepalived. Создайте или отредактируйте файл /etc/keepalived/keepalived.conf на каждом узле. Ниже представлена ​​адаптированная конфигурация.

Core -1

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

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

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
    }
}

Далее выполните команды 

systemctl enable keepalived

systemctl start keepalived

Зайдите в веб-интерфейс KUMA через VIP FKDN (ksiem.demo.lab) активируйте KUMA и убедитесь, что все ноды сервисов установлены и их статус “зеленый” 

Возможные проблемы:

 Когда устанавливается сервис хранилища или другие ноды хранилища, необходимо указать все FQDN  ядер в команде, ниже представлен пример того, как установить хранилище в Raft -е ( 2 replica и 3 keeper)

Добавляем хранилища в destination

Проблема 2. Как коллектор и коррелятор будут работать в этом режиме?

Когда вы создаете коллектор или коррелятор, все 3 ноды автоматически добавятся в скрипт, запустите этот скрипт на сервере (коллектора или коррелятора), в этом случае, если core1 упадет, то вы все равно будете иметь доступ к настройкам коррелятора или коллектора