mitigator_arch: микроархитектура процессора, для которой будет загружена
оптимизированная версия обработчика пакетов: nehalem, sandybridge
или haswell (указания по выбору).
mitigator_nic_driver: драйвер сетевой карты для DPDK
(подробнее о выборе).
mitigator_nics: сетевые порты с указанием PCI-адресов и ядер
процессора. Подразумевается, что они перечислены в порядке ext0,
int0, ext1, int1 и т.д. Портов может быть нечетное количество.
mitigator_hugepage_size: размер страницы (2M или 1G);
mitigator_hugepage_nr: количество страниц.
mitigator_nr_policies: максимальное количество политик защиты.
Можно указать версию Mitigator´а
(latest по умолчанию).
При первом запуске и при mitigator_pull_images: y будет выполнена загрузка
образов Mitigator´а, для чего нужно задать логин и пароль:
mitigator_registry_user и mitigator_registry_pass.
Можно настроить прокси для Docker´а и компонент Mitigator´а.
5. Развернуть Mitigator на целевую машину mitigator.local,
куда есть доступ по SSH:
Запятая после имени хоста — не опечатка. Если имя пользователя SSH
отличается от локального, например, login, добавляется параметр -u login.
--become и --ask-become-pass используются для повышения привилегий, когда
подключение осуществляется не напрямую через пользователя root
(необходимо для выполнения части задач в процессе инсталяции).
В конце установки машина перезагрузится.
Playbook безопасно исполнять повторно в случае проблем.
Дополнение
1. Задания в роли ансибла разделены на 4 «тега»:
checks, system, hugepages, mitigator.
Задания под тегом, соответственно, предназначены для проверки конфигурации,
настройки системы, настройки hugepages и настройки непосредственно Mitigator´а.
При необходимости перезапустить роль и перенастроить установку только частично,
можно запустить playbook с необходимым набором тегов, например:
2. Конфигурацию GRUB2 под UEFI на RHEL/CentOS
необходимо дополнительно перегенерировать вручную:
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Для CentOS redhat заменить на centos
После установки и запуска настроить систему
для её стабильной и безопасной работы.
3. Mitigator в режиме кластера
В режиме кластера несколько экземпляров системы Mitigator пользуются
едиными базами данных и управляются централизованно. За счет добавления
дополнительных экземпляров система допускает неограниченное масштабирование.
Режим кластера позволяет обрабатывать трафик независимо на каждом экземпляре,
но управлять ими из единого интерфейса. При плановом или аварийном отключении
любого экземпляра сохраняется возможность управления остальными.
Развертывание
Между экземплярами настраивается виртуальная сеть (VPN)
Для ее работы нужна сетевая связность между экземплярами.
Подробные сведения по настройке и необходимым доступам описаны по ссылке.
Существует несколько принципиальных схем внедрения.
+ отказоустойчивость за счет репликации БД; + нет потребности в дополнительном сервере для хранилища; − ресурсы экземпляров Mitigator´а расходуются на нужды хранилища; − повышенные требования к квалификации администратора; − отсутствие гибкости настройки.
+ полный контроль и гибкость (отказоустойчивость, тонкая настройка); + снимается нагрузка с экземпляров Mitigator´а; − требуется квалификация администратора; − нужен дополнительный сервер для хранилища; − необходимо запускать миграцию вручную при обновлении.
Управление через web-интерфейс
Основным изменением в интерфейсе Mitigator´а при переходе на режим кластера
стало разделение некоторых настроек на относящиеся к системе в целом и для
конкретных экземпляров.
На вкладке «Экземпляры» пользователю доступен список всех экземпляров системы.
Для каждого из них отображается текущий статус активности. Переключателями
централизованно изменяется состояние экземпляра. Нажатие на название
экземпляра переводит пользователя на страницу настройки экземпляра. Если в
системе создан только один экземпляр, то при нажатии на пункт меню «Экземпляры»
пользователь сразу попадет на страницу настройки экземпляра.
В настройках экземпляра могут быть изменены его название, признак лидера,
статус защиты и адрес обработчика пакетов для данного экземпляра.
Разделы «Интеграция в сеть» и «GRE-туннель со сторонним сервисом» теперь
также находятся на вкладке «Экземпляры», так как для корректной работы системы
следует задать параметры внедрения в сеть для каждого экземпляра.
Mitigator позволяет использовать агрегацию каналов (LAG) между устройствами
во внешней и внутренней сети. Настройки интеграции в сеть влияют на то, какие
варианты агрегации каналов могут использоваться:
в режиме «L2-прозрачность» — статический или динамический (например, LACP);
в режиме «On-a-stick» — только статический LAG.
Mitigator позволяет балансировать нагрузку между несколькими экземплярами системы
по ECMP за счет анонсирования по BGP каждым экземпляром одинаковых префиксов.
Когда один из экземпляров отключается, анонс снимается и трафик автоматически
распределяется между оставшимися экземплярами.
Карточка «Лицензия» разделена на две. В настройках системы задается
значение лицензионного ключа, а в настройках экземпляра находятся элементы
управления лицензированной полосой и сервисная информация.
В верхней панели интерфейса находится выпадающий список, позволяющий
выбрать экземпляр, для которого в системе будут показываться графики. Также
возможно отображение суммарно для всех экземпляров, если выбрано значение
«Все экземпляры».
3.1. Сеть между экземплярами
Принцип работы
Взаимодействие между экземплярами устроено через
Wireguard.
Между экземплярами создается виртуальная сеть (VPN).
Каждый экземпляр имеет ключевую пару: приватный ключ и публичный ключ.
Приватный ключ хранится только на своем экземпляре в vpn-private.conf.
Публичные ключи всех экземпляров перечислены в vpn-public.conf,
который должен быть одинаков на всех экземплярах.
В нем же указаны адреса экземпляров и их адреса в VPN.
Адрес экземпляра в VPN также указывается как MITIGATOR_VPN_ADDRESS в .env.
За организацию VPN отвечает компонент gateway. Когда кластеризация
не применяется, он не создает VPN. При кластеризации он настраивает VPN
в соответствии с vpn-private.conf, vpn-public.conf, MITIGATOR_VPN_ADDRESS.
Если нужно поменять настройки gateway, кроме *.conf, нужно полностью
перезапустить экземпляр (docker-compose down && docker-compose up -d).
Специальную команду для обновления конфигурации VPN
см. ниже.
Подготовка системы
Модуль ядра
Ubuntu 20.04 LTS включает Wireguard в базовой поставке.
Дополнительные действия не нужны.
В Debian 10 (Buster) требуется установить портированный пакет:
echo deb http://deb.debian.org/debian buster-backports main > /etc/apt/sources.list.d/buster-backports.list
apt-get update
apt-get install linux-headers-amd64 wireguard-dkms
Проверить поддержку можно командной modprobe wireguard. Если ничего
не печатается в ответ, модуль доступен. В этом случае достаточно настроить
его автоматическую загрузку. Иначе требуется перезагрузка.
Инструменты
Установить утилиту wg:
apt-get install wireguard-tools
Настройка экземпляра
Все файлы создаются в каталоге /srv/mitigator.
Если настраивается не первый экземпляр, файл vpn-public.conf нужно взять
с любого из настроенных экземпляров, чтобы дополнять его.
Создать приватный ключ
(пример результата: yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=):
Если используется больше файлов, например, docker-compose.override.yml,
их все нужно перечислить через двоеточия.
Добавить в .env адрес экземпляра внутри VPN:
MITIGATOR_VPN_ADDRESS=10.8.3.1
Он должен совпадать с настроенным в vpn-public.conf.
Также этот адрес должен быть указан в настройках экземпляра в
web-интерфейсе Mitigator´а.
Перезапустить Mitigator:
docker-compose down && docker-compose up -d
Настройка кластера после добавления экземпляра
После добавления нового экземпляра в файл vpn-public.conf нужно
внести изменения на всех экземплярах.
На каждом экземпляре нужно обновить конфигурацию VPN без перезапуска:
docker-compose exec gateway reconfigure
3.2. Общее нерезервированное хранилище
Перед настройкой кластера необходимо настроить
виртуальную сеть (VPN). Для ее работы нужна сетевая
связность между экземплярами. Подробные сведения по настройке и необходимым
доступам описаны по ссылке.
Общие базы данных для всех экземпляров Mitigator´а физически хранятся на сервере
одного из них. К базовому экземпляру должны быть разрешены подключения
с остальных экземпляров по следующим портам TCP: 8888, 2003, 3080, 5432.
Если кластер собирается из Mitigator´ов, которые ранее уже работали независимо,
то в ходе интеграции могут возникнуть конфликты. Поэтому на всех экземплярах
кроме будущего лидера необходимо выполнить команду:
docker-compose down -v
При выполнении данной команды будут удалены настройки контрмер, журнал событий,
графики и другая информация, хранимая в базах данных этих экземпляров. Если
данные нужно сохранить, следует предварительно сделать
резервную копию.
Установка базового экземпляра выполняется по шагам,
описанным в разделе «Установка».
Остальные экземпляры Mitigator´а должны обращаться к БД базового экземпляра
и поэтому сначала для них необходимо также выполнить стандартную установку.
После установки, но перед запуском, необходимо:
Если требуются дополнительные настройки, например, при использовании карт
Mellanox, поместить их в docker-compose.override.yml и добавить его
в список:
В файле .env задать переменную MITIGATOR_STORAGE_HOST=192.0.2.1.
Здесь 192.0.2.1 – адрес базового экземпляра.
В файле .env задать переменную MITIGATOR_OWN_NAME=mitigator-1.
Здесь mitigator-1 – имя экземпляра. Имя каждого экземпляра должно быть уникально.
В файле .env задать переменную MITIGATOR_HOST_ADDRESS=192.0.2.1.
Здесь 192.0.2.1 – адрес хоста для данного экземпляра.
3.3. Внутреннее отказоустойчивое хранилище
Перед настройкой кластера необходимо настроить
виртуальную сеть (VPN). Для ее работы нужна сетевая
связность между экземплярами. Подробные сведения по настройке и необходимым
доступам описаны по ссылке.
В целях отказоустойчивости синхронизированные копии БД должны физически
храниться на разных серверах (реплицироваться). При данной схеме реплики
БД хранятся на тех же серверах, где работают экземпляры Mitigator´а.
Это позволяет сэкономить ресурсы и не требует знаний по настройке PostgreSQL.
Если кластер собирается из Mitigator´ов, которые ранее уже работали независимо,
то в ходе интеграции могут возникнуть конфликты. Поэтому на всех экземплярах
кроме будущего лидера необходимо выполнить команду:
docker-compose down -v
При выполнении данной команды будут удалены настройки контрмер, журнал событий,
графики и другая информация, хранимая в базах данных этих экземпляров. Если
данные нужно сохранить, следует предварительно сделать
резервную копию.
Экземпляры PostgreSQL работают в схеме потоковой репликации
active — hot standby.
Вместо подключения к PostgreSQL напрямую каждый Mitigator подключается
к локальной работающий программе pgfailover,
которая перенаправляет подключения к PostgreSQL-лидеру репликации.
Если лидер недоступен, pgfailover делает лидером одну из ведомых реплик
в заданной очередности.
Mitigator-лидер кластера и PostgreSQL-лидер репликации не обязаны совпадать.
Предполагается, что между узлами надежная связь. Если группа экземпляров
окажется отрезана от лидера репликации, среди них будет выбран новый лидер
(split-brain). После восстановления связи придется вручную удалить данные
на отрезанной части экземпляров и заново ввести их в кластер.
Метрики для графиков пишутся Mitigator´ом-лидером на все экземпляры
для сохранности. Это задается списком серверов FWSTATS_GRAPHITE_ADDRESS.
Настройка
Процесс настройки описан для двух экземпляров и одинаков на всех экземплярах,
кроме конкретных значений MITIGATOR_OWN_INDEX. Для большего количества
экземпляров нужно расширить по аналогии списки серверов pgfailover
и FWSTATS_GRAPHITE_ADDRESS.
В файле .env задать переменную MITIGATOR_HOST_ADDRESS=192.0.2.1.
Здесь 192.0.2.1 – адрес хоста для данного экземпляра.
В файле .env задать переменную MITIGATOR_OWN_INDEX=0.
Здесь 0 – идентификатор очередности данного экземпляра
стать Active-сервером PostgreSQL.
Должен быть уникальным и последовательно возрастающим на каждом экземпляре.
В файле .env задать переменные SERVER1=10.8.3.1 и SERVER2=10.8.3.2.
Здесь 10.8.3.1 и 10.8.3.2– адреса серверов внутри VPN, на которых запущены
экземпляры. Также эти адреса должны быть указаны в настройках экземпляров в
web-интерфейсе Mitigator´а.
Если используются адаптеры Mellanox, вместо адресов серверов внутри VPN следует
указывать реальные адреса экземпляров.
Создать docker-compose.failover.yml на базе шаблона:
docker-compose run -e PGPORT=15432 postgres standby
после чего запускается как обычно:
docker-compose up -d
Если произойдет разрыв соединения с экземпляром-лидером (базы в режиме Active),
экземпляр с базами в режиме Standby занимает его место и становится лидером.
Механизма переключения баз бывшего лидера в режим Standby не предусмотрено
штатной репликацией PostgreSQL.
Для схемы из двух баз данных это означает прекращение репликации на другой
сервер до ручной перенастройки схемы.
Восстановление Standby из Active
Для переключения бывшего Active и возвращения его в схему репликации
необходимо остановить сервис PostgreSQL, а также удалить локальные данные базы.
Остановка сервиса PostgreSQL:
docker-compose rm -fsv postgres
Удаление локальных данных базы:
docker volume rm mitigator_postgres
Инициализация Standby аналогично первой инициализации:
docker-compose run -e PGPORT=15432 postgres standby
после чего запускается как обычно:
docker-compose up -d
Конфликт лидерства
В случае split brain в каждой изолированной части кластера будет выбран
свой лидер репликации, то есть кластер распадется на несколько меньших
(возможно, из единственной машины).
После восстановления связности pgfailover всех меньших кластеров обнаружат,
что есть несколько серверов PostgreSQL, работающих как лидеры репликации.
В каждом из кластеров сработает оповещение об этой ситуации,
будет создано событие журнала «Возник конфликт лидерства экземпляров».
В логах каждого бэкенда-лидера (docker-compose logs backend)
будет сообщение такого вида:
sender — индекс экземпляра, который оповещает о произошедшем
(MITIGATOR_OWN_INDEX, -index у pgfailover).
primary — индекс того экземпляра,
который sender читает корректным лидером репликации.
rivals — список индексов экземпляров, на которых PostgreSQL работает
как лидер репликации, помимо primary.
Необходимо проанализировать такие записи в логах всех экземпляров,
выбрать, какой будет лидером, а остальные сделать standby.
3.4. Внешнее отказоустойчивое хранилище
Перед настройкой кластера необходимо настроить
виртуальную сеть (VPN). Для ее работы нужна сетевая
связность между экземплярами. Подробные сведения по настройке и необходимым
доступам описаны по ссылке.
Данная схема внедрения подразумевает физическое хранение общих для всех
экземпляров Mitigator´а баз данных на внешнем сервере. Работоспособность
и отказоустойчивость всех СУБД обеспечивается силами администратора внешнего
сервера под конкретные требования.
Все экземпляры разворачиваются как worker´ы (см. выше).
Если кластер собирается из Mitigator´ов, которые ранее уже работали независимо,
то в ходе интеграции могут возникнуть конфликты. Поэтому на всех экземплярах
кроме будущего лидера необходимо выполнить команду:
docker-compose down -v
При выполнении данной команды будут удалены настройки контрмер, журнал событий,
графики и другая информация, хранимая в базах данных этих экземпляров. Если
данные нужно сохранить, следует предварительно сделать
резервную копию.
Схема взаимодействия:
Mitigator подключается к Postgres для записи и чтения настроек и журналов;
Mitigator оправляет в graphite метрики и обращается к его API;
В качестве инструмента для миграции схемы и дальнейшего управления используется
утилита SHMIG.
Миграции необходимо брать прямо из контейнера используемой версии:
Развернуть полноценный стенд
(временно закомментировать строку #COMPOSE_FILE= в файле .env).
Выполнить команду:
docker-compose create postgres
Скопировать скрипты миграции:
docker cp mitigator_postgres_1:/schema schema
Выполнить команду:
docker-compose rm -sf postgres
Восстановить состояние файла .env, раскомментировав строку
#COMPOSE_FILE=.
На уровне Postgres необходимо создать базу mitigator. Скрипты миграций
создадут пользователя backend и назначат ему необходимые права. После чего
на уровне СУБД нужно разрешить подключение для этого пользователя.
Экземпляры Mitigator´а подключаются к порту 5432/tcp.
Строку подключения можно явно переопределить, по умолчанию используется:
Mitigator отправляет метрики в формате Graphite plaintext
protocol по
адресу: ${MITIGATOR_STORAGE_HOST}:2003 (TCP). Если нужно отправлять их
в несколько баз, адреса можно указать явно через запятую:
Разместить compose-файл и задать глобальные параметры системы.
Настроить использование сетевых портов и ядер ЦП обработчиком пакетов.
Автоматизировать привязку драйверов к сетевым портам и запуск Mitigator´а.
Скачать Docker-образы Mitigator´а.
4.1. Подготовка системы
Оборудование
Hyper-threading
Рекомендуется включить hyper-threading в BIOS.
При включенном HT следующая команда показывает 2:
lscpu | grep 'Thread(s) per core:'
NUMA
Многопроцессорные платформы рекомендуется использовать в NUMA-режиме с одним процессором
на NUMA-ноду. Поддерживаются платформы с одной и двумя NUMA-нодами.
Для оптимальной производительности рекомендуется разносить сетевые карты по разным
NUMA-нодам, чтобы каждый процессор работал только с портами на своей ноде.
Для сетевых карт Intel и некоторых других в системе должен быть загружен модуль ядра,
позволяющий DPDK работать с ними. Для карт Mellanox загрузка модулей ядра не требуется.
Необходимо:
Подобрать драйвер для установленных сетевых устройств
(документация DPDK):
Для просмотра состояния сетевых устройств и доступных драйверов:
dpdk-devbind --status-dev=net
В списке Network devices using DPDK-compatible driver перечислены устройства,
привязанные к совместимому с DPDK драйверу. В списке Network devices using kernel driver —
устройства со стандартными драйверами ядра. Доступные драйвера указываются для каждого
устройства в поле unused=, например unused=i40e. Отображаются только драйвера,
загруженные в системе.
Для загрузки драйвера vfio-pci:
modprobe vfio-pci
Сопоставить имя устройства (например, eth0 или enp3s0f0) и его PCI-адрес
можно через поле if= в выводе dpdk-devbind.
Рекомендуется привязывать все устройства одной командной dpdk-devbind.
Для работы с vfio-pci все порты одной карты должны быть привязаны к одному драйверу.
Для привязки устройств 0000:06:00.0 и 000:06:00.1 к драйверу vfio-pci:
Если команда привязки выполнилась без сообщений об ошибках, драйвер можно
использовать. Устройство, привязанное к специальному драйверу, пропадает из системы
(вывод ip link и т.п.). Привязка работает до перезагрузки, автоматическую привязку
можно будет настроить при установке Mitigator´а.
Внимание. Устройства, отмеченные в списке **Active**, имеют IP-адрес. Обычно
это порт, через которой идет доступ к машине по SSH, поэтому скрипт не позволяет менять
драйвер таким устройствам.
Автоматическая загрузка модуля ядра
Если нужный модуль ядра не загружается по умолчанию при старте системы, его загрузку
можно включить так:
echo vfio-pci >> /etc/modules
Модуль vfio-pci
Модуль vfio-pci входит в состав ядра Linux. Необходим для работы DPDK с сетевыми
картами Intel. Требует поддержки процессором виртуализации ввода-вывода (например,
Intel VT-d). Настраивается в BIOS и в параметрах ядра через опцию iommu=on.
Для работы Mitigator´а необходимы настроенные hugepages (большие страницы памяти).
Платформой могут поддерживаться hugepages разных размеров (2 МБ, 1 ГБ), рекомендуется
настраивать страницы большего размера.
Необходимое количество hugepages зависит желаемого количества политик защиты.
Рекомендуется отводить на hugepages 50-75% от общего объема памяти.
1 GB hugepages
Рекомендуется использовать hugepages размером 1 ГБ, если поддерживаются платформой.
Их можно выделить только при загрузке системы.
Проверить поддержку:
grep -m1 pdpe1gb /proc/cpuinfo
Настраивается опциями в параметрах ядра. Пример для выделения 64-х 1 ГБ страниц:
default_hugepagesz=1G hugepagesz=1G hugepages=64
2 MB hugepages
Hugepages размером 2 МБ можно настраивать без перезагрузки системы.
Микроархитектуру процессора из списка указанных в файле-примере (ARCH).
Максимальное количество политик защиты (DATA_PLANE_NR_POLICIES).
Имя экземпляра в кластере (MITIGATOR_OWN_NAME, обязательно).
Внешний адрес Mitigator´а (MITIGATOR_HOST_ADDRESS, обязательно).
Прокси для сервера лицензий
(ls.mitigator.ru), почтовых уведомлений и службы «Весточка».
Часовой пояс (TZ).
Токен взаимодействия бэкенда и подсистемы детектирования (TOKEN).
Подробно эти настройки описаны внутри файла-примера.
2. Обработчик пакетов
Архитектура процессора
Для максимальной производительности Mitigator´а нужно использовать сборку,
оптимизированную под архитектуру и набор инструкций процессора целевой машины.
В файле .env должна быть строка вида:
ARCH=haswell
Доступные варианты:
nehalem - для SSE4.2,
sandybridge - для AVX,
haswell - для AVX2 и новее.
Свой процессор можно найти в каталоге Intel, микроархитектура указана в
строке Code Name. Для большинства современных процессоров подойдет haswell.
Параметры обработки
Необходимо создать файл data-plane.conf, описывающий параметры запуска обработчика
пакетов:
touch data-plane.conf
Файл настроек по умолчанию пустой. Править его требуется только если нужно указать
настройки, отличные от выбранных автоматически.
Описание настроек.
Выбор портов
Порты в приложении называются ext0, int0, ext1, int1 и т.д. ext — порты
внешней сети, int — порты внутренней (защищаемой) сети. Объединяются в ext-int пары по
индексу в названии. ext-int пары портов используются для маршрутизации трафика в схеме
включения «в разрыв». В схеме включения «on-a-stick» ext-int пары не используются и могут
быть любыми.
Если порты не заданы в настройках, используются все порты в системе, доступные DPDK.
В таком случае, порты перечисляются в порядке возрастания их PCI-адресов. ext-int пары
портов формируются только для портов с общей NUMA-ноды.
Если порядок перечисления портов по умолчанию не совпадает с физическим подключением
линков, либо требуется ограничить список используемых портов, порты можно настроить явно:
Обновить описание службы Docker и перезапустить её:
systemctl daemon-reload
systemctl restart docker
Mitigator
Если Mitigator будет сообщаться с сервером лицензий (ls.mitigator.ru),
почтовым сервером и службой «Весточка» через прокси, нужно указать переменные
окружения. Для этого нужно создать файл docker-compose.override.yml
с таким содержимым:
При необходимости задать также NO_PROXY (адреса, к которым нужно
обращаться без прокси), требуется включать в нее .mitigator и localhost:
NO_PROXY: "<новые серверы>,.mitigator,localhost"
После этого нужно перезапустить службу бэкенда:
docker-compose up -d backend
Собственный сертификат TLS
Для замены самоподписанного сертификата cert.crt с ключом cert.key
на собственный, необходимо смонтировать сертификат и ключ через
/srv/mitigator/docker-compose.override.yml:
modprobe: FATAL: Module igb_uio not found in directory /lib/modules/4.9.0-6-amd64
при установке пакета:
Module build for kernel 4.9.0-6-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Необходимо установить пакет linux-headers-amd64 (Debian) и убедиться,
что загружена версия ядра, соответствующая версии этого пакета, после
чего выполнить:
dkms autoinstall
Не работает docker и docker-compose
По умолчанию эти команды работают только для пользователей группы
docker и для root. Это стандартная мера безопасности Docker.
Решение:
sudo usermod -aG docker $USER
newgrp docker
Обработчик пакетов недоступен
Такое сообщение появляется в web-интерфейсе, если обработчик пакетов не
запустился или остановился. Диагностика (из /srv/mitigator):
docker-compose logs data-plane
Ниже приводятся некоторые типовые проблемы и характерные сообщения.
EAL: Cannot get hugepage information.
Сообщение:
EAL: No free hugepages reported in hugepages-2048kB
EAL: No free hugepages reported in hugepages-1048576kB
EAL: FATAL: Cannot get hugepage information.
EAL: Cannot get hugepage information.
EAL: Error exiting with code: 1
Cause: DPDK init error: 1
Причина: не выделены или полностью заняты hugepages.
Нужно проверить наличие свободных hugepages и убедиться, что значения
HugePages_Total и Hugepagesize совпадают с настроенными,
а HugePages_Free равно HugePages_Total (или отличается не более,
чем на несколько страниц):
grep Huge /proc/meminfo
no port found with PCI address BB:DD.F
Сообщение:
/data-plane/config.click:12: no port found with pci address '04:00.0'
Нужно убедиться, что адрес устройства 04:00.0 соответствует действительности,
и что устройство привязано к драйверу для DPDK точно так же,
как при подготовке системы.
Аварийное завершение
При просмотре логов docker-compose logs data-plane сообщение:
Segmentation fault (core dumped)
Чтобы незамедлительно восстановить работу, можно дать команду:
docker-compose up -d data-plane
Далее рекомендуется связаться с разработчиками с целью точной
диагностики и исправления и направить им:
Описание ситуации, в которой произошла проблема
(действий с Mitigator´ом, входящего трафика).
Описание аппаратной конфигурации сервера:
модель ЦП и сетевых карт;
размер памяти и конфигурация hugepages;
версия ядра Linux, используемые драйвера для сетевых карт и их версии.
Файл /srv/mitigator/data-plane.conf.
Файл сlick.stacktrace, который по умолчанию сохраняется
в /var/lib/docker/volumes/mitigator_coredumps/_data/click.stacktrace.
Core dump (слепок памяти процесса), который по умолчанию сохраняется
в /var/lib/docker/volumes/mitigator_coredumps/_data/core. Его
размер — гигабайты, но он обычно хорошо сжимается.
В некоторых дистрибутивах (например, Ubuntu) файл core не появляется,
потому что обработка сбоев настроена иначе.
Проверить настройку можно так:
cat /proc/sys/kernel/core_pattern
По умолчанию в Linux значение core. Если оно другое:
