Jump to content
Калькуляторы

в основном из-за билинга, т.к. билинг не может передать в каком вилане будет абонент и в какой сети. accel - в связке с dhcp как понял решит эту проблему, шейпер будет уже выше на nat сервере, куда придут абоненты с 2-х билингов - это как раз lisg (почему нат тут - из-за физического расположения сети + железо производительнее в разы)

Share this post


Link to post
Share on other sites

linx

У ацеля есть свой шейпер, управляемый по радиусу. По идее биллингу все равно.

Смысл еще и lisg в этой схеме теряется, проще вместо него чистый NAT-бокс поставить.

Share this post


Link to post
Share on other sites

у accel-pptpd с шейпером не так все просто, на исходящую скорость нужен ifb если судить по документации http://accel-ppp.org/wiki/doku.php?id=ru:shaperbasic

lisg - по шейперу достаточно расписано и вроде все что нужно есть

 

чистый нат-бокс не получится, хотя бы по той причине что где терминируются пользователи и где поднято bgp с магистралом и сорм географически разнесены, не могу на месте натить хотя бы той причине что нужно дотащить пользователей до зеркала с сормом

 

ps. хотя по-любому придется начинать от обратного т.е. с accel-ppptpd - и если по шейперу не сложится, подниму lisg (в качестве шейпера) на nat-ах

Edited by linx

Share this post


Link to post
Share on other sites

Коллеги, добрый день.

 

Изучаем функционал LISG, собрали последнюю версию, с радиусом завязали.

Возник вопрос, поддерживается ли функционал скачивания сервисов по RADIUSу?

Share this post


Link to post
Share on other sites

Скачивание сервисов по радиусу? Это как?

Ну, то есть сначала проходит запрос на авторизацию сессии, радиус отдает сервисы.

Затем, в случае если ISG не знает сервиса, (не занесен в конфиге), он делает запрос к серверу по этому сервису, и получает в ответ описание.

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

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

Share this post


Link to post
Share on other sites

Кто-нибудь может подсказать как поменять скорость на сервисе или поменять активный сервис без потерь???

 

Если сначала деактивировать сервис, а потом активировать другой, то при этом трафик все-таки теряется.

 

есть какой-нибдь еще вариант???

Share this post


Link to post
Share on other sites

Вроде есть возможность описать неактивный сервис и по CoA активировать его.

 

Такой вопрос:

Стоял LISG, все работало.

В какой то момент (когда именно понять не удается) перестал резать скорость.

Авторизация происходит нормально. А вот скорость не режет.

Куда копать ?

Share this post


Link to post
Share on other sites

А реально ли изменение ограничения скорости шейпера на лету с помощью СоА ? Вроде как автор рекомендует для идентификации сессии использовать 4 атрибута и как бы говорит , что для главной сессии можно использовать Cisco-Account-Info="QU;512;256;D;512;256" .... Однако ограничение скорости сбрасывается лично у меня в ноль , новые параметры шейпера не устанавливаются .

echo User-Name=10.10.14.161,Acct-Session-Id=EEF658C8352559ED,Nas-Port=4,Nas-Identifier="192.168.122.111",Cisco-Account-Info="QU;512;256;D;512;256"|/usr/local/freeradius/bin/radclient -x 10.10.10.2:3799 coa 5678

Может руки кривые ? Ткните носом че не так делаю . С консольки по типу /ISG.pl change_rate <Virtual# | Session-ID> <in_rate out_rate> все замечательно меняется . Уже задумался удаленно по SSH менять параметры очереди , но хочется красиво через СоА .

Share this post


Link to post
Share on other sites

Вопрос по производительности с linux ISG.

Сервер Proliant DL360G5, 1 x Intel® Xeon® CPU E5345 @ 2.33GHz, 4GB RAM.

Сетевки встроенные, две Broadcom Corporation NetXtreme II BCM5708, driver: bnx2 version: 2.0.2

Собраны в бондинг, на бонде висят вланы, в сторону абонентов и на аплинк.

Система Linux isg1 2.6.32-5-amd64 #1 SMP Mon Mar 26 07:00:19 UTC 2012 x86_64 GNU/Linux (знаю что старая, просто долгое время проблем не было, и не трогали :)

Ядро ванильное, особо ничего не тюнили.

lISG-0.11.3-alpha

Дополнительно к ISG машина делает NAT и сливает netflow через ipt_netflow.

Десяток правил проходят пакеты в iptables.

 

Проблема такая. Когда общий трафик через бонд приближается к 1.4G в каждую сторону (например, 1G download + 400M upload у абонентов), резко растет загрузка процессора (число LA). Соответственно, растут пинги, сильно падает скорость у абонов, и прочее. Число абонентов в это время 1.2к, ~110kpps download + 90kpps upload в абонентском влане (соответственно, плюс столько же в аплинке).

Что интересно - если трафик через бонд допустим 1.2G - то LA болтается в районе 0.00 - 0.01.

 

Прерывания поделены вроде:

root@isg1:~# cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3

---

61: 314048990 314088388 313987066 313815289 PCI-MSI-edge eth0

62: 349329762 349279662 349388109 349542114 PCI-MSI-edge eth1

---

Сейчас нагрузка на бонде 650Mbps, top показывает:

Tasks: 98 total, 1 running, 97 sleeping, 0 stopped, 0 zombie

Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 80.4%id, 0.0%wa, 0.0%hi, 19.6%si, 0.0%st

Cpu1 : 0.0%us, 0.7%sy, 0.0%ni, 76.8%id, 0.0%wa, 0.0%hi, 22.5%si, 0.0%st

Cpu2 : 0.3%us, 0.3%sy, 0.0%ni, 75.7%id, 0.0%wa, 0.3%hi, 23.3%si, 0.0%st

Cpu3 : 0.3%us, 0.3%sy, 0.0%ni, 81.7%id, 0.0%wa, 0.0%hi, 17.6%si, 0.0%st

 

Основные пожиратели процессорного времени - ksoftirqd и events.

 

Внимание, вопрос!

Куда бежать? Тюнить ядро? Обновлять ядро?

Покупать нормальную сетевку типа http://shop.nag.ru/catalog/00006.Servery/02273.Setevye-karty/11473.E1G42ET ?

Или расслабиться, и это предел данного сервака?

Edited by seagull

Share this post


Link to post
Share on other sites

Для этого старенького сервера 200к pps и так подвиг можно сказать. Особенно в такой хитрой схеме.

Главная печаль у вас в 2 сетевках и неприбитых прерываниях. Кто сказал что размазать по всем ядрам это правильно?? Это не более чем самообман и иллюзия свободного CPU в топе.

Для начала прибейте прерывания к ядрам на одной пластине, топологию для вашей системы думаю найдете как поглядеть. По топу загрузка разделится менее красиво, но станет реальной и системе полегче будет.

Ну и дальше, поставьте еще одну двухголовую карту и сделайте 2 нормальных бонда, на вход и на выход. Раскидайте 4 сетевки на 4 ядра - сервер вздохнет свободно.

 

2ух головая ET по ссылке вам конечно тоже хорошо поможет, но еще лучше - как я и говорил любая 2ух портовая карта(лучше тот же броадком, или intel PT), что б 4 порта сделать.

Edited by kayot

Share this post


Link to post
Share on other sites

Главная печаль у вас в 2 сетевках и неприбитых прерываниях. Кто сказал что размазать по всем ядрам это правильно?? Это не более чем самообман и иллюзия свободного CPU в топе.

Для начала прибейте прерывания к ядрам на одной пластине, топологию для вашей системы думаю найдете как поглядеть.

Хм, а не будут 2 ядра вхолостую молотить? Сетевки то с одной очередью, только 2 ядра получится занять?

Share this post


Link to post
Share on other sites

seagull

Дык в том то и дело, что сетевки с 1 очередью.

Они и сейчас только 2 ядра занимают, но т.к. вы разрешили использовать все ядра - планировщик постоянно перекидывает обработку прерывания между ядрами, в итоге в 1 момент времени используется 1 ядро на 100%, а кроме того получаем снижение производительности из-за необходимости синхронизации разных CPU и вымывания кешей. Хотя в топе все красиво.

Share this post


Link to post
Share on other sites

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

Вообще, уже по случаю заказали за недорого две таких ЕТ, как по ссылке, так что будем апгрейдится.

А подскажите, как с 4 портами будет оптимальней сконфигурить?

Я так понимаю - 2 бонда - аплинк и даунлинк, к ядру прибиваем RX от аплинка, TX от даунлинка? Бондинг сам по себе тут не будет проблем создавать? Ведь хрен знает, в какой канал у нас пакет прилетит?

 

А вообще интересно - сколько можно выгадать таким шаманством? Единицы процентов? Десятки?

Или собирать мелочь, и покупать что-то вроде http://shop.nag.ru/catalog/02275.Servery-HP/09193.360-G6-380-G6/14979.DL360G6_2xX5650_48GB чтобы уже очереди на 12 ядер раскидывать, а не на 4?

Share this post


Link to post
Share on other sites

4 порта нужно привязать к 4 ядрам естественно. Очереди лучше вообще отключить, оставив 1 сокращённую(совмещенную, Т9) на порт(почему я предлагал дешёвые карты ставить, но если деньги на ЕТ есть - хуже точно не будет).

Выиграть в вашей конфигурации можно раза в 3, чётко будет до 2г дуплекса пролезать.

Edited by kayot

Share this post


Link to post
Share on other sites

kayot, докладываю ситуацию :)

Вчера наблюдал общий трафик на бонде 1.46G.

Соответственно, в влане на абонов - 1.07G/0.4G, 116/85kpps.

LA не поднимался существенно.

 

Для интересующихся - вот что вообще затюнено было:

#CONNTRACK tuning:
echo 524288 > /sys/module/nf_conntrack/parameters/hashsize
echo 524288 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

echo 1024000 > /proc/sys/net/netflow/sndbuf

/sbin/sysctl -w net.core.rmem_default=262144
/sbin/sysctl -w net.core.wmem_default=262144
#
/sbin/sysctl -w net.core.rmem_max=8388608
/sbin/sysctl -w net.core.wmem_max=8388608

ifconfig eth0 txqueuelen 10000
ifconfig eth1 txqueuelen 10000
ethtool -G eth0 rx 1020
ethtool -G eth1 rx 1020
/sbin/sysctl -w net.netflow.hashsize=800000
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=1800
sysctl -w net.netfilter.nf_conntrack_generic_timeout=180
sysctl -w net.netfilter.nf_conntrack_udp_timeout=10
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=60
sysctl -w net.netfilter.nf_conntrack_icmp_timeout=10

echo 4 > /proc/irq/61/smp_affinity
echo 8 > /proc/irq/62/smp_affinity

ethtool -C eth0 rx-usecs 40
ethtool -C eth1 rx-usecs 40

 

Кстати - интересный момент... smp affinity не применился, пока я не сделал для интерфейсов изменение параметров с ethtool...

Share this post


Link to post
Share on other sites

kayot, докладываю ситуацию :)

Вчера наблюдал общий трафик на бонде 1.46G.

Соответственно, в влане на абонов - 1.07G/0.4G, 116/85kpps.

LA не поднимался существенно.

 

Ошибок на интерфейсах тоже нет?

Share this post


Link to post
Share on other sites

Ошибок на интерфейсах тоже нет?

 

Ну сейчас на 12 миллиардов пакетов на одном интерфейсе 512 дропов, на другом 30.

Так что можно сказать - нет...

Share this post


Link to post
Share on other sites

Протестировали модуль на одном из НАТ серверов.

Машинка 2x Intel Xeon E5649, Intel X520-DA2, 8 гигов памяти

 

На сервере запущено:

NAT (1:1 и Overload)

Conntrack

Nfqueue, для фильтрации РКН

ipt_netflow

 

в ЧНН было 9555 сабскрайберных сессий генерящих 6,93+3.69 (10,62Gb/s трафика)@1,58Mpp/s и 816k записей в Conntrack.

 

