Utiliser le stockage Blob Azure avec Azure Managed Lustre

Article
11/11/2024

Azure Managed Lustre s’intègre à Stockage Blob Azure pour simplifier le processus d’importation de données à partir d’un conteneur d’objets blob vers un système de fichiers. Vous pouvez également exporter des données du système de fichiers vers un conteneur d’objets blob pour le stockage à long terme. Cet article explique les concepts d’utilisation de l’intégration d’objets blob avec les systèmes de fichiers Azure Managed Lustre.

Pour comprendre les exigences et la configuration requises pour un conteneur d’objets blob compatibles, consultez les conditions préalables à l’intégration d’objets blob.

Vue d’ensemble de l’intégration d’objets

Vous pouvez configurer l’intégration d’objets blob lors de la création du cluster et créer un travail d’importation à tout moment après la création du cluster. Une fois les données importées, vous pouvez utiliser les données comme vous le feriez avec d’autres données de système de fichiers. À mesure que de nouveaux fichiers sont créés ou que des fichiers existants sont modifiés dans le système de fichiers, vous pouvez les exporter vers le compte de stockage en exécutant des commandes CLI Lustre sur le client ou en exportant les données à l’aide de travaux d’exportation.

Lorsque vous importez des données à partir d’un conteneur d’objets blob dans un système de fichiers Azure Managed Lustre, seuls les noms de fichiers (espace de noms) et les métadonnées sont importés dans l’espace de noms Lustre. Le contenu réel d’un objet blob est importé lors de l’accès d’un client. Il existe un léger délai lors de l’accès aux données lors de l’extraction de la fonctionnalité HSM (Lustre Hierarchical Storage Management) dans le contenu de l’objet blob dans le fichier correspondant dans le système de fichiers.

Vous pouvez prérécupérer le contenu des objets blob à l’aide de la lfs hsm_restore commande de Lustre à partir d’un client monté avec des fonctionnalités sudo. Pour plus d’informations, consultez Restaurer des données à partir du stockage Blob.

Azure Managed Lustre fonctionne avec des comptes de stockage qui ont un espace de noms hiérarchique activé et des comptes de stockage avec un espace de noms non hiérarchique ou plat. Les différences mineures suivantes s’appliquent :

Pour un compte de stockage avec un espace de noms hiérarchique activé, Azure Managed Lustre lit les attributs POSIX à partir de l’en-tête d’objet blob.
Pour un compte de stockage qui n’a pas d’espace de noms hiérarchique activé, Azure Managed Lustre lit les attributs POSIX à partir des métadonnées d’objet blob. Un fichier distinct et vide portant le même nom que le contenu de votre conteneur d’objets blob est créé pour contenir les métadonnées. Ce fichier est un frère du répertoire de données réel dans le système de fichiers Azure Managed Lustre.

Importer à partir du stockage Blob

Vous pouvez configurer l’intégration au stockage Blob lors de la création du cluster, et vous pouvez créer un travail d’importation à tout moment après la création du cluster.

Configuration requise pour le conteneur d’objets blob

Lors de la configuration de l’intégration d’objets blob lors de la création du cluster, vous devez identifier deux conteneurs d’objets blob distincts : le conteneur à importer et le conteneur de journalisation. Le conteneur à importer contient les données que vous souhaitez importer dans le système de fichiers Azure Managed Lustre. Le conteneur de journalisation est utilisé pour stocker les journaux de la tâche d’importation. Ces deux conteneurs doivent se trouver dans le même compte de stockage. Pour en savoir plus sur les conditions requises pour le conteneur d’objets blob, consultez les conditions préalables à l’intégration d’objets blob.

Préfixe d’importation

Lors de l’importation de données à partir d’un conteneur d’objets blob, vous pouvez éventuellement spécifier un ou plusieurs préfixes pour filtrer les données importées dans le système de fichiers Azure Managed Lustre. Les noms de fichiers dans le conteneur d’objets blob qui correspondent à l’un des préfixes sont ajoutés à un enregistrement de métadonnées dans le système de fichiers. Lorsqu’un client accède d’abord à un fichier, son contenu est récupéré à partir du conteneur d’objets blob et stocké dans le système de fichiers.

Dans le Portail Azure, utilisez les champs Importer le préfixe sous l’onglet Avancé pendant la création du cluster pour spécifier les données à importer à partir de votre conteneur d’objets blob. Ces champs s’appliquent uniquement au travail d’importation initial. Vous ne pouvez pas modifier le préfixe d’importation une fois le cluster créé.

