Usar Azure Blob Storage con Azure Managed Lustre

2025-06-24

Azure Managed Lustre se integra con Azure Blob Storage para simplificar el proceso de importación de datos de un contenedor de blobs a un sistema de archivos. También puede exportar datos del sistema de archivos a un contenedor de blobs para su almacenamiento a largo plazo. En este artículo se explican los conceptos para usar la integración de blobs con sistemas de archivos de Azure Managed Lustre.

Para comprender los requisitos y la configuración necesarios para un contenedor de blobs compatible, consulte Requisitos previos de integración de blobs.

Información general sobre la integración de blobs

Puede configurar la integración de blobs durante la creación del clúster y puede crear un trabajo de importación en cualquier momento después de crear el clúster. Una vez importados los datos, puede trabajar con ellos como lo haría con otros datos del sistema de archivos. A medida que se crean archivos nuevos o se modifican los archivos existentes en el sistema de archivos, puede volver a exportar dichos archivos a la cuenta de almacenamiento ejecutando comandos de la CLI de Lustre en el cliente o exportando datos mediante trabajos de exportación.

Al importar datos de un contenedor de blobs a un sistema de archivos de Azure Managed Lustre, solo se importan los nombres de archivo (espacio de nombres) y los metadatos en el espacio de nombres de Lustre. El contenido real de un blob se importa cuando un cliente accede a él por primera vez. Hay un ligero retraso al acceder por primera vez a los datos mientras la característica Lustre Hierarchical Storage Management (HSM) extrae el contenido del blob al archivo correspondiente en el sistema de archivos.

Puede capturar previamente el contenido de los blobs mediante el comando lfs hsm_restore de Lustre desde un cliente montado con funcionalidades sudo. Para obtener más información, consulte Restaurar datos de Blob Storage.

Azure Managed Lustre funciona con cuentas de almacenamiento que tienen habilitados espacios de nombres jerárquicos y cuentas de almacenamiento con un espacio de nombres no jerárquico o plano. Se aplican las siguientes pequeñas diferencias:

En el caso de una cuenta de almacenamiento con un espacio de nombres jerárquico habilitado, Azure Managed Lustre lee los atributos POSIX del encabezado del blob.
En el caso de una cuenta de almacenamiento que no tenga habilitado el espacio de nombres jerárquico, Azure Managed Lustre lee los atributos POSIX de los metadatos del blob. Se crea un archivo vacío independiente con el mismo nombre que el contenido del contenedor de blobs para incluir los metadatos. Este archivo es un elemento que está en el mismo nivel que el directorio de datos real del sistema de archivos de Azure Managed Lustre.

Importar de Blob Storage

Puede configurar la integración con Blob Storage durante la creación del clúster y puede crear un trabajo de importación en cualquier momento después de crear el clúster.

Requisitos del contenedor de blobs

Al configurar la integración de blobs durante la creación del clúster, debe identificar dos contenedores de blobs independientes: el contenedor que se va a importar y el contenedor de registro. El contenedor que se va a importar contiene los datos que desea importar en el sistema de archivos de Azure Managed Lustre. El contenedor de registro se usa para almacenar registros del trabajo de importación. Estos dos contenedores deben estar en la misma cuenta de almacenamiento. Para obtener más información sobre los requisitos del contenedor de blobs, consulte Requisitos previos de integración de blobs.

Importar prefijos

Al importar datos de un contenedor de blobs, opcionalmente puede especificar uno o varios prefijos para filtrar los datos importados en el sistema de archivos de Azure Managed Lustre. Los nombres de archivo del contenedor de blobs que coinciden con uno de los prefijos se agregan a un registro de metadatos en el sistema de archivos. Cuando un cliente accede por primera vez a un archivo, su contenido se recupera del contenedor de blobs y se almacena en el sistema de archivos.

En el portal de Azure, use los campos Importar prefijo en la pestaña Opciones avanzadas durante la creación del clúster para especificar los datos que se importarán del contenedor de blobs. Estos campos solo se aplican al trabajo de importación inicial. No se puede cambiar el prefijo de importación después de crear el clúster.

Para un trabajo de importación, puede especificar prefijos de importación al crear el trabajo. En el portal de Azure, puede especificar prefijos de importación en los campos Importar prefijo. También puede especificar el prefijo de importación al usar la API REST para crear un trabajo de importación.

Tenga en cuenta las siguientes consideraciones al especificar prefijos de importación:

El prefijo de importación predeterminado es /. Este comportamiento predeterminado importa el contenido de todo el contenedor de blobs.
Si especifica varios prefijos, los prefijos no deben superponerse. Por ejemplo, si especifica /data y /data2, ocurre un error en el trabajo de importación porque los prefijos se superponen.
Si el contenedor de blobs está en una cuenta de almacenamiento con el espacio de nombres jerárquico habilitado, puede considerar el prefijo como una ruta de archivo. Los elementos bajo la ruta de acceso se incluyen en el sistema de archivos de Azure Managed Lustre.
Si el contenedor de blobs está en una cuenta de almacenamiento con un espacio de nombres no jerárquico (o plano), puede considerar el prefijo de importación como una cadena de búsqueda que se compara con el principio del nombre del blob. Si el nombre de un blob en el contenedor comienza con la cadena que especificó como prefijo de importación, dicho archivo se convierte en accesible en el sistema de archivos. Lustre es un sistema de archivos jerárquico y los caracteres / de los nombres de blob se convierten en delimitadores de directorio cuando se almacenan en Lustre.

Modo de resolución de conflictos

Al importar datos de un contenedor de blobs, puede especificar cómo gestionar los conflictos entre el contenedor de blobs y el sistema de archivos. Esta opción solo se aplica a los trabajos de importación que se ejecutan para los clústeres existentes. La siguiente tabla muestra los modos de resolución de conflictos disponibles y sus descripciones:

Mode	Descripción
`fail`	El trabajo de importación genera un error inmediatamente si se detecta un conflicto.
`skip`	El trabajo de importación omite el archivo si se detecta un conflicto.
`overwrite-dirty`	El trabajo de importación evalúa una ruta de acceso en conflicto para ver si se debe eliminar y volver a importar. Para obtener más información, consulte modo overwrite-dirty.
`overwrite-always`	El trabajo de importación evalúa una ruta de acceso en conflicto y siempre la elimina o la vuelve a importar si está sucia o la libera si está limpia. Para obtener más información, consulte modo overwrite-always.

Modo overwrite-dirty

El modo overwrite-dirty evalúa una ruta de acceso en conflicto para ver si se debe eliminar y volver a importar. En un nivel alto, el modo overwrite-dirty comprueba el estado de HSM. Si el estado de HSM es Limpio y Archivado, lo que significa que para Lustre sus datos están sincronizados con el contenedor de blobs, solo se actualizarán los atributos, si es necesario. De lo contrario, el archivo se elimina y se vuelve a importar del contenedor de blobs.

La comprobación del estado de HSM no garantiza que el archivo de Lustre coincida con el archivo del contenedor de blobs. Si debe asegurarse de que el archivo de Lustre coincide con el archivo del contenedor de blobs lo más posible, use el modo overwrite-always.

Modo overwrite-always

El modo overwrite-always evalúa una ruta de acceso en conflicto y siempre la elimina o la vuelve a importar si está sucia o la libera si está limpia. Este modo resulta útil si desea asegurarse de que el sistema de archivos siempre está sincronizado con el contenedor de blobs. También es la opción más costosa, ya que todos los archivos restaurados anteriormente se liberan o se eliminan o se vuelven a importar tras el primer acceso.

Tolerancia a errores

Al importar datos de un contenedor de blobs, puede especificar la tolerancia a errores. El nivel de tolerancia a errores determina cómo controla el trabajo de importación los errores transitorios que se producen durante el proceso de importación, por ejemplo, errores del sistema operativo o interrupciones de red. Es importante tener en cuenta que los errores de este contexto no hacen referencia a conflictos de archivos, que se gestionan mediante el modo de resolución de conflictos.

Las siguientes opciones de tolerancia a errores están disponibles para los trabajos de importación:

No permitir errores (valor predeterminado): el trabajo de importación genera un error inmediatamente si se produce algún fallo durante la importación. Este comportamiento es el valor predeterminado.
Permitir errores: el trabajo de importación continúa si se produce un fallo y se registra el error. Una vez completado el trabajo de importación, puede ver los errores en el contenedor de registro.

