Citrix pvs в касперском что это
В этой статье речь пойдёт о достаточно новом о функционале под названием App Protection. Данная технология была представлена в версии Citrix Virtual Apps and Desktops 1912 LTSR, но общедоступной стало только с выходом Workspace App 1912, 24 марта 2020 года. Здесь вы также найдёте подробное пошаговое руководство по конфигурации.
Что такое защита приложений (App Protection) и для чего она используется?
С пользовательской точки зрения – это быстрый и простой вариант дополнительной защиты корпоративных ресурсов, не требующий специальной настройки удаленного рабочего места. Это особенно актуально при резком росте количества удаленных рабочих мест вне офиса, в том числе и из дома.
С технической точки зрения, App Protection является интегрированным компонентом Workspace App для Windows и MacOS. App Protection предназначена для предотвращения захвата ввода с клавиатуры при помощи Keylogger, а также записи с экрана, как видео, так и скриншотов.
После выполнения всех этапов конфигурирования будут активны нижеследующие функции:
- Anti-Keylogging – шифрует уже в процессе логина имя и пароль пользователя, а также остальную информации вводимую пользователем в активном окне сессии. Установленный злоумышленником Keylogger будет записывать только бесполезный набор знаков или ничего.
- Anti-Screen-Capturing (предотвращение захвата экрана) – при включённом режиме любая попытка захвата экрана (скриншоты или запись экрана) окрашивает активное окно сессии в серый цвет. Есть небольшое отличие в работе под Windows и MacOs. В Windows весь экран будет серым, в MacOS – только защищаемое окно. В Windows это даже может быть мешающим поведением, поэтому – для создания скриншотов незащищаемых областей необходимо свернуть защищенное окно.
Обе вышеперечисленные функции интегрированы в Workspace App начиная с версии 1912. Использование защиты приложений особенно интересно в различных сценариях BYOD.
Технология защиты приложений, представленная Citrix, очень похожа на продукт Armored Client for Citrix, английской компании SentryBay . Armored Client for Citrix | White Paper
- Workspace app 1912 for Windows
- App Protection Erweiterung
- App Protection Add-On License
- Citrix.StoreFront.AppProtectionPolicy.Control
- FeatureTable.OnPrem.AppProtection.xml-файл
- Set-BrokerDesktopGroup:
- AppProtectionKeyLoggingRequired,
- AppProtectionScreenCaptureRequired
- Citrix Policy: Client Clipboard Redirection (optional)
- Защищённая группа доставки (Delivery Group).
Требования к программному обеспечению и ограничения:
- Citrix Workspace app 1912 for Windows или новее
- Citrix Workspace app 2001 for Mac или новее
- использование в сценариях Double-Hop невозможно
- Citrix Cloud пока не поддерживается
- если Вы используете версии Workspace App, которые не поддерживают функционал App Protection, то защищённые группы доставки (Delivery Group) не отображаются.
- защищённые группа доставки также не отображаются, если доступ осуществляется через браузер (Workspace for Web). Как видно на рисунке ниже, группа доставки, защищённая с помощью App Protection, не видна при доступе через браузер StoreFront:
Подготовка
1.1. Получить дополнительную лицензию (Add-On License). Первый пункт, безусловно, один из самых времязатратных. Add-On лицензия не может быть сгенерирована на странице Citrix в качестве тестовой лицензии, а должна быть запрошена у вашего партнёра Citrix.
1.2. Скачайте Protection Policy File. Файл для версии 1912 вы можете скачать при наличии активной подписки по этой ссылке: FeatureTable.OnPrem.AppProtection.xml
Версии 2003: App Protection Policies 2003, Apr 16, 2020 - Download
1.3. Коммуникация (XML Traffic) между StoreFront и Delivery Controller должна быть зашифрована посредством установки SSL/TSL сертификатов на обоих компонентах.
1.4. Необходимо активировать опцию TrustRequestsSentToTheXmlServicePort на контролёре доставки: Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true
Для проверки конфигурации можно использовать команду Get-BrokerSite :
Установка / Конфигурация
Непосредственно настройка состоит из шести последовательных шагов:
2.1. инсталляция Workspace App на рабочем месте
2.2. добавление Add-on лицензии на сервер лицензий
2.3. активирование AppProtectionPolicy на сервере StoreFront
2.4. Дальнейшие шаги выполняются на контроллере доставки (Delivery Controller):
- импорт файла FeatureTable.OnPrem.AppProtection.xml
- активация функционала AppProtection
- настройка политик Citrix
2.1. Установите рекомендованную версию приложения Workspace на каждом целевом устройстве.
Активируйте опцию Enable app protection при установке.
Производитель предлагает обратите внимание на то, что отключить функцию защиты приложения после установки невозможно. Если вы хотите отключить функцию защиты приложения, вам потребуется переустановить Workspace App. По сути же, наличие активированного функционала AppProtection не несёт негативных последствий.
или с помощью командной строки: CitrixWorkspaceApp.exe /silent /includeSSON /includeappprotection
2.2. Импортируйте лицензионный файл. Существует несколько методов добавления лицензий.
Самый быстрый из них, просто скопировать лицензионный файл в папку
C:\Program Files (x86)\Citrix\Licensing\MyFiles , а затем перезапустить службу лицензирования Citrix:
Restart-Service –Name „Citrix Licensing“
Вы также можете импортировать лицензионный файл с помощью одной из двух консолей управления Citrix Lizenzierung Manager или License Administation Console.
2.3. Для следующего пункта настройки нам необходимо запустить консоль PowerShell (с правами администратора) на основном сервере StoreFront. Выполните следующую команду:
Add-STFFeatureState -Name "Citrix.StoreFront.AppProtectionPolicy.Control" -IsEnabled $True
Результаты можно проверить с помощью следующей команды:
Get-STFFeatureState -Name "Citrix.StoreFront.AppProtectionPolicy.Control”
Примечание . Если ваши сервера StoreFront объединены в группу, то изменения необходимо распространить и на другие сервера.
2.4. Все остальные этапы настройки выполняются на контроллере доставки.
2.4.1. Импортируйте загруженный ранее файл XML:
Import-ConfigFeatureTable .\FeatureTable.OnPrem.AppProtection.xml
С помощью команды Get-ConfigEnabledFeature | Select-String –Pattern 'AppProtection' можно проверить, был ли импорт успешным.
2.4.2. Следующие шаги являются фактической активацией функционала. В настоящее время конфигурация возможна только с помощью PowerShell.
Политики привязываются к выбранным группам (Delivery Groups) по отдельности:
- AppProtectionKeyLoggingRequired
- AppProtectionScreenCaptureRequired
Set-BrokerDesktopGroup -Name NameOfTheSecretGroup -AppProtectionKeyLoggingRequired $true -AppProtectionScreenCaptureRequired $true
Политики могут быть активированы при необходимости индивидуально или вместе.
Настройки можно проверить следующим образом:
Get-BrokerDesktopGroup -Property Name, AppProtectionKeyLoggingRequired, AppProtectionScreenCaptureRequired | Format-List
2.4.3. Настройка политик Citrix. Данная конфигурация является опциональным дополнением и предотвращают использование буфера обмена между конечным клиентом пользователя и сессией Citrix.
Не повредит, если следующие опции будут также отключены для группы с политикой AppProtection:
- Client drive redirection
- Client removable drivers
Создайте новую политику Citrix или отключите нижеследующею опцию уже в существующей политике: Client clipboard redirection:
и свяжите их с соответствующей группой:
На этом конфигурация закончена…
Проверьте работоспособность решения и при необходимости проведите диагностику
All our security apps – at your fingertips. Protect yourself with security apps & features that suit you best.
Погружение в Citrix
Мир ИТ не стоит на месте: каждый вендор развивает свои продукты и вносит что-то новое в линейки оборудования и ПО. Вот и Citrix как лидер в сфере виртуализации, балансировки сетевой нагрузки и решений для совместной работы пользователей, недавно представил новинки. Основные направления, активно развиваемые вендором, — терминальные сервисы и виртуализация рабочих мест (VDI).
При проектировании ИТ-проектов мы решаем множество задач. Часто первой становится выбор между терминальным решением и VDI. Технология виртуализации получается дороже при расчете бюджетной оценки, но позволяет создать изолированную среду с гостевой операционной системой. Использование каждым клиентом изолированной операционной системы повышает безопасность окружения и позволяет избежать конфликта приложений. В терминальной среде возникают ситуации, когда одно приложение не может работать в мультипользовательском режиме. Ответить на вопрос «что же выбрать?» можно, развернув решения от Citrix в тестовом режиме и проверив совместимость с приложениями, используемыми в той или иной компании.
Предположим, что мы остановились на VDI. Помимо основных вводных (количество пользователей, интегрируемые приложения, технические параметры одного виртуального места и т.д.), нужно ответить на вопрос — на сколько необходимо сохранять изменения, сделанные в виртуальном рабочем месте? Виртуальные рабочие места без возможности сохранения данных называются «non-persistent», а с возможностью сохранения — «persistent». Данные, которые сохраняются в виртуальном рабочем месте, делятся на две составляющие: appdata (установленные приложения) и user profiles (пользовательские профили с данными). Если для управления пользовательскими профилями активно используются решения Citrix User Profile Management либо Microsoft Roaming Profiles, то с пользовательскими приложениями дело обстоит сложнее. Реализовать такой функционал без Personal vDisk или использования полных клонов раньше было просто невозможно.
Определиться с решением можно только после анализа инфраструктуры. Например, в одном из наших проектов заказчик использовал самописный портал с доставкой приложений. Другими словами, пользователь мог зайти через веб-браузер, выбрать необходимые приложения и в соответствии с группами безопасности, назначенными ему в Active Directory, установить их на свое рабочее место. Подобный механизм доставки приложений не позволял использовать non-persistent VDI и требовал сохранение данных.
Есть другой сценарии, когда у заказчика используется терминальная ферма для доставки всех приложений. В таком случае persistent VDI не требуется. Это позволяет экономить вычислительные ресурсы на виртуальных рабочих местах и отдавать их под нужды терминальных сервисов, оставляя в виртуальном рабочем месте только те приложения, которые требуют изолированной среды. С точки зрения пользователя все выглядит как обычное рабочее место.
Ниже рассмотрим основные новшества у Citrix, которые позволят лучше ориентироваться в их технологиях после недавних обновлений.
Дизайн VDI и как в нем использовать Citrix App Layering
Поговорим немного о дизайнах VDI-решений. После того как мы определились с количеством persistent и non-persistent виртуальных рабочих мест, необходимо определиться с механизмом их создания. Для этого может использоваться две технологии: machine creation services (MCS) и provisioning services (PVS). Основные различия приведены ниже.
Сравнение принципов работы механизмов развертывания рабочих столов
MCS работает путем обращения консоли управления Citrix Studio к API сервера управления средой виртуализации (vCenter, VMM, XenCenter). Через необходимые команды выполняются основные действия по созданию, удалению или изменению каталогов виртуальных машин. Сервис устанавливается совместно с брокером подключения при развертывании Citrix Virtual Apps and Desktops. С использованием MCS можно создать два типа виртуальных рабочих мест: fast clone (быстрые клоны) и full clone (полные клоны). Если с full clone все понятно, так как это полная копия мастер-образа, то fast clone генерируется по следующему принципу: с мастер-образа создаются виртуальные рабочие места с двумя дополнительными дисками diff disk и id disk. Надо сказать, что id disk присутствует также в полных клонах и хранит в себе информацию о принадлежности к домену. Размер такого диска 16 МБ. Diff disk хранит изменения мастер-образа. Размер этого диска устанавливается для всех виртуальных рабочих мест при создании каталога. При перезагрузке diff disk обнуляется, поэтому использовать его для построения persistent VDI-решений нельзя. Для реализации persistent VDI с использованием быстрых клонов используется дополнительная технология personal vDisk, но об этом ниже.
PVS работает как сервис потоковой загрузки. Устанавливается на отдельный сервер, имеет свою консоль управления. Обращение к API сервера управления средой виртуализации тоже происходит, но в значительно меньшей мере. Основные операции выполняются по сети при загрузке виртуальных рабочих мест. Некоторых пугает дополнительная консоль, т.к. это усложняет администрирование, но я призываю не бояться. PVS-сервис значительно упрощает обновление виртуальных рабочих мест. Загрузка их выполняется из хранилища образов (стандартное сетевое хранилище smb или каталог на локальном диске PVS-сервера). Образ представляет собой служебный файл и виртуальный жесткий диск (.vhd), используемый при загрузке. Процесс обновления благодаря этому сервису очень простой — необходимо просто подключить другой виртуальный жёсткий диск и перезагрузить рабочее место. Разумеется, с использованием подобного сервиса создаются non-persistent виртуальные рабочие места (примечание: у данного сервиса есть способ кэширования, позволяющий сохранять все изменения, но в практике я таких решений не встречал, поэтому не стал бы их рекомендовать). Для реализации persistent VDI с использованием PVS-сервиса использовался такой же принцип, как и для быстрых клонов.
Из-за различной специфики работы технологий нагрузка ложится на различные компоненты соответственно. Если в случае работы PVS-сервиса большая нагрузка ложится на сеть, то в случае с использованием MCS-сервиса нагрузка ложится на используемую систему хранения данных.
Приведу примеры основных дизайнов VDI-решений, которые мне удалось реализовать:
- Использование сервиса MCS для создания клонов с разностным диском (fast clone), либо сервиса PVS и хранение всех изменений (app data\user profile) на выделенном персональном диске (Personal vDisk).
- Использование сервиса MCS для создания полных клонов (full clone) с экономией затраченного дискового пространства за счет системы хранения данных с дедупликацией и компрессией.
- Использование сервиса MCS для создания клонов с разностным диском (fast clone) либо сервиса PVS и перемещение пользовательских профилей с помощью технологии Citrix User Profile Management. Это, разумеется, не полный persistent VDI, в подобных дизайнах у пользователя сохраняются только настройки приложений, которые хранятся в профиле пользователя и пользовательские данные. Установка приложений в такой конфигурации невозможна, т.к. после перезагрузки виртуального рабочего места изменения откатываются. Подобный дизайн часто используется в call-центрах.
RIP, Personal vDisk
После того, как Citrix объявил, что технология personal vDisk больше развиваться не будет, реализация 1-го дизайна стала нереалистична. Заказчики начали отказываться от этой идеи, да и сама по себе технология personal vDisk имела ряд недостатков. В моей практике решение работало хорошо при статическом использовании виртуальных рабочих мест, то есть когда виртуальное рабочее место назначалось одному пользователю, соответственно ему подключался персональный диск, на котором хранились все изменения. При рандомном использовании виртуальных рабочих мест и персональных дисков зачастую возникали проблемы при получении пользователем нового виртуального рабочего места и подключением к нему персонального диска. Но все равно использование 1-го дизайна со статически выделенными виртуальными рабочими местами позволяло значительно экономить дисковое пространство, данные пользователей и установленные приложения в виртуальном рабочем месте можно было размещать на «медленных» дисках, а, чтобы не терять производительность ОС, все изменения, сделанные от мастер образа (diff disk), размещать на «быстрых» дисках. Такой дизайн позволял существенно экономить дисковое пространство и не терять производительность виртуальных рабочих мест.
В решении Citrix App Layering было объявлено, что один из слоев (User Layer) позволит реализовать функционал, подобный personal vDisk, но практически год данный слой находился в статусе лабораторных. В очередном обновлении 25 сентября в документе по App Layering наконец-то появилось обновление на эту тему и было объявлено, что User Layer доступен для использования в продуктивных средах.
Важное обновление, позволяющее реализовать дизайн 1-го типа с использованием решения Citrix App Layering и слоя User Layer для хранения пользовательских данных и установленных приложений пользователем.
Forum
Does reassigning computers to new workspaces have a known issue with computer names?
Kaspersky Administration Server Network Agent issue
password manager 10 problem
@MickyFair Thank you for your feedback. Can you please reproduce the issue and check your Windows event log.
Продление Internet Security в Украине
Спасибо большое !! Самое интересное, что теперь появилось еще больше вопросов ))) На картинке пишется 2017, в описании 2018, сегодня 2022, а прошлая лицензия была продлена в 2021, но картой для 2020. Просто какая-то каша-малаша, как понять и разобраться во всём этом просто не имею представления. Как человек должен понять, сработает ли код 2018 года для антивируса 2022 года ? И вообще почему он должен сработать, если он уже старый и ему 4 года ))) Это капец ))))
password manager 10 problem
this is a clean install after a fresh install of win10 sorry should have made that clearer in the original post
Kaspersky Administration Server Network Agent issue
Hi hope so you all experts are you doing well. Im working in a sector which is running over 1000 Computers. We purchased the kaspersky license for better security reasons. The issue with my kaspersky administration server is that after successfull installation of kapersky server and all other required policies and agents almost 595 computers gets all the updates from kaspersky administration server they were running smoothly communication was great. All of a sudden my administration server crashed and my badluck that i had no backup i reinstall the administration server and connect activer directory and created policies as well tasks for communication with client pc but the issue is this that kaspersky administration server is not communicating with those clients which already had network agents and kes. I want a solid solution for this problem that my those 595 pcs get connected to administration server automatically. Thanks looking forward
Does reassigning computers to new workspaces have a known issue with computer names?
Hi all, I'm back with a new problem. I have a several-month-old laptop that I originally set up for a different user. I wiped it and set it up for another person, but for some reason Kaspersky Endpoint Security isn't connecting to the workspace; it's visible for two minutes and then disappears from the Cloud. The laptop retains the same name as before. is that a known issue? I'm going from one workspace to another, and had reassigned the other user to another machine before deleting this machine from that workspace. I've tried uninstalling completely, wiping Kaspersky off the face of the planet from this machine, reinstalling with a package from the new workspace, installing the update, putting in the activation key. just about everything except renaming the computer.
Вопрос, что лучше MCS или PVS, является предметом интенсивных дискуссий уже многие годы. Каждая технология имеет как своих сторонников, так и противников. И я пожалуй, не ошибусь, если скажу, что приверженцы PVS все еще в большинстве.
Понятно, что у каждой технологии есть свои преимущества и недостатки. Часто недостатки одной технологии одновременно являются преимуществом другой. И MCS, и PVS преследуют одну общую цель, а именно, быстрое создание и развёртывание виртуальных машин для инфраструктуры XenDesktop. В обоих случаях мы говорим о создании Master-Image и его распределении соответствующим целевым системам.
Если PVS передает vDisk по сети, то MCS использует функции гипервизора для создания виртуальных машин. В широком смысле можно сказать, что PVS создает нагрузку на сеть, а MCS на СХД (Storage).
Итак, предлагаю небольшое сравнение обоих технологий.
Недостатки PVS
- Основным недостатком внедрения PVS является дополнительное усложнение всей инфраструктуры и связанные с этим затраты.
- Консоль управления довольно устарела и не слишком интуитивна
- PVS создает дополнительную нагрузку на сети, но в современных сетях данная тема не заслуживает особого внимания.
- PVS не способен работать в облаке (полагаю, что это лишь временное ограничение).
- PVS может работать только в пределах локальной сети.
- Создание образа (Master-Image) занимает достаточно много времени.
- PVS требует следующие дополнительные компоненты инфраструктуры при внедрении:
- PVS-Server (2 сервера для создания высокой доступности)
- PVS-Store (место для хранения vDisk-ов)
- дополнительные опции на DHCP сервере (66 и 67)
- дополнительная база данных
- создание шаблонов виртуальных машин.
Преимущества PVS
- PVS обеспечивает более гибкий способ для управления версиями системы
- В случае возникновения проблемы с актуальной версией системы, откат на предыдущую может быть выполнен в кратчайшие сроки. Фактически речь идет лишь о перезагрузки виртуальных машин.
- PVS может быть использован не только с виртуальными, но и с физическими машинами.
- Все изменения, сделанные пользователями во время работы, будут сброшены после перезагрузки.
- PVS требует значительно меньшего пространства на СХД.
- Физические требования к СХД значительно ниже, чем у MCS.
- Простота резервного копирования, достаточно лишь сохранить диск (.vhdx) и конфигурационные файлы к нему.
- теоретически, возможно использование одного и того же образа, как для виртуальной, так и для физической среды.
Если в вашей инфраструктуре используется гипервизор XenServer (версии 7.1 и выше), то встроенная технология кэширования (PVS-Accelerator) значительно снизит нагрузку на сеть. Лишь одна виртуальная машина (вернее ее vDisk) будет передана по сети и сохранена в кэше гипервизора. Все остальные VM будут загружены из кэша.
Machine Creation Services
В версии XenDesktop 7.9 компания Citrix значительно улучшила функциональность MCS, представив новую технологию, называемую MCS Storage Optimization. Она позволяет снизить нагрузку и повысить производительность. Функциональность MCS Storage Optimization идентична функции PVS „Cache in Device RAM with Overflow on Hard Disk“
Недостатки MCS
- MCS требует гораздо больше времени для развертывания и отката к предыдущей версии *
- высокие требования по IOPS к СХД (речь идет прежде всего о так называемом Boot-Storm) *
- потребляет значительно больше места на СХД *
- с помощью MCS возможно только развёртывание виртуальных систем
* Зависит от используемых систем хранения и количества прикрепленных хранилищ данных (Datastore). Частота обновления системы также имеет значение.
Данная картинка иллюстрирует процесс обновления имиджа. При каждом обновлении каталога машин, вся процедура повторяется снова (шаги 1-3). Необходимо помнить, что базовый диск будет скопирован на все подключенные хранилища. Чем больше хранилищ подключено при конфигурации хоста, тем медленнее общий процесс. Использование All-Flash СХД (например, PureStorage) может устранить проблемы с Boot-Storm. А применение дедупликации данных сводит к минимуму потребность в дисковом пространстве.
Преимущества MCS
- Никаких дополнительных компонентов (SQL, Store) и внесение изменений (DHCP) в инфраструктуру не требуется.
- Функционал полностью интегрирован в Studio, дополнительная консоль управления не требуется.
- MCS интуитивен и прост в обращении- возможность использования в облаке (Microsoft Azure, Amazon AWS)
Нижеперечисленные шаги, необходимые для обновления образа:
MCS - Обновление образа
- включить Master-VM
- внести необходимые изменения
- выключить Master-VM
- создайте снимок системы (Snapshot)
- обновите каталог машины на основе снапшота
PVS – Обновление образа
- создать новую версию vDisk (Maintenance Disk)
- включить Maintenance -VM
- в меню загрузки выбрать Maintenance Disk
- внести необходимые изменения
- выключить Maintenance -VM
- перевести виртуальную машину в режим Production
- перезагрузить виртуальные машины из коллекции
Заключение
Для меня лично, одно их основных преимуществ PVS, — это скорость отката на предыдущую версию. Необходимо просто выбрать в свойствах диска желаемую версию и перезагрузить подключённые к диску компьютеры. В MCS хоть и есть кнопка „Rollback Machine Update“, но в зависимости от скорости и количества узлов СХД процесс может занимать достаточно длительное время. Другой неоспоримый плюс PVS возможность нахождения одного и того же диска в трех режимах одновременно: обслуживания, тестирования и продуктивном.
Как вы можете видеть, каждая технология имеет свои преимущества и недостатки. Существуют сценарии, в которых одна технология наиболее близко соответствует вашим требованиям, чем другая. С помощью Proof-of-Concept вы можете быстро получить первоначальный опыт и принять правильное решение.
Дополнительная полезная информация
Сравнение PVS vs MCS от ведущего инженера фирмы Citrix, Даниэля Феллера - PVS vs MCS
Всегда рад Вашим отзывам, комментариям и конструктивной критике
В данной статье я попытаюсь максимально просто описать принципы работы двух основных методов развертывания виртуальных машин в инфраструктуре Citrix.
Принцип работы MCS
Citrix Machine Creation Services является одним из двух типов массового автоматизированного развертывания виртуальных машин и в сравнении с Provisioning Services (PVS) MCS является встроенным функционалом XenDesktop.
Нижеследующие шаги описывают процесс создания каталога виртуальных машин для их дальнейшего развертывания механизмом MCS.
Создание виртуальных машин в каталоге можно условно разделить на следующие этапы:
1. Будем исходить из того, что ваша виртуальная машина полностью проинсталлирована и готова к развёртыванию. Прежде всего необходимо сделать снимок виртуальной машины (Snapshot), если его не сделать вручную, то он будет сделан автоматически и ему будет присвоено имя состоящие из имени каталога и даты.
2. На базе основного диска и снепшота будет создана новая версия, так называемый Base Disk. Base Disk является основой для последующего создания виртуальных машин каталога.
3. Средствами гипервизора создается (клонируется) заданное при конфигурации количество виртуальных машин. При применении гипервизора vSphere используется технология Linked Clone.
Каждая созданная виртуальная машина состоит из двух дисков:
a. Difference (Delta) Disk – на этом диске содержится временная информация, используемая операционной системой. После каждой перезагрузки вся записанная информация удаляется. Difference Disk можно считать аналогом Write Cache Disk в PVS.
b. Identity Disk – на нем сохраняется информация, делающую систему уникальной, например SID, имя компьютера, пароль. Размер диска составляет всего 16 MB.
4. Для каждой машины создается учетная запись в Active Directory.4. Для каждой машины создается учетная запись в Active Directory.
5. После перезагрузки, созданные виртуальных машины получают IP-адрес от DHCP-сервера.
Каждая последующая актуализация системы требует повторения шагов от 1 до 3.
Full Clone
MCS Full Clone – создание полноценной копии виртуальной машины
В версии XenDesktop 7.11 появилась возможность выбора, использовать ли Full Clone или Linked Clone. Основное преимущество Full Clone, — это возможность создания резервной копии виртуальной машины, что в свою очередь упрощает процесс миграции виртуальных машин.
Использование технологии Full Clone имеет, к сожалению, и недостатки, а именно: значительно увеличивается время создания / обновления каталогов, требуется больше места на СХД и Full Clone применима только для настольных операционных систем (Windows 10).
Принцип работы PVS
PVS - это технология, которая обеспечивает одновременную загрузку операционной системы по сети с помощью стриминга на множество целевых систем (виртуальных или физических). Целевые компьютеры, в отличие от классического ПК, не имеют жесткого диска с установленной операционной системой и запускаются непосредственно из сети. Передачи нескольких сотен мегабайт уже достаточно для старта операционной системы и регистрации пользователя в ней. Например, окно регистрации в системе Windows 10 появляется после загрузки 250 MB.
Ключевым элементом инфраструктуры PVS является Provisioning Server. Сервер PVS не только отвечает за управление средой PVS, но и является центральной точкой потоковой передачи vDisk-ов. Все настройки конфигурации хранятся в базе данных MS SQL. По сравнению с MCS, PVS не является частью XenApp / XenDesktop.
Для достижения высокой доступности требуется как минимум два сервера PVS. Серверы PVS используют протокол IPC для связи друг с другом.
Следующие шаги описывают принцип работы PVS:
- PVS Streaming Service предоставляет файл (PXE-Bootstrap File: ARDBP32.BIN) для начальной загрузки. PXE-Bootstrap File содержит инструкции для запроса виртуального диска.
- На основании MAC-адреса проверяется, имеет ли целевая система запись в базе данных PVS.
- vDisk передается по сети целевой системе. Передача данных осуществляется по UDP протоколу.
Master Image - vDisk
Для создания vDisk-а необходимо на операционной системе (серверной или настольной) установить PVS Target Device. Задача PVS Target Device сконвертировать диск операционной системы в vhd-файл (с версии 7.7 у вас есть выбор между VHD и VHDX) и сохранить его в соответствующей папке (PVS Store). Для конвертации используется XenConvert Tool.
В папке PVS Store сохраняются файлы следующих типов:
- .vhdx (vhd) – диск операционной системы
- .lok – файл блокировки доступа, активен если vDisk используется
- .pvp – конфигурационный файл vDisk
- .avhd - (z.B. .1.avhdx) – файл с последними сохранёнными изменениями (Differencing Disk)
Методы загрузки
Существует три различных способа загрузки целевых систем в среде PVS: DHCP, PXE и BDM:
1. DHCP Метод
DHCP является наиболее широко используемым и пожалуй самым популярным методом. Клиент получает IP-адрес от DHCP-сервера, который включает в себя следующие параметры:- Option 66 – здесь указывается IP-адрес PVS сервера - Option 67 – имя файла загрузки (ARDBP32.bin)
2. PXE Метод
Клиент получает только IP-адрес с сервера DCHP, так как на DHCP-сервере не настроены опции 66 и 67. PVS сервер сам реагирует на запрос клиента и отвечает ему передавая параметры опций 66 / 67. Данный метод крайне редок и не всегда возможен, ввиду определённой зависимости от конфигурации сети.
3. BDM (Boot Device Manager)
В этом случае целевая система запускается непосредственно с физического загрузочного носителя (CD). Этот метод бывает единственно возможным для использования PVS, так как опции 66 / 67 уже используются другими системами (например, SCCM или Matrix42).
Пошаговое описание процесса загрузки
1. Получение IP адреса - целевое устройство получает IP-адрес от DHCP сервера. Вместе с IP-адресом передаются также адрес TFTP-сервера (Option 66) и название файла загрузки (Option 67).
2. Загрузка Bootstrap файла - загрузочный файл (ARDBP32.bin) скачивается с TFTP-сервера на целевое устройство.
3. Процесс входа в систему PVS - после того, как целевое устройство получило IP-адрес и скачало загрузочный файл, оно регистрируется на PVS-сервере, чтобы начать стриминг vDisk-а.
4. Single Read Mode – целевое устройство начинает отправлять запросы на PVS-сервер в так называемом режиме одиночного чтения и делать это до тех пор, пока операционная система не начнет загружать драйверы, и не загрузит BNISTACK-драйвер.
5. BNISTACK / MIO Read Mode – заключительная фаза загрузки системы. BNISTACK загружается в память и продолжает управлять коммуникацией между сервером и целевым устройством. BNISTACK использует параллельно несколько потоков для связи с сервером PVS. Multiple Input/Output - один канал используется для запроса и множество для получения ответа от сервера PVS.
PVS Store
Store – это место физического хранения для vDisk-ов. Данная папка может находиться как на любом из PVS-серверов, так и на общем хранилище (Shared Storage). Важно позаботиться о достаточном количестве места на диске и быстром доступе к нему (IOPS performance).
Использование совместного хранилища (Shared Storage) не требует дополнительных механизмов для синхронизации vDisks-ов.
Сервера PVS не имеют встроенных механизмов для репликации vDisk-ов между собой. Для этого чаще всего используется простой и удобный метод, - скрипт на основе команды robocopy. Использование распределенной файловой системы (DFS) также возможно.
Write Cache
В стандартном режиме (Standard Mode) vDisk доступен только для чтения (read only), и все данные, которые обычно записываются на системный диск виртуальной машины, переносятся в Write Cache. Существует несколько различных режимов настроек Write Cache.
Write Cache - это временная память, содержащая данные, созданные операционной системой во время работы, а также информация, которую следует сохранить после перезагрузки (например, журналы событий, сигнатуры вирусов, кэш App-V). Write Cache Disk также является типичным местом для хранения Pagefile-файла.
Write-Cache файл (vdiskdiff.vhdx) постоянно растет в течении работы системы и обнуляется только после перезагрузки. vdiskdiff фактически и является следующими опциями “Cache on Target Device Hard Drive” и „Cache in device RAM withoverflow on hard disk“
Текущая версия PVS предлагает шесть различных опций для хранения Write-Cache. У каждого варианта есть свои плюсы и минусы. Рекомендуется использовать „Cache in device RAM with overflow on hard disk“
Возможные варианты размещения Write Cache
Кэш на жестком диске целевого устройства (Cache on device hard disk)
В данном случае Write Cache расположен на жестком диски целевого устройства. До недавнего времени данный вариант был самым предпочтительным решением.
Постоянный к эш на жестком диске целевого устройства и сервера (Cache on device hard disk persisted / Cache on server, persistent )
Как следует из названия, речь идет о постоянном, не сбрасываемом после перезагрузки файла кэша.
Write Cache в рабочей памяти целевого устройства (Cache in device RAM)
Если вы хотите получить максимально возможную производительность, то этот вариант будет наиболее предпочтителен, но крайне дорогостоящим.
Write Cache на жестком диске PVS сервера (Cache on server)
Данный способ наиболее неэффективный из всех перечисленных. Write Cache расположен на PVS-сервере, доступ к которому осуществляется по сети.
Write Cache в рабочей памяти целевого устройства с переполнением на жесткий диск (Cache in device RAM with overflow on hard disk)
Данная опция представляет собой идеальный баланс между производительностью и стоимостью. Опция имеет два уровня. Вначале все изменения хранятся в памяти виртуальной машины. Размер памяти, вернее его максимальное значение для каждого виртуального диска настраивается в конфигурации. Не забывайте о том, что выделенная память будет взята из общей памяти виртуальной машины. Когда выделенная память будет заполнена, наименее востребованные данные, будут перемещены из области ОЗУ в файл (vdiskdif.vhdx) на жестокий диск виртуальной машины. В настоящее время данная опция является рекомендованной производителем.
Режим доступа к vDisk
Private Mode - в этом случае vDisk находится в состоянии записи и соединен только с одной виртуальной машиной.
Standard Mode - vDisk доступен только для чтения и используется многими виртуальными машинами одновременно.
Иными словами, в Private Mode диск всегда имеет отношение 1:1, в стандартном режиме всегда соотношение 1:n.
Обновление vDisk-а
Как вы можете видеть на приведенных ниже рисунках, целевое устройство может быть загружено с разных версий диска. Differencing Disk (.avhdx) – это всегда зависимый от предыдущей версии снимок файловой системы, по функциональности сравнимый со снапшотом. Все .avhdx-файлы последовательно нумеруются. Differencing Disk используется для установки программного обеспечения, обновлений или исправлений.
Существует три различных метода доступа: обслуживание (Maintenance), тестирование и рабочий (Produktion)
Maintenance - является доступной для записи версией, которая может использоваться только одной виртуальной машиной, чаще всего специально созданной для этих целей.
Test - это версия, предназначенная только для чтения, используемая для тестирования.
Produktion – рабочая версия, из которой загружены все виртуальные машины каталога
Дополнительная полезная информация
Подробные диаграммы и описание процесса загрузки (постер): Citrix Provisioning Services Boot Process
Best Practices for Configuring Provisioning Services Server on a Network (CTX117374) - Прочитать
Guidance on PVS Ports and Threads - Прочитать
Understanding Write Cache in Provisioning Services Server (CTX119469) - Прочитать
Size Matters: PVS RAM Cache Overflow Sizing - Прочитать
Всегда рад Вашим отзывам, комментариям и конструктивной критике
Говоря про космические корабли, бороздящие просторы Большого Театра цифровую трансформацию компаний, никто не даёт пояснений, какие конкретные шаги нужно сделать, чтобы прийти в эту самую цифровую эпоху. В этом цикле статей мы не станем говорить про все и сразу, а расскажем про одно из направлений — цифровизацию рабочего пространства (digital workspace). Опишем, как его понимает каждый из ведущих производителей области, и что со всем этим делать ИТ-специалистам.
Выводы и рекомендации
Очевидные проблемы классической организации виртуальных рабочих мест заставили Citrix пересмотреть свой подход в сторону гибридной многослойной структуры виртуальной машины, что позволило создавать persistent VDI в non-persistent окружении (забегая вперёд, это справедливо и для остальных вендоров).
В реалиях Citrix делается упор на развитие Citrix App Layering, поэтому я бы рекомендовал присмотреться к данному решению при разработке эскиза вашего VDI. Данный продукт значительно сократит трудозатраты на обслуживание мастер-образа, позволит быстрее компилировать необходимые образы для различных подразделений и, разумеется, увеличит гибкость решения за счет Elastic Layer. И не забывайте про User Layer, благодаря которому можно реализовать дизайн 1-го типа.
Роман Мирзаянов, Старший инженер-проектировщик вычислительных комплексов,
«Инфосистемы Джет»
Ребрендинг
В первую очередь хочется отметить невероятную любовь вендора к изменению названий своих продуктов. Взять хотя бы основной, за который многие так полюбили Citrix. Как только его не называли: и Metaframe, и Presentation Server, и XenApp. Сейчас остановились на Virtual Apps. Функционал при этом везде остается одинаковый — предоставлять доступ к серверным приложениям.
Те, кто наблюдают за новостями вендора, наверняка уже знают, что произошел очередной ребрендинг продуктов и называются они теперь по-новому. Это касается не только решений по организации терминального доступа, но и остальных продуктовых линеек. На рисунке ниже приведены старые и новые названия. Не запутайтесь :)
Изменились не только названия привычных нам продуктов, но и уровни редакции каждого из решений. Обратите внимание, чтобы избежать путаницы в редакциях продуктов XenApp: теперь уровень Advanced — это не стартовая лицензия, а лицензия, равная уровню Enterprise. В таблице ниже приведены все изменения:
Устаревшее наименование | Устаревшая редакция | Новое наименование | Новая редакция |
XenApp | Advanced | Virtual Apps | Standard |
XenApp | Enterprise | Virtual Apps | Advanced |
XenApp | Platinum | Virtual Apps | Premium |
XenDesktop | VDI | Virtual Desktops | Standard |
XenDesktop | Enterprise | Virtual Apps and Desktops | Advanced |
XenDesktop | Platinum | Virtual Apps and Desktops | Premium |
XenServer | Standard | Hypervisor | Standard |
XenServer | Enterprise | Hypervisor | Premium |
NetScaler ADC VPX | Standard | ADC VPX | Standard |
NetScaler ADC VPX | Enterprise | ADC VPX | Advanced |
NetScaler ADC VPX | Platinum | ADC VPX | Premium |
Citrix App Layering
Помимо изменений в названиях хочу отметить и обновленное видение VDI-решений основных производителей. Речь идет о построение дизайна с использованием ПО, которое позволяет разделить образ на несколько слоёв. У VMware оно называется App Volume, у Citrix — App Layering. Примечательно, что оба решения могут работать не только с VDI своих производителей, но и с решениями конкурентов, например, с VMware Horizon.
Основная идея решения — создание различных слоев, например, с операционной системой, со средой виртуализации или с приложениями, а затем их компиляция в рабочий образ для пользователей. Делается это все быстро, на выходе получаем разнообразные типы образов для различных групп пользователей со своими приложениями.
В решении Citrix App Layering используются следующее слои:
- Платформы (Platform Layer)
- Операционной системы (Operating System Layer)
- Приложений (Application Layer)
- Персональные (User Layer)
Из слоев собирается единый монолитный образ, который и доставляется пользователю. Предварительно каждый слой требуется подготовить. Сам процесс сборки образа не занимает много времени.
Помимо использования монолитных образов у App Layering есть возможность доставлять слои приложений в виртуальное рабочее место через Elastic Layering. Данная функция позволяет персонализировать пользовательское окружение по запросу. Управляется эта функция через группы безопасности в Active Directory, что позволяет добавлять наборы приложений в виртуальное рабочее место.
Правила лицензирования приведены в таблице ниже:
Важное примечание: App Layering доступен только при наличии активной поддержки от Citrix (Customer Success Services).
Forum
Does reassigning computers to new workspaces have a known issue with computer names?
Kaspersky Administration Server Network Agent issue
password manager 10 problem
@MickyFair Thank you for your feedback. Can you please reproduce the issue and check your Windows event log.
Продление Internet Security в Украине
Спасибо большое !! Самое интересное, что теперь появилось еще больше вопросов ))) На картинке пишется 2017, в описании 2018, сегодня 2022, а прошлая лицензия была продлена в 2021, но картой для 2020. Просто какая-то каша-малаша, как понять и разобраться во всём этом просто не имею представления. Как человек должен понять, сработает ли код 2018 года для антивируса 2022 года ? И вообще почему он должен сработать, если он уже старый и ему 4 года ))) Это капец ))))
password manager 10 problem
this is a clean install after a fresh install of win10 sorry should have made that clearer in the original post
Kaspersky Administration Server Network Agent issue
Hi hope so you all experts are you doing well. Im working in a sector which is running over 1000 Computers. We purchased the kaspersky license for better security reasons. The issue with my kaspersky administration server is that after successfull installation of kapersky server and all other required policies and agents almost 595 computers gets all the updates from kaspersky administration server they were running smoothly communication was great. All of a sudden my administration server crashed and my badluck that i had no backup i reinstall the administration server and connect activer directory and created policies as well tasks for communication with client pc but the issue is this that kaspersky administration server is not communicating with those clients which already had network agents and kes. I want a solid solution for this problem that my those 595 pcs get connected to administration server automatically. Thanks looking forward
Does reassigning computers to new workspaces have a known issue with computer names?
Hi all, I'm back with a new problem. I have a several-month-old laptop that I originally set up for a different user. I wiped it and set it up for another person, but for some reason Kaspersky Endpoint Security isn't connecting to the workspace; it's visible for two minutes and then disappears from the Cloud. The laptop retains the same name as before. is that a known issue? I'm going from one workspace to another, and had reassigned the other user to another machine before deleting this machine from that workspace. I've tried uninstalling completely, wiping Kaspersky off the face of the planet from this machine, reinstalling with a package from the new workspace, installing the update, putting in the activation key. just about everything except renaming the computer.
Вопрос, что лучше MCS или PVS, является предметом интенсивных дискуссий уже многие годы. Каждая технология имеет как своих сторонников, так и противников. И я пожалуй, не ошибусь, если скажу, что приверженцы PVS все еще в большинстве.
Понятно, что у каждой технологии есть свои преимущества и недостатки. Часто недостатки одной технологии одновременно являются преимуществом другой. И MCS, и PVS преследуют одну общую цель, а именно, быстрое создание и развёртывание виртуальных машин для инфраструктуры XenDesktop. В обоих случаях мы говорим о создании Master-Image и его распределении соответствующим целевым системам.
Если PVS передает vDisk по сети, то MCS использует функции гипервизора для создания виртуальных машин. В широком смысле можно сказать, что PVS создает нагрузку на сеть, а MCS на СХД (Storage).
Итак, предлагаю небольшое сравнение обоих технологий.
Недостатки PVS
- Основным недостатком внедрения PVS является дополнительное усложнение всей инфраструктуры и связанные с этим затраты.
- Консоль управления довольно устарела и не слишком интуитивна
- PVS создает дополнительную нагрузку на сети, но в современных сетях данная тема не заслуживает особого внимания.
- PVS не способен работать в облаке (полагаю, что это лишь временное ограничение).
- PVS может работать только в пределах локальной сети.
- Создание образа (Master-Image) занимает достаточно много времени.
- PVS требует следующие дополнительные компоненты инфраструктуры при внедрении:
- PVS-Server (2 сервера для создания высокой доступности)
- PVS-Store (место для хранения vDisk-ов)
- дополнительные опции на DHCP сервере (66 и 67)
- дополнительная база данных
- создание шаблонов виртуальных машин.
Преимущества PVS
- PVS обеспечивает более гибкий способ для управления версиями системы
- В случае возникновения проблемы с актуальной версией системы, откат на предыдущую может быть выполнен в кратчайшие сроки. Фактически речь идет лишь о перезагрузки виртуальных машин.
- PVS может быть использован не только с виртуальными, но и с физическими машинами.
- Все изменения, сделанные пользователями во время работы, будут сброшены после перезагрузки.
- PVS требует значительно меньшего пространства на СХД.
- Физические требования к СХД значительно ниже, чем у MCS.
- Простота резервного копирования, достаточно лишь сохранить диск (.vhdx) и конфигурационные файлы к нему.
- теоретически, возможно использование одного и того же образа, как для виртуальной, так и для физической среды.
Если в вашей инфраструктуре используется гипервизор XenServer (версии 7.1 и выше), то встроенная технология кэширования (PVS-Accelerator) значительно снизит нагрузку на сеть. Лишь одна виртуальная машина (вернее ее vDisk) будет передана по сети и сохранена в кэше гипервизора. Все остальные VM будут загружены из кэша.
Machine Creation Services
В версии XenDesktop 7.9 компания Citrix значительно улучшила функциональность MCS, представив новую технологию, называемую MCS Storage Optimization. Она позволяет снизить нагрузку и повысить производительность. Функциональность MCS Storage Optimization идентична функции PVS „Cache in Device RAM with Overflow on Hard Disk“
Недостатки MCS
- MCS требует гораздо больше времени для развертывания и отката к предыдущей версии *
- высокие требования по IOPS к СХД (речь идет прежде всего о так называемом Boot-Storm) *
- потребляет значительно больше места на СХД *
- с помощью MCS возможно только развёртывание виртуальных систем
* Зависит от используемых систем хранения и количества прикрепленных хранилищ данных (Datastore). Частота обновления системы также имеет значение.
Данная картинка иллюстрирует процесс обновления имиджа. При каждом обновлении каталога машин, вся процедура повторяется снова (шаги 1-3). Необходимо помнить, что базовый диск будет скопирован на все подключенные хранилища. Чем больше хранилищ подключено при конфигурации хоста, тем медленнее общий процесс. Использование All-Flash СХД (например, PureStorage) может устранить проблемы с Boot-Storm. А применение дедупликации данных сводит к минимуму потребность в дисковом пространстве.
Преимущества MCS
- Никаких дополнительных компонентов (SQL, Store) и внесение изменений (DHCP) в инфраструктуру не требуется.
- Функционал полностью интегрирован в Studio, дополнительная консоль управления не требуется.
- MCS интуитивен и прост в обращении- возможность использования в облаке (Microsoft Azure, Amazon AWS)
Нижеперечисленные шаги, необходимые для обновления образа:
MCS - Обновление образа
- включить Master-VM
- внести необходимые изменения
- выключить Master-VM
- создайте снимок системы (Snapshot)
- обновите каталог машины на основе снапшота
PVS – Обновление образа
- создать новую версию vDisk (Maintenance Disk)
- включить Maintenance -VM
- в меню загрузки выбрать Maintenance Disk
- внести необходимые изменения
- выключить Maintenance -VM
- перевести виртуальную машину в режим Production
- перезагрузить виртуальные машины из коллекции
Заключение
Для меня лично, одно их основных преимуществ PVS, — это скорость отката на предыдущую версию. Необходимо просто выбрать в свойствах диска желаемую версию и перезагрузить подключённые к диску компьютеры. В MCS хоть и есть кнопка „Rollback Machine Update“, но в зависимости от скорости и количества узлов СХД процесс может занимать достаточно длительное время. Другой неоспоримый плюс PVS возможность нахождения одного и того же диска в трех режимах одновременно: обслуживания, тестирования и продуктивном.
Как вы можете видеть, каждая технология имеет свои преимущества и недостатки. Существуют сценарии, в которых одна технология наиболее близко соответствует вашим требованиям, чем другая. С помощью Proof-of-Concept вы можете быстро получить первоначальный опыт и принять правильное решение.
Дополнительная полезная информация
Сравнение PVS vs MCS от ведущего инженера фирмы Citrix, Даниэля Феллера - PVS vs MCS
Всегда рад Вашим отзывам, комментариям и конструктивной критике
В данной статье я попытаюсь максимально просто описать принципы работы двух основных методов развертывания виртуальных машин в инфраструктуре Citrix.
Принцип работы MCS
Citrix Machine Creation Services является одним из двух типов массового автоматизированного развертывания виртуальных машин и в сравнении с Provisioning Services (PVS) MCS является встроенным функционалом XenDesktop.
Нижеследующие шаги описывают процесс создания каталога виртуальных машин для их дальнейшего развертывания механизмом MCS.
Создание виртуальных машин в каталоге можно условно разделить на следующие этапы:
1. Будем исходить из того, что ваша виртуальная машина полностью проинсталлирована и готова к развёртыванию. Прежде всего необходимо сделать снимок виртуальной машины (Snapshot), если его не сделать вручную, то он будет сделан автоматически и ему будет присвоено имя состоящие из имени каталога и даты.
2. На базе основного диска и снепшота будет создана новая версия, так называемый Base Disk. Base Disk является основой для последующего создания виртуальных машин каталога.
3. Средствами гипервизора создается (клонируется) заданное при конфигурации количество виртуальных машин. При применении гипервизора vSphere используется технология Linked Clone.
Каждая созданная виртуальная машина состоит из двух дисков:
a. Difference (Delta) Disk – на этом диске содержится временная информация, используемая операционной системой. После каждой перезагрузки вся записанная информация удаляется. Difference Disk можно считать аналогом Write Cache Disk в PVS.
b. Identity Disk – на нем сохраняется информация, делающую систему уникальной, например SID, имя компьютера, пароль. Размер диска составляет всего 16 MB.
4. Для каждой машины создается учетная запись в Active Directory.4. Для каждой машины создается учетная запись в Active Directory.
5. После перезагрузки, созданные виртуальных машины получают IP-адрес от DHCP-сервера.
Каждая последующая актуализация системы требует повторения шагов от 1 до 3.
Full Clone
MCS Full Clone – создание полноценной копии виртуальной машины
В версии XenDesktop 7.11 появилась возможность выбора, использовать ли Full Clone или Linked Clone. Основное преимущество Full Clone, — это возможность создания резервной копии виртуальной машины, что в свою очередь упрощает процесс миграции виртуальных машин.
Использование технологии Full Clone имеет, к сожалению, и недостатки, а именно: значительно увеличивается время создания / обновления каталогов, требуется больше места на СХД и Full Clone применима только для настольных операционных систем (Windows 10).
Принцип работы PVS
PVS - это технология, которая обеспечивает одновременную загрузку операционной системы по сети с помощью стриминга на множество целевых систем (виртуальных или физических). Целевые компьютеры, в отличие от классического ПК, не имеют жесткого диска с установленной операционной системой и запускаются непосредственно из сети. Передачи нескольких сотен мегабайт уже достаточно для старта операционной системы и регистрации пользователя в ней. Например, окно регистрации в системе Windows 10 появляется после загрузки 250 MB.
Ключевым элементом инфраструктуры PVS является Provisioning Server. Сервер PVS не только отвечает за управление средой PVS, но и является центральной точкой потоковой передачи vDisk-ов. Все настройки конфигурации хранятся в базе данных MS SQL. По сравнению с MCS, PVS не является частью XenApp / XenDesktop.
Для достижения высокой доступности требуется как минимум два сервера PVS. Серверы PVS используют протокол IPC для связи друг с другом.
Следующие шаги описывают принцип работы PVS:
- PVS Streaming Service предоставляет файл (PXE-Bootstrap File: ARDBP32.BIN) для начальной загрузки. PXE-Bootstrap File содержит инструкции для запроса виртуального диска.
- На основании MAC-адреса проверяется, имеет ли целевая система запись в базе данных PVS.
- vDisk передается по сети целевой системе. Передача данных осуществляется по UDP протоколу.
Master Image - vDisk
Для создания vDisk-а необходимо на операционной системе (серверной или настольной) установить PVS Target Device. Задача PVS Target Device сконвертировать диск операционной системы в vhd-файл (с версии 7.7 у вас есть выбор между VHD и VHDX) и сохранить его в соответствующей папке (PVS Store). Для конвертации используется XenConvert Tool.
В папке PVS Store сохраняются файлы следующих типов:
- .vhdx (vhd) – диск операционной системы
- .lok – файл блокировки доступа, активен если vDisk используется
- .pvp – конфигурационный файл vDisk
- .avhd - (z.B. .1.avhdx) – файл с последними сохранёнными изменениями (Differencing Disk)
Методы загрузки
Существует три различных способа загрузки целевых систем в среде PVS: DHCP, PXE и BDM:
1. DHCP Метод
DHCP является наиболее широко используемым и пожалуй самым популярным методом. Клиент получает IP-адрес от DHCP-сервера, который включает в себя следующие параметры:- Option 66 – здесь указывается IP-адрес PVS сервера - Option 67 – имя файла загрузки (ARDBP32.bin)
2. PXE Метод
Клиент получает только IP-адрес с сервера DCHP, так как на DHCP-сервере не настроены опции 66 и 67. PVS сервер сам реагирует на запрос клиента и отвечает ему передавая параметры опций 66 / 67. Данный метод крайне редок и не всегда возможен, ввиду определённой зависимости от конфигурации сети.
3. BDM (Boot Device Manager)
В этом случае целевая система запускается непосредственно с физического загрузочного носителя (CD). Этот метод бывает единственно возможным для использования PVS, так как опции 66 / 67 уже используются другими системами (например, SCCM или Matrix42).
Пошаговое описание процесса загрузки
1. Получение IP адреса - целевое устройство получает IP-адрес от DHCP сервера. Вместе с IP-адресом передаются также адрес TFTP-сервера (Option 66) и название файла загрузки (Option 67).
2. Загрузка Bootstrap файла - загрузочный файл (ARDBP32.bin) скачивается с TFTP-сервера на целевое устройство.
3. Процесс входа в систему PVS - после того, как целевое устройство получило IP-адрес и скачало загрузочный файл, оно регистрируется на PVS-сервере, чтобы начать стриминг vDisk-а.
4. Single Read Mode – целевое устройство начинает отправлять запросы на PVS-сервер в так называемом режиме одиночного чтения и делать это до тех пор, пока операционная система не начнет загружать драйверы, и не загрузит BNISTACK-драйвер.
5. BNISTACK / MIO Read Mode – заключительная фаза загрузки системы. BNISTACK загружается в память и продолжает управлять коммуникацией между сервером и целевым устройством. BNISTACK использует параллельно несколько потоков для связи с сервером PVS. Multiple Input/Output - один канал используется для запроса и множество для получения ответа от сервера PVS.
PVS Store
Store – это место физического хранения для vDisk-ов. Данная папка может находиться как на любом из PVS-серверов, так и на общем хранилище (Shared Storage). Важно позаботиться о достаточном количестве места на диске и быстром доступе к нему (IOPS performance).
Использование совместного хранилища (Shared Storage) не требует дополнительных механизмов для синхронизации vDisks-ов.
Сервера PVS не имеют встроенных механизмов для репликации vDisk-ов между собой. Для этого чаще всего используется простой и удобный метод, - скрипт на основе команды robocopy. Использование распределенной файловой системы (DFS) также возможно.
Write Cache
В стандартном режиме (Standard Mode) vDisk доступен только для чтения (read only), и все данные, которые обычно записываются на системный диск виртуальной машины, переносятся в Write Cache. Существует несколько различных режимов настроек Write Cache.
Write Cache - это временная память, содержащая данные, созданные операционной системой во время работы, а также информация, которую следует сохранить после перезагрузки (например, журналы событий, сигнатуры вирусов, кэш App-V). Write Cache Disk также является типичным местом для хранения Pagefile-файла.
Write-Cache файл (vdiskdiff.vhdx) постоянно растет в течении работы системы и обнуляется только после перезагрузки. vdiskdiff фактически и является следующими опциями “Cache on Target Device Hard Drive” и „Cache in device RAM withoverflow on hard disk“
Текущая версия PVS предлагает шесть различных опций для хранения Write-Cache. У каждого варианта есть свои плюсы и минусы. Рекомендуется использовать „Cache in device RAM with overflow on hard disk“
Возможные варианты размещения Write Cache
Кэш на жестком диске целевого устройства (Cache on device hard disk)
В данном случае Write Cache расположен на жестком диски целевого устройства. До недавнего времени данный вариант был самым предпочтительным решением.
Постоянный к эш на жестком диске целевого устройства и сервера (Cache on device hard disk persisted / Cache on server, persistent )
Как следует из названия, речь идет о постоянном, не сбрасываемом после перезагрузки файла кэша.
Write Cache в рабочей памяти целевого устройства (Cache in device RAM)
Если вы хотите получить максимально возможную производительность, то этот вариант будет наиболее предпочтителен, но крайне дорогостоящим.
Write Cache на жестком диске PVS сервера (Cache on server)
Данный способ наиболее неэффективный из всех перечисленных. Write Cache расположен на PVS-сервере, доступ к которому осуществляется по сети.
Write Cache в рабочей памяти целевого устройства с переполнением на жесткий диск (Cache in device RAM with overflow on hard disk)
Данная опция представляет собой идеальный баланс между производительностью и стоимостью. Опция имеет два уровня. Вначале все изменения хранятся в памяти виртуальной машины. Размер памяти, вернее его максимальное значение для каждого виртуального диска настраивается в конфигурации. Не забывайте о том, что выделенная память будет взята из общей памяти виртуальной машины. Когда выделенная память будет заполнена, наименее востребованные данные, будут перемещены из области ОЗУ в файл (vdiskdif.vhdx) на жестокий диск виртуальной машины. В настоящее время данная опция является рекомендованной производителем.
Режим доступа к vDisk
Private Mode - в этом случае vDisk находится в состоянии записи и соединен только с одной виртуальной машиной.
Standard Mode - vDisk доступен только для чтения и используется многими виртуальными машинами одновременно.
Иными словами, в Private Mode диск всегда имеет отношение 1:1, в стандартном режиме всегда соотношение 1:n.
Обновление vDisk-а
Как вы можете видеть на приведенных ниже рисунках, целевое устройство может быть загружено с разных версий диска. Differencing Disk (.avhdx) – это всегда зависимый от предыдущей версии снимок файловой системы, по функциональности сравнимый со снапшотом. Все .avhdx-файлы последовательно нумеруются. Differencing Disk используется для установки программного обеспечения, обновлений или исправлений.
Существует три различных метода доступа: обслуживание (Maintenance), тестирование и рабочий (Produktion)
Maintenance - является доступной для записи версией, которая может использоваться только одной виртуальной машиной, чаще всего специально созданной для этих целей.
Test - это версия, предназначенная только для чтения, используемая для тестирования.
Produktion – рабочая версия, из которой загружены все виртуальные машины каталога
Дополнительная полезная информация
Подробные диаграммы и описание процесса загрузки (постер): Citrix Provisioning Services Boot Process
Best Practices for Configuring Provisioning Services Server on a Network (CTX117374) - Прочитать
Guidance on PVS Ports and Threads - Прочитать
Understanding Write Cache in Provisioning Services Server (CTX119469) - Прочитать
Size Matters: PVS RAM Cache Overflow Sizing - Прочитать
Всегда рад Вашим отзывам, комментариям и конструктивной критике
Говоря про космические корабли, бороздящие просторы Большого Театра цифровую трансформацию компаний, никто не даёт пояснений, какие конкретные шаги нужно сделать, чтобы прийти в эту самую цифровую эпоху. В этом цикле статей мы не станем говорить про все и сразу, а расскажем про одно из направлений — цифровизацию рабочего пространства (digital workspace). Опишем, как его понимает каждый из ведущих производителей области, и что со всем этим делать ИТ-специалистам.
Читайте также: