В рамках методологии Citrix Consulting выделяется 5 этапов развертывания и подержки решения VDI.

1. Определение потребностей (Define). Формулирование и изучение бизнес-кейса. Составление роадмапа внедрения высокого уровня (с низкой детализацией).
2. Оценка (Assess). Выработка требований к решению VDI. Оценка задач и приоретизация усилий. Оценка текущей инфраструктуры для определения круга задач внедрения и выявления потенциальных проблем.
3. Разработка решения (Design). Определение архитектуры будущего решения, удовлетворяющее задачам бизнеса и требованиям, выработанным на этапе оценки. Также, на этом этапе прорабатываются требования к масштабируемости и отказоустойчивости.
4. Развертывание (Deploy). Фаза развертывания включает в себя реализацию решений и требований, сформулированных на этапах оценки и разработки. Компоненты инфраструктуры должны быть обособлены. Перед запуском в эксплуатацию должно быть проведено тестирование отказоустойчивости.
5. Контроль (Monitor). Формирование регламента и процедур обслуживания системы.

Процесс оценки включает в себя:

Лучший сбособ сбора сведений - опросники.
Примеры задач и требований:

Со стороны менеджеров от бизнеса:

• Agilty. Более высокая гибкость инфраструктуры IT. Способность подстроиться под быстро появляющиеся задачи. Например - открытие новых офисов организации.
• BYOD. Использоваие сотрудниками тех устройств, которые в данный момент наиболее эффективны. В том числе и их собственных.
• Эффективная совместная работа сотрудников из разных географических локаций.
• Возможность работать откуда угодно.

Со стороны принимающих решения IT-менеджеров:

• Высокая управляемость инфраструктуры рабочих столов.
• Высокая безопасность. Защита данных от потери.
• Расширение жизненного цикла оборудования (настольные компьютеры).
• Уменьшение круга рутинных задач IT-подразделения за счет использования облачных вычислительных ресурсов.
• Увеличение производительности рабочих мест пользователей и возможность использования ранее недоступных технологий.

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

Среди потребностей пользователей выделяют:

Возможные уровни персонализации - никакая (пользователь не имеет прав менять настройки), базовая (можно менять параметры рабочего стола) и полная персонализация (любые настройки, в том числе установка ПО).

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

Локальный пользователь - Всегда работает за локальным рабочим местом.
Перемещающийся локальный пользователь - Работает за разными рабочими местами в пределах высокоскоростной локальной сети.
Удаленный пользователь - Иногда подключается с помощью незащищенных каналов с различной скоростью.
Мобильный - Нуждается в доступе к приложениям в условиях отсутствия подключения.

Эта метрика определяет необходимость резервирования элементов инфраструктуры VDI и балансировки нагрузки. Низкая критичность - В случае неработосопсобности VDI риск для бизнес-процессов отсуствует.
Средняя критичность- В случае неработосопсобности VDI существует потенциальный риск для бизнес-процессов.
Высокая критичность- В случае неработосопсобности VDI бизнес-процессы останавливаются либо подвургаются существенным рискам.

Тип и число приложений, влияющих на плотность сессий и выбор типа VDI.
Легкая нагрузка - 1-2 офисных приложения или информационный киоск.
Средняя нагрузка - 2-10 приложений с небольши количеством мультимедиа.
Высокая нагрузка - Тяжелые мультимедийные приложения.

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

Различные типы нагрузки скорее всего потребуют применения различных типов VDI. Применение единой модели VDI для разных типов нагрузки в рамках крупного внедрения скорее всего не приведет к хорошим результатам.
Citrix предлагает полный спектр технологических решений VDI,которые объединяются в интегрированное решение:

• Опубликованные приложения (Hosted Apps). Среди них можно выделить:
  • Windows-приложения, развернутые на Windows Server. В этом случае много пользователей могут работать на одном сервере (физическом или виртуальном).
  • Windows-приложения, развернутые на виртуальных машинах с десктопной версией Windows. В этом случае каждый пользователь получает доступ к приложению, работающему на выделенной виртуальной (или физической) машине.
  • Linux-приложения, развернутые на сервере Linux. В этом случае много пользователей могут работать на одном сервере (физическом или виртуальном).
  • Приложения с Web-интерфейсом. Приложение, развернутое на Windows-сервере доставляется во вкладку локального браузера (IE, Chrome или Firefox).
• Опубликованный рабочий стол (Shared desktop). Рабочий стол опубликованный на серверной ОС (Windows или Linux).
• Пул рабочих столов (Pooled Desktop). Пользователю предоствляется динамичейский доступ к случайной неизменяемой виртуальной машине из определенного пула машин. Возможная плотность размещения несколько уступает Shared Desktop.
• Персональный рабочий стол (Personal Desktop) - Пользователь получает доступ к статически выделенной машине, которая сохраняет произведенные им изменения. Возможная плотность размещения несколько уступает Shared Desktop.
• Рабочий стол с поддержкой GPU (Pro Graphics Desktop) - виртуальная машина для работы с 3D-графикой.
• Образ ОС, загружаемый по сети (Local Streamed Desktop)- Централизованно поддерживаемый образ машины загружается по сети и работает на локальной машине пользователя.
• Локальная виртуальная машина (Local VM Desktop) - Централизованно распространяемый локально исполняемый образ виртуальной машины, способный работать без доступа к сети предприятия.
• Удаленный доступ к рабочему месту - удаленный доступ к физической машине.

• В большинстве случаев следует рассматривать один из трех вариантов: Опубликованные приложения (Hosted Apps), развернутые на Windows Server, Пул рабочих столов (Pooled Desktop) или Опубликованный рабочий стол (Shared desktop). Варианты Local Streamed Desktop и Local VM Desktop следует рассматривать в исключительных случаях.
• Возможно, для какой-то группы пользователей требования будут противоречивы и не удастся однозначно определиться с вариантом модели VDI.
• Критичность неработоспособности рабочего места - только три модели VDI имеют резервирование и допускают быстрое восстановление работоспособности - Hosted Apps, Pooled Desktop и Shared desktop.
• При выборе модели VDI в каждом случае следует учитывать сложность обслуживания. Например - в случае исползования Pooled Desktop виртуальную машину достаточно просто перезагрузить, чтобы она вернулась в нормальное (первоначальное) состояние, что может может не сработаь в случае с Personal Desktop.

Оценка количества и качества приложений включает два этапа:

• Инвентаризация текущего набора приложений и оптимизация этого списка.
• Привязка приложений к группам пользователей.

При инвентаризации важно учитывать:

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

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

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

• Приложение может быть установлено непосредственно в образ.
• Приложение может быть упакованно в контейнер Microsoft App-V.
• Приложение может быть выделено в собственный слой - Citrix App Layering.
• Приложение может работать на локальной машине пользователя и бесшовно интегрироваться в виртуальный рабочий стол - Citrix Local App Access.

Для каждого приложения следует определить характеристику, которая поможет выбрать способ доставки:

• Сложные приложения - приложения сложные в техническом отношении, требующие увязывания многих компонент в единый комплекс. Как правило успешно доставляются как Hosted Apps.
• Приложения требовательные к ресурсам - следует корректно опредлелять требования приложений к ресурсам для их своевременного выделения. Например требовательные приложения не следует публиковать в pooled/personal desktop средах, поскольку в этом случае невозможно адекватно контролировать выделение необходимых ресурсов.
• Мобильные приложения - некоторые приложения должны исполняться в условиях отсутствия доступа к сети и доствляться с помощью Microsoft App-V.
• Приложения работающие с периферией - приложения, работающие с периферией должны иметь доступ к локально установленным устройствам из виртуальной среды. Часто реализовать такой сценарий удается с помощью бесшовной интеграции приложения в виртуальный рабочий стол - Citrix Local App Access.
• Приложения, использовапние которых ограничено - например, приложения с ограниченным числом лицензий не следует устанавливать в образ polled desktop.

Напишу как-нибудь потом. Когда сделаюсь архитектором :)

В качестве стандарта разработки рекомендуется использовать пятиуровневую модель: Три верхних уровня - разрабатываются индивидуально для каждой группы пользователей в соответсвтии с критериями, определенными на этапе оценки (assess). Эти уровни опеределяют ресурсы, доступные пользователям, и способ доступа к ним.
Два нижних уровня - управление и аппаратный уровень разрабатываются для всего внедрения вцелом.

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

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

• On premises. Вычислительные ресурсы размещены на площадке заказчика (on premises). IT-команда заказчика полностью обеспечивает работоспособность решения.

• Public Cloud. Вычислительные ресурсы размещены (арендованы) в публичном облаке (IaaS). IT-команда заказчика не отвечает за аппаратные средства.

• Hybrid Cloud. Вычислительные ресурсы размещены как на площадке заказчика (on premises), так и в публичном облаке (IaaS).

• Citrix Cloud. В этом случае управляющие элементы инфраструктуры XenApp и XenDesktop работают в Облаке Citrx (Citrix Cloud), а слой ресурсов доступных пользователю (resource layer) управляется IT-командой заказчика. Citrix берет на себя обслуживание аппаратных средств, масштабирование и поддержание в актуальном состоянии управляющих элементов инфраструктуры.

В рамках архитектуры XenApp и XenDesktop сайтом (site) называется группа рабочих столов и приложений, управляемых как единая сущность. Вся информация о текущей конфигурации, выделенных ресурсах и подключениях хранится в базе данных сайта.
Компоненты сайта XenDesktop могут быть физически размещены в одном или нескольких локациях. Нагрузочное тестирование показывает, что один сайт способен одновременно обслуживать более 40 000 сессий.
Сайт может быть разделен на зоны в соотвествии с географическим принципом разделения ресурсов. При планировании топологии сайта учитываются несколько факторов:

• Отказоустойчивость (Risk Tolerance). Создание нескольких сайтов позволит минимизировать влияние отказов на бизнес-процессы. Например - повреждение базы данных одного сайта не повлияет на другие сайты.
• Безопасность (Security). В некоторых случаях регулирующие органы могут предъявлять требования, которые подразумевают физическое разделение вычислительных ресурсов, обрабатывающих критичные и некритичные данные. Например - разделение складского и финансового учета.
• Административные границы (Administrative Boundaries). В пределах компании IT-ресурсы могут быть разделены административно и управляться различными IT-командами.
• Географическая связанность (Geographical Connectivity). В общем случае - реализация зон не подразумевает распределения инфраструктуры сайта по нескольким географическим локациям (потому что база все равно одна), однако если между локациями (основной и дополнительными зонами) существует достаточно производительный и стабильный канал связи, то реализация зон может быть оправдана. Большой размер зоны и высокие задержки в канале связи отражаются на времени отклика для пользователя.

Производительность зон Citrix Xendesktop

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

В общем случае - администраторам следует минимизировать количество сайтов и зон для упрощения структуры.

При развертывании XenApp или XenDesktop, как правило, создаются мастер-образы (master images). Важно зараее определиться со стратегией управления мастер-образами. Возможные варианты:

• Установленный образ (Installed Image). В таком варианте администратор устанавливает ОС и прикладное ПО при создании каждого мастер-образа. Это самый простой вариант, однако в этом случае при создании и обновлении каждого мастер-образа администратор вынужден повторять одни и те же действия, что может быть очень затратно по времени.
• Мастер-образ формируемый скриптом (Scripted Image). Образ формируемый скриптом (настройки и установка ПО).
• Многослойный образ (Layered Image). В этом варианте - ОС и прикладное ПО рассматриваются в качестве элементов многослойной структуры. В этом случае любой элемент (слой) доступен любому мастер-образу и может быть добавлен при необходимости.

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

В качестве пользовательского устройтсва могут выступать:

• Планшет
• Ноутбук
• Настольный ПК
• Тонкий клиент
• Смартфон

В любом случае - пользовательское устройство должно удовлетворять требованиям.

Обычно - пользовательские устройства принадлежат и управляются компанией. Альтенативный подход - BYOD, когда пользователь подключается к корпоративным ресурсам с помощью личного устройства. Критерии допустимости BYOD зависят от сценария использования:

• Безопасность. В случае обработки критичных данных личные устройства недопустимы.
• Мобильность. Если пользовательработает без доступа к сети, то при использовании личного устройства, скорее всего, ему будет недоступен сценарий local VM desktop, предъявляющий определенные требования к аппаратным возможностям устройства.
• Критичность отказа. Если отказ критичен, то должно быть предусмотрено резервирование пользовательского устройства, что может быть непросто в случае BYOD.
• Модель VDI - При использовании local VDI (streamed desktop или local VM desktop) предъявляются определенные требования к аппаратным возможностям устройства.