Pour un travail d’importation, vous pouvez spécifier des préfixes d’importation lorsque vous créez le travail. À partir de la Portail Azure, vous pouvez spécifier des préfixes d’importation dans les champs Importer le préfixe. Vous pouvez également spécifier le préfixe d’importation lorsque vous utilisez l’API REST pour créer un travail d’importation.

Gardez à l’esprit les considérations suivantes lors de la spécification des préfixes d’importation :

Le préfixe d’importation par défaut est /. Ce comportement par défaut importe le contenu de l’ensemble du conteneur d’objets blob.
Si vous spécifiez plusieurs préfixes, les préfixes doivent être sans chevauchement. Par exemple, si vous spécifiez /data et /data2que le travail d’importation échoue, car les préfixes se chevauchent.
Si le conteneur d’objets blob se trouve dans un compte de stockage avec un espace de noms hiérarchique activé, vous pouvez considérer le préfixe comme un chemin d’accès de fichier. Les éléments sous le chemin d’accès sont inclus dans le système de fichiers Azure Managed Lustre.
Si le conteneur d’objets blob se trouve dans un compte de stockage avec un espace de noms non hiérarchique (ou plat), vous pouvez considérer le préfixe d’importation comme une chaîne de recherche qui est comparée au début du nom de l’objet blob. Si le nom d’un objet blob dans le conteneur commence par la chaîne que vous avez spécifiée comme préfixe d’importation, ce fichier est rendu accessible dans le système de fichiers. Lustre est un système de fichiers hiérarchique, et / les caractères dans les noms d’objets blob deviennent des délimiteurs de répertoire lorsqu’ils sont stockés dans Lustre.

Mode de résolution des conflits

Lors de l’importation de données à partir d’un conteneur d’objets blob, vous pouvez spécifier comment gérer les conflits entre le conteneur d’objets blob et le système de fichiers. Cette option s’applique uniquement aux travaux d’importation qui sont exécutés pour les clusters existants. Le tableau suivant présente les modes de résolution des conflits disponibles et leurs descriptions :

Mode	Description
`fail`	Le travail d’importation échoue immédiatement avec une erreur si un conflit est détecté.
`skip`	Le travail d’importation ignore le fichier si un conflit est détecté.
`overwrite-dirty`	Le travail d’importation évalue un chemin d’accès en conflit pour voir s’il doit être supprimé et réimporté. Pour en savoir plus, consultez le mode remplacer-dirty.
`overwrite-always`	Le travail d’importation évalue un chemin en conflit et supprime toujours/réimporte s’il est sale ou libère s’il est propre. Pour plus d’informations, consultez le mode remplacer-always.

Mode de remplacement sale

Le overwrite-dirty mode évalue un chemin en conflit pour voir s’il doit être supprimé et réimporté. À un niveau élevé, overwrite-dirty le mode vérifie l’état du HSM. Si l’état HSM est Propre et Archivé, ce qui signifie que ses données sont synchronisées avec le conteneur d’objets blob jusqu’à Lustre, seuls les attributs sont mis à jour, si nécessaire. Sinon, le fichier est supprimé et réimporté à partir du conteneur d’objets blob.

La vérification de l’état HSM ne garantit pas que le fichier dans Lustre correspond au fichier dans le conteneur d’objets blob. Si vous devez vous assurer que le fichier dans Lustre correspond au fichier dans le conteneur d’objets blob aussi étroitement que possible, utilisez le overwrite-always mode.

Remplacer le mode always

Le overwrite-always mode évalue un chemin en conflit et supprime toujours/réimporte s’il est sale ou libère s’il est propre. Ce mode est utile lorsque vous souhaitez vous assurer que le système de fichiers est toujours synchronisé avec le conteneur d’objets blob. Il s’agit également de l’option la plus coûteuse, car chaque fichier précédemment restauré est publié ou supprimé/réimporté lors de la première accès.

Tolérance d’erreur

Lors de l’importation de données à partir d’un conteneur d’objets blob, vous pouvez spécifier la tolérance d’erreur. Le niveau de tolérance d’erreur détermine comment le travail d’importation gère les erreurs temporaires qui se produisent pendant le processus d’importation, par exemple, les erreurs du système d’exploitation ou les interruptions réseau. Il est important de noter que les erreurs dans ce contexte ne font pas référence aux conflits de fichiers, qui sont gérés par le mode de résolution des conflits.

Les options de tolérance d’erreur suivantes sont disponibles pour les travaux d’importation :

Ne pas autoriser les erreurs (valeur par défaut) : la tâche d’importation échoue immédiatement si une erreur se produit pendant l’importation. C’est le paramétrage par défaut.
Autoriser les erreurs : la tâche d’importation se poursuit si une erreur se produit et que l’erreur est enregistrée. Une fois la tâche d’importation terminée, vous pouvez afficher les erreurs dans le conteneur de journalisation.

Considérations relatives aux travaux d’importation d’objets blob

Les éléments suivants sont importants à prendre en compte lors de l’importation de données à partir d’un conteneur d’objets blob :

Une seule action d’importation ou d’exportation peut s’exécuter à la fois. Par exemple, si un travail d’importation est en cours, la tentative de démarrage d’un autre travail d’importation retourne une erreur.
Les travaux d’importation peuvent être annulés. Vous pouvez annuler un travail d’importation démarré sur un cluster existant ou un travail d’importation lancé lors de la création du cluster.
Le déploiement de cluster peut retourner correctement avant la fin du travail d’importation correspondant. Le travail d’importation continue à s’exécuter en arrière-plan. Vous pouvez surveiller la progression du travail d’importation de la manière suivante :
- Portail Azure : le Portail Azure affiche l’état du travail d’importation. Accédez au système de fichiers et sélectionnez Intégration d’objets blob pour afficher l’état du travail d’importation.
- Fichier Lustre dans le répertoire racine : un fichier nommé similaire à celui-ci /lustre/IMPORT_<state>.<timestamp_start> est créé dans le répertoire racine Lustre pendant l’importation. L’espace <state> réservé change à mesure que l’importation progresse. Le fichier est supprimé une fois la tâche d’importation terminée.
Pour afficher des détails sur un travail d’importation terminé, vous pouvez vérifier le conteneur de journalisation. Le conteneur de journalisation contient les journaux de la tâche d’importation, y compris les erreurs ou les conflits qui se sont produits pendant l’importation.
Si le travail d’importation échoue pour une raison quelconque, il se peut que vous n’ayez pas de statistiques complètes sur la tâche d’importation, telles que le nombre de fichiers importés ou le nombre de conflits.

Restaurer des données à partir du stockage Blob

Par défaut, le contenu d’un objet blob est importé dans un système de fichiers la première fois que le fichier correspondant est accessible par un client. Pour certaines charges de travail et scénarios, vous préférerez peut-être restaurer les données à partir d’un conteneur d’objets blob avant son premier accès. Vous pouvez choisir de prérécupérer le contenu des objets blob pour éviter le délai initial d’accès à l’objet blob pour la première fois après l’importation. Pour prérécupérer le contenu des objets blob, vous pouvez utiliser la commande de Lustre à partir d’un lfs hsm_restore client monté avec des fonctionnalités sudo. La commande suivante prérécupère le contenu des objets blob dans le système de fichiers :

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

Cette commande indique au serveur de métadonnées de traiter de manière asynchrone une demande de restauration. La ligne de commande n’attend pas la fin de la restauration, ce qui signifie que la ligne de commande peut mettre en file d’attente un grand nombre d’entrées pour la restauration sur le serveur de métadonnées. Cette approche peut surcharger le serveur de métadonnées et dégrader les performances des restaurations.

Pour éviter ce problème potentiel de performances, vous pouvez créer un script de base qui tente de parcourir le chemin d’accès et émet des demandes de restauration par lots d’une taille spécifiée. Pour obtenir des performances raisonnables et éviter d’accablant le serveur de métadonnées, il est recommandé d’utiliser des tailles de lots allant de 1 000 à 5 000 requêtes.

Exemple : Créer un script de restauration par lots

L’exemple suivant montre comment créer un script pour restaurer des données à partir d’un conteneur d’objets blob par lots. Créez un fichier nommé file_restorer.bash avec le contenu suivant :

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

L’exemple suivant montre comment exécuter le script avec l’exemple de sortie :

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

Remarque

À ce stade, Azure Managed Lustre restaure les données à partir du stockage Blob à un débit maximal de ~7,5GiB/seconde.

Exporter des données vers le stockage Blob à l’aide d’un travail d’exportation

Vous pouvez copier des données de votre système de fichiers Azure Managed Lustre vers un stockage à long terme dans Stockage Blob Azure en créant un travail d’exportation.

Quels fichiers sont exportés pendant un travail d’exportation ?

Lorsque vous exportez des fichiers à partir de votre système Azure Managed Lustre, tous les fichiers ne sont pas copiés dans le conteneur d’objets blob que vous avez spécifié lors de la création du système de fichiers. Les règles suivantes s’appliquent aux travaux d’exportation :

