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

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

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

Модель управления	Модель выставления счетов	Уровень медиа	Избыточность	Малый и средний бизнес (SMB)	Система сетевых файлов (NFS)
Microsoft.Storage	Настроенная версия 2	SSD (премиум)	Локальное (LRS)
Microsoft.Storage	Настроенная версия 2	SSD (премиум)	Зона (ZRS)
Microsoft.Storage	Настроенная версия 2	HDD (стандартный)	Локальное (LRS)
Microsoft.Storage	Настроенная версия 2	HDD (стандартный)	Зона (ZRS)
Microsoft.Storage	Настроенная версия 2	HDD (стандартный)	Гео (GRS)
Microsoft.Storage	Настроенная версия 2	HDD (стандартный)	GeoZone (GZRS)
Microsoft.Storage	Настроенная версия v1	SSD (премиум)	Локальное (LRS)
Microsoft.Storage	Настроенная версия v1	SSD (премиум)	Зона (ZRS)
Microsoft.Storage	Оплата по мере использования	HDD (стандартный)	Локальное (LRS)
Microsoft.Storage	Оплата по мере использования	HDD (стандартный)	Зона (ZRS)
Microsoft.Storage	Оплата по мере использования	HDD (стандартный)	Гео (GRS)
Microsoft.Storage	Оплата по мере использования	HDD (стандартный)	GeoZone (GZRS)

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

Параметр 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 NFS

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

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

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

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

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

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

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

Рекомендации

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

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

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

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

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

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

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

Конфигурация точки монтирования

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

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

• 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. Конфигурация подключения через общедоступную конечную точку (не поддерживается)

• 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. Конфигурация подключения через частную конечную точку с несколькими общими ресурсами в одной учетной записи хранения (не поддерживается)

• 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: Общий файловый ресурс SSD (подготовленный 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 % операций чтения

Размер ввода-вывода 64 КиБ — случайное чтение — глубина очереди 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

Размер ввода-вывода 1024 КиБ - 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% операций записи

Размер I/O 4 КиБ — 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

Размер ввода-вывода 8 КиБ — 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 % операций записи

Размер ввода-вывода 64 КиБ — 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

Размер ввода-вывода 1024 KiB — 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