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

PCoIP Log Analyzer для анализа журналов PCoIP

Update: вышла обновленная версия (v2.1), теперь в формате модуля для PowerShell, содержащего команды для анализа журналов

Для собственных нужд написал модуль на PowerShell для разбора журналов pcoip_server, создаваемых агентом VMware Horizon Agent.

Модуль доступен для загрузки со страницы проекта: https://github.com/omnimod/PCoIPLogAnalyzer

С помощью команд из модуля можно проанализировать файл журнала и получить разнообразную полезную информацию о PCoIP сессии.

Результаты также можно экспортировать в текстовый файл, CSV таблицу, или создать HTML отчет с графиками.

Для установки модуля просто скопируйте файл PCoIPLogAnalyzer.psm1 на свой компьютер. Затем выполните команду Import-Module PCoIPLogAnalyzer.psm1 для добавления команд в PowerShell. Модуль содержит следующие команды:

  • Get-PCoIPStatistics
  • Import-PCoIPLog
  • Show-PCoIPStatistics
  • Export-PCoIPStatistics

Команда Get-PCoIPStatistics предназначена для анализа файла журнала и создания отчетов и имеет несколько параметров запуска:
Get-PCoIPStatistics -FilePath <string> [-ResultPath <string>] [-Format <string>] [-NoScreenOutput] [-MaxSamples <int>]

Параметры:
  • FilePath <string> - (обязательный) Указывает путь к pcoip_server файлу журнала для анализа.
  • ResultPath <string> - (опциональный) Указывает путь к создаваемому файлу отчета.
  • Format <string> - (опциональный) Задает формат создаваемого отчета. Допустимые значения: CSV, HTML или TEXT. По умолчанию если параметр не задан, файл отчета создается в текстовом формате (TEXT).
  • NoScreenOutput - (опциональный) Если указан, то пропускает вывод информации на экран.
  • MaxSamples <int> - (опциональный) Устанавливает максимальное количество выводимых строк в таблицах. Если не задан, используется значение по умолчанию: 500.
Примеры:
Проанализировать файл журнала и вывести информацию на экран:
Get-PCoIPStatistics -FilePath "C:\Temp\pcoip_server_2017_12_19_000034d0.txt"

Проанализировать файл журнала, вывести информацию на экран и сохранить отчет в HTML файле:
Get-PCoIPStatistics -FilePath "C:\Temp\pcoip_server_2017_12_16_00000230.txt" -ResultPath "C:\Temp\report.html" -Format HTML

Команда Import-PCoIPLog анализирует журнал и выдает в результате работы объект PSObject, содержащий различную полезную информацию из журнала.
Import-PCoIPLog -FilePath <string>

Параметры:
  • FilePath <string> - (обязательный) Указывает путь к pcoip_server файлу журнала для анализа.
Примеры:
Проанализировать файл журнала и сохранить результат в переменной:
$PCoIPLog = Import-PCoIPLog -FilePath "C:\Temp\pcoip_server_2017_12_19_000034d0.txt"

Известные ограничения

  1. Текущая версия поддерживает только pcoip_server файлы журналов, созданные агентом VMware Horizon Agent версии 5.3, 6.x 7.x. Модуль не тестировался на журналах из других версий.
  2. Текущая версия не отображает часть статистики из файлов журналов, созданных агентом, установленным на рабочие станции с адаптером PCoIP Hardware Host Card (Teradici Remote Workstation Card).
  3. Для корректного отображения стилей и графиков в HTML файле, компьютеру требуется доступ к ресурсам https://code.jquery.com и https://cdnjs.cloudflare.com для загрузки дополнительных javascripts сценариев и таблиц стилей CSS.

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

Немного о дизайне VDI. Часть 10. Организация подключения и безопасность

10.1 Варианты подключения к виртуальным десктопам

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

Подключение к виртуальным десктопам может осуществляться одним из трех способов:
  • Подключение через брокер или прокси-сервер с использованием механизма туннелирования сессионного трафика.
  • Подключение через брокер или прокси-сервер без использования механизма туннелирования.
  • Прямое подключение с клиентского устройства к виртуальному десктопу.