Consideraciones para los trabajos de importación de blobs

Los siguientes elementos se deben tener en cuenta al importar datos de un contenedor de blobs:

Solo se puede ejecutar una acción de importación o exportación a la vez. Por ejemplo, si un trabajo de importación está en curso y se intenta iniciar otro trabajo de importación, se devuelve un error.
Los trabajos de importación se pueden cancelar. Puede cancelar un trabajo de importación iniciado en un clúster existente o un trabajo de importación iniciado durante la creación del clúster.
La implementación del clúster puede devolver resultados correctos antes de que se complete el trabajo de importación correspondiente. El trabajo de importación se sigue ejecutando en segundo plano. Puede supervisar el progreso del trabajo de importación de los modos siguientes:
- Portal de Azure: el portal de Azure muestra el estado del trabajo de importación. Vaya al sistema de archivos y seleccione Integración de blobs para ver el estado del trabajo de importación.
- Archivo de Lustre en el directorio raíz: se crea un archivo con un nombre similar a /lustre/IMPORT_<state>.<timestamp_start> en el directorio raíz de Lustre durante la importación. El marcador de posición <state> cambia a medida que avanza la importación. El archivo se elimina cuando el trabajo de importación se completa correctamente.
Para ver los detalles sobre un trabajo de importación completado, puede comprobar el contenedor de registro. El contenedor de registro contiene registros del trabajo de importación, incluidos los errores o conflictos que se produjeron durante la importación.
Si por cualquier motivo se produce un error en el trabajo de importación, es posible que no tenga estadísticas completas sobre el trabajo de importación, por ejemplo, el número de archivos importados o el número de conflictos.

Restaurar datos de Blob Storage

De forma predeterminada, el contenido de un blob se importa a un sistema de archivos la primera vez que un cliente accede al archivo correspondiente. Para determinadas cargas de trabajo y escenarios, es posible que prefiera restaurar los datos a partir de un contenedor de blobs antes de que se acceda a ellos por primera vez. Puede optar por capturar previamente el contenido de los blobs para evitar el retraso inicial cuando se accede al blob por primera vez después de la importación. Para capturar previamente el contenido de los blobs, puede usar el comando lfs hsm_restore de Lustre desde un cliente montado con funcionalidades sudo. El siguiente comando capturará previamente el contenido de los blobs en el sistema de archivos:

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

Este comando indica al servidor de metadatos que procese una solicitud de restauración de forma asincrónica. La línea de comandos no espera a que se complete la restauración, lo que significa que la línea de comandos tiene la posibilidad de poner en espera un gran número de entradas para su restauración en el servidor de metadatos. Este método puede sobrecargar el servidor de metadatos y reducir el rendimiento de las restauraciones.

Para evitar este posible problema de rendimiento, puede crear un script básico que intente recorrer la ruta de acceso y emitir solicitudes de restauración por lotes de un tamaño especificado. Para lograr un rendimiento razonable y evitar sobrecargar el servidor de metadatos, se recomienda usar tamaños de lote en cualquier lugar de 1000 a 5000 solicitudes.

Ejemplo: crear un script de restauración por lotes

En el siguiente ejemplo se explica cómo crear un script para restaurar los datos de un contenedor de blobs por lotes. Cree un nuevo archivo denominado file_restorer.bash con el contenido siguiente:

#!/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 "$@"

En el siguiente ejemplo se muestra cómo ejecutar el script junto con la salida de ejemplo:

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

Nota

En este momento, Azure Managed Lustre restaura los datos de Blob Storage a una velocidad de rendimiento máxima de unos 7,5 GiB/segundo.

Exportar datos a Blob Storage mediante un trabajo de exportación

Puede copiar datos del sistema de archivos de Azure Managed Lustre al almacenamiento a largo plazo en Azure Blob Storage creando un trabajo de exportación.

¿Qué archivos se exportan durante un trabajo de exportación?

Al exportar archivos del sistema de Azure Managed Lustre, no todos los archivos se copian en el contenedor de blobs que especificó al crear el sistema de archivos. Se aplican las reglas siguientes a los trabajos de exportación:

Los trabajos de exportación solo copian archivos nuevos o cuyo contenido se modifica. Si el archivo que importó del contenedor de blobs durante la creación del sistema de archivos no se modifica, el trabajo de exportación no exportará el archivo.
Los archivos en los que solo cambian los metadatos no se exportan. Los cambios de los metadatos incluyen: el propietario, permisos, atributos ampliados y cambios de nombre (renombrados).
Los archivos eliminados en el sistema de archivos de Azure Managed Lustre no se eliminan en el contenedor de blobs original durante el trabajo de exportación. El trabajo de exportación no elimina los archivos del contenedor de blobs.
Los nombres de blobs deben cumplir ciertas reglas de nomenclatura, lo que significa que los nombres de blobs aceptables difieren ligeramente de los nombres de archivo POSIX aceptables. El proceso de exportación conserva los caracteres especiales en los nombres de archivo asegurando su correcta codificación al exportar a blobs. Sin embargo, un nombre de archivo que infringe una regla de nomenclatura de blobs, como un nombre de archivo que supera la longitud máxima del nombre de blob, produce un error al intentar exportar ese archivo.

Ejecutar trabajos de exportación en sistemas de archivos activos

En los sistemas de archivos activos, los cambios de los archivos durante el trabajo de exportación pueden generar un estado de error. Este estado de error le permite saber que no todos los datos del sistema de archivos se pueden exportar a Blob Storage. En esta situación, puede volver a intentar la exportación creando un nuevo trabajo de exportación. El nuevo trabajo copia solo los archivos que no se copiaron en el trabajo anterior.

En los sistemas de archivos con mucha actividad, los reintentos pueden producir errores varias veces porque los archivos cambian con frecuencia. Para comprobar que un archivo se exportó correctamente a Blob Storage, compruebe la marca de tiempo en el blob correspondiente. Una vez completado el trabajo, también puede ver el contenedor de registro configurado en el momento de la implementación para ver información detallada sobre el trabajo de exportación. El contenedor de registro proporciona información de diagnóstico sobre qué archivos han fallado y el motivo.

Si se está preparando para retirar un clúster y desea realizar una exportación final a Blob Storage, debe asegurarse de que se detengan todas las actividades de E/S antes de iniciar el trabajo de exportación. Este método sirve para garantizar que se exportan todos los datos y evita errores debidos a la actividad del sistema de archivos.

Metadatos de archivos exportados

Cuando se exportan archivos del sistema de archivos de Azure Managed Lustre al contenedor de blobs, se guardan metadatos adicionales para que resulte más sencillo volver a importar el contenido a un sistema de archivos.

La siguiente tabla enumera los atributos POSIX del sistema de archivos de Lustre que se guardan en los metadatos del blob como pares de clave-valor:

Atributo POSIX	Tipo
`owner`	entero
`group`	entero
`permissions`	formato octal o rwxrwxrwx; se admiten bits persistentes

Los atributos de directorio se guardan en un blob vacío. Este blob tiene el mismo nombre que la ruta del directorio y contiene el siguiente par de clave-valor en los metadatos del blob: hdi_isfolder : true.

Puede modificar manualmente los atributos POSIX antes de usar el contenedor para hidratar un nuevo clúster de Lustre. Edite o agregue metadatos de blob mediante los pares de clave-valor descritos anteriormente.

Consideraciones para los trabajos de exportación

Se deben tener en cuenta los siguientes aspectos al exportar datos con un trabajo de exportación:

Solo se puede ejecutar una acción de importación o exportación a la vez. Por ejemplo, si un trabajo de exportación está en curso y se intenta iniciar otro trabajo de exportación, se devuelve un error.

Copiar un contenedor de blobs de Lustre con AzCopy o el Explorador de Storage

Puede mover o copiar el contenedor de blobs que usa Lustre mediante AzCopy o el Explorador de Storage.

Para AzCopy, puede incluir atributos de directorio agregando la siguiente marca:

--include-directory-stub

Al incluir esta marca se conservan los atributos POSIX del directorio durante una transferencia, por ejemplo, owner, group y permissions. Si usa azcopy en el contenedor de almacenamiento sin esta marca o con la marca establecida en false, los datos y directorios se incluyen en la transferencia, pero los directorios no conservan sus atributos POSIX.

En el Explorador de Storage, puede habilitar esta marca en Configuración seleccionando Transferencias y activando la casilla Incluir códigos auxiliares de directorio.