chuck

dadv


Choose your future

Choose to sysadmin


Previous Entry Share Next Entry
mpd-5.5
chuck
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% :-)


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

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

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

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

(Deleted comment)
Только без ASIC.

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

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

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

(Deleted comment)

Re: Конфиги.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 1
?

Log in

No account? Create an account