Använda Azure Blob Storage med Azure Managed Lustre

Artikel
01/10/2025

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. I den här artikeln beskrivs begrepp för att använda blobintegrering med Azure Managed Lustre-filsystem.

Information om vilka krav och konfiguration 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 efter att 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 finns 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. Mer information finns i Återställa data från Blob Storage.

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 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 efter att 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 på 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:

Standardprefixet för import ä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 se 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	beskrivning
`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äpper den om den är ren. Mer information finns i läget skriv över alltid.

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 igen 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 importprocessen, till exempel operativsystemfel eller nätverksavbrott. Det är viktigt att 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 uppstår 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 status för importjobbet.
- Lustre-fil i rotkatalogen: En fil med namnet liknar /lustre/IMPORT_<state>.<timestamp_start> skapas i Lustre-rotkatalogen under importen. Platshållaren <state> ändras under importens gång. 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.

Återställa data från Blob Storage

Som standard importeras innehållet i en blob till ett filsystem första gången motsvarande fil används av en klient. För vissa arbetsbelastningar och scenarier kanske du föredrar att återställa data från en blobcontainer innan de först används. Du kan välja att förinställa innehållet i blobar för att undvika den inledande fördröjningen när bloben används för första gången efter importen. Om du vill förinstallera innehållet i blobar kan du använda 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 &

Det här kommandot instruerar metadataservern att asynkront bearbeta en återställningsbegäran. Kommandoraden väntar inte på att återställningen ska slutföras, vilket innebär att kommandoraden har potential att köa ett stort antal poster för återställning på metadataservern. Den här metoden kan överbelasta metadataservern och försämra prestanda för återställningar.

För att undvika det här potentiella prestandaproblemet kan du skapa ett grundläggande skript som försöker gå i sökvägen och problem med återställningsbegäranden i batchar med en angiven storlek. För att uppnå rimliga prestanda och undvika att överbelasta metadataservern rekommenderar vi att du använder batchstorlekar var som helst från 1 000 till 5 000 begäranden.

Exempel: Skapa ett batchåterställningsskript

I följande exempel visas hur du skapar ett skript för att återställa data från en blobcontainer i batchar. Skapa en fil med namnet file_restorer.bash med följande innehåll:

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

I följande exempel visas hur du kör skriptet tillsammans med exempelutdata:

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

Kommentar

För närvarande återställer Azure Managed Lustre data från Blob Storage med en maximal dataflödeshastighet på ~7,5GiB/sekund.

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 den blobcontainer 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 den fil 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.
Blobnamn måste överensstämma med vissa namngivningsregler, vilket innebär att acceptabla blobnamn skiljer sig något från godkända POSIX-filnamn. Exportprocessen bevarar specialtecken i filnamn genom att ta bort dem när de exporteras till blobar. Ett filnamn som bryter mot en namngivningsregel för blobar, till exempel ett filnamn som överskrider den maximala längden på blobnamn, resulterar dock i ett fel vid försök att exportera filen.

Köra exportjobb i aktiva filsystem

I aktiva filsystem kan ändringar av filer under exportjobbet resultera i felstatus. Med den här felstatusen vet du 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 endast 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 på 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`	heltal
`group`	heltal
`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 hydrera ett nytt Lustre-kluster. Redigera eller lägga 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 blobcontainern 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

Inklusive den här flaggan bevaras POSIX-katalogattribut 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.

Dela via