Повышение производительности общих папок Azure NFS

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

Применяется к

Тип общей папки	SMB	Система сетевых файлов (NFS)
Стандартные общие папки (GPv2), LRS/ZRS
Стандартные общие папки (GPv2), GRS/GZRS
Премиум файловые ресурсы (FileStorage), LRS/ZRS	Нет, эта статья не относится к файловым ресурсам Azure SMB премиум-класса.

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

Параметр read_ahead_kb ядра в Linux представляет объем данных, которые должны быть "прочитаны заранее" или предварительно возвращены во время последовательной операции чтения. Версии ядра Linux до 5.4 устанавливают значение предварительного чтения, эквивалентное 15-кратному объему подключенной файловой системы rsize, что соответствует параметру монтирования на стороне клиента для размера буфера чтения. Это задает достаточно высокое значение упреждающего чтения, чтобы повысить пропускную способность клиента при последовательном чтении в большинстве случаев.

Однако начиная с ядра Linux версии 5.4 клиент Linux NFS использует значение по умолчанию read_ahead_kb 128 КиБ. Это небольшое значение может уменьшить объем пропускной способности чтения для больших файлов. Клиенты, которые обновляют версии Linux с большим значением предвыборочного чтения до версий с 128 КиБ по умолчанию, могут обнаружить снижение производительности при последовательном чтении.

Для ядер Linux версии 5.4 или более поздней версии рекомендуется постоянно устанавливать read_ahead_kb значение 15 МиБ для повышения производительности.

Чтобы изменить это значение, установите размер предзагрузки, добавив правило в udev, диспетчере устройств ядра Linux. Выполните следующие действия:

1. В текстовом редакторе создайте файл /etc/udev/rules.d/99-nfs.rules , введя и сохраняя следующий текст:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. В консоли примените правило udev, выполнив команду udevadm в качестве суперпользователя и перезагрузив файлы правил и другие базы данных. Эту команду необходимо выполнить только один раз, чтобы udev знал о новом файле.

   sudo udevadm control --reload
   

Nconnect

Nconnect — это параметр подключения Linux на стороне клиента, который повышает производительность в масштабе, позволяя использовать дополнительные подключения протокола TCP между клиентом и службой файлов Azure Premium для NFSv4.1.

Преимущества nconnect

С помощью nconnectэтого можно увеличить производительность в масштабе, используя меньше клиентских компьютеров, чтобы снизить общую стоимость владения (TCO). Nconnect увеличивает производительность за счёт использования нескольких TCP-каналов на одном или нескольких сетевых адаптерах и с помощью одного или нескольких клиентов. Без nconnect этого вам потребуется примерно 20 клиентских компьютеров для достижения максимальной пропускной способности (10 ГиБ/с), предлагаемой наибольшим объемом выделенного азурного файлового ресурса уровня "Премиум". С помощью nconnect вы можете достичь этих пределов, используя всего 6-7 клиентов, что снижает затраты на вычисления почти на 70 %, обеспечивая при этом значительные улучшения операций ввода-вывода в секунду (IOPS) и пропускной способности в масштабе. См. следующую таблицу.

Предварительные требования

• Последние дистрибутивы Linux полностью поддерживают nconnect. Для старых дистрибутивов Linux убедитесь, что версия ядра Linux — 5.3 или более поздняя.
• Конфигурация подключения для каждого монтирования поддерживается только в том случае, если общий доступ к файлам используется в каждой учетной записи хранения через приватную конечную точку.

Влияние на производительность nconnect

Мы достигли следующих результатов производительности при использовании nconnect параметра монтирования с общими папками NFS Azure на масштабируемых клиентах Linux. Дополнительные сведения о том, как мы достигли этих результатов, см. в разделе настройки теста производительности.

Рекомендации для nconnect

Следуйте этим рекомендациям, чтобы получить наилучшие результаты.nconnect

Задайте значение nconnect=4.

Хотя Файлы Azure поддерживают nconnect настройку до максимального значения 16, рекомендуется настроить параметры подключения с оптимальным параметром nconnect=4. В настоящее время для реализации Azure Files нет результатов, превышающих nconnect четыре канала. На самом деле превышение четырех каналов к одной общей папке Azure из одного клиента может негативно повлиять на производительность из-за насыщенности сети TCP.

Внимательно выбирайте размер виртуальных машин

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

Держите глубину очереди не больше 64.

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

Nconnect Конфигурация для каждой точки монтирования

Если для рабочей нагрузки требуется подключение нескольких томов к одной или нескольким учетным записям хранения с разными nconnect параметрами с одного клиента, мы не можем гарантировать, что эти параметры будут сохраняться при подключении через общедоступную конечную точку. Конфигурация на уровне монтирования поддерживается только в том случае, если один файлoвый ресурс Azure используется в учетной записи хранения через частную точку доступа, как описано в сценарии 1.

Сценарий 1. nconnect Конфигурация подключения через частную конечную точку с несколькими учетными записями хранения (поддерживается)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Сценарий 2. nconnect Конфигурация подключения через общедоступную конечную точку (не поддерживается)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Сценарий 3. nconnect Конфигурация подключения через частную конечную точку с несколькими общими папками в одной учетной записи хранения (не поддерживается)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Конфигурация для теста производительности

Мы использовали следующие ресурсы и средства тестирования для достижения и измерения результатов, описанных в этой статье.

• Один клиент: виртуальная машина Azure (DSv4-Series) с одним сетевым адаптером
• ОС: Linux (Ubuntu 20.40)
• Хранилище NFS: Общий файловый ресурс Azure класса Premium (выделено 30 ТиБ, комплект nconnect=4)

Инструменты и тесты для бенчмаркинга

Мы использовали гибкий средство тестирования ввода-вывода (FIO), бесплатное средство ввода-вывода с открытым исходным кодом, используемое как для проверки производительности, так и для проверки нагрузки и оборудования. Чтобы установить FIO, следуйте разделу "Двоичные пакеты" в файле FIO README, чтобы установить для выбранной платформы.

Хотя эти тесты сосредоточены на случайных шаблонах доступа ввода-вывода, вы получаете аналогичные результаты при использовании последовательного ввода-вывода.

Высокий уровень операций ввода-вывода в секунду: 100 % операций чтения

Размер ввода-вывода 4k — случайное чтение — глубина очереди 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Размер ввода-вывода 8k — случайное чтение — глубина очереди 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Высокая пропускная способность: 100 % операций чтения

Размер ввода-вывода 64k — случайное чтение — глубина очереди 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Размер ввода-вывода 1024k — 100 % случайного чтения — глубина очереди 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Высокий IOPS: 100% операций записи

Размер ввода-вывода 4k — 100 % случайных записей — глубина очереди 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Размер ввода-вывода 8k — 100 % произвольной записи — глубина очереди 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Высокая пропускная способность: 100 % операций записи

Размер в/в 64k — 100% случайной записи — глубина очереди 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Размер ввода-вывода 1024k — со 100 % случайной записью — глубина очереди 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Рекомендации по производительности nconnect

При использовании nconnect параметра подключения следует внимательно оценивать рабочие нагрузки, имеющие следующие характеристики:

• Записывающие рабочие нагрузки, чувствительные к задержкам, которые выполняются в одном потоке и/или используют небольшую глубину очереди (менее 16)
• Чувствительные к задержкам нагрузки на чтение, которые являются одно-поточными и/или используют низкую глубину очереди в сочетании с маленькими размерами операций ввода-вывода.

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

См. также

• Подключение файловой системы NFS к Linux
• Список параметров подключения
• Понимание производительности Azure Files