Бөлісу құралы:

Рекомендации по параметрам подключения 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вызовов /access, возвращающегося в хранилище. Обычно эти наборы данных обновляются с помощью другого клиента, который подключает файловые системы и периодически отправляет обновления содержимого.

В таких случаях существует известная задержка при выборе нового содержимого, и приложение по-прежнему работает с потенциально устаревшими данными. В этих случаях параметры 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.

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