URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID13
Нить номер: 591
[ Назад ]
Исходное сообщение
"увеличения масштабируемости VPN-сервера?"
Отправлено Luxor , 21-Июл-09 21:01 
Здравствуйте!
VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор на кластерную технологию.
Опишу что хочу получить в итоге: у всех клиентов единый ip адрес vpn-сервера, vpn-тунели раскидываются между серверами 50 на 50, либо (здорово если так можно) терминировать все тунели будет один логический сервер состоящий из двух физических. Самое главное это - хочу масштабиремость решения, если кластер не справляется - добавить еще один сервер и радоваться жизни.
Я вообще не зациклен на кластере - буду рад выслушать все идеи! Можно ли вообще подойти к решению моей задачи с "кластерной" стороны ? Может у кого есть опыт решения таких задач ? Многие интернет-провайдеры используют такой метод аутентификации своих пользователи по vpn pptp, как они решают такую задачу интересно?

Единственное что пока придумал это балансирвока средствами DNS - указать два ip адреса на доменное имя и раскидывать будет DNS, но мне этот вариант не нравится ибо будет складываться дисбаланс мжеду серверами потому как у многих в сети установлен не доменное имя сервера а ip-адрес, и не понятно как быть с сетью реальных адресов, непонятно на какой vpn-сервер пограничному маршрутизатору маршрутизировать реальный блок адресов...

Содержание
Сообщения в этом обсуждении
"увеличения масштабируемости VPN-сервера?"
Отправлено shadow_alone , 21-Июл-09 21:26 
>Здравствуйте!
>VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор
>на кластерную технологию. 

Я вообще не зациклен на кластере

ну и правильно что не зациклены
берите нормальный рутер, и на серваке радиус+DB (mysql, postgresql - не суть важно)
если очень нагружен, то советую 72 или 73 серию, если средненько, то и 28 серия пойдет.
"увеличения масштабируемости VPN-сервера?"
Отправлено Luxor , 22-Июл-09 00:15 
>>Здравствуйте!
>>VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор
>>на кластерную технологию.
>
>
Я вообще не зациклен на кластере
>ну и правильно что не зациклены
>берите нормальный рутер, и на серваке радиус+DB (mysql, postgresql - не суть
>важно)
>если очень нагружен, то советую 72 или 73 серию, если средненько, то
>и 28 серия пойдет.

Не совсем понял идею, у меня HP DL380 G5 2 двухядерных Xeon-а 3 GHz серии 5160, 4 гига   фирменной оперативки от HP, на нем уже все поднято и работает. Конкретно на нем поднят mpd, ОС FreeBSD 7.0. Сервер вянет когда количество тунелей переваливает за 1200.
Решить проблему можно купив более мощный сервер, а потом когди он не будет справляться опять более мощный сервер. Мне бы хотелось решить эту задачу поднятие дополнительных серверов... так экономически выгоднее :) подскажите пожалуйста что-нибудь в этом направлении.

"увеличения масштабируемости VPN-сервера?"
Отправлено shadow_alone , 22-Июл-09 00:28 
Я и подсказываю именно в этом направлении.
Был когда-то П4 2,2 1Г памяти, на нем были подключены порядка 140-150 юзеров(pptp - mschap2) (Linux)
Стал загибаться, решил тож делать кластер - слава Богу, умные люди подсказали в свое время не париться и взять 2811 с крипто модулем. Мискл и радиус оставил на серваке, со временем, поменял её на 7306, сейчас порядка 1000 юзеров +12 туннелей ipsec
всё работает без проблем - зачем изобретать велосипед, когда уже есть ДВС :)
"увеличения масштабируемости VPN-сервера?"
Отправлено Luxor , 22-Июл-09 10:20 
>Я и подсказываю именно в этом направлении.
>Был когда-то П4 2,2 1Г памяти, на нем были подключены порядка 140-150
>юзеров(pptp - mschap2) (Linux)
>Стал загибаться, решил тож делать кластер - слава Богу, умные люди подсказали
>в свое время не париться и взять 2811 с крипто модулем.
>Мискл и радиус оставил на серваке, со временем, поменял её на
>7306, сейчас порядка 1000 юзеров +12 туннелей ipsec
>всё работает без проблем - зачем изобретать велосипед, когда уже есть ДВС
>:)

Нашему пограничному маршрутизатору Cisco 7206VXR NPE-G2 и так немного осталось (по вечерам загрузка 70%), перенести на него VPN это подписать ему смертный приговор. Вообще раньше когда пользователей было немного 7206 выполняла функции и VPN-а и NAT, с увеличением числа пользователей пришлось перекинуть на отдельный сервер VPN и NAT, и вот сейчас опять же из-за увеличения числа пользователей необходимо как-то решить проблему с повышенной загрузкой сервера терминирующего VPN, денег купить супермощный сервер сейчас нет, но купить сервер такой же по мощности как существующий возможность есть... есть ли все-таки варианты с распредлением нагрузки между двумя серверами работающими под одним ip

"увеличения масштабируемости VPN-сервера?"
Отправлено Refresh , 22-Июл-09 12:03 
>[оверквотинг удален]
>
>Нашему пограничному маршрутизатору Cisco 7206VXR NPE-G2 и так немного осталось (по вечерам
>загрузка 70%), перенести на него VPN это подписать ему смертный приговор.
>Вообще раньше когда пользователей было немного 7206 выполняла функции и VPN-а
>и NAT, с увеличением числа пользователей пришлось перекинуть на отдельный сервер
>VPN и NAT, и вот сейчас опять же из-за увеличения числа
>пользователей необходимо как-то решить проблему с повышенной загрузкой сервера терминирующего VPN,
>денег купить супермощный сервер сейчас нет, но купить сервер такой же
>по мощности как существующий возможность есть... есть ли все-таки варианты с
>распредлением нагрузки между двумя серверами работающими под одним ip

Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности БД юзеров и RADIUS лучше вынести на выделенный сервер.

"увеличения масштабируемости VPN-сервера?"
Отправлено егерь , 22-Июл-09 12:25 
>[оверквотинг удален]
>>денег купить супермощный сервер сейчас нет, но купить сервер такой же
>>по мощности как существующий возможность есть... есть ли все-таки варианты с
>>распредлением нагрузки между двумя серверами работающими под одним ip
>
>Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних
>IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку
>не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете
>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете
>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности
>БД юзеров и RADIUS лучше вынести на выделенный сервер.

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

"увеличения масштабируемости VPN-сервера?"
Отправлено Luxor , 22-Июл-09 15:52 
>[оверквотинг удален]
>>Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних
>>IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку
>>не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете
>>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете
>>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности
>>БД юзеров и RADIUS лучше вынести на выделенный сервер.
>
>ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с
>другим ip ? даже не знал что так можно, а можете
>примерчик  примерный показать ?

Refresh не томите :) расскажите как перенаправить установку соединения с другим VPN-сервером с помощью ipfw

"увеличения масштабируемости VPN-сервера?"
Отправлено Refresh , 23-Июл-09 17:52 
>[оверквотинг удален]
>>>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете
>>>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности
>>>БД юзеров и RADIUS лучше вынести на выделенный сервер.
>>
>>ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с
>>другим ip ? даже не знал что так можно, а можете
>>примерчик  примерный показать ?
>
>Refresh не томите :) расскажите как перенаправить установку соединения с другим VPN-сервером
>с помощью ipfw

http://www.opennet.me/base/net/ipfw_balance.txt.html

Я бы попробовал вот отсюда кусок:

В  ipfw тоже есть возможность реализовать нечто подобное, но на другом
   принципе.  Здесь  в правило можно включить опцию prob N, где N - число
   от   0   до  1,  указывающее  вероятность,  с  которой  правило  будет
   применяться  к  пакетам,  подходящим  по остальным критериям. В паре с
   действием skipto можно попробовать реализовать нечто подобное:

           ipfw add 500 check-state
           ipfw add 1000 prob 0.4 skipto 2000 ip from any to any in via ed0
           ipfw  add  1500  fwd  10.0.1.1  ip  from  192.168.0.0/24  to  any out keep-state
           ipfw  add  2000  fwd  10.1.1.1  ip  from  192.168.0.0/24  to  any out keep-state


   Правило  1000,  имея в своём составе опцию prob 0.4, будет выполняться
   для   всех  исходящих  пакетов  (с  точки  зрения  пользователей;  для
   FreeBSD-шлюза  это будут входящие пакеты на внутреннем интерфейсе, что
   и  отражается  опциями  in  via  ed0)  с  вероятностью  40%.  Эти  40%
   "счастливчиков" будут перебрасываться на правило 2000, которым будут
   отправляться  в  шлюз  интерфейса  rl1  (хотя,  поскольку  это шлюз по
   умолчанию, можно было бы ограничиться действием allow). Оставшиеся 60%
   пакетов  продолжат свой путь и правилом 1500 будут переброшены на шлюз
   интерфейса  rl0.  Важной  особенностью  здесь  является  наличие опций
   keep-state  -  благодаря им под "пробу" будет попадать только первый
   пакет устанавливаемого соединения, а все остальные пакеты подпадут под
   действие  правила  check-state, которое должно быть указано до правила
   skipto, чтобы избежать "разрыва" уже установленной сессии. Поскольку
   динамические  правила  сохраняют  первоначальное  действие  (в  данном
   случае  forward),  то  все  пакеты соединения будут отправляться через
   указанный шлюз.

"увеличения масштабируемости VPN-сервера?"
Отправлено Monty , 23-Июл-09 22:47 
>[оверквотинг удален]
>add 500 check-state
>           ipfw
>add 1000 prob 0.4 skipto 2000 ip from any to any
>in via ed0
>           ipfw
> add  1500  fwd  10.0.1.1  ip  
>from  192.168.0.0/24  to  any out keep-state
>           ipfw
> add  2000  fwd  10.1.1.1  ip  
>from  192.168.0.0/24  to  any out keep-state

В качестве 10.0.1.1 и 10.1.1.1 вы рассматриваете IP-адреса VPN-серверов. Если так, то так не молочится, имхо. Ибо тут должны рассматриваться адреса маршрутизаторов или иже с ними.
К каком адресу должен по вашему клиент подключаться?

"увеличения масштабируемости VPN-сервера?"
Отправлено Refresh , 24-Июл-09 17:54 
>[оверквотинг удален]
>> add  1500  fwd  10.0.1.1  ip  
>>from  192.168.0.0/24  to  any out keep-state
>>           ipfw
>> add  2000  fwd  10.1.1.1  ip  
>>from  192.168.0.0/24  to  any out keep-state
>
>В качестве 10.0.1.1 и 10.1.1.1 вы рассматриваете IP-адреса VPN-серверов. Если так, то
>так не молочится, имхо. Ибо тут должны рассматриваться адреса маршрутизаторов или
>иже с ними.
>К каком адресу должен по вашему клиент подключаться?

То где это делается - назовем интернет-сервер.. На нем fwd может перенаправить ЛЮБЫЕ подключения, в том числе и внешние, на ЛЮБОЙ интерфейс, в том числе и на внутренний (при настроенном NAT-е). Если мне не изменяет память fwd тупо перезаписывает заголовок пакета в цепочке.. Поэтому разместив данную конструкцию выше NAT, Вы сможете разрулировать с вероятностью prob ЛЮБЫЕ пакеты м/у любыми внутренними серверами. Если я ошибаюсь, поправьте меня.

"увеличения масштабируемости VPN-сервера?"
Отправлено chocholl , 04-Авг-09 15:47 
pptp нормально можно раскидывать только slb
у циски есть ширпотребные железки для этого, а есть специализированные модули для 6k
но будет не дешево.