|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (12)
просмотр истории страницы... |
| {warning} |
| h1. Общие рекомендации |
| h1. Почему запрещено использовать виртуальные машины |
| *Коротко*: постарайтесь всё же вместо виртуальной машины использовать физическую\! |
... |
| * Использовать BGP Blackhole с блокировкой на маршрутизаторе до зеркала трафика, чтобы снизить его объём. |
| Все эти оптимизации можно перечеркнуть, используя ненадёжный вычислительный ресурс - виртуальную машину. h1. Процесс фильтрации Эти схемы показывают как выглядит путь пакета в сети провайдера и срабатывание системы фильтрации. Мы готовим статью с исследованием того, как различные факторы влияют на время реакции на пакет с запросом к запрещённому ресурсу. Когда закончим - добавим к пунктам схем диапазоны вносимых задержек для лучшего восприятия. |
| h2. Без виртуализации |
... |
| Эта схема - упрощённый пример, все этапы обработки пакетов и работы систем виртуализации можно расписать подробнее, некоторые нюансы могут отличаться. |
| Есть несколько способов снизить задержки и потери пакетов вносимые системой виртуализации: |
| !Снимок экрана 2018-07-24 в 15.40.21.png|border=1,width=600! |
| |
| Есть несколько способов снизить задержки и потери пакетов вносимые системой виртуализации: |
| * Проброс PCI-устройств. * Полное выделение оперативной памяти (а не по требованию). * Эксклюзивное выделение ядер процессора. * Выделение большего числа ядер процессора. |
| * Тюнинг сетевого стека хост-системы. |
| * Тюнинг сетевого стека хост-системы (не во всех системах это доступно) |
| * Выбор аппаратного обеспечения хост-системы, соответствующего [системным соответствующего [системным требованиям|CarbonReductor:Системные требования]. |
| Но они не избавляют от них целиком. |
| !Снимок экрана 2018-07-24 в 15.40.21.png|border=1,width=600! |
| В случае, если модули фильтрации будут ждать своей очереди выполняться на ядре процессора, а в это время он будет нагружен другими делами - это закончится запоздалой реакцией на пакет или его потерей. У вас появится пропуск в проверке ревизора, а у нас лишняя задача в хелпдеске. Лучше установить 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. Рекомендации по системам виртуализации |
... |