Параметры подключения и конфигурации виртуальной машины клиента

Завершено

В этом модуле мы обсудим параметры подключения и конфигурации клиентских виртуальных машин, которые повышают производительность при запуске приложений HPC или EDA в Azure NetApp Files.

Заметка

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

Используйте параметры подключения actimeo и nocto для повышения производительности

Для повышения производительности относительно статических наборов данных и сценариев массового чтения можно использовать следующие параметры подключения:

• actimeo: управляет атрибутами кэша клиента NFS каталога. Если он не указан, клиент NFS использует максимум 60 секунд по умолчанию.
• nocto: означает "нет ожидания открытия при закрытии", что значит, файл может закрываться до завершения записи, чтобы сэкономить время. По умолчанию nocto не задан в параметрах монтирования NFS. Это означает, что все файлы дожидаются завершения записи, прежде чем их можно будет закрыть.

Большинство приложений HPC, включая EDA в нашем сценарии, имеют относительно статические наборы данных (то есть данные часто не изменяются). В этом случае можно использовать nocto и actimeo для уменьшения getattr или доступа к хранилищу, что может помочь ускорить работу приложения.

Например, рекомендуется задать "nocto,actimeo=600" (600 секунд или 10 минут) для средств автоматизированного проектирования и томов библиотеки. Так как эти файлы не изменяются, поддерживать когерентность кэша не требуется. Установка этих параметров подключения уменьшает вызовы метаданных, что повышает общую производительность.

Настройка системных параметров для оптимальной производительности

Tuned — это управляющая программа, которую можно использовать для мониторинга и настройки подключенных устройств на клиентах Linux. В большинстве случаев tuned устанавливается по умолчанию. Если он не установлен, его можно добавить и включить, чтобы упростить параметры настройки на стороне клиента с помощью встроенных шаблонов по умолчанию.

Выполните следующие команды, чтобы применить базовую настройку сервера и типичную настройку задержки для виртуальных машин клиента:

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

Некоторые или все перечисленные ниже системные параметры (/etc/sysctl.conf) могут оказаться полезными на клиентских виртуальных машинах Linux для оптимальной производительности. Если у вас есть клиентские виртуальные машины с огромным объемом ОЗУ или более высокой пропускной способностью сети, например InfiniBand, может потребоваться задать некоторые значения даже выше, чем показано в следующем примере.

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Чтобы сделать эти настройки постоянными, выполните следующую команду:

sudo sysctl -P

Используйте параметр подключения nconnect, чтобы расширить сетевые соединения при необходимости.

Параметр подключения nconnect NFS ввел общую доступность в ядре Linux 5.3 или более поздней версии. Чтобы проверить ядро Linux клиентской виртуальной машины, выполните следующую команду:

uname -r

Целью nconnect является предоставление нескольких транспортных подключений для каждого tcp-подключения или точек подключения на клиенте. Этот метод помогает повысить параллелизм и производительность монтирований NFS.

Чем меньше число клиентов, тем большую ценность предоставляет nconnect в повышении производительности, так как он потенциально может использовать всю доступную пропускную способность сети. Его значение постепенно уменьшается, когда увеличивается число клиентов; существует только определенная пропускная способность в общем, и доступное максимальное количество TCP-подключений может быть исчерпано быстрее, что может привести к отказу в предоставлении услуг до освобождения TCP-подключений.

Так как Azure NetApp Files разрешает не более 128 одновременных запросов в полете для каждого tcp-подключения до возникновения ограничения (где новые запросы помещаются в очередь до тех пор, пока ресурсы не будут доступны), nconnect может помочь расширить количество запросов на полет, разрешенных путем увеличения количества доступных TCP-подключений на точку подключения. Например, если для nconnect задано использование восьми TCP-подключений, то для клиента потенциально доступны 1024 (8x128) запросов.

Современные клиенты Linux позволяют выполнять до 65 535 запросов на подключение (динамическое значение). Это может привести к переполнению доступной входящей очереди запросов тома Azure NetApp Files и, как следствие, к нежелательным результатам производительности, когда клиенты отправляют больше запросов, чем можно обработать в определенное время. Чтобы снизить риск влияния на производительность из-за этого поведения, рекомендуется задать sunrpc.tpc_max_slot_table_entries=256 или 512, если вы используете nconnect=8 или 16 для более низкого статического значения. Используйте следующую таблицу в качестве руководства.

Заметка

Разные типы клиентских ОС Linux могут иметь различные методы, чтобы задать это значение. Дополнительные сведения см. в документации по ОС.

значение nconnect	Рекомендуемое количество записей в таблице распределения слотов TCP.
0-1	128
2-4	256
6-8	512
>8	Изменение не требуется

Заметка

Параметр nconnect доступен только для виртуальных машин ядра Linux 5.3 и более поздних версий. При обновлении ядра может потребоваться перезапустить виртуальную машину. Это означает, что это может быть неприменимо для некоторых случаев.

Использование NFSv3 вместо NFSv4.1 при рассмотрении только производительности

NFSv3 — это протокол без состояния, что означает, что клиент и сервер не взаимодействуют друг с другом по поводу используемых файлов. Блокировка выполняется за пределами стека протоколов диспетчером сетевой блокировки (NLM), что приводит к некоторым проблемам, когда блокировки становятся устаревшими и должны быть удалены вручную. Блокировки устанавливаются только по запросу приложения, поэтому могут возникнуть сценарии, в которых блокировки не нужно согласовывать. Поскольку нет необходимости отслеживать идентификаторы клиентов, идентификаторы состояний, идентификаторы сеансов, состояния блокировки и т. д., NFSv3, как правило, работает немного лучше, чем NFSv4.1 в некоторых рабочих нагрузках, особенно в нагрузках с большим количеством файлов и высоким содержанием метаданных, таких как EDA и разработка программного обеспечения.

NFSv4.1 отслеживает состояния файлов, включая блокировки. При одновременном использовании нескольких файлов в NFSv4.1 каждый файл получает идентификатор состояния и получает блокировку. Сохранение состояния увеличивает нагрузку на производительность рабочей нагрузки, так как каждое состояние и блокировка должны обрабатываться сервером NFS. В некоторых рабочих нагрузках (например, EDA) производительность NFSv4.1 может снижаться на 25% до 75%. Другие рабочие нагрузки, такие как большие файлы, потоковые операции ввода-вывода или базы данных, не видят снижения производительности при использовании NFSv4.1 и могут даже воспользоваться составными операциями, используемыми протоколом.

Azure NetApp Files поддерживает как NFSv3, так и NFSv4.1. Необходимо проверить, какую версию требует ваше приложение, сравнив сходства и различия между версиями NFS, а также проведя тестирование, и создавая том с использованием наиболее подходящей версии. При необходимости тома Azure NetApp Files можно настроить для другой версии протокола после создания.

Выберите правильные значения для монтажных параметров rsize и wsize

Параметры подключения rsize (размер чтения) и wsize (размер записи) определяют, сколько данных отправляется между клиентом NFS и сервером для каждого отправленного пакета. Например, при настройке rsize или wsize значение 65 536 означает, что на каждый пакет можно отправлять до 64 K данных. Если приложение отправляет данные в небольших блоках (например, 8 K), объем отправленных данных зависит от используемых параметров подключения (например, sync).

Для Azure NetApp Files рекомендуется задать rsize и wsize одинаковое значение. Как правило, рекомендуется задать значения rsize и wsize как 262144 (256 K) в параметрах подключения.

Общие сведения о параметрах синхронизации и асинхронного подключения

Если используется sync, то каждый вызов WRITE отправляется с помощью команды FILE_SYNC. Это означает, что каждая запись должна быть подтверждена сервером и зафиксирована на диске перед тем, как может произойти следующая WRITE. Sync используется, если приложение должно гарантировать, что все данные фиксируется на диске. WRITE вызовы отправляют только объем данных, указанных размером блока приложения, что означает, что меньшие размеры блоков создают больше трафика NFS независимо от wsize и rsize значений подключения, что приводит к снижению производительности.

При использовании операции подключения async (по умолчанию) клиент может отправлять несколько вызовов WRITE через NFS с помощью команды UNSTABLE. В этом сценарии данные сбрасываются на диск после периода ожидания. Так как клиент NFS не всегда ожидает фиксации данных на диске перед началом следующей записи, время завершения задания для асинхронных подключений гораздо ниже, чем при синхронизации. При использовании меньших размеров блоков с большими значениями rsize и wsize вызовы WRITE отправляют столько данных, сколько разрешено в одном вызове NFS. Например, если размер блока 8 K используется с 64 K wsize/rsize, то каждый вызов записи NFS отправляет восемь блоков на пакет (64 K/8 K). При сбросе записи на диск сервер NFS отправляет FILE_SYNC ответ обратно клиенту NFS. Это сокращает общее количество WRITE звонков и ответов по сети, необходимых для выполнения задания, что повышает производительность.

Например, в тесте, в котором был создан файл объемом 1 ГиБ с использованием размера блока 8 K, было сгенерировано 262 144 вызова и ответа WRITE и тест завершился за 70 секунд при использовании параметра монтажа sync. То же создание файла с использованием размера блока 8 K и опции монтирования async отправило только 16 384 записывающих вызова и ответа, завершив выполнение за шесть секунд.

Azure NetApp Files использует хранилище NVRAM с резервным питанием от батареи в качестве буферного кэша для входящих записей NFS. Данные в NVRAM сбрасываются на диск каждые 10 секунд или пока кэш буфера не заполняется (независимо от того, что происходит первым). Так как NVRAM работает от батареи, она может выдержать непредвиденный сбой как минимум 72 часа, сохраняя данные, например, в маловероятном случае отключения электроэнергии в серверном центре Azure. Сочетание устойчивости данных Azure NetApp Files и влияния на производительность использования опции монтирования sync делает асинхронный режим предпочтительным выбором почти во всех сценариях использования.

Общие сведения о влиянии значений wsize и rsize

При подключении через NFS значения wsize и rsize определяют, сколько данных можно отправлять за один вызов серверу NFS. Если параметр подключения не указан, значения устанавливаются в соответствии с настройками сервера NFS. Azure NetApp Files использует максимальный размер передачи для wsize и rsize 1 МБ (1048576). Это значение нельзя изменить в Azure NetApp Files. Это означает, что если подключения NFS не указывают значения wsize и rsize, подключения по умолчанию устанавливаются на 1 МБ. Рекомендуемые значения wsize и rsize для подключений NFS в рабочих нагрузках EDA — 256 К.

Если приложению необходимо создать 1-ГиБ-файл на подключении Azure NetApp Files NFS, необходимо записать в хранилище 1048 576 КиБ. Математическое упражнение может показать, почему производительность может улучшиться с более эффективными wsize или rsize значениями.

• Если для wsize задано значение 64 K, то количество операций и пакетов, необходимых для записи 1-ГиБ-файла, равно 1048576/64=16384.
• Если для wsize задано значение 256 K, количество операций и пакетов, необходимых для записи 1-ГиБ-файла, равно 1048576/256=4096.

Меньше пакетов и операций означает задержку сети (что влияет на RTT) меньше влияния на рабочие нагрузки, которые могут быть критически важными в облачных развертываниях. Однако если приложение записывает файлы, которые меньше значений wsize/rsize, то более крупные wsize/rsize значения не влияют на производительность.

Большие блоки данных означают больше циклов обработки на клиенте и сервере, но большинство современных ЦП достаточно оснащены для эффективной обработки этих запросов.

Для Azure NetApp Files рекомендуется задать rsize и wsize одинаковое значение. Рекомендуется задать значения rsize и wsize равными 262144 (256 КБ) в параметрах монтирования. Этот параметр охватывает массив значений размера приложения для чтения и записи.

Выберите правильные параметры для жесткого, мягкого и intr монтирования.

Параметры подключения hard и soft указывают, должна ли программа, использующая файл, использующий NFS, выполнить одно из следующих действий:

• Остановите и подождите (hard), чтобы сервер вернулся в интернет, если сервер NFS недоступен. Этот параметр отображается как подключение висит на клиенте, но гарантирует, что операции в полете не теряются в случае сбоя сети. Вместо этого клиент продолжает повторять запрос до тех пор, пока сервер не будет доступен или не истекает время ожидания приложения.
• Сообщите об ошибке (soft). Подключения не зависают, но операции во время полета могут быть потеряны.

Параметр подключения intr позволяет процессам NFS прерываться, когда подключение указано как подключение hard (например, CTRL+C). Мы рекомендуем использовать intr с креплениями hard при возможности для оптимальной комбинации надежности данных и управляемости.

Рассмотрите возможность не менять MTU

Максимальный объем единиц передачи по умолчанию для виртуальных машин Azure составляет 1500 байт. Мы не рекомендуем клиентам увеличивать MTU виртуальных машин для кадров большого размера.

Пример монтажа

В следующем примере кода подключается том Azure NetApp Files с использованием предыдущих рекомендаций для actimeo, nocto, NFSv3, nconnect, rsize, wsize, hard, intr, tcpи стандартных значений MTU (1,500):

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol

Заметка

Async не указано, так как NFS подключается по умолчанию к async.