Перейти к содержимому
Калькуляторы

Linux-роутер упирается в малую полосу.

Приветствую коллеги!

 

Прошу отозваться и помочь тех, кто маршрутизирует клиентов на Linux-роутерах и имел опыт создания высоконагруженных шлюзов.

 

Мне приходится разгребать ситуацию, оставленную моим предшественником и на многие вопросы "Почему было сделано так, а не иначе?" я ответить не смогу.

 

Однако имеем следующее: Сервер IBM x3250M3 с 1 процессором Xeon на 4 ядра с 4Гб оперативной памяти, 2 двухголовых сетевых карты Intel 9402 (PRO1000).

 

На сервере установлена ESXi 5.1, под ней уже крутятся 2 виртуальных машины-шлюза, сетевые карты объединены в LACP по 2х1G внутрь и наружу.

 

На самом деле таких серверов всего 10 штук и на них в общей сложности крутится 20 образов шлюзов, каждый из которых делает следующее...

 

В качестве ВМ установлена Mageia 3, ядро 3.11.10 (полагаю тот же CentOS), в каждую ВМ подается 4 ядра процессора и 1Гб оперативки, половина из которой свободна.

 

Используется сетевой драйвер как e1000 так и vmxnet3, на проблему это не влияет, как было установлено. Прерывания сетевых карт идут на все ядра проца.

 

На образах ВМ делается роутинг, шейпинг по HTB и sfq, NAT, NetFlow, шейпинг делается на imq-интерфейсах, заворот трафика на них делается по iptables.

 

Как-то примерно так. Теперь о проблеме. Каждая ВМ обрабатывает 300 клиентов внутренней сети eth0 в 1 публичный IP смотрящий наружу с eth1.

 

Максимальная полоса через ВМ, до которой все работает нормально - 150Мбит, потом в системе начинает расти ksoftirqd и LoadAverage, как следствие видимо.

 

При этих 150Мбитах количество используемых conntrack не превышает 30к и вроде бы узких мест в системе нет, но происходит деградация трафика.

 

Полагаю так же, что дело не в правилах шейпинга, т.к. трафик упирается и при его отключении, а imq вероятно были использованы из-за NetFlow.

 

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

 

Спасибо всем, кто отзовется!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно это проблемы виртуализации. Попробуйте без нее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно, но есть под такой же виртуализацией и транскодер, который с ВМ на Debian молотит несколько гигабит трафика без проблем.

При этом там сделан аналогичный LACP через ESXi 5.1 только на 4 порта 1G, и драйвер vmxnet3 используется.

Изменено пользователем Gizmo25

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сколько пакетов в секунду?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В закладке Performance каково значение счетчиков Ready, Idle и Wait для виртуальных машин?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В закладке Performance каково значение счетчиков Ready, Idle и Wait для виртуальных машин?

 

Значение этих счетчиков применительно к CPU или Network ?

 

Сколько пакетов в секунду?

 

А как это в Линуксе посмотреть? :) Уж извините за бездарность.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А что показывает ip addr show dev imq0 (или какой там?)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На образах ВМ делается роутинг, шейпинг по HTB и sfq, NAT, NetFlow, шейпинг делается на imq-интерфейсах, заворот трафика на них делается по iptables.

Небось и классификация иптейблсом? И портянка из 100500 правил? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот так дела обстоят с pps когда все не совсем плохо, вечером сделаю замер еще.

 

pps.sh eth0

TX eth0: 7693 pkts/s RX eth0: 5618 pkts/s

TX eth0: 8122 pkts/s RX eth0: 5378 pkts/s

TX eth0: 8610 pkts/s RX eth0: 6194 pkts/s

TX eth0: 11390 pkts/s RX eth0: 7025 pkts/s

 

pps.sh eth1

TX eth1: 7692 pkts/s RX eth1: 14477 pkts/s

TX eth1: 7430 pkts/s RX eth1: 13719 pkts/s

TX eth1: 5893 pkts/s RX eth1: 10734 pkts/s

