Просмотр Исходного

{toc}
{warning}
Виртуальные машины запрещено использовать для продакшна. 

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


В случае, если от данной инсталляции зависит отсутствие/наличие штрафов за пропуски *обязательно* использование физического сервера.
{warning}

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

*Коротко*: постарайтесь всё же вместо виртуальной машины использовать физическую\!

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

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

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

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

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

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

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

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

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

!Снимок экрана 2018-07-24 в 15.40.09.png|border=1,width=600!

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

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

!Снимок экрана 2018-07-24 в 15.40.21.png|border=1,width=600!

Есть несколько способов снизить задержки и потери пакетов вносимые системой виртуализации:
* Проброс 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.