Глава 2. Обзор архитектуры и компонентов Horizon View

Для начала мы хотим ознакомить вас, на верхнем уровне, с основным ядром инфраструктуры компонентов и архитектуры, которая составляет продукт Horizon View. Мы начнём с архитектуры верхнего уровня, как она отображена на следующей схеме, прежде чем погрузимся в подробности каждой части:

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

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

Вся архитектура Horizon View изящно непосредственна для понимания, так как она основывается на стандартных продуктах VMware vSphere (ESXi и vCenter). Поэтому, если у вас имеются достаточные навыки и опыт работы с этой платформой, тогда вы уже около середины пути. {Прим. пер.: с VMware vSphere можно ознакомиться в нашем переводе книги Г. Б. Абхилаша и Ребекки Фитцхью Изучение VMware vSphere.}

Horizon View строится поверх инфраструктуры vSphere, получая преимущества некоторых свойств гипервизора ESXi и сервера vCenter. Horizon View требует добавления ряда виртуальных машин для выполнения различных родей и функций.

Общее представление архитектуры View для доставки виртуальных рабочих мест отображено на следующей схеме:

Компоненты View работают в качестве приложений которые установлены в операционной системе Microsoft Windows Server, за исключением Access Point, который является закалённым Linux устройством, поэтому он может реально работать также на физическом оборудовании. Однако, существует великое множество доступных преимуществ в случае, если вы выполняете его на виртуальных машинах, например предоставляющих HA (High Availability, высокую доступность) и DR (Disaster Recovery, восстановление после сбоев), а также обычно сокращение стоимости, которого можно достичь за счёт виртуализации.

Последующие разделы обсудят каждый из этих компонентов/ ролей общей архитектуры View более подробно, начиная с сервера соединений Horizon View.

Horizon View Connection Server (сервер соединений Horizon View), также иногда называемый Connection Broker (посредником соединений) или View Manager (менеджером View), является центральным компонентом всей инфраструктуры View. Его первейшая роль заключается в соединении пользователя с его виртуальным рабочим местом посредством выполнения аутентификации пользователя и последующей доставки соответствующих ресурсов на основании профиля пользователя и предоставленных пользователю прав. После выполнения регистрации к вашему виртуальному рабочему месту, именно сервер соединений то, с чем вы взаимодействуете.

Как работает сервер соединений?

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

Итак, как же работает процесс регистрации? После запуска клиента View (показанного как 1 на следующей схеме), пользователь вводит подробности своих идентификационных данных сервера соединений View, которые в свою очередь отвечают (2) запросом у него предоставления подробностей его сетевой регистрации (его имя пользователя и пароль в домене AD, Active Directory).

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

Обычно пул является коллекцией аналогичных машин виртуальных рабочих мест; например, это может быть пул для вашего департамента маркетинга в котором машины виртуальных рабочих мест содержат определённые приложения/ программное обеспечение для этого подразделения. Мы подробнее обсудим пулы рабочих мест в Главе 7, Управление и настройка пулов рабочих столов.

После аутентификации менеджер View или иначе сервер соединений делает запрос к серверу vCenter (4) для создания машины виртуального рабочего места, а vCenter затем делает вызов (5) либо к View Composer (если вы используете Linked Clones, присоединённые клоны), либо создаёт Instant Clone (моментальный клон), применяя функцию ВМ vSphere Fork (разветвления) для запуска построения процесса этого виртуального рабочего места если нет уже доступного для данного пользователя, чтобы он мог в нём зарегистрироваться.

Когда процесс построения завершён и машина виртуального рабочего места доступна конечному пользователю, она отображается/ предоставляется внутри окна клиента View (6) с применением выбранного протокола отображения (PCoIP, Blast или RDP).

Этот процесс схематично описывается на следующей диаграмме:

Существуют другие способы развёртывания решений VDI, которые не требуют посредника (broker) соединений, хотя вы и можете выдвинуть аргумент, что строго говоря, это не истинное решение VDI. Именно так в действительности выглядели первые решения VDI, и они просто позволяли пользователю соединяться напрямую с его собственным виртуальным рабочим местом через RDP. Если вы думаете об этом, тогда действительно у вас должны быть некоторые определённые случаи использования чтобы делать именно это.

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

Просто так получилось, что VMware тоже думал о подобном варианте применения и имеет решение, которое называется Brokerless View (View с потерей посредника), которое применяет встраиваемый модуль VMware Horizon View Agent Direct Connection (прямого соединения агента View VMware Horizon) для непосредственного соединения с машиной виртуального рабочего места без необходимости в сервере соединений. Однако, не забывайте что в среде Horizon View сервер соединений View предоставляет большую функциональность и при этом делает намного больше чем простое соединение пользователя к рабочему столу, как мы увидим позже в этой главе.

Как мы уже отмечали ранее, сервер соединений Horizon View работает как приложение на сервере Windows, который в свою очередь может быть либо физической, либо виртуальной машиной. Работа в качестве виртуальной машины имеет множество преимуществ: например, это подразумевает что вы можете легко добавлять свойства высокой доступности, которые критичны для данного окружения, если вы можете потенциально иметь сотни, или может быть даже тысячи машин виртуальных рабочих мест, работающие на отдельном сервере хоста.

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

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

Минимальные требования для сервера соединений?

Для установки сервера соединений View вам необходимо обеспечить следующий необходимый минимум требований для работы физической или виртуальной машин:

В следующем разделе мы собираемся рассмотреть как работает сервер безопасности Horizon View.

Сервер безопасности Horizon View является другим компонентом в нашей архитектуре и является по существу другой версией сервера соединений View, однако в данное время он расположен в пределах вашей DMZ (Demilitarized Zone), поэтому вы можете разрешать конечным пользователям безопасно подключаться к их машинам виртуальных рабочих мест из внешней сети или Интернета. Как вы увидите в Главе 4, Установка и настройка Horizon View, процесс установки доброжелателен во многом как и установка вашего сервера соединений View, однако вместо последнего вы выбираете роль сервера безопасности в ниспадающем меню при запуске установки.

Как работает сервер безопасности?

Чтобы начать, пользователь выполняет процесс регистрации в начале в точности так же, как когда он присоединялся к серверу соединений View, главным образом потому что сервер безопасности просто другая версия сервера соединений, выполняющий подмножество функций за исключением базы данных ADAM (Active Directory Application Mode). Разница состоит в том, что соединяетесь по адресу своего сервера безопасности. Данный сервер безопасности расположен внутри вашей DMZ и взаимодействует с сервером соединений, расположенным во внутренней сетевой среде, с которой он спарен. Таким образом, теперь мы должны добавить дополнительный уровень безопасности, так как ваш внетренний сервер соединений не экспонируется вовне с основной идей, состоящей в том, что пользователи теперь могут получать достуа к своим машинам виртуальных рабочих мест извне без необходимости вначале подключаться к VPN в вашей сетевой среде.

Процесс схематично объясняется на следующей диаграмме:

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

Мы опишем это в разделе Установка сервера безопасности View Главы 4, Установка и настройка Horizon View.

Когда пользователь регистрируется из клиента View, он теперь применяет внешний URL своего сервера безопасности для доступа к серверу соединений, который в свою очередь осуществляет аутентификацию этого пользователя в AD. Если ваш сервер соединений настроен как шлюз PCoIP, тогда он будет пропускать такое соединение и организовывать обмен информацией со своим клиентом View. Такая информация соединения позволяет клиенту View присоединяться к своему серверу безопасности и использованием PCoIP. Это показано на схеме зелёной стрелкой (1). Ваш сервер безопасности затем перенаправляет соединение PCoIP на машину виртуального рабочего места (2), создавая соединение для данного пользователя. Данная машина виртуального рабочего стола отображается/ доставляется в пределах окна клиента View (3) при помощи выбранного протокола отображения (PCoIP, Blast или RDP).

Сервер реплики Horizon View, как следует из его имени, является репликой или копией сервера соединений View и обслуживает две цели.

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

Вторая означает, что добавление серверов реплики позволяет вам масштабировать общее число пользователей и соединений виртуальных рабочих столов. Отдельный индивидуальный экземпляр сервера соединений может поддерживать 2000 соединений, поэтому добавление дополнительных серверов соединений позволяет вам добавлять другие 2000 пользователей за раз, вплоть до максимума в пять серверов соединений и 10000 пользователей для участка (pod) Horizon View. Мы обсудим архитектуру участков и блоков в Главе 3, Обсуждение проектирования и развёртывания.

При развёртывании сервера реплики вам необходимо изменить его IP адрес или обновить запись DNS чтобы она соответствовала данному серверу если вы не применяете балансировщик нагрузки.

