Я новичок в мире VoIP, и мы стремимся перейти от нашего текущего провайдера к решению, которое мы размещаем сами, в основном потому, что текущая услуга настолько ненадежна. К сожалению, я практически ничего не знаю о VoIP и о том, что необходимо для работы. Насколько я понимаю, вам понадобится минимум SIP-сервиса, система PBX и аппаратные или программные телефоны. Я считаю, что это чрезмерное упрощение того, что необходимо, так что хотелось бы получить больше информации по этому поводу.
Кроме того, поскольку все наши системы существуют в VMWare ESXi, похоже, было бы неплохо виртуализировать PBX (например, PBXInAFlash или OpenPBX и т. Д.) В VMWare; однако я не знаю, возможно ли это вообще или целесообразно. У нас около 25 пользователей и около 100 «рабочих групп» в стиле call-центра.
Итак, я предполагаю, что мои вопросы:
Все ответы на ваши вопросы - «смотря как». Если вы используете систему PBX, такую как Asterisk, где аудиоданные фактически обрабатываются серверными компьютерами, у вас будут гораздо более высокие требования к ЦП и вводу-выводу на серверном компьютере (наряду с привередливой зависимостью от времени - чего не делают виртуальные машины) т обязательно проделаю большую работу с). Если вы используете систему PBX, например sipXecs, которая действует больше как «коммутатор» с аудиоданными, в основном передаваемыми между конечными точками (телефонами и шлюзом), у вас будет гораздо меньше требований к ресурсам сервера, но, очевидно, с другим набором функций.
Я думаю, вы идете в неправильном направлении. Я бы начал с определения функций, связанных с телефонией, которые вам нужны в УАТС, а затем с определения продуктов, платформ и торговых посредников, которые могут предоставить то, что вы ищете. Вы можете рассматривать виртуализацию как технический «список желаний» на пути к разработке спецификации, но я бы сказал, что функции, связанные с телефонией, должны иметь приоритет. Как только вы узнаете, что ищете, с точки зрения набора функций, вы можете приступить к разработке требований к оборудованию.
Виртуализация УАТС является проблемой из-за одного главного аспекта: есть нет гарантированное планирование вашей виртуальной машины PBX и общее поведение планирования могут привести к дрожанию. При этом вы также должны подумать о том, как ваши линейные карты (если вам нужен S0 для какой-либо другой АТС и т. Д.) Должны быть представлены виртуальной машине и имеют ли смысл такие вещи, как vMotion и HA.
В vmware есть люди, которые это сделали и думали, как запускать в реальном времени, как приложения, и имеют в этом опыт, но вам нужно напрямую поговорить с vmware, чтобы узнать, каков текущий набор «рабочих» продуктов.
Я серьезно обдумывал это в прошлом и придумал одну очень вескую причину не виртуализировать.
Что произойдет, если вы захотите подключить свою УАТС к стандартной сети PSTN? Поскольку для этого требуется специальное оборудование, имеет смысл избегать виртуального использования. У этого есть дополнительное преимущество: если ваш SIP-провайдер выйдет из строя, вы все еще не полностью вылетели из бизнеса.
Я бы сам не стал виртуализировать АТС - сами разработчики sipxecs предупреждают, - они говорят, что не стоит рассматривать виртуализацию чего-либо, кроме тестовой системы.
Я сам виртуализировал один только с одним расширением (хост был xeon e5450 / 12 Гб с одним ядром и 4 Гб, выделенным для виртуальной машины) и обнаружил, что голосовые сообщения были прерывистыми.
Если вы действительно хотите это сделать, я читал, что кто-то сказал, что он выделил 400 МГц процессорного времени, что помогло, хотя я предполагаю, что это будет зависеть от вашего фактического процессора.
Также из других экспериментов я обнаружил, что часы виртуальной машины могут вращаться по всему шоу, что не помогает с вещами, которые очень зависят от времени, такими как ippbx.
Я не совсем придурок, но вот обсуждение некоторых методов, чтобы попытаться остановить прыгающее время http://communities.vmware.com/thread/108877
Честно говоря, я бы никогда не виртуализировал АТС или любой другой маршрутизатор, от которого она зависит. Пакеты данных обычно могут ждать доли секунды без каких-либо проблем, но любая задержка не согласуется с голосом.