configuration :: Tag :: BIFIT Mitigator

Смена конфигурации

Mon, 01 Jan 0001 00:00:00 +0000

Применить правки любых файлов конфигурации в /srv/mitigator: systemctl reload mitigator При этом могут быть перезапущены релевантные компоненты MITIGATOR. После смены сетевых портов (редактирования файла /etc/systemd/system/mitigator.service.d/nics.conf) выполните: systemctl daemon-reload && \ systemctl restart mitigator При этом MITIGATOR будет полностью выключен и заново включен. Похожие статьи Graphite на отдельном сервере Возврат к предыдущей версии Документация pgfailover Доступ к интерфейсу Grafana Задачи администратора Изменение конфигурационных параметров ClickHouse Изоляция ядер для оптимизации производительности Использование единого Graphite для нескольких кластеров MITIGATOR Настройка времени хранения метрик в Graphite Настройка системы для карт Mellanox (NVIDIA)

Доступ к интерфейсу Grafana

Mon, 01 Jan 0001 00:00:00 +0000

MITIGATOR в своей поставке включает Grafana, которую можно использовать для создания кастомизированных дашбордов. Обратитесь к документации Grafana, как именно это делать. Для получения доступа к веб-интерфейсу Grafana необходимо поднять сервис, который отключен по умолчанию. Временно это можно сделать следующей командой: docker-compose up -d --scale grafana=1 grafana Чтобы включить grafana на постоянной основе, необходимо в docker-compose.yml изменить scale с 0 на 1. services: ... grafana: ... scale: 1 ... После настройки необходимо поднять контейнер Grafana:

Изоляция ядер для оптимизации производительности

Mon, 01 Jan 0001 00:00:00 +0000

По умолчанию ядра CPU, работающие с сетевыми портами, используются и другими подсистемами. Это может снижать производительность и вызывать всплески Input Errors pps/bps на графиках Port extX/intX. Можно снять часть нагрузки с этих ядер, запретив некритичным подсистемам выполняться на них. Для этого: В опциях ядра пропишите изоляцию ядер обработчика пакетов через параметры isolcpus=... и rcu_nocbs=.... Также рекомендуется добавить mitigations=off для отключения патчей безопасности ядра. В .env добавьте параметры: DATA_PLANE_CPUS — список ядер, выделенных под обработчик пакетов (dataplane); CONTROL_PLANE_CPUS — список ядер, выделенных под остальные подсистемы (все остальные ядра). Скачайте docker-compose.cpuisol.yml, применяющий параметр cpuset для всех подсистем:

Документация pgfailover

Mon, 01 Jan 0001 00:00:00 +0000

pgfailover наблюдает за состоянием кластера PostgreSQL и выступает для клиентов как TCP-прокси к текущему Primary. При смене Primary pgfailover разрывает соединения с клиентами, и они должны переподключиться. Параметры подключения задаются через переменные окружения с префиксом PGFAILOVER_: export PGFAILOVER_BIND_ADDRESS=":5432" export PGFAILOVER_SERVERS="postgres://repuser@pg0.example.com/database?sslmode=disable&connect_timeout=5 postgres://repuser@pg1.example.com/database?sslmode=disable&connect_timeout=5" ./pgfailover Роль сервера (Primary/Standby) проверяется pg_is_in_recovery() по умолчанию раз в 5 секунд (PGFAILOVER_INTERVAL), количество попыток подключения регулируется переменной PGFAILOVER_ATTEMPTS (по умолчанию 1). pgfailover может автоматически переводить локальный PostgreSQL в Primary. Адрес локальной БД задаётся переменной окружения PGFAILOVER_PROMOTION_ADDRESS и должен совпадать с хостом одной из записей PGFAILOVER_SERVERS. Когда с Primary пропадает связь, pgfailover переводит в Primary первый по порядку Standby в PGFAILOVER_SERVERS. Если PGFAILOVER_PROMOTION_ADDRESS не задан, перевод в Primary отключён.

Настройка системы для карт Mellanox (NVIDIA)

