Raspberry Pi в качестве экономичной альтернативы тонким клиентам

Одной из существенных статей расходов при внедрении терминальных ферм или VDI инфраструктуры является покупка тонких клиентов - устройств, обеспечивающих подключение к удаленным рабочим столам. На рынке присутствует множество производителей тонких клиентов - это и широко известные компании: Dell (в свое время купивший крупнейшего производителя ТК Wyse), HP, NComputing, так и менее известные: Igel, Lenovo, Centerm, и даже местные российские производители: Тонк, Kraftway.

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

На фоне этого весьма интересной выглядит идея использовать дешевые компьютеры на базе процессоров ARM в качестве тонких клиентов. Так, например, несколько лет назад на рынке появились Computer Stick - крошечные компьютеры с ОС Andoid на борту, выполненные в форм-факторе USB flash-накопителей, снабженные HDMI портом, Wi-Fi адаптером, USB портом для подключения периферии и разъемом для Micro SD карт. В основном данные устройства использовались в качестве медиа плееров для того, чтобы сделать из обычных телевизоров т.н. Smart TV, хотя Dell даже выпустила устройство Wyse Cloud Connect.

Однако, не смотря на привлекательную цену (можно без проблем найти Compute Stick от какого-нибудь китайского производителя за 70$), ограничения со стороны ОС Android и программ-клиентов, отсутствие Ethernet разъема для подключения к проводной сети (хотя при желании можно использовать USB-Ethernet адаптеры), не привели к широкому распространению подобных устройств в качестве тонких клиентов.

Raspberry Pi

Появление одноплатных компьютеров Raspberry Pi, поддерживающих ОС Linux, имеющих весьма производительную аппаратную начинку при цене всего в 35$, возродило интерес к созданию дешевого ТК.

Благодаря своей компактности, производительности и невысокой цене RPi стал интересной основой для построения различных DIY (Do It Yourself) устройств: медиа центров, игровых приставок, устройств для умного дома и т.д.  Более того, некоторые производители бизнес-решений также заинтересовались в RPi, например, компания ThinPrint объявила о скором выходе принт-сервера ThinPrint Hub на базе RPi.

За несколько лет пребывания RPi на рынке вышло несколько поколений устройств. Последняя и наиболее продвинутая на сегодня версия Raspberry Pi 2 Model B имеет следующие характеристики:

• Четырехъядерный процессор ARM Cortex-A7 с частотой 900 МГц (Broadcom BCM2836).
• 1 ГБ оперативной памяти.
• Четыре порта USB 2.0.
• Один порт HDMI 1.3a.
• Один Ethernet порт 10/100 Мбит/с.
• Один 3.5 мм стерео аудио разъем, совмещенный с композитным видео разъемом.
• Micro USB разъем для подключения питания.
• Micro SD слот для установки карт памяти.

Если взглянуть на характеристики многих ТК начального уровня, например, Dell T10, то можно увидеть, что RPi крайне схож по параметрам, а в чем-то даже превосходит своих коллег.

При покупке RPi следует понимать, что за 35$ вы получите только саму плату-компьютер. Дополнительно вам придется раскошелиться на корпус, карту памяти, блок питания (рекомендуется использовать БП, выдающие 1.8А и выше), USB кабель к нему, мышь и клавиатуру.

Из дополнительных аксессуаров может потребоваться VESA крепление для установки на монитор и адаптеры для питания через PoE (Power over Ethernet).

Операционные системы для ТК на Raspberry Pi

Для RPi существует много официальных и неофициальных дистрибутивов ОС, которые так или иначе могут использоваться для создания ТК.

Первый вариант, который приходит на ум - использовать один из официальных дистрибутивов: Raspbian, основанный на Debian, или Ubuntu MATE, основанный, соответственно, на Ubuntu.

Из плюсов - стабильность работы, симпатичные оболочки для рабочего стола (LXDE или MATE), большой набор сторонних приложений, устанавливаемых из репозиториев, что позволит использовать устройство в качестве более-менее полноценной замены обычному ПК (есть web-браузер, офисный пакет Libre Office). Из минусов - устанавливать клиентское ПО и настраивать ТК придется самостоятельно. И если найти клиент Citrix Receiver не проблема, то, например, VMware Horizon Client для Linux под процессоры ARM доступен только технологическим партнерам, доставать его с какого-нибудь ТК - удовольствие сомнительное.

