Понимание и оптимизация производительности файлового хранилища Azure

✔️ Область применения: классические общие папки SMB и NFS, созданные с помощью поставщика ресурсов Microsoft.Storage

✔️ Применяется к: общим файловым ресурсам, созданным с помощью поставщика ресурсов Microsoft.FileShares

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

Глоссарий производительности хранилища

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

• Операции ввода-вывода в секунду (IOPS)

  IOPS, или операции ввода-вывода в секунду, измеряет количество операций файловой системы в секунду. В документации по Файлы Azure термин "io" взаимозаменяем с терминами "операция" и "транзакция".

• Объем ввода-вывода

  Размер ввода-вывода, иногда называемый размером блока, — это размер запроса, который приложение использует для выполнения одной операции ввода-вывода (ввода-вывода) в хранилище. В зависимости от приложения размер ввода-вывода может варьироваться от небольших размеров, таких как 4 КиБ до больших размеров. Размер ввода-вывода играет важную роль в достижимой пропускной способности.

• Пропускная способность

  Пропускная способность измеряет количество битов считывания или записи в хранилище в секунду и измеряется в мебибайтах в секунду (MiB/s). Чтобы вычислить пропускную способность, умножьте количество операций ввода-вывода на размер ввода-вывода. Например, 10 000 операций ввода-вывода × 1 МиБ ввода-вывода = 10 ГиБ/с, а 10 000 операций ввода-вывода × 4 КиБ ввода-вывода = 38 МиБ/с.

• Задержка

  Задержка является синонимом задержки и измеряется в миллисекундах (мс). Существует два типа задержки: сквозная задержка и задержка службы. Дополнительные сведения см. в разделе "Задержка".

• Глубина очереди

  Глубина очереди — это количество ожидающих запросов ввода-вывода, которые ресурс хранилища может обрабатывать в любое время. Дополнительные сведения см. в разделе "Глубина очереди".

Выбор уровня мультимедиа на основе шаблонов использования

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

При выборе общих папок SSD и HDD следует учитывать требования ожидаемого шаблона использования, который планируется запустить в Файлы Azure. Если требуется большое количество операций ввода-вывода в секунду, скорость быстрой передачи данных или низкая задержка, выберите общие папки SSD.

В следующей таблице приведены ожидаемые целевые показатели производительности между SSD и общими папками HDD. Дополнительные сведения см. в разделе Целевые показатели масштабируемости и производительности для Файлов Azure.

Файловые ресурсы SSD используют модель подготовки ресурсов, которая гарантирует следующий профиль производительности в зависимости от размера файлового ресурса. Дополнительные сведения см. в подготовленной модели версии 1.

Оптимальные методы повышения производительности

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

• Чувствительность к задержке: Рабочие нагрузки, чувствительные к задержке чтения и напрямую заметные конечным пользователям, лучше подходят для файловых ресурсов SSD, которые могут обеспечивать задержку на уровне одной миллисекунды как для операций чтения, так и для операций записи (менее 2 мс при небольшом размере операций ввода-вывода).

• Требования к операциям ввода-вывода в секунду (IOPS) и пропускной способности: Общие папки SSD поддерживают более высокие ограничения для IOPS и пропускной способности по сравнению с общими папками HDD. Дополнительные сведения см. в разделе целевых показателей масштабирования общих папок.

• Длительность и частота рабочей нагрузки: Короткие (минуты) и нечасто (почасовые) рабочие нагрузки менее склонны достичь верхних ограничений производительности общих папок HDD по сравнению с длительными, часто возникающими рабочими нагрузками. Для файловых ресурсов SSD длительность нагрузки помогает определить, какой профиль производительности следует использовать, исходя из выделенного объёма хранилища, IOPS (операций ввода-вывода в секунду) и пропускной способности. Распространённая ошибка — проводить тесты производительности всего несколько минут, что часто приводит к неверным выводам. Чтобы получить реалистичное представление о производительности, обязательно протестируйте достаточно высокую частоту и длительность.

