VPN servers MPD и большая нагрузка

[evb_work]

Есть группа одинаковых серверов VPN (Xeon 3.2 Ghz, 2 Gb RAM), на которые баллансируется и приземляется большое количество VPN сессий.

 

При достижении определённого количества VPN сессий и транзитного трафика через сервер порядка 25-30 мегабит, VPN клиенты начинают замечать замедление работы в сети. При детальном рассмотрении проблемы оказалось, что появляются лаги даже при пинговании интернет шлюза, стоящего сразу за NATом VPN серверов.

 

Есть подозрение, что проблема либо в NAT, либо в самом mpd. В пиковые часы на каждый из серверов приземляется порядка 600-800 сессий. У кого-нибудь есть опыт работы с подобной системой при подобной нагрузке?

 

Используемое на серверах ПО: FreeBSD 6.1 SMP, mpd 4.2 current, ipnat, flowtools, ipfw.

Сетевые карты интегрированные (myk и em), одна карта смотрит в локальную сеть, вторая на интернет шлюз.

[jab]

polling включен ? что в ipfw ?

 

С mpd4 в подобных конфигурациях никаких проблем не замечено.

[anclbob]

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

Вообщем перевёл пол месяца назад всех 70 челов на ВПН, и один чел жалуется что у него рывками работет прога для купли продажи ценных бумаг, сначала как бы виснет инет, потом прорывается и так всё время что это может быть?

вот конфиг

стандартная его часть

pptp_standart:

set bundle disable multilink

set bundle max-logins 1

set iface disable on-demand

set iface enable proxy-arp

set iface idle 0

set iface enable tcpmssfix

set link no pap chap

set link enable chap

set link keep-alive 10 60

set link max-redial -1

set link mtu 1460

set ipcp ranges 192.168.1.100/32 192.1.0.0/16

set ipcp dns 192.168.1.100

set ipcp yes vjcomp

set pptp disable windowing

set bundle yes crypt-reqd

set bundle enable compression

set link yes acfcomp protocomp

set ccp yes mppc

set ccp yes mpp-e40

set ccp yes mpp-e128

set ccp yes mpp-stateless

set pptp self 192.168.1.100

set pptp enable incoming

set pptp disable originate

[GateKeeper]

set ccp yes [что-бы-то-ни-было] - как правило основная проблема на больших потоках. Оградить от перехвата можно и более другими средствами (влан на пользователя), а шифровать сессию - себе дороже.

 

ну и второе: хотелось бы видеть вывод:

# iostat -c 2 -t proc | tail -n 1

# uptime | cut -d ":" -f 2

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

[anclbob]

ой это наверное ответ не мне... но всё же сделал вот что выдало

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

server# iostat -c 2 -t proc | tail -n 1

0 0 67 0 33 1 0

server# uptime | cut -d ":" -f 2

13PM up 1 day, 13

 

это норма?

[evb_work]

polling включен ? что в ipfw ?

 

С mpd4 в подобных конфигурациях никаких проблем не замечено.

polling пока не включали.

 

в ipfw:

1) allow tcp 1723 from / to me;

2) allow gre from / to me;

3) allow icmp from / to me;

4) deny all;

5) divert трафика в netflow колектор;

6) pipe'ы для пользователей с разными скоростями по тарифу.

Собственно вся конфигурация...

[jab]

То есть 800 пайпов, нат, нетфлоу, mpd, без поллинга и все на одном

дохлом Xeon'е c непонятно каким Marvell'ом ? Еще небось в mpd

включена компрессия с шифрацией ? И скорее всего еще что-то не

упомянули, под что бралось 2 гига памяти ?

 

А вы уверены что при пинговании клиентами шлюза - пакеты ходят мимо

этих Ваших пайпов ?

[evb_work]

То есть 800 пайпов, нат, нетфлоу, mpd, без поллинга и все на одном

дохлом Xeon'е c непонятно каким Marvell'ом ? Еще небось в mpd

включена компрессия с шифрацией ? И скорее всего еще что-то не

упомянули, под что бралось 2 гига памяти ?

 

А вы уверены что при пинговании клиентами шлюза - пакеты ходят мимо

этих Ваших пайпов ?

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

 

Включили поллинг на паре серверов - посмотрим что будет вечером. Проблема в том, что myk сетевые карты поллинг не умеют - придётся втыкать туда интелы, если дело окажется на самом деле в поллинге.

[jab]

Во-первых:

 

vmstat -i покажите

 

Во-вторых - Вы так и не сказали, ходит ли icmp мимо пайпов ?

[evb_work]

Во-первых:

 

vmstat -i покажите

 

Во-вторых - Вы так и не сказали, ходит ли icmp мимо пайпов ?

irq16: myk0 3831355 721

irq17: em0 52387 9

irq18: atapci1 34270 6

cpu0: timer 10568944 1989

cpu1: timer 10568694 1989

Total 25055650 4716

 

Да, конечно, icmp идёт через pipe'ы, если у людей тарифный план с зашейпленной скоростью.

Но даже при не занятом vpn канале, когда шейпинг не работает, есть проблемы с задержками icmp.

 

Во-первых:

 

vmstat -i покажите

 

Во-вторых - Вы так и не сказали, ходит ли icmp мимо пайпов ?

irq16: myk0 3831355 721

irq17: em0 52387 9

irq18: atapci1 34270 6

cpu0: timer 10568944 1989

cpu1: timer 10568694 1989

Total 25055650 4716

 

Да, конечно, icmp идёт через pipe'ы, если у людей тарифный план с зашейпленной скоростью.

Но даже при не занятом vpn канале, когда шейпинг не работает, есть проблемы с задержками icmp.

Да, vmstat снят с машинке, которую ребутнули полчаса назад. Вот с другой машины (uptime 5 days)

 

