Поделиться через

Рекомендации по параметрам подключения 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 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

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

Универсальный интерфейс программирования приложений уровня безопасности (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 к хранилищу и ускорить работу приложения, отключив согласованность "close-to-open" (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, — до 30 секунд. С этого момента, пока кэшированные атрибуты не перестанут быть актуальными (в момент начала цикла), срок доверия определяется как значение, заданное параметром acregmax, то есть 30 секунд.

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

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

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

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

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

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

Нет согласованности "закрыто до открыто"

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

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

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

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

  • Last updated on