Устранение неполадок с конфигурацией NAS и целевыми объектами хранилища NFS

В этой статье приводятся решения для некоторых распространенных ошибок конфигурации и других проблем, которые могут препятствовать добавлению системы хранилища NFS в качестве целевого объекта хранения.

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

Если решение проблемы не включено здесь, откройте запрос в службу поддержки , чтобы служба Майкрософт и поддержка могли работать с вами, чтобы изучить и решить проблему.

Обеспечьте достаточное количество потоков подключения

Крупные системы HPC Cache делают несколько запросов на подключение к целевому объекту хранилища. Например, если целевой объект хранилища использует модуль Ubuntu Linux nfs-kernel-server , число потоков управляющей программы NFS по умолчанию может быть не ниже восьми. Увеличьте число потоков до 128 или 256, что является более разумным числом для поддержки среднего или большого кэша HPC.

Вы можете проверить или задать количество потоков в Ubuntu с помощью значения RPCNFSDCOUNT./etc/init.d/nfs-kernel-server

Проверка параметров порта

Для Azure HPC Cache требуется доступ на чтение и запись к нескольким портам UDP/TCP в внутренней системе хранилища NAS. Убедитесь, что эти порты доступны в системе NAS, а также разрешен трафик для этих портов через любые брандмауэры между системой хранения и подсетью кэша. Возможно, вам потребуется работать с брандмауэром и сетевыми администраторами для центра обработки данных, чтобы проверить эту конфигурацию.

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

В общем случае кэшу требуется доступ к этим портам:

Чтобы узнать о конкретных портах, необходимых для вашей системы, используйте следующую rpcinfo команду. Эта команда ниже содержит список портов и форматирует соответствующие результаты в таблице. (Используйте IP-адрес системы вместо <термина storage_IP> .)

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

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

Убедитесь, что все порты, возвращаемые rpcinfo запросом, разрешают неограниченный трафик из подсети Azure HPC Cache.

Проверьте эти параметры как в самом NAS, так и на всех брандмауэрах между системой хранения и подсетью кэша.

Проверка параметров корневого сквоша

Параметры root squash могут нарушить доступ к файлам, если они неправильно настроены. Убедитесь, что параметры для каждого экспорта хранилища и соответствующие политики доступа клиентов HPC Cache соответствуют.

Функция root squash предотвращает отправку запросов от локального суперпользователя root на клиенте в систему хранилища back-end, маскируя их как запросы от обычного пользователя. Он переназначает запросы от пользователя root на непривилегированный идентификатор пользователя (UID), например, 'nobody'.

Корневой сквош можно настроить в системе HPC Cache в следующих местах:

• В Azure HPC Cache используйте политики доступа клиентов для настройки функции root squash для клиентов, соответствующих определённым правилам фильтрации. Политика доступа клиентов является частью каждого пути пространства имен целевого хранилища NFS.

  Политика доступа клиента по умолчанию не сквашивается корень.

• При экспорте хранилища можно настроить систему хранения для переназначения входящих запросов из корневого каталога в идентификатор пользователя без привилегий (UID).

Если ваша система хранения уничтожает root-привилегии, необходимо обновить правило доступа клиента HPC Cache для этого целевого хранилища, чтобы оно также уничтожало root-привилегии. Если это условие не выполнено, у вас могут возникнуть проблемы с доступом при попытке чтения или записи в систему хранилища серверной части через HPC Cache.

Эта таблица иллюстрирует поведение различных сценариев root squash, когда запрос клиента отправляется как UID 0 (root). Сценарий, помеченный параметром * , не рекомендуется , так как он может вызвать проблемы с доступом.

(UID 65534 является примером; при включении подавления привилегий root в политике клиентского доступа можно настроить UID.)

Проверка доступа к путям каталога

Для систем NAS, которые экспортируют иерархические каталоги, убедитесь, что Azure HPC Cache имеет соответствующий доступ на каждом уровне экспорта в пути к файлам, которые вы используете.

Например, система может показать три экспорта следующим образом:

