Alex's Blog

Возвращаемся к теме нашего софт-концентратора доступа по PPPoE (софт-BRAS) под названием ATLAC (AT Linux Access Concentrator).

Продолжается стресс-тестирование кодовой базы собственно концентрации доступа, тестовая версия концентратора beta7, которая обсуждалась в предыдущих статьях, достигла версии beta9, и была поставлена под серьезную рабочую нагрузку, на которую и рассчитывается.

Подробности - по ссылке "Читать далее".

...

Для начала напомню возможности концентратора. Текущие отмечены знаком "+", те, которые уже разработаны, но еще не до конца сопряжены с концентратором в единый механизм (находятся на этапе интеграции) - знаком "*", те, которые еще предстоит разработать - знаком "-".

[+] Концентрация пользователей по PPPoE - 1024 (и выше, опционально) одновременных сессий пользователей на логический интерфейс (VLAN) - реализовано. В сумме - до 4096 одновременных сессий при 4-ядерном варианте сервера.

[+] Концентрация PPPoE через QinQ - до 4094 QinQ VLAN'ов (можно концентрировать и двойной уровень вложенности - 4094*4094 QinQinQ VLAN'ов) на логический интерфейс (VLAN). Поддержка до 64 основных VLAN.

[+] Управление трафиком каждого абонента PPPoE на базе сервисных групп доступа (разделение по адресам источника/назначения, раздельно на вход и выход). Возможность изменять сервисные группы (и, соответственно, политику трафика) отдельным абонентам "на лету", без разрыва сессий (telnet-интерфейс, в перспективе - UDP-интерфейс). Возможность удаленного разрыва сессий (telnet-интерфейс, в перспективе - UDP-интерфейс). Возможность получения параметров сессий (telnet-интерфейс).

[+] Ограниченно совместимый с Cisco синтаксис ACL для групп доступа, ограниченно совместимые с Cisco параметры сервисных групп SSG/ISG в базе RADIUS (поддерживается до 7 групп политики на абонента, опция Q для контроля трафика - шейпинга).

[+] Интерфейс управления сервисными группами для пользователей (просмотр сервисных групп у подключенных пользователей, установка сервисных групп "на лету" с перезагрузкой параметров шейпера) - реализован.

[+] Учет общего трафика, и трафика сервисных групп (выборочно, необходимость учета задается в параметрах самих групп) на RADIUS-сервер.

[+] Онлайновый сброс статистики по процессорной нагрузке и количеству сессий для мониторинга с помощью Cacti.  В перспективе туда добавится pps/bps для bonding-интерфейса.

[+] Поддержка BGPv4 для приема маршрутов и отдачи маршрутов на подключенных пользователей - реализов.

[+] Распределение нагрузки между несколькими серверами ATLAC. Round-Robin распределение между двумя ATLAC-серверами (разной конфигурации) проверено, и должно работать "из коробки".

[+] Пропускная способность в "типовой конфигурации" (4-ядерный Xeon E5420 @ 2.5GHz, 2Gb, предустановка, аппаратно-программный комплект, включение 2 портами по EtherChannel/LACP) такова: до 250Kpps ("среднестатистических", реальных, пропускаемых в обе стороны пакетов) и 1400Mibps - т.е. порядка 130Kpps и 700Mibps, проходящих сквозь устройство, что сопоставимо с емкостью Cisco 7206G1, при этом загрузка двух обрабатывающих трафик ядер будет составлять порядка 80%. Естественно, возможно увеличение мощности CPU - при этом рост потенциала pps будет практически линейным.

[*] Личный кабинет абонента @Net ATLAC с интегрированной административной панелью - возможностью управления параметрами абонентов, тарифными планами, скоростными характеристиками, получения отчетов по абонентам и группам абонентов. Небольшой API интеграции внешних скоростных акций вида ночного ускорения, "турбо", etc. (внешнее приложение с доступом к БД).

[-] Web-интерфейс управления всеми основными параметрами системы.

---

Если интересна реальная нагрузочная статистика интерфейса ATLAC - вот она (замер произведен с интервалом в секунду, за 27 часов железка прогнала через себя 2.6Тб трафика):

[root@atlac ~]# sleep 1 ; ifconfig bond0 ; sleep 1; ifconfig bond0
bond0     Link encap:Ethernet  HWaddr A:B:C:D:E:F
inet addr:a.b.c.d  Bcast:a.b.c.d  Mask:a.b.c.d
UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
RX packets:5110734944 errors:0 dropped:36359 overruns:0 frame:0
TX packets:4993057284 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:2946943119084 (2.6 TiB)  TX bytes:2899540914951 (2.6 TiB)

bond0     Link encap:Ethernet  HWaddr A:B:C:D:E:F
inet addr:a.b.c.d  Bcast:a.b.c.d  Mask:a.b.c.d
UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
RX packets:5110812784 errors:0 dropped:36359 overruns:0 frame:0
TX packets:4993133673 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:2946987904684 (2.6 TiB)  TX bytes:2899585053221 (2.6 TiB)

Легким вычитанием между двумя статистиками можно получить pps и bps.

---

А теперь к графикам. Из графиков видно, что два ядра прогоняют трафик, а два ядра почти не используются - они заняты только созданием и разрушением сессий, да управлением сервисными группами. На реальной системе эти два ядра будут заняты личным кабинетом и RADIUS-базой, в рабочей же конфигурации эти детальки вынесены на отдельный сервер - так нужно, поскольку BRAS'ов больше, чем один, да и пользовательская емкость приличная.