Usare Archiviazione BLOB di Azure con Lustre gestito di Azure

Articolo
05/31/2024

Lustre gestito di Azure si integra con Archiviazione BLOB di Azure per semplificare il processo di importazione dei dati da un contenitore BLOB a un file system. È anche possibile esportare i dati dal file system in un contenitore BLOB per l'archiviazione a lungo termine. Questo articolo illustra i concetti relativi all'uso dell'integrazione BLOB con i file system lustre gestiti di Azure.

Per comprendere i requisiti e la configurazione necessari per un contenitore BLOB compatibile, vedere Prerequisiti di integrazione BLOB.

Panoramica dell'integrazione dei BLOB

È possibile configurare l'integrazione BLOB durante la creazione del cluster ed è possibile creare un processo di importazione in qualsiasi momento dopo la creazione del cluster. Dopo l'importazione dei dati, è possibile usare i dati come si farebbe con altri dati del file system. Quando vengono creati nuovi file o i file esistenti vengono modificati nel file system, è possibile esportare nuovamente questi file nell'account di archiviazione eseguendo i comandi dell'interfaccia della riga di comando lustre nel client o esportando i dati usando processi di esportazione.

Quando si importano dati da un contenitore BLOB in un file system lustre gestito di Azure, solo i nomi di file (spazio dei nomi) e i metadati vengono importati nello spazio dei nomi Lustre. Il contenuto effettivo di un BLOB viene importato quando si accede per la prima volta da un client. Si verifica un lieve ritardo durante la prima accesso ai dati mentre la funzionalità Gestione archiviazione gerarchica lustre esegue il pull del contenuto del BLOB nel file corrispondente nel file system.

È possibile prelettura del contenuto dei BLOB usando il comando di lfs hsm_restore Lustre da un client montato con funzionalità sudo. Per altre informazioni, vedere Ripristinare i dati dall'archivio BLOB.

Lustre gestito di Azure funziona con gli account di archiviazione con spazio dei nomi gerarchico abilitato e account di archiviazione con uno spazio dei nomi non gerarchico o flat. Si applicano le differenze minori seguenti:

Per un account di archiviazione con spazio dei nomi gerarchico abilitato, Azure Managed Lustre legge gli attributi POSIX dall'intestazione blob.
Per un account di archiviazione in cui non è abilitato lo spazio dei nomi gerarchico, Azure Managed Lustre legge gli attributi POSIX dai metadati del BLOB. Viene creato un file vuoto separato con lo stesso nome del contenuto del contenitore BLOB per contenere i metadati. Questo file è un elemento di pari livello della directory di dati effettiva nel file system lustre gestito di Azure.

Importare da Archiviazione BLOB

È possibile configurare l'integrazione con Archiviazione BLOB durante la creazione del cluster ed è possibile creare un processo di importazione in qualsiasi momento dopo la creazione del cluster.

Requisiti dei contenitori BLOB

Quando si configura l'integrazione BLOB durante la creazione del cluster, è necessario identificare due contenitori BLOB separati: il contenitore da importare e il contenitore di registrazione. Il contenitore da importare contiene i dati da importare nel file system lustre gestito di Azure. Il contenitore di registrazione viene usato per archiviare i log per il processo di importazione. Questi due contenitori devono trovarsi nello stesso account di archiviazione. Per altre informazioni sui requisiti per il contenitore BLOB, vedere Prerequisiti di integrazione BLOB.

Prefisso di importazione

Quando si importano dati da un contenitore BLOB, è possibile specificare facoltativamente uno o più prefissi per filtrare i dati importati nel file system lustre gestito di Azure. I nomi di file nel contenitore BLOB che corrispondono a uno dei prefissi vengono aggiunti a un record di metadati nel file system. Quando un client accede per la prima volta a un file, il relativo contenuto viene recuperato dal contenitore BLOB e archiviato nel file system.

Nella portale di Azure usare i campi Prefisso importazione nella scheda Avanzate durante la creazione del cluster per specificare i dati da importare dal contenitore BLOB. Questi campi si applicano solo al processo di importazione iniziale. Non è possibile modificare il prefisso di importazione dopo la creazione del cluster.

