Share via

Vad är BlobFuse? – BlobFuse2

  • Artikel

BlobFuse är en virtuell filsystemdrivrutin för Azure Blob Storage. Använd BlobFuse för att komma åt dina befintliga Azure-blockblobdata via Linux-filsystemet.

Om BlobFuse2-öppen källkod-projektet

BlobFuse2 är ett öppen källkod projekt som använder libfuse öppen källkod-biblioteket (fuse3) för att kommunicera med Linux FUSE-kernelmodulen. BlobFuse2 implementerar filsystemåtgärder med hjälp av REST-API:er för Azure Storage.

Öppen källkod BlobFuse2-projektet finns på GitHub:

Licensiering

BlobFuse2-projektet licensieras under MIT-licensen.

Funktioner

En fullständig lista över BlobFuse2-funktioner finns i BlobFuse2 README. Det här är några av de viktigaste uppgifterna som du kan utföra med hjälp av BlobFuse2:

  • Montera en Azure Blob Storage container eller Azure Data Lake Storage Gen2 filsystem i Linux. (BlobFuse2 stöder lagringskonton med antingen flata namnrymder eller hierarkiskt namnområde konfigurerat.)
  • Använd grundläggande filsystemåtgärder som mkdir, opendir, readdir, rmdir, open, read, create, write, close, unlink, truncate, statoch rename.
  • Använd cachelagring av lokala filer för att förbättra efterföljande åtkomsttider.
  • Få insikter om monteringsaktiviteter och resursanvändning med hjälp av BlobFuse2 Health Monitor.

Andra viktiga funktioner i BlobFuse2 är:

  • Direktuppspelning för att stödja läsning och skrivning av stora filer
  • Parallella nedladdningar och uppladdningar för att förbättra åtkomsttiden för stora filer
  • Flera monteringar till samma container för skrivskyddade arbetsbelastningar

BlobFuse2-förbättringar från BlobFuse v1

BlobFuse2 har mer funktionsstöd och bättre prestanda i flera användarscenarier från BlobFuse v1. En omfattande lista över förbättringar finns i BlobFuse2 README. Här är en sammanfattning av förbättringar i BlobFuse2 från BlobFuse v1:

  • Förbättrad cachelagring
  • Mer hanteringsstöd via nya Azure CLI-kommandon
  • Mer loggningsstöd
  • Tillägg av skrivströmning för stora filer (tidigare stöddes endast läsströmning)
  • Ny BlobFuse2-hälsoövervakare som hjälper dig att få insikter om monteringsaktiviteter och resursanvändning
  • Kompatibilitets- och uppgraderingsalternativ för befintliga BlobFuse v1-användare
  • Frågor om versionskontroll och uppgradering
  • Stöd för konfigurationsfilkryptering

Se listan över prestandaförbättringar för BlobFuse2 från BlobFuse v1.

För BlobFuse v1-användare

Förbättringarna som tillhandahålls av BlobFuse2 är tvingande skäl att uppgradera och migrera till BlobFuse2. Om du inte är redo att migrera kan du använda BlobFuse2 för att montera en blobcontainer med samma konfigurationsalternativ och Azure CLI-parametrar som du använder med BlobFuse v1.

Migreringsguiden för BlobFuse2 innehåller all information du behöver för kompatibilitet och migrering av dina aktuella arbetsbelastningar.

Support

BlobFuse2 stöds av Microsoft om det används inom de angivna gränserna. Om du stöter på ett problem rapporterar du det på GitHub.

Begränsningar

BlobFuse2 garanterar inte 100 % POSIX-efterlevnad eftersom BlobFuse2 helt enkelt översätter begäranden till BLOB REST-API:er. Byt till exempel namn på åtgärder är atomiska i POSIX men inte i BlobFuse2.

Se den fullständiga listan över skillnader mellan ett inbyggt filsystem och BlobFuse2.

Skillnader mellan Linux-filsystemet och BlobFuse2

På många sätt kan du använda BlobFuse2-monterad lagring precis som det interna Linux-filsystemet. Det virtuella katalogschemat är detsamma och använder ett snedstreck (/) som avgränsare. Grundläggande filsystemåtgärder som mkdir, opendir, readdir, rmdir, open, read, create, write, close, unlink, truncate, och statrename fungerar på samma sätt som i Linux-filsystemet.

BlobFuse2 skiljer sig från Linux-filsystemet på några viktiga sätt:

  • Readdir antal hårda länkar:

    Av prestandaskäl rapporterar BlobFuse2 inte korrekt de hårda länkarna i en katalog. Antalet hårda länkar för tomma kataloger returneras som 2. Talet för icke-tomma kataloger returneras alltid som 3, oavsett det faktiska antalet hårda länkar.

  • Icke-atomiska namn:

    Azure Blob Storage stöder inte åtgärder för atomisk namnbyte. Namn på en fil är egentligen två åtgärder: en kopia och sedan en borttagning av originalet. Katalogen byter namn rekursivt och räknar upp alla filer i katalogen och byter namn på varje fil.

  • Särskilda filer:

    BlobFuse2 stöder endast kataloger, vanliga filer och symboliska länkar. Särskilda filer som enhetsfiler, pipes och socketar stöds inte.

  • mkfifo:

    Skapande av Fifo stöds inte av BlobFuse2. Om du försöker utföra den här åtgärden uppstår felet "funktionen har inte implementerats".

  • chown och chmod:

    Data Lake Storage Gen2 lagringskonton stöder per objektbehörigheter och ACL:er, men fns-blockblobar (flat namespace) har inte det. Därför stöder chown BlobFuse2 inte åtgärderna och chmod för monterade blockblobcontainrar. Åtgärderna stöds för Data Lake Storage Gen2.

  • Enhetsfiler eller rör:

    BlobFuse2 stöder inte skapande av enhetsfiler eller rör.

  • Extended-attributes (x-attrs):

    BlobFuse2 stöder inte åtgärder för utökade attribut (x-attrs).

  • Skrivströmning:

    Samtidig direktuppspelning av läs- och skrivåtgärder på stora fildata kan ge oförutsägbara resultat. Samtidig skrivning till samma blob från olika trådar stöds inte.

Dataintegritet

Cachelagring av filer spelar en viktig roll för integriteten för data som läs- och skrivs till en Blob Storage-filsystemmontering. Vi rekommenderar strömningsläge för användning med stora filer, som stöder strömning för både läs- och skrivåtgärder. BlobFuse2 cachelagrar block med strömmande filer i minnet. För mindre filer som inte består av block lagras hela filen i minnet. Filcachen är det andra läget. Vi rekommenderar filcachen för arbetsbelastningar som inte innehåller stora filer, till exempel när filer lagras på disken i sin helhet.

BlobFuse2 stöder läs- och skrivåtgärder. Kontinuerlig synkronisering av data som skrivits till lagring med hjälp av andra API:er eller andra monteringar av BlobFuse2 garanteras inte. För dataintegritet rekommenderar vi att flera källor inte ändrar samma blob, särskilt inte samtidigt. Om ett eller flera program försöker skriva till samma fil samtidigt kan resultatet vara oväntat. Beroende på tidpunkten för flera skrivåtgärder och cacheminnets färskhet för varje åtgärd kan resultatet vara att den senaste skrivaren vinner och att tidigare skrivningar går förlorade, eller att den uppdaterade filen vanligtvis inte är i avsett tillstånd.

Cachelagring av filer på disk

När en fil är föremål för en skrivåtgärd sparas först data i cacheminnet på en lokal disk. Data skrivs endast till Blob Storage när filreferensen har stängts. Om ett problem uppstår när data ska sparas i Blob Storage visas ett felmeddelande.

Strömning

För direktuppspelning under läs- och skrivåtgärder cachelagras datablock i minnet när de läs- eller uppdateringsfunktionerna. Uppdateringar töms till Azure Storage när en fil stängs eller när bufferten är fylld med felaktiga block.

Det finns stöd för att läsa samma blob från flera samtidiga trådar. Samtidiga skrivåtgärder kan dock resultera i oväntade fildataresultat, inklusive dataförlust. Samtidiga läsåtgärder och en enda skrivåtgärd stöds, men data som läss från vissa trådar kanske inte är aktuella.

Behörigheter

När en container monteras med standardalternativen får alla filer 770 behörigheter och är endast tillgängliga för den användare som utför monteringen. Om du vill tillåta alla användare att komma åt BlobFuse2-monteringen monterar du BlobFuse2 med hjälp --allow-other av alternativet . Du kan också konfigurera det här alternativet i YAML-konfigurationsfilen.

Som tidigare nämnts chown stöds åtgärderna och chmod för Data Lake Storage Gen2, men inte för FNS-blockblobar. Om du kör en chmod åtgärd mot en monterad FNS-blockblobcontainer returneras ett meddelande om att åtgärden lyckades, men åtgärden lyckas inte.

Funktionsstöd

Den här tabellen visar hur den här funktionen stöds i ditt konto och effekten på supporten när du aktiverar vissa funktioner.

Typ av lagringskonto Blob Storage (standardstöd) Data Lake Storage Gen2 1 NFS (Network File System) 3.0 1 SSH File Transfer Protocol (SFTP) 1
Standard generell användning v2 Ja Ja Ja Ja
Premium-blockblobar Ja Ja Ja Ja

1 Data Lake Storage Gen2, NFS 3.0-protokollet och SFTP stöder alla kräver ett lagringskonto som har ett hierarkiskt namnområde aktiverat.

Se även

Nästa steg