Методы и подходы в организации IP-телефонии на тонких клиентах

Методы и подходы в организации IP-телефонии на тонких клиентах

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

Пожалуй, наиболее емкий и сложный вопрос в отношении клиентской виртуализации, на который банально нет и быть не может однозначного и краткого ответа, нередко звучит примерно так:

- "Посоветуйте модель тонкого клиента, которая будет совместима с MS Lync например"?

Методы и подходы в организации IP-телефонии на тонких клиентах

К сожалению, подобный вопрос является яркой иллюстрацией принципа айсберга, когда на поверхности виднеется лишь 10% всей проблематики, а основная масса из 90% связанных с вопросом нюансов остается скрытой под плотной толщей незнания и недооценки сопутствующих факторов.

По сути же, тонкий клиент как устройство, в решении данной задачи отходит даже не на второй, а скорее уж на десятый план.

На первый и основной план выходит с полдюжины более важных вопросов, окончательные ответы на которые и определяют собственно итоговую работоспособность решения:

  1. Планируется ли использование специализированных аппаратных IP-телефонов?
  2. Если нет, то какие именно программы с указанием версий планируется использовать для IP-телефонии на тонких клиентах?
  3. На базе какого именно гипервизора с указанием его текущей версии планируется организовать работу пользователей удаленных рабочих столов?
  4. В каком конкретно режиме эти пользователи коммуницируют с сервером?
  5. Требуется ли двусторонняя передача видео, или достаточно будет ограничиться голосом и перепиской в чате?
  6. Какие модели микрофонов и/или веб-камер будут задействованы в процессе?

На ум тут невольно приходит знаменитый научный афоризм, гласящий: "Знание принципов освобождает от знания фактов" (с)

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

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

Подробная же проработка выбранного решения, безусловно потребует дотошной сверки со справочными материалами и фактами на предмет совместимости и работоспособности...

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

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

***

Итак, начнем с перечисления всех возможных вариантов решения, их ключевых различий, а также основных преимуществ и недостатков.

  • Решение IP-телефонии на базе аппаратных IP-телефонов

Методы и подходы в организации IP-телефонии на тонких клиентах

Предполагает обязательное наличие специализированных аппаратных средств не только на стороне серверов IP-телефонии, но и на стороне рабочих мест пользователей.

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

Однако требует очевидного и существенного удорожания проекта в лице приобретения дополнительных аппаратных средств для каждого из пользователей.

Как правило, подобные реализации применяются в тех случаях, когда проект IP-телефонии живет как бы сам по себе, а клиентская виртуализация - сама по себе.

Зачастую, когда виртуализация рабочих мест пользователей внедряется в компаниях, где IP-телефоны Cisco или Avaya например, уже давно стали корпоративным стандартом де-факто и украшают своим присутствием рабочие места пользователей наравне с ПК или ноутбуками.

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

Методы и подходы в организации IP-телефонии на тонких клиентах

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

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

Требования к серверу виртуализации - остаются, но существуют уже больше в рамках совместимости решения аппаратной IP-телефонии от соответствующего производителя с конкретной версией гипервизора от поставщика программного обеспечения.

Вероятных подводных камней - минимум, и если решение IP-телефонии спроектированно верно, то привязать его к виртуальным рабочим столам пользователей как правило не составит большого труда.

 

  • Решение IP-телефонии на базе тонких клиентов

Методы и подходы в организации IP-телефонии на тонких клиентах

Предполагает установку софтовых IP-телефонов непосредственно на тонкие клиенты в рамках исключительно локальной ОС самого тонкого клиента.

Т.е. дословно, именно на тонкие клиенты полностью инсталлируются программные клиенты Lync, Jabber, Skype и прочих решений для IP-телефонии. А серверы виртуализации в данном сценарии для нужд телефонии не задействуются вовсе!

Это, безусловно половинчатое решение, имеет право на жизнь только потому, что в принципе исключает любые возможные подводные камни.

Ведь практически, сугубо локальная установка ПО IP-телефонии напрямую на тонкий клиент без вовлечения в процесс сервера виртуализации, мало чем отличается от подобной же установки на обычный ПК или ноутбук скажем.

Основное требование тут может быть только одно - аппаратная мощность самого тонкого клиента должна быть достаточной для адекватной работы с видео, а локальная ОС на тонком клиенте должна быть совместима с соответствующими программными приложениями.

Все предельно просто и прозрачно, а главное - гарантированно заработает... Однако же грешит очень существенными и серьезными недостатками.

Во-первых, и это главное, работа ПО IP-телефонии в таком сценарии оказывается полностью оторванной от собственно виртуализации рабочего места пользователя.

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

Во вторых, сама модель тонкого клиента в данном случае однозначно относится к топовым линейкам. Читай - к самым дорогим моделям на базе мощных ЦПУ и Windows Embedded в качестве локальной ОС. И, хотя ряд приложений, тот же Skype например, имеют свои аналоги в мире Linux, т.е. совместимы с более дешевыми тонкими клиентами, но чудес все равно не будет. Для полноценной самостоятельной работы с видео, тонкий клиент должен обладать как минимум мощным ЦПУ, а как максимум - достаточным объемом флеш-памяти для локальной установки и работы сторонних приложений хотя бы и под Линукс.

 

  • Решение IP-телефонии в рамках терминальных сессий

Методы и подходы в организации IP-телефонии на тонких клиентах

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

К сожалению, факты таковы, что старые-добрые, а заодно и бюджетные во всех смыслах терминальные сессии в принципе не предназначены для решения многих современных задач.

И, IP-телефония - один из самых ярких примеров таких задач, которые под терминальной сессией либо невозможно решить в принципе, либо возможно лишь в очень ограниченных объемах.

Как минимум, терминальные сессии не имеют механизма гарантированного и стабильного проброса множества веб-камер на сервер. Речь тут может идти только о микрофонах и наушниках.

Другими словами, настроить тот же Skype на терминальном сервере в режиме чата - да вообще не вопрос.

Настроить Skype, но уже в режиме голоса - получится, но только при условии поддержки и сервером и клиентом как минимум RDP7.1 или выше. Т.е. старые терминальные серверы на базе Windows Seerver 2003 / Windows Server 2008 (до R2), равно как и старые тонкие клиенты заведомо не годятся даже для этого.

А вот настроить Skype с видео, так чтобы терминальный сервер и установленные на нем драйверы корректно понимали множественные копии Skype с одновременным пробросом более чем одной веб-камеры из множества сессий с тонких и/или толстых клиентов - либо очень проблематично, либо заведомо невозможно...

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

Если же говорить о более продвинутом Lync например, где помимо собственно IP-телефонии реализована еще и интеграция с Exchange-сервером, то в этом случае для терминального сервера все окажется еще хуже и сложнее.

 

  • Решение IP-телефонии в рамках виртуальных рабочих столов

Методы и подходы в организации IP-телефонии на тонких клиентах

Наконец, самая полноценная и 100% интегрированная с виртуальной средой пользователя реализация IP-телефонии в программной форме возможна только на базе клиентских виртуальных машин, т.е. в среде VDI (Virtual Desktop Infrastructure).

Дословно - когда пользователи работают в виртуальных машинах на сервере с гипервизором, и программные клиенты различных приложений IP-телефонии (Skype, Lync, Jabber...) установлены именно в составе соответствующих виртуалок.

VDI конечно же ощутимо дороже по деньгам, чем терминальные сессии - это факт.

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

Тонкий клиент, планшет, нетбук - не важно, пользователь все равно получает полноценное рабочее окружение в рамках персональной или выделенной на время виртуальной машины - со всеми необходимыми программами, включая и тот же Skype или Jabber например. И установка-настройка соответствующих драйверов тех же веб-камер на десктопную ОС в виртуальной машине также не проблема.

Ведь фактически, на современную виртуальную машину с десктопной Windows 7 или Windows 8 можно без проблем установить любое ПО, которое только вообще возможно установить и на обычный ПК безо всякой виртуализации.

Но, на практике все равно имеются важные нюансы, о которым мы и поговорим подробнее в заключительной части статьи.

***

Первое, и самое главное - это та нагрузка, которая неизбежно ложится на сервер виртуализации при пропускании через него массированного VOIP-траффика от множества пользователей с их виртуалками.

Практически, это грозит неоправданным и очень значительным удорожанием самого сервера, дабы по своей производительности он был физически способен одновременно потянуть не только полсотни виртуалок, но и еще полсотни видео/аудио потоков в рамках VOIP-траффика через них.

Такой лобовой сценарий очевидно далек от оптимальной реализации!

Поэтому, все ключевые производители решений для IP-телефонии - Microsoft, Cisco и Avaya, еще в 2013 году пошли по пути оптимизации своих программных решений конкретно для среды VDI.

Суть этой оптимизации проста и заключается в разделении программного клиента IP-телефонии на две составляющие:

  • собственно клиент, который устанавливается на виртуальную машину
  • и дополнительный плагин (plugin), или медиа-движок (media engine), который устанавливается на конечное устройство пользователя с целью оптимизации генерируемого VOIP-траффика и разгрузки сервера виртуализации.

Схематично, суть предложенного решения изображена на рисунке ниже:

Методы и подходы в организации IP-телефонии на тонких клиентах

Это изящная идея позволяет сохранить полную интеграцию программ IP-телефонии с виртуальными рабочими столами, но при этом существенно снизить нагрузку на сервер виртуализации как с точки зрения ЦПУ, так и с точки зрения сетевого траффика.

На деле мы имеем полное сохранение основного преимущества IP-телефонии в среде VDI при полном же устранении основного недостатка данного решения - безусловно здорово!

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

И, конкретно в данном случае, пожертвовать пришлось простотой реализации подобных решений.

Потому что именно в таком сценарии оптимизированной IP-телефонии под VDI,

  • 100% функциональной
  • 100% интегрированной и консолидированной
  • 100% универсальной и аппаратно "независимой"...

в итоге присутствует наибольшее количество подводных камней и потенциально возможных нестыковок и проблем совместимости.

Фактически, круг замкнулся и мы вернулись к тому, с чего начинали статью - программная реализация IP-телефонии в виртуальной среде, на практике требует очень тщательной проработки в своих самых мельчайших деталях.

Во первых, многое будет зависеть от гипервизора.

Например, некоторые версии VMWare при работе конкретно с MS Lync обязательно требуют полного совпадения битности гостевой ОС на виртуальной машине с битностью локальной ОС на конечном устройстве пользователя (где установлен плагин)

Если скажем, на виртуалке установлена Windows 8 Enterprise 64bit, а на тонком клиенте - Windows 7 Embedded 32bit, то могут возникнуть проблемы и нестыковки в итоговой работе Lync по вине лишь относительно устаревших версий ESXi, а не собственно Lync или тонкого клиента...

Поэтому, четкое понимание и планирование конкретно используемой версии гипервизора в данном контексте - обязательно!

Microsoft Hyper-V, VMWare ESXi, Citrix XenDesktop, RedHat Linux Enterprise гипервизоры де-факто отличаются в ряде нюансов не только между собой, но и даже внутри себя в рамках своих различных версий...

Во вторых, не меньше зависит и от Вендора IP-телефонии.

Например, MS Lync в рассматриваемом контексте, очевидно отличается не только от Cisco Jabber, но даже и MS Lync 2010 существенно отличается от MS Lync 2013.

Де-факто, для Lync 2010 уже давно есть плагин VDI под Citrix XenDesktop, а вот для Lync 2013 такого плагина все еще не существует.

Точно также, Cisco Jabber определенных версий имеет плагины, совместимые со сторонними версиями Linux на тонких клиентах HP например, но не имеет плагинов, совместимых с Линукс на тонких клиентах Fujitsu например, и т.п.

Наконец, немало зависит и от модели тонкого клиента.

Т.к. часть нагрузки снимается с сервера виртуализации, то эта же часть неизбежно ложиться на конечное устройство пользователя - чудес не бывает!

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

Соответсвенно, ни веб-камеру с нулевым клиентом не подружить, ни оптимизирующий VOIP-траффик плагин на нулевой клиент не установить... Хотя исключения здесь все-таки возможны!

Тонкие же клиенты как минимум должны быть оснащены не самыми слабыми ЦПУ и достаточно емкой флеш-памятью, а также совместимой с существующими плагинами локалной ОС.

Сухой остаток в итоге простой - к сожалению, нельзя уверенно обещать работу абсолютно любых программ IP-телефонии с абсолютно любыми тонкими клиентами или абсолютно любыми средами виртуализации.

Но всегда можно обратится за развернутыми консультациями к специалистам соответствующих направлений в ERC!

Система Orphus
comments powered by Disqus
 
Top