Как и в случае с сервером безопасности, вы увидите в Главе 4, Установка и настройка Horizon View, что процесс установки опять- таки аналогичен процессу для сервера соединений, однако на этот раз вы выбираете роль сервера реплики в ниспадающем меню с различными опциями ролей.

Как работает сервер реплики?

Итак, самый первый вопрос состоит в том, что же на самом деле реплицируется? Посредник (broker) соединений сохраняет всю свою информацию, относящуюся к его конечным пользователям, пулам рабочих мест и прочим относящимся к View объектам, в базе данных ADAM (Active Directory Application Mode). Затем, при помощи LDAP ( Lightweight Directory Access Protocol) (он использует метод, аналогичный тому, который AD применяет для репликации), эта информация View копируется с вашего оригинального сервера соединений на ваш сервер реплики.

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

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

Сервер регистраций Horizon View является последним компонентом который является частью опций установки вашего сервера соединений Horizon View, и выбирается из ниспадающего меню вашего окна опций установки. Что же делает сервер регистраций?

Horizon 7 встречает введение новой функции, называемой True SSO. True SSO является решением, которое делает возможной аутентификацию пользователя в среде Microsoft Windows без необходимости ввода его полномочий AD. Он интегрируется в другой продукт VMware, менеджер идентичности VMware, который составляет часть как расширенной, так и корпоративной редакций Horizon 7.

Его задание состоит в расположении между сервером соединений и Microsoft Certificate Authority, тем самым запрашивая временные сертификаты из его запаса сертификатов (ertificate store).

Процесс схематически объясняется на следующей диаграмме:

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

По успешному завершению аутентификации, прошедший её пользователь будет представлен машинами виртуальных рабочих мест или размещённых приложений, которые он имеет право применять. Такие пользователи будут запускать всё из перечисленного простым двойным щелчком мыши, который будет запускать его клиента Horizon View, как это показано красной стрелкой (1) на предыдущей диаграмме. Пользовательские полномочия затем передаются на сервер соединений (2), который в свою очередь проверяет их, отправляя условие SAML (Security Assertion Markup Language) назад менеджеру идентичности (3).

Если пользовательские полномочия удостоверены, тогла сервер соединений пропускает их на сервер регистраций (4). Сервер регистраций затем выполняет запрос в Microsoft Certificate Authority (CA) для создания временного сертификата с коротким сроком существования для использования таким пользователем (5).

При помощи созданного теперь сертификата, сервер соединений предоставляет его операционной системе данной машины виртуального рабочего места (6), которая в свою очередь подтверждается Active Directory в том является или нет данный сертификат подлинным (authentic) (7).

Когда получено подтверждение в подлинности (authentication) данного сертификата, тогда пользователь регистрируется в его машине виртуального рабочего места, которое будет отображено/ доставлено в его клиенте View с помощью ранее выбранного протокола отображения (8).

Точка доступа (Access Point) VMware выполняет в точности ту же функциональность, что и сервер безопасности View, что отображено на схеме ниже, с одной ключевой разницей. Вместо того, чтобы быть приложением Windows или другой ролью сервера соединений, точка доступа является отдельным виртуальным устройством (appliance), которое исполняется в устойчивой, закрытой операционной системе Linux:

Хотя устройство точки доступа (Access Point Appliances) предоставляет практически ту же функциональность, что и сервер безопасности, он всё ещё не полностью заменяет его, в особенности, если у вас имеется промышленное применение, которое использует сервер безопасности для внешнего доступа. Вы можете продолжать применять эту архитектуру.

Основная разница между устройствами точки доступа и сервером безопасности состоит в способе масштабирования. Ранее, вы должны были спаривать сервер безопасности с сервером соединения, что являлось ограничением, но теперь это уже не так. Таким образом, теперь вы можете масштабировать столько устройств точек доступа, сколько требуется вашей среде, с максимальным пределом, состоящим в приблизительно 2000 сеансов для одного устройства. Добавление дополнительных устройств просто является вариантом применения данного устройства, так как устройства не зависят от прочих устройств и не взаимодействуют с ними. Они взаимодействуют напрямую с серверами соединений. {Прим. пер.: слишком категоричное утверждение. Прогресс не стоит на месте, и современные устройства, например, Wyse 3030LT, могут выполнять разгрузку (offload) сервера, осуществляя безопасное взаимодействие друг с другом в случае такой необходимости. Например, при общении пользователей в Skype, нет необходимости 100% посредничества сервера, обмен между терминалами теперь может осуществляться напрямую. При этом может применяться защищённый канал. Понятно, что важнейшая часть задачи обмена сертификатами безопасности все ещё лежит на сервере, но основной объём обмена его минует! На момент перевода (октябрь 2016), данная функциональность Wyse пока реализована только у Citrix (HDX RealTime Optimization Pack 2.1), надеемся на оперативность VMWare!}

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

Один из всегда задаваемых вопросов состоит в том, должны ли вы развёртывать выделенные (постоянные) назначения или плавающие (временные) присваивания рабочего стола. Рабочие места могут либо быть индивидуальными виртуальными машинами, которые выделяются некоторому пользователю на основе 1:1 (как мы имеем в случае применения физических рабочих мест, когда каждый пользователь эффективно владеет своим собственным рабочим столом), или же пользователь имеет новое, комплексное рабочее место которое предоставляется, строится, персонифицируется , а затем назначается во время регистрации. Машины виртуальных рабочих мест произвольно выбираются из пула доступных рабочих столов, которые данный конечный пользователь имеет право использовать.

Если вы помните, ранее в Главе 1, Введение в VDI и VMware Horizon 7, мы обсуждали построение составного рабочего места. Именно эта модель применяется для построения данного рабочего места.

Две более подробно обсуждаемые опции следующие:

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

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

Другой предмет, который мы часто рассматриваем как несколько запутывающий, состоит в разнице между выделенными и плавающими рабочими местами, а также то, как приспосабливаются присоединяемые клоны (Linked Clones). Присоединяемые клоны, полные клоны и моментальные клоны это не то, о чём мы говорим когда мы обсуждаем выделенные или плавающие рабочие места. Под операциями клонирования понимают то, как строится и предоставляется рабочее место, в то время как термины постоянный и временный относятся к тому, каким образом некоторые рабочие места назначаются конечному пользователю.

Выделенные и плавающие рабочие места это всё полностью про назначение пользователя или будет ли пользователь иметь выделенный рабочий стол, или же он будет выделяться из пула по запросу. Присоединённые клоны и полные клоны являются свойствами Horizon View, который применяет View Composer (компоновщика View) для создания конкретного образа рабочего стола для каждого пользователя из главного или родительского образа. Это означает, что вне зависимости от наличия плавающих или выделенных назначений рабочего стола, данная машина виртуального рабочего места всё ещё может продолжать быть присоединённым или полным клоном.

Итак, суммируем преимущества {плавающих мест}:

В следующем разделе мы собираемся глубже рассмотреть общий вид доступных в Horizon 7 технологий клонирования, стартуя с компоновщика (Composer) Horizon View и присоединяемых клонов и основных преимуществ, предоставляемых данной технологией.

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

Давайте рассмотрим пример. Если у вас имеется 1000 пользователей и для каждого пользовательского рабочего стола выделяется 250ГБ, вам может понадобиться 1000 * 250ГБ = 250ТБ для всего окружения виртуальных рабочих столов. Такое огромное хранилище только для рабочих столов и может в результате приводить к значительной стоимости инфраструктуры, что скорее всего будет означать, что стоимость развёртывания такого объёма хранения в вашем центре обработки данных будет представлять данный проект не эффективным в отношении стоимости в сравнении с применениями физических рабочих мест.

Требуется новый подход к развёртыванию хранилища для среды рабочих мест, и это именно то, где вступают в игру связанные клоны. Вкратце, связанные клоны (Linked Clones) разработаны с целью уменьшения общего требуемого дискового пространства, а также для упрощения развёртывания образов и управления ими для множества машин виртуальных рабочих мест, делая их их централизованными и более простыми процессами.

Начиная с верхнего уровня, клон является копией существующей или родительской виртуальной машины. Такая родительская виртуальная машина (ВМ, VM - virtual machine) обычно является вашим золотым построением, из которого вы хотите создавать новые машины виртуальных рабочих мест. Когда клон создан, он становится отдельной, новой машиной виртуального рабочего места со своей собственной уникальной идентичностью. Такой процесс не уникален для Horizon View; в действительности это функция vSphere и vCenter, а в случае Horizon View мы добавляем другой компонент, компоновщик (Composer) View, с целью управления такими образами рабочих мест. Существует два типа клонов, которые мы можем применять, а именно: полный клон и связанный клон. В последующих разделах мы поясним существующую разницу.

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

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

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

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

