Целевые показатели масштабируемости службы файлов Azure
Файлы Azure предоставляют полностью управляемые общие папки в облаке, доступные по протоколам файловой системы SMB и NFS. В этой статье описываются целевые показатели масштабируемости и производительности службы файлов Azure и службы синхронизации файлов Azure.
Указанные здесь цели могут зависеть от других параметров развертывания. Например, производительность операций ввода-вывода для файла может повлиять на поведение клиента МБ и доступную пропускную способность сети. Вам следует протестировать конкретную модель использования и оценить, соответствуют ли показатели масштабируемости и производительности службы "Файлы Azure" вашим требованиям.
Применяется к
| Тип общей папки | SMB | NFS |
|---|---|---|
| Стандартные общие папки (GPv2), LRS/ZRS |  |
 |
| Стандартные общие папки (GPv2), GRS/GZRS | |
|
| Общие папки уровня "Премиум" (FileStorage), LRS/ZRS | |
|
Целевые показатели масштабируемости службы файлов Azure
Общие папки Azure развертываются в учетных записях хранения. Это объекты верхнего уровня, которые представляют общий пул хранилища. Этот пул хранилища можно использовать для развертывания нескольких общих папок. Поэтому необходимо учитывать три категории: учетные записи хранения, общие папки Azure и отдельные файлы.
Целевые показатели масштабируемости для учетной записи хранения
Целевые показатели масштабирования учетной записи хранения применяются на уровне учетной записи хранения. В Файлах Azure существует два основных типа учетных записей хранения.
Учетные записи хранения общего назначения версии 2. Такие учетные записи хранения позволяют развертывать общие папки Azure на оборудовании на основе жестких дисков (HDD) уровня "Стандартный". Наряду с общими папками Azure такие учетные записи хранения поддерживают и другие ресурсы хранилища, включая контейнеры больших двоичных объектов, очереди и таблицы. Общие папки можно развернуть на уровнях, оптимизированных для транзакций (по умолчанию), а также на горячем или холодном уровнях.
Учетные записи хранения FileStorage. Такие учетные записи хранения позволяют развертывать общие папки Azure на оборудовании на основе твердотельных накопителей (SSD) уровня "Премиум". Учетные записи FileStorage можно использовать только для хранения общих папок Azure. Другие ресурсы хранилища (контейнеры больших двоичных объектов, очереди, таблицы и т. д.) нельзя развертывать в учетной записи FileStorage.
| Атрибут | Учетные записи хранения GPv2 (Стандартный) | Учетные записи хранения FileStorage (Премиум) |
|---|---|---|
| Количество учетных записей хранилища на подписку на регион | 2501 | 2501 |
| Максимальная емкость учетной записи хранения | 5 PiB2 | 100 ТиБ (подготовлено) |
| Максимальное количество файловых ресурсов | Не ограничено | Неограниченно, общий размер всех общих папок должен быть меньше, чем максимальная емкость учетной записи хранения. |
| Максимальное количество параллельных запросов | 20 000 операций ввода-вывода в секунду2 | 102 400 операций ввода-вывода в секунду |
Пропускная способность (для входящего и исходящего трафика) для LRS и GRS
|
|
10 340 МиБ/с |
Пропускная способность (для входящего и исходящего трафика) для ZRS
|
|
10 340 МиБ/с |
| Пропускная способность (для входящего и исходящего трафика) для других сочетаний избыточности и региона, кроме перечисленных в предыдущей строке |
|
10 340 МиБ/с |
| Максимальное число правил виртуальной сети | 200 | 200 |
| Максимальное число правил IP-адресов | 200 | 200 |
| Управляющие операции чтения | 800 за 5 минут | 800 за 5 минут |
| Управляющие операции записи | 10 в секунду / 1200 в час | 10 в секунду / 1200 в час |
| Управляющие операции вывода | 100 за 5 минут | 100 за 5 минут |
1 С увеличением квоты можно создать до 500 учетных записей хранения со стандартными конечными точками в каждом регионе. Дополнительные сведения см. в разделе "Увеличение служба хранилища Azure квот учетных записей". 2 Учетные записи хранения общего назначения версии 2 поддерживают более высокие ограничения емкости и более высокие ограничения для входящего трафика по запросу. Чтобы подать запрос на увеличение ограничений для учетной записи, обратитесь в службу поддержки Azure.
Целевые объекты масштабирования общей папки Azure
Целевые показатели масштабирования общей папки Azure применяются на уровне файлового ресурса.
| Атрибут | Общие файлы уровня "Стандартный"1 | Общие папки ценовой категории "Премиум" |
|---|---|---|
| Минимальный размер общего файла | Без минимального значения | 100 ГиБ (подготовлено) |
| Размер подготовленной единицы увеличения/уменьшения размера | Н/П | 1 ГиБ |
| Максимальный размер общей папки |
|
100 Тиб |
| Максимальное количество файлов в общей папке | Без ограничений | Без ограничений |
| Максимальная частота запросов (максимальное число операций ввода-вывода в секунду) |
|
|
| Пропускная способность (входящий + исходящий трафик) для одной общей папки (МиБ/с) |
|
100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
| Максимальное число моментальных снимков общих ресурсов | 200 моментальных снимков | 200 моментальных снимков |
| Максимальная длина имени объекта3 (полный путь, включающий все каталоги, имена файлов и символы обратной косой черты) | 2048 символов | 2048 символов |
| Максимальная длина отдельного компонента пути3 (в пути \A\B\C\D каждая буква представляет каталог или файл, который является отдельным компонентом) | 255 символов | 255 символов |
| Ограничение жесткой связи (только NFS) | Н/П | 178 |
| Максимальное количество каналов SMB Multichannel | Н/П | 4 |
| Максимальное число хранимых политик доступа на общую папку | 5 | 5 |
1 Ограничения для общих папок ценовой категории "Стандартный" применяются на всех трех уровнях, доступных для этих папок: оптимизированные для транзакций, горячий уровень, холодный уровень.
2 Размер общих папок категории "Стандартный" по умолчанию — 5 Тиб. Дополнительные сведения о том, как создавать общие папки размером 100 ТиБ и увеличить размер существующих общих папок категории "Стандартный" до 100 Тиб см. в статье Создание общей папки Azure. Чтобы воспользоваться преимуществами более крупных целевых объектов масштабирования, необходимо изменить квоту, чтобы она превышала 5 ТиБ.
3 В Файлах Azure действуют определенные правила именования каталогов и файлов.
Целевые масштабы файлов
Целевые масштабы файлов применяются к отдельным файлам, хранящимся в общих папках Azure.
| attribute | Файлы в общих папках уровня "Стандартный" | Файлы в общих папках уровня "Премиум" |
|---|---|---|
| Максимальный размер файла | 4 ТиБ | 4 ТиБ |
| Максимальное количество параллельных запросов | 1000 операций ввода-вывода в секунду | До 80001 |
| Максимальный входящий трафик для файла | 60 МиБ/с | 200 МиБ/с (до 1 ГиБ/с с помощью SMB Multichannel)2 |
| Максимальный исходящий трафик для файла | 60 МиБ/с | 300 МиБ/с (до 1 ГиБ/с с помощью SMB Multichannel)2 |
| Максимальное число одновременных дескрипторов для корневого каталога3 | 10 000 дескрипторов | 10 000 дескрипторов |
| Максимальное число одновременных дескрипторов для каждого файла и каталога3 | 2000 дескрипторов | 2000 дескрипторов |
1 Применяется для чтения и записи операций ввода-вывода (обычно меньше размеров ввода-вывода меньше или равно 64 КИБ). Операции с метаданными, кроме операций чтения и записи, могут поддерживать более низкие значения. Это мягкие ограничения, и регулирование может осуществляться за их пределами.
2 Под ограничениями сети компьютера, доступной пропускной способностью, размерами ввода-вывода, глубиной очереди и другими факторами. Дополнительные сведения см. в статье S МБ Производительность нескольких каналов.
3 Файлы Azure поддерживает 10 000 открытых дескрипторов в корневом каталоге и 2000 открытых дескрипторов на файл и каталог в общей папке. Количество активных пользователей, поддерживаемых для каждой общей папки, зависит от приложений, обращаюющихся к общей папке. Если приложения не открывают дескриптор в корневом каталоге, Файлы Azure может поддерживать более 10 000 активных пользователей на общую папку. Однако если вы используете Файлы Azure для хранения образов дисков для крупномасштабных рабочих нагрузок виртуальных рабочих столов, возможно, не упустите дескриптор корневого каталога или каждого файла или каталога. В этом случае может потребоваться использовать несколько общих папок Azure. Дополнительные сведения см. в Файлы Azure руководстве по размеру виртуального рабочего стола Azure.
руководство по размеру Файлы Azure для виртуального рабочего стола Azure
Популярным вариантом использования Файлы Azure является хранение контейнеров профилей пользователей и образов дисков для виртуального рабочего стола Azure с помощью FSLogix или подключения приложений. В крупномасштабных развертываниях Виртуального рабочего стола Azure вы можете не использовать дескриптор для корневого каталога или для каждого файла или каталога, если вы используете одну общую папку Azure. В этом разделе описывается, как дескриптор используется различными типами образов дисков и предоставляет рекомендации по размеру в зависимости от используемой технологии.
FSLogix
Если вы используете FSLogix с виртуальным рабочим столом Azure, контейнеры профилей пользователей являются файлами виртуального жесткого диска (VHD) или Hyper-V Virtual Hard Disk (VHDX), а не системным контекстом. Каждый пользователь откроет один корневой дескриптор каталога, который должен находиться в общей папке. Файлы Azure может поддерживать не более 10 000 пользователей, если у вас есть общий файловый ресурс () + каталог профилей (\\storageaccount.file.core.windows.net\sharename%sid%_%username%) + контейнер профиля (profile_%username.vhd(x)).
Если вы достигаете предела в 10 000 одновременных дескрипторов для корневого каталога или пользователей, попробуйте использовать дополнительную общую папку Azure и распределить контейнеры между общими папками.
Предупреждение
Хотя Файлы Azure может поддерживать до 10 000 одновременных пользователей из одной общей общей папки, важно правильно протестировать рабочие нагрузки по размеру и типу созданного общей папки. Требования могут отличаться в зависимости от пользователей, размера профиля и рабочей нагрузки.
Например, если у вас есть 2400 одновременных пользователей, вам потребуется 2400 дескрипторов в корневом каталоге (по одному для каждого пользователя), что ниже ограничения на 10 000 открытых дескрипторов. Для пользователей FSLogix ограничение в 2000 открытых файлов и дескрипторов каталогов крайне маловероятно. Если у вас есть один контейнер профиля FSLogix для каждого пользователя, вы будете использовать только два дескриптора файлов и каталогов: один для каталога профилей и один для файла контейнера профиля. Если у пользователей есть два контейнера (профиль и ODFC), потребуется один дополнительный дескриптор для ODFC-файла.
Подключение приложения с помощью CimFS
Если вы используете подключение приложения MSIX или приложение для динамического подключения приложений, можно использовать составную файловую систему образов (CimFS) или VHDX-файлы для образов дисков. В любом случае ограничения масштабирования предназначены для каждого подключения образа виртуальной машины, а не для каждого пользователя. Количество пользователей не имеет значения при вычислении ограничений масштабирования. При загрузке виртуальной машины он подключает образ диска, даже если нет пользователей.
Если вы используете подключение приложения с CimFS, образы дисков используют только дескриптор в файлах образа диска. Они не используют дескриптора в корневом каталоге или каталоге, содержам образ диска. Тем не менее, поскольку образ CimFS представляет собой сочетание CIM-файла и по крайней мере двух других файлов для каждой виртуальной машины, подключенной к образу диска, вам потребуется один дескриптор для трех файлов в каталоге. Таким образом, если у вас есть 100 виртуальных машин, вам потребуется 300 дескрипторов файлов.
Если количество виртуальных машин в каждом приложении превышает 2000, может не работать дескриптор файлов. В этом случае используйте дополнительную общую папку Azure.
Подключение приложения с помощью VHD/VHDX
Если вы используете подключение приложения с файлами VHD/VHDX, файлы подключены в системном контексте, а не в контексте пользователя, и они доступны только для чтения. Несколько дескрипторов vHDX-файла могут использоваться системой подключения. Чтобы оставаться в пределах Файлы Azure масштабируемых ограничений, число виртуальных машин, умноженных на число приложений, должно быть меньше 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"
В следующей таблице указано, какие целевые объекты являются мягкими, представляющими проверенную корпорацией Майкрософт границу и жесткой, указывая на принудительное максимальное значение:
| Ресурс | Назначение | Строгое ограничение |
|---|---|---|
| Служб синхронизации службы хранилища на регион | 100 служб синхронизации хранилища | Да |
| Число служб синхронизации хранилища на подписку | 15 служб синхронизации хранилища | Да |
| Число групп синхронизации на службу синхронизации хранилища | 200 групп синхронизации | Да |
| Число зарегистрированных серверов на службу синхронизации хранилища | 99 серверов | Да |
| Частные конечные точки на службу синхронизации служба хранилища | 100 частных конечных точек | Да |
| Количество облачных конечных точек на группу синхронизации | 1 облачная конечная точка | Да |
| Количество конечных точек сервера на группу синхронизации | 100 конечных точек сервера | Да |
| Число конечных точек сервера на сервер | 30 конечных точек сервера | Да |
| Число объектов файловой системы (папок и файлов) на группу синхронизации | 100 млн объектов | нет |
| Максимальное число объектов файловой системы (папок и файлов) в каталоге (не рекурсивно) | 5 млн объектов | Да |
| Максимальная длина дескриптора защиты объекта (папок и файлов) | 64 КиБ | Да |
| Размер файла | 100 ГиБ | нет |
| Минимальный размер для файла, который будет связан | на основе размера кластера файловой системы (двойной размер кластера файловой системы). Например, если размер кластера файловой системы равен 4 КиБ, минимальный размер файла будет равен 8 КиБ. | Да |
Примечание.
Конечная точка Синхронизации файлов Azure может масштабироваться до размера общей папки Azure. Если достигнуто ограничение размера общей папки Azure, синхронизация не сможет работать.
Метрики производительности службы синхронизации файлов Azure
Так как агент Синхронизация файлов Azure работает на компьютере Windows Server, подключаемом к общим папкам Azure, производительность эффективной синхронизации зависит от ряда факторов в инфраструктуре: Windows Server и базовой конфигурации диска, пропускной способности сети между сервером и хранилищем Azure, размером файла, общим размером набора данных и действием в наборе данных. Так как служба синхронизации файлов Azure работает на уровне файлов, характеристики производительности решения на основе этой службы следует измерять в количестве обрабатываемых объектов (файлов и каталогов) в секунду.
Для службы синхронизации файлов Azure производительность имеет решающее значение на двух этапах:
- Исходная однократная подготовка. Сведения об оптимальном развертывании для оптимизации производительности при начальной подготовке см. в разделе Подключение с помощью Синхронизации файлов Azure.
- Непрерывная синхронизация. После первоначального добавления данных в общие папки Azure служба "Синхронизация файлов Azure" синхронизирует несколько конечных точек.
Примечание.
Когда многие конечные точки сервера в одной группе синхронизации синхронизируются одновременно, они утверждаются на ресурсы облачной службы. В результате производительность отправки влияет на производительность. В крайних случаях некоторые сеансы синхронизации не смогут получить доступ к ресурсам и завершаются сбоем. Однако эти сеансы синхронизации будут возобновлены в ближайшее время и в конечном итоге завершатся успешно после снижения перегрузки.
Внутренние результаты теста
Чтобы спланировать развертывание для каждого этапа (начальная одноразовая подготовка и текущая синхронизация), ниже приведены результаты, которые мы наблюдаем во время внутреннего тестирования в системе со следующей конфигурацией:
| Конфигурация системы | Сведения |
|---|---|
| ЦП | 64 виртуальных ядер с кэшем L3 на 64 МиБ |
| Память | 128 ГиБ |
| Диск | Диски SAS с RAID 10 и кэшем, работающем от аккумулятора |
| Сеть | Сеть 1 Гбит/с |
| Рабочая нагрузка | Файловый сервер общего назначения |
Одноразовая начальная подготовка
| Одноразовая начальная подготовка | Сведения |
|---|---|
| Число объектов | 25 млн объектов |
| Размер набора данных | ~4,7 ТиБ |
| Средний размер файлов | ~200 КиБ (самый большой файл: 100 ГиБ) |
| Исходное перечисление изменений в облаке | 80 объектов в секунду |
| Пропускная способность отправки | 20 объектов в секунду на группу синхронизации |
| Пропускная способность скачивания пространств имен | 400 объектов в секунду |
Начальное перечисление изменений в облаке. При создании новой группы синхронизации начальное перечисление изменений в облаке является первым шагом, который выполняется. В этом процессе система перечисляет все элементы в общей папке Azure. Во время этого процесса не будет никаких действий синхронизации. Элементы не будут скачивать из облачной конечной точки в конечную точку сервера и никакие элементы не будут отправляться из конечной точки сервера в облачную конечную точку. Действие синхронизации будет возобновлено после завершения исходного перечисления изменений в облаке.
Скорость составляет 80 объектов в секунду. Вы можете оценить время, необходимое для завершения первоначального перечисления изменений в облаке, определив количество элементов в облачной общей папке и используя следующую формулу, чтобы получить время в днях.
Время (в днях) для исходного перечисления в облаке = (число объектов в облачной конечной точке)/(80 * 60 * 60 * 24)
Исходная синхронизация данных из Windows Server в общую папку Azure. Многие развертывания Синхронизации файлов Azure начинаются с пустой общей папки Azure, так как все данные находятся на сервере Windows Server. В таких случаях начальное перечисление изменений в облаке выполняется быстро, и большинство времени тратится на синхронизацию изменений из Windows Server в общую папку Azure.
Хотя синхронизация отправляет данные в общую папку Azure, на локальном файловом сервере нет времени простоя, а администраторы могут настроить ограничения сети, чтобы ограничить объем пропускной способности, используемой для фоновой передачи данных.
Исходная синхронизация обычно ограничивается начальной скоростью передачи в 20 файлов в секунду на группу синхронизации. Клиенты могут оценить время отправки всех своих данных в Azure, используя следующую формулу для расчета времени в днях:
Время (в днях) для отправки файлов в группу синхронизации = (число объектов в конечной точке сервера)/(20 * 60 * 60 * 24)
Разделение данных на несколько конечных точек сервера и групп синхронизации может ускорить начальную передачу данных, так как отправка может выполняться параллельно для нескольких групп синхронизации со скоростью 20 элементов в секунду. Таким образом, две группы синхронизации будут выполняться с общей скоростью 40 элементов в секунду. Общее время выполнения будет равно времени выполнения для группы синхронизации с наибольшим количеством синхронизируемых файлов.
Пропускная способность скачивания пространства имен: когда новая конечная точка сервера добавляется в существующую группу синхронизации, агент Синхронизация файлов Azure не загружает содержимое файла из облачной конечной точки. Сначала он синхронизирует полное пространство имен, а затем запускает фоновый вызов для скачивания файлов, либо полностью, либо, если включено распределение по уровням облака, в политику распределения по уровням облака, установленную на конечной точке сервера.
Непрерывная синхронизация
| Непрерывная синхронизация | Сведения |
|---|---|
| Количество синхронизированных объектов | 125 000 объектов (~1 % обновления) |
| Размер набора данных | 50 ГиБ |
| Средний размер файлов | ~500 КиБ |
| Пропускная способность отправки | 20 объектов в секунду на группу синхронизации |
| Полная пропускная способность скачивания* | 60 объектов в секунду |
*Если включено распределение по уровням в облаке, скорее всего, вы увидите более высокую производительность, так как скачиваются только некоторые данные файла. Синхронизация файлов Azure только загружает данные кэшированных файлов при их изменении на любой из конечных точек. Для всех многоуровневых или недавно созданных файлов агент не скачивает данные файла, а синхронизирует пространство имен только со всеми конечными точками сервера. Агент также поддерживает частичное скачивание многоуровневых файлов по мере доступа пользователя.
Примечание.
Эти числа не указывают на производительность, которую вы будете испытывать. Фактическая производительность зависит от нескольких факторов, описанных в начале этого раздела.
В качестве общего руководства по развертыванию имейте в виду следующее:
- Пропускная способность объекта приблизительно масштабируется пропорционально количеству групп синхронизации на сервере. Разделение данных на несколько групп синхронизации на сервере улучшает пропускную способность, которая также ограничена сервером и сетью.
- Пропускная способность объекта обратно пропорциональна пропускной способности в МиБ в секунду. Для небольших файлов вы будете испытывать более высокую пропускную способность с точки зрения количества объектов, обрабатываемых в секунду, но ниже МиБ в секунду. И наоборот, для больших файлов вы получите меньше объектов, обработанных в секунду, но более высокую пропускную способность MiB в секунду. Пропускная способность в МиБ в секунду ограничена целевыми объектами масштабирования файлов Azure.