Использование Хранилище BLOB-объектов Azure с Управляемым Lustre в Azure

Статья
01/10/2025

Управляемый Lustre Azure интегрируется с Хранилище BLOB-объектов Azure, чтобы упростить процесс импорта данных из контейнера BLOB-объектов в файловую систему. Вы также можете экспортировать данные из файловой системы в контейнер BLOB-объектов для долгосрочного хранения. В этой статье объясняется, как использовать интеграцию BLOB-объектов с управляемыми файловыми системами Azure Lustre.

Чтобы понять требования и конфигурацию, необходимые для совместимого контейнера BLOB-объектов, см . предварительные требования для интеграции с BLOB-объектами.

Общие сведения об интеграции BLOB-объектов

Вы можете настроить интеграцию BLOB-объектов во время создания кластера и создать задание импорта в любое время после создания кластера. После импорта данных можно работать с данными, как и с другими данными файловой системы. Так как новые файлы создаются или существующие файлы изменяются в файловой системе, эти файлы можно экспортировать обратно в учетную запись хранения, выполнив команды ИНТЕРФЕЙСА командной строки Lustre на клиенте или экспортируя данные с помощью заданий экспорта.

При импорте данных из контейнера BLOB-объектов в управляемую файловую систему Lustre Azure только имена файлов (пространство имен) и метаданные импортируются в пространство имен Lustre. Фактическое содержимое большого двоичного объекта импортируется при первом доступе к клиенту. При первом доступе к данным возникает небольшая задержка, а функция управления иерархическим хранилищем Lustre (HSM) извлекает содержимое большого двоичного объекта в соответствующий файл в файловой системе.

Вы можете предварительно получить содержимое больших двоичных объектов с помощью команды Lustre lfs hsm_restore из подключенного клиента с возможностями sudo. Дополнительные сведения см. в статье "Восстановление данных из хранилища BLOB-объектов".

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

Для учетной записи хранения с включенным иерархическим пространством имен Управляемый Lustre считывает атрибуты POSIX из заголовка BLOB-объекта.
Для учетной записи хранения, которая не включает иерархическое пространство имен, Управляемый Lustre считывает атрибуты POSIX из метаданных BLOB-объектов. Отдельный пустой файл с тем же именем, что и содержимое контейнера BLOB-объектов, создается для хранения метаданных. Этот файл является братом фактического каталога данных в управляемой файловой системе Lustre Azure.

Импорт из хранилища BLOB-объектов

Вы можете настроить интеграцию с хранилищем BLOB-объектов во время создания кластера и создать задание импорта в любое время после создания кластера.

Требования к контейнеру BLOB-объектов

При настройке интеграции BLOB-объектов во время создания кластера необходимо определить два отдельных контейнера BLOB-объектов: контейнер для импорта и контейнера ведения журнала. Контейнер для импорта содержит данные, которые необходимо импортировать в файловую систему Azure Managed Lustre. Контейнер ведения журнала используется для хранения журналов для задания импорта. Эти два контейнера должны находиться в одной учетной записи хранения. Дополнительные сведения о требованиях к контейнеру BLOB-объектов см. в статье о предварительных требованиях для интеграции BLOB-объектов.

Импорт префикса

При импорте данных из контейнера BLOB-объектов можно также указать один или несколько префиксов для фильтрации данных, импортированных в файловую систему Azure Managed Lustre. Имена файлов в контейнере БОЛЬШИХ двоичных объектов, которые соответствуют одному из префиксов, добавляются в запись метаданных в файловой системе. Когда клиент сначала обращается к файлу, его содержимое извлекается из контейнера BLOB-объектов и хранится в файловой системе.

В портал Azure используйте поля префикса импорта на вкладке "Дополнительно" во время создания кластера, чтобы указать данные, импортируемые из контейнера BLOB-объектов. Эти поля применяются только к начальному заданию импорта. После создания кластера невозможно изменить префикс импорта.

Для задания импорта можно указать префиксы импорта при создании задания. В портал Azure можно указать префиксы импорта в полях префикса импорта. Вы также можете указать префикс импорта при использовании REST API для создания задания импорта.

При указании префиксов импорта следует учитывать следующие рекомендации.

Префикс импорта по умолчанию — /. Это поведение по умолчанию импортирует содержимое всего контейнера BLOB-объектов.
Если указать несколько префиксов, префиксы не должны перекрываться. Например, если указано /data и /data2задание импорта завершается ошибкой, так как префиксы перекрываются.
Если контейнер BLOB-объектов находится в учетной записи хранения с включенным иерархическим пространством имен, можно рассматривать префикс как путь к файлу. Элементы под путем включены в файловую систему Azure Managed Lustre.
Если контейнер BLOB-объектов находится в учетной записи хранения с неиерархическим (или плоским) пространством имен, можно представить префикс импорта как строку поиска, которая сравнивается с началом имени BLOB-объекта. Если имя большого двоичного объекта в контейнере начинается со строки, указанной в качестве префикса импорта, этот файл становится доступным в файловой системе. Lustre — это иерархическая файловая система, а / символы в именах BLOB-объектов становятся разделителями каталогов при хранении в Lustre.

Режим разрешения конфликтов

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

Режим	Description
`fail`	Задание импорта завершается ошибкой немедленно, если обнаружен конфликт.
`skip`	Задание импорта пропускает файл, если обнаружен конфликт.
`overwrite-dirty`	Задание импорта оценивает конфликтующий путь, чтобы узнать, следует ли удалить и повторно импортировать его. Дополнительные сведения см. в режиме перезаписи.
`overwrite-always`	Задание импорта оценивает конфликтующий путь и всегда удаляет или повторно импортирует, если он грязный или освобождается, если это чисто. Дополнительные сведения см . в режиме перезаписи.

Перезапись грязного режима

Режим overwrite-dirty оценивает конфликтующий путь, чтобы узнать, следует ли удалить и повторно импортировать его. На высоком уровне overwrite-dirty режим проверяет состояние HSM. Если состояние HSM является чистым и архивным, то есть его данные синхронизированы с контейнером BLOB-объектов до тех пор, пока Lustre может сказать, то при необходимости обновляются только атрибуты. В противном случае файл удаляется и повторно импортируется из контейнера BLOB-объектов.

Проверка состояния HSM не гарантирует, что файл в Lustre соответствует файлу в контейнере BLOB-объектов. Если необходимо убедиться, что файл в Lustre соответствует файлу в контейнере BLOB-объектов как можно ближе, используйте overwrite-always режим.

Режим перезаписи всегда

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

Отказоустойчивость ошибок

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

Для заданий импорта доступны следующие параметры отказоустойчивости ошибок:

Не разрешать ошибки (по умолчанию): задание импорта завершается ошибкой немедленно, если во время импорта возникает какая-либо ошибка. Это поведение по умолчанию.
Разрешить ошибки: задание импорта продолжается, если возникает ошибка, и ошибка регистрируется. После завершения задания импорта можно просмотреть ошибки в контейнере ведения журнала.

Восстановление данных из хранилища BLOB-объектов

По умолчанию содержимое большого двоичного объекта импортируется в файловую систему при первом доступе к соответствующему файлу клиентом. Для определенных рабочих нагрузок и сценариев вы можете восстановить данные из контейнера BLOB-объектов перед первым доступом. Вы можете предварительно получить содержимое больших двоичных объектов, чтобы избежать начальной задержки при первом доступе к blob-объекту после импорта. Чтобы предварительно получить содержимое больших двоичных объектов, можно использовать команду Lustre lfs hsm_restore из подключенного клиента с возможностями sudo. Следующая команда предустановит содержимое больших двоичных объектов в файловой системе:

nohup find local/directory -type f -print0 | xargs -0 -n 1 sudo lfs hsm_restore &

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

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

Пример. Создание скрипта пакетного восстановления

В следующем примере показано, как создать скрипт для восстановления данных из контейнера BLOB-объектов в пакетах. Создайте файл file_restorer.bash со следующим содержимым:

#!/bin/bash
set -feu
set -o pipefail
main()
{
    if [ $# -lt 2 ]; then
        echo "$0 <path_to_fully_restore> <max_restores_at_a_time>"
        echo "Missing parameters"
        exit 1
    fi
    local RESTORE_PATH=$1
    local MAX_RESTORES=$2
    local FILES_LIST="/tmp/files_to_restore"
    find "$RESTORE_PATH" -type f > "$FILES_LIST"
    local TOTAL_FILES
    TOTAL_FILES=$(wc -l "$FILES_LIST")
    local RESTORE_TOTAL=0
    local RESTORE_COUNT=0
    while IFS="" read -r p || [ -n "$p" ]; do
        printf '%s\n' "$p"
        lfs hsm_restore "$p"
        ((RESTORE_COUNT++)) || true
        ((RESTORE_TOTAL++)) || true
        if (( RESTORE_COUNT >= MAX_RESTORES )); then
            while true; do
                local STATE
                STATE=$(lfs hsm_state "$p")
                RELEASED=') released exists archived'
                if ! [[ $STATE =~ $RELEASED ]]; then
                    echo "Restored $RESTORE_TOTAL / $TOTAL_FILES"
                    break
                fi
                sleep 0.2
            done
            RESTORE_COUNT=0
        fi
    done < "$FILES_LIST"
}
main "$@"

В следующем примере показано, как запустить скрипт вместе с примером выходных данных:

root@vm:~# time ~azureuser/file_restorer.bash /lustre/client/ 5000
Finding all files to restore beneath: /lustre/client/
Found 78100 to restore
Initiating restores in batches of 5000...
Restored 5000 / 78100
Restored 10000 / 78100
Restored 15000 / 78100
Restored 20000 / 78100
Restored 25000 / 78100
Restored 30000 / 78100
Restored 35000 / 78100
Restored 40000 / 78100
Restored 45000 / 78100
Restored 50000 / 78100
Restored 55000 / 78100
Restored 60000 / 78100
Restored 65000 / 78100
Restored 70000 / 78100
Restored 75000 / 78100
Restored 78100 / 78100
real	6m59.633s
user	1m20.273s
sys	0m37.960s

Примечание.

В настоящее время Управляемый Lustre Azure восстанавливает данные из хранилища BLOB-объектов с максимальной пропускной способностью около 7,5 ГиБ/секунды.

Экспорт данных в хранилище BLOB-объектов с помощью задания экспорта

Вы можете скопировать данные из файловой системы Azure Managed Lustre в долгосрочное хранилище в Хранилище BLOB-объектов Azure путем создания задания экспорта.

Какие файлы экспортируются во время задания экспорта?

При экспорте файлов из системы Azure Managed Lustre не все файлы копируются в контейнер BLOB-объектов, указанный при создании файловой системы. Следующие правила применяются к заданиям экспорта:

Задания экспорта копируют только новые или измененные содержимое. Если файл, импортированный из контейнера BLOB-объектов во время создания файловой системы, не изменяется, задание экспорта не экспортирует файл.
Файлы с изменениями метаданных не экспортируются. Изменения метаданных включают в себя: владелец, разрешения, расширенные атрибуты и изменения имен (переименовано).
Файлы, удаленные в управляемой файловой системе Lustre Azure, не удаляются в исходном контейнере BLOB-объектов во время задания экспорта. Задание экспорта не удаляет файлы в контейнере BLOB-объектов.
Имена BLOB-объектов должны соответствовать определенным правилам именования , что означает, что допустимые имена BLOB-объектов немного отличаются от допустимых имен файлов POSIX. Процесс экспорта сохраняет специальные символы в именах файлов, путём корректного экранирования их при экспорте в BLOBs. Однако имя файла, которое нарушает правило именования BLOB-объектов, например, имя файла, превышающее максимальную длину имени BLOB, приводит к ошибке при попытке экспорта этого файла.

Выполнение заданий экспорта в активных файловой системах

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

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

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

Метаданные экспортированных файлов

При экспорте файлов из управляемой файловой системы Lustre Azure в контейнер BLOB-объектов сохраняются дополнительные метаданные, чтобы упростить повторное отображение содержимого в файловой системе.

В следующей таблице перечислены атрибуты POSIX из файловой системы Lustre, сохраненные в метаданных большого двоичного объекта в виде пар "ключ-значение".

Атрибут POSIX	Тип
`owner`	INT
`group`	INT
`permissions`	формат octal или rwxrwxrwx; липкий бит поддерживается

Атрибуты каталога сохраняются в пустом большом двоичном объекте. Этот большой двоичный объект имеет то же имя, что и путь к каталогу, и содержит следующую пару "ключ-значение" в метаданных БОЛЬШОго двоичного объекта: hdi_isfolder : true

Вы можете вручную изменить атрибуты POSIX перед использованием контейнера для гидратации нового кластера Lustre. Изменение или добавление метаданных BLOB-объектов с помощью пар "ключ-значение", описанных ранее.

Копирование контейнера BLOB-объектов Lustre с помощью AzCopy или Обозреватель службы хранилища

Вы можете переместить или скопировать контейнер BLOB-объектов Lustre с помощью AzCopy или Обозреватель службы хранилища.

Для AzCopy можно включить атрибуты каталога, добавив следующий флаг:

--include-directory-stub

В том числе этот флаг сохраняет атрибуты POSIX каталога во время передачи, например , ownergroupи permissions. Если вы используете azcopy контейнер хранилища без этого флага или с установленным флагом false, то данные и каталоги включаются в передачу, но каталоги не сохраняют свои атрибуты POSIX.

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

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