1. без віртуалізації
2. З виртуализацией
3. Чому у мене проблеми з продуктивністю в VM на потужному сервері?
4. Чому частота процесора важливіше числа ядер?
5. Що таке ексклюзивне виділення ресурсів?
6. Чому гіпертредінг не дає приросту продуктивності?
7. VMWare ESXi
8. KVM
9. Proxmox
10. XEN
11. VirtualBox
12. LXC, OpenVZ, Docker
13. Hyper-V

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

Замість ALLTRAFFICMONITOR підставити назву свого віртуального свіча в Hyper-V.