форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Оптимизация и Промышленные системы (Public)
Изначальное сообщение		[ Отслеживать ]

"увеличения масштабируемости VPN-сервера?"		+/–
Сообщение от Luxor (??) on 21-Июл-09, 21:01
Здравствуйте! VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор на кластерную технологию. Опишу что хочу получить в итоге: у всех клиентов единый ip адрес vpn-сервера, vpn-тунели раскидываются между серверами 50 на 50, либо (здорово если так можно) терминировать все тунели будет один логический сервер состоящий из двух физических. Самое главное это - хочу масштабиремость решения, если кластер не справляется - добавить еще один сервер и радоваться жизни. Я вообще не зациклен на кластере - буду рад выслушать все идеи! Можно ли вообще подойти к решению моей задачи с "кластерной" стороны ? Может у кого есть опыт решения таких задач ? Многие интернет-провайдеры используют такой метод аутентификации своих пользователи по vpn pptp, как они решают такую задачу интересно? Единственное что пока придумал это балансирвока средствами DNS - указать два ip адреса на доменное имя и раскидывать будет DNS, но мне этот вариант не нравится ибо будет складываться дисбаланс мжеду серверами потому как у многих в сети установлен не доменное имя сервера а ip-адрес, и не понятно как быть с сетью реальных адресов, непонятно на какой vpn-сервер пограничному маршрутизатору маршрутизировать реальный блок адресов...
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "увеличения масштабируемости VPN-сервера?"		+/–
Сообщение от shadow_alone (ok) on 21-Июл-09, 21:26
>Здравствуйте! >VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор >на кластерную технологию. Я вообще не зациклен на кластере ну и правильно что не зациклены берите нормальный рутер, и на серваке радиус+DB (mysql, postgresql - не суть важно) если очень нагружен, то советую 72 или 73 серию, если средненько, то и 28 серия пойдет.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "увеличения масштабируемости VPN-сервера?"		+/–
	Сообщение от Luxor (??) on 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. Решить проблему можно купив более мощный сервер, а потом когди он не будет справляться опять более мощный сервер. Мне бы хотелось решить эту задачу поднятие дополнительных серверов... так экономически выгоднее :) подскажите пожалуйста что-нибудь в этом направлении.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	4. "увеличения масштабируемости VPN-сервера?"		+/–
	Сообщение от Luxor (??) on 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
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "увеличения масштабируемости VPN-сервера?"		+/–
	Сообщение от Refresh on 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 лучше вынести на выделенный сервер.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

	8. "увеличения масштабируемости VPN-сервера?"		+/–
	Сообщение от Refresh on 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),  то  все  пакеты соединения будут отправляться через    указанный шлюз.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "увеличения масштабируемости VPN-сервера?"		+/–
	Сообщение от Monty (??) on 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-серверов. Если так, то так не молочится, имхо. Ибо тут должны рассматриваться адреса маршрутизаторов или иже с ними. К каком адресу должен по вашему клиент подключаться?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "увеличения масштабируемости VPN-сервера?"		+/–
	Сообщение от Refresh on 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 ЛЮБЫЕ пакеты м/у любыми внутренними серверами. Если я ошибаюсь, поправьте меня.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "увеличения масштабируемости VPN-сервера?"		+/–
Сообщение от chocholl (??) on 04-Авг-09, 15:47
pptp нормально можно раскидывать только slb у циски есть ширпотребные железки для этого, а есть специализированные модули для 6k но будет не дешево.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема