Рассмотрим рабочую среду с коммутаторами типа Infiniband со скоростью 100 Гбит/с, работающими на серверах корпоративного класса с объемом ОЗУ 512 ГБ и более, с операционной системой RHEL 8.7 или близкой к ней.

При настройке NFS между серверами, является ли последняя версия NFS vers=4.2 наилучшим выбором? Есть ли какие-либо причины, по которым использование NFSv3 с proto=UDP когда-либо лучше, чем NFS vers=4.2 с proto=tcp/udp/rdma?

Меня особенно интересует это в отношении многих узлов кластера, монтирующих папку /data с головного узла для чтения/записи; какой логический выбор NFS если целью является производительность?

Я нашел это, датированное 2008 годом, что, предположительно, относится к версии 4.0, а не 4.2, где говорится, что нет явного преимущества в производительности при переходе с NFSv3 на NFSv4.

https://www.linux.com/news/benchmarking-nfsv3-vs-nfsv4-file-operation-performance/

также

https://www.techtarget.com/searchenterprisedesktop/definition/Network-File-System

Некоторые обзоры NFSv4 и NFSv4.1 предполагают, что эти версии имеют ограниченную пропускную способность и масштабируемость, и что NFS замедляется в условиях интенсивного сетевого трафика. Проблема с пропускной способностью и масштабируемостью, как сообщается, была улучшена в NFSv4.2. Это было обновлено в апреле 2022 года

Для такого быстрого оборудования, вероятно, стоит использовать многопутевой NFS поверх RDMA или NFS через TCP с несколькими соединениями (nconnect=).

Согласно nfs(5), это плохая идея использовать NFSv3 на высокоскоростных каналах.

Следующий текст был добавлен в руководство в мае 2012 года.

Методы транспорта

Использование NFS поверх UDP на высокоскоростных каналах

Использование NFS поверх UDP на высокоскоростных каналах, таких как гигабитный Ethernet, может привести к тихой порче данных.

Проблема может возникнуть при высоких нагрузках и вызвана проблемами при сборке IP-фрагментов. Чтение и запись NFS обычно передают UDP-пакеты размером 4 килобайт и более, которые должны быть разбиты на несколько фрагментов для передачи через Ethernet-соединение, которое по умолчанию ограничивает пакеты до 1500 байт. Этот процесс происходит на сетевом уровне IP и называется фрагментацией.

Для идентификации фрагментов, принадлежащих вместе, IP присваивает каждому пакету 16-битное значение IP ID; фрагменты, созданные из одного UDP-пакета, будут иметь одинаковый IP ID. Принимающая система будет собирать эти фрагменты и объединять их, чтобы сформировать исходный UDP-пакет. Этот процесс называется сборкой. Время ожидания для сборки пакета по умолчанию составляет 30 секунд; если сетевая стек не получает все фрагменты данного пакета в течение этого интервала, она считает, что недостающий фрагмент(ы) был утерян и отбрасывает те, которые были уже получены.

Проблема, которая создается на высокоскоростных каналах, заключается в том, что возможно отправить более 65536 пакетов в течение 30 секунд. На самом деле, при интенсивной трафике NFS можно наблюдать, что IP ID повторяются примерно через 5 секунд.

Это серьезно влияет на сборку: если один фрагмент потеряется, другой фрагмент из другого пакета, но с тем же IP ID, прибудет в течение 30 секунд, и сетевая стек объединит эти фрагменты для формирования нового пакета. В большинстве случаев уровни сети выше IP обнаружат эту несоответствующую сборку – в случае UDP, контрольная сумма UDP, которая является 16-битной контрольной суммой всего полезного пакета, обычно не совпадет, и UDP отбросит плохой пакет.

Однако, контрольная сумма UDP составляет всего 16 бит, поэтому существует вероятность 1 к 65536, что она совпадет, даже если полезная нагрузка пакета будет полностью случайной (что очень часто бывает не так). Если это произойдет, произойдет тихая порча данных.

Эта возможность должна быть принята всерьез, по крайней мере, на гигабитном Ethernet. Скорости 100 Мбит/с следует считать менее проблематичными, потому что при большинстве шаблонов трафика IP ID обходится гораздо дольше 30 секунд.

Поэтому настоятельно рекомендуется использовать NFS поверх TCP, где это возможно, так как TCP не выполняет фрагментацию.

Если вам нужно работать с правами пользователя/группы на файлы, знайте, что nfs4.x использует систему Acl, похожую на Windows, вместо традиционных разрядов Unix.

Это не обязательно плохо, потому что это гораздо более богатая окружающая среда прав. Однако, когда я в последний раз смотрел на это, инструменты для пользователей были сложными в использовании.

Возможно, NFS4 может опционально поддерживать режимные разряды; проверьте это, если это для вас важно.

Nfs3 является бездрайверным, что ограничивает его функциональность во многих отношениях. Однако у него есть огромное преимущество, когда у вас есть сервер NFS с высокой доступностью. Например, на dell power scale (isilon), если один узел выходит из строя, другой узел возьмет на себя адрес IP и подключения и беспрепятственно продолжит обслуживание клиентов.