1. при *ВКЛЮЧЕННОМ* sec=krb5, работа практически невозможна: запрос списка файлов может отрабатывать крайне медленно, работа с отдельным файлом может проходить крайне медленно. В то же время копирование отдельного файла проходит на полной (нормальной) скорости, но *может* внезапно приостанавливаться. при *выключенном* sec=krb5, работа идёт на полной скорости, без замираний и пауз. Падение производительности достигает 20x!!! При включенном sec=krb5, невозможно пользоваться libreoffice на nfs шарах. при трассировке и просмотре статистики выяснено: nfsstat -rs Server rpc stats: calls badcalls badfmt badauth badclnt 0 0 0 0 0 в то же время, Client rpc stats: calls retrans authrefrsh 700319 0 700319, в трассировке постоянная проверка атрибутов и постоянные запросы к серверу керберос, Когда керберос (использую ipa) не на том же сервере, что nfs сервер, ситауция становится ещё хуже и падение производительности в пиках достигает 40x. В то же время, пользоваться несекьюрной nfs в не особенно доверенной сети, безумие. что-то с этим надо делать. самба тоже, выход так себе. в результате, "чисто линуксовый" домен, на практике, невозможен.
(Ответ для Gleb Kulikov на комментарий #0) > 1. при *ВКЛЮЧЕННОМ* sec=krb5, работа практически невозможна: запрос списка > файлов может отрабатывать крайне медленно, работа с отдельным файлом может > проходить крайне медленно. В то же время копирование отдельного файла > проходит на полной (нормальной) скорости, но *может* внезапно > приостанавливаться. > при *выключенном* sec=krb5, работа идёт на полной скорости, без замираний и > пауз. Падение производительности достигает 20x!!! При включенном sec=krb5, > невозможно пользоваться libreoffice на nfs шарах. > при трассировке и просмотре статистики выяснено: > nfsstat -rs > Server rpc stats: > calls badcalls badfmt badauth badclnt > 0 0 0 0 0 > в то же время, > Client rpc stats: > calls retrans authrefrsh > 700319 0 700319, > в трассировке постоянная проверка атрибутов и постоянные запросы к серверу > керберос, Когда керберос (использую ipa) не на том же сервере, что nfs > сервер, ситауция становится ещё хуже и падение производительности в пиках > достигает 40x. > В то же время, пользоваться несекьюрной nfs в не особенно доверенной сети, > безумие. что-то с этим надо делать. самба тоже, выход так себе. > > в результате, "чисто линуксовый" домен, на практике, невозможен. Вы упомянули на канале, что в RHEL исправили. Есть конкретная информация об этом?
добрый день, извиняюсь за задержку: извещение упало в "спам". к сожалению, точные номера не знаю, только то, что гуглится. В ссылках флажок [solved], например, https://access.redhat.com/solutions/4077291
похоже, критическое падение производительности исправлено, как минимум, в связке 9.1 <-> Сизиф (9.1 <-> 9 планирую потестировать на днях). Проверялось на связке server virt (dist-upgraded) <-> сизиф. Конфигурация: 192.168.10.1 чистый сервер (установлен из образа, минимально необходимая настройка), на нём же nfs - сервер 192.168.10.2 free ipa. Сервер введён в домен ipa. Сделана запись echo 'SECURE_NFS=yes' >> /etc/sysconfig/nfs. Сделаны обычные действия по добавлению в ipa хостов и ключей. клиенты (Kworkstation 9, обновлённая до Сизифа и starter, аналогично) в той-же сети. экспорт на сервере: /mnt/T03-20150129/Archive/Photo 192.168.10.0/24(rw,no_subtree_check,sec=krb5:krb5i:krb5p,async) импорт на клиентах: athena77.athena.gtsk:/mnt/T03-20150129/Archive/Photo /Archive/PHOTO nfs rw,sec=krb5,soft,intr,timeo=4,vers=3,nofail,nodev,nosuid,noexec,noauto,asyn c,x-systemd.automount,x-systemd.device-timeout=3 проблем, пока, не видно, в том числе при интенсивной работе с большим числом относительно малых файлов (в прошлые заходы, таковая работа вешала систему начисто). ещё проверяю с vers=4, есть некоторые нехорошие ощущения см. также https://bugzilla.altlinux.org/show_bug.cgi?id=39728
