Asterisk™: будущее телефонии Второе издание

Меггелен Джим Ван

Linux подобна операционной системе UNIX, то есть является многозадачной системой, которая может выполнять несколько разных процессов одновременно. Проблема возникает, когда один из этих процессов (такой, как Asterisk) требует от системы очень высокой быстроты реагирования. По умолчанию Linux распределяет все ресурсы между приложениями, запрашивающими их, поровну. Если установлена система, включающая множество разных серверных приложений, каждое из них получит свою равную долю времени ЦП. Поскольку системе Asterisk необходим частый высокоприоритетный доступ к ЦП, для обеспечения ее сосуществования с другими приложениями система требует специальной оптимизации. Главным образом, подразумевается назначение приоритетов различным приложениям в системе и внимательное отношение к тому, какие сервисы устанавливаются.

Оптимизации ядра

Очень немногие дистрибутивы Linux предлагают по умолчанию ядро, оптимизированное для выполнения

одного конкретного приложения, поэтому здесь необходимо слегка потрудиться. Какой бы дистрибутив ни был выбран, как минимум, придется скачать и скомпилировать на своей платформе свежую версию ядра Linux (которую можно найти по адресуhttp://www.kernel.org). Также можно найти патчи, которые обеспечат повышение производительности, но считаются неофициальными дополнениями к официально поддерживаемому ядру.

Время ожидания запроса на прерывание

Время ожидания запроса на прерывание (Interrupt request, IRQ) - это, по сути, задержка между моментом, когда периферийная плата (такая, как интерфейсная плата для телефонии) запрашивает ЦП остановить выполняемый процесс, и моментом, когда ЦП фактически отреагирует и будет готов обрабатывать задачу. Периферийные устройства Asterisk (особенно платы Zaptel) чрезвычайно требовательны ко времени ожидания IRQ. Причиной этому является не столько несовершенство плат, сколько принцип работы программного механизма временного уплотнения (TDM). Если мы буферизируем данные мультиплексора с временным уплотнением (TDM) и посылаем их на шину большим пакетом, это может быть более эффективным для системы, но обусловит задержку между моментом поступления аудиоданных на плату и доставкой их в ЦП. Это делает обработку данных TDM в масштабе реального времени практически невозможной. При проектировании Zaptel было принято, что отправка данных каждую 1 мс будет наилучшим компромиссным решением. Но в результате этого возникает побочный эффект - любая плата в системе, использующая интерфейс Zaptel, будет посылать в систему запрос на обработку прерывания каждую миллисекунду. Это было характерно для старых системных плат, но на данный момент уже почти перестало быть причиной для беспокойства.

В Linux всегда существовала проблема недостаточно быстрого обслуживания IRQ; это доставляло немало неприятностей разработчикам приложений для работы с аудиоданными, поэтому было создано несколько патчей для устранения этого недостатка. До сих пор нет единого мнения по поводу того, как включать эти патчи в ядро Linux.

Версия ядра

Asterisk официально поддерживается Linux версии 2.6.

Дистрибутив Linux

Дистрибутивов Linux много, и они разнообразны. В следующей главе мы обсудим проблему выбора дистрибутива Linux и то, как получить и установить и Linux, и Asterisk.

Выбор процессора

Поскольку требования, предъявляемые Asterisk к производительности, главным образом, обусловлены большим объемом производимых математических вычислений, естественным будет выбор процессора с мощным FPU. Для осуществляемой Asterisk обработки сигналов от ЦП может потребоваться проведение громадного числа сложных математических вычислений. Эффективность, с которой выполняются эти задачи, будет определяться мощностью FPU процессора. Назвать лучший процессор для Asterisk в этой книге означало бы бросить вызов закону Мура. Даже за то время, которое пройдет между написанием и публикацией книги, скорости процессоров существенно возрастут, так же как и поддержка Asterisk для различных архитектур. Несомненно, это хорошо, но по этой причине советы по данной теме являются абсолютно неблагодарным занятием. Естественно, чем мощнее FPU, тем больше одновременных задач по ЦОС сможет выполнять Asterisk. Это основной принцип. При выборе процессора исходная тактовая частота - только часть уравнения. То, насколько хорошо он справляется с операциями с плавающей точкой, будет основным определяющим фактором, поскольку операции по ЦОС в Asterisk будут предъявлять высокие требования именно к этому процессу.

ЦП производства компаний Intel и AMD имеют мощные FPU. От чипов текущего поколения любого из данных производителей можно ожидать хорошей производительности [14] .

Сам собой напрашивается вывод, что необходимо выбирать самый мощный процессор из тех, которые позволяет ваш бюджет. Однако не торопитесь покупать самый дорогой из доступных процессоров. Помните о требованиях своей системы. В конце концов, болид «Формулы-1» Ferrari совершенно неуместен в мегаполисе с его многокилометровыми пробками в часы пик. Более медленные ЦП часто слабее нагреваются, и, таким образом, используя их, можно построить систему Asterisk для небольшого офиса с меньшим энергопотреблением, без вентиляторов, которая, возможно, смогла бы работать в условиях повышенной запыленности.

14

Найти самую свежую информацию о том, какой из ЦП лидирует в гонке производительности, можно на сайтах Tom's Hardware shardware.com) или AnandTech , где представлена масса информации как о современных, так и об устаревших ЦП, системных платах и наборах микросхем.

Чтобы ввести некий критерий, исходя из которого можно принимать решения о платформе, мы решили определить три типа систем Asterisk: малая, средняя и большая.

Малый тип систем

Требования Asterisk к производительности для малых систем (до 10 телефонов) ничем не отличаются от всех остальных, но, как правило, возможности современных процессоров позволяют справиться с нагрузкой, типичной для таких систем.

Если малая система создается на базе случайно подвернувшихся под руку старых компонентов, следует ожидать, что уровень производительности будет ниже, чем у более мощных машин, и что для нее снижение рабочих характеристик будет наблюдаться при значительно меньших нагрузках. Любительские системы могут прекрасно работать на маломощном оборудовании, но добиться этого сможет только эксперт в вопросах настройки производительности Linux [15] . Если система Asterisk настраивается в целях обучения, построить полнофункциональную платформу можно, используя относительно маломощный процессор. Авторы данной книги выполняли настройку нескольких лабораторных систем Asterisk с использованием процессоров Celeron с частотами от 433 до 700 МГц, но рабочая нагрузка таких систем минимальна (не более двух одновременных вызовов).

15

Грег Бенлеин (Greg Boehnlein) однажды скомпилировал и запустил Asterisk на процессоре Pentium с частотой 133 МГц, но это был по большей мере эксперимент. Вероятность возникновения проблем с производительностью очень велика, и, чтобы сконфигурировать такую систему надлежащим образом, необходимо быть экспертом Linux. Мы не рекомендуем использовать Asterisk в системах с процессором, частота которого ниже 500 МГц (для производственной системы 2 ГГц было бы благоразумным минимумом). И все же гибкость Asterisk просто поразительна.

AstLinux и Asterisk на OpenWRT

Те, кто действительно прекрасно себя чувствует, работая с Linux на встроенных платформах, несомненно, захотят присоединиться к рассылке AstLinux и опробовать творение Кристиана Кайл- хофнера (Kristian Kielhofner) AstLinux, или приобрести Linksys WRT54GL и установить версию Asterisk, созданную для этой платформы Брайаном Капучем (Brian Capouch). В этих проектах Asterisk представлен в базовой форме, что позволяет развертывать невероятно мощные приложения офисных АТС на очень недорогом оборудовании.

Хотя для работы с обоими проектами необходимо обладать изрядным объемом знаний и готовностью приложить большое количество усилий, они очень эффектны, чрезвычайно популярны и обеспечивают исключительное качество.

Средний тип систем

Сложнее всего решать вопросы производительности именно в системах среднего типа (от 10 до 50 телефонов). Как правило, такие системы развертываются только на одном или двух серверах и, таким образом, каждая машина должна будет обрабатывать по несколько специальных задач. По мере роста нагрузки платформа все больше приближается к своим предельным значениям технических характеристик. Пользователи могут начать испытывать проблемы с качеством связи, не понимая, что это происходит не потому, что система неисправна, а просто из-за того, что достигнуты пределы ее возможностей. По мере роста нагрузки на систему проблемы будут увеличиваться, а удовлетворенность пользователей, соответственно, падать. Исключительно важно, чтобы проблемы с производительностью были выявлены и решены до того, как они будут замечены пользователями. Отслеживание производительности в таких системах и быстрое реагирование на любые возникающие тенденции - основные условия, которые гарантируют, что платформа обеспечит качественную телефонную связь.

Большой тип систем

Большие системы (более 120 каналов) обычно развертываются на нескольких системах и сайтах, и, таким образом, вопросы производительности можно решать путем добавления компьютеров. Очень большие системы Asterisk созданы именно так.

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