Per un processo di importazione, è possibile specificare prefissi di importazione quando si crea il processo. Nella portale di Azure è possibile specificare prefissi di importazione nei campi Prefisso di importazione. È anche possibile specificare il prefisso di importazione quando si usa l'API REST per creare un processo di importazione.

Quando si specificano prefissi di importazione, tenere presenti le considerazioni seguenti:

Il prefisso di importazione predefinito è /. Questo comportamento predefinito importa il contenuto dell'intero contenitore BLOB.
Se si specificano più prefissi, i prefissi devono essere non sovrapposti. Ad esempio, se si specifica /data e /data2, il processo di importazione ha esito negativo perché i prefissi si sovrappongono.
Se il contenitore BLOB si trova in un account di archiviazione con spazio dei nomi gerarchico abilitato, è possibile considerare il prefisso come percorso del file. Gli elementi nel percorso sono inclusi nel file system lustre gestito di Azure.
Se il contenitore BLOB si trova in un account di archiviazione con uno spazio dei nomi non gerarchico (o flat), è possibile considerare il prefisso di importazione come stringa di ricerca confrontata con l'inizio del nome del BLOB. Se il nome di un BLOB nel contenitore inizia con la stringa specificata come prefisso di importazione, tale file viene reso accessibile nel file system. Lustre è un file system gerarchico e / i caratteri nei nomi BLOB diventano delimitatori di directory quando vengono archiviati in Lustre.

Modalità di risoluzione dei conflitti

Quando si importano dati da un contenitore BLOB, è possibile specificare come gestire i conflitti tra il contenitore BLOB e il file system. Questa opzione si applica solo ai processi di importazione eseguiti per i cluster esistenti. La tabella seguente illustra le modalità di risoluzione dei conflitti disponibili e le relative descrizioni:

Modalità	Descrizione
`fail`	Il processo di importazione non riesce immediatamente con un errore se viene rilevato un conflitto.
`skip`	Il processo di importazione ignora il file se viene rilevato un conflitto.
`overwrite-dirty`	Il processo di importazione valuta un percorso in conflitto per verificare se deve essere eliminato e reimportato. Per altre informazioni, vedere sovrascrivere la modalità dirty.
`overwrite-always`	Il processo di importazione valuta un percorso in conflitto e elimina sempre/reimporta se è dirty o rilascia se è pulito. Per altre informazioni, vedere sovrascrivere sempre la modalità.

Modalità overwrite-dirty

La overwrite-dirty modalità valuta un percorso in conflitto per verificare se deve essere eliminato e reimportato. A livello generale, overwrite-dirty la modalità controlla lo stato del modulo di protezione hardware. Se lo stato del modulo di protezione hardware è Pulito e Archiviato, il che significa che i dati sono sincronizzati con il contenitore BLOB fino a quando Lustre può indicare, solo gli attributi vengono aggiornati, se necessario. In caso contrario, il file viene eliminato e reimportato dal contenitore BLOB.

Il controllo dello stato del modulo di protezione hardware non garantisce che il file in Lustre corrisponda al file nel contenitore BLOB. Se è necessario assicurarsi che il file in Lustre corrisponda al file nel contenitore BLOB il più vicino possibile, usare la overwrite-always modalità .

Modalità sovrascrittura-sempre

La overwrite-always modalità valuta un percorso in conflitto e elimina sempre/re-importa se è dirty o rilascia se è pulita. Questa modalità è utile quando si vuole assicurarsi che il file system sia sempre sincronizzato con il contenitore BLOB. È anche l'opzione più costosa, perché ogni file ripristinato in precedenza viene rilasciato o eliminato/reimportato al primo accesso.

Tolleranza di errore

Quando si importano dati da un contenitore BLOB, è possibile specificare la tolleranza di errore. Il livello di tolleranza di errore determina il modo in cui il processo di importazione gestisce gli errori temporanei che si verificano durante il processo di importazione, ad esempio errori del sistema operativo o interruzioni di rete. È importante notare che gli errori in questo contesto non fanno riferimento a conflitti di file, gestiti dalla modalità di risoluzione dei conflitti.

