Alex's Blog

Давно не писал в блог по поводу разработки концентратора ATLAC. Пришло время сделать некоторый отчет по разработке.

Вначале о сроках. Разработка несколько затягивается. В основном не из-за наличия сложностей, а из-за серьезного прогресса в отдельных аспектах. И появившиеся/планируемые нововведения действительно стоят того, чтобы затянуть разработку на несколько месяцев.

Вкратце о нововведениях:

1. Ядро ATLAC обновлено, портирован весь набор проприетарных патчей к ядру и системе, в стабильное ядро бэкпортированы некоторые патчи, повышающие стабильность и производительность. Модульный патч концентратора QinQ вышел из стадии beta, и теперь в стадии rc.

2. Производительность концентратора благодаря нововведениям повышена в 2-3 раза, конкретные данные и графики - под ссылкой "Читать далее". Теперь предполагаемая емкость концентратора - до 300 Kpps "проходящего" трафика (т.е. до 600 Kpps с учетом обоих направлений), до 2 Gbps (4 Gbps) - т.е. wirespeed для двух интерфейсов.

3.  Появилась поддержка L4R (layer 4 redirect) - теперь можно отправлять "проштрафившихся" пользователей на конкретный сервер вместо любого, ими запрошенного.

4.  Планируется к поддержке NAT на базе пулов NAT. Естественно, включение NAT будет несколько снижать производительность концентратора, но не радикально. Тем, кому нужен NAT прямо на концентраторе - это пригодится.

5. Планируется к поддержке концентрация PPTP, однако производительность концентрации PPTP будет сильно ниже, чем производительность концентрации PPPoE.

6. Планируется к поддержке концентрация IPoQinQ (IP поверх QinQ), но без возможности управления трафиком ("чистая" терминация - сквозной роутинг) с возможностью раздачи адресов клиентам через DHCP. К сожалению, поддержка шейперов и прочего управления трафиком при концентрации IPoQinQ пока даже не планируется - она сопряжена с чисто техническими сложностями.

7. Система управления ATLAC будет построена на системе кластерной конфигурации DCAS,  которая в данный момент находится в разработке. Т.е. Вы сможете централизованно управлять целым кластером ATLAC через общий интерфейс управления.

Дополнительные детали - по ссылке "читать далее".

...

Итак, рассмотрим некоторые из указанных нововведений в деталях.

1. Ядро. В ATLAC теперь используется новое ядро с определенным набором патчей, повышающих стабильность и производительность системы. По поводу "чистоты кода": все патчи, кроме проприетарных, можно найти на kernel.org в GIT - это бэкпорты; проприетарные же патчи мной оформлены в виде бинарных модулей, компилируемых отдельно от ядра, и открыты не будут. К сожалению, обкатка нового ядра будет завершена только к концу 2010 года. За это время, надеюсь, будет окончательно завершена и система управления.

---

2. Производительность. Это самый интересный аспект в отчете. В прошлой статье я публиковал графики статистики и расчеты производительности концентратора. Напомню:

В "типовой конфигурации" (4-ядерный Xeon E5420 @ 2.5GHz, 2Gb, включение 2 портами по EtherChannel/LACP): до 250Kpps ("среднестатистических", реальных, пропускаемых в обе стороны пакетов) и 1400Mibps - т.е. порядка 130Kpps и 700Mibps, проходящих сквозь устройство.

Если внимательно взглянуть на графики в предыдущей статье - то видно, что пропускание трафика нагружало только два ядра процессора, по числу сетевых адаптеров. При ~70 Kpps проходящего трафика нагрузка одного из ядер составила более 50%, что автоматически подразумевало порог в 130 Kpps.

Сейчас ситуация изменилась кардинально. Предлагаю взглянуть на следующие графики:

Статистика снята с  "живого" концентратора (концентраторов в кластере стало больше, поэтому число сессий меньше, чем в старой статистике).

Суммарная нагрузка CPU на прогон трафика (красная секция графика) примерно та же, что и в старой статистике - порядка 20% в пике - но это весьма обманчивое впечатление. Почему - смотрите дальше.

Итак, через концентратор проходит в пике не 350 Mbps, как в прошлой статистике, а порядка 500 Mbps. Т.е. даже в абсолютной величине загрузки процессора производительность концентратора увеличилась. Но это не самое главное.

Наконец-то я могу представить статистику по Kpps. Теперь можно наглядно видеть загрузку процессора от числа проходящих Kpps. Как видим - через концентратор проходит порядка 80 Kpps, при этом загрузка процессора под прогон трафика составляет порядка 20%.

А теперь к главному: к статистике загрузки каждого ядра процессора в отдельности.

Что же мы видим? А видим мы то, что нагрузка от трафика равномерно распределяется по всем ядрам процессора.  Это позволяет нам сделать четкий вывод: при росте трафика мы уже не упремся в производительность одного или двух ядер, а сможем загрузить весь процессор целиком.

Итак, вывод по производительности: предельная производительность концентратора ATLAC (с учетом 20% процессора, которые заняты обработкой сеансов) в стандартной конфигурации (4-ядерный Xeon E5420 @ 2.5GHz, 2Gb, включение 2 портами по EtherChannel/LACP) - порядка 300 Kpps, проходящих сквозь концентратор (это порядка 600 Kpps c учетом обоих направлений трафика), и порядка 2 Gbps трафика (4 Gbps с учетом обоих направлений). Это фактически wirespeed, поскольку 2 интерфейса Gigabit Ethernet большую полосу пропускания предоставить не в состоянии.

Т.е. производительность концентратора ATLAC достигла скорости линии (wirespeed), и в абсолютном выражении теперь сравнима не с Cisco 7206 NPE-G1, а уже с Cisco 7206 NPE-G2. Причем это достигнуто чисто программными изменениями, а не аппаратными.

---

3.  L4R (layer 4 redirect). Эта функция позволяет задать для любой сервисной группы перенаправление всего TCP/UDP трафика на конкретный сервер и конкретный порт. Т.е., к примеру, можно отправлять проштрафившихся по балансу пользователей на личный кабинет или соответствующее сообщение. Данный функционал как по работе, так и по конфигурации соответствует принятому для Cisco ISG, однако кроме TCP/UDP еще перенаправляется ICMP. Возможно использование более 1 перенаправления на пользователя. В целом данный функционал при наличии L4R-пользователей несколько снижает производительность концентратора, как и на Cisco, однако не очень серьезно. Кроме того, вся выше приведенная статистика была снята при использовании L4R.

---

Все остальные пункты дополнительно рассматривать пока не буду. После того, как этот функционал будет реализован - я обязательно выложу отчет о производительности и возможностях.

До новых встреч. Предзаказы на ATLAC принимаются по E-mail (alex@alex-at.ru),  однако конечные сроки разработки пока что, увы, оставляю открытыми.