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

Статья
06/01/2023

Вы можете использовать контейнеры больших двоичных объектов, подключенные к системе 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 для всех контейнеров больших двоичных объектов с поддержкой NFS, используемых в качестве целевого расположения хранилища.

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

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

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

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

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

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

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

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

Совет

Дополнительные сведения о кэшировании чтения и записи см. в статье Общие сведения о моделях использования кэша.

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

Эти модели использования кэша имеют нижеуказанные сценарии кэширования записи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизация записи в контейнеры с поддержкой NFS с помощью службы HPC Cache

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

Примечание.

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

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

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

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

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

Поделиться через