Asterisk™: будущее телефонии Второе издание - [12]
– Джим Диксон «The History of Zapata Telephony and How It Relates to the Asterisk PBX»
Вам, должно быть, уже не терпится настроить собственную систему Asterisk. Если вы планируете создать любительскую систему, то, пожалуй, можете перейти сразу к следующей главе и начать установку. Однако, если Asterisk развертывается для решения ответственных задач, необходимо сказать несколько слов о среде, в которой она будет выполняться. Будьте уверены, Asterisk - очень гибкое ПО и успешно устанавливается практически на любую платформу Linux, а также на несколько не-Linux платформ[12]. Но в данной главе обсуждаются вопросы, знание ответов на которые вооружит вас пониманием того, в каком операционном окружении Asterisk будет действительно эффективно функционировать, и поможет создать надежную, хорошо спроектированную систему.
С точки зрения требований к ресурсам Asterisk подобна встроенным системам реального времени преимущественно тем, что она должна иметь приоритетный доступ к процессору и системным шинам. Поэтому крайне важно, чтобы все остальные функции системы, не связанные напрямую с задачами Asterisk по обработке вызовов, если таковые вообще выполняются, должны выполняться с более низким приоритетом. Для небольших и любительских систем это может и не представлять особой проблемы. Однако для высокопроизводительных систем недостаточная производительность будет вызывать проблемы с качеством аудиосигнала, получаемого пользователем, часто в виде эха, помех и т. п. Примерно так ведут себя устройства мобильной связи при выходе из зоны обслуживания, но здесь причина этих проблем другая. По мере увеличения нагрузки на систему будут возрастать сложности с обслуживанием соединений. Для офисной АТС подобная ситуация - настоящая катастрофа, поэтому в процессе выбора платформы требования к производительности должны быть решающим критерием. В табл. 2.1 представлены некоторые самые основные рекомендации к планированию системы. В следующем разделе подробно рассматриваются различные вопросы проектирования и реализации, связанные с производительностью системы.
Размер системы Asterisk на самом деле определяется не количеством пользователей или телефонных аппаратов, а, скорее, количеством одновременных вызовов, которые система должна будет поддерживать. Эти цифры очень приблизительны, поэтому экспериментируйте и выбирайте наиболее подходящий для себя вариант.
Таблица 2.1. Рекомендации по выбору технических характеристик системы
| Назначение | Количество каналов | Рекомендуемые минимальные параметры |
| Любительская система | Не более 5 | 400 МГц х86, 256 M6 оперативной памяти |
| SOHO-система (малый офис и дом - менее трех линий и пяти телефонных аппаратов) | От 5 до 10 | 1 ГГц х86, 512 M6 оперативной памяти |
| Малая бизнес-система | До 25 | 3 ГГц х86, 1 Гб оперативной памяти |
| Средняя или большая система | Более 25 | Два ЦП, возможно также несколько серверов в распределенной архитектуре |
Результаты нагрузочного тестирования
Джошуа Колп (Joshua Colp) смог получить результаты, приведенные в табл. 2.2, используя процессор AMD Athlon64 X2 4200+ с 1 Гб оперативной памяти и жестким диском SATA емкостью 80 Гб и проводя тестирования по стандартному сценарию в приложении SIPp: простое установление соединения, воспроизведение аудиофайла (приложение Playback()) и некоторый небольшой период ожидания (Wait()). Обратите внимание на существенное снижение использования ресурсов ЦП при чтении данных из оперативной памяти по сравнению с чтением с жесткого диска. Это можно истолковать так, что ЦП ожидает данные, подлежащие обработке, перед передачей их в запрашивающий канал. Однако это всего лишь простой тест, и он никоим образом не отражает, какое количество вызовов сможет обрабатывать ваша система. Определить количество одновременных вызовов, которое может быть обработано при использовании конкретного диалплана и сочетания приложений, можно, только проведя нагрузочное тестирование системы.
Таблица 2.2. Пример результатов тестирования для стандартного сценария SIPp, использующего простые приложения Wait() и Playback(); SIPp отражает обратный медиа-поток Asterisk
| Количество | 330 | 330 | 550 |
| одновременных | |||
| вызовов | |||
| Использование | 149 | 14,8 | 57,6 |
| ЦП, % | |||
| Средняя нагрузка | 49 | 25 | 60 |
| Запоминающее | Жесткий диск | ОЗУ | ОЗУ |
| устройство |
Для больших установок Asterisk функциональность обычно распределяют между несколькими серверами. Один или более центральных модулей будут заниматься обработкой вызовов; их дополнят один или более вспомогательных серверов, обслуживающих периферийные устройства (такие, как система баз данных, система голосовой почты, система конференц-связи, система управления, веб-интерфейс, межсетевой экран и т. д.). Asterisk, как и многие Linux-системы, может расширяться с ростом требований к ней: малая система, которая прекрасно справлялась со всеми задачами по обработке вызовов и обслуживанию периферийных устройств, может быть распределена между несколькими серверами, когда требования возрастут и превысят ее текущие возможности. Гибкость - основная причина, по которой Asterisk исключительно рентабельна для быстро растущего бизнеса; для нее не существует эффективного максимального или минимального размера, который следует учитывать при составлении сметы на покупку. Хотя масштабируемость свойственна большинству телефонных систем, до сих пор нам не приходилось слышать о системе, которая была бы настолько же гибкой, как Asterisk. Однако стоит отметить, что задача по проектированию распределенных систем Asterisk не по зубам новичку в Asterisk.
