Använda Azure Blob Storage med Azure Managed Lustre

Artikel
05/24/2024

Azure Managed Lustre integreras med Azure Blob Storage för att förenkla processen med att importera data från en blobcontainer till ett filsystem. Du kan också exportera data från filsystemet till en blobcontainer för långsiktig lagring. Den här artikeln beskriver begrepp för att använda blobintegrering med Azure Managed Lustre-filsystem.

Information om vilka krav och konfigurationer som krävs för en kompatibel blobcontainer finns i Krav för blobintegrering.

Översikt över blobintegrering

Du kan konfigurera blobintegrering när klustret skapas och du kan skapa ett importjobb när som helst när klustret har skapats. När data har importerats kan du arbeta med data på samma sätt som med andra filsystemdata. När nya filer skapas eller befintliga filer ändras i filsystemet kan du exportera filerna tillbaka till lagringskontot genom att köra Lustre CLI-kommandon på klienten eller genom att exportera data med hjälp av exportjobb.

När du importerar data från en blobcontainer till ett Azure Managed Lustre-filsystem importeras endast filnamnen (namnområdet) och metadata till Lustre-namnområdet. Det faktiska innehållet i en blob importeras när den först används av en klient. Det uppstår en liten fördröjning när du först kommer åt data medan funktionen Lustre Hierarchical Storage Management (HSM) hämtar blobinnehållet till motsvarande fil i filsystemet.

Du kan förinstallera innehållet i blobar med hjälp av Lustre-kommandot lfs hsm_restore från en monterad klient med sudo-funktioner. Följande kommando förinstallerar innehållet i blobarna i filsystemet:

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

Azure Managed Lustre fungerar med lagringskonton som har hierarkiskt namnområde aktiverat och lagringskonton med ett icke-hierarkiskt eller platt namnområde. Följande mindre skillnader gäller:

För ett lagringskonto med hierarkiskt namnområde aktiverat läser Azure Managed Lustre POSIX-attribut från blobhuvudet.
För ett lagringskonto som inte har hierarkiskt namnområde aktiverat läser Azure Managed Lustre POSIX-attribut från blobmetadata. En separat, tom fil med samma namn som innehållet i blobcontainern skapas för att lagra metadata. Den här filen är ett syskon till den faktiska datakatalogen i Azure Managed Lustre-filsystemet.

Importera data från Blob Storage

Du kan konfigurera integrering med Blob Storage när klustret skapas och du kan skapa ett importjobb när som helst när klustret har skapats.

Krav för blobcontainer

När du konfigurerar blobintegrering när klustret skapas måste du identifiera två separata blobcontainrar: containern som ska importeras och loggningscontainern. Containern som ska importeras innehåller de data som du vill importera till Azure Managed Lustre-filsystemet. Loggningscontainern används för att lagra loggar för importjobbet. Dessa två containrar måste finnas i samma lagringskonto. Mer information om kraven för blobcontainern finns i Krav för blobintegrering.

Importera prefix

När du importerar data från en blobcontainer kan du ange ett eller flera prefix för att filtrera data som importerats till Azure Managed Lustre-filsystemet. Filnamn i blobcontainern som matchar ett av prefixen läggs till i en metadatapost i filsystemet. När en klient först kommer åt en fil hämtas dess innehåll från blobcontainern och lagras i filsystemet.

I Azure Portal använder du fälten Importera prefix på fliken Avancerat när klustret skapas för att ange vilka data som ska importeras från blobcontainern. De här fälten gäller endast för det första importjobbet. Du kan inte ändra importprefixet när klustret har skapats.

För ett importjobb kan du ange importprefix när du skapar jobbet. Från Azure Portal kan du ange importprefix i fälten Importera prefix. Du kan också ange importprefixet när du använder REST-API:et för att skapa ett importjobb.

Tänk på följande när du anger importprefix:

Standardimportprefixet är /. Det här standardbeteendet importerar innehållet i hela blobcontainern.
Om du anger flera prefix måste prefixen inte överlappa varandra. Om du till exempel anger /data och /data2misslyckas importjobbet eftersom prefixen överlappar varandra.
Om blobcontainern finns i ett lagringskonto med hierarkiskt namnområde aktiverat kan du se prefixet som en filsökväg. Objekt under sökvägen ingår i Azure Managed Lustre-filsystemet.
Om blobcontainern finns i ett lagringskonto med ett icke-hierarkiskt (eller platt) namnområde kan du tänka på importprefixet som en söksträng som jämförs med början av blobnamnet. Om namnet på en blob i containern börjar med strängen som du angav som importprefix görs filen tillgänglig i filsystemet. Lustre är ett hierarkiskt filsystem och / tecken i blobnamn blir katalogavgränsare när de lagras i Lustre.