Современные устройства могут с успехом выходить за рамки типичного трехгодичного жизненного цикла и использоваться гораздо дольше в качестве конечных устройств при доступе к ресурсам VDI. Конечные устроства должны соотвествовать нескольким критериям:

• Минимальные требования. В общем случае для нормальной работы достаточно конфигурации - 1GHz, 1Gb RAM, 16Gb HDD.
• Корпоративные цели. Если приоритет - сокращение затрат, то расширение жизненного цикла оборудования - благо, но если приоритет - удобство и сокращение энергопотребления, то нет.
• Сценарий использования. Если предполагается активно использовать локально исполняющиеся приложения, то оборудование должно соответствовать задачам.

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

• Удаленно уничтожать информацию на потеряных или украденых устройствах.
• Соблюдать регламент паролей.
• Устанавливать ограничения в соответствии с географическим положением устройств.
• Упрощать конфигурацию Exchange ActiveSync.
• Настраивать конфигурацию Wi-Fi.
• Распространять сертификаты безопасности.

Также важно разграничивать уровни безопасности в зависимости от различных условий:

• Доступ к опубликованным ресурсам со “взломанных” устройств (rooted Android OS или jailbroken iOS).
• Копирование/Вставка данных между опубликованными и локальными приложениями.
• Доступ к опубликованным ресурсам с устройств незащищенных паролем.
• Доступ к корпоративной почте небезопасными почтовыми клиентами.
• Доступ к корпоративным сайтам с помощьюб мобильных браузеров или с помощью опубликованного настольного браузера.

Citrix предлагает решение для унификации управления пользовательскими устройствами Unified Endpoint Management (UEM) для приложений или Mobile Device Management (MDM) для корпоративных мобильных устройств или Mobile Application Management (MAM) для личных мобильных устройств - Citrix XenMobile.

V - рекомендовано, X - не рекомендуется, o - допустимо.


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

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

Как правило - лучшим вариантом является установка полной версии Citrix Receiver, совместимой с клиентским устройством. Для случаев, когда установка невозможна существует версия HTML5 Receiver (раньше его место занимал Java-клиент). HTML5 Receiver не рекомендуется для масштабных внедрений из-за ограниченной функциональности и ограничений в современных браузерах. Для распространения Citrix Receiver могут использоваться следующие механизмы:

• Store Front. При наличии Store Front можно включить опцию “Client Detection”, которая сможет автоматически определять наличие климента и при необходимости предлагать установку Citrix Receiver for Web. Этот функционал совместим не со всеми браузерами и зависит от настроек ActiveX.
• Корпоративный сайт. Дистрибутив Citrix Receiver может быть размещен для скачивания и установки на локальном корпоративном сайте.
• Магазины приложений различных ОС (Windows, Android, iOS и т.д).
• Корпоративные системы распространения ПО - Enterprise software deployment deployment (ESD) или Mobile Application Management (MAM) для корпоративных мобильных устройств.
• Citrix Receiver может быть встроен в предустанавливаемый корпоративный образ ОС.
• Групповые политики AD. В ситуациях, коргда отсутствуют специализированные Корпоративные системы распространения ПО можно использовать функционал Групповых политик AD. Простые скрипты для установки доступны в каждом *.iso образе XenApp или XenDesktop - X:\Citrix Receiver and Plugins\Windows\Receiver\Startup_Logon_Scripts
• Установка вручную. Просто скачать с сайта http://receiver.citrix.com/ и установить.

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

• Получение настроек при введении адреса e-mail. ( Email based discovery). Для того, чтобы этот способ работал необходимо настроить StoreFront и соотвествующую SRV-запись на DNS-сервере - Configuring Email-Based Account Discovery for Citrix Receiver.
• Групповая политика AD. В центральное хранилище шаблонов групповых политик ADMX/ADML импортируется шаблон, входящий в состав Citrix Receiver, и настраивается политика. Способ применим при доступе к ресурсам из корпоративной сети.
• Настройки распространяются с помощью StoreFront (Provisioning File). В случаях, когда развернут StoreFront, пользователю можно предоставлять конфигурационный файл *.cr, который можно просто открыть на пользовательском устройстве с помощью Citrix Receiver. Файл доступен по сслыке Activate в Web Interface.
• Конфигурирование вручную - при запуске Citrix Receiver вводится адрес сервера StoreFront или Web Interface.
• Citrix Studio. Citrix Receiver, установленный на виртуальных машинах, доступ к которым предоставляется через Citrix XenDesktop, можно сконфигурировать в свойствах Delivery Group.

Обновления Citrix Receiver могут выполнятьтяр тремя способами:

• Автоматически (начиная с версии 4.8).
• В помощью корпоративной системы распространения ПО. (Enterprise software deployment deployment (ESD)).
• Вручную.

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

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

Обычно, для доступа к ресурсам пользователь предоставляет свои учетные данные Active Directory (логин и пароль). В большинстве случаев - инфраструктура AD уже существует на предприятии и этот этап внедрения сложностей не предстваляет.
Также, могут встречаться более экзотичные варианты - аутентификация пользователей с помощью внешний провайдеров - Azure Active Directory, Google, LinkedIn и других. Внешние провайдеры аутентификации поддерживаются с помощью компонента Citrix Federated Authentication.

В XenDesktop пользователь может аутентифицироваться в двух точках:

• Citrix StoreFront (ранее - Web Interface) - явялется веб-интерфейсом для доступа к ресурсам и применяется внутри корпоративной сети.
• NetScaler Gateway - инструмент для безопасного доступа к ресурсам из незащищенных сегментов сети Internet. Реализует различные политики безопасности при доступе к ресурсам и позволяет проверять состояние канала связи и клиентского устройства перед предоставлением доступа.

Желательно, чтобы аутентификация удаленных клиентов всегда проходила на Netscaler Gateway, однако в некоторых случаях, аутентификация удаленных клиентов может происходить и на StoreFront. Например - если политики безопасности исключают подключение Netscaler Gateway к Active Directory, то на Netscaler может реализован виртуальный сервер, предоставляющий доступ к корпоративному StoreFront (NetScaler SSL_BRIDGE).

После выбора точки аутентификации следует выбрать способ аутентификации.
StoreFront поддерживает следующие типы:

• Имя и пароль.
• Сквозная доменная аутентификация (Domain pass-through). Пользователь логинится на своё устойство, и далее его учетные данные прозрачно используются для аутентификации на StoreFront.
• Сквозная аутентифиакция на Netscaler Gateway (NetScaler Gateway pass-through). Пользователь вводит логин и пароль на NetScaler Gateway и далее его учетные данные прозрачно используются для аутентификации на StoreFront.
• Смарт-карты. Пользователь может аутентифициоваться с помощью смарт-карты на Citrix Receiver или Netscaler Gateway. Для использования этого типа аутентификации учетные записи пользователей должны быть сконфигурированы в домене AD в котором находится сервер Storefront, либо в домене, который имеет двусторонние доверительные отношения (two-way trust)с доменом, в котором находится сервер Storefront. Конфигурации с односторонними доверительными отношениями не поддерживаются.
• Анонимный доступ. При анонимном доступе от пользователей не требуется предоставлять учетные данные, а временные локальные учетные записи автоматически создаются в момент подключения на сервере, к которому происходит подключение.

NetScaler Gateway поддерживает несколько методов аутентификации:

• LDAP - используется для аутентификации в Active Directory и других подобных службах каталога, поддерживающих протокол LDAP.
• RADIUS (token) - протокол, работающий на базе UDP и обеспечивающий аутентификацию, авторизацию и учет пользователей. Шлюз Citrix (Netscaler gateway или старый Web Interface), к которому подключается пользователь, направляет учетные данные серверу RADIUS, который проверяет их локально или в службе каталога (AD).
• Клиентские сертификаты - при подключении к Netscaler gateway производится проверка аттрибутов сертификата клиента. Обычно клиентские сертификаты выпускаются в виде смарт-карт (или других аппаратных устройств) и считываются специальным считывателем.

Citrix StoreFront аутентифицирует пользователей для доступа к ресурсам XenApp и XenDesktop. StoreFront предоставляет пользователю единый интерфейс для доступа к ресурсам XenApp и XenDesktop.

При недоступности сервера Citrix Storefront пользователи не смогут получить доступ к ресурсам. Следовательно, для исключения этой точки отказа необходимо разворачивать не менее двух серверов Storefront, а также балансировку нагрузки между ними. Тут доступны следующие варианты:

• Аппаратные средства балансировки. Citrix Netscaler способен отслеживать состояние балансируемых серверов Storefront и распределять нагрузку между работоспособными серверами. Рекомендовано к применению.
• Балансировака на уровне DNS. Простейший вариант балансировки. В этом случае никакой проверки работоспособности серверов Storefront не производится и в случае выхода севрера из строя к нему все равно будут производиться попытки подключения. Не рекомендуется к применению.
• Балансировка на уровне сетевых интерфейсов средствами Windows. Сетевые средства балансировки Windows позволяют производить простейшую проверку доступности сервера, но не могут оценить работоспособность сервисов Storefront. Не рекомендуется к применению.

Citrix Storefront получает список доступных пользователю ресурсов от контроллеров доставки - Desktop Delivery Controler (DDC). Для обеспечения отказоустойчивости необходимо разворачивать несколько DDC и возможны два варианта балансировки XML-сервисов, предоставляемых DDC: средствами Citrix NetScaler в режиме active/active, либо - встроенные в Storefront средства обеспечения отказоустойчивости DDC, которые могут работать как в режиме active/passive, так и в режиме active/active.

Пользователь может подключаться из внутренней (локальной) сети непосредственно к Storefront или из внешней сети через Netscaler Gateway и в зависимости от этого, ему может быть предоставлен различный набор ресурсов. При первичном подключении Citrix Receiver получает список доступных точек подключения (beacons) в который входят имена внутреннего сайта Storefront и внешних Citrix Netscaler Gateway.
Во время работы Citrix Receiver постоянно отслеживает состояние сетевого подключения и при его изменении (отключение, подключение, изменение дефолтного шлюза) сначала проверяет доступность локальной точки подключения Storefront и если она недоступна - перебирает доступные адреса внешних точек подключения Citrix Netscaler Gateway. Для обеспечения отказоустойчивости необходимо, чтобы было сконфигурировано как минимум две точки подключения из внешних сетей Citrix Netscaler Gateway.

По-умолчанию пользователь выбирает (self-service) из списка ресурсов те, которыми он планирует пользоваться и они помещаются в главное окно Citrix Receiver. Список ресурсов, выбранных пользователем хранится на группе серверов Storefront для того, чтобы, независимо от того с какого устройства пользователь производит подключение, список его “избранных” приложений сохранялся. Также списки избранных ресурсов могут сихронизироваться между двумя магазинами (store) в пределах одной серверной группы или между двумя магазинами с одинаковыми именами находящимися в разных серверных группах.
Администратор может задать какие приложения должны всегда отображаться в окне Citrix Receiver. Представление приложения по-умолчанию задается с помощью ключесого слова в строчке Description в свойствах приложения.

Если в инфраструктуре Citrix есть несколько ферм, то Storefront объединит все доступные пользователю ресурсы в единый интерфейс. Однако, если на разных фермах есть приложения с одинаковыми названиями - это может привести пользователя в замешательство. Группировка ресурсов(Storefront Aggregation Groups) позволяет объединить приложения нескольких ферм в единый интерфейс для лучшего восприятия, напрмиер - исключив дублирование ярлыков одинаковых приложений. При включении группировки ресурсов на Storefront необходимо задать способ распределения пользователей между фермами:

• Балансировка нагрузки (Load Balancing) - Если большие фермы соотвествуют рекомендациям по количеству пользователей и предоставляют одинаковые ресурсы. В этом случае Storefront равномерно распределяет нагрузку по доступным фермам.
• Обработка отказа (Failover) - при недоступности основной (локальной) фермы пользователям предоставляются ресурсы резервной (удаленной).

Число пользователей, которое может обработать один сервер Storefront зависит от аппаратных ресурсов сервера. При большом количестве пользователей Web-интерфейса возрастает потребление опреативной памяти (RAM). Минимальное рекомендованное количество памяти - 4Gb. тестироание покащзывает,что эффективность масштабирования заметно падает при увеличении числа Storefront до 3-4, а максимальное рекомендуемое число серверов в группе - 5-6.

https://docs.citrix.com/en-us/netscaler.html
При разработке решения, включающего NetScaler Gateway следует учитывать несколько особенностей, не возникающих при аутентификации на Storefront:

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

• 1-Arm. Нормальный уровень безопасности. В этом случае NetScaler Gateway использует единственный сетевой интерфейс (один VLAN и одна IP-подсеть) как для внешнего, так и для внутреннего траффика.

• 2-Arm. Высокий уровень безопасности. В этом случае NetScaler Gateway использует два или более сетевых интерфейса и соответвующие VLANы и IP-подсети для внутреннего и внешнего траффика. Таким образом удается полностью изолировать внутренние ресурсы сети и обеспечить полный контроль над траффиком.

При недоступности NetScaler Gateway удаленные пользователи не смогут получить доступ к опубликованным ресурсам. Для отказоустойчивости необходимо иметь как минимум два хоста NetScaler Gateway.
Два хоста NetScaler Gateway могут работать в режиме кластера active/passive. В таком режиме один основной хост принимает подключения (active), а второй резервный хост (passive) следит за состоянием основного хоста с помощью heartbeat-сообщений. Если основной хост не отвечает на heartbeat-сообщение, то резервный хост повторяет проверку через заданный интервал а, в случае неудачи, фиксирует отказ основного хоста и сам становится основным и принимает подключения.
Версии NetScaler Gateway 10.5 и более новые поддерживают кластер из большего числа хостов. В зависимости от версии Netscaler Gateway поддерживаются кластеризации в вариантах Spotted и Stripped.
В варианте Spotted IP-адрес назначен единственной ноде в каждый момент времени и используется в кластерах active/passive, а в варианте Stripped IP-адрес назначается одновременно нескольким нодам и используется для балансировки нагрузки.
http://docs.citrix.com/en-us/netscaler/11-1/clustering/cluster-features-supported.html

Для правильного выбора платформы NetScaler Gateway нужно правильно оценить предполагаемую нагрузку. Для оценки требуемой производительности используются две метрики:

• Пропускная способность SSL (SSL throughput ). С какой скорость NetScaler Gateway может генерировать SSL-траффик.
• Количество SSL-транзакций в секунду (SSL transactions per second (TPS)). Эта величина сильно зависит от длинны ключа шифрования. Метрика существенно ограничивает число SSL-сессий, которые могут быть одновременно инициированы и не существенно влияет на число одновременно поддерживаемых сессий.

Таким образом, требуемая пропускная способность SSL является основной метрикой, применяемой при выборе платформы Citrix Netscaler.
Использование протокола SSL немного (примерно на 2%) увеличивает количество передаваемых данных. Таким образом, максимальная требуемая пропускная способность SSL будет равна максимальной загрузке внешнего канала фермы + 2%.
Используются три основных платформы NetScaler Gateway:

• VPX - виртуальная машина NetScaler Gateway, которая функционально полностью идентична аппаратным решениям, но может работать на стандартных серверах. Подходит для обслуживания внедрений до 500 пользователей.
• MPX - аппаратное решение NetScaler Gateway, в котором применено аппаратное ускорение обработки SSL-траффика.
• SDX - платформа для виртуализации NetScaler Gateway, котрая позволяет в запустить несколько VPX с аппаратной поддержкой шифрования SSL и большой пропускной способностью. Предназначено для крупных внедрений, нуждающихся в большом числе NetScaler Gateway.

Конкретные характеристики различных платформ можно найти тут: https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/netscaler-data-sheet.pdf.
Следует учесть, что реальная пропускная способность SSL может существенно отличаться от заявленной, поскольку зависит от требований безопасности - длинны ключей шифрования и используемых алгоритмов. В даташитах указывается максимальная пропускная способность SSL, достижимая в идеальных с точки зрения производительности условиях. Например - при использовании шифрования по алгоритму RC4 с ключем длинной 1024 бит, платформа VPX может обеспечить работу более 500 подключений с использованием HDX. Однако, если использовать алогритм 3DES и ключ длинной 2048 бит, то количество одновременно поддерживаемых подключений упадет вдвое.

Если Netscaler используется для аутентификации пользователей, то к ним могут применяться политики, которые проверяют соответствие пользовательского устройства корпоративным политикам с помощью Endpoint Analysis Scan (EPA Scan) и ограничивают доступ к корпоративной среде при несоответствии устройства политикам.
Политики Endpoint Analysis Scan могу проверять наличие и состояние антивируса, файервола, операционной системы и даже записей реестра. Эти политик могут либо полностью блокировать доступ к ресурсам при несоответствии, либо блокировать заданную функциональность XenDesktop (например - буфер обмена, принтеры а также доступ к приложениям и десктопам и прочие). Например - если у пользователя нет антивируса,то политика может скрыть опеределенные приложения.
Приведенная ниже схема демонстрирует применение политик в зависимости от результатов проверок Endpoint Analysis Scan:

Для того, чтобы пользователи могли аутентифицироваться на Netscaler Gateway необходимо, чтобы для групп пользователей были созданы сеансовые политики (session policy).
Политики сеансов могут применяться в зависимости от версии Citrix Receiver. Для привязки политик сеансов, устройства обычно группируются по принципу мобильности - мобильные (iOS, Android и другие) и немобильные (Windows, Mac и Linux).
Для идентификации типа устройства (и возможностей Citrix Receiver) используются выражения, проверящие заголовки HTTP, предоставляемые клиентским устройством: http://docs.citrix.com/en-us/netscaler-gateway/11-1/storefront-integration/ng-clg-session-policies-overview-con.html
Также, политики сеансов можно использовать для применения политик пользовательских устройств. То есть политики сеансов могут имитировать работу политик пользовательских устойств. Политики сеансов могу использоваться в качестве резервного сценария для пользовательских устройств, которые не удовлетворяют требованиям безопасности (например - предоставление доступа только для чтения для заданных приложений).

К каждой сеансовой политике должен быть привязан сеансовый профиль. Сеансовый профиль опеределяет конкретные критерии, которые должны удовлетворяться для предоставления доступа. Существует два основных вида сеансовых профилей, которые опеределяют способ доступа к опубликованным ресурсам:

• SSLVPN - Пользовательское устройство создает VPN-туннель и траффик перенаправляется во внутреннюю сеть компании. Пользователь получае доступ к корпоративным ресурсам (ресурсам Citrix XenDesktop, файловым ресурсам, сайтам в корпоративной сети и т.д) так же как это происходило бы в корпоративной сети.
  

