Аппаратные и программные требования

При расчете конфигурации кластера хранения нужно учитывать количество EPS, средний размер события и глубину хранения, а также требования к дисковой подсистеме, сетевому интерфейсу, оперативной памяти и профилю использования.

Дисковая подсистема

Основная нагрузка на ClickHouse в KUMA – это операции записи (вставки):

• События поступают в СУБД практически постоянным потоком.
• Вставки, по меркам ClickHouse, частые и мелкие.
• ClickHouse отличается высоким показателем амплификации записи (write amplification) за счет постоянных фоновых слияний частей партиций (parts).
• Часть партиции размером до 1 ГБ хранится в виде одного файла. При превышении размера в 1 ГБ для части применяется ширококолоночный формат (wide column format), где каждый столбец таблицы представлен в виде двух файлов .dat и .mrk. В этом случае для перезаписи части партиции в результате ее слияния с другой частью, требуется запись в 384 файла + fsync на каждый, что подразумевает большое количество IOPS.

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

• Использовать DAS (Direct Attached Storage) c NVME или SAS/SATA-интерфейсами, избегая решений класса SAN/NAS.
• Если узлы кластера ClickHouse развернуты в виртуальной среде, директория /opt/kaspersky/kuma должна быть напрямую смонтирована на дисковый массив. Не следует использовать виртуальные диски.
• Использовать SSD (SATA/NVME). Любые SSD серверного класса обеспечат большую производительность, чем HDD (даже 15 000 RPM). Для SSD следует использовать RAID-10 или RAID-0 (если используется репликация в ClickHouse).

  Если использовать SSD невозможно, следует применять HDD 15 000 RPM, SAS, объединенные в RAID-10.

  Допускается гибридный вариант, когда горячие данные (например, за последний месяц) хранятся на SSD, а холодные данные – на HDD. Таким образом, операции записи всегда будут адресованы SSD-массивам.

  При использовании гибридного варианта SSD и HDD нужно учитывать, что программный RAID-массив (madm) всегда будет демонстрировать более высокую производительность и гибкость, чем аппаратный RAID-контроллер. При использовании RAID-0 или RAID-10 важно, чтобы размер полосы (stripe size) был равен 1 МБ. Часто в аппаратных RAID-контроллерах размер полосы по умолчанию составляет 64 КБ, а максимально доступное значение – 256–512 КБ. Для RAID-10 наиболее оптимальным для записи является near-layout, а для чтения – far-layout.

• Рекомендуемая файловая система – EXT4. Если использовать EXT4 невозможно, допустимо использовать файловую систему XFS. Для любой из этих файловых систем рекомендуется включить опцию монтирования noatime.

Сетевой интерфейс

Рекомендации для сетевого интерфейса:

1. На каждом узле кластера должен быть установлен и скоммутирован сетевой интерфейс с пропускной способностью не менее 10 Гбит/с. С учетом амплификации записи и репликации наиболее подходящим решением будет 25 Гбит/с.
2. При необходимости процессы репликации могут использовать обособленный сетевой интерфейс, который не обрабатывает трафик, связанный со вставками и поисковыми запросами.

Оперативная память

ClickHouse рекомендует использовать соотношение объема оперативной памяти к объему данных, хранящихся на узле, равное 1:100.

Однако при расчете требований к оперативной памяти следует учитывать не только общий объем хранимых данных, но и объем данных, который в среднем обрабатывается при выполнении запросов. Например, если средний запрос предполагает сканирование партиций суммарным объемом 10 ТБ, рекомендуется предусмотреть не менее 100 ГБ оперативной памяти. Приведенное соотношение является общей рекомендацией и рассчитано на выполнение широких аналитических запросов. Фактические требования к оперативной памяти зависят от характера запросов, объема обрабатываемых данных и конфигурации системы.

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

Профиль использования

Требования к оборудованию рассчитаны на поглощение СУБД потока в n EPS при нахождении СУБД в покое (поисковые запросы не выполняются, только операции записи). На этапе внедрения KUMA не всегда удается точно определить, какие поисковые и аналитические запросы будут выполняться в системе, интенсивность, конкурентность и глубину поисковых запросов, а также фактическую производительность узлов кластера.

Таким образом, масштабирование кластера ClickHouse в процессе эксплуатации KUMA является стандартным сценарием. Если в результате увеличения потока EPS или увеличения интенсивности либо ресурсоемкости поисковых запросов кластер перестает справляться с нагрузкой, следует либо добавить шарды (горизонтальное масштабирование), либо усовершенствовать дисковые подсистемы, СPU или оперативную память на узлах кластера.

Масштабирование решения в зависимости от количества сервисов

Требования к оборудованию сервера для сервиса Метрики в зависимости от количества сервисов в экземпляре KUMA приведены в таблице ниже. Расчет проводился для потока событий 20 000 EPS. Значения количества процессоров и объема ОЗУ в таблице округлены в большую сторону до целого значения.

Результаты в таблице были получены при следующих параметрах:

• Параметры обнаружения источников: по умолчанию.
• Параметры политик мониторинга:
  • Тип: byCount.
  • Нижний порог: 10.
  • Верхний порог: 1000.
  • Период подсчета: 10 минут.
  • Интервал оценки: 5 минут.

  Масштабирование решения в зависимости от числа сервисов

  Число сервисов	Число процессоров (рекомендуется)	ОЗУ (ГБ) (рекомендуется)
  50	1	3
  100	1	3
  500	1	4

Из таблицы следует, что рост числа сервисов в экземпляре KUMA повышает требования к оборудованию незначительно.

Масштабирование решения в зависимости от состояния источников событий

На требования к оборудованию (процессорам, оперативной памяти и дисковому пространству) влияют следующие параметры, отображаемые или заданные в разделах Метрики и Состояние источников:

• Параметры определения источников.

  На требования к оборудованию влияют параметры, заданные для определения источников: количество полей и их свойства. Если вы увеличите количество полей или укажете поля, которые содержат большое количество уникальных значений, это может привести к тому, что KUMA определит большое количество источников событий. Как следствие, увеличение количества источников событий увеличивает требования к оборудованию.

  Например, набор полей DeviceProduct, DeviceHostName, DeviceAddress определит в качестве источника межсетевой экран Firewall, fw-1.example.com, 192.0.2.1. Если же вы зададите набор полей DeviceProduct, DeviceHostName, DeviceAddress, Name, KUMA определит гораздо большее количество источников событий:

  • Firewall, fw-1.example.com, 192.0.2.1, DNS
  • Firewall, fw-1.example.com, 192.0.2.1, IPS
  • Firewall, fw-1.example.com, 192.0.2.1, TRAFFIC
  • Firewall, fw-1.example.com, 192.0.2.1, TREAT

  Следует учесть, что заметное влияние на требования к оборудованию начинается при количестве источников событий, превышающем 100 000.

• Количество источников событий, которым назначены политики мониторинга, а также период подсчета данных и интервал оценки.

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

• Количество политик мониторинга, назначенных каждому из источников событий.
• Средний размер точки данных (значение метрики Bytes per point).

  С помощью значения метрики Bytes per point (bpp) сервиса Метрики вы можете вычислить объем дискового пространства, необходимого для хранения метрик. Для этого вы можете использовать формулу:

  hdd_sizing = ROUNDUP (bpp * (retention_sec/interval_sec) * EPS * 1,1)

  где:

  • hdd_sizing – требуемый объем дискового пространства;
  • ROUNDUP – функция округления в большую сторону;
  • bpp – значение метрики Bytes per point;
  • retention_sec – срок хранения метрик в секундах;
  • interval_sec – интервал получения информации, равен 15 секундам;
  • EPS – среднее значение EPS по источникам, примерно равно значению метрики Processing EPS на коллекторе;
  • 1,1 – корректирующий коэффициент, добавляющий 10% к расчетному значению дискового пространства.
• Поток событий, обрабатываемых всеми коллекторами KUMA.

  Требования к оборудованию при масштабировании решения по числу источников событий и политик мониторинга в экземпляре KUMA приведены в таблице ниже.

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

  Результаты в таблице были получены при следующих параметрах:

  • Параметры обнаружения источников: по умолчанию.
  • Параметры политик мониторинга:
    • Тип: byCount.
    • Нижний порог: 10.
    • Верхний порог: 1000.
    • Период подсчета: 10 минут.
    • Интервал оценки: 5 минут.

  Масштабирование решения в зависимости от числа источников событий и политик мониторинга

  Число источников событий	Число источников событий, отслеживаемых политиками мониторинга	EPS	Число политик мониторинга на одном источнике	Число процессоров (рекомендуется)	ОЗУ (ГБ) (рекомендуется)	Дисковое пространство (ГБ) в расчете на срок хранения метрик 30 дней
  10 000	0	25 000	0	1	2	13
  25 000	0	25 000	0	1	2	13
  50 000	0	25 000	0	1	3	13
  100 000	0	25 000	0	1	3	14
  250 000	0	25 000	0	1	3	13
  500 000	0	25 000	0	1	5	13
  1 000 000	0	25 000	0	1	7	11
  10 000	2000	5000	1	1	3	4
  10 000	5000	5000	1	1	3	5
  10 000	2000	10 000	1	1	3	8
  10 000	2000	10 000	2	1	3	10
  10 000	5000	10 000	1	1	3	9
  10 000	5000	25 000	1	1	3	24
  10 000	10 000	5000	1	1	4	5
  10 000	10 000	5000	2	1	5	5
  50 000	10 000	5000	1	1	4	4
  50 000	10 000	10 000	1	1	5	7
  50 000	25 000	25 000	1	1	6	20
  100 000	20 000	5000	1	1	6	4
  100 000	20 000	10 000	1	1	6	8
  100 000	100 000	5000	1	4	19	5
  250 000	50 000	10 000	1	3	12	7
  100 000	100 000	5000	2	6	29	5
  250 000	250 000	5000	1	10	40	4
  250 000	250 000	5000	2	17	68	5