понедельник, 27 ноября 2017 г.

Баг: Blast + Единый клиент JaCarta + ThinOS = черный экран

Недавно наткнулся на проблему с черным экраном при подключении к виртуальной рабочей станции по протоколу VMware Blast с тонкого клиента Dell Wyse с ОС ThinOS при аутентификации с использованием смарт-карты JaCarta. После подключения на экране на короткое время показывается экран входа в ОС, а затем черный экран вместо рабочего стола.

В Event Log тонкого клиента отображается следующее событие:
12:24:37 pool: trap 14, EIP 0x6fcbee26, CR2 0xff18dc37
В журналах Blast на виртуальной рабочей станции появляются следующие сообщения:
2017-11-10 11:40:01.142+0300 [ERROR] 0x150c vncsession::VNCSessionVVCAsyncSocketError: Error callback, error: 4, asock:0000000001F9F620
2017-11-10 11:40:01.142+0300 [WARN ] 0x150c vncsession::VerifyCloseReason: Close reason was never set. Setting to reason:5.
2017-11-10 11:40:01.142+0300 [ERROR] 0x150c vncsession::HandleAsyncSocketError: Error:4 on asock:0000000001F9F620, CloseReason:5.
2017-11-10 11:40:01.142+0300 [INFO ] 0x150c vncsession::HandleAsyncSocketError: Forcibly close VNCSession due to Asyncsocket error
2017-11-10 11:40:01.142+0300 [INFO ] 0x150c vncsession::Stop: Stopping VNCSession, reason:5.
Баг встречается только в том случае, если для аутентификации используются смарт-карты JaCarta, а внутри ВМ установлен Единый Клиент JaCarta.

Для решения проблемы есть следующие обходные варианты:
  1. Перезагрузить клиент (или извлечь смарт-карту если на View Connection Server включена настройка Disconnect user sessions on smart card removal) и заново войти в сессию.
  2. Использовать протокол PCoIP вместо Blast.
  3. Использовать аутентификацию по паролю вместо смарт-карты.
  4. Удалить Единый Клиент JaCarta и вместо него установить JaCarta PKI для Windows.

среда, 22 ноября 2017 г.

Видео: автоматическая настройка тонкого клиента Dell Wyse с ThinOS

В продолжение статьи о тонких клиентах Dell Wyse с операционной системой ThinOS выкладываю небольшое видео с демонстрацией автоматической настройки и обновления ТК через файл wnos.ini.

вторник, 7 ноября 2017 г.

Немного о дизайне VDI. Часть 6. Лицензирование VDI

Продолжение цикла статей о дизайне VDI. Предыдущие части доступны по ссылкам:
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации

6.1 Требования к лицензированию VDI сред

Не малую долю в стоимость внедрения VDI вносит необходимость лицензирования ПО. Для работы VDI могут потребоваться следующие лицензии:
  • Лицензии на брокеры VDI и ПО виртуализации (VMware Horizon, vSphere, vCenter, vSAN).
  • Лицензии на клиентские ОС (Microsoft Windows 7, Windows 10).
  • Лицензии на ОС для служебных ВМ и терминальных серверов (Microsoft Windows Server 2016, Windows Server CAL, RDS CAL).
  • Лицензии на прикладное ПО, запускаемое на виртуальных десктопах (Microsoft Office, антивирусное ПО, WinRAR и прочее).
  • Лицензии на вспомогательное ПО: СУБД, мониторинг, резервное копирование, управление клиентскими устройства и прочее.

6.2 Лицензирование VMware Horizon

Лицензии VMware Horizon включают в себя право на использование различных продуктов и технологий VMware, но в первую очередь, необходимы для работы ключевого компонента VDI инфраструктуры VMware – сервера View Connection Server. После развертывания View Connection Server требуется вводит лицензионного ключа, без которого сервер не будет принимать подключения от пользователей и выводит ошибку об отсутствии необходимой лицензии.

VMware Horizon может лицензироваться по именованным пользователям (Named User) или по числу одновременных подключений (Concurrent), Concurrent лицензии являются более дорогими (приблизительно на 60% дороже, чем Named). Выбор типа лицензирования зависит от количества одновременно работающих пользователей. Если в вашей организации VDI используется сотрудниками, работающими в несколько смен (производство, Call Center), то Concurrent может быть выгоднее. Если же количество одновременно работающих сотрудников в среднем близко к максимальному, то имеет смысл выбирать Name User. Также следует учитывать, что Named User лицензии доступны только в редакциях Advanced и Enterprise.
Лицензии Horizon поставляются отдельно, либо в составе бандла Workspace ONE в редакции Enterprise, который также включает в себя лицензии на ПО AirWatch.

Существуют два типа поставки лицензий – Add-On и Bundle.

В Bundle помимо самих лицензий Horizon View также входят лицензии vSphere Desktop, vCenter Desktop и vSAN Desktop Advanced (присутствует в Horizon в редакциях Advanced и Enterprise).

vSphere Desktop функционально идентичен vSphere Enteprise Plus, однако отличается по типу лицензирования (в vSphere for Desktop лицензируется не по сокетам/процессорам, а по количеству запущенных ВМ), а также имеет лицензионные ограничения – на хостах с vSphere Desktop возможно запускать только виртуальные десктопы, а также служебные ВМ, обеспечивающие работу VDI инфраструктуры (брокеры View Connection Server и Security Server, серверы vCenter, серверы мониторинга VDI, серверы резервного копирования VDI и т.д.). Аналогичные ограничения касаются vCenter Server Desktop и vSAN Advanced Desktop. С использованием vSAN Advanced Desktop связан еще один момент. Данная редакция не позволяет использовать функцию территориально распределенного кластера (stretched vSAN Cluster), которая присутствует только в Enterprise редакции. По этому причине, при необходимости организации катастрофоустойчивой VDI инфраструктуре на vSAN вам потребуется дополнительно приобрести лицензии vSAN Enterprise, vSAN Enterprise Desktop, либо vSAN Enterprise for Desktop Add-on (http://blog.vmpress.org/2017/08/vmware-vsan-enterprise-for-desktop-add.html).

Если вы решили приобретать лицензии vSphere for Desktop отдельно (например, для VDI сред на базе vSphere + Citrix XenDesktop), там вам следует помнить о необходимости покупки лицензий на сервер управления vCenter Server. К сожалению, VMware не позволяет купить vCenter Server Desktop отдельно вне бандла Horizon, поэтому в этом случае вам потребуется приобрести полноценные лицензии vCenter Server Foundation или Standard.

Вариант Add-On, доступен только для редакции Horizon Standard, дешевле, т.к. не включает в себя лицензии vSphere Desktop и vCenter Standard, и может пригодиться в тех случаях, когда у вас уже есть развернутая и виртуальная инфраструктура VMware vSphere со всеми необходимыми лицензиями, а также для небольших SOHO инсталляций или в филиалах, где на одних и тех же серверах работают виртуальные десктопы и инфраструктурные ВМ.
Существуют три основные редакции Horizon: Standard, Advanced и Enterprise, плюс специальная редакция Horizon for Linux для запуска VDI на виртуальных десктопах с ОС Linux. Сравнение функциональных возможностей редакций Horizon приведены в таблице.

Функции
Horizon Standard
Horizon Advanced
Horizon Enterprise
Horizon for Linux
Лицензирование по пользователям (Per User)
Нет
Да
Да
Нет
Лицензирование по конкурентным подключениям(Concurrent)
Да
Да
Да
Да
Поддержка Windows десктопов
Да
Да
Да
Нет
Поддержка Linux десктопов
Нет
Нет
Да
Да
Поддержка Linked Clones
Да
Да
Да
Да
Поддержка Instant Clones
Нет
Нет
Да
Нет
Поддержка 3D (vSGA, vDGA, vGPU)
Да
Да
Да
Да
Add-on поставка
Да
Нет
Нет
Нет
Bundle поставка
Да
Да
Да
Да
vSphere Desktop
Да
Да
Да
Да
vCenter Desktop
Да
Да
Да
Да
Лицензии Mirage
Нет
Да
Да
Нет
Persona Management
Да
Да
Да
Нет
vSAN for Desktop Advanced
Нет
Да
Да
Нет
Публикация приложений с терминальных серверов
Нет
Да
Да
Нет
ThinApp
Да
Да
Да
Нет
Identity Manager
Нет
Да
Да
Нет
vRealize Operations for Horizon
Нет
Нет
Да
Нет
App Volumes
Нет
Нет
Да
Нет
User Environment Manager
Нет
Нет
Да
Нет

При планировании инфраструктуры следует учитывать, что для одной инсталляции Horizon View может быть указан только один лицензионной ключ. Соответственно, использование разных редакций (Standard, Advanced, Enterprise) и разных типов лицензирования (Named User, Concurrent) может быть осложнено из-за невозможности отслеживания и назначения лицензий конкретным пользователям. VMware явно не запрещает использовать разные лицензии в рамках одной инсталляции, но не рекомендует этого делать.

Дополнительная информация по лицензированию Horizon доступна по ссылке: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vmware-horizon-pricing-packaging-guide.pdf


6.3 Лицензирование клиентских ОС

Для виртуальных десктопов поддерживаются различные ОС:
  • Windows 7, 8, 10
  • Windows Server 2008 R2, 2012.
  • Ubuntu, CentOS, RHEL.
В большинстве VDI сценариев на виртуальные десктопы устанавливается одна из клиентских ОС Windows. Правила лицензирования клиентских ОС едины для любых VDI сред, будь то VMware Horizon, Citrix XenDesktop или Microsoft RDS.

Согласно лицензионной политике Microsoft, доступ к виртуальным десктопам с клиентской ОС должен осуществляться с устройства, имеющего действующую подписку Microsoft VDA (Virtual Desktop Access).

Microsoft VDA может быть приобретена в виде ежегодно обновляемой подписки на каждое устройство, с которого осуществляется доступ к VDI инфраструктуре.

В случае, если доступ к VDI инфраструктуре осуществляется с устройства с установленной лицензионной клиентской ОС Windows с действующей подпиской Software Assurance, VDA предоставляется бесплатно, на срок действия Software Assurance. Данный вариант может использоваться в тех случаях, когда в компании сотрудники компании продолжают работать на физических компьютерах, а VDI используют в качестве вспомогательной системы.

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

Также существует еще один вариант с получением права на запуск клиентских ОС при действующей подписке Windows Software Assurance per User, приобретаемой в рамках программ лицензирования Volume Licensing (http://download.microsoft.com/download/5/c/7/5c727885-ec15-4920-818b-4d140ec6c38a/Windows_SA_per_User_at_a_Glance.pdf).

В качестве альтернативы клиентским версиям Windows для VDI могут быть использованы серверные ОС Windows. Одним из преимуществ Windows Server Datacenter является возможность запуска неограниченного количества экземпляров ОС при условии, что лицензированы все ядра физического сервера.

Однако, при использовании Windows Server в качестве клиентской ОС вам также потребуется приобрести RDS CAL на каждое устройство или пользователя, который работает с VDI. Лицензия RDS CAL может быть приобретена отдельно, либо получена в составе подписки VDI Suite, которую требуется ежегодно продлять (по аналогии с Microsoft VDA).

В свете изменения политики лицензирования серверной ОС Windows Server 2016 с сокетов на ядра, и соответствующим увеличением стоимости лицензий для серверов, имеющих многоядерные процессоры, данный вариант стал менее привлекательным по сравнению с VDA подпиской. Другим недостатком серверных ОС Windows по сравнению с клиентскими, является то, что часть ПО может не работать на серверных ОС по лицензионным или техническим причинам. Не все производители поддерживают запуск своего ПО на серверных ОС.

Для специфических сценариев возможно развертывание виртуальных десктопов с ОС Linux. Horizon поддерживает следующие дистрибутивы Linux:
  • Ubuntu
  • RHEL
  • CentOS
  • NeoKylin
В основном сценарии работы с Linux затрагивают области работы проектировщиков с различными CAD/CAM системами. В том случае, когда вам требуется поддержка ОС Linux вам может потребоваться приобрести ее у разработчика дистрибутива. Например, Red Hat предоставляет несколько вариантов приобретения поддержки на RHEL для ВМ:
  • Приобретение поддержки на каждую ВМ по отдельности (Red Hat Enterprise Linux Desktop или Red Hat Enterprise Linux Workstation).
  • Приобретение поддержки на физический сервер и все ВМ, которые на нем запускаются (например, Red Hat Enterprise Linux for Virtual Datacenters)
Дополнительные материалы:

6.4 Лицензирование серверных ОС для служебных ВМ

Многие службы, необходимые для работы VMware Horizon работают поверх ОС Windows Server, что требует приобретения соответствующих лицензий.
Ранее мы уже обсуждали, что для многих инсталляций VDI рационально запускать служебные ВМ, обеспечивающие работу VDI, на отдельных хостах. Это позволит упростить и удешевить лицензирование.
Согласно лицензионной политике Microsoft, Windows Server лицензируется по ядрам процессоров физического сервера. При этом должны соблюдаться следующие лицензионные требования:
  • На один физический процессор должно быть отлицензировано не менее 8 ядер (даже в том, случае, если у вас используются процессоры с меньшим кол-вом ядер).
  • На один физический сервер должно быть отлицензировано не менее 16 ядер (даже в том, случае, если в сервере установлен всего один процессор).
  • Согласно лицензионной политике организации имеют право переносить (перепривязывать) лицензии с одного сервера на другой не чаще, чем раз в 90 дней.
В таблице приведен пример необходимого количества лицензий Windows Server на ядра в зависимости от конфигурации сервера.
Кол-во ядер в процессоре
1-процессорный сервер
2-процессорный сервер
4-процессорный сервер
1-ядерный процессор 16 16 32
2-ядерный процессор 16 16 32
4-ядерный процессор 16 16 32
6-ядерный процессор 16 16 32
8-ядерный процессор 16 16 32
10-ядерный процессор 16 20 40
12-ядерный процессор 16 24 48
14-ядерный процессор 16 28 56
16-ядерный процессор 16 32 64
18-ядерный процессор 18 36 72
20-ядерный процессор 20 40 80
22-ядерный процессор 22 44 88
24-ядерный процессор 24 48 96
26-ядерный процессор 26 52 104
28-ядерный процессор 28 56 112
30-ядерный процессор 30 60 120
32-ядерный процессор 32 64 128

Windows Server 2016 доступен в двух основных редакция: Standard и Datacenter. Помимо функциональных различий редакций, для Standard и Datacenter действуют разные правила в отношении запускаемых ВМ. При лицензировании редакции Standard на физическом сервере возможно запустить до двух экземпляров ОС (OSE - Operating System Environments), например, две ВМ, при условии, что на самом физическом сервере не устанавливается никаких приложений.

При необходимости запуска уже четырех ВМ потребуется увеличить количество привязанных лицензий в два раза, для шести – в три, и так далее.
При лицензировании Datacenter на физическом сервере можно запустить неограниченно количество экземпляров ОС (OSE).

Редакция Standard может быть более выгодной для небольших инсталляций, в которых требуется запускать пару-другую ВМ с ОС Windows, однако вы должны следить за тем, чтобы не было нарушений лицензионной политике. В случае, когда вы объединяете хосты в HA & DRS кластер, ВМ могут переноситься с одного хоста на другой, что может повлечь нарушение лицензионной политики. Для этого вам может потребоваться привязать дополнительные лицензии Windows Server Standard к каждому хосту, а также использовать политики VM to Host Affinity.

Помимо лицензирования самого сервера вам также потребуется приобрести Device CAL/User CAL на каждое устройство или пользователя, который работает с серверами Windows.
Пару слов следует сказать о лицензировании СУБД Microsoft SQL Server. SQL Server может потребоваться для работы различных компонентов виртуальной инфраструктуры – vCenter Server, View Composer, View Connection Server, App Volumes и Identity Manager. Помимо бесплатной SQL Server Express для Horizon View, поддерживаются старшие редакции Standard, Enterprise и Datacenter, которые предоставляют расширенные возможности по резервному копированию и обеспечению доступности БД.

SQL Server может лицензироваться по ядрам сервера (Core) или по числу инсталляций и пользователям (Server + CAL). С лицензированием Server + CAL действует правило мультиплексирования, которое в разных источниках и разными представителями вендоров и дистрибьюторов трактуется по-разному, поэтому более простым вариантом лицензирования будет лицензирование по ядрам. В случае использования SQL Server Standard можно лицензировать ядра виртуальной машины (минимально, 4 ядра).

Дополнительные материалы:

6.5 Лицензирование приложений

При лицензировании приложений следует рассматривать юридическую и техническую сторону вопроса.

Если какое-то ПО лицензируется на устройство (per device), то в случае использования VDI несмотря на то, что виртуальные рабочие станции запускаются на меньшем количестве серверов, производитель ПО может потребовать приобрести лицензии на программное обеспечение по количеству виртуальных рабочих станций или устройств, с которых осуществляется доступ к VDI. Примером такого ПО является Microsoft Office, которое использует принцип Remote Use Rights.

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

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

В тех случаях, когда требуется контроль за количеством выданных лицензий, следует уточнить – какой механизм подсчета используется. Так, например, некоторое ПО различает рабочие станции по идентификатору безопасности SID или уникальному сертификату, который генерируется и сохраняется на компьютере во время установки. В случае использования механизма клонирования Linked Clones совместно с Quick Prep, все рабочие станции будут иметь одинаковый SID компьютера и набор файлов, что нарушит работу механизма подсчета лицензий.

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

Дополнительные материалы:

6.6 Технические аспекты активации

Для активации Windows и Office в больших VDI инфраструктурах рекомендуется использовать – KMS сервер.

Для сторонних продуктов следует проработать вопрос лицензирования в VDI средах. Многие продукты уже учитывают наличие VDI инфраструктур (например, ПО антивирусной защиты). Однако, в ряде случаев может потребоваться дополнительные действия при автоматизированном развертывании виртуальных десктопов. В частности, можно подготовить скрипт, выполняющий добавление лицензионного ключа и активацию приложений. Запуск скрипта можно настроить в автоматическом режиме в настройках пула при создании нового десктопа. Важным моментом является то, что ряд приложений могут генерировать уникальные номера в момент установки и для корректного подсчета лицензий и активации, может потребоваться удалять информацию об этих идентификаторах из эталонного образа перед началом клонирования. Кроме того, лицензия может привязываться к SID компьютера, поэтому я ряде случаев вариант с Quickprep подготовкой клонированных образов может не подойти, и придется использовать Sysprep подготовку.

Продолжение доступно по ссылкам: