Комментарии 31
Ваш способ не сработает если IP пулами заведует RADIUS:
Но можно узнать количество сессий с помощью вот такого скрипта:
[] show ippool
Available IP pools:
poolsat: used 0 of 510
Но можно узнать количество сессий с помощью вот такого скрипта:
#!/usr/local/bin/bash
online=`ifconfig | grep ng | wc -l` echo $online"
exit 0
+1
Ссылка на блог автора повеселила)
+10
Дело в том, что работа скрипта осуществляется на DNS сервере, который не является MPD5 сервером, поэтому вариант с ifconfig не подходит. Кол-во сессий можно еще узнать так:
Среди прочей информации будет значение BUND — количество фактически поднятных ng интерфейсов
http://0.0.0.0:5006/bincmd?show%20mem
Среди прочей информации будет значение BUND — количество фактически поднятных ng интерфейсов
0
Дело в том, что работа скрипта осуществляется на DNS сервере, который не является MPD5 сервером, поэтому вариант с ifconfig не подходит.
Подходит. Если есть ssh доступ к серверу с MPD. У меня так графики загруженности в rrdtool рисуются.
И чем http лучше ssh?
0
Как правило для такого туннелирования используются либо серьезные железки (Cisco, Juniper, etc), либо софт-роутеры на базе FreeBSD и MPD5.
Либо Linux и poptop/accel-pptp/rp-pppoe/accel-ppp
+1
Все это работает в usermode и нету аналога netgraph.
+1
В Linux pppd сотоварищи шибко ущербное решение в сравнении с MPD. Мы это поняли, когда, устав от спорадических зависаний серверов доступа под Debian, преревели их на FreeBSD с MPD. И виснуть перестало и кучу «полезностей» получили.
+1
FreeBSD вообще на мой взгляд лучше в качестве шлюза, роутера, сервера доступа. Таже quagga для BGP чувствует себя на фряхе заметно лучше. Организация работы VLAN просто чудесна по сравнению с Linux. Зато в качестве сервера приложений мне больше нравится Linux, хотя и фря вполне себе со многими задачами справляется.
+1
Дело вкуса. У меня не было проблем с pptpd и pppoed на дебианах.
-2
Подправьте использования grep. Он может напрямую парсить файл.
grep used "$workdir/$ipsrv"
0
у меня балансер находится на днс-сервере и лазит по vpn-ам через ssh с авторизированным ключем. В списке балансера у каждого сервера vpn стоит коэффициент его вычислительной мощности. при опросе серверов выбирается наименее запруженный, который и становится vpn.local
скрипт который выполняется на vpn:
отдаёт: жив ли mpd и сколько текущих сессий
скрипт который выполняется на vpn:
#!/bin/sh
/bin/ps ax | grep -v grep | grep -c mpd5
/usr/bin/netstat -rn | grep -v grep | grep -c ng
отдаёт: жив ли mpd и сколько текущих сессий
0
А почему была необходимость в собственном dns сервере?
0
В свое время стояло 20 разных впн-серверов. Основные моменты в принципе как во всех выше приведенных примерах:
1. у каждого сервера был свой «вес», коэффициент в зависимости от его процессорной мощности (использовались несколько однотипных платформ, так что при установке нового сервера вес бы уже известен)
2. каждый впн-сервер раз в минуту собирал сам некое взвешенное число получаемое из кол-ва своего трафика в pps'ах и кол-ва сессий. Почему только не один из этих параметров, а совокупность? — потому что большое кол-во сессий не всегда прямо пропорционально трафику (допустим сломалась маршрутизация и т.п, и трафика нет, а балансер будет все кидать и кидать сессии на этот сервер). NAS отдавал эти числа по обычному snmp (exec в snmpd.conf на сервере и snmpwalk .1.3.6.1.4.1.2021.8.1.101 на балансере)
По snmp же строились графики онлайна, загрузки, pps
3. TTL для имени впн-сервера был крайне малым — 1-2 минуты, выдавались 4 самых ненагруженных nas'а роунд-робином
для выключения nas'а из балансировки для обслуживания можно было погасить снмп демон на нем.
1. у каждого сервера был свой «вес», коэффициент в зависимости от его процессорной мощности (использовались несколько однотипных платформ, так что при установке нового сервера вес бы уже известен)
2. каждый впн-сервер раз в минуту собирал сам некое взвешенное число получаемое из кол-ва своего трафика в pps'ах и кол-ва сессий. Почему только не один из этих параметров, а совокупность? — потому что большое кол-во сессий не всегда прямо пропорционально трафику (допустим сломалась маршрутизация и т.п, и трафика нет, а балансер будет все кидать и кидать сессии на этот сервер). NAS отдавал эти числа по обычному snmp (exec в snmpd.conf на сервере и snmpwalk .1.3.6.1.4.1.2021.8.1.101 на балансере)
По snmp же строились графики онлайна, загрузки, pps
3. TTL для имени впн-сервера был крайне малым — 1-2 минуты, выдавались 4 самых ненагруженных nas'а роунд-робином
для выключения nas'а из балансировки для обслуживания можно было погасить снмп демон на нем.
0
А что же вы делаете с клиентами, у которых статический ип-адрес?
0
Я про статический ип в инернет. Если раздавать реал, то пуллы закреплять за насами нужно, а они тут балансируют видите ли. Как на практике решаете вопрос статика за разными насами? BGP? proxy arp? Еще что-нибудь
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распределение нагрузки на PPTP/L2TP серверы MPD5