... {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. 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.
|