Взаимодействие компонентов Kaspersky SIEM с кластером Raft

Kaspersky SIEM поддерживает отказоустойчивую кластерную конфигурацию на основе алгоритма консенсуса Raft. В кластер Raft входят только сервисы Ядра KUMA. Остальные компоненты платформы (коллекторы, корреляторы, хранилища, маршрутизаторы, агенты) работают вне кластера и взаимодействуют с Ядром KUMA как внешние сервисы.

Работа Ядер KUMA, объединенных в кластер Raft, обеспечивает следующее:

• согласованное хранение конфигурации сервисов;
• синхронизацию состояния между экземплярами Ядра KUMA;
• высокую доступность данных;
• автоматический выбор ведущего узла.

Для корректной работы требуется не менее трех экземпляров Ядра KUMA и нечетное количество узлов для обеспечения кворума (см. таблицу ниже).

Допустимое количество отказавших узлов в зависимости от количества узлов в кластере Raft

Взаимодействие сервисов Ядра KUMA внутри кластера

Все экземпляры Ядра KUMA взаимодействуют друг с другом напрямую.

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

Лидер отвечает за следующие задачи:

• обработка изменений конфигурации;
• репликацию изменений на остальные сервисы Ядра KUMA;
• координации состояния кластера;
• прием запросов на операции записи и трансляция на остальные узлы кластера.

Последователи выполняют следующие действия:

• получают обновления от лидера;
• подтверждают репликацию;
• участвуют в выборах нового лидера при отказе текущего;
• выполняют запросы пользователей на чтение данных из локальной базы данных SQLite.

Все сервисы Ядра KUMA должны иметь прямую сетевую доступность друг к другу.

Взаимодействие компонентов внутри кластера включает:

• обмен heartbeat-сообщениями;
• выборы лидера в случае отказа действующего узла;
• репликацию журнала Raft;
• синхронизацию конфигурации сервисов KUMA;
• передачу служебного состояния сервисов KUMA.

Взаимодействие внешних сервисов с Ядром KUMA без балансировщика

При отсутствии внешнего балансировщика сервисы решения подключаются напрямую к сервисам Ядра KUMA.

В этом случае требуется выполнение следующих условий:

• Каждый сервис должен знать адреса Ядер KUMA.
• Список URL Ядер KUMA был указан при установке или настройке внешнего сервиса.
• Адреса передаются через список, разделенный запятыми или с помощью многократного указания параметра --core <url>.

  Пример команды установки хранилища:

  sudo /opt/kaspersky/kuma/kuma <storage> --core https://core1.example.com:7210,https://core2.example.com:7210,https://core3.example.com:7210 --pair.fingerprint <CA_cert_ID> --id <service_ID> --install

  где:

  • <CA_cert_ID> — идентификатор отпечатка CA-сертификата, используемый для проверки подлинности при подключении сервиса.

    Параметр --pair.fingerprint является необязательным. При создании сервиса KUMA автоматически добавляет этот параметр в команду установки и указывает идентификатор отпечатка.
    Вы можете выполнить установку сервиса без указания параметра --pair.fingerprint. В этом случае KUMA использует значение insecure по умолчанию, что не обеспечивает проверку подлинности CA-сертификата Ядра KUMA при установлении соединения. Если используется значение insecure, обновление отпечатка после перевыпуска CA-сертификата не требуется.
    
    Для обеспечения проверки подлинности CA-сертификата Ядра KUMA рекомендуется не удалять параметр --pair.fingerprint с идентификатором отпечатка при установке сервиса. При перевыпуске CA-сертификата необходимо скопировать новый отпечаток сертификата в веб-интерфейсе и перезапустить сервис с обновленным значением параметра.

  • <service_ID> — идентификатор сервиса, скопированный из веб-интерфейса KUMA.

Таким образом, все компоненты платформы получают список всех Ядер KUMA, подключаются к одному из доступных узлов кластера Raft и при недоступности текущего Ядра KUMA переключаются на другой URL из списка.

При этом внешние сервисы не участвуют во внутреннем взаимодействии кластера Raft.

Особенности работы без балансировщика

Преимущества:

• Отсутствует дополнительный инфраструктурный компонент.
• Упрощается схема развертывания.
• Уменьшается количество промежуточных точек отказа.

Ограничения:

• Требуется хранить список всех Ядер KUMA в конфигурации каждого сервиса.
• При изменении состава кластера нужно обновлять конфигурацию внешних сервисов.
• Отсутствует единая точка входа в веб-интерфейс.
• В случае недоступности текущего экземпляра Ядра KUMA внешний сервис последовательно пытается установить соединение с другими Ядрами KUMA, указанными в конфигурации.

Взаимодействие сервисов Ядра KUMA через балансировщик

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

Балансировщик не входит в поставку KUMA и разворачивается отдельно средствами инфраструктуры заказчика.

Взаимодействие внешних сервисов с Ядрами KUMA через балансировщик

При наличии настроенного балансировщика возможно использование SSO (Single Sign-On). Поскольку все пользовательские запросы проходят через единую точку входа, балансировщик становится точкой интеграции механизмов централизованной аутентификации.

Внешние сервисы KUMA взаимодействуют с кластером Raft через балансировщик следующим образом:

• Внешние сервисы отправляют запросы на адрес балансировщика и работают только с одним URL, например https://kuma-load-balancer.example.com.
• Балансировщик распределяет запросы между сервисами Ядра KUMA.
• При отказе узла кластера Raft маршрутизация автоматически переключается на другой экземпляр Ядра KUMA.

При этом взаимодействие между сервисами Ядра KUMA внутри кластера Raft остается прямым и не проходит через балансировщик.