Дата и время публикации:
Проблемы и решение
1. Суть проблемы
Заключалась в больших задержках и подвисании NFS соединения, создаваемого гостевой ОС для доступа к дисковому пространству центральной машины, и купировалась мной командами tracepath и nmon, которые нужно было до установить, как показано в дампе 1.1
Дамп 1.1
# apt search iputils-tracepath nmop
При этом, ранее, мной были сделаны соответствующие установки во время настройки сети для NFS-cоединений. Поэтому на стороне хозяйского узла с ip: 192.168.2.2 с использованием tracepath тестировалось прохождение пакетов [3.1] до гостевой ОС ip: 192.168.2.125, как показано в дампе 1.2
Дамп 1.2
root@home2:~# tracepath -b -l 65535 -4 192.168.2.125
1?: [LOCALHOST] pmtu 1500
1: 192.168.2.125 (192.168.2.125) 0.474ms reached
1: 192.168.2.125 (192.168.2.125) 0.511ms reached
Resume: pmtu 1500 hops 1 back 1
И обратно, прохождение пакетов с гостевой ОС (ip:192.168.2.125) на хозяйский узел (ip:192.168.2.2) как показано в дампе 1.3
Дамп 1.3
root@debian9-univ:~# tracepath -b -l 65535 -4 192.168.2.2
1?: [LOCALHOST] pmtu 1500
1: gateway (192.168.2.2) 0.487ms reached
1: gateway (192.168.2.2) 0.422ms reached
Resume: pmtu 1500 hops 1 back 1
Результат тестирования прямого и обратного канала передачи данных показали практически идентичные результаты и достаточно высокую скорость прохождения маршрута от гостевой ОС (ip: 192.168.2.125) до хозяйского узла (ip: 192.168.2.0) локальной сети с ip:192.168.2.0/24 виртуальной среды эмулятора Qemu/KVM
Далее, мной была проведена проверка сетевой утилитой nmon, который позволяет получать статистику использования сервиса NFS, как это видится с точки зрения клиента или сервера для нахождение узких мест. Результат применения которого показана на рисунке 1.4
Рисунок 1.4
Рисунок 1.4
Как показано на рисунке 1.4, сетевой утилитой nmon можно получить общую статистику обращения к системным вызовам в секунду, наибольшее же число можно получить, например, при компиляции пакета программного обеспечения, например openssh, которая была достигнута за счет оптимизации NFS, как пороизводить которую расскажу ниже.
2. Решение
В виду полученных достаточно высоких показателей быстродействия самой сети, но не достаточно больших для NFS, провел оптимизацию с использованием следующих опций на стороне клиента, таких как rsize, wsize, nolock, nointr и actimeo с timeo
2.1 Опции rsize и wsize
Указываются на стороне клиента либо непосредственно в команде mount после опции -o или в fstab, как показано в дампе 2.1
Дамп 1.3
192.168.2.2:/path/to/server /path/to/client/directory nfs vers=3,hard,nointr,rsize=31457280,wsize=31457280,nolock,tcp,user,exec,noauto,sync,actimeo=1,timeo=10 0 0
Опции rsize и wsize были установлены 30МБ или 31457280 байт, потому что по умолчанию, начиная ядра с версий 2.4-2.6, они устанавливаются равными не больше чем 32КБайта [3.4], что конечно не так много и существенно влияет на быстродействие.
2.2 Опции nolock
При установке данной опции блокировка файлов производится только в пределах одного и того же клиента, потому что эта опция запрещает использовать NLM протокол, который в свою очередь вносит свои задержки.
2.3 Опции nointr
Хотя данная опция устанавливается по умолчанию,но полезно это делать явно, чтобы точно знать, что сигналы не будут прерывать выполнение файловых операций.
2.4 Опции actimeo или timeo
Как уже писал ранее, когда баловался более предметно с этими опциям, что actimeo=n на стороне клиента, который устанавливает в одно и тоже положение сразу несколько опций отвечающих за своевременное кэширование атрибутов директорий и файлов.
Поэтому мной была установлена рассматриваемые опции: actimeo=1, timeo=10 . Последнюю нужно указывать обязательно больше нуля, а лучше равной 10-ть по 100-миллисекунд промежутоков времени ожидания.
2.5 Почему применять опцию async на стороне сервера небезопасно
Эта опция несет с собой не только проблемы в безопасности, но так же возможность потери данных [3.4]. Также нужно учитывать, то версию протокола через опции монтирования nfsvers, ее альтернатива vers и minorversion(только для протокола версии 4) , как было показано в дампе 2.1.1
Так, при использовании протокола NFSv2
клиент считает, что он работает с устойчивым и стабильным хранилищем данных на стороне сервер. Поэтому любой отказ на стороне которого приводит неминуемо к потери данных из того, что буфера с записанными данными уже очищены. Поэтому, как показано в дампе 2.5.1, следующая экспортная запись в файле /etc/exports будет небезопасна.Дамп 2.5.1
/path/to/server/directory 192.168.2.0/24(rw,async,insecure,no_root_squash,no_subtree_check)
Так же клиент/серверное соединение, созданное по протоколу NFSv2 не обладает какими-либо знаниями когда и какие данные были переданы, поэтому в этой версии протокола данные записываются прежде чем сервере даст ответ клиенту.
Поэтому при любом малейшем сбое в работе сервера , даже если клиент все еще хранит модифицированные данные в своем КЭШе, данные на стороне сервера больше не соответствуют тем что клиент записал в свой КЭШ Поэтому скорее всего в будущем данные будут кэшироваться на стороне клиента из угрозы повреждения передаваемых файлов.
При использовании протокола версий протокола NFSv3
и выше указывать эту нет смысла, потому что начиная с этой версии протокола формируется ответ сервера до записи данных на диск при надлежащем контроле. Тем самым клиент неминуемо получит ответ на всякие неординарные события с сервера, например перезапуска, и произведет повторную отправку данных.В итоге, нужно позаботится, что все экспортные записи в файле были /etc/exports использовали опцию "sync", которая лучше явно указывать даже несмотря, что все современные дистрибутивы используют пакет nfs-utils версии 1.0.1 и выше, как показано в дампе 2.5.2
Дамп 2.5.2
/path/to/server/directory 192.168.2.0/24(rw,sync, wdelay, insecure,no_root_squash,no_subtree_check)
Как показано в дампе 2.5.2, для повышения быстродействия также мной была задействована опция wdelay [3.6], которая вносит задержку записи полученных от клиента данных на диск, если сервером ожидаются какие-либо подобные запросы от клиента.
Для отключения времени ожидания, устанавливаемое опцией wdelay на получения запросов по записи, следует указывать опцию no_wdelay, которая доступна только, когда указана опция sync
Кроме того,
- Опция insecure : позволяет отказаться от использования резервного порта NFS [3.7], с целью обезопасить , т.е. оградить, NFS сервер от возможных инъекций клиентских запросов. Для отключения этой возможности следует указывать данную опцию.
- Опция secure : включения этой возможность использования резервного (привеллегированного) порта для исключения на серверной стороне инъекций клиентских запросов [3.8]
- Опция no_root_squash : также повышают быстродействия отключая проверки на предотвращение пользователей с привеллегиями суперпользователя от осуществления их применения, включаемых опцией root_squash
- Опция no_subtree_check : мало влияет на повышения безопасность, но может привнести некоторые улучшения в надежности при некоторых обстоятельства; так, если указана опция subtree_check, сервер при получении запросов производит проверку не только, что поддиректория является экспортируемой, но и всей остальной смонтированной файловой системы; при этом, возможно ситуация когда клиент прошляпит переименование открываемого файла из-за времени потраченного на выполнение данной проверки.
Соответственно, наличие описанных выше проблем опции secure, root_squash и subtree_check только приводят ухудшению быстродействия с минимально возможным повышения быстродействия. Кроме того, учитывая характер использования клиент/серверного соединения NFS в вычислительной сети с IP=192.168.2.0/24, которая находится внутри безопасного периметра и недоступного субъектам внешнего доступа, вместо них необходимо использовать insecure, no_root_squash и no_subtree_check, как это собственно и делается в дампе 2.5.2
2.6 Применение экспортных опций и их проверка
После внесения всех изменений в файл /etc/exports на серверной стороне и в файл /etc/fstab была проведена проверка с использованием утилиты nmon и запуском на гостевой ОС исполнительной части bitbake сборочной машины Yocto/poky
Поэтому до начала проверки был выполнен перезапуск:
- на стороне сервера NFS (хозяйский узел) : service nfs-kernel-server restart
- на стороне клиента NFS (гостевой узел): перезапустил гостевую ОС и произвел монтирование экспортной директории на сервере с абсолютным /path/to/server/directory в точку монтирования /path/to/client/directory на клиенте.
После чего, запустил пресборку пакета openssh и приступил к оценке, быстродействия с использованием утилиты nmon , которая выявила необходимость использования "опасной" опции async вместо sync в купе со всеми остальными и вышеприведенными в файле /etc/exports на стороне сервера, как показано в листинге 2.6.1
Листинге 2.6.1
... /path/to/server/directory 192.168.2.0/24(rw,async,wdelay,insecure,no_root_squash,no_subtree_check) ...
Оценка быстродействия производилась визуально, как было показано на рисунке 1.1 выше. В ходе, который было выявлено, что использование опции sync на стороне клиента, /etc/fstab, как показано в листинге 2.6.1 файла /etc/fstab, позволяет сохранить надежность передачи информации с достаточно приемлемым уровнем быстродействия
А вот опция async на стороне сервера не влияет на качество сохраняемой информации, но при определенных условиях снижает быстродействие соединения NFS
3. Библиография
3.1 Tracepath: Article about Tracepath by The Free Dictionary
3.2 nmon Command - IBM Documentation
3.3 NFS performance tuning - Real-time monitoring - Programmer Sought
3.4 Linux NFS faq
3.6 Red Hat's Docs. Chapter 4. Exporting NFS shares Red Hat Enterprise Linux 8 | Red Hat Customer Portal
3.7 exports(5) - Linux man page
3.8 Setting up reserved (privileged) ports - IBM Documentation
3.9 Create a root-squashing rule for the default NFS export
3.10 Using nfsstat and nfsiostat to troubleshoot NFS performance issues on Linux