Про использование виртуальных машин для Carbon Reductor

Эта статья содержит обезличенные цитаты из одной из заявок, в которой техническая поддержка решала проблему того, что периодически на Carbon Reductor, работающем в виртуальной машине не блокируются несколько ссылок. В самом начале заявки их число было близким к нескольким тысячам, под конец снизилось до шести, благодаря дополнительным настройкам. Когда клиент закончит переезд на железо - обязательно процитирую, что он скажет про результат работы.

Уменьшение числа работающих виртуальных машин на хосте - не решение

Рано радовались что проблема решена.

Мы изначально этому не радовались, потому что проблема не исключена. Снижение числа работающих на хосте виртуальных машин не создаёт близких к реалтайм-работе условий, так что у проблемы просто снизилась вероятность возникновения. Для полного исключения такой вероятности использовать Carbon Reductor следует на железе.

Сетевая производительность бывает разная

Там крутятся редуктор,тестовая машина с windowsXP, и еще 8мь vm, при этом суммарная процессорная загрузка не превышает 40% в пике, а бОльшую часть времени находится на уровне 17%-22%. На текущий момент выделено 8vcpu, дополнительно ни affinity ни приоритеты не назначались.

Хост совсем не загружен! И вроде как процессора и прерываний и сетевой производительности более чем достаточно!

Я никак не могу понять - как Вы декларируете гигабит фильтрации пропускной способности, если сейчас трафика куда меньше!

Итак, сетевая производительность бывает разной.

  1. Throughput - пропускная способность (объём трафика, который хостом может быть получен и доставлен к виртуальным машинам без потерь). Видимо здесь имелась в виду именно она. С пропускной способностью действительно может (и должно!) быть всё в порядке.
  2. Latency - задержки. В нашем случае важен именно этот тип производительности, максимальное снижение времени прохода пакетов по всей системе, включая сеть провайдера, начиная с отправки зеркала свитчом, заканчивая доставкой пакета с редиректом абоненту.

В случае с использованием Carbon Reductor в виртуальной машине многие места, влияющие на Latency, вносимые операционной системой, дублируются. По сути - это добавление на путь (обоих!) пакетов второго сетевой стэка, который тоже та ещё проблема оптимизировать под задачи захвата трафика.

Если на самом Carbon Reductor мы что-то пытаемся делать и можем (тюним прерывания, используем возможности Linux по максимуму итд), то на стороне гипервизора, как и на остальной внешней среде, куда нас редко пускают провайдеры (свитчи итд) - мы такого сделать не можем.

Про декларацию гигагабита в секунду - мы и 10 и 40гбит/с с достаточно хорошим latency добивались. Но - это на железном сервере, который занимается исключительно фильтрацией.

Сейчас, кстати, рассматриваем опциональную схему для провайдеров, которые хотят, чтобы всё в их сети было идеально, с выносом всех задач кроме обработки трафика на отдельный сервер, чтобы на latency никак не влияли выгрузки / разбор реестра / обработка списков и прочие периодические задачи, просто взять и избавиться от которых нельзя.

Выбор процессора - частота важнее числа тредов, тем более виртуальных

т.е. Хост с 8 CPUs x Intel(R) Xeon(R) CPU L5520 @ 2.27GHz и загрузкой в 20%-30% не успевает?!?! для VM с редуктором выделено 8-мь виртуальных ядер, т.е. все ядра трудятся над задачами редуктора - всем остальным VM отдано по 1-4 ядер. т.е. перекрываться не должно!

Тут немного поспорю, смотрите: http://ark.intel.com/products/40201/Intel-Xeon-Processor-L5520-8M-Cache-2_26-GHz-5_86-GTs-Intel-QPI

  1. Имеем довольно маленькую частоту процессора 2.26GHz (обычно мы рекомендуем на железе использовать как можно ближе к 3GHz и выше, пусть и с меньшим числом ядер).
  2. Ядер на самом деле не 8, а 4, включен hyperthreading, который мы, кстати, рекомендуем отключать для задач фильтрации трафика.
  3. Перекрываться будет, потому что дополнительных ядер, кроме 8 выделенных редуктору неисключительно у процессора нет.
  4. Выделять рекомендуется прямым пробросом, а не эмуляцией виртуальных ядер, но эта возможность зависит от гипервизора.

Виртуальная машина не может не использовать ресурсы процессора

