понедельник, 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 подготовку.

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

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

Немного о дизайне VDI. Часть 2. Постановка задачи

Сегодня мы продолжаем говорить о дизайне VDI. Первая часть доступна по ссылке: http://blog.vmpress.org/2017/09/vdi-1.html

2.1 Требования

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

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

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

Зачастую, когда речь заходит о VDI, то заказчики имеют довольно смутные представления – каким требования должен удовлетворять VDI. Но если вы выступаете в качестве генератора идей, помните, что дополнительные возможности, которые вы предлагаете реализовать, приводят к усложнению системы, что в свою очередь может привести к удорожанию проекта. Простой пример – если спросить у любого заказчика – что он выберет, систему с надежностью 99.99% (1 час простоя в год) или 99.9% (8 часов простоя в год), будьте уверены, что он выберет первый вариант, пока не увидит стоимость этих двух решений, которая может отличаться в разы.

Условно, требования к системе можно разделить на две группы: функциональные и нефункциональные. Функциональные требования описывают то, что система должна делать, например:
  • VDI должен обеспечивать удаленное подключение пользователей к персональным виртуальным рабочим местам с ПК под управлением ОС Windows или MAC OS X, а также тонких клиентов и мобильных устройств под управлением Android или iOS.
  • VDI должен предоставлять возможность централизованного развертывания и обновления виртуальных десктопов из единого образа.
  • Система должна автоматически выключать виртуальные десктопы без активных сеансов пользователей.
  • Хранение данных ВМ должно осуществляться на выделенной системе хранения данных. Все серверы виртуализации должны иметь подключение к системе хранения.
Нефункциональные требования описывают то, как система должна выполнять те или иные функции. При проработке функциональных требований можно полагаться на модель AMPRS (Availability, Manageability, Performance, Recoverability, Security). Данная модель, конечно, не описывает все многообразие требований (можно вспомнить о таких критериях, как: Interoperability, Scalability, Supportability, Usability и многих других), которые могут предъявляться к системе, но может послужить некой отправной точкой для того, чтобы упростить формирование данных требований.

Availability определяет требования относящиеся к доступности системы, например:
  • Система должна функционировать в режиме 12x5 (рабочие дни с 8:00 до 20:00). Система должна быть спроектирована с учетом 99.99% доступности.
  • Физические серверы должны иметь блоки питания, резервируемые по схеме 1+1.
  • Локальные накопители, должны быть объединены в RAID-1 для обеспечения отказоустойчивости.
  • Все служебные ВМ и виртуальные десктопы должны быть защищены при помощи технологии VMware HA, обеспечивающей автоматический перезапуск ВМ на других узлах при выходе из строя одного из серверов кластера.
  • Подключения серверов к дисковому хранилищу должны быть задублированы, должна использоваться технология multipathing, обеспечивающая автоматическое переключение на резервный путь в случае отказа одного из контроллеров СХД, FC коммутатора, порта FC HBA адаптера или обрыва кабеля.
  • В сервере должны присутствовать не менее двух сетевых адаптеров. Порты сетевых адаптеров должны быть объединены в общий логический канал (транк) при помощи протоколов статической (EtherChannel) или динамической (LACP) агрегации каналов.
Manageability – требования к управляемости:
  • VDI должен обеспечивать управление посредством централизованной консоли администрирования HTML5, не требующей установки дополнительных плагинов, доступ к которой осуществляется через web-браузер Google Chrome или Mozilla Firefox.
  • VDI должен поддерживать управление из командной строки. VDI должен иметь интеграцию с PowerShell посредством установки и запуска модулей расширения, позволяющих выполнять типовые операции по созданию, удалению, изменению конфигурации виртуальных десктопов из командной строки.
  • VDI должен поддерживать интерфейс REST API для интеграции со сторонними системами оркестрации и автоматизации.
Performance – требования к производительности системы:
  • Среднее время загрузки виртуального десктопа после включения не должно превышать 2 минут.
  • Средняя утилизация процессора и ОЗУ серверов виртуализации при одновременной работе всех виртуальных десктопов не должно превышать 80%.
  • Среднее время отклика при выполнении операций ввода/вывода дисковой подсистемы не должно превышать 15 мс.
  • Время входа пользователя в систему с учетом загрузки профиля размером 2 ГБ не должно превышать 30 секунд.
  • Каждая виртуальная рабочая станция должна иметь не менее 2х виртуальных процессоров (vCPU), не менее 4 ГБ ОЗУ.
Recoverability – требования к восстановлению системы после сбоя. Сюда относятся требования к RPO и RTO. RPO (recovery point objective) определяет временной интервал между заданиями резервного копирования или репликации данных и тот объем данных, которые допустимо потерять в случае сбоя системы. RTO (recovery time objective) – время, которое потребуется на восстановление системы. В реально жизни помимо RTO также следует принимать во внимание другой параметр WRT (Work Recovery Time) – время необходимое на проверку и подтверждение того, что система успешно восстановлена и готова к работе. Сложив значения двух параметров, мы получаем Maximum Tolerable Downtime (MTD) – максимальное время, в течение которого система может быть недоступна.

MTD = RTO + WRT

Важно донести до заказчика, что на практике возможно реализовать системы с RPO и RTO близким к 0, стоимость подобных решений может выйти за рамки бюджета проекта.
При формировании требований к восстановлению важно определить перечень аварийных сценариев, от которых требуется защищаться, а также, что к разным компонентам системы, и к системе в целом могут предъявляться разные требования к восстановлению, например: 
  • В случае отказа системы хранения на основной площадке должна быть предусмотрена возможность запуска системы с использованием системы хранения, расположенной на резервной площадке. Время восстановления не должно превышать 1 часа, допустима потеря данные не более чем за 2 часа до момента отказа.
  • Время восстановления одного виртуального десктопа в случае потери данных не должно превышать 2 часов (RTO), данные, хранящиеся в профиле пользователя, должны быть восстановлены за интервал не позднее 48 часов с момента сбоя.
  • Для высококритичных ВМ должны использоваться средства, обеспечивающие восстановление работоспособности ВМ в течение 15 минут, без потери данных. 
Security – требования к безопасности. Примеры:
  • Для пользователей, подключающихся к виртуальным рабочим станциям из сети Интернет, должна выполняться двухфакторная аутентификация с использованием смарт-карт.
  • На рабочих местах пользователей должен быть установлен антивирусный агент, осуществляющий антивирусную проверку файлов, с которыми работает пользователь, в реальном времени и по расписанию один раз в день.
  • Для всех служебных учетных записей должны использоваться уникальные пароли, отвечающие критериям безопасности (длина не менее 12 символов, в пароле одновременно должны использоваться заглавные и строчные буквы, цифры и спец. символы).
  • Все операции, выполняемые администраторами в консоли управления, должны заноситься в журнал и отправляться на внешний Syslog сервер.
Помимо озвученных выше требований, к нефункциональным требованиям можно отнести требования по использованию определенных версий и редакций ПО. Это может быть продиктовано необходимостью обеспечить совместимость со сторонними системами, например, системой мониторинга или СРК. Однако с указанием конкретных версий (если только это не обусловлено необходимостью использования определенных сертифицированных дистрибутивов) связана проблема того, что постоянно выходят новые версии ПО, и указав старые версии вы сами можете себя ограничить. Более корректным может быть замена это на требования вида:
  • На оборудование должны быть установлены последние актуальные версии микропрограммного обеспечения, рекомендуемые вендором/производителем оборудования.
  • Для развертывания VDI должны использоваться версии ПО, совместимые с существующим ПО мониторинга и резервного копирования.
При фиксировании требований в техническом задании, важно описать их таким образом, чтобы у исполнителя и заказчика не возникало двойного трактования. Также следует заранее продумать, каким образом планируется подтверждение выполнения требований на этапе приемки системы. В первую очередь это касается нагрузочного тестирования и проверки отказоустойчивости, каким образом вы планируете доказывать, что система может масштабироваться до 10000 виртуальных десктопов, или выдерживать отказ одной из площадок?

2.2 Риски

Риски – это возможные неблагоприятные ситуации, которые могут возникать на различных этапах проекта, и которые могут приводить к затягиванию сроков или увеличению затрат на проект. Примеры рисков:
  • Подрядчик не успевает закончить работы в срок, из-за чего увеличивается длительность проекта.
  • Между ЦОД и офисом организован один канал связи, его падение может повлиять на доступность системы для пользователей.
  • Отсутствие расширенной поддержки со стороны производителя с заменой в течение 4 часов или ЗИП фонда не позволит гарантировать RTO в случае отказа оборудования.
  • Используется серверное оборудование, которое официально не совместимо с данной версией ПО, что может привести к возникновению проблем с производительностью или доступностью системы.
  • Отсутствие процедуры тестирования обновлений может повлечь за собой появления в производственной среде проблем из-за наличия ошибок в ПО.
  • У специалистов нет опыта работы с данным оборудованием/ПО, что может привести к увеличению времени выполнения работ по настройке.
При постановке задачи следует составить перечень наиболее вероятных и опасных (затратных) сценариев и вариантов, которые позволят снизить вероятность их возникновения и их влияние на проект. Описание рисков в техническом задании может повлиять на позицию заказчика в выборе того или иного решения, а также послужит своеобразной страховкой для исполнителя.

2.3 Допущения

Допущения – это утверждения, которые не были проверены на практике, и которые используются в качестве входных данных для проектирования. Примеры допущений:
  • Между ЦОД и офисом организован канал передачи данных, пропускной способности которого достаточно для работы 1000 пользователей.
  • Производительности существующего дискового массива/серверов достаточно для размещения виртуальных рабочих станций.
  • В ЦОД есть место для установки нового оборудования, система электропитания и охлаждения рассчитана на дополнительную нагрузку.
  • Прикладное ПО и периферийное оборудование, с которым работают пользователи на физических компьютерах, совместимо с VDI.
Во многих случаях допущения можно оценивать с позиции рисков – существует риск, что производительности не хватит, ПО не заработает и т.д. Отличием допущения от риска является то, что мы можем проверить его достоверность, собрав дополнительную информацию, и проведя необходимые замеры или расчеты.

2.4 Ограничения

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

Пожалуй, самым известным и неприятным ограничением проекта является его бюджет. Другие примеры ограничений:
  • Использование оборудования или ПО определенных производителей, использование определенных моделей/версий, определенных конфигураций.
  • Необходимость использования существующего оборудования или ПО для построения системы.
  • Ограничения, накладываемые законодательством (например, использование ПО, сертифицированное ФСТЭК или внесенное в Единый реестр российских программ).

2.5 Вопросы

В проектах постоянно возникают ситуации, когда заказчик не может или не желает самостоятельно сформировать техническое задание. В этом случае приходится брать инициативу в свои руки и по крупицам собирать необходимую информацию.
Помочь в определении требований, рисков, допущений и ограничений может заранее проработанный перечень вопросов. Вот пример некоторых вопросов, которые можно задать на интервью с заказчиком.
  1. Для каких целей предназначен VDI? Какие функции будут выполнять пользователи в VDI? Предполагается обеспечить полноценную работу сотрудников, или предполагается работа только с определенным набором ПО?
  2. Какое количество пользователей планируется перевести в VDI?
  3. Все пользователи выполняют одинаковые задачи на рабочих станциях? Существует ли разделение пользователей по группам в зависимости от задач, набора установленного ПО или конфигурации рабочей станции (например, оператор call-центра, менеджер, бухгалтер, дизайнер, VIP-пользователь)?
  4. Работуют ли пользователи с мультимедиа? Прослушивают аудиофайлы, просматривают видео (видео-файлы, flash анимация, 3D анимация)? Запускают ли пользователи приложения для работы с 3D (Google Earth, ГИС системы, CAD/CAM системы)?
  5. Требования к доступности – какие показатели RTO/RPO для рабочих станций? Какой режим работы сервиса? Требуется ли высокая доступность для рабочих станций, требуется ли обеспечения катастрофоустойчивой защиты VDI? Есть ли вторая и третья площадки? (Когда вы задаете вопрос о допустимом времени простоя, то вероятнее всего ответ будет – ноль. Вместо этого можно задать вопрос – за какое время сейчас выполняется восстановление рабочей станции при отказе? Каким образом выполняется процедура восстановления?)
  6. Какая конфигурация у существующих рабочих станций? Приведите перечень ПО и периферийного оборудования, которое используют пользователи? (Внедрение VDI может повлиять на выбор тех средств, что используется для физических рабочих станций, например, потребует смены решения для антивирусной защиты или резервного копирования, управления рабочими станциями)
  7. Определен ли бюджет проекта? (Важно понимать предельную стоимость. Заказчик может долго мечтать о новых блейд-серверах, территориально-распределенных кластерах, графических ускорителях и all-flash массивах, блестящих тонких клиентах и 4K дисплеях, но каждое такое пожелание приводит к увеличению стоимости реализации, важно понимать, когда следует остановиться и начать уменьшать аппетиты).
  8. Какие подсистемы должны быть включены в проект? Требуется ли модернизировать сетевую инфраструктуру, СХД, СРК, систему мониторинга, закупать дополнительные лицензии на прикладное ПО и т.д.? Какие существующие ресурсы можно задействовать в проекте? (Не стоит ожидать, что у заказчика будет под рукой свободные серверы и СХД, подходящее для внедрения VDI, если только это не небольшой пилотный проект. А вот балансировщики, система резервного копирования, файловый сервер, или же вычислительные ресурсов виртуальной инфраструктуры для размещения служебных ВМ помогут снизить стоимость внедрения)
  9. Как организовано хранение пользовательских данных (настроек, профиля, документов) на текущий момент? Рассматривается ли вариант с переходом на централизованное хранение данных пользователей на файловом сервере?
  10. Какие средства антивирусной защиты используются на текущий момент? Готовы ли рассматривать другой продукт/вендора, который интегрируется с VDI?
  11. Как организована печать? Используется специализированное ПО для печати? Какие модели принтеров используются?
  12. Какие зоны ответственности в проекте? Кто выполняет настройку тех или иных компонентов, кто выполняет интеграцию с существующими системами заказчика? Кто выполняет миграцию пользователей в VDI и перенос данных с рабочих станций?
  13. Оборудование и ПО каких производителей предпочитает покупать заказчик? Какие ограничения есть в плане выбора моделей или аппаратной конфигурации?

2.6 Обследование

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

Помимо решений по управлению конфигурацией серверов и рабочих станций, вроде Microsoft SCCM или CMDB систем, можно использовать VMware Capacity Planner – средство, разрабатываемое VMware, которое доступно для партнеров компании, позволяющее выполнить инвентаризацию, сбор информации об утилизации серверов и рабочих станций, и на основании полученных данных выполнять сайзинг оборудования. Основные компоненты Capacity Planner, включая консоль управления и генератор отчетов размещаются в "облаке" VMware. В инфраструктуре компании развертывается сервер-коллектор, который собирает необходимую информацию, подключаясь к компьютерам по протоколам WMI (для ОС Windows) или SSH (для ОС Linux).

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

Другим распространенным средством является Microsoft Assessment and Planning (MAP) Toolkit. Он также позволяет выполнить сбор данных о конфигурации компьютеров, но что самое полезное - MAP предоставляет средства инвентаризации установленного ПО. В MAPT также присутствует встроенный инструмент для сайзинга, который позволяет определить количество физических серверов, которое потребуется для запуска ВМ.

Для обследования существующих виртуальных сред подойдет средство vSphere Optimization Assessment. VOA представляет собой тестовую версию vRealize Operations Manager – инструмента для мониторинга виртуальной инфраструктуры VMware. VOA может собирать статистику об утилизации вычислительных ресурсов и на основании полученных данных создавать отчеты и выдавать рекомендации по оптимальной конфигурации ВМ. Также VOA содержит инструмент по прогнозированию роста нагрузки на основании статистической информации и планировщик, который может показать достаточно ли в виртуальной инфраструктуре ресурсов для запуска определенного количества ВМ с заданными аппаратными ресурсами.

2.7 Техническое задание

После сбора необходимой информации наступает этап формирования технического задания (technical requirements), в котором фиксируются все требования, ограничения, риски и допущения.

Формат ТЗ может быть разным. В качестве основы можно руководствоваться стандартом ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы. Альтернативный вариант – описывать требования в формате, который часто используется зарубежными компаниями. в качестве примера можно привести документ
Для удобства указания на конкретные пункты ТЗ можно использовать сквозную нумерацию абзацев ТЗ, например:
5 Требования к системе5.1 Функциональные требования5.1.1 Система должна обеспечивать подключение...
После чего можно ссылаться на данное требование из других документов: "В соответствии с требованиями 5.1.1…".

Другой вариант – оформлять требования в виде таблицы и давать им уникальные идентификаторы, например:
Идентификатор
Требование
ФТ1Хранилище должно поддерживать протокол Fibre Channel для доступа к данным

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

В ТЗ описываются не только требования к самой системе, но и к инфраструктуре и смежным системам, с которыми интегрируется VDI. Требования доступа к VDI из Интернет накладывает ограничения на каналы связи м их пропускную способность доступность. Доступность VDI напрямую определяется доступностью ЦОД.

Допущения могут быть оформлены в виде требований к текущей инфраструктуре / к объекту автоматизации до начала работ по внедрению. например:
Для работы инфраструктуры требуется наличие следующих инфраструктурных сервисов: службы каталога, сервера точного времени, службы динамической конфигурации узлов DHCP, службы разрешения имен.
Также можно описать требования к каналам передачи данных – пропускной способности, задержкам, допустимым потерям пакетов, требования к клиентским устройствам с которых осуществляется доступ (версия ОС, требования к периферийному оборудованию, используемому при работе с VDI).

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

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

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

пятница, 22 сентября 2017 г.

VMworld Europe 2017

С небольшим запозданием опубликовал отчеты о посещении конференции VMworld Europe 2017.

Посты доступны по ссылкам: нулевой день, первый деньвторой и третий день.

Фотографии можно посмотреть тут.

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

Экзамен на статус VMware vSAN Specialist 2017

На прошлой неделе, находясь на конференции VMworld 2017 Europe, я пошел сдавать экзамен VMware vSAN 2017 Specialist (2VB-601). Это новый экзамен и статус, который стал доступен в начале августа, предназначается для администраторов и инженеров, которые специализируются на программно-конфигурируемых хранилищах VMware vSAN.

Причин сдать экзамен было несколько. Во-первых, я работую с vSAN, начиная с версии 5.5, и давно слежу за развитием данного продукта. Во-вторых, во время проведения VMworld предоставлялась 50% скидка на сдачу экзамена (оригинальная цена составляет 200$). В-третьих, всем успешно сдавшим экзамен, в качестве подарка выдается симпатичная рубашка поло Nike Golf Dri-FIT.

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

Накакой особенной подготовки для сдачи экзамена я не проходил, помог официальный гайд VMware Specialist: vSAN 6.x Badge Exam Exam Preparation Guide, включающий в себя описание основных тем экзамена, примеры вопросов и рекомендуемые темы для изучения.

Из материалов для самостоятельной подготовки рекомендую книгу Essential Virtual SAN (VSAN): Administrator's Guide to VMware Virtual SAN (2nd Edition) за авторством Дункана Эппинга и Кормака Хогана, книга написана по версии 6.2, но содержит много актуальной информации, а также VMware vSAN Design and Sizing Guide. И конечно, официальную документацию по продукту.

Если говорить о практической стороне - статус Specialist пока не требуется для получения партнерами компетенций, или возможности продавать или внедрять vSAN, поэтому особой ценности не несет. По пощеголять редкой рубашкой все-равно приятно.

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

Немного о дизайне VDI. Часть 1. Введение

1.1 О чем это

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

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

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

Всего планируется 12 частей / глав (количество, порядок и содержимое могут измениться на дальнейших этапах подготовки материала).

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

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

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

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

Пятая глава "Подсистема виртуализации" будет посвящена теме серверной виртуализации VMware vSphere. Здесь будут рассмотрены вопросы проектирования vCenter Server, Platform Services Controller, кластеров ESXi.

В шестой главе "Лицензирование VDI" будет затронута тема лицензирования программного обеспечения, необходимого для построения VDI.

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

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

В девятой главе "Сетевая подсистема" приводится информация о проектировании виртуальной сетевой подсистемы, а также кратко описаны основные функциональные возможности VMware NSX.

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

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

В последней, двенадцатой главе "Дополнительные сервисы" описывается проектирование дополнительных компонентов VDI – средств доставки приложений, мониторинг, управление профилями, данными и настройками пользователей.

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

Прогресс не стоит на месте, появляются новые технологии, продукты, решения, а вслед за ними и новые рынки, на которых присутствуют новые игроки и новые лидеры. Еще десять лет назад во всем Мире о VDI знали единицы, сегодня – для Citrix или VMware – это один из основных источников дохода и роста бизнеса, а вокруг технологий VDI строят свой бизнес множество компаний. Восемь лет назад Flash накопители были большой роскошью и использовались в основном для кэширования операций ввода-вывода или размещения небольших высоконагруженных баз, сегодня – в портфеле всех ведущих вендоров СХД присутствуют all-flash массивы, которые с успехом конкурируют с классическими дисковыми массивами по цене, Dell-EMC продал All-flash массивов XtremIO на 1 миллиард долларов, а в лидерах рынка присутствует компания Pure Storage, представившая свой первый массив, всего-то, в 2011 году. Развитие технологий ускорения обработки графики в виртуальных средах (NVIDIA GRID, AMD MxGPU) и протоколов сжатия (H.264 Advanced Video Coding) в последние годы позволили расширить сферы использования VDI для 3D дизайнеров, CAD/CAM проектирования или облачного гейминга. Стоит ли говорить о том, какие изменения происходят сейчас в подходе к организации VDI инфраструктур в связи с приходом гиперконвергентных решений в лице таких компаний как Nutanix, Dell-EMC, HPE и ряда других?

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

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

Что включает в себя дизайн VDI? Чтобы ответить на данный вопрос я подготовил диаграмму в виде MindMap.
Рисунок 1-1 - Что включает в себя дизайн VDI?

Оригинал и PDF версия по ссылке.

1.2 Преимущества VDI

Начать разговор о дизайне VDI я хотел бы с перечисления основных преимуществ, которые приносит внедрение VDI. В качестве примера рассмотрим несколько сценариев, в которых, на мой взгляд, применение VDI может быть обосновано и целесообразно:
  • Организация удаленной работы, повышение мобильности.
  • Централизация ИТ-сервисов, переход к облачной модели обслуживания.
  • Быстрое развертывание рабочих мест.
  • Упрощение поддержки и обновления рабочих мест.
  • Повышение безопасности.
  • Аварийное восстановление.
Организация удаленной работы. При помощи VDI возможно обеспечить доступ к любым приложениям, даже если пользователи находится за пределами корпоративной сети и не имеет доступа к своему рабочему месту. В отличие от терминального доступа, VDI позволяет запустить более широкий спектр приложений, благодаря использованию клиентских версий ОС Windows. За счет изоляции рабочих сред пользователей на уровне виртуальных машин, для каждой ОС и пользователя могут быть выполнены индивидуальные настройки, не затрагивающие других пользователей, например, пользователю могут быть предоставлены права локального администратора. Кроме того, пользователю может быть выделено несколько виртуальных рабочих столов с разными версиями ОС, один из которых, например, может использоваться для запуска унаследованных приложений. Данные возможности расширяют сферы применения VDI, позволяя организовать работу новых типов пользователей, включая, например, разработчиков ПО или проектировщиков, работающих с CAD/CAM системами, что делает его более универсальным решением, чем терминальный доступ.

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

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

Для VDI гораздо проще оценить и спрогнозировать требования к сети. Необходимая полоса пропускания определяется, исходя из частоты изменений экрана и качества изображения, и не зависит от размера файлов, с которыми работает пользователь на виртуальном десктопе. Конечно, воспроизведение видео, особенно, в полноэкранном режиме, требует большой полосы пропускания, однако с появлением в VDI таких технологий, как Multimedia Redirection, Flash Redirection, поддержки плагинов Microsoft Lync стало возможным существенно оптимизировать требования к полосе пропускания между виртуальным десктопом и клиентским устройством.

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

Упрощение поддержки и обновления рабочих мест. VDI позволяет заменить имеющиеся процедуры управления обновлениями благодаря централизованного развертыванию десктопов из одного образа. VDI упрощает переход на новые версии ОС, поскольку не требует одномоментного отказа от существующей ОС или замены клиентского устройства. На время миграции пользователю могут быть выделены две ВМ (с новой ОС – для тестирования и адаптации, и со старой ОС – в качестве запасного варианта на случай возникновения каких-либо проблем). При решении проблем с работоспособностью десктопа у сотрудников поддержки есть возможность откатить сделанные изменения, пересоздать ВМ или временно предоставить пользователю другой свободный десктоп. Использование серверного оборудования, СХД и технологий резервирования позволяет повысить доступность виртуальных десктопов и снизить количество простоев из-за отказов аппаратных компонентов.

Повышение безопасности. Отсутствие физического доступа к виртуальным десктопам у пользователей снижает риск неавторизованного доступа или утечки корпоративных данных. Использование временных (non-persistent) ВМ, а также средств микросегментации позволяют уменьшить риск заражения большого числа десктопов. Продукты VMware Horizon сертифицированы ФСТЭК в качестве программных средств общего назначения со встроенными средствами защиты от несанкционированного доступа к информации, не содержащей сведения, составляющие государственную тайну, что позволяет использовать их для построения систем с классом защищенности до 1Г включительно, соответствующих требованиям ФЗ-152 О персональных данных.

Аварийное восстановление. Благодаря централизованному хранению пользовательских данных VDI позволяет упростить резервирование и аварийное восстановление рабочих мест. В VDI могут быть реализованы различные механизмы катастрофоустойчивости, например, с использованием территориально-распределенных кластеров, автоматизированного переключения в резервный ЦОД, или выделения пользователям двух виртуальных десктопов из разных ЦОД. В случае, если сбой затронул один из офисов, на время устранения последствий аварии сотрудники могут быть переведены на работу из дома с сохранением доступа ко всем данным и приложениям.

1.3 Недостатки VDI

Говоря о недостатках VDI, нельзя не упомянуть книгу Брайана Мэддена (Brian Madden) – The VDI Delusion. Несмотря на то, что прошло уже более 5 лет с момента выхода книги, она все еще актуальна и затрагивает многие болезненные вопросы, связанные с построением и эксплуатацией VDI. Она вышла как раз в те годы, когда тема VDI владела умами многих специалистов, считавших, будто внедрив VDI, они смогут разом решить все вопросы организации работы сотрудников, управления парком ПК, доставки приложений, и к тому же еще порядочно сэкономить на капитальных и операционных затратах. В свое время эта книга позволила мне посмотреть на VDI не как на серебряную пулю, а как средство, призванное решать определенный круг задач, которое имеет свои преимущества и недостатки.

Основным недостатком, препятствующим повсеместному распространению VDI, остается высокая стоимость внедрения по сравнению с физическими рабочими станциями или терминальным доступом.

Немалую долю в стоимости решения играют лицензии на ПО виртуализации, ОС Windows и брокеры VDI. До сих порт для легального использования клиентских ОС Windows требуется либо иметь лицензию Windows с действующим Software Assurance на каждое устройство, с которого осуществляется подключение к виртуальным десктопам, либо ежегодно оплачивать подписку Windows VDA. К этом добавляются затраты на серверные ОС Microsoft Windows и в ряде случаев Microsoft SQL Server, который требуется для функционирования большинства VDI решений на рынке, а также требования по лицензированию брокеров VDI (как правило по количеству пользователей или активных подключений).

Другие затраты – аппаратное обеспечение: серверы, системы хранение, клиентские устройства, которые требуются для развертывания VDI. Обычно, если речь не идет об инсталляции с нуля, расширении или массовой модернизации, в организациях уже имеются в наличии достаточное количество функционирующих ПК. При переходе к VDI данные ПК становятся, по сути, не востребованы (хотя их можно использовать в качестве тонких клиентов), в то же время для запуска большого количества виртуальных десктопов требуется приобретение высокопроизводительных серверов с многоядерными процессорами и большим объемом оперативной памяти. Для хранения виртуальных десктопов также требуется использовать выделенные системы хранения, способных предоставить требуемые объемы дискового пространства и обеспечить достаточный уровень производительности, чтобы выдержать не только типовую нагрузку, но и периодические пиковые нагрузки.

Клиентские устройства (тонкие клиенты) остаются весьма недешевым удовольствием. За цену брендового ТК можно приобрести ПК начального уровня, достаточного для решения типовых офисных задач. Кроме того, для работы некоторых функций VDI (проброс сканеров, интеграция с VOIP-клиентами и др.) может потребоваться приобретение ТК с ОС Windows Embedded / IOT, отличающихся более высокой стоимостью. Использование же существующих ПК в качестве тонких клиентов влечет за собой сохранение операционных затрат на обслуживание рабочих мест.

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

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

Необходимость смены мышления. Достаточно часто в проектах я наблюдаю ситуацию, когда внедрение VDI не приводит к изменениям в администрировании рабочих станций. Показательный пример – использование Linked-clone десктопов. Несмотря на возможность централизованного обновления рабочих станций, многие администраторы не используют ее, не выполняют регулярного обновления эталонного образа, используя вместо этого WDS или SCCM для установки обновлений. Другой пример – доступ к виртуальному десктопу можно получить только после подключения по VPN, несмотря на наличие удобных и безопасных средств туннелирования в самом VDI. Использование старых подходов нивелирует преимущества VDI и эффект от его внедрения.

1.4 Основные игроки рынка VDI

Разобравшись с преимуществами и недостатками VDI, перейдем к рассмотрению основных игроков на рынке VDI.

В качестве основы возьмём диаграмму из отчета компании IDC: MarketScape: Worldwide Virtual Client Computing Software 2016.
Рисунок 1-2 - Диаграмма IDC основных игроков рынка VDI

Согласно диаграмме, к лидерам рынка VDI можно отнести две компании – Citrix и VMware. Остальные, это игроки второго эшелона – Microsoft, Parallels, NComputing, Huawei и другие.

Как человек, имеющий опыт внедрения VDI на базе Citrix XenDesktop и VMware Horizon, могу сказать, что оба продукта идут ноздря в ноздрю, если говорить функциональных возможностях и стоимости решения. В сети Интернет полно сравнений двух продуктов, как относительно независимых, так и ангажированных за одну или за другую сторону, вот пример лишь некоторых из них:
Если говорить о каждом вендоре отдельно, то VMware может быть интересен благодаря широкому набору собственных продуктов и решений, которые идут в составе бандла Horizon, либо интегрируются с ним. В первую очередь речь идет о VMware vSphere – лидирующей платформе виртуализации. Помимо vSphere, VMware включает в старшие редакции Horizon лицензии на VSAN – ПО, предназначенное для построения гиперконвергентной платформы, позволяющей существенно снизить затраты на организацию хранения ВМ, vRealize Operations for Horizon – ПО для мониторинга виртуальной и VDI инфраструктуры, Mirage – ПО для резервного копирования и обновления физических рабочих станций, Identity Manager – портал для публикации приложений и организации единой точки входа, ThinApp – средство виртуализации и упаковки приложений, App Volumes – ПО для доставки приложений на рабочие станции, User Environment Manager – ПО для синхронизации и настройки пользовательского окружения на рабочих станциях. Вдобавок VMware активно продвигает идею защиты виртуальных рабочих станций при помощи ПО для построения и управления программно-определяемыми сетями – VMware NSX.
Рисунок 1-3 - Компоненты инфраструктуры VMware Horizon View

В последние годы можно видеть, как VMware понемногу выходит вперед, реализуя в Horizon возможности, которые ранее были сильными сторонами Citrix – доставку приложений с терминальных серверов, а также протокол Blast, оптимизированный для работы с медленными, ненадежными каналами.

С другой стороны, Citrix предлагает широкие возможности по интеграции с различные платформы виртуализации (собственный гипервизор Citrix XenServer, Microsoft Hyper-V, Nutanix AHV и VMware vSphere), а также облачными сервисами – Microsoft Azure и Amazon AWS. Вместе с лицензией XenDesktop предоставляются лицензии на Citrix XenServer, а в старших редакциях еще и Provisioning Services – ПО для загрузки ОС виртуальных рабочих станций и серверов по сети, EdgeSight – ПО для мониторинга виртуальной и VDI инфраструктур, Profile Management – ПО для управления перемещаемыми профилями, а также клиентские лицензии NetScaler для удаленного доступа к виртуальным рабочим станциям.
Рисунок 1-4 - Компоненты Citrix, обеспечивающие работу XenDesktop

Компания Citrix смогла быстро занять долю рынка во многом благодаря распространенности решения по организации терминального доступа – XenApp. В свое время XenApp и XenDesktop представляли собой два отдельных продукта, однако в версии 7.0 Citrix унифицировала платформу, и сейчас для построения терминальных ферм и VDI инфраструктур используются одни и те же компоненты. Обеспечение кросс-платформенности и партнерство с другими производителями систем виртуализации является сильными сторонами Citrix и открывает для нее дополнительные рынки.

Если говорить о другом крупном игроке – Microsoft, то он заметно отстает по функциональным возможностям от решений Citrix и VMware. Несмотря на то, что брокер VDI появился у Microsoft с выходом Windows Server 2008 R2, в больших инсталляциях Microsoft продвигает совместное с Citrix решение, которое включает в себя брокер и другие компоненты, входящие в Citrix XenDesktop, балансировщик NetScaler, гипервизор Hyper-V, наборы продуктов линейки System Center для управления и мониторинга виртуальной инфраструктуры, а также пакет MDOP, включающий App-V для виртуализации приложений, UE-V – для управления рабочим окружение пользователя, MED-V – для доставки ВМ на компьютеры пользователей и ряд других продуктов.

Компания Huawei предлагает собственное VDI решение Fusion Cloud Desktop, работающее в связке с гипервизором Fusion Sphere (есть две версии, старая, базирующаяся на Xen, и новая – на KVM). Для доступа к виртуальным рабочим станциям используется собственный протокол – Huawei Desktop Protocol. К плюсам можно отнести относительно простое развертывание, богатые функциональные возможности продукта, включая поддержку виртуальных десктопов с ОС Linux, ускорение графики при помощи графических адаптеров NVIDIA, проброс различных периферийных устройств, поддержка различных клиентских устройств (включая iOS и Android).

