4 марта 2024

Статья 2. Аппаратная конфигурация / требования к системе

Цикл статей PT NAD Getting Started
Приветствуем вас во второй статье курса «PT NAD Getting Started». В ней мы рассмотрим основные принципы работы решения PT NAD, его внутреннюю составляющую и технические требования.


Перед установкой PT NAD необходимо определить:
  • количество ресурсов, которое потребуется выделить системе для ее стабильной работы;
  • количество точек снятия копии трафика;
  • продолжительность хранения метаданных и pcap-файлов
И уже на основе этой информации выбрать аппаратную конфигурацию.

Elasticsearch

Elasticsearch — самый ресурсоемкий модуль в системе PT NAD.
Для быстрого полнотекстового поиска по метаданным elasticsearch использует обратный индекс. Он разбивается на отдельные осколки (шарды), что позволяет распределить нагрузку и увеличить эффективность системы.

Elasticsearch использует узлы (ноды) трех типов:
  • Master node: следит за другими узлами в кластере, распределяет шарды по нодам;
  • Client node: принимает и передает запросы пользователя к узлам данных;
  • Data node: хранят шарды и производят операции над данными (запись, поиск, изменение, удаление)

При распределении ресурсов по нодам elasticsearch необходимо руководствоваться следующими правилами:
  • На весь кластер elasticsearch выделено не более половины от ОЗУ сервера;
  • По 2 потока и 2Гб ОЗУ достаточно для стабильной работы master и client нод;
  • Для каждого из узлов данных выделяется не менее 6 потоков ЦПУ, а также строго не более 30 Гб ОЗУ (и желательно не менее). Такой же объем памяти резервируется под кэш;
  • Количество шардов должно быть кратно числу узлов данных;
  • На каждый шард должно приходиться не более 50 Гб метаданных, собранных за сутки

Рассмотрим пример: пусть у нас в распоряжении находится сервер с 56-ядерным процессором и 256 ГБ ОЗУ, которому отведена роль Core. При этом за сутки генерируется 720 Гб метаданных.
Сперва определим максимальное количество узлов данных, которое можно разместить на данном сервере, взяв целую часть от результата деления объема ОЗУ на 60 (30 Гб для процессов самого узла и 30 Гб под кэширование):
На master и client ноды выделяем по 2 потока ЦПУ и 2 потока ОЗУ.

Суммарно на кластер elasticsearch было выделено 4*30 + 2 + 2 = 124 Гб ОЗУ (меньше половины всей доступной оперативной памяти). Для работы ОС оставим 4 Гб ОЗУ и 4 потока ЦПУ.

Оставшиеся 48 потоков ЦПУ разделим на 4 узла данных: на каждый узел приходится по 12 потоков, что соответствует требованию выделения не менее 6 потоков.

Перейдем к расчету количества осколков индекса.
Определим минимальное количество шардов, на которые необходимо разделить индекс, учитывая ограничение в 50 Гб суточного трафика метаданных:
Так как у нас есть 4 узла данных, а 15 не делится на 4, то добавим еще один шард. Итого: необходимо разделить индекс на 16 фрагментов.

Elasticsearch — самый ресурсоемкий модуль в системе PT NAD.
Для быстрого полнотекстового поиска по метаданным elasticsearch использует обратный индекс. Он разбивается на отдельные осколки (шарды), что позволяет распределить нагрузку и увеличить эффективность системы.

Elasticsearch использует узлы (ноды) трех типов:
  • Master node: следит за другими узлами в кластере, распределяет шарды по нодам;
  • Client node: принимает и передает запросы пользователя к узлам данных;
  • Data node: хранят шарды и производят операции над данными (запись, поиск, изменение, удаление)

При распределении ресурсов по нодам elasticsearch необходимо руководствоваться следующими правилами:
  • На весь кластер elasticsearch выделено не более половины от ОЗУ сервера;
  • По 2 потока и 2Гб ОЗУ достаточно для стабильной работы master и client нод;
  • Для каждого из узлов данных выделяется не менее 6 потоков ЦПУ, а также строго не более 30 Гб ОЗУ (и желательно не менее). Такой же объем памяти резервируется под кэш;
  • Количество шардов должно быть кратно числу узлов данных;
  • На каждый шард должно приходиться не более 50 Гб метаданных, собранных за сутки

Рассмотрим пример: пусть у нас в распоряжении находится сервер с 56-ядерным процессором и 256 ГБ ОЗУ, которому отведена роль Core. При этом за сутки генерируется 720 Гб метаданных.
Сперва определим максимальное количество узлов данных, которое можно разместить на данном сервере, взяв целую часть от результата деления объема ОЗУ на 60 (30 Гб для процессов самого узла и 30 Гб под кэширование):
25660 = 4

* х – возвращает целую часть числа х

На master и client ноды выделяем по 2 потока ЦПУ и 2 потока ОЗУ.

Суммарно на кластер elasticsearch было выделено 4*30 + 2 + 2 = 124 Гб ОЗУ (меньше половины всей доступной оперативной памяти). Для работы ОС оставим 4 Гб ОЗУ и 4 потока ЦПУ.

Оставшиеся 48 потоков ЦПУ разделим на 4 узла данных: на каждый узел приходится по 12 потоков, что соответствует требованию выделения не менее 6 потоков.

Перейдем к расчету количества осколков индекса.
Определим минимальное количество шардов, на которые необходимо разделить индекс, учитывая ограничение в 50 Гб суточного трафика метаданных:
⌈72050⌉ = 15

* ⌈х⌉ – возвращает наименьшее целое число, большее или равное х

Так как у нас есть 4 узла данных, а 15 не делится на 4, то добавим еще один шард. Итого: необходимо разделить индекс на 16 фрагментов.