Per i processi di importazione sono disponibili le opzioni di tolleranza di errore seguenti:

Non consentire errori (impostazione predefinita): il processo di importazione ha esito negativo immediatamente se si verifica un errore durante l'importazione. Si tratta del comportamento predefinito.
Consenti errori: il processo di importazione continua se si verifica un errore e viene registrato l'errore. Al termine del processo di importazione, è possibile visualizzare gli errori nel contenitore di registrazione.

Considerazioni per i processi di importazione BLOB

Gli elementi seguenti sono importanti da considerare quando si importano dati da un contenitore BLOB:

È possibile eseguire una sola azione di importazione o esportazione alla volta. Ad esempio, se è in corso un processo di importazione, il tentativo di avviare un altro processo di importazione restituisce un errore.
I processi di importazione possono essere annullati. È possibile annullare un processo di importazione avviato in un cluster esistente o un processo di importazione avviato durante la creazione del cluster.
La distribuzione del cluster può restituire correttamente prima del completamento del processo di importazione corrispondente. Il processo di importazione continua a essere eseguito in background. È possibile monitorare lo stato di avanzamento del processo di importazione nei modi seguenti:
- portale di Azure: il portale di Azure visualizza lo stato del processo di importazione. Passare al file system e selezionare Integrazione BLOB per visualizzare lo stato del processo di importazione.
- File Lustre nella directory radice: un file denominato simile a /lustre/IMPORT_<state>.<timestamp_start> viene creato nella directory radice Lustre durante l'importazione. Il <state> segnaposto cambia man mano che l'importazione avanza. Il file viene eliminato al termine del processo di importazione.
Per visualizzare i dettagli su un processo di importazione completato, è possibile controllare il contenitore di registrazione. Il contenitore di registrazione contiene i log per il processo di importazione, inclusi eventuali errori o conflitti che si sono verificati durante l'importazione.
Se il processo di importazione non riesce per qualsiasi motivo, è possibile che non siano presenti statistiche complete sul processo di importazione, ad esempio il numero di file importati o il numero di conflitti.

Ripristinare i dati dall'archiviazione BLOB

Per impostazione predefinita, il contenuto di un BLOB viene importato in un file system la prima volta che si accede al file corrispondente da un client. Per determinati carichi di lavoro e scenari, è consigliabile ripristinare i dati da un contenitore BLOB prima di accedervi per la prima volta. È possibile scegliere di prelettura del contenuto dei BLOB per evitare il ritardo iniziale quando si accede al BLOB per la prima volta dopo l'importazione. Per prelettura del contenuto dei BLOB, è possibile usare il comando di lfs hsm_restore Lustre da un client montato con funzionalità sudo. Il comando seguente eseguirà il prelettura del contenuto dei BLOB nel file system:

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

Questo comando indica al server di metadati di elaborare in modo asincrono una richiesta di ripristino. La riga di comando non attende il completamento del ripristino, il che significa che la riga di comando può accodare un numero elevato di voci per il ripristino nel server di metadati. Questo approccio può sovraccaricare il server di metadati e ridurre le prestazioni per i ripristini.

Per evitare questo potenziale problema di prestazioni, è possibile creare uno script di base che tenta di seguire il percorso e generare richieste di ripristino in batch di dimensioni specificate. Per ottenere prestazioni ragionevoli ed evitare di sovraccaricare il server di metadati, è consigliabile usare dimensioni batch da 1.000 a 5.000 richieste.

Esempio: Creare uno script di ripristino batch

L'esempio seguente illustra come creare uno script per ripristinare i dati da un contenitore BLOB in batch. Creare un file denominato file_restorer.bash con il contenuto seguente:

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

L'esempio seguente illustra come eseguire lo script insieme all'output di esempio:

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

Nota

Al momento, Lustre gestito di Azure ripristina i dati dall'archiviazione BLOB con una velocità effettiva massima di circa 7,5GiB al secondo.

Esportare i dati nell'archivio BLOB usando un processo di esportazione

È possibile copiare dati dal file system lustre gestito di Azure all'archiviazione a lungo termine in Archiviazione BLOB di Azure creando un processo di esportazione.

Quali file vengono esportati durante un processo di esportazione?

Quando si esportano file dal sistema Lustre gestito di Azure, non tutti i file vengono copiati nel contenitore BLOB specificato al momento della creazione del file system. Le regole seguenti si applicano ai processi di esportazione:

I processi di esportazione copiano solo i file nuovi o i cui contenuti vengono modificati. Se il file importato dal contenitore BLOB durante la creazione del file system rimane invariato, il processo di esportazione non esporta il file.
I file con modifiche ai metadati non vengono esportati solo. Le modifiche ai metadati includono: proprietario, autorizzazioni, attributi estesi e modifiche al nome (rinominate).
I file eliminati nel file system lustre gestito di Azure non vengono eliminati nel contenitore BLOB originale durante il processo di esportazione. Il processo di esportazione non elimina i file nel contenitore BLOB.

Esecuzione di processi di esportazione in file system attivi

Nei file system attivi, le modifiche apportate ai file durante il processo di esportazione possono causare errori. Questo stato di errore consente di sapere che non tutti i dati nel file system potrebbero essere esportati nell'archivio BLOB. In questo caso, è possibile ritentare l'esportazione creando un nuovo processo di esportazione. Il nuovo processo copia solo i file che non sono stati copiati nel processo precedente.

Nei file system con molte attività, i tentativi possono avere esito negativo più volte perché i file cambiano di frequente. Per verificare che un file sia stato esportato correttamente nell'archivio BLOB, controllare il timestamp nel BLOB corrispondente. Al termine del processo, è anche possibile visualizzare il contenitore di registrazione configurato in fase di distribuzione per visualizzare informazioni dettagliate sul processo di esportazione. Il contenitore di registrazione fornisce informazioni di diagnostica sui file non riusciti e sul motivo per cui non sono riusciti.

Se si sta preparando a rimuovere le autorizzazioni di un cluster e si vuole eseguire un'esportazione finale nell'archiviazione BLOB, assicurarsi che tutte le attività di I/O vengano interrotte prima di avviare il processo di esportazione. Questo approccio consente di garantire che tutti i dati vengano esportati evitando errori dovuti all'attività del file system.

Metadati per i file esportati

Quando i file vengono esportati dal file system lustre gestito di Azure nel contenitore BLOB, vengono salvati metadati aggiuntivi per semplificare l'importazione del contenuto in un file system.

La tabella seguente elenca gli attributi POSIX del file system Lustre salvati nei metadati BLOB come coppie chiave-valore:

Attributo POSIX	Type
`owner`	int
`group`	int
`permissions`	octal o rwxrwxrwx format; bit sticky è supportato

Gli attributi della directory vengono salvati in un BLOB vuoto. Questo BLOB ha lo stesso nome del percorso della directory e contiene la coppia chiave-valore seguente nei metadati del BLOB: hdi_isfolder : true.

È possibile modificare manualmente gli attributi POSIX prima di usare il contenitore per idratare un nuovo cluster Lustre. Modificare o aggiungere metadati BLOB usando le coppie chiave-valore descritte in precedenza.

Considerazioni per i processi di esportazione

Gli elementi seguenti sono importanti da considerare quando si esportano dati con un processo di esportazione:

È possibile eseguire una sola azione di importazione o esportazione alla volta. Ad esempio, se è in corso un processo di esportazione, il tentativo di avviare un altro processo di esportazione restituisce un errore.

Copiare un contenitore BLOB Lustre con AzCopy o Storage Explorer

È possibile spostare o copiare il contenitore BLOB usato da Lustre usando AzCopy o Storage Explorer.

Per AzCopy, è possibile includere gli attributi della directory aggiungendo il flag seguente:

--include-directory-stub

L'inclusione di questo flag mantiene gli attributi POSIX della directory durante un trasferimento, ad esempio , ownergroupe permissions. Se si usa azcopy nel contenitore di archiviazione senza questo flag o con il flag impostato su false, i dati e le directory vengono inclusi nel trasferimento, ma le directory non mantengono gli attributi POSIX.

In Storage Explorer è possibile abilitare questo flag in Impostazioni selezionando Trasferisci e selezionando la casella Includi stub directory.

Condividi tramite