Использование блоб-хранилища, подключенного к NFS, совместно с Azure HPC Cache

Контейнеры BLOB-объектов, подключенные к NFS, можно использовать с Azure HPC Cache. Дополнительные сведения о поддержке протокола NFS 3.0 в хранилище BLOB-объектов Azure см. на сайте документации по хранилищу BLOB-объектов.

Azure HPC Cache использует хранилище BLOB-объектов с поддержкой NFS в своем целевом типе хранилища ADLS-NFS. Эти целевые объекты хранения похожи на обычные целевые объекты хранилища NFS, но также имеют некоторые перекрытия с обычными целевыми объектами BLOB-объектов Azure.

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

Вы также должны ознакомиться с документацией по BLOB-объектам NFS, особенно с теми разделами, которые описывают совместимые и несовместимые сценарии, а также содержат советы по устранению неполадок.

• Обзор функций
• Вопросы производительности
• Известные проблемы и ограничения
• Руководство по процедуре и устранению неполадок

Общие сведения о требованиях к согласованности

HPC Cache требует строгой согласованности для целевых объектов хранения ADLS-NFS. По умолчанию хранилище BLOB-объектов с поддержкой NFS не обновляет метаданные файлов, что предотвращает точное сравнение версий файлов в HPC Cache.

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

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

Предварительная загрузка данных с помощью протокола NFS

В контейнере BLOB-объектов с поддержкой NFS файл может изменяться только тем же протоколом, который использовался при его создании. То есть при использовании REST API Azure для заполнения контейнера невозможно использовать NFS для обновления этих файлов. Так как Azure HPC Cache использует только NFS, он не может изменять файлы, созданные с помощью REST API Azure. (Дополнительные сведения о известных проблемах с API хранилища BLOB-объектов)

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

Если файлы в контейнере были созданы через REST API для Blob-объектов Azure, а не с помощью NFS, кэширование HPC в Azure ограничено следующими действиями над исходными файлами.

• Вывод списка файлов в каталоге.
• Считывайте файл (и удерживайте его в кэше для последующих операций чтения).
• Удалите файл.
• Очистите файл (обнулите его до 0).
• Сохраните копию файла. Копия помечена как созданный NFS-файл, и его можно изменить с помощью NFS.

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

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

Сценарии кэширования

Эти модели использования кэша включают кэширование записи:

• Более 15% операций записи
• Более 15% записи, проверка резервного сервера на наличие изменений каждые 30 секунд
• Более 15% записи, проверка резервного сервера на наличие изменений каждые 60 секунд
• Если более 15% операций - записать данные обратно на сервер каждые 30 секунд

Модели использования кэширования записей должны использоваться только в файлах, созданных с помощью NFS.

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

Вот как попытка кэшировать записи в созданные REST файлы ставит данные под угрозу:

1. Кэш принимает изменения от клиентов и возвращает сообщение об успешном выполнении каждого изменения.

2. Кэш сохраняет измененный файл в хранилище и ожидает дополнительных изменений.

3. Через некоторое время кэш пытается сохранить измененный файл в серверном контейнере. На этом этапе появится сообщение об ошибке, так как он пытается записать в созданный REST файл с помощью NFS.

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

Чтение сценариев кэширования

Сценарии кэширования чтения подходят для файлов, созданных с помощью NFS или REST API BLOB-объектов Azure.

Эти модели использования используют только кэширование чтения:

• Чтение с высокой нагрузкой, редкие записи
• Клиенты записывают данные в целевой объект NFS, обходя кэш
• Интенсивное чтение данных, проверка основного сервера каждые 3 часа

Эти модели использования можно использовать с файлами, созданными REST API или NFS. Все записи NFS, отправляемые клиентом в контейнер back-end, по-прежнему завершаются ошибкой, но они завершаются сразу и возвращают клиенту сообщение об ошибке.

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

Распознавание ограничений диспетчера сетевой блокировки (NLM)

Контейнеры объектов BLOB с поддержкой NFS не поддерживают диспетчер блокировки сети (NLM), который является частью протокола NFS и используется для защиты файлов от конфликтов.

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

Чтобы отключить NLM, используйте параметр -o nolock в команде клиентов mount . Этот параметр запрещает клиентам запрашивать блокировки NLM и получать ошибки в ответ. Этот nolock параметр реализуется по-разному в разных операционных системах. Дополнительные сведения см. в документации по клиентской ОС (man 5 nfs).

Упростите записи в контейнеры с поддержкой NFS с помощью HPC Cache.

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

Одним из ограничений, описанных в статье Performance considerations о BLOB-объектах с поддержкой NFS, является то, что хранилище ADLS-NFS не очень эффективно при перезаписи существующих файлов. Если вы используете Azure HPC Cache с хранилищем BLOB-объектов, подключенным к NFS, кэш обрабатывает периодические перезаписи, так как клиенты изменяют активный файл. Задержка записи файла в внутренний контейнер скрыта от клиентов.

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

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

• Сведения о предварительных требованиях целевого хранилища ADLS-NFS
• Создание учетной записи хранения BLOB-объектов с поддержкой NFS