Теперь, обсудив полные клоны, мы собираемся поговорить о развёртывании машин виртуальных рабочих мест с помощью связанных клонов (Linked Clones).

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

Связанный клон сам по себе может потенциально расти до того же самого размера, что имеет диск реплики, если вы ему позволите это. Однако вы можете установить пределы на то, до какого размера он может расти и должен ли он становиться настолько большим, после чего вы можете обновлять свои виртуальные рабочие столы, которые привязаны к нему. Естественно, это запускает процесс клонирования снова из его первоначального моментального снимка. {Прим. пер.: подробнее о работе со снимками, на примере ZFS, см. Моментальные снимки и клоны перевода книги ZFS Майкла В. Лукаса и Аллана Джуда.}

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

Лежащая в основе связанных клонов технология более похожа на моментальный снимок, чем на клон, однако с единственной ключевой разницей: компоновщиком View. С помощью компоновщика (Composer) View вы можете иметь более одного активного моментального снимка, присоединённого к своему родительскому диску виртуального рабочего места. Это позволяет вам создавть множество образов виртуальных рабочих мест всего лишь из одного родителя.

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

Один момент, о котором следует знать, который всё ещё связан с самим хранилищем, заключается в том, что больше чем о ёмкости, в настоящее время мы говорим о производительности. Все рабочие места связанного клона собираются выполнять чтение из одной реплики и тем самым будут приводить к высокому значению IOPS (Input /Output Operations Per Second ) того хранилища, где обитает данная реплика. В зависимости от архитектуры вашего пула рабочих столов, вы скорее всего будете располагать более чем одной репликой, так как обычно имеете более одного хранилища данных. Это в свою очередь зависит от общего числа пользователей, которым будет управлять данная архитектура вашего решения. Мы обсудим подробности в Главе 3, Обсуждение проектирования и развёртывания. {Прим. пер.: советуем также ознакомится с основными приёмами настройки производительности на примере ZFS в Главе 8, Производительность перевода книги ZFS для профессионалов.Майкла В. Лукаса и Аллана Джуда.}

В Horizon View у вас имеется возможность выбирать местоположение вашей реплики. Одна из рекомендаций состоит в том, что ваша реплика должна располагаться на быстром хранилище, таком как локальный SSD. {Прим. пер.: помимо рекомендованных нами к ознакомлению в сноске предыдущего параграфа, стоит также напомнить об уверенно входящем на современный рынок интерфейсе NVMe, который благодаря отказу от CHS адресации к хранимым данным позволяет достигать истинного параллельного доступа, например, к тем же самым чипам SSD, заменяя собой SAS/SATA. Подробнее о численном сопоставлении в разделе NVMe уже упомянутого перевода ZFS для профессионалов. Представить разнообразие современных продуктовых реализаций NVMe может помочь обзор серверов Huawei с поддержкой NVMe (октябрь 2016).}

Альтернативными решениями были бы реализации некоторых видов технологий ускорения хранилищ в отношении IOPS. Horizon View также имеет своё собственное встроенное решение, называемое VSA (View Storage Accelerator, ускоритель хранилища View) или CBRC (Content Based Read Cache, кэш чтения на основе содержимого). Данная функциональность позволяет вам выделять до 2ГБ оперативной памяти лежащего в основе сервера хоста ESXi, которые могут быть использованы в качестве кэша для наиболее часто читаемых блоков. Поскольку мы обсуждаем загрузку загрузку операционных систем рабочего стола, требуются именно эти блоки; так как они будут браться из оперативной памяти, данный процесс ускоряется.

Другим решением является VCAI (View Composer Array Integration, интеграция массива компоновщика View), которое делает возможным процесс разгружать в вашем массиве хранения сам процесс построения связанных клонов и его внутренний механизм моментальных снимков вместо забора тактов ЦПУ с вашего сервера хоста.

Существует также большое число прочих решений сторонних разработчиков, которые решают проблему узкого места производительности хранилища, например, Atlantis Computing и их продукт ILIO, или же применение массивов all-flash, таких как Tintri.

В следующем разделе мы мы заглянем глубже в то как работают связанные клоны.

Первый шаг состоит в создании вашего главного образа машины виртуального рабочего места, который должен содержать не только выбранную операционную систему, основные приложения и настройки, но также и компоненты агента Horizon View. Эта машина виртуального рабочего места станет вашей родительской ВМ, или вашим золотым образом. Мы раскроем процесс построения в Главе 6, Построение и оптимизация ОС виртуального рабочего стола.

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

Общий вид процесса создания присоединённого клона отображён на следующей схеме:

Когда вы создали свой родительский рабочий стол, или золотой образ (1), вы затем берёте моментальный снимок (2). Когда вы создаёте свой пул рабочих мест, этот снимок выбирается и становится репликой (3) и будет установлен доступным только для чтения. Каждый виртуальный рабочий стол ссылается назад на данную реплику; отсюда происхождение термина присоединённый клон. Когда вы запускаете создание своих виртуальных рабочих мест, вы создаёте присоединённые клоны, которые являются уникальными копиями для каждого пользователя.

В процессе построения вашего образа и после того как был создан конкретный диск реплики, компоновщик View (View Composer) создаёт ряд других виртуальных дисков, включая присоединённый клон (диск операционной системы) сам по себе. Это описано в последующих разделах.

Диск связанного клона

Не желая утверждать очевидное, тем не менее, самый главный создаваемый диск это сам по себе диск присоединённого клона (Linked Clone disk). Такой диск присоединённого клона в основном пустой контейнер виртуального диска, который подключается к вашей машине виртуального рабочего стола как только пользователь регистрируется и запускается его рабочий стол.

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

Диск реплики установлен доступным только для чтения и применяется в качестве первичного диска. Любые записи и/ или блочные замены, запрашиваемые вашим виртуальным рабочим местом записываются/ считываются с его диска присоединённого клона.

Постоянный диск или диск данных пользователя

Свойство постоянного диска (persistent disk) компоновщика View позволяет вам настроить отдельный диск который содержит только данные конкретного пользователя и настройки пользователя, а не саму операционную систему. Это позволяет сохранять любые пользовательские данные при ваших обновлениях или вносить изменения в сам диск операционной системы, например при действии реконструкции.

Этот диск также используется для хранения профиля его пользователя. Имея это в виду, вам необходимо настраивать его размер надлежащим образом, гарантируя что он достаточно велик для хранения для любого типа данных профиля пользователя, например оценок виртуального рабочего стола (Virtual Desktop Assessments). Это другая причина, того, почему будет хорошей мыслью выполнять оценку рабочего места, которую мы рассмотрим в Главе 3, Обсуждение проектирования и развёртывания, с тем, чтобы вы могли строить картинку того какие профили рабочего места вашего пользователя и требования данных пользователя каким образом выглядят.

Одноразовый диск

При помощи опции одноразового диска (disposable disk), Horizon View создаёт фактически временный диск, который удаляется при каждом выключении его пользователем своей машины виртуального рабочего места.

Если вы знаете о том, как операционная система рабочего стола Windows работает и какие файлы она создаёт, то существуют определённые файлы, которые используются на временной основе. Файлы подобные временным файлам интернета или страницы Windows это только пара таких примеров. Так как эти файлы являются только временными, зачем вам сохранять их? При помощи Horizon View данный тип файлов перенаправляется в одноразовый диск и затем удаляются после выключения данной ВМ.

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

Отметим, что здесь мы говорим о временных системных файлах, а не о файлах пользователя. Временные файлы пользователя всё ещё хранятся на диске данных этого пользователя, поэтому они могут сохраняться. Многие приложения применяют папку temp Windows для хранения файлов CAB установки, которые могут упоминаться после установки. Сказав это, вы можете захотеть удалять временные пользовательские данные для уменьшения размера образа своего рабочего места, и в этом случае вы можете обеспечить, чтобы все временные пользовательские файлы переназначались в его одноразовый диск.

Внутренний диск

Наконец, у нас имеется внутренний диск. Внутренний диск применяется для хранения важной информации о настройках, такой как пароль учётной записи данного компьютера, который будет необходим для присоединения машины этого виртуального рабочего места назад к её домену если вы обновите её присоединённые клоны. Он также используется для хранения подробностей настроек Sysprep и Quickprep. Мы рассмотрим Quickprep в Главе 6, Построение и оптимизация ОС виртуального рабочего стола.

В терминах дискового пространства, такой внутренний диск относительно невелик, в среднем примерно 20МБ. По умолчанию, конкретный пользователь может не видеть этот диск из своего Windows Explorer, поскольку он содержит важную информацию настроек, и вы не хотите чтобы он мог её удалить.

Следующая схема показывает вам общий обзор различных создаваемых типов дисков:

Существует несколько сложных этапов исполняемых компоновщиком View и менеджером View и они осуществляются при запуске пользователем сеансов виртуального рабочего места. Итак, что такое процесс построения связанного клона рабочего места и что происходит за сценой? Когда пользователь регистрируется в Horizon View и запрашивает рабочее место, менеджер View, применяя vCenter и компоновщика View, создаёт машину виртуального рабочего места. Этот процесс описывается в последующих разделах.

Создание и подготовка к работе нового рабочего стола

Первый шаг в процессе состоит в создании и подготовке к работе вашей машины виртуального рабочего места следуя этапам, описываемым здесь: Запись для вашей машины виртуального рабочего стола создаётся в ADAM (Active Directory Application Mode) перед её помещением в режим подготовки к работе.

Теперь виртуальная машина создана и следующий этап состоит в её индивидуализации.

Персонализация рабочего стола

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

Этапы персонализации таковы:

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

Во многих окружениях AD пароль учётной записи вашей машины периодически изменяется. Если агент компоновщика View определяет какое- либо изменение пароля, он обновляет пароль учётной записи это машины на её внутреннем диске, который был создан в её присоединённом клоне.

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

Процесс вашего присоединённого клона изображён на следующей схеме:

Существует также ряд других функций управления которые вы можете выполнять с диском присоединённого клона в компоновщике View; они очерчены в данном разделе и требуются для предоставления непрерывного управления вашими машинами виртуальных рабочих мест.

Реконструкция связанного клона

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

Как мы уже обсудили в разделе Что строит View Composer, у нас имеются отдельные диски для таких элементов, как пользовательские данные. Эти диски не подвергаются воздействию в процессе операции реконструкции, поэтому все специфичные для пользователя данные на них сохраняются.

Когда вы инициируете операцию реконструкции, компоновщик View по существу вновь запускает процесс построения вокруг связанного клона; таким образом, создаётся диск новой операционной системы, который впоследствии персонализируется и берётся его моментальный снимок, подобный снимку, показанному в предыдущем разделе.

Процесс реконструкции описывается следующими шагами:

Приводимая ниже схема отображает графическое представление процесса реконструкции. Перед началом процесса, первое что вы должны сделать, это обновить свой Золотой диск (1) с обновлениями изменений или новыми приложениями, которые вы хотите предоставить для своих виртуальных рабочих мест.

Как уже объяснялось на предыдущих этапах, для создания новой реплики выполняется моментальный снимок (2), Replica V2 (3). Разрушается диск вашей текущей ОС, однако диск User Data (4) остаётся прежним в процессе реконструкции:

Обновление связанного клона

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

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

Процесс обновления выполняет следующие задачи:

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

Следующая схема отображает представление подобной операции обновления:

Присоединённый клон с левой стороны схемы (1) начал расти в размере. Обновление возвращает его назад к его моментальному снимку, как если бы он был новым виртуальным рабочим местом, что показано в правой части данной схемы (2).

Ребалансировка работы при помощи View Composer

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

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

Процесс балансировки описывается следующими этапами:

Следующая схема отображает операцию повторной балансировки:

В следующем разделе мы собираемся рассмотреть метод создания машин виртуальных рабочих столов с применением функциональности моментального (Instant) клона.

Функция моментального (Instant) клона в действительности является функциональностью встроенной в платформу vSphere, а не неким специфическим свойством Horizon, и была сделана доступной начиная с выпуска vSphere 6.0 U1, однако только теперь она получает поддержку функциональности как часть Horizon 7.

Она использует технологию VMware VM Fork для очень быстрой подготовки к применению машин виртуальных рабочих мест. Моментальный клон создаётся из уже включённой и выполняющейся машины виртуального рабочего места, называемой Родительской ВМ (Parent VM), которая переводится в пассивное состояние перед созданием моментального клона. Это то, что делает моментальные клоны более быстрыми при подготовке к работе, чем присоединённые клоны, создаваемые при помощи компоновщика View.

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

Следующая схема отображает архитектуру такого моментального клона:

Когда конечный пользователь выходит из машины виртуального рабочего метса моментального клона, она разрушается, а когда пользователь регистрируется вновь, она получает вновь создаваемый моментальный клон. Если ей требуются какие- либо постоянные данные, тогда она должна использовать свойство записываемого тома (Writeable Volume) App Volumes для предоставления подобной функциональности и UEM для своих персональных настроек.

Существует ряд преимуществ от использования моментальных клонов в сравнении с присоединёнными клонами:

принимая во внимание, что моментальные клоны всё ещё достаточно новая технология, существует пара ограничений, о которых следует знать:

Давайте начнём с небольшого обзора основ и истории, лежащих за View Persona Management. View Persona Management первоначально был технологическим продуктом, который назывался Virtual Profiles и был приобретён VMware у RTO Software в 2010. Он впервые был введён в View 5.0 и позволил вам настраивать профили пользователя таким образом, что они динамично синхронизировались с репозиторием удалённых профилей в пределах окружения виртуальных рабочих мест.

VMware View Persona Management был впервые введён в в View 5.0 и позволил вам настраивать профили пользователя таким образом, что они динамично синхронизировались с репозиторием удалённых профилей, размещённых на файловом сервер в вашем центре обработки данных.

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

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

Это именно то место, где вступает в игру View Persona Management и предоставляет профиль этого пользователя плавающему виртуальному рабочему месту, на которое они применяются, фактически делая их собственниками.

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

Это показано на следующей схеме:

В данном разделе мы подробно рассмотрели View Persona Management в управлении профилем пользователя и ключевые преимущества его предоставления. Глубокое погружение в технический обзор и подробности того, как настраивать View Persona Management можно найти в доступной через интернет главе, Глава 14. Управление окружением пользователя в инфраструктуре виртуальных рабочих мест.

На верхнем уровне View Persona Management предоставляет следующие свойства:

Помимо перечисленных свойств, View Persona Management также помогает снизить TCO виртуального рабочего места делая возможным перемещение в среду виртуальных рабочих мест без сохранения состояния. В некоторых реализациях, пользователи помещаются в выделенные пулы исключительно для получения своих настроек профиля, которые добавляют стоимость и сложность в управлении. С точки зрения стоимости, Persona Management является интегрированной частью Horizon View, у вас нет необходимости покупать дополнительный сторонний продукт, если только у вас нет потребности в дополнительной функциональности, выходящей за рамки имеющейся базовой.

Раз в предмете управления нет никаких дополнительных компонентов для настройки или установки, всё управляется групповой политикой AD (Active Directory Group Policy); опять же, в терминах масштабирования, поскольку нет дополнительных накладных расходов на инфраструктуру, таких как базы данных, масштабирование не вызывает никаких проблем.

Продукт VMware UEM (VMware User Environment Manager, менеджер окружения пользователя VMware) является новой редакцией для портфолио Horizon и он был добавлен когда VMware приобрела голландскую компанию Immidio в феврале 2015. Immidio была компанией производителем программного обеспечения, которая создала продукт, имеющий целью помочь её консультантам в поле с ключевым продуктом, имевшим название Flex+.

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

Существует пять основных вариантов применения, при которых может быть использован UEM:

SmartPolicies являются свойством Horizon 7 и применяют UEM 9.0 для доставки набора политик, которые специфичны для машин виртуальных рабочих мест Horizon View.

При помощи SmartPolicies вы можете настраивать следующее:

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

UEM предоставляет намного больший набор переменных настройки и свойств, а также наличие консоли централизованного управления, что делает намного более простыми управление и развёртывание. Однако, вы можете уже иметь более комплексное решение UEM на площадке. Если вы применяете более низкие редакции Horizon, тогда Persona Management может нормально удовлетворять вашим требованиям, а если нет, то может быть есть смысл рассмотрения сторонних продуктов, таких как Liquidware Labs ProfileUnity или AppSense.

Часто возникающий при развёртывании решения VDI - как вы управляете печатью? раз ваше виртуальное рабочее место фактически работает на сервере в вашем центре обработки данных, означает ли это, что когда вы нажимаете кнопку печати, ваше задание появляется там? Что с драйверами принтера? Обычно ваш рабочий стол имеет определённый драйвер, установленный для находящегося поблизости от вас принтера, или же, вообще, это может быть локально подключённый принтер. Означает ли это, что вы должны устанавливать все возможные драйверы на ваши машины виртуальных рабочих мест? К счастью, ответ на этот вопрос - нет, и в данном разделе мы вкратце обсудим как VMware Horizon View управляет печатью.

