Тяжелые муки выбора. Что предпочесть – VDI или терминальный доступ?

 СЕРГЕЙ ХАЛЯПИН, Citrix Systems, руководитель группы системных инженеров Россия и СНГ

Тяжелые муки выбора
Что предпочесть – VDI или терминальный доступ?

В прошлой раз [1] я писал о тестировании тонкого клиента «ТОНК-1100С», построенного с использованием технологии HDX-on-Chip, пообещав рассказать о «муках выбора» технологии удаленного доступа. Давайте разберемся, в каком случае необходимо отдать предпочтение тому или иному решению и как найти условия, оптимальные для их работы

Начнем с того, что обе технологии (терминального доступа и виртуализации десктопов) представляют собой Server based computing – вычисления на стороне сервера, поэтому одним из ключевых моментов выбора будет протокол удаленного доступа и его возможности. Основные отличия терминального доступа от виртуализации десктопов:

• Уровень изоляции предоставляемого ресурса.
• Лицензии, необходимые для построения всего решения.

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

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

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

Рассмотрим технологии с точки зрения ресурсов, к которым осуществляется подключение. В случае терминального сервера это отдельная сессия на общем сервере Windows. В случае виртуализации десктопов – отдельный изолированный контейнер с клиентской ОС. Здесь можно выделить два ключевых различия – серверная ОС против клиентской и отдельная сессия (которая разделяет ресурсы одной ОС) против изолированной виртуальной машины.

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

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

• Лицензия Microsoft VDA, дающая право на подключение к виртуальному десктопу.
• Лицензии на серверные ОС (которые используются для различных компонентов решения).
• Лицензии клиентского доступа CAL.
• Лицензия на SQL.
• Лицензии для подключения к SQL (SQL CAL).
• Лицензии терминального доступа (RDS CAL).

При использовании терминального доступа нам нужно:

• Лицензии на серверные ОС.
• Лицензии клиентского доступа CAL.
• Лицензия на SQL.
• Лицензии для подключения к SQL (SQL CAL).
• Лицензии терминального доступа (RDS CAL).

Лицензии на SQL и SQL CAL (в обоих случаях) не обязательны для небольших внедрений, поскольку там можно использовать MS SQL Express. Лицензия RDS CAL нужна при построении комбинированного решения – виртуализация десктопов с терминальным доступом. Обязательно нужно учесть тот факт, что лицензия VDA – это подписка, требующая ежегодного продления.

Теперь посмотрим, что потребуется с аппаратной точки зрения (серверы и СХД). Для того чтобы получить количественные оценки, будем исходить из 200 пользователей, работающих с обычными офисными приложениями (MS Office) обычных серверов с ОЗУ 64 Гб и двумя процессорами по шесть ядер в каждом.

Решение по виртуализации десктопов потребует восемь серверов. Считаем, что у нас используются виртуальные машины с ОС Windows 7 c 2 Гб оперативной памяти. Тогда на одном сервере с 64 Гб памяти мы сможем запустить 31 виртуальную машину, что для двухсот пользователей потребует от нас семь серверов (и еще один сервер добавляем для обеспечения отказоустойчивости). В большинстве случаев для реализации указанного решения требуется система хранения данных. Необходимо учитывать, что выбор СХД должен осуществляться не по объему, а по такому показателю, как «количество операций ввода/вывода дисковой подсистемы в секунду» (IOPS), достаточному для работы всех виртуальных десктопов. Считается, что средний офисный сотрудник при работе в виртуальной машине Windows 7 создает нагрузку от 15 до 25 IOPS. Во время старта или выключения виртуальной машины данный показатель будет больше. Возьмем минимальное значение 15 и посчитаем дисковую подсистему: 200 пользователей * 15 = 3000 IOPS. Один диск SAS 15k rpm может выдать до 180 IOPS. Скорее всего диски мы объединим в RAID-5, тогда этот показатель нужно разделить на 4. В результате получаем требуемое количество дисков в СХД: 3000 / (180 / 4) = 67 дисков.