• Параллелизация рабочей нагрузки: Для рабочих нагрузок, выполняющих операции параллельно, например с несколькими потоками, процессами или экземплярами приложений на одном клиенте, общие папки SSD предоставляют четкое преимущество по сравнению с общими папками HDD: SMB Multichannel. Дополнительные сведения см. в разделе «Повышение производительности общего файлового ресурса Azure по протоколу SMB».

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

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

Задержка

Когда речь идет о задержке, сначала разберитесь, как Файлы Azure определяет задержку. Наиболее распространенные измерения — это задержка, связанная с сквозной задержкой и метриками задержки службы. Используя эти метрики транзакций , вы можете определить задержку на стороне клиента и сетевые проблемы, показывая, сколько времени трафик приложения тратит на транзит в клиент и из нее.

• Конечная задержка (SuccessE2ELatency) — это общее время, необходимое для полной обработки транзакции от клиента через сеть до сервиса Файлы Azure и обратно к клиенту.

• Задержка службы (SuccessServerLatency) — это время, необходимое для полного цикла обработки транзакции только в пределах Файлы Azure. Это измерение не включает задержку клиента или сети.

  

Разница между значениями SuccessE2ELatency и SuccessServerLatency — это задержка, вызванная сетью и /или клиентом.

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

Кроме того, как показано на схеме, чем дальше вы находитесь в службе, тем медленнее задержка и тем сложнее достичь ограничений масштабирования производительности с любой облачной службой. Это условие особенно верно при доступе к Файлы Azure из локальной среды. Хотя такие варианты, как Azure ExpressRoute, идеально подходят для локальной среды, они по-прежнему не соответствуют производительности приложения (вычислений и хранилища), выполняющегося исключительно в том же регионе Azure.

Длина очереди

Глубина очереди — это количество невыполненных запросов ввода-вывода, которые может обслуживать ресурс хранилища. Так как диски, используемые системами хранения, превратились из спинделей HDD (IDE, SATA, SAS) на твердотельные устройства (SSD, NVMe), они также развивались для поддержки более высокой глубины очереди. Рабочая нагрузка, состоящая из одного клиента, который последовательно взаимодействует с одним файлом в большом наборе данных, является примером низкой глубины очереди. В отличие от этого, рабочая нагрузка, поддерживающая параллелизм с несколькими потоками и несколькими файлами, может легко достичь высокой глубины очереди. Так как Файлы Azure — это распределенная файловая служба, которая охватывает тысячи узлов кластера Azure и предназначена для выполнения рабочих нагрузок в масштабе, сборке и тестировании рабочих нагрузок с высокой глубиной очереди.

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

В следующей таблице показаны различные сочетания, которые можно использовать для достижения более высокой глубины очереди. Хотя вы можете превысить оптимальную глубину очереди 64, не рекомендуется. Вы не увидите дальнейшего повышения производительности, если вы это сделаете, и рискуете увеличить задержку из-за перегрузки TCP.

Однопотоковые и многопоточные приложения

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

Эта таблица показывает время, необходимое (в миллисекундах), чтобы создать один 16 КиБ-файл в общей папке Azure на основе однопотокового приложения, которое использует размер блока 4 КиБ для записи.

В этом примере требуется около 14 мс для создания одного 16 КиБ-файла из шести операций. Если однопоточное приложение хочет переместить 10 000 файлов в общую папку Azure, эта операция преобразуется в 140 000 мс (14 мс × 10 000) или 140 секунд, так как каждый файл перемещается последовательно по одному. Время обслуживания каждого запроса в первую очередь определяется тем, как близко вычислительные ресурсы и хранилище расположены друг к другу, как описано в предыдущем разделе.

Используя восемь потоков вместо одного, можно уменьшить предыдущую рабочую нагрузку с 140 000 мс (140 секунд) до 17500 мс (17,5 секунд). Как показано в следующей таблице, при параллельном перемещении восьми файлов вместо одного файла можно переместить тот же объем данных в 87,5% меньше времени.

См. также

• Устранение проблем с производительностью файловых хранилищ Azure
• Мониторинг Файлов Azure
• Планирование развертывания Файлов Azure
• Общие сведения о выставлении счетов за Файлы Azure
• Цены на Файлы Azure