Устранение неполадок конфигурации NAS и целевого расположения хранилища NFS

В этой статье приводятся решения для некоторых распространенных ошибок конфигурации и других проблем, которые могут помешать Azure HPC Cache добавить систему хранения 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-адрес вашей системы вместо 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, так и во всех брандмауэрах между системой хранения и подсетью кэша.

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

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

Корневой скваш предотвращает отправку запросов, отправленных локальным корнем суперпользователя на клиенте, в систему хранилища серверной части в качестве корневого. Он переназначает запросы из корневого каталога в не привилегированный идентификатор пользователя (UID), например "никто".

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

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

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

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

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

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

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

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

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

Например, в системе могут отображаться три операции экспорта, подобные следующим:

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

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

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

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

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

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

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

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

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

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

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

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

  Выполните команду проверки связи через VPN до NAS со следующими параметрами. (Используйте IP-адрес системы хранения вместо < 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
  

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

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

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

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

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

Если стиль безопасности вашей системы — UNIX или POSIX без аббревиатуры "ACL", эта проблема не повлияет на вас.

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

Следующие шаги

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