TX eth1: 6715 pkts/s RX eth1: 10271 pkts/s

 

pps.sh imq0

TX imq0: 7153 pkts/s RX imq0: 7155 pkts/s

TX imq0: 8421 pkts/s RX imq0: 8451 pkts/s

TX imq0: 7486 pkts/s RX imq0: 7462 pkts/s

TX imq0: 7525 pkts/s RX imq0: 7512 pkts/s

 

pps.sh imq1

TX imq1: 14757 pkts/s RX imq1: 14780 pkts/s

TX imq1: 16419 pkts/s RX imq1: 16488 pkts/s

TX imq1: 14897 pkts/s RX imq1: 14863 pkts/s

TX imq1: 13148 pkts/s RX imq1: 13147 pkts/s

 

 

Gizmo25 (Сегодня, 11:11) писал:

На образах ВМ делается роутинг, шейпинг по HTB и sfq, NAT, NetFlow, шейпинг делается на imq-интерфейсах, заворот трафика на них делается по iptables.

Небось и классификация иптейблсом? И портянка из 100500 правил? :)

 

Вроде бы нет классификации и правила в сетах, ИПтаблес на 1 экран, к счастью :)

 

А что показывает ip addr show dev imq0 (или какой там?)

 

ip addr show dev imq0

22: imq0: <NOARP,UP,LOWER_UP> mtu 16000 qdisc htb state UNKNOWN qlen 11000 link/void

 

ip addr show dev imq1

23: imq1: <NOARP,UP,LOWER_UP> mtu 16000 qdisc htb state UNKNOWN qlen 11000 link/void

Изменено пользователем Gizmo25

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как-то так, только не понимаю, что есть объекты.

 

sq2.jpg

 

Или так:

 

sq22.jpg

Изменено пользователем Gizmo25

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скриншотов не видно.

 

И снова не видно.

 

ERR_CONNECTION_TIMED_OUT

Изменено пользователем smelnik

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проверял с МегаФона снаружи - работает.

http://79.98.9.11/gizmo/sq2.jpg

http://79.98.9.11/gizmo/sq22.jpg

Можно еще по ФТП.

ftp://79.98.9.11/gizmo/sq2.jpg

ftp://79.98.9.11/gizmo/sq22.jpg

Изменено пользователем Gizmo25

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот пошли чудеса.

 

top - 19:35:15 up 14:24, 1 user, load average: 0.65, 7.80, 13.24

Tasks: 88 total, 2 running, 86 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.0%us, 0.4%sy, 0.0%ni, 70.0%id, 0.0%wa, 0.0%hi, 29.6%si, 0.0%st

Mem: 1023348k total, 439768k used, 583580k free, 38856k buffers

Swap: 0k total, 0k used, 0k free, 204148k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

15 root 20 0 0 0 0 S 8 0.0 18:35.82 ksoftirqd/2

3 root 20 0 0 0 0 R 7 0.0 18:18.61 ksoftirqd/0

11 root 20 0 0 0 0 S 7 0.0 16:28.75 ksoftirqd/1

19 root 20 0 0 0 0 S 3 0.0 18:54.70 ksoftirqd/3

 

 

При этом PPS не сильно увеличился.

 

TX eth0: 13647 pkts/s RX eth0: 11270 pkts/s

TX eth0: 12403 pkts/s RX eth0: 10473 pkts/s

TX eth0: 12645 pkts/s RX eth0: 10900 pkts/s

TX eth0: 12084 pkts/s RX eth0: 10379 pkts/s

 

TX eth1: 11148 pkts/s RX eth1: 13751 pkts/s

TX eth1: 10755 pkts/s RX eth1: 13718 pkts/s

TX eth1: 11783 pkts/s RX eth1: 14404 pkts/s

TX eth1: 11982 pkts/s RX eth1: 14562 pkts/s

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно это проблемы виртуализации. Попробуйте без нее.

 