Exportez uniquement des travaux qui copient des fichiers nouveaux ou dont le contenu est modifié. Si le fichier que vous avez importé à partir du conteneur d’objets blob pendant la création du système de fichiers n’est pas modifié, la tâche d’exportation n’exporte pas le fichier.
Les fichiers avec des modifications de métadonnées ne sont pas exportés uniquement. Les modifications de métadonnées sont les suivantes : propriétaire, autorisations, attributs étendus et modifications de nom (renommées).
Les fichiers supprimés dans le système de fichiers Azure Managed Lustre ne sont pas supprimés dans le conteneur d’objets blob d’origine pendant la tâche d’exportation. Le travail d’exportation ne supprime pas les fichiers dans le conteneur d’objets blob.

Exécution de travaux d’exportation dans des systèmes de fichiers actifs

Dans les systèmes de fichiers actifs, les modifications apportées aux fichiers pendant le travail d’exportation peuvent entraîner un état d’échec. Cet état d’échec vous permet de savoir que toutes les données du système de fichiers peuvent être exportées vers le stockage Blob. Dans ce cas, vous pouvez réessayer l’exportation en créant un travail d’exportation. Le nouveau travail copie uniquement les fichiers qui n’ont pas été copiés dans le travail précédent.

Dans les systèmes de fichiers avec beaucoup d’activités, les nouvelles tentatives peuvent échouer plusieurs fois, car les fichiers changent fréquemment. Pour vérifier qu’un fichier a été correctement exporté vers le stockage Blob, vérifiez l’horodatage sur l’objet blob correspondant. Une fois le travail terminé, vous pouvez également afficher le conteneur de journalisation configuré au moment du déploiement pour afficher des informations détaillées sur le travail d’exportation. Le conteneur de journalisation fournit des informations de diagnostic sur les fichiers qui ont échoué et pourquoi ils ont échoué.

Si vous préparez à désactiver un cluster et que vous souhaitez effectuer une exportation finale vers le stockage Blob, vous devez vous assurer que toutes les activités d’E/S sont arrêtées avant de lancer la tâche d’exportation. Cette approche permet de garantir que toutes les données sont exportées en évitant les erreurs en raison de l’activité du système de fichiers.

Métadonnées pour les fichiers exportés

Lorsque des fichiers sont exportés du système de fichiers Azure Managed Lustre vers le conteneur d’objets blob, des métadonnées supplémentaires sont enregistrées pour simplifier l’importation du contenu vers un système de fichiers.

Le tableau suivant répertorie les attributs POSIX du système de fichiers Lustre enregistrés dans les métadonnées de l’objet blob sous forme de paires clé-valeur :

Attribut POSIX	Type
`owner`	int
`group`	int
`permissions`	octal ou rwxrwxrwx format ; Le bit sticky est pris en charge

Les attributs d’annuaire sont enregistrés dans un objet blob vide. Cet objet blob porte le même nom que le chemin d’accès au répertoire et contient la paire clé-valeur suivante dans les métadonnées de l’objet blob : hdi_isfolder : true.

Vous pouvez modifier manuellement les attributs POSIX avant d’utiliser le conteneur pour hydrater un nouveau cluster Lustre. Modifiez ou ajoutez des métadonnées d’objet blob à l’aide des paires clé-valeur décrites précédemment.

Considérations relatives aux travaux d’exportation

Les éléments suivants sont importants à prendre en compte lors de l’exportation de données avec un travail d’exportation :

Une seule action d’importation ou d’exportation peut s’exécuter à la fois. Par exemple, si un travail d’exportation est en cours, la tentative de démarrage d’un autre travail d’exportation retourne une erreur.

Copiez un conteneur d’objets blob Lustre avec AzCopy ou Explorateur Stockage

Vous pouvez déplacer ou copier le conteneur d’objets blob à l’aide d’AzCopy ou de Explorateur Stockage.

Pour AzCopy, vous pouvez inclure des attributs de répertoire en ajoutant l’indicateur suivant :

--include-directory-stub

L’inclusion de cet indicateur conserve les attributs POSIX du répertoire pendant un transfert, par exemple, owner, groupet permissions. Si vous utilisez azcopy sur le conteneur de stockage sans cet indicateur ou avec l’indicateur défini falsesur , les données et les répertoires sont inclus dans le transfert, mais les répertoires ne conservent pas leurs attributs POSIX.

Dans Explorateur Stockage, vous pouvez activer cet indicateur dans Paramètres en sélectionnant Transferts et en cochant la case Pour inclure des stubs d’annuaire.

Partager via