Was ist BlobFuse? – BlobFuse2

Artikel
11/21/2024

Bei BlobFuse handelt es sich um einen virtuellen Dateisystemtreiber für Azure Blob Storage. Mithilfe von BlobFuse können Sie über das Linux-Dateisystem auf vorhandene Azure-Blockblobdaten zugreifen. Seitenblobs werden nicht unterstützt.

Informationen zum Open-Source-Projekt BlobFuse2

BlobFuse2 ist ein Open Source-Projekt, das über die Open Source-Bibliothek „libfuse“ (fuse3) mit dem Linux-Kernelmodul FUSE kommuniziert. BlobFuse2 implementiert Dateisystemvorgänge mithilfe der Azure Storage REST-APIs.

Das BlobFuse2-Open Source-Projekt befindet sich auf GitHub:

Lizenzierung

Das BlobFuse2-Projekt ist unter der MIT-Lizenz lizenziert.

Funktionen

Eine vollständige Liste der BlobFuse2-Features befindet sich in der BlobFuse2-Infodatei. Dies sind einige der zentralen Aufgaben, die Sie mithilfe von BlobFuse2 ausführen können:

Einbinden eines Azure Blob Storage-Containers oder eines Azure Data Lake Storage-Dateisystems unter Linux (BlobFuse2 unterstützt Speicherkonten, für die entweder flache Namespaces oder hierarchische Namespaces konfiguriert sind.)
Verwenden von grundlegenden Dateisystemvorgängen wie mkdir, opendir, readdir, rmdir, open, read, create, write, close, unlink, truncate, stat und rename.
Verwenden der lokalen Dateizwischenspeicherung zur Verbesserung der Zugriffszeiten für nachfolgende Vorgänge.
Erhalten von Einblicken in Einbindungsaktivitäten und die Ressourcennutzung mithilfe des BlobFuse2-Integritätsmonitors.

Weitere wichtige Features in BlobFuse2 umfassen Folgendes:

Streaming zur Unterstützung von Lese- und Schreibvorgängen für große Dateien
Parallele Downloads und Uploads zur Verbesserung der Zugriffszeit für große Dateien
Mehrere Bereitstellungen im gleichen Container für schreibgeschützte Workloads

Wichtig

Aufgrund bekannter Datenkonsistenzprobleme bei der Verwendung älterer Versionen von Blobfuse2 beim Streaming mit dem block-cache-Modus wird dringend empfohlen, dass alle Blobfuse2-Installationen auf Version 2.3.2 oder höher aktualisiert werden. Weitere Informationen finden Sie hier.

BlobFuse2-Verbesserungen gegenüber BlobFuse v1

BlobFuse2 bietet in mehreren Benutzerszenarien eine größere Featureunterstützung und verbesserte Leistung im Vergleich zu BlobFuse v1. Die umfassende Liste von Verbesserungen finden Sie in der BlobFuse2-Infodatei. Hier ist eine Zusammenfassung der Verbesserungen in BlobFuse2 im Vergleich zu BlobFuse v1:

Verbesserte Zwischenspeicherung
Umfassendere Verwaltungsunterstützung über neue Azure CLI-Befehle
Mehr Protokollierungsunterstützung
Das Hinzufügen von Schreibstreaming für große Dateien (vorher wurde nur Lesestreaming unterstützt)
Neuer BlobFuse2-Integritätsmonitor, damit Sie Einblicke in Einbindungsaktivitäten und die Ressourcennutzung erhalten
Kompatibilitäts- und Upgradeoptionen für vorhandene BlobFuse v1-Benutzer
Versionsüberprüfung und Upgradeaufforderungen
Unterstützung für die Verschlüsselung von Konfigurationsdateien

Sehen Sie sich die Liste der BlobFuse2-Leistungsverbesserungen im Vergleich zu BlobFuse v1 an.

Für BlobFuse v1-Benutzer

Die von BlobFuse2 gebotenen Verbesserungen sind überzeugende Gründe für das Upgrade auf und die Migration zu BlobFuse2. Wenn Sie noch nicht zur Migration bereit sind, können Sie mithilfe von BlobFuse2 einen Blobcontainer mit den gleichen Konfigurationsoptionen und Azure CLI-Parametern einbinden, die Sie bei BlobFuse v1 verwenden.

Der BlobFuse2-Migrationsleitfaden enthält alle Details, die Sie für die Kompatibilität und Migration Ihrer aktuellen Workloads benötigen.

Support

BlobFuse2 wird von Microsoft unterstützt, wenn die Verwendung innerhalb der angegebenen Grenzwerte erfolgt. Wenn Sie auf ein Problem stoßen, melden Sie es auf GitHub.

Einschränkungen

BlobFuse2 garantiert keine 100-prozentige Konformität mit POSIX, weil Anforderungen einfach in Blob-REST-APIs übersetzt werden. Beispielsweise sind Umbenennungsvorgänge in POSIX atomisch (unteilbar), aber nicht in BlobFuse2.

Sehen Sie sich die vollständige Liste der Unterschiede zwischen einem nativen Dateisystem und BlobFuse2 an.

Unterschiede zwischen dem Linux-Dateisystem und BlobFuse2

Sie können über BlobFuse2 eingebundenen Speicher in vielerlei Hinsicht genauso wie das native Linux-Dateisystem nutzen. Das Schema für virtuelle Verzeichnisse ist das gleiche und verwendet einen Schrägstrich (/) als Trennzeichen. Grundlegende Dateisystemvorgänge wie mkdir, opendir, readdir, rmdir, open, read, create, write, close, unlink, truncate, statund rename funktionieren genauso wie im Linux-Dateisystem.

BlobFuse2 unterscheidet sich in mancher Hinsicht vom Linux-Dateisystem:

Readdir-Anzahl von Hardlinks:

Aus Leistungsgründen meldet BlobFuse2 die Hardlinks in einem Verzeichnis nicht richtig. Als Anzahl der Hardlinks für leere Verzeichnisse wird „2“ zurückgegeben. Als Anzahl für nicht leere Verzeichnisse wird immer „3“ zurückgegeben – unabhängig von der tatsächlichen Anzahl von Hardlinks.
Nicht atomische Umbenennungen:

Azure Blob Storage unterstützt keine Vorgänge von atomischen Umbenennungen. Bei der Umbenennung einer einzelnen Datei werden tatsächlich zwei Vorgänge ausgeführt: Erstellen einer Kopie und anschließendes Löschen des Originals. Bei Verzeichnisumbenennungen werden alle Dateien im Verzeichnis rekursiv aufgelistet. Dann wird jede Datei umbenannt.
Spezielle Dateien:

BlobFuse2 unterstützt nur Verzeichnisse, reguläre Dateien und symbolische Verknüpfungen. Spezielle Dateien wie Gerätedateien, Pipes und Sockets werden nicht unterstützt.
mkfifo:

Die Erstellung per FIFO wird von BlobFuse2 nicht unterstützt. Wenn Sie versuchen, diese Aktion auszuführen, wird ein Fehler „Funktion nicht implementiert“ angezeigt.
chown und chmod:

Data Lake Storage-Speicherkonten unterstützen Berechtigungen und ACLs pro Objekt, aber keine FNS-Blockblobs (Flat Namespace, flacher Namespace). Daher unterstützt BlobFuse2 die Vorgänge chown und chmod für eingebundene Blockblobcontainer nicht. Die Vorgänge werden für Data Lake Storage unterstützt.
Gerätedateien oder Pipes:

BlobFuse2 unterstützt nicht das Erstellen von Gerätedateien oder Pipes.
Erweiterte Attribute (x-attrs):

BlobFuse2 unterstützt keine Vorgänge mit erweiterten Attributen (x-attrs).
Schreibstreaming:

Gleichzeitiges Streaming von Lese- und Schreibvorgängen in großen Dateidaten könnte zu unvorhersehbaren Ergebnissen führen. Gleichzeitiges Schreiben in dasselbe Blob aus verschiedenen Threads wird nicht unterstützt.

Datenintegrität

Die Dateizwischenspeicherung spielt eine wichtige Rolle bei der Integrität von Daten, die in eine Blob Storage-Dateisystemeinbindung gelesen und geschrieben werden. Wir empfehlen, den Streamingmodus bei großen Dateien zu verwenden, die Streaming für Lese- und Schreibvorgänge unterstützt. BlobFuse2 speichert Blöcke von Streamingdateien im Arbeitsspeicher zwischen. Bei kleineren Dateien, die nicht aus Blöcken bestehen, wird die gesamte Datei im Arbeitsspeicher gespeichert. Der Dateicache ist der zweite Modus. Wir empfehlen den Dateicache für Workloads, die keine großen Dateien enthalten, beispielsweise wenn Dateien vollständig auf dem Datenträger gespeichert werden.

BlobFuse2 unterstützt Lese- und Schreibvorgänge. Eine kontinuierliche Synchronisierung von Daten, die mithilfe von anderen APIs oder anderen BlobFuse2-Einbindungen in den Speicher geschrieben wurden, wird nicht garantiert. Aus Gründen der Datenintegrität raten wir davon ab, dass mehrere Quellen dasselbe Blob ändern, insbesondere nicht gleichzeitig. Wenn eine oder mehrere Anwendungen versuchen, gleichzeitig in dieselbe Datei zu schreiben, könnten die Ergebnisse unerwartet sein. Je nach dem Timing von mehreren Schreibvorgängen und der Aktualität des Caches bei jedem Vorgang könnte das Ergebnis so aussehen: Der letzte Schreibvorgang gewinnt, und vorherige Schreibvorgänge gehen verloren oder – ganz allgemein – die aktualisierte Datei ist nicht im beabsichtigten Zustand.

Dateizwischenspeicherung auf Datenträger

Wenn eine Datei Gegenstand eines Schreibvorgangs ist, werden die Daten zuerst auf einem lokalen Datenträger zwischengespeichert. Die Daten werden erst, nachdem das Dateihandle geschlossen wurde, in Blob Storage geschrieben. Wenn beim Versuch, die Daten in Blob Storage dauerhaft zu speichern, ein Problem auftritt, wird eine Fehlermeldung angezeigt.

Streaming

Beim Streaming werden Datenblöcke während Lese- und Schreibvorgängen im Arbeitsspeicher zwischengespeichert, während sie gelesen oder aktualisiert werden. Aktualisierungen werden in Azure Storage geleert, wenn eine Datei geschlossen oder der Puffer mit Dirty Blocks gefüllt ist.

Das Lesen desselben Blobs aus mehreren gleichzeitigen Threads wird unterstützt. Gleichzeitige Schreibvorgänge könnten jedoch zu unerwarteten Ergebnissen bei Dateidaten führen, einschließlich Datenverlust. Die Ausführung gleichzeitiger Lesevorgänge und eines einzelnen Schreibvorgangs wird unterstützt, aber die aus einigen Threads gelesenen Daten sind möglicherweise nicht aktuell.

Berechtigungen

Wenn ein Container mit den Standardoptionen eingebunden wird, erhalten alle Dateien die Berechtigungen „770“ und sind nur für den Benutzer zugänglich, der die Einbindung durchführt. Um jedem beliebigen Benutzer Zugriff auf die BlobFuse2-Einbindung zu ermöglichen, binden Sie BlobFuse2 mithilfe der Option --allow-other ein. Sie können diese Option auch in der YAML-Konfigurationsdatei konfigurieren.

Wie weiter oben erwähnt, werden die Vorgänge chown und chmod bei Data Lake Storage unterstützt, aber nicht bei FNS-Blockblobs. Bei der Ausführung eines chmod-Vorgangs für einen eingebundenen FNS-Blockblobcontainer wird eine Erfolgsmeldung zurückgegeben, der Vorgang tatsächlich aber nicht erfolgreich ausgeführt.

Featureunterstützung

Diese Tabelle zeigt, wie diese Funktion in Ihrem Konto unterstützt wird und welche Auswirkungen es auf den Support hat, wenn Sie bestimmte Funktionen aktivieren.

Speicherkontotyp	Blob Storage (Standardunterstützung)	Data Lake Storage¹	Network File System (NFS) 3.0 ¹	SSH-Dateiübertragungsprotokoll (File Transfer Protocol, SFTP) ¹
Standard „Allgemein v2“
Premium-Blockblobs

¹ Für Data Lake Storage, das NFS 3.0-Protokoll und die Unterstützung von SFTP ist ein Speicherkonto mit aktiviertem hierarchischem Namespace erforderlich.

Freigeben über