Стандартные показатели производительности томов Azure NetApp Files для Linux
В этой статье описываются тесты производительности Azure NetApp Files для Linux с обычным томом.
Все рабочие нагрузки потоковой передачи файлов (тесты тестов на основе горизонтального масштабирования)
Цель теста горизонтального масштабирования — показать производительность тома Файла Azure NetApp при масштабировании (или увеличении) числа клиентов, генерирующих одновременную рабочую нагрузку на тот же том. Как правило, эти тесты могут отправлять том на край своих ограничений производительности и указывают на рабочие нагрузки, такие как отрисовка мультимедиа, ИИ/ML и другие рабочие нагрузки, использующие большие вычислительные фермы для выполнения работы.
Конфигурация тестов с высоким масштабируемым масштабированием операций ввода-вывода
Эти тесты используют следующие показатели:
- Один обычный том Azure NetApp Files 100-TiB с набором данных 1-ТиБ с использованием уровня производительности "Ультра"
- FIO (с параметром randrepeat=0)
- Размер блока 4-KiB и 8 КиБ
- 6 D32s_v5 виртуальных машин с RHEL 9.3
- NFSv3
- Руководство по QoS
- Параметры подключения: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Конфигурация эталонного теста масштабирования высокой пропускной способности
Эти тесты используют следующие показатели:
- Один регулярный том Azure NetApp Files с набором данных 1-TiB с помощью FIO уровня производительности "Ультра" (с параметром randrepeat=0)
- FIO (с параметром randrepeat=0)
- Размер блока 64-KiB и 256-KiB
- 6 D32s_v5 виртуальных машин с RHEL 9.3
- NFSv3
- Руководство по QoS
- Параметры подключения: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Конфигурация тестов параллельного сетевого подключения (nconnect)
Эти тесты используют следующие показатели:
- Один обычный том Azure NetApp Files с набором данных 1 ТиБ с помощью уровня производительности "Ультра"
- FIO (с параметром randrepeat=0)
- 4-KiB и 64-KiB wsize/rsize
- Одна D32s_v4 виртуальная машина под управлением RHEL 9.3
- NFSv3 с и без
nconnect - Параметры подключения: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Тесты тестов на основе масштабирования
Цель теста масштабирования — показать производительность тома Azure NetApp File при увеличении (или увеличении) количества заданий, генерирующих одновременную рабочую нагрузку для нескольких TCP-подключений на одном клиенте, к одному тому (например, с nconnect).
Без nconnectэтого эти рабочие нагрузки не могут отправлять ограничения максимальной производительности тома, так как клиент не может генерировать достаточную пропускную способность ввода-вывода или сети. Как правило, эти тесты свидетельствуют о том, что взаимодействие с одним пользователем может находиться в рабочих нагрузках, таких как отрисовка мультимедиа, базы данных, ИИ/ML и общие общие файловые ресурсы.
Высокомасштабируемые тесты масштабирования операций ввода-вывода
В следующих тестах производительность, достигнутная для Azure NetApp Files с высокой рабочей нагрузкой ввода-вывода и операций ввода-вывода, используется:
- 32 клиента
- 4-KiB и 8-KiB случайные операции чтения и записи
- Набор данных 1-TiB
- Коэффициенты чтения и записи: 100%:0%, 90%:10%, 80%:20%, т. д.
- Кэширование файловой системы и без нее (использование
randrepeat=0в FIO)
Дополнительные сведения см . в статье "Методология тестирования".
Результаты: 4 КиБ, случайное кэширование клиента
В этом тесте FIO выполнялся без randrepeat параметра случайной обработки данных. Таким образом, неопределенное количество кэширования вступило в игру. Эта конфигурация приводит к значительно лучшему общему количеству производительности, чем тесты запускаются без кэширования с использованием всего стека операций ввода-вывода.
На следующем графике тестирования показан регулярный том Azure NetApp Files, который может обрабатываться примерно от 130 000 чистых случайных операций записи 4-KiB и примерно 460 000 чистых случайных 4 КИБ считывается во время этого теста. Сочетание операций чтения и записи для рабочей нагрузки, скорректированной на 10 % для каждого запуска.
По мере увеличения объема операций ввода-записи операций чтения и операций ввода-операций в режиме записи общий объем операций ввода-записи увеличивается.
Результаты: 4 КиБ, случайное кэширование клиента, исключенное
В этом тесте FIO был запущен с параметром randrepeat=0 случайных данных, уменьшая влияние кэширования на производительность. Это привело к сокращению операций ввода-вывода и операций ввода-вывода примерно на 8 % и примерно на 17 % при чтении операций ввода-вывода, но отображает более репрезентативные показатели производительности того, что на самом деле может сделать хранилище.
На следующем графике тестирования показан регулярный том Azure NetApp Files, который может обрабатываться примерно от 120 000 чистых случайных операций записи 4-KiB и примерно 388 000 чистых случайных операций чтения 4-KiB. Сочетание операций чтения и записи для рабочей нагрузки, скорректированной на 25 % для каждого запуска.
По мере увеличения объема операций ввода-записи операций чтения и операций ввода-операций в режиме записи общий объем операций ввода-записи увеличивается.
Результаты: 8 КиБ, случайное кэширование клиента, исключенное
Более крупные размеры операций чтения и записи приводят к меньшему общему объему операций ввода-вывода, так как с каждой операцией можно отправлять больше данных. Размер чтения и записи 8 КИБ использовался для более точной имитации использования большинства современных приложений. Например, многие приложения EDA используют 8-KiB чтения и записи.
В этом тесте FIO выполнялся со randrepeat=0 случайными данными, чтобы снизить влияние кэширования клиента. На следующем графике тестирования показано, что регулярный том Azure NetApp Files может обрабатываться примерно от 111 000 чистых случайных операций записи 8-KiB и примерно 293 000 чистых случайных операций чтения 8-КиБ. Сочетание операций чтения и записи для рабочей нагрузки, скорректированной на 25 % для каждого запуска.
По мере увеличения объема операций ввода-записи операций чтения и операций ввода-операций в режиме записи общий объем операций ввода-записи увеличивается.
Параллельное сравнение
Чтобы иллюстрировать, как кэширование может повлиять на тесты производительности, на следующем графике показан общий объем операций ввода-вывода для 4-КиБ-тестов с механизмами кэширования и без нее. Как показано выше, кэширование обеспечивает небольшое повышение производительности для довольно согласованного тренда ввода-вывода в секунду.
Конкретное смещение, потоковая передача случайных рабочих нагрузок чтения и записи: масштабирование тестов с помощью параллельных сетевых подключений (nconnect)
В следующих тестах показан высокий тест ввода-вывода с использованием одного клиента с 4-KiB случайными рабочими нагрузками и набором данных 1-TiB. Сочетание рабочих нагрузок, созданное каждый раз, использует другую глубину ввода-вывода. Чтобы повысить производительность для одной клиентской рабочей нагрузки, nconnect параметр подключения использовался для улучшения параллелизма по сравнению с подключениями клиентов без nconnect параметра подключения.
При использовании стандартного TCP-подключения, предоставляющего только один путь к хранилищу, меньше общих операций отправляются в секунду, чем если подключение может использовать больше TCP-подключений (например, с nconnect) на точку подключения. При использовании nconnectобщая задержка операций обычно ниже. Эти тесты также выполняются, randrepeat=0 чтобы намеренно избежать кэширования. Дополнительные сведения об этом параметре см . в статье "Методология тестирования".
Результаты: 4 КиБ, случайные, без nconnectкэширования исключенные
На следующих графиках показано параллельное сравнение операций чтения и записи 4 КиБ и без nconnect выделения улучшений производительности при использовании nconnect: более высокая общая задержка ввода-вывода и операций ввода-вывода.
Тесты высокой пропускной способности
В следующих тестах показана производительность, достигнутная для Azure NetApp Files с высокой пропускной способностью.
Рабочие нагрузки с высокой пропускной способностью являются более последовательными и часто удобочитаются и записываются с низкими метаданными. Пропускная способность, как правило, более важна, чем I/OPS. Эти рабочие нагрузки обычно используют более крупные размеры чтения и записи (64K до 256K), которые создают более высокую задержку, чем меньшие размеры чтения и записи, так как большие полезные данные, естественно, будут обрабатываться дольше.
Ниже приведены примеры рабочих нагрузок высокой пропускной способности:
- Репозитории мультимедиа
- Для высокопроизводительных вычислений
- ИИ/ML/ML/ТОО
В следующих тестах показана высокая пропускная способность с использованием 64-KiB и 256-KiB последовательных рабочих нагрузок и набора данных 1-ТиБ. При использовании различных коэффициентов чтения и записи (например, 100%:0%, 90%:100%, 90%:10%, 80%:20% и т. д.).
Результаты: 64 КиБ последовательного ввода-вывода, включена кэширование
В этом тесте FIO выполнялся с помощью логики цикла, которая более агрессивно заполняла кэш, поэтому неопределенное количество кэширования повлияло на результаты. Это приводит к немного лучшему общему числу производительности, чем тесты выполняются без кэширования.
На приведенном ниже графике тестирование показывает, что обычный том Azure NetApp Files может обрабатываться примерно от 4500MiB/с чистой последовательной записи 64-KiB и приблизительно 1600MiB/с чистой последовательной записи 64-KiB. Сочетание чтения и записи для рабочей нагрузки было скорректировано на 10 % для каждого запуска.
Результаты: 64 КиБ последовательного ввода-вывода, кэширование исключено
В этом тесте FIO выполнялся с помощью логики цикла, которая менее агрессивно заполняла кэш. Кэширование клиента не повлияло на результаты. Эта конфигурация приводит к немного лучшему числу производительности записи, но меньше чисел чтения, чем тесты без кэширования.
На следующем графике тестирование демонстрирует, что обычный том Azure NetApp Files может обрабатываться примерно от 3600MiB/с чистой последовательной записи 64-KiB и приблизительно 2400МиБ/с чистой последовательной записи 64-KiB. Во время тестов 50/50 смесь показала общую пропускную способность по пару с чистой последовательной рабочей нагрузкой чтения.
Сочетание чтения и записи для рабочей нагрузки было скорректировано на 25 % для каждого запуска.
Результаты: 256 КиБ последовательного ввода-вывода, кэширование исключено
В этом тесте FIO выполнялся с помощью логики цикла, которая менее агрессивно заполняла кэш, поэтому кэширование не повлияло на результаты. Эта конфигурация приводит к немного меньшему числу производительности записи, чем 64-КиБ-тесты, но более высокие числа чтения, чем те же 64-KiB-тесты выполняются без кэширования.
На приведенном ниже графике тестирование показывает, что обычный том Azure NetApp Files может обрабатываться примерно от 3500MiB/с чистой последовательной записи 256-KiB и приблизительно 2500МиБ/с чистой последовательной записи 256-KiB. Во время тестов 50/50 смесь показала, что общая пропускная способность достигла максимума выше чистой последовательной рабочей нагрузки чтения.
Набор операций чтения и записи для рабочей нагрузки был скорректирован на 25 % приращения для каждого запуска.
Параллельное сравнение
Чтобы лучше показать, как кэширование может повлиять на тесты производительности, на следующем графике показан общий объем МиБ/с для 64-КиБ-тестов с механизмами кэширования и без нее. Кэширование обеспечивает начальное небольшое повышение производительности для общего объема MiB/s, так как кэширование обычно улучшает чтение больше, чем записи. По мере изменения набора операций чтения и записи общая пропускная способность без кэширования превышает результаты, использующие кэширование клиента.
Параллельные сетевые подключения (nconnect)
В следующих тестах показан высокий тест ввода-вывода с использованием одного клиента с 64-КиБ случайными рабочими нагрузками и набором данных 1 ТиБ. Сочетание рабочих нагрузок, созданное каждый раз, использует другую глубину ввода-вывода. Чтобы повысить производительность для одной клиентской рабочей нагрузки, nconnect параметр подключения использовался для улучшения параллелизма по сравнению с подключениями клиентов, которые не использовали nconnect параметр подключения. Эти тесты выполнялись только с исключением кэширования.
Результаты: 64 КиБ, последовательное кэширование, исключенное, без и без nconnect
В следующих результатах показаны результаты теста масштабирования при чтении и написании фрагментов 4-KiB на подключении NFSv3 на одном клиенте и без параллелизации операций (nconnect). Графики показывают, что по мере увеличения глубины ввода-вывода также увеличивается число операций ввода-вывода. Но при использовании стандартного TCP-подключения, предоставляющего только один путь к хранилищу, меньше общих операций отправляются в секунду, чем при использовании подключения больше TCP-подключений на точку подключения. Кроме того, общая задержка операций обычно ниже при использовании nconnect.
Параллельное сравнение (с и без)nconnect
На следующих графиках показано параллельное сравнение 64-KiB последовательных операций чтения и записи без nconnect выделения улучшений производительности при использовании nconnect: более высокая общая пропускная способность, низкая задержка.