Первые два варианта требуют для своей работы функционирующего брокера подключений (в случае Horizon – View Connection Server), а при доступе из Интернет и пограничного сервера (View Security Server, Unified Access Gateway, либо стороннее устройство). Брокер является единой точкой подключения, выполняет аутентификацию пользователя и выдает перечень десктопов доступных для подключения. Дальнейшая схема различается в зависимости от того используется режим туннелирования или нет. При туннелировании трафика клиентское устройство устанавливает вторичное подключение к брокеру (или прокси-серверу), который, в свою очередь, подключается к десктопу. Весь трафик сессии от клиента до виртуального десктопа идет через брокер. Это позволяет легко реализовать сценарии подключения пользователей из сети Интернет, без необходимости использования VPN или настройки публичных IP-адресов для виртуальных десктопов.

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

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

Выбор протокола для подключения также влияет на архитектуру VDI. На текущий момент Horizon поддерживает следующие протоколы для подключения к виртуальным десктопам.
Функции
RDP
PCoIP
Blast (Extreme)
HTML5 (Blast)
Способ подключения
Клиент Horizon Client
Клиент Horizon Client
Клиент Horizon Client
Веб-браузер
Транспорт
TCP
UDP
TCP или UDP
TCP
Туннелирование через View Security Server, UAG
Да
Да
Да
Да
Возможность прямого подключения к десктопу
Да, (Direct connection agent или клиент RDP)
Да, (Direct connection agent)
Да, (Direct connection agent)
Да, View HTML Access)
Многомониторные конфигурации
Да
Да
Да
Да
Передача буфера обмена (Clipboard Redirection)
Да
Да
Да
Да
USB Redirection
Да
Да
Да
Нет
Serial Port Redirection
Нет
Да
Да
Нет
Virtual Printing / проброс принтера
Да
Да
Да
Нет
Воспроизведение звука
Да
Да
Да
Да
Проброс микрофона
Да
Да
Да
Да
Проброс сканеров
Нет
Да
Да
Нет
Проброс локальных дисков
Да
Да
Да
Нет
Flash Redirection
Нет
Да
Да
Нет
Поддержка Multimedia Redirection
Да
Да
Да
Нет
Поддержка RTAV
Нет
Да
Да
Да
Поддержка Skype for Business
Нет
Да
Да
Нет
Аппаратное кодирование протокола
Да, зависит от ОС
Да, Teradici PCoIP Hardware Accelerator
Да, графические адаптеры NVIDIA GRID/Tesla
Да, графические адаптеры NVIDIA GRID/Tesla
Аппаратное декодирование протокола
Да, зависит от клиента
Только на нулевых клиентах Teradici
Да, графические адаптеры
Только в веб-браузере Chrome, графические адаптеры
Поддержка Lossless режима
Да, зависит от ОС
Да
Да
Да

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

Протоколы PCoIP или Blast являются более оптимальным выбором, поскольку помимо более широких функциональных возможностей, обеспечивают лучшее качество изображения, меньшие задержки и утилизацию канала, чем RDP, хотя большую роль здесь играет версия ОС (Windows 10 обеспечивает гораздо лучшие показатели сжатия и качества в сравнении с Windows 7 или Windows 8: https://cloudblogs.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview/).

HTML5 клиент может применяться в качестве вспомогательного варианта, в тех случаях, когда пользователь подключается с специализированных клиентских устройств и не имеет возможности установить полнофункциональный клиент Horizon Client. Несмотря на свою "платформонезависимость", ряд функций, такие как аппаратное декодирование и многомониторные конфигурации поддерживаются только для браузера Google Chrome.

Еще один немаловажный показатель – это приспособленность протокола к работе на нестабильных, медленных каналах. Согласно документу Blast Extreme Display Protocol in Horizon 7 (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-7-view-blast-extreme-display-protocol.pdf) протокол PCoIP способен работать на каналах с потерями пакетов, достигающих 15%, в то время как Blast может «пережить» до 20% потерь.

Последний фактор – это простота публикации протокола на межсетевых экранах. Лидером здесь является RDP, поскольку для его работы при использовании режима туннелирования требуется открыть только один порт – TCP 443. Для Blast помимо TCP 443 требуется открыть TCP 8443 и опционально UDP 8443, хотя в случае использования Unified Access Gateway есть возможность туннелирования трафика только через TCP 443. Для PCoIP помимо TCP 443 требуется открыть доступ по портам TCP 4172 и UDP 4172. В большинстве случаев, когда не работает подключение по PCoIP, и пользователь видит перед собой черный экран, это означает, что администраторы забыли открыть доступ по порту UDP 4172.

10.2 Клиентские устройства

Выбор протокола связан с используемыми клиентскими устройствами. Horizon поддерживает следующие типы клиентских устройств:
  • Стационарные компьютеры и ноутбуки с ОС Windows, MAC OS X, Linux или Chrome OS.
  • Тонкие клиенты под управлением Windows Embedded / IoT, Linux или иных ОС, например, тонкие клиенты Dell Wyse, HP, Lenovo, Atrust, Igel, Fujitsu и других производителей.
  • Нулевые клиенты с аппаратной поддержкой PCoIP на базе чипов Teradici.
  • Мобильные устройства – планшеты и смартфоны с ОС iOS, Android, Windows Phone.
  • Устройства, оснащенные HTML5 совместимым браузером.
Критериями выбора клиентского устройства (помимо стоимости) являются: производительность, функциональные возможности, удобство эксплуатации, надежность и защищенность.

Производительность тонкого клиента напрямую влияет на частоту прорисовки и качество изображения, а, следовательно, на удобство и комфорт работы пользователя. В большинстве случаев производительности процессоров уровня Core i3 или Pentium достаточно для обеспечения работы в большинстве приложений, а вот процессоры Intel Atom или AMD G-series, не говоря уже о процессорах с архитектурой ARM, могут не справиться с обработкой изображения в высоком разрешении с частой перерисовкой экрана (воспроизведение видео, работа графикой, многомониторные конфигурации).

Решить проблему с недостаточно производительными процессорами позволяют тонкие клиенты, поддерживающие VMware Blast. Данный протокол использует кодек H.264 и для декодирования изображения может задействовать графический адаптер клиентского устройства, тем самым снижая нагрузку на процессор и ускоряя процесс обработки изображения, что позволяет обеспечивать приемлемый уровень производительности даже на ТК начального уровня. На текущий момент далеко не все клиенты, поддерживающие VMware Blast, поддерживают аппаратное декодирование (например, ТК Dell Wyse с ОС ThinOS версии 8.4.110 и ниже), кроме того следует помнить о некоторых нюансах работы (http://blog.vmpress.org/2017/05/vmware-blast-h264.html).

Альтернативой ТК с аппаратной поддержкой Blast являются нулевые клиенты на базе процессоров Teradici (TERA2 2321 и 2220). Данные ТК обеспечивают высокий уровень производительности, сопоставимый со стационарными компьютерами, экономичны, просты в настройке и эксплуатации, однако из-за ограничений Teradici OS не поддерживают многие функции Horizon.

Если говорить о функциональных возможностях, то здесь лидерами являются компьютеры с ОС Windows и клиентами Horizon Client. Версии Horizon Client под MAC OS X или Linux не поддерживают проброс сканеров или последовательных портов, а у нулевых клиентов Teradici также отсутствует поддержка протоколов RDP и Blast, функций Flash Redirection, MMR, RTAV, Virtual Printing и пр.

Linux является крайне популярной ОС для установки на тонкие клиенты (у каждого производителя найдется пара-другая моделей ТК с Linux). Некоторые вендоры предоставляют оптимизированную версию ОС Linux, которая может быть установлена на существующие компьютеры, превращая их в ТК. Среди популярных решений можно отметить:
  • Thinstation.
  • Dell Wyse PC Extender.
  • Igel Universal Desktop Converter.
  • Stratodesk NoTouch Desktop.
Важный нюанс, хотя большинство современных тонких клиентов с Linux базируются на процессорах с архитектурой Intel x86, до сих пор остается некоторое количество устаревших моделей на базе процессоров ARM. Horizon Client для ARM процессоров имеет функциональные ограничения (отсутствие RTAV и Flash URL Redirection) по сравнению с Horizon Client для Linux на x86 процессорах. Клиенты для платформ iOS, Android, Windows Phone и HTML5 клиент функционально крайне ограничены, однако представляют интерес благодаря мобильности, имея доступ к Интернет, пользователь всегда может подключиться к своему виртуальному десктопу.

Пару слов следует сказать о ТК Dell Wyse с ОС ThinOS. Данные клиенты интересны как альтернатива нулевым клиентам благодаря простоте настройки, поддержке нескольких брокеров и протоколов подключения, небольшому размеру образа ОС и возможности установки дополнительных пакетов. Функционально ТК с ThinOS находятся где-то между нулевыми клиентами и клиентами под ОС Linux.

Большинство моделей ТК также обладают возможностью централизованной настройки и обновления при помощи сервера управления (Dell Wyse Device Manager или Wyse Management Suite, HP Device Manager, Atrust Device Manager, PCoIP Management Console и другие). ТК с ОС Windows могут также управляться стандартными инструментами вроде групповых политик или Microsoft SCCM.

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

Что касается безопасности, на ТК с ThinOS и нулевых клиентах Teradici у пользователей отсутствует доступ к файловой системе, поддерживается экспорт логов на внешнее хранилище или сервер управления, а также имеется разграничение пользовательского и административного режима. На многих Windows и Linux ТК может быть активирован режим защиты от записи, который позволяет после перезагрузки автоматически откатывает все изменения, сделанные на ТК. Такой режим помимо повышения безопасности может усложнить установку дополнительных приложений и обновлений на ТК, т.к. потребует предварительного отключения защиты. Показателен размер установочного образа ОС (прошивки) для ТК разных типов:
  • Нулевой клиент Teradici: 5 – 10 МБ.
  • Тонкий клиент с ThinOS: 20 – 30 МБ.
  • Тонкий клиент с Linux: 600 – 1200 МБ.
  • Тонкий клиент с Windows: 2 – 8 ГБ.
В таблице представлено сравнение функциональных возможностей клиентов по платформам. В качестве специализированных клиентских устройств рассматриваются только нулевые клиенты Teradici и ТК Dell Wyse с ОС Thin OS. Большинство оставшихся ТК на рынке в качестве ОС используют ОС Windows или Linux.

Ознакомиться со всеми функциональными возможностями клиентов под различные платформы можно на странице документации по клиентам (https://www.vmware.com/support/viewclients/doc/viewclients_pubs.html).

10.3 Удаленный доступ

Для организации удаленного доступа используются пограничные серверы, в качестве которых могут выступать VMware Security Server, VMware Unified Access Gateway (UAG) или решения от сторонних производителей (F5 Big-IP, Citrix Netscaler Gateway и др.).

Основные отличия Security Server от UAG приведены в таблице:
Описание
Security Server
Unified Access Gateway
Тип установкиНа Windows Server 2008 R2 и вышеLinux Virtual Appliance
Интеграция с View Connection Server1 к 1
Один Security Server связывается (pairing) только с одним Connection Server, использование балансировщика между security server и connection server не поддерживается
Многие к 1 или многие ко многим
К одному и тому же Connection Server могут подключаться несколько UAG. При балансировании Connection Server несколько UAG могут подключаться к нескольким Connection Server
Порты/протоколы для интеграции с Connection ServerIPSEC при использовании режима (IPSec security) или TCP 4001, TCP 4002 и т.д.HTTPS (TCP 443)
Поддерживаемые функцииMMR
USB Redirection
Two-factor Authentication (RSA SecurID или Radius)
Smart-Card Authentification
USB Redirection
MMR
USB Redirection
Two-factor Authentication (RSA SecurID или Radius)
Smart-Card Authentification
USB Redirection
НастройкиНастройки туннелирования и аутентификации задаются на уровне парного Connection ServerНастройки туннелирования и аутентификация задаются на уровне UAG
МаксимумыМаксимальное кол-во одновременных подключений: 2000​• PCoIP Sessions = 2,000
• Blast Extreme Sessions – UDP = 1,000
• Blast Extreme Sessions – TCP = 2,000

Основное отличие Security Server от UAG заключается в том, что UAG представляет собой предустановленный виртуальный апплайнс на базе ОС Linux и не требует лицензии Windows.

UAG гораздо проще в установке и настройке, он использует только HTTPS протокол для интеграции с Connection Server и не требует открытия большого кол-ва портов между Security Server и Connection Server.

Security Server поддерживает режим развертывания по схеме 1 к 1, для каждого Connection Server’а создается один парный Security Server, варианты, когда к одному Connection Server’у подключаются два Security Server или, наоборот, когда один Security Server подключается к двум Connection, не поддерживается. Для обеспечения безопасности передаваемых данных между Security Server и Connection Server может быть настроен IPSec.

Использование Security Server’ов на больших инсталляциях связано с определенными ограничениями в случаях, когда вам необходимо сделать разные настройки туннелирования и аутентификации для разных пользователей, подключающихся из внутренних и внешних сетей. Например, вы хотите, чтобы для внутренних пользователей аутентификация по смарт-картам была опциональна и не использовалось туннелирование, а для внешних пользователей использовалось туннелирование и была бы обязательна аутентификация по смарт-картам или SAML аутентификация при интеграции с Identity Manager (…и еще там тэги разные для разных пулов и Connection Server’ов).

Так как данные настройки задаются на парном Connection Server и не могут быть переопределены на Security Server, все варианты комбинаций не получится задать в рамках одного POD’а и обеспечить при этом отказоустойчивость подключений.

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

Также UAG позволяет настроить проксирование трафика BLAST Extreme через единый порт (TCP 443), в отличие от Security Server, который требует открыть и TCP 443, и TCP 8443. Помимо предоставления доступа к VDI инфраструктуре Horizon, UAG также может использоваться для публикации Identity Manager и AirWatch, и все через один IP адрес.

Решения от сторонних производителей (Citrix и F5) предоставляют функции PCoIP Proxy сервера и могут заменить собой Security Server или UAG. Кроме проксирования PCoIP трафика, сторонние решения также могут осуществлять балансирование нагрузки, выступать в качестве серверов публикации приложений, выполнять SSL Offload и т.д.

Обычно серверы Security Server или UAG размещаются в DMZ сети, однако следует помнить, что клиент устанавливает туннелированное подключение через Security Server/UAG, минуя Connection Server, соответственно, между ними и виртуальными десктопами должна быть настроена маршрутизация трафика и открыт доступ по соответствующим протоколам.

Более подробно о портах и протоколах, необходимых для работы Horizon, вы можете узнать из документа: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-7-end-user-computing-network-ports.pdf.

10.4 Балансирование нагрузки

Настройка балансировщика подключений между несколькими Connection Server или пограничными серверами преследует собой две цели:
  • Распределение нагрузки в больших инсталляциях, когда производительности одного сервера недостаточно.
  • Обеспечение отказоустойчивости на случай выхода из строя одного из серверов.
Конечно, всегда есть вариант сообщить пользователям адреса нескольких Connection Server или пограничных серверов и выдать простую инструкцию вида: "–Если не удается подключиться к одному серверу, попробуйте подключиться к другому.", однако такой вариант с ручным переключением подходит только для небольших инсталляций и для терпеливых пользователей.

Самым простым в настройке вариантом балансировки является DNS Round Robin. Для каждого IP-адреса сервера Connection Server (или пограничного сервера) создается A-запись с одним и тем же именем (например, vdi.company.local), которое используется клиентами для подключения. При запросе клиентом адреса у DNS сервера, сервер возвращает список IP адресов. Для каждого запроса порядок адресов меняется, таким образом, один клиент подключиться к серверу Connection Server, который в списке адресов находится на первом месте, второй клиент подключится ко второму серверу, и так далее. DNS Round Robin позволяет равномерно распределить входящие подключения по серверам, однако имеет несколько недостатков. Во-первых, DNS Round Robin не выполняет проверку доступности серверов, поэтому при отказе сервера продолжает возвращать список, включающий его IP адрес, что может привести к тому, что клиент предпримет попытку подключиться к нерабочему серверу.

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

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

Другой вариант предполагает использование балансировщика сетевой нагрузки: встроенного (Windows Network Load Balancer), либо внешних (Citrix NetScaler, F5 BIG-IP, KEMP Loadmaster, NSX Edge, HAProxy и др.). Среди преимущества использования внешних балансировщиков:
  • Упрощение сетевой конфигурации серверов View Connection Server по сравнению с NLB.
  • Поддержка различных алгоритмов балансировки (failover, round-robin, балансировка по числу активных соединений, балансирование по загрузке серверов).
  • Проверка здоровья балансируемого сервиса (health check).
  • SSL offloading – позволяет выполнять шифрование соединения только на стороне клиента-балансировщика, и передавать трафик между балансировщиком и Connection Server в незашифрованном виде, что снижает нагрузку на серверы View.
  • Глобальная балансировка (Global Load Balancing) для территориально-распределенных инсталляций VMware Horizon.
Для Horizon внешние балансировщики могут быть настроены в одном из двух режимов:
  • Балансирование только первоначального HTTPS соединения.
  • Балансирование всего трафика (включая PCoIP или Blast).
Балансирование только служебного трафика создает существенно меньшую нагрузку на балансировщики, но требует прямого доступа с клиентов до Connection Server или пограничных серверов по протоколам PCoIP / Blast, что потребует дополнительных IP-адресов в случае публикации из Интернет и настройки межсетевого экрана. Первичное соединение по HTTPS выполняется через балансировщик (например, balancer.company.local), который перенаправляет трафик на один из Connection Server. После выбора десктопа клиент устанавливает туннелированное подключение с соответствующим сервером View Connection или пограничным сервером (например, view01.company.local).


В случае балансирования всего трафика через балансировщик идет не только служебный трафик, но также трафик удаленной сессии PCoIP/Blast. Это приводит к большей нагрузке на балансировщик, а также требует настройки дополнительных правил балансирования для сессионного трафика (по портам TCP/UDP 4172 для PCoIP, и TCP/UDP 8443/443 для Blast, зато позволит упростит публикацию из Интернет, т.к. публичный IP адрес потребуется только для балансировщика. Кроме того, при использовании балансировщика с функциями L7 (application) firewall, такое устройство может использоваться для защиты серверов View от различных сетевых атак.

Если вы планируете балансировать весь траффик, а не только первоначальное подключение по HTTPS, то на балансировщиках требуется включить sticky sessions/affinity, чтобы трафик PCoIP/Blast перенаправлялся на тот же Connection Server, через который было установлено первоначальное соединение.


Еще одна важная функция, которую предоставляют внешние балансировщики, это проверка здоровья балансируемого сервиса (health check). Балансировщик периодически выполняет подключение к балансируемому серверу для проверки его состояния. В случае если проверка завершается неудачно, балансировщик может временно исключить сервер из списка и перенаправлять подключения на оставшиеся серверы. Для HTTPS трафика предпочтительно использовать проверку здоровья на уровне приложения. Например, при публикации Connection Server балансировщик может выполнять проверку здоровья путем выполнения HTTP GET запроса для получения файла иконки сайта ("/favicon.ico"). Этот вариант позволит избежать у пользователей проблем с подключением, возникающих при использовании менее строгих вариантов проверки здоровья, например, при помощи ping’а или telnet’а на определенный порт.

Если к VDI инфраструктуре не предъявляются повышенные требования к безопасности, и нет необходимости использования application firewall на балансировщике, то вариант с балансированием только HTTPS является предпочтительным. Для балансирования HTTPS трафика будет достаточно балансировщика начального уровня, это позволит снизить затраты на развертывание (многие балансировщики лицензируются по функциональным возможностям и пиковой полосе пропускания).

10.5 Двухфакторная аутентификация

Двухфакторная аутентификация предоставляет дополнительный уровень защиты при подключении и позволяет снизить риски при утечке или подборе логина и пароля учетных записей пользователей. Horizon поддерживает следующие механизмы двухфакторной аутентификации:
  • RSA SecurID
  • RADIUS
  • Смарт-карты
Аутентификация RSA SecurID работает в связке с RSA Authentication Manager и требует наличия у пользователя программного или аппаратного генератора временных паролей SecurID. При подключении к Connection Server у пользователя будет запрошен логин и временный пароль, и в случае успешной аутентификации на RSA пользователю потребуется ввести логин и пароль своей учетной записи (второй фактор).

При интеграции Horizon с VMware Identity Manager и настройке SAML аутентификации может быть задействован механизм True SSO, позволяющий избавиться от необходимости ввода логина и пароля при аутентификации через RSA SecurID на портале Identity Manager.

Принцип работы механизма True SSO основан на генерировании и использовании одноразовых цифровых сертификатов пользователей. В инфраструктуре развертывается дополнительный сервер Horizon Enrollment Server, который отвечает за запрос сертификатов от имени пользователя и передачу сертификата серверу View для дальнейшей аутентификации пользователей.

Интеграция Horizon с RADIUS серверами позволяет обеспечить работу различных механизмов двухфакторной аутентификации, например, JaCarta Authentication Server – аналог RSA SecurID.

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

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

понедельник, 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 может потребовать разработку документации – инструкций, регламентов, чек-листов, а также проведения обучения или инструктажа для технических специалистов.

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

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