Альтернативный вариант, Raspberry Pi Thin Client Project (RPiTC2) обладает, пожалуй, самым широким перечнем функциональных возможностей. RPiTC2 поддерживает клиенты для многих популярных терминальных сред и VDI инфраструктур, включая Citrix XenApp и XenDesktop, VMware Horizon View, Microsoft RDS, NoMachine NX, Thinlinc, Parallels 2X, Red Hat SPICE.

RPiTC2 представляет собой дистрибутив на базе Debian с оболочкой XFCE4, из которого убрано все лишнее (по умолчанию установлен только web-браузер Iceweasel). Установка клиентов для удаленного подключения и дополнительного ПО выполняется из мастера RPiTC Builder.

В PRiTC2 присутствует несколько интересных функций, например, разгон CPU, плагин для Citrix с аппаратной поддержкой декодирования H.264, VNC сервер, несколько клиентов для RDP, включая собственную сборку - dFreeRDP, отличающуюся более высоким уровнем производительности.

Еще один вариант может подойти тем, кто использует терминальные решения Microsoft. Компания WTware, разработчик одноименного ПО, позволяющего создавать нулевые клиенты из обычных ПК, предлагает бесплатную версию и для Raspberry Pi 2.

Несмотря на то, что WTware работает только с RDP протоколом, поддерживаются такие функции, как воспроизведение звука, проброс в удаленную сессию дисков, принтеров и serial-устройств. Кроме того, WTware имеет встроенный VNC сервер, с помощью которого можно наблюдать за работой пользователей ТК, и web-браузер Chrome.

Огромным плюсом WTware является возможность централизованного управления ТК (можно править конфигурационные файлы клиентов, удаленно перезагружать устройства и просматривать их журналы) через административную консоль WTware Center, устанавливаемую на отдельный компьютер с ОС Windows.

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

Последний и довольно экзотический вариант - сборка Chromium OS под Raspberry Pi.

Chromium OS имеет встроенный браузер Chomium, что позволяет подключаться к инфраструктуре VMware View, используя протокол Blast, или Citrix XenApp/XenDesktop (при помощи Citrix Receiver for HTML5).

Недостатки Raspberry Pi

Кратко описав варианты ОС для создания ТК, перейдем к недостаткам использования RPi в качестве ТК.

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

Сырость ОС и ограничения клиентского ПО под архитектуру ARM. Например, клиент VMware Horizon Client под Linux ARM не поддерживает RTAV (Real Time Audio-Video), Scanner Redirection, Multimedia Redirection, Serial-port Redirection. Клиенты RDP не отличаются высокой производительностью и стабильностью работы. Клиенты Citrix Receiver и VMware Horizon Client требуется доводить до кондиции, особенно если вы устанавливаете их самостоятельно. Но следует отметить, что во многих "готовых" тонких клиентах под ARM присутствуют подобные недостатки.

Отсутствие ПО для централизованного управления и обновления ТК (кроме WTware). Если для ТК Dell или HP вы можете использовать Wyse Device Manager или HP Device Manager, то для RPi вам придется самому писать скрипты или осваивать что-нибудь вроде Ansible.

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

Отсутствие поддержки загрузки по PXE - RPi поддерживает загрузку только с Micro SD карт (справедливо для старых поколений устройств, в RPi 3 добавлена загрузка по PXE и с USB накопителя).

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

Низкая производительность для ресурсоемких задач (проигрывание видео, графические редакторы, САПР в удаленной сессии). Для типовой офисной работы RPi вполне хватает, но не следует ждать чудес от устройства за 35$ там, где не справляется ТК за 600$.

Вывод

Вывод по поводу использования Raspberry Pi в качестве ТК очень простой. Если на первом месте стоит снижение затрат на покупку, и вы готовы самостоятельно дорабатывать данное решение, то в этом случае RPi - безоговорочный лидер. Вполне возможно, что кто-то из производителей рано или поздно решится сделать ТК на базе RPi.

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

Уязвимости CVE-2015-7547 могут быть подвержены продукты VMware

Со мной в чате поделились ссылкой касаемо новой глобальной уязвимости CVE-2015-7547, которая затрагивает огромное число устройств, использующих ОС на базе Linux.

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

Многие продукты VMware также используют уязвимые версии данной библиотеки, например, гипервизор ESXi 5.5 - 6.0, vSphere Data Protection, vSphere Replication, vRealize Operations, vRealize Orchestrator, vRealize Automation, NSX и другие (в которых используется glibc 2.11.1 или 2.11.2).

И если насчет гипервизора нет информации, используется ли glibc для разрешения DNS имен, то виртуальные апплайнсы, вероятно, подвержены уязвимости.

Согласно баг-репорту, уязвимость исправлена в glibc версии 2.23.

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

1. Использовать только доверенные DNS серверы для разрешения имен.
2. Ограничивать на брандмауэрах длину DNS паветов от сервера 512 байтами для протокола UDP и 1024 для TCP.

Миграция с VMware Embedded PSC на External PSC на Windows Server

Начиная с версии vSphere 6.0 U1, стала поддерживаться миграция vCenter Server со встроенного Platform Services Controller на внешний PSC.

Разнесение PSC и vCenter между серверами может потребоваться в больших виртуальных средах, если вы планируете настроить балансировку служб PSC, использовать несколько серверов vCenter, объединенных в Enhanced Linked Mode, или создать отказоустойчивый кластер vCenter Server.

Краткие шаги по миграции:

1. Если включен брандмауэр Windows, откройте порты 88, 389, 636, 2012,2014, 2020, 7080, 7081, 11711, 11712 на сервере vCenter с установленным PSC. Иногда при перезагрузке сервера может возникать ситуация, когда службы PSC не прослушивают порт 2020, в этом случае помогает перезапуск службы VMware afd Service.
2. Установите External PSC на отдельный сервер, подключив к тому же домену (по умолчанию, vsphere.local), и указав тот же сайт, что был задан при установке Embedded PSC. Узнать имя сайта можно, выполнив следующую команду на сервере vCenter:
   

   "C:\Program Files\VMware\vCenter Server\python\python.exe" "C:\Program Files\VMware\vCenter Server\VMware Identity Services\lstool\scripts\lstool.py" get-site-id --url https://psc_node_fqdn/lookupservice/sdk
   

   Если в процессе установки возникает ошибка "failed to run vdcpromo", то, скорее всего, вы не открыли какой-то из портов. В этом случае проверьте их при помощи Telnet с какого-нибудь компьютера из локальной сети.
3. Перенастройте vCenter Server на использование нового PSC: http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc%2FGUID-E7DFB362-1875-4BCF-AB84-4F21408F87A6.html
4. Удалите записи о старом PSC, чтобы исправить ошибку в Perfcharts: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2131327
5. Удалите старые корневые сертификаты на сервере vCenter: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2133028
6. Замените Machine и User сертификаты на vCenter Server: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2112279
7. и http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2112281
8. Поправьте сертификаты: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2121701
9. Перезагрузите сервер vCenter Server.

Использование силосов для хранения индивидуальных настроек VMware User Environment Manager

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

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

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

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

Настройка нескольких хранилищ для профилей, например, при использовании стандартных перемещаемых профилей Windows или профилей VMware Persona Management, хоть и решает данную проблему, но, во-первых, приводит к необходимости выделять на файловом сервере дисковое пространство под каждый новый профиль, во-вторых, поскольку профили никак не синхронизируются между собой, потребует от пользователя выполнять одни и те же настройки несколько раз.

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

Для начала требуется включить поддержку силосов (Silo support) в окне Settings в консоли UEM Management Console.

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

Каждый силос представляет собой каталог на файловом сервере, где располагается конфигурация UEM, например, \\fileserver\UEMConfig\silos\termfarm1 и т.д.

Настройки силоса выполняются через групповую политику Silo-specific Flex config files. В политике есть две настройки:
Central location of silo-specific Flex config files - указывает путь к каталогу, где хранятся конфигурационные файлы (Flex configuration file) силоса.
Silo-specific suffix - (опциональная настройка) имя дочернего каталога, где будет храниться архив профиля пользователя (UEM profile archive) для данного силоса. Если суффикс не указан, то в качестве имени дочернего каталога будет использоваться имя силоса.