Вместе с Horizon View поставляется OEM решение виртуальной печати, ThinPrint, для которого OEM является компания с именем Cortado. ThinPrint позволяет вашим конечным пользователям выполнять печать даже на сетевые принтеры или локальные принтеры, подключаемые с оконечных устройств к своим машинам виртуальных рабочих мест через перенаправление USB. В следующем разделе мы обсудим управление USB устройствами.

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

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

Существует два ключевых компонента для решения виртуальной печати которые устанавливаются как часть Horizon View в процессе установки; они таковы:

Все мы используем подключаемые устройства USB в своих переносимых и настольных машинах. Если вы работаете в среде VMware Horizon View, вы можете захотеть продолжить использование ваших устройств USB с таким виртуальным рабочим местом. Перенаправление USB является встроенной в Horizon View функцией, которая позволяет физически подключать USB устройство к оконечному устройству при работе его в качестве как если бы оно было подключено к такому виртуальному рабочему месту.

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

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

Проще говоря, большинство устройств USB должно работать в среде Horizon View, так как все они по существу переправляют обмен этого USB от работающего на вашем оконечном устройстве клиента View на агента View, работающего на машине виртуального рабочего места. Полный список протестированнных (validated) устройств не существует; если существуют вопросы о функциональности конкретного устройства, вам следует связаться с производителем именно этого устройства USB.

Могут существовать некоторые устройства, которые не будут работать, причём исключительно из- за своего внутреннего устройства, например, некоторые устройства безопасности, которые проверяют физические свойства машины или устройства, к которым они подключаются. Для классификации USB веб- камер мы применяли термин неподдерживаемые устройства. Однако, после появления RTAV (Real Time Audio Video, аудио- и видео- в реальном масштабе времени) эти устройства теперь поддерживаются. Мы обсудим это позже в данной главе.

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

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

Horizon View имеет функциональность, которая может препятствовать перенаправлению USB устройств в имеющуюся машину виртуального рабочего места пользователя. Вы можете применять её используя политику для оконечных устройств, виртуальных рабочих мест или посредством групповой политики AD (Active Directory Group Policy). Например, ваша организация может хотеть препятствовать применению устройств флеш- памяти, так как это предоставило бы данному пользователю возможность копирования данных с машины виртуального рабочего места (одна из причин для реализации VDI состоит именно в том, что данные должны быть сосредоточены в едином центре и не покидать центр обработки данных).

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

В своей среде вы можете иметь некоторые устройства USB, каждое из которых может иметь определённые различные функции, и в то же время использовать одно USB соединение. Например, мультимедийная клавиатура может иметь сенсорную панель мыши, колонки, считыватель отпечатка пальца и клавиатуру саму по себе. {Прим. пер.: а ещё и считыватели RFID меток, слип- документов, венозного строения ладони и т.д., и т.п.}

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

ThinApp является виртуальным приложением без агента или прикладным пакетным решением, которое отсоединяет приложения от лежащих в их основе операционных систем. Оно разработано для разрешения конфликта приложений, ускорения предоставления приложений и улучшения управляемости. Лицензии ThinApp включены в лицензию Horizon View и могут использоваться как на физических, так и на виртуальных рабочих местах, вследствие чего предоставляя механизм доставки приложений для всех моделей ваших рабочих мест, всё ваше имущество конечных пользователей.

ThinApp заключает приложения в пакет состоящий из отдельного файла .exe или .msi и абстрагирует его от:

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

Когда вы создаёте пакет ThinApp, вы главным образом захватываете все файлы приложений, настройки реестра, а также изменения файловой системы, которые необходимы данному приложению для работы. Он также захватывает свой собственный агент как часть всего процесса, таким образом оконечное устройство не требует ничего для установки, пока вы не предоставите пакеты ThinApp при помощи своего Workspace Portal.

После упаковки, такое приложение может быть применено (либо в виде потока, либо после установки) в вашей машине виртуального рабочего места или даже физического рабочего стола. Единственное требование пакетов ThinApp состоит в наличии работающей в её основе операционной системы Windows, либо физической, либо виртуальной. Важно отметить, что в процессе своей работы этот пакет не вносит никаких изменений в свою операционную систему на машине, на которой он работает.

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

Суммируя, ThinApp выполняет следующее:

Дополнительные сведения о том как использовать ThinApp в вашей среде вы можете прочитать в книге Питера Бьёрка VMware ThinApp 4.7 Essentials.

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

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

Скажем, у вас имеется сервер хоста vSphere, выполняющий быть может 100 рабочих мест или около того; что если в 12:00 дня в четверг они все ринутся сканировать вирусы? Такой хост, скорее всего, станет очень быстро загруженным на 100%, причём как в отношении ЦПУ, так и в отношении операций ввода/ вывода для хранилища, что приведёт в конечном счёте к остутствию ответа от рабочих мест. Вместо получения воздействия от одного пользовательского рабочего места вы получаете воздействие 100 рабочих мест пользователей. Вам следует составить расписание для сканирования с тем, чтобы они не случались все одновременно, однако в идеале вам нужно найти альтернативные методы, которые спроектированы для более предназначенной работы в инфраструктуре виртуальных рабочих мест.

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

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

В VMware vSphere 5.5, VMware ввела в действие продукт с названием vShield Endpoint (терминал vShield), который предназначен для проблем, связанных с антивирусным сканированием в реализациях виртуальных рабочих мест большого масштаба. В оснащении Horizon View, терминал vShield обобщает и разгружает все антивирусные операции в одном централизованном SVA (security virtual appliance, виртуальном устройстве безопасносоти).

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

VMware работает со следующими партнёрами, которые имеют интегрированными с терминалом vShield свои антивирусные решения:

Терминал vShield VMware предоставляет следующие свойства:

Существует два основных компонента терминала vShield: сам SVA и его драйвер.

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

Драйвер терминала vShield затем устанавливается на главный или родительский образ рабочего места. драйвер терминала vShield является частью установки инструментов VMware:

ИТ администратор может централизованно управлять терминалом vShield VMware через входящую в состав VMware vShield Manager консоли, которая в свою очередь интегрируется в сервер vCenter. Изолирование механизма антивирусного сканирования в виртуальном устройстве (applience) делает более простым защиту этого механизма сканирования чем если бы он размещался на каждой виртуальной машине. Кроме того, подробное протоколирование активности от службы антивирусного и противовредоносного ПО удовлетворяет требованиям соответствия аудита.

Одним из наиболее важных элементов решения виртуального рабочего места состоит в том, как получать на оконечное устройство вашего пользователя содержимое экрана вашей работающей в центре обработки данных машины виртуального рабочего места. Для выполнения этого VMware Horizon View применяет PCoIP (PC-over Internet Protocol). В данном разделе мы собираемся обсудить что такое протокол PCoIP и то, как он участвует в предоставлении удобства на практике конечного пользователя.

