Руководство по файлам Azure для рабочих нагрузок виртуального рабочего стола

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

Что такое VDI?

Инфраструктура виртуальных рабочих столов (VDI) централизованно распределяет рабочие среды на серверах, обеспечивая безопасный удаленный доступ и упрощенное управление на разных устройствах. Виртуальный рабочий стол Azure (AVD) — это облачное решение VDI корпорации Майкрософт, предлагающее масштабируемые, многосеансовые компьютеры Windows 10 и 11 с простой интеграцией с Microsoft 365 и Идентификатором Microsoft Entra, идеально подходит для удаленной работы и безопасного доступа к ресурсам. Другие решения VDI включают Citrix/VMWare Horizon на инфраструктуре Azure.

Почему файлы Azure для VDI?

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

Производительность, масштабирование и затраты

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

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

Виртуальные рабочие столы с домашними каталогами могут воспользоваться кэшированием метаданных в общих папках SSD.

Проверка подлинности и авторизация

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

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

• Локальные доменные службы Active Directory (AD DS): для этого параметра требуется, чтобы пользователи виртуального рабочего стола имели беспрепятственное сетевое подключение к контроллерам домена.

• Microsoft Entra Kerberos (только для гибридных удостоверений): для этого параметра требуется существующее развертывание AD DS, которое затем синхронизируется с клиентом Microsoft Entra, чтобы идентификатор Microsoft Entra смог пройти проверку подлинности гибридных удостоверений. Это хорошо подходит для рабочих нагрузок виртуального рабочего стола, так как оно не требует от пользователей бесперебойного сетевого подключения к контроллерам домена. С помощью этого параметра можно хранить профили, к которым можно обращаться через гибридные удостоверения пользователей из устройств, присоединенных к Microsoft Entra, или узлов сеансов с гибридным присоединением Microsoft Entra.

• Доменные службы Microsoft Entra: если у вас нет доменных служб Active Directory и требуется пройти проверку подлинности удостоверений, доступных только для облака, выберите этот параметр.

Сведения о настройке разрешений хранилища см. в разделе "Настройка разрешений хранилища SMB для FSLogix".

Доступность и аварийное восстановление

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

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

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

Файловые хранилища Azure предлагают стандартные HDD и премиальные SSD. Помните, что общие папки SSD Azure не предлагают геоизбыточность. Дополнительные сведения о различных вариантах избыточности, доступных для файлов Azure, см. в статье "Избыточность файлов Azure ".

руководство по определению размеров Azure Files для Azure виртуального рабочего стола

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

Файлы Azure поддерживают сценарии хранения профилей FSLogix и не-FSLogix. В этом руководстве приведены рекомендуемые конфигурации общей папки на основе количества одновременных пользователей виртуального рабочего стола, ожидаемых операций ввода-вывода в секунду на пользователя и типа хранилища (HDD или SSD). Как правило, FSLogix обеспечивает более эффективное использование дескрипторов по сравнению с не-FSLogix.

Контейнеры профилей FSLogix

Если вы используете FSLogix с Azure Virtual Desktop, контейнеры профилей пользователей представлены в виде файлов виртуального жесткого диска (VHD) или Hyper-V виртуального жесткого диска (VHDX), и они монтируются в пользовательском контексте, а не в системном. Каждый пользователь открывает один корневой дескриптор каталога, который должен находиться в общей папке. Azure Files может поддерживать не более 10 000 пользователей, если у вас есть общий файловый ресурс (\\storageaccount.file.core.windows.net\sharename) + каталог профилей (%sid%_%username%) + контейнер профиля (profile_%username.vhd(x)).

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

Например, если у вас есть 2400 одновременных пользователей, вам потребуется 2400 дескрипторов в корневом каталоге (по одному для каждого пользователя), что ниже ограничения на 10 000 открытых дескрипторов. Для пользователей FSLogix вряд ли достижима ситуация, когда будет исчерпан лимит на открытые дескрипторы файлов и каталогов. Если у вас есть один контейнер профиля FSLogix для каждого пользователя, вы будете использовать только два дескриптора файлов и каталогов: один для каталога профилей и один для файла контейнера профиля. Если у пользователей есть два контейнера (профиль и ODFC), вам потребуется еще один дескриптор для ODFC-файла.

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