Konfliktlösningsläge

När du importerar data från en blobcontainer kan du ange hur du ska hantera konflikter mellan blobcontainern och filsystemet. Det här alternativet gäller endast för importjobb som körs för befintliga kluster. I följande tabell visas tillgängliga konfliktlösningslägen och deras beskrivningar:

Läge	Description
`fail`	Importjobbet misslyckas omedelbart med ett fel om en konflikt identifieras.
`skip`	Importjobbet hoppar över filen om en konflikt identifieras.
`overwrite-dirty`	Importjobbet utvärderar en sökväg i konflikt för att se om den ska tas bort och importeras igen. Mer information finns i overwrite-dirty mode (Skriv över-smutsigt läge).
`overwrite-always`	Importjobbet utvärderar en sökväg i konflikt och tar alltid bort/importerar om den är smutsig eller släpps om den är ren. Mer information finns i overwrite-always mode (Skriv över alltid-läge).

Skriv över smutsigt läge

Läget overwrite-dirty utvärderar en sökväg i konflikt för att se om den ska tas bort och importeras igen. På hög nivå overwrite-dirty kontrollerar läget HSM-tillståndet. Om HSM-tillståndet är Rensat och arkiverat, vilket innebär att dess data är synkroniserade med blobcontainern så vitt Lustre kan se, uppdateras endast attributen om det behövs. Annars tas filen bort och importeras på nytt från blobcontainern.

Att kontrollera HSM-tillståndet garanterar inte att filen i Lustre matchar filen i blobcontainern. Om du måste se till att filen i Lustre matchar filen i blobcontainern så nära som möjligt använder du overwrite-always läget.

Skriv över alltid-läge

Läget overwrite-always utvärderar en sökväg i konflikt och tar alltid bort/importerar om den är smutsig eller släpps om den är ren. Det här läget är användbart när du vill se till att filsystemet alltid är synkroniserat med blobcontainern. Det är också det dyraste alternativet eftersom varje tidigare återställd fil antingen släpps eller tas bort/importeras på nytt vid första åtkomsten.

Feltolerans

När du importerar data från en blobcontainer kan du ange feltoleransen. Feltoleransnivån avgör hur importjobbet hanterar tillfälliga fel som inträffar under importen, till exempel operativsystemfel eller nätverksavbrott. Observera att fel i den här kontexten inte refererar till filkonflikter som hanteras av konfliktlösningsläget.

Följande feltoleransalternativ är tillgängliga för importjobb:

Tillåt inte fel (standard): Importjobbet misslyckas omedelbart om något fel inträffar under importen. Det här är standardbeteendet.
Tillåt fel: Importjobbet fortsätter om ett fel inträffar och felet loggas. När importjobbet har slutförts kan du visa fel i loggningscontainern.

Överväganden för blobimportjobb

Följande objekt är viktiga att tänka på när du importerar data från en blobcontainer:

Endast en import- eller exportåtgärd kan köras i taget. Om ett importjobb till exempel pågår returnerar försök att starta ett annat importjobb ett fel.
Importjobb kan avbrytas. Du kan avbryta ett importjobb som startats i ett befintligt kluster eller ett importjobb som initierades när klustret skapades.
Klusterdistributionen kan returneras innan motsvarande importjobb har slutförts. Importjobbet fortsätter att köras i bakgrunden. Du kan övervaka importjobbets förlopp på följande sätt:
- Azure Portal: Azure Portal visar status för importjobbet. Navigera till filsystemet och välj Blob-integrering för att visa importjobbets status.
- Lustre-fil i rotkatalogen: En fil med namnet liknande /lustre/IMPORT_<state>.<timestamp_start> skapas i Lustre-rotkatalogen under importen. Platshållaren <state> ändras när importen fortskrider. Filen tas bort när importjobbet har slutförts.
Om du vill visa information om ett slutfört importjobb kan du kontrollera loggningscontainern. Loggningscontainern innehåller loggar för importjobbet, inklusive eventuella fel eller konflikter som inträffade under importen.
Om importjobbet misslyckas av någon anledning kanske du inte har fullständig statistik om importjobbet, till exempel antalet filer som importeras eller antalet konflikter.

