mpd-5.5

[dadv]

Первый стресс-тест mpd-5.5/PPPoE под FreeBSD 8.2-STABLE/amd64 на реальной нагрузке.

Система настроена решать одну задачу - терминировать пользовательские сессии PPPoE с AAA через RADIUS, с шейпингом трафика и анонсированием абонентских IP-адресов в ядро сети через OSPF. На машине нет NAT (адреса реальные), нет netflow (собирается на другом роутере), нет BGP.

В час наибольшей нагрузки отмечено:

• 1812 сессий PPPoE;
  
• средняя нагрузка по ядрам процессора 2% user time / 88% (system time + interrupts) (CPU0: 2+90, CPU1: 2+89, CPU2: 2+90, CPU3: 3+86);
  
• 1184.9Mbit/s трафика в сторону клиентов и 830.9Mbit/s от них (итого 2015.8Mbit/s);
  
• 549.8Kpps: на интерфейсе lagg0 136.2Kpps in, 120.3Kpps out и на lagg1 139.0Kpps in, 154.3Kpps out;
  
• до 102K прерываний в секунду (device polling не использовался);
  
• использовано памяти:
  
  Mem: 101M Active, 41M Inact, 486M Wired, 1644K Cache, 138M Buf, 3314M Free
  
  
• в среднем на одну PPPoE-сессию приходилось 654.1Kbit/s трафика на вход и 434.2Kbit/s на выход.

То есть, на каждый процент загрузки CPU пришлось по 20 сессий.
Система продолжала быть отзывчивой на ssh так же, как и без нагрузки.

Железо:

• SuperMicro SuperServer 5016T-MTFB с двумя гигабитными интегрированными сетевыми Intel 82574L (драйвер em) и платой IPMI 2.0 с выделенным портом 100M;
  
• дополнительная двухпортовая сетевая карта Intel 82576 (драйвер igb);
  
• процессор Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (четыре ядра, гипертрединг отключен в BIOS Setup, 4M Cache, 4.80 GT/s Intel® QPI);
  
• 4GB памяти ECC;
  
• в качестве загрузочного носителя SSD 64GB (KINGSTON SNV425S264GB), при загрузке монтируется только для чтения (система собрана в виде NanoBSD, без свопа).

Общая стоимость железа около 60 тысяч рублей (всё железо новое).

Сетевые em0 и em1 объединены в lagg0, на нём есть IP-адрес и нет vlan-ов, это аплинк. Сетевые igb0 и igb1 объединены в lagg1, на котором нет IP, зато создано 596 vlan-ов, каждый из которых несет PPPoE-трафик пользователей. Шейпинг выполнен через ipfw/dummynet - на каждого подключенного пользователя dummynet динамически (pipe ... mask) создает по две индивидуальных трубы, на вход и на выход, в соответствии с тарифом пользователя. Весь шейпинг делается двумя правилами ipfw, список правил не растет при росте количества абонентов:

pipe tablearg ip from any to table(11) in
pipe tablearg ip from table(12) to any in

Для сравнения: бывшая в употреблении Cisco 7201 на usedcisco.ru стоит $11400 $10900 (примерно в 5.5 раз дороже), срок поставки 3 недели. На этой же задаче и на этих же пользователях обрабатывает около 10 сессий на процент загрузки CPU (то есть, вдвое меньше), причем при высоких загрузках вносит большие задержки и сама с трудом управляется по telnet. Поэтому приходится ограничивать количество сессий на ней (не более 700), чтобы держать нагрузку в пределах 75%. Стоит отметить, что при маленьких нагрузках (ближе к нулю) количество сессий на процент загрузки CPU у обоих систем растет в разы.

Зато Cisco - продукт, и умеет гораздо больше, например, ISG. А FreeBSD - конструктор, и требует существенного тюнинга. Про тюнинг как-нибудь в другой раз.

Update: для проверки провёл второй тест на FreeBSD с целью удержать загрузку в пределах 75%. При прочих равных условиях для этого оказалось нужным ограничить количество сессий PPPoE в 1500. Подтверждается прямая пропорциональность: 1800/0.9=1500/0.75=2000, что даёт нам прогноз стопроцентной загрузки при 2000 сессиях.

На деле у меня пока достаточно железок, чтобы держать нагрузку в пике на уровне 35% :-)

Comments

[blacklion.livejournal.com]

Красиво.

[techquisitor.livejournal.com]

Помнится, несколько дней назад немножко спорил с товарищем о софт- и хард роутерах. Так ни до чего и не доспорились. :)

Но в очередной раз убедился, что при прямых руках такой конструктор не уступит по прозводительности брэндовым решениям (а то и порвёт как тузик грелку) и даст суровую экономию даже с учётом всех расходов (зарплата спеца, железа, етц). Хотя на очень больших сетях с количеством абонентов эдак 400-600 тысяч нужны другие решения. Хотя на том же наге, помнится, 10 гигабит на лялихе вполне себе роутили.

[http://users.livejournal.com/_slw/]

даже самое другое решение не тянет более 32К, кажется, на шасси.
так что по любому надо ставить К или даже М коробок.

а с хард-роутерами тягаться бесполезно -- от 100G интерфейса захлебнешься и 322 Tbps тебе не светит

[easyjohn.livejournal.com]

65xx с мозгом 7200 роутит 400мп/с.
а кто дает 32k? это терминация ppoe или?

[dadv.livejournal.com]

Просто отроутить IP-пакеты задача сама по себе проще.

[techquisitor.livejournal.com]

Естессно.

[easyjohn.livejournal.com]

некоторое время назад вопрос был в интерраптах, на пц в них упирались, что мешало получить адекватный ппс.
как сейчас стало - не очень следил.

[techquisitor.livejournal.com]

Сейчас новые чипсеты пошли. Те же упоминаемые мной 10 гигабит роутили на Intel X58, кажется. Если очень надо, ссылку на наг могу найти.

[fuflolog.livejournal.com]

Поздравляю, ты собрал себе джунипер!

[dadv.livejournal.com]

Только без ASIC.

[dmartynov.livejournal.com]

Обязательно выложи всё на какой-нибудь публичный ресурс типа opennet - вселенские знания в карму :)

[dadv.livejournal.com]

Туда надо с описанием тюнинга, а описание пока не готово :-)

[mtg-nvkz.livejournal.com]

А почему не на НАГ? )))

[sir-dog.livejournal.com]

Красиво!
Как я понимаю, это все сопровождалось достаточно суровым тюнингом?

[dadv.livejournal.com]

Да (http://dadv.livejournal.com/138951.html).

Re: Конфиги.

[dadv.livejournal.com]

Достаточно собрать все указанные параметры и получатся loader.conf и sysctl.conf

[actika.livejournal.com]

А как же netisr ? Непробовали ?
http://alter.org.ua/ru/soft/fbsd/netisr/

[dadv.livejournal.com]

Сайт в данный момент не открывается (и даже не пингуется).

Про проблемы netisr я писал в следующих постах, описывающих тюнинг системы, ссылка в конце этого поста.

[metal-solid.livejournal.com]

извините, а чем вы мониторите это хозяйство?

[dadv.livejournal.com]

Через bsnmpd и его модуль bsnmp-ucd из портов, у которого есть фича extNames для передачи через SNMP результата вызова внешних скриптов. Так у меня mrtg рисует, получая по SNMP, количество PPPoE-сессий, по-ядерную загрузку серверов с разбивкой на user/nice/system/interrupt, суммарный локальный/внешний трафик, потребленный юзерами сервера, потребление памяти процессом mpd (график доказывает, что в mpd память не течет - мне это важно, так как у меня mpd патченный), использование mbufs, количество дропов в системных очередях и прочее. Нет, эти вещи я выкладывать не буду :-)

[nizam nagiev (from livejournal.com)]

Хочу приобрести, такое же железо что у вас описано. Использоваться будет, практически, для того же. Только я буду использовать ipfw nat + mpd4 + pptp.

Были ли у вас кернель паники? Использовали ли данную конфигурацию под рабочей(реальной нагрузкой)?

[dadv.livejournal.com]

> Только я буду использовать ipfw nat + mpd4 + pptp.

ipfw nat и pptp будут грузить машину сильне

> Были ли у вас кернель паники?

На нынешней 8.2-STABLE при включенном net.isr.direct паники ещё возможны, но крайне редки - какая-то бага сидит, но воспроизводится только при пиковых нагрузках и раз в несколько недель, поэтому поймать сложно.

> Использовали ли данную конфигурацию под рабочей(реальной нагрузкой)?

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

[kan5300.livejournal.com]

- Насколько принципиально наличие ECC памяти для подобных задачь?
- Чем обусловлено отключение HTT?
- По каким причинам не рассматривались шестиядерные версии процессоров Xeon?

[dadv.livejournal.com]

> Насколько принципиально наличие ECC памяти для подобных задачь?

Не принципиально, хотя и повышает надежность. Можно без ECC.

> Чем обусловлено отключение HTT?

Во-первых, мне совершенно непонятно, как мониторить и анализировать загруженность/недогруженность/перегруженность системы с HTT. Сейчас я строю графики нагрузки каждого "честного" ядра прерываниями, ядром и прикладными процессами и четко вижу запас по производительности, всё предсказуемо.

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

> По каким причинам не рассматривались шестиядерные версии процессоров Xeon?

Во-первых, они дороже. Во-вторых, см. выше. Из-за описанных проблем в netisr затруднительно ровно распределять нагрузку на шесть ядер, а на четыре просто. Можно брать более мощные четырехядерные процессоры с пропорциональным увеличением производительности машины.