+1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подготовили железку без гипервизора, завтра перенесем один из образов на нее и понаблюдаем.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В порядке бреда, посмотрите что будет по gzip -dc /proc/config.gz | grep CONFIG_HZ

 

Помню напоролся на нечто похожее по симптомам, а оказалось, что ядро собрано с CONFIG_HZ_250 и CPU тупо не успевал разгребать очередь с сетевухи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В порядке бреда, посмотрите что будет по gzip -dc /proc/config.gz | grep CONFIG_HZ

 

Помню напоролся на нечто похожее по симптомам, а оказалось, что ядро собрано с CONFIG_HZ_250 и CPU тупо не успевал разгребать очередь с сетевухи.

 

Тут вот так:

# CONFIG_HZ_PERIODIC is not set

CONFIG_HZ_100=y

# CONFIG_HZ_250 is not set

# CONFIG_HZ_300 is not set

# CONFIG_HZ_1000 is not set

CONFIG_HZ=100

 

По совету smelnik разделил ядра пополам на ВМ посредством Scheduling Affinity во вкладке Resources.

Стало несколько лучше, продолжаем исследования.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я столкнулся с похожим. Трафик выше 150 не прыгал. Полоса использовалась на полную только в том случае, если нет pppoe сессий.

В итоге ушел с виртуалки на физическую железку. Пока мониторю, но сдвиги явно на "лицо". За 2 дня ниодного разгневаного звонка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А я похоже решил проблему, как по части виртуализации, так и по части оптимизации роутера.

 

Чуть позже напишу пост в помощь, может кому пригодиться.

 

Спасибо всем откликнувшимся, в особенности smelnik!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

# CONFIG_HZ_PERIODIC is not set

CONFIG_HZ_100=y

# CONFIG_HZ_250 is not set

# CONFIG_HZ_300 is not set

# CONFIG_HZ_1000 is not set

CONFIG_HZ=100

 

Хм... С такими параметрами и с виртуализацией у вас клиенты всякими танчикам еще не задолбали? На ровном месте даете +3-7мс пинга на каждом хопе. Вряд ли у вас роутер на каком-нибудь K6-200, уже давно актуальны CONFIG_HZ_1000=y CONFIG_HZ=1000

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Странно, по идее HZ указывает на частоту переключения между потоками планировщиком, а прерывания они независимо от этого должны отрабатывать, если не используется поллинг сетевух.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Gizmo25 (06 ноября 2015 - 21:57) писал:

# CONFIG_HZ_PERIODIC is not set

CONFIG_HZ_100=y

# CONFIG_HZ_250 is not set

# CONFIG_HZ_300 is not set

# CONFIG_HZ_1000 is not set

CONFIG_HZ=100

 

Хм... С такими параметрами и с виртуализацией у вас клиенты всякими танчикам еще не задолбали? На ровном месте даете +3-7мс пинга на каждом хопе. Вряд ли у вас роутер на каком-нибудь K6-200, уже давно актуальны CONFIG_HZ_1000=y CONFIG_HZ=1000

 

Спасибо за подсказку! То есть в данной случае больше = лучше для роутера?

 

У нас процессоры сейчас Xeon X3430 используются, но работают не пределе.

 

Прибавления лишних ms замечено не было ни разу и жалоб у многотысячных абонентов нет.

 

Вероятно учтем данный критерий при обновлении ПО с ядром на роутерах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Странно, по идее HZ указывает на частоту переключения между потоками планировщиком, а прерывания они независимо от этого должны отрабатывать, если не используется поллинг сетевух.

 

HTB шейпит трафик, то есть задерживает пакеты, то есть откладывает посылку пакетов на будущее, то есть ждёт события от таймера

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

HTB шейпит трафик, то есть задерживает пакеты, то есть откладывает посылку пакетов на будущее, то есть ждёт события от таймера

Угу, но не того которому HZ задается :) Юзаются TSC/HPET. А системный таймер на свежих ядрах вообще может гаситься (tickless ядро, да).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.