• /ifs
• /ifs/accounting
• /ifs/accounting/payroll

Экспорт /ifs/accounting/payroll является дочерним элементом /ifs/accounting, и /ifs/accounting является дочерним элементом /ifs.

При добавлении payroll экспорта в качестве целевого хранилища HPC Cache, кэш фактически подключается /ifs/ и получает доступ к каталогу заработной платы. Для доступа к экспорту /ifs/accounting/payroll Azure HPC Cache требуется иметь достаточный доступ к /ifs.

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

Система NAS с иерархическими экспортами может предоставлять разные дескрипторы для одного файла, если файл извлекается из разных экспортов. Например, клиент может подключить /ifs/accounting и получить доступ к файлу payroll/2011.txt. Другой клиент монтирует /ifs/accounting/payroll и обращается к файлу 2011.txt. В зависимости от того, как система хранения назначает дескриптор файлов, эти два клиента могут получать один и тот же файл с различными дескрипторами файлов (один для <mount2>/payroll/2011.txt и один для <mount3>/2011.txt).

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

Чтобы избежать этого возможного конфликта файлов в нескольких экспортах, Azure HPC Cache автоматически подключает самый мелкий доступный экспорт в пути (/ifs в примере) и использует дескриптор файла, заданный из этого экспорта. Если несколько экспортов используют один и тот же базовый путь, Azure HPC Cache должен получить доступ к такому пути.

Настройка ограничений размера VPN-пакетов

При наличии VPN между кэшем и устройством NAS VPN может блокировать полноразмерные 1500-байтовые пакеты Ethernet. Эта проблема может возникнуть, если большие обмены между NAS и экземпляром Azure HPC Cache не завершены, но небольшие обновления работают должным образом.

Существует не простой способ определить, имеет ли ваша система эту проблему, если вы не знаете подробности конфигурации VPN. Ниже приведены несколько методов, которые помогут вам проверить эту проблему.

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

• Если VPN разрешает команды ping, можно проверить отправку полноразмерного пакета.

  Выполните команду ping через VPN в NAS с помощью этих параметров. (Используйте IP-адрес системы хранения вместо <значения storage_IP> .)

  ping -M do -s 1472 -c 1 <storage_IP>
  

  Ниже приведены параметры в команде:

  • -M do - Не фрагментировать
  • -c 1 — Отправка только одного пакета
  • -s 1472 — Задайте размер полезных данных до 1472 байт. Это максимальный размер полезной нагрузки для 1500-байтового пакета после учета накладных расходов Ethernet.

  Успешный ответ выглядит следующим образом.

  PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
  1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms
  

  Если ping не удается с 1472 байтами, вероятно, возникла проблема с размером пакета.

Чтобы устранить проблему, может потребоваться включить ограничение MSS на VPN для правильного обнаружения максимального размера кадра удаленной системой. Дополнительные сведения см. в документации по параметрам IPsec/IKE VPN-шлюза .

Изменение параметра MTU для Кэша HPC Azure на 1400 в некоторых случаях может помочь. Однако при ограничении MTU в кэше необходимо также ограничить параметры MTU для клиентов и внутренних систем хранения, взаимодействующих с кэшем. Дополнительные сведения о настройке параметров Azure HPC Cache см. в статье "Настройка дополнительных параметров Azure HPC Cache ".

Проверить стиль безопасности ACL

В некоторых системах NAS используется гибридный стиль безопасности, который объединяет списки управления доступом (ACL) с традиционной безопасностью POSIX или UNIX.

Если система сообщает о своем стиле безопасности как UNIX или POSIX без включения акронима ACL, эта проблема не влияет на вас.

Для систем, использующих списки управления доступом, Azure HPC Cache необходимо отслеживать дополнительные данные, связанные с пользователями, в целях управления доступом к файлам. Это делается путем включения кэша доступа. Для включения кэша доступа нет пользовательского элемента управления, но вы можете открыть запрос в службу поддержки, чтобы запросить, чтобы он был включен для затронутых целевых объектов хранения в системе кэша.

Дальнейшие действия

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