interrupt total rate

irq1: atkbd0 16 0

irq6: fdc0 3 0

irq14: ata0 2223758 5

irq20: fxp0 1209677646 2792

irq23: em0 1770176795 4086

cpu0: timer 866320061 2000

cpu3: timer 866321140 2000

cpu1: timer 866323245 2000

cpu2: timer 866314577 2000

Total 6447357241 14884

[jab]

Пустите icmp первым правилом ipfw для очистки совести.

 

И покажите кусок vmstat -w1 во время пиковой нагрузки.

[evb_work]

Пустите icmp первым правилом ipfw для очистки совести.

 

И покажите кусок vmstat -w1 во время пиковой нагрузки.

С совестью и так всё в порядке, но лаги интернета при пиковой загрузке - налицо :(

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

[jab]

А Вы уверены что там именно 20-30 мегабит ? Сколько это в pps ?

[evb_work]

А Вы уверены что там именно 20-30 мегабит ? Сколько это в pps ?

Трафик там получается практически симметричный - в пики до 25 мегабит in/out, т.е всего в единицу времени - 50 мегабит.

[jab]

Все-равно это небольшая нагрузка для mpd. Тут скорее надо смотреть в сторону ipnat и ipfw.

[mr.Scamp]

Поставьте обе карточки em и включите поллинг, отключите компрессию впн.

Поллинг разгрузит машины по интерапту.

Компрессия на езернет-линках бесполезна и только загружает попусту процессор, её надо отключить :)

[Pterodaktil]

первым делом, ipfw add 1 pass all from any to any

Смотреть. Если нагрузка упадет, то переписываем грамотно правила.

Вообще нат надо с машинки убрать. Не правильно это.

Пишите что получится.

[anclbob]

Подскажите а что мне в своём конфиге, который вторым сообщением, убрать? что там лишнее?

[anclbob]

и ещё одна проблема возникла! нужно что бы например 2-3 человека подключались по одному и тому же логину и паролю! как это решить? что бы у них соответственно был одинаковый ИП, который выдатся при подключении! такое возможно?

 

ну и подскажите ПЛЗ что всё таки можно убрать отсюда лишнего что бы вообще не нагружало ничего и инет вылетал пулей

set bundle disable multilink

set bundle max-logins 1

set iface disable on-demand

set iface enable proxy-arp

set iface idle 0

set iface enable tcpmssfix

set link no pap chap

set link enable chap

set link keep-alive 10 60

set link max-redial -1

set link mtu 1460

set ipcp ranges 192.168.1.100/32 192.1.0.0/16

set ipcp dns 192.168.1.100

set ipcp yes vjcomp

set pptp disable windowing

set bundle yes crypt-reqd

set bundle enable compression

set link yes acfcomp protocomp

set ccp yes mppc

set ccp yes mpp-e40

set ccp yes mpp-e128

set ccp yes mpp-stateless

set pptp self 192.168.1.100

set pptp enable incoming

set pptp disable originate

Edited November 10, 2006 by anclbob

[anclbob]

ну подскажите!!! на скайпе исходящий трафик плохо проходит! рывками какими то!, трейдерские проги тормозят ну посмотрите! НУ ПЛЗ!!!!

[Blackmore]

set bundle disable multilink <

set bundle enable compression <<< вот сюда посмотри

$ man mpd <

 

ты уже большой мальчик и умеешь читать

[anclbob]

ага ага компресию отключил и шифрование убрал...

будем тестировать

[evb_work]

Все-равно это небольшая нагрузка для mpd. Тут скорее надо смотреть в сторону ipnat и ipfw.

Сейчас на сервере 607 vpn сессий.

 

last pid: 58630; load averages: 2.25, 2.84, 2.90 up 0+11:30:41 23:17:17

78 processes: 6 running, 56 sleeping, 16 waiting

CPU states: 4.5% user, 0.0% nice, 13.3% system, 32.3% interrupt, 49.9% idle

 

# vmstat -w1

procs memory page disks faults cpu

r b w avm fre flt re pi po fr sr ad4 ad6 in sy cs us sy id

1 0 1 113336 1514080 357 0 0 0 319 0 0 0 43556 1812 13197 6 37 58

0 0 0 113336 1514080 60 0 0 0 98 0 4 0 41754 672 12130 8 42 50

1 0 0 113336 1514056 17 0 0 0 116 0 6 0 45717 2289 12954 4 46 50

0 0 0 113336 1514032 4 0 0 0 84 0 2 0 44865 877 19034 6 44 50

0 0 0 113336 1514016 5 0 0 0 58 0 29 0 43720 754 28167 4 46 50

1 0 0 113336 1513752 807 0 0 0 906 0 0 0 43147 4077 10653 9 41 50

1 0 0 113336 1514040 1199 0 0 0 881 0 4 0 44956 2481 12382 9 41 50

 

Загрузка интерфейсов - 23mbit/s in / 15mbit/s out (nload)

 

Визуально наблюдаются тормоза с подключением VPN соединения (от 10 до 30 секунд) и медленно работает интернет через сервер.

 

Сегодня включили polling на обе сетевухи и выключили гипертрейдинг.

Можно что-то ещё покрутить в плане тюнинга поллинга и/или сетевой подсистемы? Или всё таки убирать нафиг NAT с этих машин?

[GateKeeper]

Я так понимаю, divert у Вас на демон, экспортирующий нетфлоу? М.б. избавиться от диверта и применить ng_netflow? Стопудово издержки на userspace исчезнут.

[evb_work]

Я так понимаю, divert у Вас на демон, экспортирующий нетфлоу? М.б. избавиться от диверта и применить ng_netflow? Стопудово издержки на userspace исчезнут.

у нас диверт на ng_netflow