Виртуальные машины

Skip to end of metadata
Go to start of metadata
Виртуальные машины запрещено использовать для продакшна. 

Все рекомендации по системам виртуализации даны исключительно для того, чтобы посмотреть на возможности 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.

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.