Перейти к основному содержимому
Версия: 4.6.X

Кластеризация komrad-bus

KOMRAD Enterprise SIEM поддерживает организацию отказоустойчивой доставки событий с помощью кластера NATS JetStream. В данном разделе описаны шаги по созданию инфраструктуры из трёх связанных между собой узлов KOMRAD, обеспечивающих репликацию событий.

Целевая инфраструктура​

Для корректной работы кластер должен находиться в состоянии кворума --- как минимум половина узлов плюс один должна быть активна. По этой причине кластер рекомендуется строить из нечётного количества узлов. Минимальное количество --- три узла.

Для построения отказоустойчивой инфраструктуры необходимо разделить в komrad-bus два основных потока данных:

  • Поток событий --- события от коллекторов, отфильтрованные события.
  • Поток служебных сообщений --- управляющие сообщения, оповещения и прочие внутренние данные.
Важно

Если не разделить потоки, при кластеризации возникнет хаос: каждый из узлов сможет отправлять управляющие сообщения коллекторам и вмешиваться в работу других серверов.

Для разделения потоков на каждом узле необходимо запустить два экземпляра komrad-bus:

  • Событийный komrad-bus --- участвует в транспорте событий и входит в кластер JetStream.
  • Локальный (внутренний) komrad-bus --- обслуживает поток служебных сообщений и не входит в кластер, обеспечивая работу только компонентов KOMRAD на текущем узле.

Создание второго komrad-bus для кластера​

Создание systemd-юнита​

Скопируйте файл systemd-юнита установленного komrad-bus:

sudo cp /lib/systemd/system/komrad-bus.service /lib/systemd/system/komrad-bus-events.service

Отредактируйте файл /lib/systemd/system/komrad-bus-events.service, указав другой конфигурационный файл и файл переменных окружения:

EnvironmentFile=-/etc/default/komrad-bus-events
ExecStart=/usr/bin/komrad-bus -c /etc/echelon/komrad/komrad-bus-events.yaml

Создание конфигурации​

Скопируйте конфигурацию основного komrad-bus:

sudo cp /etc/echelon/komrad/komrad-bus.yaml /etc/echelon/komrad/komrad-bus-events.yaml

В файле komrad-bus-events.yaml измените путь к конфигурации NATS:

nats:
  # Путь до файла конфигурации NATS
  path: /etc/echelon/komrad/komrad-bus-events.conf

Настройте стандартный клиент NATS (замените komrad-1, komrad-2, komrad-3 на IP-адреса или доменные имена машин кластера):

bus:
  default:
    client-name: komrad-1
    servers:
      - nats://komrad-1:4490
      - nats://komrad-2:4490
      - nats://komrad-3:4490
    # ...
    replicas: 3

Установите права доступа:

sudo chmod 664 /etc/echelon/komrad/komrad-bus-events.yaml

Создание директории хранения​

sudo mkdir /var/lib/echelon/komrad/komrad-bus-events
sudo chown komrad:komrad /var/lib/echelon/komrad/komrad-bus-events

Конфигурация NATS JetStream​

Скопируйте конфигурационный файл NATS:

sudo cp /etc/echelon/komrad/komrad-bus.conf /etc/echelon/komrad/komrad-bus-events.conf

Добавьте блок кластеризации (замените адреса на актуальные):

cluster: {
  listen: komrad-1:44900
  name: events-cluster
  routes: [
    nats://komrad-2:44900
    nats://komrad-3:44900
  ]
}

В поле listen укажите адрес текущей машины, в поле routes --- адреса всех остальных элементов кластера. Имя кластера (name) должно быть одинаковым на всех узлах.

Измените порт для основного прослушивания и HTTP-порт (поскольку на машине будет два экземпляра komrad-bus):

listen: komrad-1:4490
# ...
http_port: 4491

Измените директорию хранения:

STORE_DIR = "/var/lib/echelon/komrad/komrad-bus-events/.jetstream"

Обеспечьте уникальность поля server_name на каждом узле кластера. По умолчанию значение --- komrad. Добавьте суффикс, например: komrad-a, komrad-b, komrad-c.

Установите права доступа:

sudo chmod 664 /etc/echelon/komrad/komrad-bus-events.conf

Запуск сервиса​

sudo systemctl enable komrad-bus-events
sudo systemctl start komrad-bus-events

Настройка конфигурации сервисов​

После внесения поддержки кластеризации конфигурация блока bus в конфигурационных файлах представляет собой набор именованных конфигураций клиентов NATS:

КонфигурацияОписание
defaultИспользуется, если более специфичная конфигурация не указана. Обслуживает служебные сообщения
eventsСвязана с потоком событий: JetStream-потоки EVENTS, FILTERS и LOGS. Охватывает связку коллектор-процессор и коллектор-коррелятор
correlationСвязана с потоком инцидентов: охватывает связку коррелятор-менеджер инцидентов

Конфигурацию default можно оставить без изменений. Блок events настраивается для подключения сервисов к кластеру:

events:
  servers:
    - nats://komrad-1:4490
    - nats://komrad-2:4490
    - nats://komrad-3:4490
  user: komrad
  password: pass
  user-credentials: ""
  client-name: komrad-a
  tls:
    disable: false
    ServerName: ""
    TrustedCA: /var/lib/echelon/komrad/certs/ca.pem
    Cert: /var/lib/echelon/komrad/certs/client.pem
    CertKey: /var/lib/echelon/komrad/certs/client-key.pem
    system-pool: false
    min-version: "1.3"
    client-auth: require-and-verify-client-cert
  tuning:
    connect-timeout: 10s
    max-reconnects: 1000000
    max-wait: 0s
    ping-interval: 2m
    max-pings-outstanding: 2
    publish-async-max-pending: 0
    reconnect-interval: 5s
    reconnect-wait: 1s
    retry-on-failed-connect: false
    # Количество реплик потоков JetStream
    replicas: 3
Обратите внимание

Блок events необходимо добавить во все конфигурационные файлы, где присутствует секция bus.

Ключевые параметры​

  1. servers --- перечислите адреса всех событийных komrad-bus, входящих в кластер.

  2. client-name --- для каждого узла задайте уникальное имя клиента. Если имена будут совпадать, узлы будут перехватывать данные друг у друга, что приведёт к потере событий и инцидентов.

  3. tuning.replicas --- коэффициент репликации потоков JetStream. Рекомендуется устанавливать значение, равное количеству узлов в кластере (в данном случае --- 3). Если оставить значение по умолчанию, при отказе любого узла будет утрачена часть данных.

Особенности работы кластера​

  1. Синхронизация идентификаторов фильтров. Одинаковые по смыслу фильтры на разных узлах должны иметь одинаковый ID. Идентификатор используется для дальнейшей корреляции и создания инцидентов. Без синхронизации возможно появление ложноположительных инцидентов и пропуск реальных угроз.

  2. Репликация событий. События от всех коллекторов поступают на все процессоры и корреляторы. При одинаковых фильтрах и директивах на узлах будут появляться идентичные инциденты.

  3. Отказ узла. При выводе узла из строя остальные члены кластера могут не сразу пометить его как вышедший из строя. В этот период доставка сообщений может задерживаться, однако в конечном итоге все сообщения будут доставлены.

  4. Сертификаты. У всех элементов кластера должен быть общий корневой сертификат.

Последнее обновление