... * Проброс PCI-устройств.
* Полное выделение оперативной памяти (а не по требованию).
* Эксклюзивное выделение ядер процессора.
* Выделение большего числа ядер процессора.
* Тюнинг сетевого стека хост-системы (не во всех системах это доступно)
* Выбор аппаратного обеспечения хост-системы, соответствующего [системным требованиям|CarbonReductor:Системные требования].
Но они не избавляют от них целиком.
В случае, если модули фильтрации будут ждать своей очереди выполняться на ядре процессора, а в это время он будет нагружен другими делами - это закончится запоздалой реакцией на пакет или его потерей. У вас появится пропуск в проверке ревизора, а у нас лишняя задача в хелпдеске. Лучше установить Carbon Reductor на физический сервер и не рисковать.
h1. Часто задаваемые вопросы
h2. Почему у меня проблемы с производительностью в VM на мощном сервере?
Производительность бывает разной и при этом проблемы с не обязательно связаны друг с другом.
* *Throughput* \- пропускная способность (объём трафика, который хостом может быть получен и доставлен к виртуальным машинам без потерь). С пропускной способностью действительно может (и должно\!) быть всё в порядке.
* *Latency* \- задержки. В нашем случае важен именно этот тип производительности, максимальное снижение времени прохода пакетов по всей системе, включая сеть провайдера, начиная с отправки зеркала коммутатором, заканчивая доставкой пакета с редиректом абоненту.
В случае с использованием Carbon Reductor в виртуальной машине дублируются вносимые операционной системой места, влияющие на задержки. Из-за дублирования может не возникать потерь пакетов, но время реакции на запросы существенно снижается, что может приводить к пропускам фильтрации. По сути - это добавление на путь обоих пакетов - и запроса и редиректа пакетов второго сетевой стэка, который также требует оптимизации под задачи захвата трафика. Если на самом Carbon Reductor мы что-то пытаемся делать в автоматическом и ручном режиме (распределения прерываний, максимизация частоты процессора, прерывания, увеличение размера буферов сетевых карт), используя возможности Linux по максимуму, то на стороне гипервизора, как и на остальной внешней среде мы такого обычно сделать не можем - либо нет доступа, либо компетенции в сторонних закрытых продуктах. Однако оптимизация не означает избавления от дополнительных задержек.
Сейчас, кстати, тестируется схема масштабирования для провайдеров, которые хотят, чтобы всё в их сети было идеально, с выносом всех задач кроме обработки трафика на отдельный сервер, который можно устанавливать в виртуальную машину. Это позволяет избавиться от влияния на задержки периодических задач, от которых нельзя просто взять и избавиться - выгрузка и разбор реестра, обработка списков, интеграция с маршрутизаторами и т.д.
h2. Почему частота процессора важнее числа ядер?
Рассмотрим то, из чего состоит обработка пакета (упрощённо):
# Попадение в сетевую карту.
# Сетевая карта посылает прерывание.
# Операционная система копирует пакет из памяти в очередь.
# Очередь на обработку пакета доходит до него.
# Пакет попадает в модуль фильтрации.
# Содержимое анализируется.
# Производится поиск по базе сигнатур.
# При срабатывании поиска посылается ответный пакет.
Число ядер позволяет масштабировать пункты 2, 3, 4, 5 - можно добавить больше сетевых карт, одновременно обрабатывать несколько очередей.
Но на скорость обработки отдельного пакета, когда до него доходит очередь число ядер не влияет. У процессора есть описанный в модуле фильтрации набор инструкций, который ему в любом случае надо последовательно выполнить. Чем выше частота процессора - тем больше инструкций он может выполнить за определённое время и тем быстрее обработает пакет. Помимо частоты процессора на скорость обработки отдельного пакета влияют:
* объём кэш-памяти процессора;
* частота оперативной памяти;
* скорость системной шины.
Гипертрединг не приносит прироста производительности в этой задаче по той же причине.
h2. Что такое эксклюзивное выделение ресурсов?
Эксклюзивное выделение ресурса означает, что ничто в системе больше не будет его использовать.
Если несколько виртуальных машин используют одно и то же ядро процессора и это ядро используется виртуальной машиной Carbon Reductor для обработки трафика - это означает что периодически виртуальная машина Carbon Reductor будет ожидать своей очереди выполняться на этом ядре и в это время очереди сетевых карт не будут обрабатываться. Время, в течение которого очередь использовать ядро процессора дойдёт до ВМ с Carbon Reductor может на порядки отличаться от времени обработки одного пакета модулем фильтрации.
Выделять ядра рекомендуется прямым пробросом, а не эмуляцией виртуальных ядер, но эта возможность зависит от гипервизора.
h2. Почему гипертрединг не даёт прироста производительности?
Гипертрединг даёт прирост производительности только при условии, что процессор значительную часть времени проводит в состоянии простоя.
В случае с обработкой крупных потоков трафика это не так.
Теоретически небольшая выгода есть - на одно физическое ядро (core) будет приходиться две очереди сетевой карты.
Но:
* Того же можно добиться с помощью ethtool \-L
* Это не ускорит обработку трафика. Если ядро не успевает его обработать, проблема скорее всего вычислительных ресурсах процессора, а не самой очереди.
h1. Рекомендации по системам виртуализации
h2. VMWare ESXi
Для зеркала трафика используйте тип сетевых карт *vmxnet3*, а не e1000 или vmxnet.
Эти сетевые карты поддерживают [распределение прерываний по нескольким ядрам процессора, что позволяет снизить нагрузку|Потери на сетевых картах, задержки в обработке и как с ними бороться].
Известные проблемы:
# Имели место случаи изменения порядка пакетов редиректа и RST. Точная причина не обнаружена (возможно промежуточное оборудование, возможно хост-система, при включенном tcpdump/tshark не воспроизводилась).
# Нужно [настроить vSwitch для приёма зеркала|reductor5:Reductor в VMWare], иначе в зеркало трафика будет приходить только broadcast-трафик.
h2. KVM
* Поддерживает прямой проброс оборудования.
* Сетевую карту можно настроить на хосте.
* Можно эксклюзивно выделить сетевую карту и ядра процессора виртуальной машине.
*ЗАМЕЧАНИЕ*: Некоторые виды виртуальных сетевых карт приводят к проблемам с фильтрацией по данным в пакете. Если вы столкнулись с этой проблемой, попробуйте поменять тип сетевой карты на e1000.
h2. Proxmox
Не рекомендуем на каналах больше 100мбит/с.
h2. XEN
Иногда имеются проблемы с передачей пакетов модулю для анализа, смещены указатели на данные.
h2. VirtualBox
Не подходит ни для реальной эксплуатации ни для тестирования качества фильтрации.
h2. LXC, OpenVZ, Docker
Из-за ограничений на взаимодействие с ядром ОС не подходят для работы с Carbon Reductor.
h2. Hyper-V
В случае работы на Windows server 2012 Standart нужны следующие действия:
# Установить и применить пакет обновления от Microsoft KB2885541 ([https://support.microsoft.com/ru-ru/kb/2885541])
# Настроить зеркалирование через PowerShell:
{code}
> $ExtPortFeature=Get-VMSystemSwitchExtensionPortFeature -FeatureName "Ethernet Switch Port SecuritySettings"
> $ExtPortFeature.SettingData.MonitorMode = 2
> PS C:\Windows\System32\WindowsPowerShell\v1.0> Add-VMSwitchExtensionPortFeature -ExternalPort -SwitchName ALLTRAFFICMONITOR -VMSwitchExtensionFeature $ExtPortFeature
{code}
Вместо ALLTRAFFICMONITOR подставить название своего виртуального свича в Hyper-V.
|
