Тезисы

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

Для удовлетворения перечисленных требований был разработан ряд решений, которые в комплексе позволяют практически решить все перечисленные задачи. В ядре системы расположен производительный softswith с открытой архитектурой FreeSWITCH. При его разработке была использована одна из самых удачных SIP-библиотек sofia. При большом количестве внешних соединений очень сильно растет паразитный SIP-трафик, от которого нельзя отказаться, но его обработка не требует интеллекта. Для решения этой задачи на границу ставится SBC (я использую kamailio), за которым в свою очередь "прячется" ядро. Хранение динамической конфигурации происходит в MySQL, а для статической используются родные конфигурационные файлы. Для преобразования данных из БД в понятный ПО формат используется или встроенный интерпретатор Lua (он есть как в FreeSWITCH, так и в kamailio), или ngx-lua-module (использует LuaJIT), в нем выполняется генерация конфигураций, которые после этого отдаются по HTTP. В процессе обработки больших объемов звонков возникает необходимость в хранении промежуточных данных: различных счетчиков, истории звонков по caller ID/destination number и т.д. И если в случае с единичной нодой вполне можно обойтись хранением таких данных в памяти самого softswitch, то в случае с распределенными системами необходимо доступное производительное хранилище. В таком качестве выступает Redis.

Отказоустойчивость делается по схеме n+1. В зависимости от генерируемой нагрузки компоненты распределяются по нодам. Управление всеми процессами (за исключением MySQL) отдается на откуп системе управления кластером corosync/pacemaker. Так вкратце выглядит схема бэкенда. MySQL используется 5.7, в котором есть собственная система кластеризации.

Все данные о состоянии системы (конфигурация, промежуточные данные) хранятся в Redis и MySQL, а доступ к ним хочется иметь унифицированный. Для этого на базе того же ngx-lua-module был разработан движок REST API, позволяющий оперировать данными. Сейчас в качестве фронтенда используется quasar.