В данном случае имеем следующую ситуацию: 8 тредов, часть из них (или все, я не знаю как именно выделяются 1-4 ядра остальным машинам) используются совместно с другими машинами. Машины - полноценные виртуальные, у них внутри есть полноценные операционные системы, которые точно так же, требуют ресурсов под свои системные задачи. Бесплатных тактов процессора не существует, так что это может редко, но метко (на какие-то жалкие доли секунды) очень отрицательно влиять не latency и приводить к замедлению процесса фильтрации трафика и приводить вот к таким разовым пропускам фильтрации.

Такая вот особенность работы в режиме анализа зеркала трафика, если не хочется влиять на качество предоставляемых абонентам услуг.

Как обойти все эти проблемы, не переходя на железо?

На самом деле вы можете попробовать провернуть следующую схему, в которой всё оставить как есть, кроме исключения влияния latency на результат проверок ревизора:

  1. Добавляем дополнительный виртуальный интерфейс на редуктор, специально для ревизора.
  2. Разворачиваем на редукторе dhcp
  3. Определяемся с адресацией и включаем опцию menu -> Настройка алгоритма фильтрации -> Редуктор - шлюз ревизора
  4. Включаем ревизора в свитч (мб и vSwitch) с виртуальным интерфейсом редуктора, тот получит адрес по dhcp и будет ходить через редуктор.

В такой схеме, забив на достижение хорошей latency получаем 99.9% качество фильтрации для абонентов и 100% качество для ревизора.

В любом другом случае нам будет необходимо добиваться гарантированного хорошего latency, что невозможно без переезда на железо.

Любые другие действия, кроме двух выше, связанные: со снижением нагрузки на отдельные части системы, эксперименты с системой виртуализации дадут только понижение вероятности возникновения проблемы (что никуда не денет плавающие проблемы с фильтрацией и, например, 3 ссылки в отчёте раз в неделю, а не 6 ссылок, как сейчас).

Почему мы так настойчиво рекомендуем перейти на железо

Мы поглядываем за http://asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=1102471-6, которые очень скоро вступит в действие, так что очень сильно рекомендуем вам как можно скорее перенести редуктор на отдельный сервер, либо провернуть вышеописанную схему, так как очень дорожим Вами, как и всеми нашими клиентами и не хотим, чтобы Вашу компанию штрафовали из-за каких-то мелочей, вроде не самого подходящего окружения для работы редуктора.

Штрафы ожидаются серьёзнейшие - 50-100 тысяч рублей за каждую незакрытую ссылку. Купить физический сервер и установить на него Carbon Reductor значительно дешевле.

Общие рекомендации

Постарайтесь всё же вместо виртуальной машины использовать физическую!

Виртуальная машина, это всегда какая-никакая, а прослойка между ресурсами процессора и выполняемыми задачами. Обработка зеркала трафика это практически задача реального времени, на которую отведен очень короткий промежуток времени, в течении которого Carbon Reductor должен успеть:

  1. Принять пакет в сетёвую карту.
  2. Протолкнуть пакет в операционную систему.
  3. Разобрать пакет
  4. Проанализировать, требуется ли ответить на него
  5. Сформировать ответный пакет
  6. Отправить его.

и пакет ещё должен вылететь в сеть и пролететь до абонента через все промежуточные хосты. В случае, если модули фильтрации будут ждать своей очереди крутиться на процессоре, а в это время он будет нагружен другими делами (например проверять, стоит ли сбросить кэши виртуальных дисков на физический диск или вообще сейчас ядро процессора используется другой виртуальной машиной) - ничего хорошего из этого не выйдет: у вас появится пропуск в проверке ревизора, а у нас лишняя задача в хелпдеске.

Так что лучше установить Carbon Reductor на физический хост и не рисковать!

Если вы всё таки решили положиться на вашу систему виртуализации:

  • При нагрузке больше 100 пользователей выделяйте Carbon Redcutor 4+ ядра процессора, которые никто кроме него не будет использовать (если кто-то использует их, то даже от 16 ядер ситуация лучше не станет - редуктор будет периодически обрабатывать пакеты медленнее, чем требуется).
  • Лучше, если других виртуальных машин на сервере не будет вообще (хотя, в таком случае, зачем вообще виртуализация? :) )
  • Старайтесь напрямую пробрасывать сетевые карты, а не эмулировать их.
  • Хост система тоже должна удовлетворять системным требованиям (хост с realtek-сетевками и эмуляцией e1000 внутри виртуалки - не даст повышения производительности).