Объем хранилищ

Также необходимо определить объем хранилищ для сырого трафика и метаданных. Он зависит от объема захватываемого трафика и продолжительности хранения данных.
Рассчитать данные значения можно по следующим формулам:
  • Для хранения сырого трафика
  • S = V*t*0,00432
  • Для хранения метаданных
  • S = V*t*0,000486

Где S – требуемый объем хранилища в Тб,
V – скорость захватываемого трафика в Мбит/с,
t – продолжительность хранения данных в днях,
числа 0,00432 и 0,000486 – полученные опытным путем коэффициенты.

Таким образом, для хранения 5 дней сырого трафика и 14 дней метаданных при скорости трафика 600 Мбит/с понадобится:
  • Сырой трафик: 600*5*0,00432 = 12,96 ≈13 Тб
  • Метаданные: 600*14*0,000486 = 4,082 ≈ 4 Тб

Для хранения метаданных рекомендуется использовать твердотельные накопители, обладающие повышенными скоростью записи и чтения (это минимизирует задержки при работе в веб-интерфейсе продукта).
Сырой трафик занимает на порядок больше места, чем метаданные, а запросы на его импорт/экспорт достаточно редки. Поэтому высокая скорость чтения/записи не является критическим параметром, благодаря чему допускается использовать жесткие диски.

Зеркалирование трафика

PT NAD работает с копией сетевого трафика, поэтому отдельно стоит задуматься о том, каким образом трафик будет зеркалироваться и передаваться в сенсоры.

В PT NAD используются два основных механизма зеркалирования трафика: SPAN и TAP-устройства.

SPAN (Switch Port Analyzer) позволяет коммутатору дублировать пакеты с одного или нескольких портов на назначенный SPAN-порт. Трафик с этого порта подается сенсору.

Очевидным преимуществом данного решения является доступность: достаточно просто произвести перенастройку коммутаторов, никаких дополнительных расходов не требуется. Однако есть существенный недостаток — копирование трафика происходит на логическом уровне, поэтому использование SPAN оказывает значительную нагрузку на процессор коммутатора (что может вызвать его перегрузку и, как следствие, потерю пакетов). Протоколы удаленного SPAN (RSPAN, ERSPAN) также дополнительно нагружают каналы связи, уменьшая их полезную пропускную способность, что тоже может привести к потере пакетов.
Поэтому предпочитаемым механизмом зеркалирования трафика является TAP (Test Access Point).

Данные устройства ставятся «в разрыв» кабеля и производят копирование проходящих в нем пакетов на физическом уровне. Такой подход никак не сказывается ни на производительности сетевых устройств, ни на скорости трафика. Наверное, единственным значимым доводом против данного решения является высокая стоимость TAP-устройств (особенно на фоне условно бесплатного SPAN).

Сетевые карты и механизмы захвата

В версии PT NAD 11.1 (актуальной на момент написания статьи) поддерживается только два механизма захвата трафика:
  • DPDK: для скорости захвата трафика до 10 Гбит/с;
  • AF-PACKET: используется при невозможности настроить DPDK для скорости захвата трафика на интерфейсе менее 1Гбит/с
Используемый ранее и поддерживаемый вплоть до версии 11.0 для совместимости с установленными ранее системами механизм захвата трафика PF-RING теперь недоступен для настройки в PT NAD.

Механизм захвата DPDK является предпочтительным, однако не все сетевые карты поддерживают его стабильную работу на высоких скоростях (более 1Гбит/с). Во избежание потерь пакетов рекомендуется использовать сетевые карты от производителей Intel, NVIDIA Mellanox или Broadcom.

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

А также по два интерфейса (при использовании TAP) на каждую линию связи, с которой происходит копирование трафика: один интерфейс для исходящего трафика, второй — для входящего.
Скорость интерфейсов выбирается исходя из скорости передачи линии связи и ее нагрузки. Однако количество необходимых портов можно сократить с помощью использования брокера сетевых пакетов: он может агрегировать несколько потоков копии сетевого трафика в одну линии связи. Главное — учесть скорость передачи информации и выбрать подходящие для этого интерфейс и кабель.

PTDPI

На каждый 1 Гбит/с подаваемого в систему трафика необходимо выделять не менее 8Гб ОЗУ. Стоит учитывать, что необходимый объем оперативной памяти может увеличиваться, если в трафике передаются пакеты с увеличенным MTU или устанавливаются длительные сессии.

При скорости трафика 1 Гбит/с и использовании механизма захвата трафика AF-PACKET рекомендуется предусмотреть 8−16 потоков ЦПУ для работы модуля ptdpi. При этом распределение потоков на выполнение задач происходит автоматически.

Для DPDK нам необходимо самостоятельно определить, сколько ядер процессора будет выделено для каждой из трех задач модуля ptdpi:
  1. Захват трафика
  2. Обработка трафика
  3. Обработка соединений
Расчет происходит по следующим правилам:
  • Одно физическое ядро процессора обеспечивает захват трафика скоростью до 5 Гбит/с;
  • Одно логическое ядро процессора обрабатывает трафик скоростью до 300 Мбит/с;
  • Одно логическое ядро процессора обрабатывает до 5 млн активных соединений;
  • Два логических ядра процессора выделяются для записи pcap-файлов в хранилища
Все эти правила можно объединить в одну формулу:
Где K – общее количество потоков, которое необходимо выделить для ptdpi;
i – количество логических ядер в одном физическом ядре;
v – скорость подаваемого в систему трафика (Мбит/с);
c – количество актуальных соединений, млн.

Заключение

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

В следующих статьях мы рассмотрим процесс установки продукта в односерверной и многосерверной конфигурациях.

До встречи в третьей статье!