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

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 - можно добавить больше сетевых карт, одновременно обрабатывать несколько очередей.

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

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

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

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

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 
Ищите метку? просто начните печатать.