Рекомендации по параметрам подключения NFS для Linux для Azure NetApp Files

  • Статья

Эта статья поможет изучить параметры подключения и рекомендации по их использованию с Azure NetApp Files.

Nconnect

С помощью параметра подключения nconnect можно указать число подключений (сетевых потоков), которые должны быть установлены между клиентом NFS и конечной точкой NFS. Можно настроить до 16 подключений. Обычно клиент NFS использует одно подключение между самим собой и конечной точкой. Увеличив число сетевых потоков, вы значительно увеличите максимальные значения числа операций ввода-вывода и пропускной способности. Тестирование показало, что значение nconnect=8 обеспечивает наибольшую производительность.

При подготовке среды сетки SAS с несколькими узлами в рабочей среде вы можете заметить повторяющееся сокращение времени выполнения на 30 % (5,5 часов вместо 8 часов).

Параметры подключения Время выполнения заданий
Без nconnect 8 часов
nconnect=8 5,5 часа

Оба набора тестов использовали одну и ту же виртуальную машину E32-8_v4 с RHEL 8.3, на которой настроен буфер упреждающего чтения в 15 МиБ.

При использовании nconnect необходимо учитывать следующие правила.

  • nconnect поддерживается Azure NetApp Files во всех основных дистрибутивах Linux, но только в более новых выпусках.

    Выпуск Linux NFS версии 3 (минимальный выпуск) NFS версии 4.1 (минимальный выпуск)
    Red Hat Enterprise Linux RHEL 8.3 RHEL 8.3
    SUSE SLES 12 SP4 или SLES 15 SP1 SLES 15 SP2
    Ubuntu Ubuntu 18.04

    Примечание.

    SLES 15 SP2 — это минимальный выпуск SUSE, в котором поддерживается nconnect для Azure NetApp Files для NFS версии 4.1. Все остальные выпуски, которые были указаны, являются первыми выпусками, в которых появилась функция nconnect.

  • Все подключения из одной конечной точки будут наследовать параметр nconnect первого подключенного экспорта, как показано в следующих сценариях.

    Сценарий 1. Параметр nconnect используется при первом подключении. Следовательно, все подключения к одной и той же конечной точке используют nconnect=8.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    Сценарий 2. Параметр nconnect не используется при первом подключении. Следовательно, подключения к одной и той же конечной точке не используют nconnect, даже если потом будет указан параметр nconnect.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    Сценарий 3. Параметры nconnect не распространяются между отдельными конечными точками службы хранилища. Параметр nconnect используется подключением с 10.10.10.10, но не используется подключением с 10.12.12.12.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • Параметр nconnect может использоваться для увеличения параллелизма службы хранилища из любого заданного клиента.

Дополнительные сведения см. в разделе Рекомендации по параллелизму Linux для Azure NetApp Files.

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

Не рекомендуется использовать и sec=krb5* подключать nconnect параметры вместе. Снижение производительности наблюдалось при использовании двух вариантов в сочетании.

Универсальный интерфейс программирования приложений уровня безопасности (GSS-API) позволяет приложениям защищать данные, отправленные одноранговым приложениям. Эти данные могут быть отправлены от клиента на одном компьютере на сервер на другом компьютере. 

При nconnect использовании в Linux контекст безопасности GSS используется между всеми nconnect подключениями к конкретному серверу. TCP — это надежный транспорт, который поддерживает доставку пакетов вне порядка для работы с пакетами вне порядка в потоке GSS, используя скользящее окно порядковых номеров. При получении пакетов, не входящих в окно последовательности, контекст безопасности отключен карта и согласовывается новый контекст безопасности. Все сообщения, отправляемые в контексте", отправляемые в настоящее время карта, больше не являются допустимыми, что требует повторного отправки сообщений. Большее количество пакетов в nconnect установке приводит к частому выходу из окна пакетов, вызывая описанное поведение. С этим поведением не можно указать конкретные проценты снижения.

Rsize и Wsize.

Примеры в этом разделе содержат сведения о том, как подходить к настройке производительности. Возможно, потребуется внести корректировки в соответствии с конкретными потребностями приложения.

Флаги rsize и wsize задают максимальный размер перемещаемых данных для операции NFS. Если при подключении не указан флаг rsize или wsize, то клиент и сервер согласовывают максимальный размер, поддерживаемый ими. В настоящее время Azure NetApp Files и современные дистрибутивы Linux поддерживают размер данных для чтения и записи до 1048 576 байтов (1 МиБ). Однако для обеспечения наилучшей общей пропускной способности и задержки Azure NetApp Files рекомендует устанавливать с помощью rsize и wsize не более 262 144 байтов (256 КиБ). Вы можете заметить увеличение задержки и снижение пропускной способности при использовании rsize и wsize со значением больше 256 КиБ.

Например, развертывание горизонтально масштабируемой системы SAP HANA с резервным узлом на виртуальных машинах Azure с помощью Azure NetApp Files в SUSE Linux Enterprise Server использует rsize и wsize с максимальным значением в 256 КиБ.

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

Например, SAS Viya рекомендует 256-КиБ считывать и записывать размеры, а SAS GRID ограничивает r/wsize до 64 КИБ при увеличении производительности чтения с увеличением производительности чтения с повышенным числом операций чтения для подключений NFS. См. рекомендации по упреждающему чтению NFS для Azure NetApp Files.

Ниже приведены аспекты использования rsize и wsize.

  • Размер данных в случайных операциях ввода-вывода часто меньше, чем значение параметров подключения rsize и wsize. Следовательно, в действительности они не будут ограничены.
  • При использовании кэша файловой системы последовательный ввод-вывод выполняется с использованием размера, указанного в параметрах подключения rsize и wsize, если только размер файла не значения rsize и wsize.
  • Операции, обходящие кэш файловой системы, хотя и ограничены параметрами подключения rsize и wsize, не обязательно будут оперировать максимальным объемом, указанным в параметре rsize или wsize. Это важно знать при использовании генераторов рабочей нагрузки с параметром directio.

Для повышения общей пропускной способности и снижения задержки Azure NetApp Files рекомендуется задавать для параметров rsize и wsize значения, не превышающие 262 144 байтов.

Согласованность "близко к открытому" и таймеры атрибутов кэша

NFS использует нестрогую модель согласованности. Согласованность нестрогая, так как приложению не нужно обращаться к общему хранилищу и получать данные каждый раз, когда их нужно использовать. Такой сценарий оказывает значительное влияние на производительность приложения. Существуют два механизма управления этим процессом: таймеры атрибутов кэша и согласованность "близко к открытому".

Если клиент полностью владеет данными, то есть они не используются совместно в нескольких узлах или системах, то согласованность гарантируется. В этом случае можно уменьшить количество операций доступа getattr к хранилищу и ускорить работу приложения, отключив согласованность "близко к открытому" (cto) (с параметром подключения nocto) и установив время ожидания для управления кэшем атрибута (параметр подключения actimeo=600 изменяет значение таймера на 10 мин по сравнению со значениями по умолчанию acregmin=3,acregmax=30,acdirmin=30,acdirmax=60). В некоторых тестах nocto демонстрирует сокращение числа вызовов для получения доступа getattr на 65–70 %, а настройка actimeo сокращает количество вызовов еще на 20–25 %.

Как работают таймеры кэша атрибутов

Атрибуты acregmin, acregmax, acdirmin и acdirmax управляют согласованностью кэша. Первые два атрибута определяют, как долго атрибуты файлов являются доверенными. Следующие два атрибута определяют, как долго атрибуты каталога файлов являются доверенными (размер каталога, владельцы каталога, разрешения каталога). Атрибуты min и max определяют минимальный и максимальный сроки, в течении которых атрибуты каталога, атрибуты файла и содержимое кэша для файла считаются доверенными. На интервале от min до max используется алгоритм для определения интервала времени, в течение которого кэшированная запись является доверенной.

Например, рассмотрим значения по умолчанию acregmin и acregmax — 3 и 30 секунд соответственно. Например, атрибуты многократно оцениваются для файлов в каталоге. Через 3 секунды служба NFS запрашивает актуальность. Если атрибуты считаются допустимыми, клиент удваивает время доверия до 6, 12 и 24 секунд, а затем — до максимального значения в 30 секунд. С этого момента, пока кэшированные атрибуты не перестанут быть актуальными (в момент начала цикла), срок доверия определяется как значение, заданное параметром acregmax, то есть 30 секунд.

Существуют и другие случаи, которые могут воспользоваться аналогичным набором параметров подключения, даже если нет полного владения клиентами, например, если клиенты используют данные только для чтения, а обновление данных управляется другим путем. Для приложений, использующих сетки таких клиентов, как EDA, службы размещения веб-узлов и службы рендеринга видеороликов, и использующих относительно статические наборы данных (инструменты или библиотеки EDA, веб-содержимое, данные текстур), набор данных в основном кэшируется на клиентах. Существует несколько операций чтения и без операций записи. Кроме того, будет выполняться мало вызовов для доступа getattr к хранилищу. Обычно эти наборы данных обновляются с помощью другого клиента, который подключает файловые системы и периодически отправляет обновления содержимого.

В таких случаях существует известная задержка при выборе нового содержимого, и приложение по-прежнему работает с потенциально устаревшими данными. В этих случаях параметры nocto и actimeo можно использовать для управления периодом для обработки неактуальных данных. Например, в инструментах и библиотеках EDA параметр actimeo=600 работает эффективно, так как эти данные обычно обновляются редко. Для небольшого веб-размещения, где клиенты должны своевременно просматривать обновления данных, так как они редактируют свои сайты, actimeo=10 могут быть приемлемыми. Для крупномасштабных веб-сайтов, где содержимое, отправленное в несколько файловых систем, actimeo=60 может быть приемлемым.

Использование этих параметров подключения значительно сокращает рабочую нагрузку на хранилище в таких случаях. (Например, недавний интерфейс EDA сокращает количество операций ввода-вывода в секунду до >150 K до ~6 K.) Приложения могут работать значительно быстрее, так как они могут доверять данным в памяти. (Время доступа к памяти исчисляется наносекундами, а не сотнями микросекунд для операций доступа getattr в быстрой сети).

Согласованность "близко к открытому"

Согласованность "близко к открытому" (параметр подключения cto) гарантирует, что, вне зависимости от состояния кэша, при открытии файла приложению будут представлены самые последние данные для него.

  • При обходе каталога (например, ls -l определенный набор RPCs (lsудаленные вызовы процедур) выдаются.
    Сервер NFS предоставляет представление файловой системы. Если параметр cto используется всеми клиентами NFS, обращающимися к заданному экспорту NFS, то все клиенты будут видеть один и тот же список файлов и каталогов. Актуальность атрибутов файлов в каталоге контролируется с помощью таймеров кэша атрибутов. Другими словами, если используется cto, файлы отображаются на удаленных клиентах сразу после создания файла и его передачи в хранилище.
  • При открытии файла его содержимое гарантированно актуально с точки зрения сервера NFS.
    Если есть состояние гонки, в котором содержимое не завершило очистку с компьютера 1 при открытии файла на компьютере 2, компьютер 2 будет получать только данные, присутствующих на сервере во время открытия. В этом случае компьютер 2 не получит больше данных из файла, пока не истечет таймер acreg, после чего компьютер 2 снова проверит согласованность кэша с сервера. Этот сценарий можно наблюдать с помощью заключительного параметра -f с компьютера 2, когда файл еще записывается с компьютера 1.

Согласованность, отличная от режима "близко к открытому"

Если не используется согласованность "близко к открытому" (nocto), клиент будет доверять актуальности своего текущего представления файлов и каталогов до тех пор, пока не будут превышены таймеры атрибутов кэша.

  • При обходе каталога (например, ls -l определенный набор RPCs (lsудаленные вызовы процедур) выдаются.
    Клиент будет отправлять вызов на сервер для получения текущего списка файлов, только когда значение таймера кэша acdir будет превышено. В этом случае недавно созданные файлы и каталоги не будут отображаться, а недавно удаленные файлы и каталоги по-прежнему будут отображаться.

  • Если при открытии файла он все еще находится в кэше, его кэшированное содержимое (если таковое имеется) возвращается без проверки согласованности с сервером NFS.

Следующие шаги