Компания Parallels – основной конкурент VMware на рынке клиентских гипервизоров под платформу MAC OS, также предлагает свое VDI решение – Remote Application Server. RAS предоставляет все основные функциональные возможности для работы с VDI, включая проброс периферийных устройств и наличие средств терминального доступа. Поддерживаются все основные гипервизоры, включая VMware ESXi, Microsoft Hyper-V, Citrix XenServer, KVM и Nutanix AHV. Доступ к виртуальным рабочим станциям осуществляется по протоколу RDP или через HTML5 клиент.

NComputing – компания, которая долгое время выпускала собственные клиентские устройства, адаптеры и ПО, обеспечивающие одновременную работу с одним сервером или рабочей станцией нескольких пользователей (у Microsoft есть схожая функция – Multipoint Service). NComputing vSpace Pro, который можно назвать более-менее полноценным VDI решением, распространяется по довольно интересной модели. Возможность удаленного подключения и работы не требуют приобретения лицензий, лицензируются только дополнительные возможности (premium features), вроде поддержки многомониторной конфигурации, стриминга видео, мониторинга производительности и доступности компонентов. NComputing не предоставляет собственных средств виртуализации, а полагается на платформы VMware, Microsoft, Citrix.

Кроме упомянутых выше компаний, на рынке VDI присутствуют и другие игроки, вроде Leostream, Ericom, Red Hat, однако на практике мне не доводилось встречать их решений.

Не так давно на рынке присутствовал еще один известный продукт – Dell vWorkspace, который компания получила вместе с приобретением Quest Software. vWorkspace занял свою рыночную долю благодаря простоте и невысокой стоимости. Однако в 2016 году в связи с покупкой компании EMC (и соответственно VMware), Dell объявила о прекращении продаж данного продукта.

Также можно вспомнить компанию Kaviza, со своим решением VDI-in-a-box, которое поддерживало три основные платформы виртуализации (vSphere, Hyper-V, XenServer) и использовало лицензированный у Citrix протокол ICA для доступа к виртуальным десктопам. В 2011 году Citrix приобрела компанию и некоторое время предлагала VDI-in-a-Box в качестве экономичной и простой альтернативы своему флагманскому продукту XenDesktop. В 2016 году Citrix свернул продажи VDI-in-a-Box, оставив только XenDesktop.

Говоря о VDI, нельзя не упомянуть о классе решений, который стал одним из прародителей VDI - удаленных графических станциях (Remote Graphics Workstation).
Рисунок 1-5 - Рабочая станция Amulet Hotkey DXM630 на базе блейд-сервера Dell

Собственно, еще до массового внедрения технологий серверной виртуализации многие крупные вендоры предоставляли возможность размещения рабочих станций в ЦОД (выполненных в классическом башенном исполнении, или высокоплотном исполнении в виде blade или sled серверов).

Среди вендоров о которых следует упомянуть, можно назвать компанию HPE, которая выделяется несколькими интересными продуктами. В первую очередь - Remote Graphics Software, который на моей памяти был первым протоколом, ориентированным на удаленную работу с графическими приложениями. Еще до появления поддержки PCoIP, именно RGS использовался в VMware View в качестве альтернативы классическому протоколу RDP.

Второй продукт – это Moonshot, представляющий собой шасси, в которое устанавливаются компактные серверы-картриджи. В каждое шасси высотой чуть более 4U можно установить до 45 серверов. В связке с Citrix XenDesktop и Provisioning Services такие серверы могут обеспечить высокую плотность размещения рабочих станций и простоту развертывания даже без использования серверной виртуализации.
Рисунок 1-6 - Шасси HPE Moonshot 1500, в которое может быть установлено до 45 серверов-картриджей

Другой вендор – компания Teradici, известная как разработчик протокола PCoIP, который лицензируется VMware для использования в Horizon.

Teradici также производит специализированные процессоры TERA, обеспечивающие аппаратное кодирование и декодирование протокола PCoIP. На текущий момент выпущено уже второе поколение процессоров и, построенных на их основе, нулевых клиентов и хост-адаптеров.
Рисунок 1-7 - Нулевой клиент второго поколения на чипе TERA2140

Помимо аппаратных компонентов и Horizon View, протокол PCoIP используется для доступа к публичным облачным VDI сервисам (DaaS – Desktop as a Service) в Amazon WorkSpaces и Microsoft Azure.

Пару слов хотелось бы сказать об отечественных разработчиках VDI решений. Из-за политики импортозамещения, практикуемой в ряде государственных и около государственных учреждений, периодически можно встречать упоминания о российских продуктах, предназначенных для создания VDI инфраструктур. К сожалению, у меня нет практического опыта работы с данными продуктами, но большинство из того, что я видел, строится на базе гипервизора KVM и использует открытые протоколы типа Red Hat Spice или VNC для доступа к виртуальным рабочим станциям.

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

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