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

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

Чтобы понять требования и настройки для совместимого контейнера BLOB, см. раздел Предварительные требования для интеграции с BLOB.

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

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

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

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

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

Для учетной записи хранения с включенным иерархическим пространством имен Azure Managed Lustre считывает атрибуты переносимого интерфейса операционной системы (POSIX) из заголовка блоба.
Для учетной записи хранения, которая не включает иерархическое пространство имен, Управляемый 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-объектов и файловой системой. Этот параметр применяется только к заданиям импорта, которые выполняются для существующих кластеров. В следующей таблице показаны доступные режимы разрешения конфликтов и их описания:

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

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

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

Если состояние HSM является чистым и архивированным (файловая система Lustre обнаруживает, что данные синхронизированы с контейнером BLOB-объектов), при необходимости обновляются только атрибуты. В противном случае файл удаляется и повторно импортируется из контейнера BLOB-объектов.

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

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

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

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

При импорте данных из контейнера 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 &

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим это ограничение

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

Копирование контейнера объектов BLOB Lustre с помощью azcopy или Storage Explorer

Вы можете переместить или скопировать контейнер BLOB, который используется файловой системой Lustre, с помощью azcopy или Storage Explorer.

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

--include-directory-stub

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

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-01-13