Вопрос к админам использующим PPTP VPN сервера, под большой нагрузкой.
У меня 5 серверов, debian 2.6.18 патченый под mppe+mppc . Максимальна нагрузка на 1-м сервере - 700 подключений. Сервера - HP DL140 , 1 двухядерный Xeon , 2 гига озу.
Трафик ок 35Мбит на каждом. Процессор загружен на 60-80% . И у меня создаеться впечатление - по графикам, что ограничение по трафику происходит из за ВПН-ов. Больно уж он квадратный, как становиться в 10-11 утра в 160 мбит так и стоит до 24-00. К тому же, после ребута загрузка проца при том же трафике - 10%, и каждый день растет, растет, пока не доходит до 90% и не ребутнешь его. Аптаймы по 6-8 дней.
А теперь собственно вопрос, кто использует какие конфигурации, и какие результаты. Интересно услышать насчет FreeBSD, кто то использует под большой нагрузкой? Только без релегиозных войн - типа фря рулит, линух говно. С цифрами пожалуйста.
>[оверквотинг удален]
>меня создаеться впечатление - по графикам, что ограничение по трафику происходит
>из за ВПН-ов. Больно уж он квадратный, как становиться в 10-11
>утра в 160 мбит так и стоит до 24-00. К тому
>же, после ребута загрузка проца при том же трафике - 10%,
>и каждый день растет, растет, пока не доходит до 90% и
>не ребутнешь его. Аптаймы по 6-8 дней.
>А теперь собственно вопрос, кто использует какие конфигурации, и какие результаты. Интересно
>услышать насчет FreeBSD, кто то использует под большой нагрузкой? Только без
>релегиозных войн - типа фря рулит, линух говно. С цифрами пожалуйста.
>цифры - не цифры - главное во фре то, что там всё ядерное и уменьшается число переключений контекста/копирования блоков памяти, что дает более высокую производительность системы. Кроме того, стабильность системы не требует перезагрузки раз в 6-8 дней ;-)
ИМХО заменой можно получить двукратное повышение производительности.
Собственно что Вам мешает заменить один из пяти серверов на FreeBSD+mpd и попробовать ?
я тоже без цифр
mppc упрать к чертям собачим и не вспоминать о нем больше
это раз
два если нагрузка растёт -- значит есть утечка -- значит не нужно было патчить(использовать ядро и pppd родные).
три могу порекомендовать поставить lenny -- как ВПН сервер он уже стабилен -- точно.
FreeBSD + mpd тоже очень не плохая связка для VPN, но я с некоторых пор полностью мигрировал на DebianP.S. Linux уже довольно давно имеет ядерные pppoe/ppp/l2/ipsec
>[оверквотинг удален]
>mppc упрать к чертям собачим и не вспоминать о нем больше
>это раз
>два если нагрузка растёт -- значит есть утечка -- значит не нужно
>было патчить(использовать ядро и pppd родные).
>три могу порекомендовать поставить lenny -- как ВПН сервер он уже стабилен
>-- точно.
>FreeBSD + mpd тоже очень не плохая связка для VPN, но я
>с некоторых пор полностью мигрировал на Debian
>
>P.S. Linux уже довольно давно имеет ядерные pppoe/ppp/l2/ipsecне заметил в Вашем P.S.-списке ядерного pptp.
Моё имхо подсказывает мне, что реализация впн-pptp-сервера под линуксом средствами poptop (http://poptop.sourceforge.net/) реализована путем взаимодействия двух процессов пользовательского пространства(userspace): pptpd + pppd.
Первый работает с GRE-каналом к пользователю (сокет IP-соединения), второй работает с ppp-сетевым интерфейсом (реализованными, например, модулями ppp_*, в число которых входят ppp_deflate,ppp_mppe которые реализуют компрессию/шифрование траффика на уровне ядра).Между собой два процесса взаимодействуют через PTY (псевдотерминалы). Таким образом передаваемый траффик от VPN-клиента приходит через GRE-сокет, попадает в PPTPD (pptpctrl), оттуда через PTY передается в pppd, пихается в ядро, далее разжимается/декодируется и попадает через сетевой интерфейс ppp в общую схему движения траффика. Ну и в обратную сторону к VPN-клиенту соответственно.
В факах poptop-а на эту тему есть свидетельство в виде ошибок, которые иногда бывают :)
Jun 22 21:48:35 linuxbox pptpd[1900]: GRE: read(fd=5,buffer=804d720,len=8196) from PTY failed: status = -1 error = Input/output error
Jun 22 21:48:35 linuxbox pptpd[1900]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)Ну или если особенно интересно, смотрим функции decaps_gre(), encaps_gre() в pptpgre.c.
==============
Если мы рассмотрим систему MPD - то там все движение траффика происходит через NetGraph-ноды, данные в userspace не копируются. В userspace крутится только процесс, осуществляющий рулежкой построением цепочек движения траффика, принятием/передачей нодам управляющих сообщений. В нодах будет открыт сетевой сокет для GRE-пакетов, будет производиться сжатие/шифрование, передача в ядро для маршрутизации и обратные процессы.Считаю что эта схема передачи траффика эффективнее. Кроме того, не требуется большое число управляющих процессов, что также уменьшает накладные расходы системы.
poptop на данный момент только управляет установкой/остановкой/контролем ppp соединений -- остальное за ядром
>poptop на данный момент только управляет установкой/остановкой/контролем ppp соединений -- остальное за
>ядромВы хотите сказать что я смотрел не в те исходники или использую не тот софт ?
Расскажите мне как pppd умеет сам работать с GRE-сокетами?
>poptop на данный момент только управляет установкой/остановкой/контролем ppp соединений -- остальное за
>ядромЗапустил с клиента (FreeBSD подключается к линуксу с помощью мпд) "ping -f".
В топе резко нарисовался процесс pptpctrl. Интересно, почему это вдруг резко возросло число управляющих пакетов ;-) ?
>>poptop на данный момент только управляет установкой/остановкой/контролем ppp соединений -- остальное за
>>ядром
>
>Запустил с клиента (FreeBSD подключается к линуксу с помощью мпд) "ping -f".
>
>
>В топе резко нарисовался процесс pptpctrl. Интересно, почему это вдруг резко возросло
>число управляющих пакетов ;-) ?не буду повторяться
x:~# ps awux | grep pptpctrl | grep -v grep
x:~#
x:~# lsmod | grep pppppp_mppe 11656 2
ppp_deflate 10496 0
ppp_async 16512 1
crc_ccitt 6656 1 ppp_async
pppoe 19200 0
pppox 8728 1 pppoe
ppp_generic 33448 10 ppp_mppe,ppp_deflate,bsd_comp,ppp_async,pppoe,pppox
slhc 10624 1 ppp_generic
zlib_deflate 24088 2 ppp_deflate,deflate
zlib_inflate 19328 2 ppp_deflate,deflate
>
>не буду повторяться
>
>x:~# ps awux | grep pptpctrl | grep -v grepА я повторюсь: "не заметил в Вашем P.S.-списке ядерного pptp. "
в случае PPTP траффик проходит через юзерспейс. При этом он может расшифровываться/разжиматься на уровне ядра, но тем не менее проходит через юзерспейс.
>[оверквотинг удален]
>
>ppp_generic
>33448 10 ppp_mppe,ppp_deflate,bsd_comp,ppp_async,pppoe,pppox
>slhc
> 10624 1 ppp_generic
>
>zlib_deflate 24088
> 2 ppp_deflate,deflate
>zlib_inflate 19328
> 2 ppp_deflate,deflate
>[оверквотинг удален]
>меня создаеться впечатление - по графикам, что ограничение по трафику происходит
>из за ВПН-ов. Больно уж он квадратный, как становиться в 10-11
>утра в 160 мбит так и стоит до 24-00. К тому
>же, после ребута загрузка проца при том же трафике - 10%,
>и каждый день растет, растет, пока не доходит до 90% и
>не ребутнешь его. Аптаймы по 6-8 дней.
>А теперь собственно вопрос, кто использует какие конфигурации, и какие результаты. Интересно
>услышать насчет FreeBSD, кто то использует под большой нагрузкой? Только без
>релегиозных войн - типа фря рулит, линух говно. С цифрами пожалуйста.
>
>http://tula.bofh.ru/articles/461Читал, и даже делал на одном ВПН
результат, к сожалению 0-й - абсолютно ничего не поменялось. Автор замеряет производительность 1-м клиентом и одной закачкой, а тут 700-800 клиентов, и по 200 тысяч TCP сессий (торренты и пр.) Кстати - l2tp без шифрования дает производительность на 30-40% выше, но проблема перевести на него 15 000 юзеров.
Фрю попробую, конечно, как будет новый сервер.
>
>>http://tula.bofh.ru/articles/461
>
>Читал, и даже делал на одном ВПН
>результат, к сожалению 0-й - абсолютно ничего не поменялось. Автор замеряет
>производительность 1-м клиентом и одной закачкой, а тут 700-800 клиентов, и
>по 200 тысяч TCP сессий (торренты и пр.) Кстати - l2tp
>без шифрования дает производительность на 30-40% выше, но проблема перевести на
>него 15 000 юзеров.
>Фрю попробую, конечно, как будет новый сервер.Правильнее использовать управляемые свичи, D-Link на 24 1Gbit порта за 7000 рублей - это не те деньги, хотя конкретно эта модель свича не удобна в централизованном управлении.
>
>Правильнее использовать управляемые свичи, D-Link на 24 1Gbit порта за 7000 рублей
>- это не те деньги, хотя конкретно эта модель свича не
>удобна в централизованном управлении.Не подходит. Сеть стоилась много лет, во многих старых сегментах, не то что юзер на управляемом порту, а целые кварталы сидят. Реконструкция идет, но не так быстро как хотелось бы. Понятно, что если бы каждый сидел на порту то впн бы нафиг не был нужен. Длинки используем, и телезины и циски. Но нужна общая схема, по этому от впн пока не отказаться.
Когда-то работал на ISP были примерно такие-же проблемы. В итоге после наращивания парка vpn концентраторов на Linux(FreeBSD тоже пробовали), решили посмотреть в сторону cisco, на которой и остались. Да, дороже, но оно того стоило.
>Когда-то работал на ISP были примерно такие-же проблемы. В итоге после наращивания
>парка vpn концентраторов на Linux(FreeBSD тоже пробовали), решили посмотреть в
>сторону cisco, на которой и остались. Да, дороже, но оно того
>стоило.Я только за. Но ..
Типичный ВПН (а ля HP DL140G3) обходиться в 1200 баксов. 700 подключений - 1,7 бакса на юзера. Циско (72хх) - 3000 подключений - 15000 баксов - 5 баксов на юзера.
И не всегда админы решают финансовые вопросы, вы понимаете.
>>Когда-то работал на ISP были примерно такие-же проблемы. В итоге после наращивания
>>парка vpn концентраторов на Linux(FreeBSD тоже пробовали), решили посмотреть в
>>сторону cisco, на которой и остались. Да, дороже, но оно того
>>стоило.
>
>Я только за. Но ..
>Типичный ВПН (а ля HP DL140G3) обходиться в 1200 баксов. 700 подключений
>- 1,7 бакса на юзера. Циско (72хх) - 3000 подключений -
>15000 баксов - 5 баксов на юзера.
>И не всегда админы решают финансовые вопросы, вы понимаете.Но кроме концентратора, Вы получаете много возможностей. Вообщем это как подать это на блюдечке руководству.