Exportera data till Blob Storage med hjälp av ett exportjobb

Du kan kopiera data från ditt Azure Managed Lustre-filsystem till långsiktig lagring i Azure Blob Storage genom att skapa ett exportjobb.

Vilka filer exporteras under ett exportjobb?

När du exporterar filer från ditt Azure Managed Lustre-system kopieras inte alla filer till blobcontainern som du angav när du skapade filsystemet. Följande regler gäller för exportjobb:

Exportera jobb kopierar endast filer som är nya eller vars innehåll ändras. Om filen som du importerade från blobcontainern när filsystemet skapades är oförändrad exporterar inte exportjobbet filen.
Filer med metadataändringar exporteras inte. Metadataändringar inkluderar: ägare, behörigheter, utökade attribut och namnändringar (omdöpt).
Filer som tas bort i Azure Managed Lustre-filsystemet tas inte bort i den ursprungliga blobcontainern under exportjobbet. Exportjobbet tar inte bort filer i blobcontainern.

Köra exportjobb i aktiva filsystem

I aktiva filsystem kan ändringar i filer under exportjobbet resultera i felstatus. Den här felstatusen visar att inte alla data i filsystemet kunde exporteras till Blob Storage. I det här fallet kan du försöka exportera igen genom att skapa ett nytt exportjobb. Det nya jobbet kopierar bara de filer som inte kopierats i föregående jobb.

I filsystem med mycket aktivitet kan återförsök misslyckas flera gånger eftersom filer ändras ofta. Kontrollera att en fil har exporterats till Blob Storage genom att kontrollera tidsstämpeln för motsvarande blob. När jobbet är klart kan du också visa loggningscontainern som konfigurerades vid distributionen för att se detaljerad information om exportjobbet. Loggningscontainern innehåller diagnostisk information om vilka filer som misslyckades och varför de misslyckades.

Om du förbereder att inaktivera ett kluster och vill utföra en slutlig export till Blob Storage bör du se till att alla I/O-aktiviteter stoppas innan du påbörjar exportjobbet. Den här metoden hjälper till att garantera att alla data exporteras genom att undvika fel på grund av filsystemaktivitet.

Metadata för exporterade filer

När filer exporteras från Azure Managed Lustre-filsystemet till blobcontainern sparas ytterligare metadata för att förenkla återimporten av innehållet till ett filsystem.

I följande tabell visas POSIX-attribut från Lustre-filsystemet som sparas i blobmetadata som nyckel/värde-par:

POSIX-attribut	Typ
`owner`	int
`group`	int
`permissions`	octal- eller rwxrwxrwx-format; sticky bit stöds

Katalogattribut sparas i en tom blob. Den här bloben har samma namn som katalogsökvägen och innehåller följande nyckel/värde-par i blobmetadata: hdi_isfolder : true.

Du kan ändra POSIX-attributen manuellt innan du använder containern för att hydratisera ett nytt Lustre-kluster. Redigera eller lägg till blobmetadata med hjälp av nyckel/värde-paren som beskrevs tidigare.

Överväganden för exportjobb

Följande objekt är viktiga att tänka på när du exporterar data med ett exportjobb:

Endast en import- eller exportåtgärd kan köras i taget. Om ett exportjobb till exempel pågår returnerar försök att starta ett annat exportjobb ett fel.

Kopiera en Lustre-blobcontainer med AzCopy eller Storage Explorer

Du kan flytta eller kopiera den blobcontainer som Lustre använder med hjälp av AzCopy eller Storage Explorer.

För AzCopy kan du inkludera katalogattribut genom att lägga till följande flagga:

--include-directory-stub

Om du inkluderar den här flaggan bevaras katalog-POSIX-attribut under en överföring, ownertill exempel , groupoch permissions. Om du använder azcopy i lagringscontainern utan den här flaggan, eller med flaggan inställd falsepå , inkluderas data och kataloger i överföringen, men katalogerna behåller inte sina POSIX-attribut.

I Storage Explorer kan du aktivera den här flaggan i Inställningar genom att välja Överföringar och markera kryssrutan Inkludera katalogstubbar.

Share via