Поскольку эта политика относится к пользовательской части GPO, то для ее применения на компьютеры потребуется использовать group policy loopback processing mode (о том, что это такое, можно почитать по ссылке: https://technet.microsoft.com/en-us/library/cc978513.aspx).

Настройка силоса выглядят следующим образом:

1. Создайте в консоли UEM Management Console новый силос.
2. Создайте в Active Directory новое организационное подразделение, например, termfarm1.
3. Поместите в OU компьютеры, для которых потребуется указать настройки силоса.
4. Создайте новый объект групповой политике и включите настройку Configure user Group Policy loopback processing mode в режиме Merge.
5. В этой же политике укажите путь к силосу Central location of silo-specific Flex config files.
6. Примените групповую политику к созданному OU.
7. Повторите шаги для другой группы компьютеров.

Теперь вы можете создавать конфигурации для приложений и ОС по аналогии с каталогом General.

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

В плане настройки силосы ничем не отличаются от каталога General, где, по умолчанию, создаются конфигурационные файлы приложений и ОС.

В силосах хранятся только настройки UEM в части Personalization (настройки приложений и ОС), в силосах нельзя задавать настройки User Environment (подключения сетевых дисков, принтеров, задания переменных окружения и т.д.) и Application Migration (перенос настроек между приложениями).

Если вы создаете конфигурационный файл для одного и того же приложения (настройки ОС) и в каталоге General, и в силосе, то FlexEngine агент будет обрабатывать оба файла. Если в конфигурационных файлах задаются предопределенные настройки для одних и тех же файлов, папок или веток реестра, то после импорта на рабочую станцию настройки из силоса будут иметь приоритет ("перезапишут" настройки из конф.файла General каталога).

Если в конфигурационном файле силоса разрешен экспорт настроек в архив профиля пользователя, то сам архив создается в дочернем каталоге в сетевой папке UEMUsers. Имя каталога либо соответствует имени силоса, либо определяется настройкой групповой политики (см. выше).

Для того чтобы рассмотреть, как настройки силоса сочетаются с архивами профиля пользователя, рассмотрим небольшой пример. Пусть ключ реестра HKCU\software\application\key определяется в predefined параметрах на уровне каталога general, в конфигурации силоса, а также сохранен в основном архиве профиля пользователя, а также архиве профиля пользователя на уровне силоса.

1. Каталог general: key = A
2. Архив профиля: key = B
3. Конфигурация силоса: key = C
4. Архив профиля в силосе: key = D

При входе пользователя в систему (или запуске приложения, если включен Flex Direct) значение параметра key в реестре будет равно D. Если разрешен экспорт настроек в архив профиля пользователя и на уровне каталога General, и на уровне силоса, то после выхода пользователя из системы (или закрытия приложения) значение key станет равным:

1. Каталог general: key = A
2. Архив профиля: key = D
3. Конфигурация силоса: key = C
4. Архив профиля в силосе: key = D

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

Настройки профиля пользователя через VMware User Environment Manager

Разбираясь в VMware UEM, я решил записать небольшое видео, которое показывает настройку профиля пользователя на примере задания обоев рабочего стола.

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

Ошибка Personal vDisk при обновлении MCS образа Citrix XenDesktop

При обновлении базового образа в Machine Catalog, использующего персональные диски (Persinal vDisk), в консоли Citrix Desktop Studio виртуальная машина отображается со статусом Unregistered, а при подключении к ВМ через консоль появляется ошибка "Citrix personal vDisk failed to Start" с кодом: 0xC03A001A.

При этом в файле журнала PvDActivation.Errors.txt на виртуальной машине могут появляться следующие сообщения:

[ERROR][12-11-2015 14:21:04]VDeskNativeV   [0169] Creating of the child VHD P:\UserData.V2.VHD.UpdateInProgress failed with error -> = -1069940710
[ERROR][12-11-2015 14:21:04]VDeskNativeV   [0577] Failed to create differencing disk P:\UserData.V2.VHD.UpdateInProgress, against P:\UserData.V2.vhd, Error:-1069940710
[ERROR][12-11-2015 14:21:04]VDeskNativeA   [2476] Failed to create diffrencing disk for applying updates,Error:-1069940710

Ошибка возникает из-за того, что на персональном диске (P:\) включено сжатие на уровне файловой системы NTFS, что не поддерживается виртуальными дисками .vhd. Отключите сжатие в свойствах диска (снижите флажок с Compress this drive to save disk space / Сжать этот диск для экономии места) и перезагрузите ВМ.