Модуль простоял двое суток под такой нагрузкой, и судя по всему это предел :(

Как видно из графиков Начиная ~ с 10Gb/s in+out в логи начинаются сыпаться сообщения вида:

[15193462.931241] ipt_ISG: ISG_IS_DYING is set, freeing (ignore this)
[15193464.562432] ipt_ISG: ISG_IS_DYING is set, freeing (ignore this)
[15193538.701591] ipt_ISG: ISG_IS_DYING is set, freeing (ignore this)

И userspace ные

Apr  3 17:09:24 nat-10g-4 kernel: [15192416.117801] ipt_ISG: Lost packet during sending data to listener (err=-11)
Apr  3 17:09:24 nat-10g-4 kernel: [15192416.119128] ipt_ISG: Lost packet during sending data to listener (err=-11)
Apr  3 17:09:24 nat-10g-4 kernel: [15192416.119941] ipt_ISG: Lost packet during sending data to listener (err=-11)
Apr  3 17:09:24 nat-10g-4 kernel: [15192416.120452] ipt_ISG: Lost packet during sending data to listener (err=-11)

И начинает лавинообразно расти загрузка CPU

Мы не смогли посмотреть состояние непосредственно в момент проблемы, но ~ в 23.30

Perf top выглядел следующим образом

11.99%  [kernel]                     [k] _raw_spin_lock_bh
 5.07%  [kernel]                     [k] ipt_do_table
 4.64%  [kernel]                     [k] netflow_target
 4.55%  [kernel]                     [k] _raw_spin_lock
 3.80%  [kernel]                     [k] ____nf_conntrack_find
 3.39%  [kernel]                     [k] ixgbe_clean_rx_irq
 2.99%  [kernel]                     [k] _raw_read_lock

Похоже, архитектура модуля упирается в количество локов, мы пытались крутить параметр nehash_key_len, однако судя по всему он не имеет отношения к локам внутри ipt_isg. Машина у нас конечно не лучшая, 12 не сильно быстрых ядер, да еще и SMP

но тем не менее без ISG, она спокойно жует 15-16Gb/s трафика и кладет в полку интерфейс по входящему направлению без существенных дропов и с 15% запасом по CPU/

С подобной проблемой LOCKов мы сталкивались, когда тестировали модуль IPT_netflow, тогда, силами AABC, его тогда удалось переписать :)

 

Не смотря на не совсем удовлетворительное тестирование модуль нам весьма интересен, и не в ЧНН он работает вполне нормально, и авторизация (нам пришлось переписать User-space часть, т.к. наш биллинг умеет только Cisco command code) и CoA, и L4Redirect.

Нагрузка модуля в нормальном режиме по тестам занимала +10% CPU от packet forwardingа ядра Linux и это на первый взгляд, сильно лучше чем Accel-ppp, который даже без сервисов, просто сожрал 10% CPU чтобы поделить трафик на сессии, и не совсем понятно поддерживает ли accel-ppp полисинг, т. к. шейпер кушает слишком много ресурсов.

 

В связи с этим возникают вопросы, есть ли на текущий момент у модуля мейнтейнер? Интересно было бы переписать модуль под Lockless архитектру с целью увеличения производительности? Или проект уже мертв, и придется писать свое с нуля/таки пилить accel-ppp? Есть некоторое количество финансов, могли бы оплатить время разработчика, организовать стенд для тестирования.

Conntrack.png

CPU.png

Netflow.png

PPS.png

radius.png

Sessions.png

Traff.png

Share this post


Link to post
Share on other sites

В packet forwardingе ядра тоже локи и тоже все довольно печально с производительностью. Так еще и все эти софтинки вместе ну просто очень неоптимальны. Профита будет чуть больше, чем ничего.

Ну реально, чуть-чуть лучше, чуть-чуть хуже - разве от этого что-то изменится?

Если уже вкладывать, то пора это все под netmap переписывать, под современные процессоры.

Edited by ttttt

Share this post


Link to post
Share on other sites

Произвоидительность Линуксового packet forwardingа нам известна :)

Рядом стоит идентичный сервер, делает все тоже самое NAT, Netflow, NFQ но без LISG.

Производительность там хоть и не высокая, но все же вполне линейно масштабируется, и к слову, ipt_netflow после доработок, там кушает всего 3-5%

 

Переписывать сетевой стек на NETMAP, это как минимум другой порядок по объему работ. Учитывая стоимость серверов, главное чтоб софт линейно масштабировался по нагрузки.

Не хотелось бы все переписывать.

CPU.png

PPS.png

traf.png

netflow.png

Share this post


Link to post
Share on other sites

Учитывая стоимость серверов, главное чтоб софт линейно масштабировался по нагрузки.

Не понял этой вашей фразы. Вы тоже согласны, что глупо что-то переписывать ради микро профита? Это как раз о lisg.

А что такое линейное масштабирование софта? Вы же хотите полку чуть-чуть отодвинуть оптимизацией и все, не называл бы это линейной масштабируемостью.

 

Переписывать сетевой стек на NETMAP, это как минимум другой порядок по объему работ.

Шейпер, полисер, классификатор, нэтфлоу и даже НАТ - это задачи, где сетевой стэк ОСи как бы и не нужен совсем. Пространство для оптимизаций просто огромное.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now