Устранение неполадок файловых хранилищ NFS в Azure

Область применения: ✔️ общие папки Azure NFS

Примечание.

CentOS, на который ссылается в этой статье, является дистрибутивом Linux и достигнет конца жизни (EOL). Думайте об использовании и планировании соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

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

Внимание

Содержимое этой статьи применяется только к NFS-ресурсам. Сведения об устранении неполадок SMB в Linux см. в статье Устранение проблем с файлами Azure в Linux (SMB). Общие папки NFS Azure не поддерживаются для Windows.

Используйте диагностический инструмент Always-On

Средство диагностики Always-On (AOD) можно использовать для сбора журналов на клиентах NFSv4 и SMB Linux. Управляющая программа выполняется в фоновом режиме в качестве системной службы и может быть настроена для обнаружения аномалий в различных источниках, таких как журналы dmesg, отладочные данные, метрики ошибок и метрики задержки. Он может записывать данные из tcpdump, nfsstat, mountstsat и других источников, а также использования ЦП и памяти системы. Это средство полезно для сбора сведений об отладке проблем на местах, которые трудно воспроизвести.

Средство диагностики Always-On в настоящее время совместимо с системами под управлением SUSE Linux Enterprise Server 15 (SLES 15) и Red Hat Enterprise Linux 8 (RHEL 8). Выполните действия по установке, соответствующие операционной системе:

Внимание

Always-On Diagnostics не поддерживает тома NFS с включённым шифрованием данных при передаче. Чтобы включить сбор журналов на затронутом ресурсе NFS, необходимо смонтировать этот ресурс без EiT.

В RHEL 8 выполните следующие инструкции, чтобы установить средство диагностики Always-On:

  1. Скачайте пакет конфигурации репозитория.

    curl -ssl -O https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
    
  2. Установите пакет конфигурации репозитория.

    sudo rpm -i packages-microsoft-prod.rpm
    
  3. Удалите пакет конфигурации репозитория после установки и обновления файлов индекса пакета.

    rm packages-microsoft-prod.rpm
    sudo dnf update
    
  4. Установите пакет .

    sudo dnf install aod
    

Сбой команды chgrp "имя_файла": недопустимый аргумент (22)

Причина 1: сопоставление идентификаторов не отключено

Таким образом, так как Файлы Azure запрещает буквенно-цифровые UID/GID, необходимо отключить отображение идентификаторов.

Причина 2: Отключённое idmapping снова включается после обнаружения некорректного имени файла или каталога

Даже если отключить idmapping, в некоторых случаях система может автоматически включить его снова. Например, если Файлы Azure обнаруживает неправильное имя файла, он отправляет ошибку. При получении этого кода ошибки клиент Linux NFS 4.1 решает снова включить сопоставление идентификаторов (idmapping) и отправляет последующие запросы с буквенно-цифровым UID или GID. Список неподдерживаемых символов в Файлы Azure см. в разделе Именование и ссылка на общие папки, каталоги, файлы и метаданные. Одним из неподдерживаемых символов является двоеточие.

Обходное решение

Убедитесь, что вы отключили idmapping и что ничто не включает его снова. В этом случае выполните следующие шаги.

  1. Отключите общую папку.

  2. Отключите idmapping, выполнив следующую команду:

    sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
    
  3. Подключите общую папку обратно.

  4. Если вы используете rsync, выполните rsync с аргументом -numeric-ids в каталоге, путь к которому не содержит некорректного имени каталога или файла.

Не удалось создать общую папку NFS

Причина: неподдерживаемые параметры учетной записи хранения

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

  • Уровень: Премиум
  • Тип учетной записи: FileStorage

Решение

Следуйте инструкциям из статьи "Создание общей папки NFS".

Не удается подключиться к сетевому ресурсу NFS Azure или смонтировать его

Причина 1. Запрос поступает от клиента в ненадежной сети или ненадежном IP-адресе.

В отличие от SMB, NFS не поддерживает проверку подлинности на основе пользователей. Аутентификация для сетевого ресурса зависит от конфигурации правила сетевой безопасности. Чтобы клиенты подключались к вашему общему ресурсу NFS только по защищённым соединениям, необходимо использовать конечную точку службы или частные конечные точки. Чтобы получить доступ к общим ресурсам из локальной среды в дополнение к частным конечным точкам, необходимо настроить VPN-подключение или Azure ExpressRoute. Брандмауэр учетной записи хранения игнорирует IP-адреса, добавленные в список разрешений. Чтобы настроить доступ к общей папке NFS, используйте один из следующих методов:

  • Конечная точка службы

    • Доступ через общедоступную конечную точку.

    • Доступна только в том же регионе.

    • Нельзя использовать VNet-пиринг для доступа к общим ресурсам.

    • Вы должны добавить в список разрешений каждую виртуальную сеть или подсеть по отдельности.

    • Для локального доступа можно использовать конечные точки службы с поддержкой ExpressRoute, а также VPN типов "точка — сеть" и "сеть — сеть". Используйте частную конечную точку, так как она более безопасна.

      На следующей схеме показано подключение с помощью общедоступных конечных точек:

      Схема подключения к общедоступным конечным точкам.

  • Приватная конечная точка

    • Доступ более безопасен, чем при использовании конечной точки службы.

    • Доступ к общей папке NFS через частное подключение доступен внутри и за пределами региона учетной записи хранения Azure (межрегионально и из локальной среды).

    • Пиринг виртуальных сетей с сетями, размещёнными в частной конечной точке, обеспечивает доступ к NFS-ресурсу клиентам в пиринговых виртуальных сетях.

    • Частные конечные точки можно использовать вместе с ExpressRoute, VPN типа "точка — сеть" и VPN типа "сеть — сеть".

      Схема подключения к частным конечным точкам.