• Каждый пользователь имеет 1–2 контейнера (профиль + необязательный контейнер Office)
• Дескрипторы: ~2–3 на пользователя (корневой каталог, профиль и, возможно, контейнер ODFC)

Хранилище профилей, отличных от FSLogix

Если вы не используете FSLogix, вы можете использовать перемещаемые профили пользователей или перенаправление папок в Windows.

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

• Данные профиля хранятся как много небольших файлов и папок
• Более высокая производительность операций ввода-вывода метаданных на пользователя
• Расход дескрипторов относительно высок (каждое обращение к файлу или папке потребляет дескриптор)
• Размер профиля ~5 ГиБ
• Пиковые IOPS: 50 IOPS на пользователя во время входа в систему, 20 IOPS на пользователя во время устойчивого состояния

Присоединение приложения

Если вы используете MSIX App attach или App attach для динамического подключения приложений, можно использовать файловую систему Composite Image File System (CimFS) или файлы VHD/VHDX для образов дисков. В любом случае ограничения масштабирования предназначены для каждого подключения образа виртуальной машины, а не для каждого пользователя. Количество пользователей не имеет значения при вычислении ограничений масштабирования. При загрузке виртуальной машины он подключает образ диска, даже если нет пользователей.

Подключение приложения с помощью CimFS

Если вы используете App attach с CimFS, образы дисков используют только дескрипторы в файлах образа диска. Они не используют дескрипторы в корневом каталоге или в каталоге, содержащем образ диска. Тем не менее, поскольку образ CimFS представляет собой сочетание .cim-файла и минимум двух других файлов, для каждой виртуальной машины, которая монтирует образ диска, требуется по одному дескриптору для каждого из трех файлов в каталоге. Поэтому если у вас есть 100 виртуальных машин, вам потребуется 300 дескрипторов файлов.

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

Подключение приложения через VHD/VHDX

Если вы используете подключение приложения с VHD/VHDX-файлами, файлы подключаются в контексте системы, а не в контексте пользователя. Они общие и только для чтения. Несколько дескрипторов доступа VHDX-файла могут использоваться системой, предназначенной для подключения. Чтобы оставаться в пределах масштабных ограничений Azure Files, произведение числа виртуальных машин на число приложений должно быть меньше 10 000, и количество виртуальных машин на одно приложение не может превышать 2000. Таким образом, ограничением является то, на что вы наткнетесь первым.

В этом сценарии можно достичь лимита на файл/каталог при 2000 монтированиях одного виртуального жесткого диска или VHDX. Или, если общий ресурс содержит несколько VHD/VHDX-файлов, сначала можно столкнуться с ограничением корневого каталога. Например, 100 виртуальных машин, подключенных к 100 общим VHDX-файлам, достигнут предела количества дескрипторов в корневом каталоге, равного 10 000.

В другом примере 100 виртуальных машин, подключающихся к 20 приложениям, потребуются 2000 маркеров корневого каталога (100 x 20 = 2000), что находится в допустимых пределах 10 000 маркеров корневого каталога. Кроме того, вам нужен дескриптор файлов и дескриптор каталога и папки для каждой виртуальной машины, подключенной к образу VHD(X), поэтому 200 дескрипторов в этом случае (100 дескрипторов файлов + 100 дескрипторов каталогов), что удобно ниже ограничения на 2000 дескрипторов для каждого файла или каталога.

Если вы достигаете предела на максимальные одновременные дескрипторы для корневого каталога, используйте дополнительное файловое хранилище Azure.

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

См. также

• Рекомендации по хранению рабочих нагрузок Виртуального рабочего стола Azure
• Варианты хранения для контейнеров профилей FSLogix в Виртуальном рабочем столе Azure