Виртуальные машины запрещено использовать для продакшна.  Все рекомендации по системам виртуализации даны исключительно для того, чтобы посмотреть на возможности Carbon Reductor во время тестового периода. В случае, если от данной инсталляции зависит отсутствие/наличие штрафов за пропуски обязательно использование физического сервера.

Почему запрещено использовать виртуальные машины

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

Обработка зеркала трафика это задача реального времени. На неё отведен короткий промежуток времени, в течении которого Carbon Reductor должен успеть среагировать на пакет.

В некоторых сетях требуется вводить оптимизации для надёжной работы на всех возможных уровнях схем ниже:

• Снимать зеркало трафика ближе к абонентам
• Использовать OSPF, чтобы снизить число промежуточных хостов для пакетов с редиректами
• Использовать BGP Blackhole с блокировкой на маршрутизаторе до зеркала трафика, чтобы снизить его объём.

Все эти оптимизации можно перечеркнуть, используя ненадёжный вычислительный ресурс - виртуальную машину.

Процесс фильтрации

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

Мы готовим статью с исследованием того, как различные факторы влияют на время реакции на пакет с запросом к запрещённому ресурсу. Когда закончим - добавим к пунктам схем диапазоны вносимых задержек для лучшего восприятия.

Без виртуализации

С виртуализацией

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

Есть несколько способов снизить задержки и потери пакетов вносимые системой виртуализации:

• Проброс PCI-устройств.
• Полное выделение оперативной памяти (а не по требованию).
• Эксклюзивное выделение ядер процессора.
• Выделение большего числа ядер процессора.
• Тюнинг сетевого стека хост-системы (не во всех системах это доступно)
• Выбор аппаратного обеспечения хост-системы, соответствующего системным требованиям.

Но они не избавляют от них целиком.

В случае, если модули фильтрации будут ждать своей очереди выполняться на ядре процессора, а в это время он будет нагружен другими делами - это закончится запоздалой реакцией на пакет или его потерей. У вас появится пропуск в проверке ревизора, а у нас лишняя задача в хелпдеске. Лучше установить Carbon Reductor на физический сервер и не рисковать.

Часто задаваемые вопросы

Почему у меня проблемы с производительностью в VM на мощном сервере?

Производительность бывает разной и при этом проблемы с не обязательно связаны друг с другом.

• Throughput - пропускная способность (объём трафика, который хостом может быть получен и доставлен к виртуальным машинам без потерь). С пропускной способностью действительно может (и должно!) быть всё в порядке.
• Latency - задержки. В нашем случае важен именно этот тип производительности, максимальное снижение времени прохода пакетов по всей системе, включая сеть провайдера, начиная с отправки зеркала коммутатором, заканчивая доставкой пакета с редиректом абоненту.

В случае с использованием Carbon Reductor в виртуальной машине дублируются вносимые операционной системой места, влияющие на задержки. Из-за дублирования может не возникать потерь пакетов, но время реакции на запросы существенно снижается, что может приводить к пропускам фильтрации. По сути - это добавление на путь обоих пакетов - и запроса и редиректа пакетов второго сетевой стэка, который также требует оптимизации под задачи захвата трафика. Если на самом Carbon Reductor мы что-то пытаемся делать в автоматическом и ручном режиме (распределения прерываний, максимизация частоты процессора, прерывания, увеличение размера буферов сетевых карт), используя возможности Linux по максимуму, то на стороне гипервизора, как и на остальной внешней среде мы такого обычно сделать не можем - либо нет доступа, либо компетенции в сторонних закрытых продуктах. Однако оптимизация не означает избавления от дополнительных задержек.

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

Почему частота процессора важнее числа ядер?

Рассмотрим то, из чего состоит обработка пакета (упрощённо):

1. Попадение в сетевую карту.
2. Сетевая карта посылает прерывание.
3. Операционная система копирует пакет из памяти в очередь.
4. Очередь на обработку пакета доходит до него.
5. Пакет попадает в модуль фильтрации.
6. Содержимое анализируется.
7. Производится поиск по базе сигнатур.
8. При срабатывании поиска посылается ответный пакет.

Число ядер позволяет масштабировать пункты 2, 3, 4, 5 - можно добавить больше сетевых карт, одновременно обрабатывать несколько очередей.

Но на скорость обработки отдельного пакета, когда до него доходит очередь число ядер не влияет. У процессора есть описанный в модуле фильтрации набор инструкций, который ему в любом случае надо последовательно выполнить. Чем выше частота процессора - тем больше инструкций он может выполнить за определённое время и тем быстрее обработает пакет. Помимо частоты процессора на скорость обработки отдельного пакета влияют:

• объём кэш-памяти процессора;
• частота оперативной памяти;
• скорость системной шины.

Гипертрединг не приносит прироста производительности в этой задаче по той же причине.

Что такое эксклюзивное выделение ресурсов?

Эксклюзивное выделение ресурса означает, что ничто в системе больше не будет его использовать.

Если несколько виртуальных машин используют одно и то же ядро процессора и это ядро используется виртуальной машиной Carbon Reductor для обработки трафика - это означает что периодически виртуальная машина Carbon Reductor будет ожидать своей очереди выполняться на этом ядре и в это время очереди сетевых карт не будут обрабатываться. Время, в течение которого очередь использовать ядро процессора дойдёт до ВМ с Carbon Reductor может на порядки отличаться от времени обработки одного пакета модулем фильтрации.

Выделять ядра рекомендуется прямым пробросом, а не эмуляцией виртуальных ядер, но эта возможность зависит от гипервизора.

Почему гипертрединг не даёт прироста производительности?

Гипертрединг даёт прирост производительности только при условии, что процессор значительную часть времени проводит в состоянии простоя.

В случае с обработкой крупных потоков трафика это не так.

Теоретически небольшая выгода есть - на одно физическое ядро (core) будет приходиться две очереди сетевой карты.

Но:

• Того же можно добиться с помощью ethtool -L
• Это не ускорит обработку трафика. Если ядро не успевает его обработать, проблема скорее всего вычислительных ресурсах процессора, а не самой очереди.

Рекомендации по системам виртуализации

VMWare ESXi

Для зеркала трафика используйте тип сетевых карт vmxnet3, а не e1000 или vmxnet.

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

Известные проблемы:

1. Имели место случаи изменения порядка пакетов редиректа и RST. Точная причина не обнаружена (возможно промежуточное оборудование, возможно хост-система, при включенном tcpdump/tshark не воспроизводилась).
2. Нужно настроить vSwitch для приёма зеркала, иначе в зеркало трафика будет приходить только broadcast-трафик.

KVM

• Поддерживает прямой проброс оборудования.
• Сетевую карту можно настроить на хосте.
• Можно эксклюзивно выделить сетевую карту и ядра процессора виртуальной машине.

ЗАМЕЧАНИЕ: Некоторые виды виртуальных сетевых карт приводят к проблемам с фильтрацией по данным в пакете. Если вы столкнулись с этой проблемой, попробуйте поменять тип сетевой карты на e1000.

Proxmox

Не рекомендуем на каналах больше 100мбит/с.

XEN

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

VirtualBox

Не подходит ни для реальной эксплуатации ни для тестирования качества фильтрации.

LXC, OpenVZ, Docker

Из-за ограничений на взаимодействие с ядром ОС не подходят для работы с Carbon Reductor.

Hyper-V

В случае работы на Windows server 2012 Standart нужны следующие действия:

1. Установить и применить пакет обновления от Microsoft KB2885541 (https://support.microsoft.com/ru-ru/kb/2885541)
2. Настроить зеркалирование через PowerShell:

> $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

Вместо ALLTRAFFICMONITOR подставить название своего виртуального свича в Hyper-V.