Как рассчитать ёмкость Asterisk для офиса

Сколько звонков выдержит Asterisk, зависит не от числа сотрудников, а от пика одновременных разговоров и того, что АТС делает с каждым: перекодирует, пишет, держит в очереди. Считать надо пик по детализации, цену каждого сценария и запас, а проверять — нагрузочным тестом на своём профиле звонков.

Почему сервер под АТС нельзя выбирать на глаз

Типовой сценарий выглядит так: офису нужна АТС, кто-то находит в интернете фразу «Asterisk тянет сотни звонков на обычном сервере», берёт что под рукой, и первые недели всё хорошо. Потом приходит сезон, менеджеры одновременно обзванивают клиентов, включена запись, у части абонентов другой кодек — и голос начинает рваться. Сервер при этом формально жив, просто его ресурсы закончились в самый неудобный момент. Когда такое приносят нам на ИТ-аутсорсинг для офиса, первым делом я не меняю железо, а считаю.

Расчёт опирается на сценарии, которые вы уже собрали в паспорте требований из прошлой статьи серии «Требования к телефонии: что решить до установки». Там перечислены номера, группы, запись, меню и интеграции. Здесь мы превращаем этот список в цифры: сколько разговоров идёт одновременно, сколько из них пишется, сколько требует перекодирования, какой нужен канал к оператору. Без паспорта считать нечего — получится оценка численности офиса, а не нагрузки. Если паспорта пока нет, начните с него: потратить два часа на сценарии дешевле, чем менять сервер через полгода.

Универсальной цифры «один звонок съедает столько-то процессора» нет, и я специально её не привожу. Один и тот же сервер может выдержать больше разговоров без перекодирования и раньше упереться в предел, если звонки перекодируются, записываются и проходят через конференцию. Нагрузку создаёт не количество строк в конфигурации, а то, что dialplan делает с каждым каналом. Поэтому правильный ответ на вопрос «сколько выдержит» всегда звучит как «давайте измерим на вашем профиле».

Как посчитать пиковые одновременные вызовы

Отправная точка — не штат, а детализация вызовов. Возьмите у оператора или из текущей АТС выгрузку за несколько типичных недель, включая известный сезонный пик. Нужны время начала и длительность каждого звонка. Из этого легко получить максимальное число разговоров, которые шли одновременно, по каждому часу. Смотрите на пик, а не на среднее: среднее по дню у офиса почти всегда скромное, а проблемы возникают в те полчаса, когда все звонят разом. Учитывайте и сезонность: у бизнеса с выраженными пиками перед праздниками или в конце квартала нагрузка в эти недели может заметно отличаться от обычной.

Если детализации нет, оценивайте по ролям. Сколько человек работают на телефоне постоянно, сколько звонят эпизодически, бывают ли массовые обзвоны. Для очередей с многими входящими есть классический инструмент — формула Эрланга B: по нагрузке в час наибольшей нагрузки и допустимой доле отказов она показывает, сколько линий нужно. Для офиса на двадцать человек это обычно избыточно, но полезно хотя бы раз прикинуть, чтобы увидеть порядок величины. Если вы не уверены в расчёте, ничего страшного: дальше всё равно будет нагрузочный тест, который проверит гипотезу. Расчёт нужен, чтобы тест проверял правильную гипотезу.

К найденному пику добавьте внутренние звонки, если они идут через тот же сервер, и звонки удалённых сотрудников. Внутренний разговор между двумя аппаратами — это два канала в Asterisk, а не один. Если входящий звонок переадресуется на мобильный через тот же SIP-транк, АТС обычно держит два канала, а оператору нужны входящая и исходящая линии. Схема зависит от способа переадресации и тарифа: при переводе вызова на стороне оператора второй канал на АТС может не понадобиться. Про переадресации забывают чаще всего, и именно они дают сюрприз, когда лимит линий по тарифу заканчивается раньше, чем казалось. Итоговую цифру пика каналов запишите в паспорт отдельно от пика линий оператора — это две разные величины, и путать их нельзя.

• Детализация за несколько типичных недель и сезонный пик
• Максимум одновременных разговоров по часам, а не среднее
• Внутренние звонки — два канала на разговор
• Переадресация на мобильный — два канала и две линии оператора
• Удалённые сотрудники и софтфоны
• Запланированные обзвоны и рассылки

Что съедает ресурсы: транскодирование, запись, конференции

Самый дорогой сценарий по процессору — транскодирование. Если телефон говорит одним кодеком, а оператор принимает другой, Asterisk перекодирует звук в реальном времени в обе стороны на каждом таком разговоре. Когда кодеки совпадают и медиапоток можно передать без обработки, нагрузка на процессор обычно ниже; насколько именно — зависит от маршрута медиа и функций на вызове. Поэтому первым делом я выравниваю кодеки: узнаю, какие поддерживает оператор, и настраиваю телефоны и софтфоны так, чтобы общий кодек выбирался без перекодирования. Если перекодирования не избежать, например для части удалённых сотрудников на слабом мобильном интернете, его объём надо знать заранее и проверить на тесте.

В PJSIP конфигурация строится отдельными объектами: transport, endpoint, aor, auth. Разрешённые кодеки задаются на endpoint параметрами disallow и allow, а приоритет кодеков зависит от настроек согласования и версии Asterisk. Одной строки allow недостаточно, чтобы обещать отсутствие транскодирования: проверьте, какие форматы в итоге согласованы на обоих плечах вызова. Сами объекты нагрузку почти не создают, их может быть много. Нагрузку создаёт то, что происходит в разговоре: перекодирование, запись, обработка звука в конференции, проигрывание сообщений очереди. Если один endpoint разрешает всё подряд, а соседний — только один кодек, транскодирование почти гарантировано. Ошибки в выборе форматов часто проявляются не сразу; отдельно я разобрал ошибки кодеков Asterisk.

Запись разговоров через MixMonitor добавляет работу с диском: каждый записываемый разговор — это постоянная запись файла, а при одновременных пиках — много параллельных потоков. Медленная или перегруженная подсистема хранения может стать узким местом, но сама запись не означает автоматически слышимые задержки: это проверяют на стенде с теми же условиями. Конференции через ConfBridge смешивают звук от всех участников и стоят заметно дороже обычного разговора. Очереди с музыкой ожидания и периодическими объявлениями тоже не бесплатны. Поэтому в расчёте каждый сценарий из паспорта получает отметку: сколько каналов в пике попадает именно в него. Если после завершения вызова диалплану нужно сразу читать или обрабатывать файл, документация требует использовать StopMixMonitor: так файл гарантированно закрыт и доступен в ходе выполнения диалплана.

Канал связи и лимиты оператора

Процессор — не единственный предел. Каждый разговор занимает полосу в обе стороны. Для кодека G.711 полезная нагрузка — 64 кбит/с, а с учётом заголовков IP, UDP и RTP получается около 80 кбит/с на уровне IP в каждом направлении; Ethernet добавляет ещё накладные расходы, поэтому грубая оценка доходит примерно до 87 кбит/с. VLAN, VPN, частота отправки RTP-пакетов и другие сетевые обёртки меняют итог. Сжатые кодеки требуют меньше, но могут потребовать перекодирования. Умножьте полосу на пик одновременных разговоров и добавьте запас — так получится минимум, который должен быть свободен именно в момент пика, а не в среднем по дню. Если в пике идут записи на внешнее хранилище или обновления, их трафик тоже нужно учесть, иначе голос будет делить канал с файлами.

Важнее ширины канала его качество. Голос плохо переносит потери пакетов и неравномерную задержку, и при общем канале достаточно одного сотрудника, который заливает большой файл в облако, чтобы у всех поплыл звук. Поэтому на офисном маршрутизаторе голосовой трафик получает приоритет, а при возможности — отдельный канал или хотя бы ограничение для фоновых загрузок. Это настраивается один раз, но без этого никакой мощный сервер не спасёт разговор. Проверить качество канала можно до покупки сервера: длительный тест потерь и задержки до адреса оператора в рабочее время скажет больше, чем скорость в спидтесте. Если голос рвётся уже до нагрузочного теста, сначала проверьте маршрут до оператора по чек-листу SIP-транка.

Третий предел — лимит одновременных линий у оператора. Он задаётся тарифом и не зависит от вашего сервера. Если в пике нужно восемь линий с учётом переадресаций, а по договору их шесть, лишний вызов может быть отклонён оператором до поступления в АТС и тогда не появится в её журналах. Точное поведение зависит от SIP-транка и ответа оператора. Сверьте число линий с расчётом пика до запуска и запишите его в паспорт рядом с номером. Это самая дешёвая часть расчёта и самая частая причина жалоб «до нас не дозвониться». Если лимит не хватает, у оператора обычно можно расширить число линий — это дешевле и быстрее, чем любые изменения на сервере.

Нагрузочная проверка на реальном профиле

Расчёт даёт гипотезу, проверка — ответ. Для нагрузочного теста SIP есть открытый инструмент SIPp: он генерирует вызовы по сценарию, может держать заданное число одновременных разговоров и передавать звук. Я делаю так: собираю тестовый стенд с той же конфигурацией, что пойдёт в работу, включаю те же кодеки, запись и очереди, и поднимаю число одновременных вызовов ступенями до расчётного пика и выше. Тест гоняю на стенде или в нерабочее время, никогда — через боевые линии оператора. Сценарий теста должен повторять ваш профиль: доля записываемых звонков, кодеки, длительность разговоров и звонки в очередь.

Во время теста смотрим сразу на несколько вещей. Загрузка процессора и диска на сервере, число активных каналов в самой АТС, качество звука на тестовых разговорах и потери пакетов. Активные каналы и вызовы показывает консоль Asterisk, остальное — системные утилиты. Команда core show translation отображает время преобразования между аудиоформатами; core show translation recalc 60 пересчитывает его на машине, где запущена АТС. Это помогает сравнить кодеки, но не заменяет измерение всего сценария под нагрузкой. В asterisk.conf также есть maxcalls — административный предел числа одновременных вызовов, а не обещание производительности: проверьте фактическое значение в своей конфигурации. Звук обязательно слушать ушами хотя бы на нескольких звонках: график может быть зелёным, а голос уже квакает.

asterisk -rx "core show channels"
asterisk -rx "core show calls"
top
iostat -x 5

Снимайте показатели на каждой ступени и держите её несколько минут, а не секунды: кратковременный всплеск ничего не говорит о поведении сервера в реальный час пик.

Ступень, на которой начинаются проблемы, — это ваш реальный предел. Рабочая ёмкость — заметно ниже: я оставляю запас, чтобы пик сезона, рост штата на несколько человек и случайный массовый обзвон не упёрлись в потолок. Результат теста записываем в паспорт: при каком числе одновременных разговоров с какими сценариями сервер работает чисто. Через год, когда офис вырастет, этот же тест повторяется за полчаса, а не превращается в расследование. Если тест показывает предел ниже расчёта, это тоже хороший результат: вы узнали о нём на стенде, а не в понедельник утром.

Разбор: ёмкость АТС для «Линии растра»

Центр печати «Линия растра» — 21 рабочее место: приёмщики заказов, дизайнеры препресса, менеджеры по корпоративным клиентам, производство и бухгалтерия. Перед переходом на Asterisk владелец хотел купить «сервер помощнее, чтобы наверняка». Мы взяли детализацию у оператора за сезон, включая предновогодний пик с корпоративными заказами. Пик одновременных внешних разговоров оказался в разы меньше численности офиса, но с учётом переадресаций на мобильные менеджеров потребовал больше линий, чем было в тарифе.

Дальше выровняли кодеки: оператор и телефоны договорились на одном кодеке без перекодирования, софтфоны удалённых дизайнеров настроили так же. Запись включили только для приёма заказов и корпоративных менеджеров, хранение вынесли на файловое хранилище с резервным копированием. Конференции у них бывают редко, и под них отдельный запас не закладывали. На стенде с SIPp прогнали ступени до двойного расчётного пика: процессор и диск оставались спокойными, звук на тестовых звонках — чистым. На всё — от выгрузки детализации до отчёта по тесту — ушло около недели работы.

Итог оказался приятнее ожидания: вместо нового мощного сервера хватило виртуальной машины на уже имеющемся оборудовании, а сэкономленные деньги ушли на расширение тарифа по линиям и приоритизацию голоса на маршрутизаторе. Жалобы «не дозвониться» в следующий сезон не повторились. Если считать по шагам — пик по детализации, сценарии, кодеки, канал, лимит линий, нагрузочный тест — предел перестаёт быть сюрпризом. Следующая статья серии — «План внутренних номеров без тупиков»: разберём, как нумеровать отделы и людей, чтобы схема пережила рост офиса.

Частые вопросы