Uso de Azure Blob Storage con Azure Managed Lustre

Artículo
05/31/2024

Azure Managed Lustre se integra con Azure Blob Storage para simplificar el proceso de importación de datos desde un contenedor de blobs a un sistema de archivos. También puede exportar datos del sistema de archivos a un contenedor de blobs para el 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.

Introducción a 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 los datos como lo haría con otros datos del sistema de archivos. A medida que se crean archivos nuevos o los archivos existentes se modifican en el sistema de archivos, puede volver a exportar estos archivos a la cuenta de almacenamiento ejecutando comandos de la CLI de Lustre en el cliente o exportando los 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 lustre. El contenido real de un blob se importa cuando un cliente accede 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 en el archivo correspondiente en el sistema de archivos.

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

Azure Managed Lustre funciona con cuentas de almacenamiento que tienen habilitado el espacio de nombres jerárquico y cuentas de almacenamiento con un espacio de nombres no jerárquico o plano. Se aplican las siguientes diferencias menores:

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 de 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 contener los metadatos. Este archivo es un elemento relacionado con el directorio de datos real en el sistema de archivos de Azure Managed Lustre.

Importación desde 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 para el trabajo de importación. Estos dos contenedores deben estar en la misma cuenta de almacenamiento. Para más información sobre los requisitos del contenedor de blobs, consulte Requisitos previos de integración de blobs.

Importar prefijo

Al importar datos desde un contenedor de blobs, puede especificar opcionalmente 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 Azure Portal, 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 desde el 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 Azure Portal, puede especificar prefijos de importación en los campos Importar prefijos . 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 deben no superponerse. Por ejemplo, si especifica /data y /data2, se produce 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 acceso de archivo. Los elementos de 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, ese archivo se hace accesible en el sistema de archivos. Lustre es un sistema de archivos jerárquico y / los caracteres de los nombres de blobs se convierten en delimitadores de directorio cuando se almacenan en Lustre.

Modo de resolución de conflictos

Al importar datos desde un contenedor de blobs, puede especificar cómo controlar 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. En la tabla siguiente se muestran los modos de resolución de conflictos disponibles y sus descripciones:

Mode	Descripción
`fail`	El trabajo de importación produce 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 más información, consulte sobrescritura y modo desfasado.
`overwrite-always`	El trabajo de importación evalúa una ruta de acceso en conflicto y siempre elimina o vuelve a importar si está sucia o libera si está limpia. Para más información, consulte sobrescribir el modo always.

Modo sobrescrito

El overwrite-dirty modo evalúa una ruta de acceso en conflicto para ver si se debe eliminar y volver a importar. En un nivel alto, overwrite-dirty el modo comprueba el estado de HSM. Si el estado de HSM es Clean y Archived, lo que significa que sus datos están sincronizados con el contenedor de blobs en lo que se refiere a Lustre, solo se actualizan 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 en el contenedor de blobs. Si debe asegurarse de que el archivo de Lustre coincide con el archivo en el contenedor de blobs lo más cerca posible, use el overwrite-always modo .

Modo sobrescribir siempre

El overwrite-always modo evalúa una ruta de acceso en conflicto y siempre elimina o vuelve a importar si está sucia o libera si está limpia. Este modo es útil cuando 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 desde un contenedor de blobs, puede especificar la tolerancia a errores. El nivel de tolerancia a errores determina cómo el trabajo de importación controla 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 controlan 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 produce un error inmediatamente si se produce algún error durante la importación. Este es el comportamiento predeterminado.
Permitir errores: el trabajo de importación continúa si se produce un error 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 son importantes tener en cuenta al importar datos desde 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, al intentar iniciar otro trabajo de importación se devuelve un error.
Se pueden cancelar los trabajos de importación. 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 devolverse correctamente antes de que se complete el trabajo de importación correspondiente. El trabajo de importación continúa ejecutándose en segundo plano. Puede supervisar el progreso del trabajo de importación de las maneras siguientes:
- Azure Portal: Azure Portal 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 Lustre en el directorio raíz: se crea un archivo denominado similar al /lustre/IMPORT_<state>.<timestamp_start> que se crea en el directorio raíz de Lustre durante la importación. El <state> marcador de posición 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 para el trabajo de importación, incluidos los errores o conflictos que se produjeron durante la importación.
Si se produce un error en el trabajo de importación por cualquier motivo, es posible que no tenga estadísticas completas sobre el trabajo de importación, como el número de archivos importados o el número de conflictos.

Restauración de datos desde 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 desde un contenedor de blobs antes de que se acceda 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 de lfs hsm_restore Lustre desde un cliente montado con funcionalidades de sudo. El comando siguiente 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 de forma asincrónica una solicitud de restauración. 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 cola un gran número de entradas para la restauración en el servidor de metadatos. Este enfoque puede sobrecargar el servidor de metadatos y degradar 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 en 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: Creación de un script de restauración por lotes

En el ejemplo siguiente se muestra cómo crear un script para restaurar datos desde un contenedor de blobs en 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 ejemplo siguiente 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 ~7,5GiB/segundo.

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

Puede copiar datos desde el sistema de archivos de Azure Managed Lustre al almacenamiento a largo plazo en Azure Blob Storage mediante la creación de un trabajo de exportación.

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

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

Exportar trabajos solo copia archivos nuevos o cuyo contenido se modifica. Si el archivo que importó desde el contenedor de blobs durante la creación del sistema de archivos no cambia, el trabajo de exportación no exporta el archivo.
Los archivos con cambios de metadatos solo no se exportan. Los cambios de metadatos incluyen: propietario, permisos, atributos extendidos y cambios de nombre (cambiados de nombre).
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 archivos en el contenedor de blobs.

Ejecución de trabajos de exportación en sistemas de archivos activos

En los sistemas de archivos activos, los cambios en los archivos durante el trabajo de exportación pueden dar lugar a 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 mediante la creación de 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 ha exportado 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 tiempo de 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 por qué han fallado.

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

Metadatos para archivos exportados

Cuando los archivos se exportan desde el sistema de archivos de Azure Managed Lustre al contenedor de blobs, se guardan metadatos adicionales para simplificar la reinportación del contenido a un sistema de archivos.

En la tabla siguiente se enumeran los atributos POSIX del sistema de archivos lustre que se guardan en los metadatos del blob como pares clave-valor:

Atributo POSIX	Tipo
`owner`	int
`group`	int
`permissions`	octal o rwxrwxrwx formato; Se admite el bit sticky

Los atributos de directorio se guardan en un blob vacío. Este blob tiene el mismo nombre que la ruta de acceso del directorio y contiene el siguiente par 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 clave-valor descritos anteriormente.

Consideraciones para los trabajos de exportación

Los siguientes elementos son importantes tener en cuenta 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, al intentar iniciar otro trabajo de exportación se devuelve un error.

Copia de un contenedor de blobs de Lustre con AzCopy o Explorador de Storage

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

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

--include-directory-stub

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

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

Compartir a través de