Qu’est-ce que BlobFuse ? - BlobFuse2

Article
06/01/2023

BlobFuse est un pilote de système de fichiers virtuel pour Stockage Blob Azure. Utilisez BlobFuse pour accéder à vos données d’objet blob de blocs Azure par le biais du système de fichiers Linux.

À propos du projet open source BlobFuse2

BlobFuse2 est un projet open source qui utilise la bibliothèque open source libfuse (fuse3) pour communiquer avec le module de noyau FUSE Linux. BlobFuse2 implémente les opérations de système de fichiers à l’aide des API REST du Stockage Azure.

Le projet open source BlobFuse2 se trouve sur GitHub :

Licences

Le projet BlobFuse2 est concédé sous licence MIT.

Fonctionnalités

La liste complète des fonctionnalités BlobFuse2 se trouve dans le fichier LISEZMOI BlobFuse2. Voici quelques-unes des tâches clés que vous pouvez effectuer à l’aide de BlobFuse2 :

Monter un conteneur Stockage Blob Azure ou un système de fichiers Azure Data Lake Storage Gen2 sur Linux. (BlobFuse2 prend en charge les comptes de stockage avec des espaces de noms plats ou hiérarchiques configurés.)
Utiliser des opérations de système de fichiers de base comme mkdir, opendir, readdir, rmdir, open, read, create, write, close, unlink, truncate, stat et rename.
Utiliser la mise en cache de fichiers locaux pour améliorer les temps d’accès suivants.
Obtenir des insights sur les activités de montage et l’utilisation des ressources en utilisant le moniteur d’intégrité de BlobFuse2.

D’autres fonctionnalités clés dans BlobFuse2 sont les suivantes :

Streaming pour prendre en charge la lecture et l’écriture de fichiers volumineux
Téléchargements et chargements parallèles pour améliorer le temps d’accès aux fichiers volumineux
Montages multiples sur le même conteneur pour les charges de travail en lecture seule

Améliorations de BlobFuse2 de BlobFuse v1

Par rapport à la version v1, BlobFuse2 offre une meilleure prise en charge des fonctionnalités et de meilleures performances dans plusieurs scénarios utilisateur de BlobFuse v1. Pour obtenir la liste complète des améliorations, consultez le fichier LISEZMOI de BlobFuse2. Voici un résumé des améliorations apportées à BlobFuse2 à partir d’BlobFuse v1 :

Amélioration de la mise en cache
Meilleure prise en charge de la gestion par le biais de nouvelles commandes Azure CLI
Meilleure prise en charge des enregistrements
L’ajout de la diffusion en continu en écriture pour les fichiers volumineux (précédemment, seule la diffusion en lecture a été prise en charge)
Obtenir des informations sur les activités de montage et l’utilisation des ressources en utilisant le nouveau moniteur d’intégrité de BlobFuse2
Options de compatibilité et de mise à niveau pour les utilisateurs BlobFuse v1 existants
Vérification des versions et invite de mise à niveau
Prise en charge du chiffrement des fichiers de configuration

Consultez la liste des améliorations des performances de BlobFuse2 par rapport à BlobFuse v1.

Pour les utilisateurs de BlobFuse v1

Les améliorations apportées à BlobFuse2 constituent d’excellentes raisons d’effectuer la mise à niveau et la migration. Si vous n’êtes pas prêt pour la migration, vous pouvez utiliser BlobFuse2 pour monter un conteneur d’objets blob à l’aide des mêmes options de configuration et paramètres Azure CLI que vous avez utilisés avec BlobFuse v1.

Le guide de migration BlobFuse2 fournit tous les détails dont vous avez besoin pour la compatibilité et la migration de vos charges de travail actuelles.

Support

BlobFuse2 est pris en charge par Microsoft s’il est utilisé dans les limites spécifiées. Si vous rencontrez un problème, signalez-le sur GitHub.

Limites

BlobFuse2 ne garantit pas une conformité totale à POSIX, car il traduit simplement les requêtes en API REST Blob. Par exemple, les opérations de renommage sont atomiques dans POSIX, mais pas dans BlobFuse2.

Consultez la liste complète des différences entre un système de fichiers natif et BlobFuse2.

Différences entre le système de fichiers Linux et BlobFuse2

À bien des égards, vous pouvez utiliser le stockage monté sur BlobFuse2 comme un système de fichiers Linux natif. Le schéma de répertoire virtuel est le même, et utilise une barre oblique (/) utilisée comme délimiteur. Les opérations de système de fichiers de base telles que mkdir, opendir, readdirrmdir, open, read, create, write, close, unlink, truncate, stat et rename fonctionnent de la même façon que dans le système de fichiers Linux.

BlobFuse2 est différent du système de fichiers Linux de certaines manières clés :

Nombre de ReadDir des liens physiques :

Pour des raisons de performances, BlobFuse2 ne signale pas correctement les liens physiques à l’intérieur d’un répertoire. Pour les répertoires vides, le nombre de liens physiques retourné est 2. Pour les répertoires non vides, le nombre retourné est toujours 3, quel que soit le nombre réel de liens physiques.
Renommages non atomiques :

Stockage Blob Azure ne prend pas en charge les opérations de renommage atomique. Les renommages de fichiers uniques sont réalisés en deux opérations : une copie, suivie d’une suppression de l’original. Les renommages de répertoire énumèrent de manière récursive tous les fichiers du répertoire, puis renomment chacun d’eux.
Fichiers spéciaux :

BlobFuse2 prend uniquement en charge les répertoires, les fichiers normaux et les liens symboliques. Les fichiers spéciaux, tels que les fichiers d’appareil, les canaux et les sockets, ne sont pas pris en charge.
mkfifo :

La création de Fifo n’est pas prise en charge par BlobFuse2. Si vous tentez cette action, l’erreur « Fonction non implémentée » s’affichera.
chown et chmod :

Les comptes de stockage Data Lake Storage Gen2 prennent en charge les autorisations par objet et les listes de contrôle d’accès, contrairement aux objets blob de blocs d’espace de nom plat. Par conséquent, BlobFuse2 ne prend pas en charge les opérations chown et chmod pour les conteneurs d’objets blob de blocs montés. Les opérations sont prises en charge pour Data Lake Storage Gen2.
Fichiers ou canaux d’appareil :

BlobFuse2 ne prend pas en charge la création de fichiers ou de canaux d’appareil.
Extended-attributes (x-attrs) :

BlobFuse2 ne prend pas en charge les opérations extended-attributes (x-attrs).
Write-streaming :

La diffusion simultanée d’opérations de lecture et d’écriture sur des données de fichiers volumineuses peut produire des résultats imprévisibles. L’écriture simultanée dans le même objet blob à partir de threads différents n’est pas prise en charge.

Intégrité des données

La mise en cache des fichiers joue un rôle important dans l’intégrité des données lues et écrites dans un montage du système de fichiers stockage Blob. Nous vous recommandons d’utiliser le mode de diffusion en continu avec des fichiers volumineux, qui prend en charge la diffusion en continu pour les opérations de lecture et d’écriture. BlobFuse2 met en cache les blocs de fichiers de streaming en mémoire. Pour les fichiers plus petits qui ne se composent pas de blocs, l’ensemble du fichier est stocké en mémoire. Le cache de fichiers est le deuxième mode. Nous vous recommandons de mettre en cache de fichiers pour les charges de travail qui ne contiennent pas de fichiers volumineux, par exemple lorsque les fichiers sont stockés sur le disque dans leur intégralité.

BlobFuse2 prend en charge les opérations de lecture et d’écriture. La synchronisation continue des données écrites dans le stockage à l’aide d’autres API ou d’autres montages de BlobFuse2 n’est pas garantie. Pour l’intégrité des données, il faut éviter que plusieurs sources modifient le même objet blob, en particulier en même temps. Si une ou plusieurs applications tentent d’écrire simultanément des données dans un même fichier, des résultats inattendus peuvent se produire. Selon l’heure à laquelle sont effectuées les différentes opérations d’écriture et selon le niveau d’actualisation du cache pour chacune des opérations, il est possible que la dernière écriture gagne et que les précédentes soient perdues, ou plus généralement, que le fichier mis à jour ne soit pas à l’état souhaité.

Mise en cache de fichiers sur le disque

Lorsqu’un fichier est l’objet d’une opération d’écriture, les données sont d’abord conservées pour être mises en cache sur un disque local. Les données sont écrites dans le stockage d’objets blob uniquement après la fermeture du descripteur de fichier. Si un problème se produit lors de la tentative de conservation des données dans le stockage d’objets blob, vous recevrez un message d’erreur.

Diffusion en continu

Pour la diffusion en continu pendant les opérations de lecture et d’écriture, les blocs de données sont mis en cache en mémoire lorsqu’ils sont lus ou mis à jour. Les mises à jour sont vidées dans le stockage Azure lorsqu’un fichier est fermé ou lorsque la mémoire tampon est remplie de blocs sales.

La lecture du même objet blob à partir de plusieurs threads simultanés est prise en charge. Toutefois, les opérations d’écriture simultanées peuvent entraîner des résultats inattendus de données de fichier, y compris la perte de données. L’exécution d’opérations de lecture simultanées et une seule opération d’écriture est prise en charge, mais les données lues à partir de certains threads peuvent ne pas être actuelles.

Autorisations

Lorsqu’un conteneur est monté avec les options par défaut, tous les fichiers obtiennent 770 autorisations et sont accessibles uniquement par l’utilisateur qui effectue le montage. Pour autoriser tout utilisateur à accéder au montage BlobFuse2, montez BlobFuse2 à l’aide de l’option --allow-other. Vous pouvez également configurer cette option dans le fichier de configuration YAML.

Comme indiqué précédemment, les opérations chown et chmod sont prises en charge pour Data Lake Storage Gen2, mais pas pour les objets blob de blocs FNS. L’exécution d’une opération chmod sur un conteneur d’objets blob de blocs d’espace de nom plat monté retourne un message de réussite, alors que l’opération n’a pas réellement réussi.

Prise en charge des fonctionnalités

Ce tableau montre comment cette fonctionnalité est prise en charge dans votre compte ainsi que l’effet sur la prise en charge lorsque vous activez certaines fonctionnalités.

Type de compte de stockage	Stockage Blob (prise en charge par défaut)	Data Lake Storage Gen2 ¹	Network File System (NFS) 3.0 ¹	Protocole Transfert de fichiers FTP (SFTP) ¹
Usage général v2 Standard
Objets blob de blocs Premium

¹ Data Lake Storage Gen2, le protocole NFS 3.0 et SFTP requièrent tous un compte de stockage avec un espace de noms hiérarchique activé.