Mon, 01 Jan 0001 00:00:00 +0000

Подготовка системы Работа с картами Mellanox (NVIDIA) требует актуальной версии драйвера и прошивки устройства NVIDIA MLNX_OFED. По указанной ссылке в разделе Download в таблице Current Versions выбрать актуальную версию MLNX_OFED для нужного дистрибутива операционной системы. При отсутствии нужной версии ОС выбрать ближайшую по старшинству. При отсутствии нужной ОС в списке MLNX_OFED не устанавливать. Проверена работа на Debian 10+ и Ubuntu 20.04+.

Настройки обработчика пакетов

Mon, 01 Jan 0001 00:00:00 +0000

Обработчик пакетов настраивается через файл dataplane.conf. Файл необходимо поместить в рабочий каталог MITIGATOR и добавить в него настройки, которые требуется изменить. Для незаданных настроек используются значения по умолчанию. Комментарии задаются через #, // или /* */. Доступные параметры (указаны значения по умолчанию): # IP-адрес сокета управления приложением. control_address: 0.0.0.0 # TCP-порт сокета управления приложением. # [1, 65535] control_port: 8888 # TCP-порт отладочного сокета управления приложением. # [1, 65535] debug_port: 8889 # TCP-порт gRPC-сокета управления приложением. # [1, 65535] grpc_port: 8890 # UDP-порт сокета управления sync/web-challenger. # [1, 65535] sync_udp_port: 8891 # Количество потоков обработки запросов к порту управления. # [1, 1000] control_threads: 20 # Таймаут обработки запросов к порту управления (секунды). # [1, 10000] control_request_timeout: 15 # Таймаут обработки содержимого запросов/ответов порта управления (секунды). # [1, 10000] control_content_timeout: 300 # Включение логирования событий порта управления. control_log: false # Ограничение на максимальную длину сообщения логирования событий порта управления. # [0, 100000] control_log_limit: 100 # Количество потоков обработки синхронизации данных. # [1, 1000] sync_threads: 10 # Включение логирования событий синхронизации данных. sync_log: false # Включение дополнительных ядер для сокета управления sync/web-challenger. use_extra_service_cores: false # MAC-адрес отправляемых challenge-пакетов. challenge_mac: <не задано> # VLAN ID отправляемых challenge-пакетов. # [1, 4095] challenge_vlan_id: <не задано> # LACP system ID. # По умолчанию используется локальный MAC-адрес. lacp_system_id: <автоопределение> # Операционный ключ порта LACP. # [0, 65535] lacp_oper_key: 1000 # Период повторной отправки запросов резолвера MAC-адресов (секунды). # [1, 10000] mac_retransmit_time: 5 # Время жизни валидных записей резолвера MAC-адресов (секунды). # [1, 10000] mac_reachable_time: 30 # Время жизни протухших записей резолвера MAC-адресов (секунды). # [1, 10000] mac_stale_time: 60 # Максимально допустимое количество политик IPv4. # [1, 60000] max_policies: 100 # Максимально допустимое количество политик IPv6. # [1, 60000] max_policies6: 100 # Максимально допустимая разрядность используемых SIMD-инструкций. # [0, 512] max_simd_bitwidth: <автоопределение> # Размер пула памяти сетевых пакетов (на NUMA-ноду). # [0, 2^31] packet_mempool_size: <автоопределение> # Включение отложенного старта обработки пакетов. # Сетевые порты поднимаются только после полной инициализации приложения. # Предотвращает появление петель на сети. deferred_start: false # Включение особого режима работы с сетевыми картами с двумя портами # (для `port_direct_mode: true`). # Каждый порт карты обрабатывается на отдельном наборе ядер. # Улучшает производительность на скоростях 100G и выше, # когда используются оба порта одновременно. dual_port_nic: false # Политика разгрузки контрольной суммы для RX-пакетов: # `false` - не запрашивать разгрузку, проверять программно; # `true` - включить разгрузку для всех портов, если поддерживается. # Включает разгрузку контрольной суммы только для физических портов, если не указано. port_checksum_offload: <автоопределение> # Режим обработки I/O-очередей сетевых портов: # `false` - обрабатывать I/O-очереди портов на выделенных ядрах, # рекомендуется для небольших скоростей; # `true` - обрабатывать I/O-очереди портов на ядрах обработки пакетов, # рекомендуется для скоростей 100G и выше. port_direct_mode: <автоопределение> # Скорость сетевых портов (Мбит/с). # Отключает автосогласование скорости, если задано. # [100|1000|10000|...] или [100M|1G|10G|...] port_link_speed: <автосогласование> # Включение синхронизации состояния линка пар сетевых портов. port_lsp: false # MTU сетевых портов. # [0, 65535] port_mtu: 1500 # Размер кольцевых буферов обмена пакетами между ядрами обработки I/O-очередей сетевых # портов и ядрами обработки пакетов (для `port_direct_mode: false`). # [0, 2^20] port_ring_size: 8192 # Количество RX-дескрипторов сетевых портов. # [0, 65535] port_rx_desc: <автоопределение> # Количество TX-дескрипторов сетевых портов. # [0, 65535] port_tx_desc: <автоопределение> # Максимальное количество попыток повторной отправки сетевых пакетов в порт. # [0, 2^31] port_tx_retries: 128 # Ядра обработки I/O-очередей сетевых портов (для `port_direct_mode: false`). # Список диапазонов [0, 255] port_cores: <автоопределение> # Количество ядер обработки I/O-очередей сетевых портов (на NUMA-ноду). # [0, 256] port_cores_nr: <автоопределение> # NUMA-ноды ядер обработки I/O-очередей сетевых портов. # Список диапазонов [0, 7] или `all`: # `all` - использовать все ноды. port_nodes: <автоопределение> # Ядра обработки пакетов. # Список диапазонов [0, 255] worker_cores: <автоопределение> # Количество ядер обработки пакетов (на NUMA-ноду). # [0, 256] worker_cores_nr: <автоопределение> # NUMA-ноды ядер обработки пакетов. # Список диапазонов [0, 7] или `all`: # `all` - использовать все ноды. worker_nodes: <автоопределение> # Список сетевых портов. # Определяет сетевые порты, используемые обработчиком пакетов. # Настраивает пары портов, зоны портов и их порядок. # Формируется автоматически для всех обнаруженных портов, если не задан. # Если задан, должны быть перечислены все используемые порты. # # Формат: # <зона_порта> [ext|int] <индекс_пары> [0, 255] : # id_порта: # или <номер_порта> [0, 255] или <имя_порта> (строка). # # Пример: ext0: 01:00.0 int0: 01:00.1 ext1: 04:00.0 int1: 04:00.1 Похожие статьи Изоляция ядер для оптимизации производительности Graphite на отдельном сервере Troubleshooting Документация pgfailover Доступ к интерфейсу Grafana Изменение конфигурационных параметров ClickHouse Использование единого Graphite для нескольких кластеров MITIGATOR Настройка времени хранения метрик в Graphite Настройка системы для карт Mellanox (NVIDIA) Настройка эшелонированной защиты на базе MITIGATOR

Период обновления графиков инцидентов

Mon, 01 Jan 0001 00:00:00 +0000

Период обновления графиков инцидентов по умолчанию равен 60 секундам. Для удобства работы с графиками инцидентов может потребоваться изменить период их обновления: Создать файл incident.yml и поместить в него: services: backend: environment: INCIDENT_UPDATE_PERIOD: "30" Здесь 30 – значение периода обновления в секундах. В файле .env задать переменную incident.yml: COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml:incident.yml Перезапустить MITIGATOR: systemctl restart mitigator Похожие статьи Graphite на отдельном сервере Документация pgfailover Доступ к интерфейсу Grafana Изменение конфигурационных параметров ClickHouse Изоляция ядер для оптимизации производительности Использование единого Graphite для нескольких кластеров MITIGATOR Настройка времени хранения метрик в Graphite Настройка системы для карт Mellanox (NVIDIA) Настройка эшелонированной защиты на базе MITIGATOR Настройки обработчика пакетов

Graphite на отдельном сервере

Mon, 01 Jan 0001 00:00:00 +0000

Перенос Graphite на отдельный сервер позволяет разделить нагрузку на два сервера. До переноса архива метрик, в интерфейсе MITIGATOR можно будет наблюдать только новые графики. Дальше по тексту Server1 – сервер с MITIGATOR, Server2 – сервер, на который выполняется перенос. Предполагается, что на Server2 уже установлен Docker и docker-compose и имеется способ доставки файловой базы с Server1 на Server2 (объем данных может составлять более 100 ГБ в зависимости от количества политик).

Изменение конфигурационных параметров ClickHouse

Mon, 01 Jan 0001 00:00:00 +0000

Конфигурационные параметры ClickHouse делятся на пользовательские и серверные. Узнать про структуру файлов и их расположение можно в официальной документации. При конфигурации модуля хранения метрик в MITIGATOR нужно учитывать следующее: корневой элемент конфигурационных файлов — пользовательские файлы конфигураций следует размещать в /etc/clickhouse-server/users.d внутри контейнера clickhouse файлы конфигурации сервера следует размещать в /etc/clickhouse-server/config.d внутри контейнера clickhouse Как сконфигурировать ClickHouse на примере ограничения используемой оперативной памяти сервером до 50Гб: Создать файл custom.xml с необходимыми параметрами

Подключение внешней Grafana

Mon, 01 Jan 0001 00:00:00 +0000

Чтобы внешняя Grafana могла получать данные с Graphite, нужно пробросить порт 3080 из контейнера, для чего: Создать, либо дополнить docker-compose.override.yml следующим: services: gateway: ports: - "13080:3080" Перезапустить MITIGATOR: docker-compose down && docker-compose up -d В Web-интерфейсе Grafana добавить источник данных: Выбрать тип Graphite и указать внешний адрес:

Использование единого Graphite для нескольких кластеров MITIGATOR

Mon, 01 Jan 0001 00:00:00 +0000

Использование единого Graphite для нескольких MITIGATOR позволяет снизить нагрузку на вычислительные ресурсы комплексов обработки трафика, упростить администрирование, настроить сложный мониторинг. Настройка Настройка сходна с переносом Graphite на отдельный сервер. Если имеется хост с настроенным Graphite, необходимо перейти к этапу настройки MITIGATOR для работы с внешним общим Graphite. Создайте директорию под сервисы: mkdir -p /opt/mitigator-graphite Скачайте docker-compose.yml:

Настройка времени хранения метрик в Graphite

Mon, 01 Jan 0001 00:00:00 +0000

MITIGATOR хранит данные графиков в Graphite-ClickHouse. Свежие данные хранятся с меньшим разрежением, затем прореживаются: Срок Разрежение меньше суток 5 секунд от суток до недели 10 секунд от недели до месяца 1 минута от месяца до 145 дней 5 минут свыше 145 дней 10 минут Времена хранения не суммируются, то есть данные за последний день последней недели хранятся с разрежением 5 секунд, а следующие 6 дней (не 7) хранятся с разрежением 10 секунд. В отличие от стандартного хранилища Graphite, ClickHouse продолжает хранить метрики с самым высоким разрежением из заданных и за пределами настроенного срока (с настройками по умолчанию — после 145 дней).

Настройка эшелонированной защиты на базе MITIGATOR

Mon, 01 Jan 0001 00:00:00 +0000

Наибольшую эффективность при защите от DDoS-атак показывают схемы эшелонированной обороны, где тонкой очисткой трафика, поступающего в защищаемую сеть, занимается on-premise устройство на границе сети, а защитные механизмы на уровне вышестоящего оператора связи позволяют предотвратить переполнение канала. Постоянно включенная защита на стороне оператора связи может вызывать проблемы и оказывать негативное влияние на легитимный трафик, поэтому она должна активироваться только по необходимости. Для этого сценария требуется настроить взаимодействие между эшелонами защиты — облачную сигнализацию.