Причина 2: nfs-utils, nfs-client или nfs-common пакет не установлен

Перед выполнением mount команды установите пакет nfs-utils, nfs-client или nfs-common.

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

Те же команды в этом разделе применяются к CentOS и Oracle Linux.

sudo rpm -qa | grep nfs-utils

Решение

Если пакет не установлен, установите пакет с помощью команды дистрибутива.

Те же команды в этом разделе применяются к CentOS и Oracle Linux.

ОС версии 7.X

sudo yum install nfs-utils

ОС версии 8.X или 9.X

sudo dnf install nfs-utils

Причина 3. Блокировка брандмауэра порта 2049

Протокол NFS взаимодействует с сервером через порт 2049. Убедитесь, что этот порт открыт для учетной записи хранения (сервер NFS).

Решение

Убедитесь, что в клиенте открыт порт 2049, выполнив следующую команду. Если порт не открыт, откройте его.

sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

Причина 4. Удаленная учетная запись хранения

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

Решение

Восстановление учетной записи хранения. Затем удалите и повторно создайте частную конечную точку, чтобы она связана с новым идентификатором ресурса учетной записи хранения.

Причина 5. Вы пытаетесь подключить общую папку с помощью клиента NFS вместо вспомогательного средства подключения AZNFS, а в учетной записи хранения включена настройка Необходима безопасная передача и/или Требовать шифрование при передаче для NFS.

Настройка Обязательная безопасная передача применяет шифрование в процессе передачи для всех файловых ресурсов в учетной записи хранения, если только не включена настройка Требовать шифрование для передачи NFS, тогда Обязательная безопасная передача применяется только к трафику REST/HTTPS. Для общих папок NFS, при использовании шифрования при передаче требуется подключение общей папки с помощью вспомогательного средства монтирования AZNFS — клиентского пакета утилит, который упрощает создание защищенных туннелей для трафика NFSv4.1.

Решение

Отключите настройки Требуется безопасная передача данных и Требовать шифрование при передаче данных для NFS в учетной записи хранилища или используйте вспомогательный инструмент монтирования AZNFS для подключения общего ресурса. Дополнительные сведения см. в разделе Шифрование при передаче данных для общих папок NFS Azure.

Команда ls зависает при перечислении файлов в больших каталогах в некоторых ядрах

Причина: ошибка появилась в ядре Linux версии 5.11 и исправлена в версии 5.12.5

В некоторых версиях ядра существует ошибка, из-за которой перечень каталогов приводит к бесконечной последовательности READDIR. Небольшие каталоги, в которых все записи могут быть отправлены в одном вызове, не имеют этой проблемы. Ошибка появилась в ядре Linux версии 5.11 и исправлена в версии 5.12.5. Итак, любая промежуточная версия содержит эту ошибку. RHEL 8.4 использует эту версию ядра.

Обходное решение: понижение или обновление ядра

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

Системные команды завершаются ошибкой "Файл не найден"

Причина

32-разрядные приложения Linux, использующие номера инодеров, могут не работать должным образом с Файлы Azure из-за форматирования 64-разрядных номеров инодеров, созданных службой NFS.

Решение

Чтобы решить эту проблему, используйте один из указанных ниже способов.

  • Сжать 64-разрядные номера инодера до 32 бит, используя параметр загрузки ядра nfs.enable_ino64=0.

  • Задайте параметр модуля, добавив options nfs enable_ino64=0 в файл /etc/modprobe.d/nfs.conf и перезагрузив виртуальную машину.

Этот параметр загрузки ядра также можно сохранить в файле grub.conf . Дополнительные сведения см. в документации по дистрибутиву Linux.

Не удается изменить владение файлами и каталогами

Причина

Клиентская ОС применяет разрешения для общих папок NFS, а не службы Файлы Azure. Если включить параметр root Squash в общей папке NFS, корневой пользователь в клиентской системе становится анонимным (не привилегированным) пользователем для управления доступом. Это ограничение означает, что даже если вы вошли в клиентскую систему под учетной записью root, вы не можете использовать команду chown, чтобы изменить владельца файлов и каталогов, которые вам не принадлежат.

Решение

На портале Azure перейдите в общую папку и выберите "Свойства". Измените параметр Root Squash на No Root Squash. Дополнительные сведения см. в разделе Configure root squash for Файлы Azure.

Если включить no Root Squash, корневой пользователь в клиентской системе имеет те же привилегии, что и корневой пользователь в серверной системе. Теперь вы можете chown изменить владельца любого файла или каталога в общей папке, независимо от текущего владельца. После внесения изменений можно повторно включить root Squash при необходимости.

Нужна помощь?

Если вам все еще нужна помощь, обратитесь в службу поддержки, которая поможет быстро устранить проблему.

См. также

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

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