PCoIP является высокопроизводительным протоколом отображения спроектированным и разработанным Teradici (http://www.teradici.com/). Он был разработан для целей доставки виртуального рабочего места по вашей локальной или глобальной сети и предоставлении конечным пользователям наилучшего, снабжённого богатой функциональностью удобства использования рабочего места.

При помощи PCoIP всё содержимое экрана сжимается, кодируется и шифруется в центре обработки данных перед отправкой только пиксельных данных через стандартную сетевую среду IP в поддерживающие PCoIP оконечные устройства (например, нулевые клиенты), которые используют микросхемы Teradici Terra 1 или Terra 2 в качестве аппаратной поддержки, или же на устройства Windows, Mac или планшеты, исполняющих клиента View на основе программного обеспечения. Ключевым здесь является то, что никакие данные не покидают центр обработки данных.

PCoIP поддерживает высокое разрешение, частоты полнокадровой развёртки, 3D графику, среду HD, множество дисплеев (до четырёх, в зависимости от оконечного устройства), а также высококачественный звук. Как мы уже обсуждали ранее в этой главе, PCoIP также поддерживает перенаправление периферии USB.

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

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

В следующем разделе мы собираемся обсудить как PCoIP выполняет отрисовку (rendering) изображений и как он динамично приспосабливается к сетевому окружению.

Итак, давайте начнём с рассмотрения того, как работают различные модели визуализации (отрисовки, rendering). В настольном ПК ваши приложения, операционная система и графические драйверы совместно работают локально над предоставлением наилучшей производительности для этого ПК. Это локальная визуализация клиента.

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

Итак, что с визуализацией хоста? В сценарии с отрисовкой на стороне хоста среда вашего рабочего места ПК, которую мы обсуждали ранее, в значительной степени та же самая. Однако ПК теперь работает в качестве машины виртуального рабочего места. Это означает, что приложения будут работать так, как они обычно работали бы на физическом настольном ПК, в то время как визуализация выполняется на стороне хоста. PCoIP затем работает только над кодированием только пикселей на машине вашего виртуального места, исполняющего вашего агента View, а затем отправляет их на оконечное устройство выполняющего клиента View или на устройство нулевого клиента, работающего на оборудовании Teradici, где происходит процесс декодирования.

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

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

PCoIP имеет возможность анализировать эти различные компоненты среды изображений и применять соответствующий кодек для каждого пикселя перед его сжатием, кодированием и отправкой этих пикселей на оконечное устройство для декодирования. Работая таким образом, PCoIP передаёт пиксели более эффективно, что в конечном итоге означает меньшую полосу пропускания и лучшую производительность. Это также означает что вы можете управлять качеством подлежащего доставке содержимого изображения. Мы обсудим это в следующем разделе.

Качество картинки, которую предоставляет PCoIP, может контролироваться через групповую политику AD или SmartPolicies для доставки соответствующего качества изображения в зависимости от вашего варианта применения. Данное изображение постепенно строится из того, что называется воспринимаемым без потерь изображения, в изображение без потерь, причём последнее предоставляет высокую точность воспроизведения с точностью отображения вплоть до пикселя. Например, действительно ли вам требуется строить изображение с качеством попиксельного отображения если вы просто работаете с Microsoft Word?

Важный момент, о котором следует помнить, состоит в том, что качество изображения будет оказывать влияние на требующуюся для доставки полосу пропускания. Мы обсудим подробности этих параметров управления в доступной через интернет главе Глава 13. Тонкая настройка и удобство конечных пользователей.

Для управления использованием полосы пропускания адаптивное кодирование PCoIP автоматически выравнивает качество изображения по достижению переполнения сетевых сред, основываясь на установленных вами пределах политики, а затем возобновляет максимальное качество изображения, когда ваша сеть перестаёт быть перегруженной. Так как PCoIP не передаёт никакие данные, а только пиксельные значения, имеет смысл вместо протокола TCP применять в реальном масштабе времени UDP (User Datagram Protocol, тот же самый протокол, что и для VoIP (Voice over IP), чтобы гарантировать чувствительную и интерактивную практику удалённому пользователю. Это уменьшает общие требования к полосе пропускания и предоставляет большее удобство интерактивности для пользователя на основе на данный момент общей полосы пропускания имеющейся сетевой среды.

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

Существует пара других протоколов рабочего места в основном потоке. Основные доступные сегодня протоколы это Microsoft RDP (Remote Desktop Protocol) и Citrix ICA (Independent Computing Architecture). Они более подробно обсуждаются в следующих разделах. {Прим. пер.: можно добавить RedHat SPICE и Huawei HDP}.

RDP протокол был разработан Microsoft {Прим. пер.: после его приобретения у PictureTel (ныне известной как Polycom) в составе телекоммуникационной программы Liveshare Plus (названной впоследствии NetMeeting)} и изначально применялся для соединения с удалённой машиной, сервером, рабочей станцией или виртуальной машиной при помощи TCP IP. RDP теперь более известен как Remote Desktop Connection. Скорее всего, вы ежедневно используете его для удалённой связи с вашей серверной инфраструктурой.

Когда вы соединяетесь с удалённым рабочим местом или машиной, вы фактически соединяетесь компонентом терминальной службы, который затем транслирует содержимое её экранов назад клиенту, помимо нажатий клавиш и перемещений мыши. {Прим. пер.: на момент перевода доступна версия 10.0, поддерживающая широкое разнообразие многих новых свойств, как то: опция Zoom для поддержки старых версий Windows в сеансах с HiDPI (например, отображения экрана 640x480 в сеансе с разрешением 2560x1440); поддержку AVC/ H.264; богатый функционал RemoteFX, включая vGPU (DirectX 11 в Windows Server 2012, OpenGL 4.4 и OpenCL 1.1 API в Windows Server 2016, Windows 10 Enterprise) и т.п.}

ICA (Independent Computing Architecture) является другим протоколом отображения, применяемым Citrix в своих продуктах XenDesktop и XenApp. По своей архитектуре он аналогичен прочим протоколам в том, что он используется для доставки содержимого экранов и нажатий клавиатуры устройствам клиентов через сетевое соединение TCP IP.

Вы соединяетесь при помощи клиента ICA, такого как Citrix Receiver, установленного на вашем оконечном устройстве. Это загружает файл ICA, содержащий подробности удалённой системы, к которой вы присоединяетесь, и необходимые к применению в данном сеансе свойства.

Что можно сказать про HDX? На самом деле HDX не является протоколом или некоторой технологией, а скорее маркетинговой торговой маркой для HDX (High Definition Experience, практика высокого разрешения). HDX охватывает целый ряд технологий Citrix, которые описывают весь опыт пользователя, а не сосредотачивается на отдельном протоколе. Вы также можете встретиться с некоторыми подчинёнными торговыми марками, подпадающими по HDX, например, HDX MediaStream, HDX RealTime и HDX 3D.

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

Первая вещь, которую стоит сказать об этой карте состоит в том, что она не является платой GPU (Graphics Processing Unit, графического устройства). Я часто слышу некоторую путаницу вокруг этого, и пользователи полагают, что добавляя плату Apex они могли бы получить возможности OpenGL и DirectX, однако это не тот случай. Вы можете хорошо улучшить свои общие удобство и производительность, однако вы не добавите дополнительных свойств GPU и его функций.

Задача этой платы состоит полностью в том, чтобы снять нагрузку с вашего ЦПУ и хоста при обработке операций кодирования. Разгрузка кодирования изображений на плату аппаратного кодирования уменьшает пики в использовании ЦПУ, обеспечивая пользовательское удобство для всех пользователей вне зависимости от задач и уровня активности. В том случае, когда ваш ЦПУ умерщвляется повторяющимися действиями, функция разрузки делает возможным приложениям работать более гладко. Если уж сравнивать её с чем- то, так это плата TOE (TCP Offload Engine, механизм разгрузки TCP), применяемая в вашем мире IP хранения для iSCSI, которую намного лучше применять в виде аппаратного решения, чем использование программной реализации в инициаторе.

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

Teradici также имеет решение для усиления протокола PCoIP физических рабочих станций, а именно свою плату PCoIP Remote Workstation. Эта плата на самом деле не служит для сеансов виртуального рабочего места; вместо этого она позволяет добавить карту хоста Teradici в физическое рабочее место, подключиться к вашему рабочему месту и отсылать удалённую графику, аудио и USB с вашего рабочего места на оконечное устройство с включённым PCoIP, например, нулевой клиент. Представляйте себе это как захват вашего настольного ПК и его помещение в центр обработки данных, с последующей работой с ним по очень длинным кабелям видео, клавиатуры и мыши. Такой вариант использования типичен для реализации высоко энергопотребляющих монтируемых в стойку рабочих станций или ПК.

Фактически ваши пиксели пересылаются по сетевой среде, поэтому как это совмещается с Horizon View? Да очень просто, ваше соединение к физическому рабочему месту управляется с применением Horizon View и сервера соединений в качестве посредника (broker) вашего сеанса тем же способом, как вы присоединяетесь к машине виртуального рабочего места.

Blast Extreme является новым разработанным VMware протоколом, который применяет видео кодек H/264 в качестве параметра, если у вас имеются соответствующие доступные ресурсы ускорения GPU, которые позволяют доставлять вам пользовательскую практику на пользовательские устройства с включённым H.264. H.264 (MPEG-4 Part 10) является Advanced Video Coding (MPEG-4 AVC), который является стандартом видеосжатия на основе блочно- ориентированного сжатия перемещений. Это один из наиболее распространённых применяемых видео- форматов, который применяется для записи, сжатия и распространения видео- содержимого и используется для записи, сжатия и распространения видео- содержимого наподобие содержимого DVD.

В качестве протокола VMware, Blast присутствовал некоторое время и впервые был продемонстрирован в Horizon 5.2 несколько лет назад, где он был применён для предоставления HTML5 доступа к машинам виртуальных рабочих мест. Однако теперь он не ограничен предоставлением доступа HTML5; он также может доставлять практику применения пользователем на самые последние устройства клиента, которые применяют стандартные порты HTTPS.

Метод доставки Blast Extreme также является функциональным соответствием PCoIP, и также поддерживает аналогичную функциональность, такую как переназначение устройств клиента, USB, комплексное взаимодействие, а также локальную печать. То, гда начинаются различия, так это в потреблении ресурсов, поскольку Blast использует намного меньше циклов ЦПУ, а протокол доставки при использовании Blast намного более гибкий.

Как и PCoIP, Blast Extreme может компенсировать задержки или снижение полосы пропускания и осуществлять динамическую подстройку: однако он может использовать для своих целей как TCP, так и UDP, в то время как PCoIP является исключительно UDP поддерживаемым.

Вы можете подключать множество мониторов. В зависимости от вашего оконечного устройства поддерживается до черырёх мониторов, причём каждый может работать с разрешающей способностью 2560 x 1600. Или вы можете работать с тремя мониторами 4K, поддерживающими разрешающую способность 3840 x 2160 для удалённых рабочих мест Windows 7 с выключенным Aero.

Некоторые из оставшихся свойств Blast Extreme детализируются в приводимом ниже списке:

Теперь, когда у нас имеется хорошее понимание PCoIP, Blast Extreme и RDP, какой же из них выбрать?

Наиболее интригующей причиной окунуться в PCoIP состоит в том факте, что он применяет протокол UDP, который наилучшим образом соответствует потоковому содержимому и, тем самым, сам по себе даёт исключительные возможности для доставки виртуального рабочего места, однако, как мы уже обсуждали, Blast также применяет UDP в качестве протокола доставки. Просто чтобы подчеркнуть ещё раз, UDP не озабочен тем, как ваши данные поступают на оконечное устройство; он интересуется только скоростью доставки и того, насколько быстро они туда поступают.

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

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

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

Существуют варианты, когда PCoIP не является надлежащим протоколом, и Blast Extreme или RDP будут необходимы для применения. Один из наиболее часто встречающихся состоит в том, что необходимые порты блокируются в силу корпоративной политики, или же в удалённом местоположении, которое имеет ограниченные возможности соединений Интернета.

Когда ваше рабочее место отображается вам обратно, PCoIP использует порт UDP 4172 для отправки своих пикселей. Этот порт иногда блокируется, поскольку он обычно не используется. Результатом блокировки такого порта является то, что даже несмотря на то, что вы способны зарегистрироваться на своём виртуальном рабочем месте через клиента View, и все будет выглядеть хорошо, вы всё- таки будете получать чёрный экран. Чёрный экран обусловлен тем, что все пиксели блокируются при их отправке. В данном примере обходным приёмом будет доступ к рабочему месту из браузера с поддержкой HTML5 с применением Blast Extreme, котрый использует стандартные порты HTTPS. Мы рассмотрим это в доступной через интернет главе Глава 13. Тонкая настройка и удобство конечных пользователей.

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

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

Давайте начнём с краткой истории и основ. Технология для поддержки профессиональной графики реализовывалась несколькими этапами, причём начальная поддержка для 3D графики была предложена в vSphere 5 с View 5.0 с применением отрисовки (rendering) на программном уровне. Это предоставило нам такие возможности, как функциональность Windows Aero, однако всё ещё не было достаточно мощным для некоторых по- настоящему профессиональных вариантов применения из- за своего исполнения программным образом.

Затем, на следующем этапе было предоставлено решение для предоставления виртуализации GPU на аппаратном уровне, которое пришло вместе с vSpere 5.1, сделав возможным виртуальным машинам совместно применять некое физическое GPU, предоставляя виртуальным машинам пробрасывать (pass through) уровень гипервизора чтобы получать преимущества установленной на данном сервере хоста физической графической карты.

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

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

Всё это теперь изменилось. Начиная с выпуска View 5.2 в конце 2013, возможность предоставлять аппаратно ускоряемую графику стала стандартной продуктовой возможностью с появлением vSGA (Virtual Shared Graphics Acceleration, разделяемого виртуального графического ускорения), за которым затем последовал запуск vDGA (Virtual Dedicated Graphics Acceleration, виртуального выделенного графического ускорения).

В следующих разделах этой главы мы обсудим эти две технологии. Также мы обсудим самую последнюю партию графических возможностей в Horizon View, предоставляемых vGPU (Virtual Graphics Processing Unit, виртуальным графическим процессором).

Реализация vSGA (Virtual Shared Graphics Acceleration, разделяемого виртуального графического ускорения) делает возможным множеству машин виртуальных рабочих мест совместно использовать физическую карту GPU, которая установлена в ваш сервер хоста ESXi,который размещает эти машины виртуальных рабочих мест.

В данной модели ваши машины виртуального рабочего стола не имеют прямого доступа к выделенной физической карте GPU. Вместо этого в операционной системе виртуального рабочего места устанавливается стандартный графический драйвер VMware SVGA 3D, являющийся частью инструментария VMware. Этот SVGA драйвер является драйвером VMware, который осуществляет поддержку для DirectX 9.0c и OpenGL 2.1. вашей GPU в данном сервере ESXi. В данной конфигурации драйвер, поставляемый производителем графической платы (VIB) устанавливается в гипервизоре ESXi вместо операционной системы машины виртуального рабочего места.

Графические команды из сеанса пользователя перехватываются данным драйвером и отсылаются в его гипервизо, который управляет имеющимся в своём сервере ESXi GPU. В данной конфигурации драйвер, поставляемый производителем графической платы (VIB) устанавливается в гипервизоре ESXi вместо операционной системы машины виртуального рабочего места. Предоставление конкретному оконечному устройству пользователя работает в точности так же, как когда DevTAP кодирует поведение пользователя в PCoIP или Blast Extreme и предоставляет его терминальному устройству пользователя либо в браузер HTML5, либо клиенту Horizon.

Следующая схема отображает архитектуру vSGA:

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

Поддерживаемые настройки vSGA

vSGA будет поддерживать приложения на основе OpenGL 2.1 и DirectX 9, работающие в машинах виртуальных рабочих столов с Windows 7 либо 8, виртуализируемых в VMware vSphere 5.1 или старше с применением следующих производимых карт GPU:

За самым последним руководством совместимости обратитесь к ссылке http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsga.

Сколько виртуальных рабочих столов поддерживает vSGA?

Это вопрос, который обычно задают когда обсуждают предоставление аппаратной графики в рамках среды Horizon View, поэтому уделим некоторое время пониманию этого. В рамках Horizon View мы можем создавать различные пулы рабочих мест в зависимости от вариантов их использования, как мы это обсудим в Главе 7, Управление и настройка пулов рабочих столов, в которой один из таких пулов рабочих мест будет настроен для профессиональной графики. Обычно у вас нет необходимости предоставлять всем своим пользователям доступ к GPU с аппаратной поддержкой, следовательно, существует причина, по которой вам следовало бы создать пул именно для этого специального варианта использования.

Итак, чтобы ответить на этот вопрос, общее число виртуальных рабочих мест, которое вы можете назначить на GPU зависит от общего объёма VRAM (video memory, видео памяти), которое вы можете выделить каждому виртуальному рабочему месту. Вещь, о которой стоит помнить, состоит в том, что ресурс является совместно используемым и, по этой причине, применяются обычные правила виртуализации VMware. Первый момент, который стоит отметить, это то, как разделяется память.

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

Итак, значение по умолчанию VRAM, выделяемое машине виртуального рабочего места составляет 128МБ. Поэтому, в нашем примере, 64МБ поступает от GPU, а вторые 64МБ от его сервера хоста. Если вы затем возьмёте плату GPU, которая имеет 4ГБ VRAM на борту, у вас будет возможность поддерживать 64 виртуальных рабочих места (4ГБ, или 4096МБ, делённые по 64МБ из GPU дают в результате 64 машины виртуальных рабочих мест).

В рамках Horizon View вы можете выделить максимум 512МБ VRAM на одну машину виртуального рабочего места. Если вы примените это к предыдущему примеру, используя те же 4ГБ платы GPU, вы теперь уменьшаете общее число поддерживаемых виртуальных рабочих мест до значения 16 (4ГБ или 4096МБ поделённые на 256МБ из GPU = 16 машин виртуальных рабочих мест).

Ранее мы утверждали, что применяются обычные правила виртуализации VMware, поэтому давайте в точности поясним что это означает. Что обычно происходит, когда вы не можете соответствовать спецификации машины виртуального рабочего места и у вас нет достаточных ресурсов? Они не смогут загрузиться или включиться, верно? То же самое и с настройками для GPU. Если вы настроили пул рабочих мест на большее число машин виртуальных рабочих мест, чем может поддерживать этот GPU, тогда они не будут загружены.

В то время, как vSGA работают на основе совместного использования, vDGA (Virtual Dedicated Graphics Acceleration, виртуальное выделенное графического ускорения) позволяет индивидуальной машине виртуального рабочего места иметь свой собственный выделенный доступ к физической карте GPU, установленной в данном сервере хоста ESXi. Это делает возможным для машины виртуального рабочего места иметь больший уровень производительности графики, делая её исключительной для таких вариантов применения как приложения CAD/CAM, так как они поддерживают DirectX (9, 10 и 11), OpenGL 4.4, а также NVIDIA CUDA.

Следующая схема показывает архитектуру для vDGA:

Решение vDGA применяет функциональность, называемую VMDirectPath I/O pass-through (пробросом ввода/ вывода VMDirectPath), иногда также называемую пробросом (pass-through) PCI, что позволяет машине виртуального рабочего места пропускать запросы на уровень его гипервизора и осуществлять прямой доступ к аппаратным средствам на этом сервере хоста. В данном случае вашим оборудованием в запросе является GPU карта Nvidia.

Сколько виртуальных рабочих столов поддерживает vDGA?

В отличие от vSGA, которая ограничена общим объёмом оперативной памяти своей карты GPU, vDGA ограничен целиком общим числом GPU или GRID карт, которые вы физически можете поместить в свой сервер хоста. Это зависит от вашего производителя сервера и того, что он поддерживает.

Например, карта nVidia GRID K2 GPU имеет на борту два GPU, что будет означать, что вы сможете выделять четыре машины виртуальных рабочих мест для этой карты. В зависимости от вашей аппаратной серверной платформы вы можете устанавливать более одной карты, тем самым увеличивая общее число пользователей, имеющих доступ к аппаратным GPU в своих собственных виртуальных рабочих местах. {Прим. пер.: в настоящее время мы предлагаем Вам решения с 8ю GPU в шасси 2U/3U/4U и 10ю GPU в шасси 5U.}

Поддерживаемые настройки vDGA

Для vDGA осуществляется поддержка следующих карт GPU:

За самым последним руководством по совместимости, обращайтесь к ссылке http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vdga

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

Для vSGA, вы получаете масштабируемость в терминах общего числа пользователей, которые могут использовать эту плату GPU; однако, так как оно не применяет естественный драйвер, поставляемый производителем этого GPU, тогда некоторые ISV (Independent Software Vendor, независимые поставщики ПО) не будут соответствовать драйверу SVGA VMware, так как именно этот драйвер применяется.

Тогда вашим ответом для решения поддержки такого ISV будет применение vDGA, который будет использовать собственный драйвер графики этого производителя GPU, однако теперь мы ограничены в терминах масштабируемости, а также высокой стоимостью. Наличие машины виртуального рабочего места выделенного для GPU, причём только небольшое число GPU доступно на каждом сервере хоста, будет создавать весьма затратные решения. Следует сказать, что могут существовать варианты использования, при которых это было бы верным решением.

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

Это решение называется vGPU (Virtual Graphics Processing Unit, виртуальный графический процессор), и оно было введено в строй в выпуске версии 6.1 Horizon 6.

Ниже приводится архитектура для vGPU:

Для данной модели у нас имеются cобcтвенный драйвер nVidia установленным на машинах виртуальных рабочих мест, который затем перенаправляется на карту nVidia GRID в ваших серверах хоста. Сам же GPU затем фактически выполняет виртуализацию и квантование времени (time-slice), причём каждая машина виртуального рабочего места имеет некий квант (slice) такого времени.

Сколько виртуальных рабочих столов поддерживает vGPU?

Для vGPU общее число поддерживаемых пользователей/ машин виртуальных рабочих мест основывается на различных профилях. Подробности этих профилей приводятся на следующей диаграмме и представляют вам общее число пользователей, число поддерживаемых мониторов и тому подобное:

Как и в случае vDGA и vSGA решений, вам необходимо проверить, что вы имеете правильную поддержку оборудования. Кроме того, вам следует также проверить, что ваше приложение поддерживается в этих конфигурациях. Вы можете найти текущий перечень поддерживаемых приложений по следующей ссылке на веб- сайте Nvidia: http://www.nvidia.com/object/grid-isv-tested-applications.html.

Как и в случае с профессиональной графикой, если мы обсуждали работу универсальных решений взаимодействия или сеансов VoIP на рабочем месте VDI пару лет назад, я описывал бы их как Kryptonite для VDI! Хотя он технически работает, первый вызов может иметь приемлемую производительность, однако при добавлении большего числа пользователей, вы в конечном счёте ставите серверы на колени тем объёмом создаваемого обмена и ресурсов, требующихся для проведения вызовов. В конечном счёте практическое применение стало бы полностью непригодным. Комплексные взаимодействия были не самым лучшим вариантом использования VDI.

Однако, всё это изменилось и вы теперь можете успешно применять решения комплексных взаимодействий на своих виртуальных рабочих местах. Именно это всегда было великолепным вариантом применения - развёртывание комплексного взаимодействия при помощи VDI; только это никогда не работало, например, в рамках среды центра вызовов (call center) с возможностью предоставления решения DR (Disaster Recovery, восстановления после сбоев), или для предоставления пользователям возможности домашней работы в снегопад.

Итак, почему оно не работало? Если просто, это происходило по той причине, что когда вы помещаете свой вызов VoIP в вашем виртуальном рабочем месте, этот вызов должен пройти через протокол PCoIP, создавая проблему с полосой пропускания и вызывая низкую производительность вашего рабочего места, а также размещая дополнительную нагрузку на ваши серверы в центре обработки данных при получении процесса вызова. Это подробно отображено на следующей схеме, которая показывает как это было раньше и конечный результат впоследствии:

Чтобы решить эти проблемы и сделать работающее решение, VMware сосредоточилась на трёх основных областях и предоставило следующие новые функции/ расширения:

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

Стек управления вызовом (стек SIP при использовании сигналов SIP, Session Initiation Protocol - протокола установления сеанса) взаимодействует с управляющим сервером или менеджером вызова для регистрации или установления этого вызова.

Механизм среды на вашем устройстве клиента выполняет кодирование и декодирование потоков голоса и видео в поддерживаемые кодеки аудио и видео, а затем направляет эти VoIP/ видео потоки напрямую на другое оконечное устройство (как то предписывает сервер менеджера вызова), тем самым, настраивая вызов точка- точка, который минует ваш центр обработки данных. Это теперь исключает эффект игольного ушка.

В настоящее время VMware поддерживает решения от Cisco, Mittal, Avaya и Microsoft Lync 2013. В следующем разделе мы обсудим решение Microsoft Skype (Lync).

Horizon View предоставляет сертифицированную поддержку Microsoft Lync 2013, или Skype for Business, как оно теперь называется. Она включает полную поддержку для VoIP и видео. Следующая схема отображает процесс того как этот клиент работает:

Чтобы включить Skype, вам необходимо проверить, что встраиваемый модуль VDI установлен на оконечном устройстве вместе с клиентом View или клиентом Microsoft Skype. VMware реализовал DVC (Dynamic Virtual Channels, динамичные виртуальные каналы) Microsoft внутри своего протокола PCoIP для включения этой функциональности. DVC предоставляет путь взаимодействия между вашей виртуальной машиной и оконечным устройством клиента.

Существуют некоторые ограничения для данного решения, о которых следует упомянуть:

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

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

Это то, как работает аудио вход, однако аудио вход при использовании 3.5 мм разъёма не работало совсем. Аудио выход работал при использовании свойства перенаправления PCoIP, что было намного лучше чем использование перенаправления USB.

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

RTAV (Real-Time Audio Video аудио- видео- в реальном масштабе времени) не переправляет звуковые устройства и веб камеру при помощи USB. Вместо этого, такие устройства остаются локальными на стороне клиента, а звук/ картинка извлекаются из локальных устройств. Звук/ изображение затем кодируются и доставляются на вашу гостевую виртуальную машину, после чего выполняется их декодирование. Виртуальная веб- камера и виртуальный микрофон устанавливаются в гстевой виртуальной машине, которые затем и воспроизводят получаемые звук/ видео. Вы увидите элементы для VMware Virtual Microphone и VMware Virtual Webcam в своём менеджере устройств вашей машины виртуального рабочего места.

RTAV может поддерживать следующее:

Свойство Перенаправления содержимого URL (URL Content Redirection) позволяет вам настраивать URL для открытия либо в локальном браузере на терминальном устройстве, либо открывать на машине виртуального рабочего места. Какое содержимое открывается где настраивается с применением GPO.

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

Существует два типа URL, которые вы можете настраивать на перенаправление:

В этом разделе мы собираемся быстро указать на нашего клиента Horizon View, поскольку он является важным компонентом всего решения и способом, которым вы получаете моментальные снимки экрана вашей машины виртуального рабочего места удалённо.

Клиент View это в основном то место, в котором осуществляется декодирование и отображение на вашем терминальном устройстве. Существует два различных типа клиентов View, версии на основе программного обеспечения, которая устанавливается на терминальном устройстве пользователя и аппаратной версии, которая использует нулевых клиентов (zero clients).

Более подробно мы рассмотрим параметры вашего клиента View в Главе 10, Опции клиента Horizon View.

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