Данный вариант расматривается как потенциально небезопасный, поскольку пользователь получает прямой доступ к корпоративной сети, минуя виртуальную инфраструктуру. Возможные риски включают в себя атаки на приложения и серверы, возможность распространения вирусов, троянов и другого нежелательного ПО.
Для предотвращения этих рисков существует опция ограничения туннелируемого траффика (split tunneling), которая дает администратору возможность предоставить доступ только к требуемым маршрутам, ресурсам и портам. Включение split tunneling позволяет обеспечить требуемый уровне безопасности, в то же время отключение split tunneling и направление пользовательского траффика во внутреннюю сеть позволяет производить мониторинг содержимого траффика - фильтровать web-ресурсы и использовать системы обнаружения проникновения (intrusion detection systems).

• HDX Proxy - с профилем HDX proxy пользователь подключается только к опубликованным приложениям и рабочим столам Citrix XenDesktop, и пользовательское устройство не имеет сетевого доступа ни к каким другим ресурсам внутренней сети. Доступ к корпоративным ресурсам осуществляется только в рамках сессии Citrix XenDesktop. Решение об использовании этого профиля принимается для каждой группы пользователей, учитывая тип конечного устройства и вариант Citrix Receiver. Этот сеансовый профиль является предпочтительным:

Довольно часто, для обеспечения отказоустойчивости критичные опубликованные приложения могут быть размещены в двух и более датацентрах, но в то же время некритичные приложения могут быть опубликованы только в одном датацентре. Таким образом, в конфигурации с несколькими активными Citrix Netscaler может возникнуть ситуация, когда пользователь аутентифицировался на Netscaler, находящемся в одном датацентре, а приложение опубликовано в другом. В таком случае Citrix Storefront способен определить расположение запрошенного ресурса и направить сессию HDX по назначению. Однако, результирующий путь может быть не оптимальным и доступ опубликованного приложения к данным может осуществляться по медленным WAN-каналам, а не быстрым LAN.
Существуют динамические и статические методы для подключения сессии пользователя к ресурсам в его основном датацентре через Netscaler Gateway. Выбор метода в каждом конкретном случае определяется технологическими возможностями - Global Server Load Balancing (GSLB позволяет динамически изменять ответ на DNS-запросы клиентов, напрявляя их в нужный датацентр), правильной оценкой пропускной способностей каналов связи и возможностями QoS. http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-config-proxmt-con.html

• Прямая привязка пользователей (Direct) - Netscaler Gateway в каждом датацентре имеет собственное DNS-имя и каждый пользователь подключается к ресурсам используя DNS-имя Netscaler Gateway, расположенного в его основном датацентре. Никакого динамического направления пользователей не происходит. Это самый простой метод, однако он не реализует никакой отказоустойчивости.

• Intranet - В большинстве случаев, при реализации динамической балансировки, пользователь подключается к Netscaler Gateway в ближайшем датацентре. Например - при использовании GSLB dynamic proximity - к Netscaler Gateway в датацентре с минимальным временем отклика по сети. После подключения, HDX-сессия пользователя направляется к ресурсам через тот же Netscaler Gateway, не зависимо от того, в каком датацентре расположены ресурсы. В результате данные будут передаваться по корпоративным WAN-каналам, в которых можно использовать QoS.

• Internet - альтернативный вариант - пользователь аутентифицируется в ближайшем Netscaler Gateway, но затем HDX-сессия динамически передается на Netscaler Gateway, который расположен в основном датацентре пользователя (в котором расположены ресурсы к которым подключается пользователь). Такой метод снижает нагрузку на корпоративные WAN-каналы и рекомендуется в случаях, когда надежность корпоративных WAN-каналов сравнима или ниже, чем надежность подключения пользователя к сети Internet.

Возможно использоватнеи сочетания этих методов, например - для определенного географического региона используются динамические URL, таким образом обеспечивается отказоустойчивости в пределах региона, без использования глобального GSLB.

Инфраструктура Citrix XenDesktop и XenApp может быть распределена по нескольким площадкам (sites). Для того, чтобы успешно реализовать многосайтовое решение нужно на этапе проектирования уделить внимание связям между сайтами и маршрутизации сессий.

В многосайтовой конфигурации для правильной маршрутизации сессий учитываются несколько критериев (например - минимальная задержка в сети). Эти алгоритмы не учитывают особенности ресурсов, к которым осуществляется доступ.
Неоптимизированная маршрутизация сессий может приводить к таким результатам: 1. Пользователь авторизуется на ближайшем Citrix Netscaler Gateway с минимальной сетевой задержкой.
2. Citrix Netscaler Gateway проксирует HDX-сессию к ресурсам, находящимся в другом датацентре через корпоративные WAN-каналы.

Оптимизированная маршрутизация выглядит так: 1. Пользователь авторизуется на ближайшем Citrix Netscaler Gateway с минимальной сетевой задержкой.
2. Ближайший Netscaler Gateway перенаправляет сессию в основной (preffered) датацентр пользователя, в котором расположен запрошенный ресурс.
3. Netscaler Gateway основного (preffered) датацентра пользователя проксирует ICA-траффик к ресурсам, расположенным в основном датацентре по локальной сети LAN.
Использование опции оптимизированной маршрутизации HDX в Citrix Storefront позволяет разгрузить корпоративные WAN-каналы связи и перенести этот траффик в публичные каналы.

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

• Экстенсивный (Scale Up) - при нехватке пропускной способности можно просто расширить пропускную способность канала.
• Интенсивный (Scale Out) - Можно увеличить число каналов связи между офисами и датацентром и объединить их в виртуальный канал WAN (virtual WAN). В результате создается программно определяемый виртуальный канал, например - на базе технологии Netscaler SD-WAN (software defined WAN). В таком случае Netscaler одновременно посылает пакеты по всем доступным каналам связи, на другом конце Netscaler реконструирует траффик используя пакеты, пришедшие первыми, а остальные пакеты отбрасываются. В результате удается достичь максимальной производительности каналов связи, которая независит от состояния и загрузки каналов в течение дня.

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

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

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

• Legacy - оптимизированный для Windows 7 и Windows 2008R2 (GDI/GDI+).
• Desktop Composition Redirection - позволяет разгрузить менеджер окон (Windows manager) сервера, направляя на пользовтельское устройство только команды для формирования изображения, а не растровую картинку. Этот протокол поддерживается только VDA для Windows и в Citrix XenDesktop 7.15 LTSR уже считается устаревшим.
• Framehawk - протокол, использующий UDP для передачи данных и обеспечивающий высокую скорость обновления изображения (refresh rate) в условиях нестабильных каналов связи с высокими задержками и высоким уровнем потерь пакетов, компенсируя наличие этих недостатков более высокими требованиями к пропускной способности канала связи. Эти условия характерны для широкополосных и мобильных каналов связи.
• H.264 - Эта аббревиатура часто используется для обозначения видеокодека, которы обеспечивает высокое качечтво картинки при невысоком битрейте. Этот протокол потребляет много процессорного времени сервера и снижает максимальное количество пользователей, работающих на одном физическом сервере, однако именно он рекомендуется для применения в случаях, когда пользователь работает с мультимедийными приложениями.
• ThinWire - протокол основанный на ранних патентах Citrix, который позволяет передавать картинку при минимальной пропускной способности канала связи. Использование этого протокола в большинстве случаев обеспечивает приемлемое качество картинки при минимальных требованиях к ресурсам сервера. Существует две разновидности ThinWire:
  • Legacy - оптимизированный для Windows 7 и Windows 2008R2 (GDI/GDI+).
  • ThinWire+ - оптимизированный для Desktop Windows Manager (DWM), входящего в состав Winodows 8, Windows 10, Windows 2012 и Windows 2016.
• Selective H.264 (Adaptive Display) - использует несколько кодеков (H.264 и ThinWire+) для разных участков экрана. Возможны три опции:
  • Не использовать Adaptive Display - используется только ThinWire+. Лучший вариант для пользователей приложений с преимущественно статичной картинкой.
  • Для всего экрана целиком (For entire screen) - Используется только протокол H.264. Рекомендуется для мультимедийных и 3D приложений, особенно на каналах связи с низкой пропускной способностью.
  • Для активно меняющихся участков экрана (For actively changing regions) - Для обработки активно меняющихся участков используется H.264, а для статичных участков - ThinWire+. Оптимальный вариант для любых приложений.

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

Трафик HDX может передаваться с помощью одного из трех сетевых протоколов транспортного уровня:

• TCP - Протокол является индустриальным стандартом. Применяется в локальных сетях и каналях связи с невысокими задержками. При увеличении дистанции и задержек становится неэффективным из-за высокого числа повторных передач.
• EDT( Enlightened Data Transport) - Проприетарный протокол Citrix, основанный на UDP. Подходит для каналов связи с высоким уровнем потерь и высокими задержками. Обеспечивает приемлемую скорость работы без существенной нагрузки на сервер, при некотором увеличении требований к пропускной способности канала связи.
• Адаптивный протокол (Adaptive Transport) - протокол сочетающий TCP и EDT. Если возможно используется EDT, а если использование EDT невозможно - используется TCP.

В большинстве случаев рекомендуется использовать адаптивный протокол (Adaptive Transport).

При каждом подключении пользователя (если это не переподключение - reconnection) должен завершиться процесс входа (logon process), который включает в себя инициализацию сессии, загрузку профиля пользователя, применение политик, подключение сетевых дисков и принтеров, выполнение логон-скриптов и инициализацию рабочего окружения. Каждый из этих элементов занимет время и удлинняет процесс входа. Citrix Workspace Environment Management позволяет существенно оптимизировать процесс входа и ускорить его. При иcпользовании WEM во время входа не мапятся диски и принтеры, не выпоняются логон-скрипты и не загружается перемещаемый профиль. Все эти действия производятся в многопоточном фоновом режиме после инициализации сессии и рабочего стола. Таким образом, пользователь получает доступ к своему рабочему месту значительно быстрее.
В большинстве случаев оптимизацию входа следует включать по-умолчанию.

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

• Разблокировка учетной записи (Account Unlock). Если пользователь знает ответ на секретный вопрос - он сможет самостоятельно разблокировать свою учетную запись через интерфейс StoreFront/
• Сброс пароля (Password Reset). Если пользователь знает ответ на секретный вопрос - он сможет самостоятельно сбросить забытый пароль.

Архетектура подсистемы самообслуживания пользователей (self-service password reset - SSPR) включает в себя: SSPR Service, Central Store (хранилище ответов на контрольные вопросы) и пару учетных записей:

• Data Proxy Account - учетная запись, используемая для доступа к Central Store, в котором хранятся зашифрованные ответы на контрольные вопросы.
• Self Service Account - учетная запись в AD, которая имеет права на сброс паролей и разблокировку учетных записей пользователей.

Кроме того, сервис SSPR требует составления секретных вопросов. Лучше всего, если будут созданы группы вопросов группы вопросов на разные темы.

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

• Локальный профиль (Local Profile) - локальные профили создаются на базе дефолтногопрофиля и хранятся непосредственно на сервере или виртуальной машине, к которой подключается пользователь. Таким образом, если пользователь подключается к нескольким машинам, то на каждой будет создан локальный профиль. Изменения, произведенные пользователем сохраняются, однако доступны только на машине на которой были произведены.
• Перемещаемый профиль (Roaming Profile) - перемещаемые профили хранятся на сетевом ресурсе. Информация, хранящаяся в перемещаемом профиле доступна пользователю при работе на нескольких машинах. Для настройки перемещаемого профиля администратору необходимо прописать путь к профилю в настройках пользовательской учетной записи. При первом входе пользователя его профиль создается на базе дефолтного профиля. При выходе пользователя из системы содержимое папки профиля копируется на заданный сетевой ресурс.
• Неизменяемые профили (Mandatory Profiles) - неизменяемые профили обычно хранятся централизованно на сетевом ресурсе. При выходе пользователя из системы изменения в профиле не сохраняются. Сделать из обычного профиля неизменяемый можно просто переименовав файл профиля NTUSER.DAT в NTUSER.MAN. Также неизменяемые профили можно конфигурировать с помощью групповых политик или Citrix Profile Management.
• Гибридные профили (Hybrid Profiles) - в рамках гибридного профиля объединяются “ядро” профиля на базе дефолтного (или кастомизированного) профиля и настройки реестра и файлы, подключаемые при логоне. Этот метод позволяет администраторам контролировать то, какие изменения сохранятся в профиле, а какие будут оставаться неизменными. Таким образом, размер профиля будет оставаться в пределах разумного. Кроме того, гибридные профили позволяют использовать функцию last writes wins, которая отслеживает все записи в профиль из нескольких сеансов и позволяет избежать коллизий. Также в профиль записываются только изменения, что позволяет сократить время выхода из системы. Хорошим примером системы управления гибридными профилями является Citrix Profile Management.

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

Перенаправаление папок может дополнить любой из типов профилей. Перенаправление папок это хорошее решение, которое позволяет подключать выбранные папки как сетевые ресурсы и тем самым существенно уменьшает размеры пользовательского профиля. Однако, следует избегать перенаправления папок в которые постоянно производится интенсивная запись или чтение (например - AppData), потому что это может приводить к замедлению работы приложений и неоправданной нагрузки на сервер. При планировании перенаправления папок важно исследовать активность приложений при чтении/записи данных во избежание проблем. Например - Microsoft Outlook постоянно выполняет чтение подписи пользователя из профиля при создани сообщений.
В таблице приведены рекомендации по перенаправлению папок:

Некоторые папки нужно исключать из профилей пользователей для уменьшения размеров профилей. По умолчанию, Windows не хранит в перемещаемых и гибридных профилях папки AppData\Local и AppData\LocalLow, в том числе History, Temp и Temporary Internet Files. Кроме того, следует исключать и другие папки, например Downloads и прочие. Все перенаправляемые папки нужно исключать из перемещаемых и гибридных профилей.

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

• Пул рабочих столов (Hosted Pooled Desktops) (можно не удалять, если виртуальная машина принудительно перезагружается при выходе пользователя).
• Персональный рабочий стол (Hosted Personal Desktops)
• Локальная виртуальная машина (Local VM Desktop)
• Удаленный доступ к рабочему месту (Remote PC Access)

Для ускорения завершения сеанса пользователя существует опция политик Citrix - “Delay before deleting cached profiles”. Включение этой опции позволяет завершить сеанс, а также дать возможность завершиться процессам, работающим с файлами профиля, отложив удаление локально кешированного профиля на заданное время.

Выбор сетевого ресурса для размещения профилей - важный этап. В общем случае - рекомендуется размещать профили на высокопроизводительных NAS или файловых серверах.
При выборе сетевого ресурса важно учитывать четыре момента:

• Производительность (Performance) - В крупных инфраструктурах файловый сервер будет испытывать пиковые нагрузки при массовом подключении и отключении пользователей и скорее всего для нормальной работы потребуется создание кластера файловых серверов для балансировки нагрузки.
• Физическое расположение (Location) - Доступ к профилям осуществляется по протоколу SMB, для которого очень критична величина задержки в локальной сети. Кроме того, пропускная способность WAN-каналов обычно ограничена, что может вызывать существенные задержки в процессе доступа к файлам профиля. Таким образом - файловый сервер должен быть размещен поблизости от серверов приложений и рабочих столов.
• Операционные системы (Operating system platforms) - профили, созданные в разных версиях ОС Windows(различные поколения и разрядность), как правило не совместимы между собой. Таким образом, для ресурсов с различными ОС следует предусмотреть отдельные папки профилей.
• Индексирование (Index capabilities) - Для того, чтобы пользоваться преимуществами Windows Search профили следует размещать на файловых серверах Windows с поддержкой индексирования.

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

• User object - с помощью соответствующего поля в параметрах свойств учетной записи пользователя.
• Computer GPO variables - с помощью групповой политики компьютера к которому производится подключение. В этому случае можно разным группам компьютеров (с разными версиями ОС) назначить различные пути к профилям. Для балансировки нагрузки на файловые серверы нужно учитывать, что объект политики, которая настраивает Citrix Profile Manager, привязана к OU в AD, соответственно, для балансировки достаточно, чтобы компьютеры к которым подключаются пользователи находились в разных OU. Также логично выделять на каждую Delivery Group собственный файловый сервер.

Примечание: Microsoft не поддерживает связку DFS-N + DFS-R для хранения активно используемых профилей. Дополнительную информацию можно найти в статьях:

• Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario
• Microsoft’s Support Statement Around Replicated User Profile Data

При использовании Citrix Profile Manager возможно использование третьего способа указания пути к профилям:

• Аттрибуты и переменные объекта пользователя (User object attributes and variables) - Citrix Profile Manager позволяет сконфигурировать путь к профилю в объекте GPO, используя аттрибуты объекта пользователя в AD. Для этого нужно:
  • Создать DNS-алиас (например - fileserver1), который ссылается на реальный файловый сервер.
  • Занести имя DNS-алиаса в LDAP-аттрибут, который не имеет значения (например - I или UID).
  • Сконфигурировать Citrix Profile Manager с помощью объекта GPO, а в пути к профилям указать ссылку на этот аттрибут. Например, если имя сервера прописано в аттрибуте UID, то путь в настройках GPO будет выглядеть так: \\#UID#\profiles\.

Кроме того, Citrix Profile Manager предоставляет доступ к переменным, значения которых соответствуют параметрам системы. Таким образом можно динамически строить путь к нужному профилю в зависимости от того на какую систему заходит пользователь. Доступны такие переменные:

• !CTX_PROFILEVER! - содержит версию профиля - v1 или v2.
• !CTX_OSBITNESS! - содержит битность ОС - x86 или x64.
• !CTX_OSNAME! - содержит краткое наименование ОС, напрмиер - Win7.

таким образом, сочетая эти приемы можно добиться формирования полностью динамического пути к профилю, который позволит балансировать нагрузку между файловыми серверами и иметь для каждой версии ОС собственный путь к профилю:

\\#UID#\profiles$\%USERNAME%.%USERDOMAIN%\!CTX_OSNAME!!CTX_OSBITNESS!

Функция Profile Streaming доступна при использовании Citrix Profile Manager и позволяет значительно уменьшить время входа пользователя на компьютер. При использовании Profile Streaming система получает сообщение об окончании загрузки профиля сразу после входа пользователя, а файлы копируются на компьютер по мере необходимости (при доступе к ним).
Citrix рекомендует использовать Profile Streaming во всех сценариях развертывания. Если необходимо всегда иметь локальный кеш профиля (для увеличения быстродействия), то следует включать опцию Always Cache и устанавливать размер 0. В этом случае профиль пользователя будет скопирован на компьютер в фоновом режиме и система сможет пользоваться кешированной копией. Это может быть полезно в случае, если приложение пытается получить данные из папки AppData раньше, чем они были скопированы. Включение Always Cache позволяет увеличить быстродействие в случае когда папка AppData не перенаправлена (not redirected).

Функция Profile Streaming доступна при использовании Citrix Profile Manager. Она следит за открытыми файлами и при закрытии файла копирует его на сетевой ресурс в фоновом режиме. Эта функция может быть очень полезна в сценариях, когда пользователь одновременно работает на нескольких рабочих столах. Однако, копируются только файлы, но не записи реестра.