Для терминального доступа нам потребуется три сервера (с учетом обеспечения отказоустойчивости), т.к. на одном сервере смогут одновременно работать до 160 пользователей. Из общего объема памяти в 64 Гб зарезервируем 16 Гб для нужд ОС и системы терминального доступа. Одному пользователю требуется в среднем по 300 Мб оперативной памяти, что в результате дает (64 – 16) / 0,3 = 160. Специальных требований к СХД терминальные серверы не предъявляют.

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

Во-первых, это получение доступа к приложениям, которые для своей работы требуют права администратора. Данные приложения можно запустить и на терминальном сервере, однако это будет означать, что пользователь, получивший доступ к такому приложению, работает в контексте администратора. Тогда в случае некорректных действий такого пользователя может аварийно прекратиться работа всех 160 пользователей. При работе же в виртуальном десктопе «пострадает» только одна виртуальная машина – машина этого же пользователя.

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

В-третьих, бывают ситуации, когда программист, отступив от рекомендованных подходов, использовал недокументированные возможности клиентской ОС (это характерно для приложений, написанных собственными программистами компаний). В таких случаях приложение скорее всего не будет работать в среде терминального сервера, т.к. там используется серверная ОС.

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

Как же тогда выбирать решение и оборудование?

Простая рекомендация – руководствоваться здравым смыслом, а не маркетинговыми обещаниями, и ориентироваться на стоящие перед вами задачи.

1. Необходимо сегментировать своих пользователей на группы в зависимости от того, какие ресурсы им необходимы для работы.
2. Провести инвентаризацию приложений, выяснить, где и как они могут быть использованы в новой инфраструктуре.
3. Провести аудит имеющихся лицензий Microsoft в целях понимания, что потребуется еще приобретать для построения полнофункционального решения.
4. Проверить каналы связи (их качество и текущую загруженность), по которым пользователи филиалов будут подключаться к ресурсам в головном офисе.
5. Посмотреть на протоколы доступа, с которыми может работать решение. Можно выделить три наиболее распространенных протокола: RemoteFX (RDP) от компании Microsoft, PCoIP от компании Teradici и HDX (также хорошо известный, как ICA) от компании Citrix Systems. Данные протоколы обладают разными возможностями, и область их применения сильно зависит от условий и требований, предъявляемых конечными пользователями.
6. Оценить возможности, предоставляемые протоколом доступа, особенно в части работы с тем оборудованием, которое сотрудники подключают локально и которое теперь должно будет перенаправляться или пробрасываться в виртуальную машину или терминальное приложение. Такими устройствами могут быть принтеры, сканеры, считыватели штрих-кодов, устройства безопасности, гарнитуры и т.д. Особое внимание нужно уделить тому, к каким портам данные устройства подключаются – COM или USB.
7. Определиться с устройствами, с которых пользователи будут удаленно подключаться к ресурсам. При выборе клиентских устройств необходимо будет проверить, с какими протоколами они могут работать, а также какими возможностями обладают сами устройства (сколько и каких портов имеет устройство, а также какими вычислительными ресурсами располагает клиент). Скорее всего для работы придется выбрать несколько моделей, в зависимости от потребностей разных групп пользователей. Учитывая данный факт, следует удостовериться, что производитель тонкого клиента предоставляет систему управления клиентами, в том числе и для их удаленной настройки и обновления firmware.

Учитывая тот факт, что за последний месяц я протестировал несколько различных моделей тонких клиентов, любезно предоставленных мне компанией ТОНК, могу сказать, что в их модельном ряду можно подобрать устройство практически под любые запросы. В них есть поддержка трех основных протоколов доступа, есть система управления тонкими клиентами, а также большой выбор моделей с «нестандартными» параметрами – наличие большого количества COM-портов, возможность подключения нескольких мониторов. Самое приятное, что перед покупкой устройства можно бесплатно протестировать в своей инфраструктуре, чтобы осознанно прийти к решению о выборе.

1. Халяпин С. ТОНК 1100С – неожиданная, доступная и надежная находка для «правильных» ИТ-решений. //«Системный администратор», №7-8, 2012 г. – С.30-31 (http://samag.ru/archive/article/2244).

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