Verwenden von Azure Blob Storage mit Azure Managed Lustre

Artikel
06/06/2024

Azure Managed Lustre ist in Azure Blob Storage integriert, um den Import von Daten aus einem BLOB-Container in ein Dateisystem zu vereinfachen. Sie können auch Daten aus dem Dateisystem in einen BLOB-Container für den langfristigen Speicher exportieren. In diesem Artikel werden Konzepte für die Verwendung der Blob-Integration in Azure Managed Lustre-Dateisysteme erläutert.

Informationen zu den Anforderungen und der Konfiguration, die für einen kompatiblen BLOB-Container erforderlich sind, finden Sie unter Blob-Integrationsvoraussetzungen.

Übersicht über die Blob-Integration

Sie können die Blob-Integration während der Clustererstellung konfigurieren und jederzeit einen Importauftrag erstellen, nachdem der Cluster erstellt wurde. Nachdem die Daten importiert wurden, können Sie mit den Daten wie mit anderen Dateisystemdaten arbeiten. Wenn neue Dateien erstellt oder vorhandene Dateien im Dateisystem geändert werden, können Sie diese Dateien zurück in das Speicherkonto exportieren, indem Sie Lustre CLI-Befehle auf dem Client ausführen oder die Daten mithilfe von Exportaufträgen exportieren.

Wenn Sie Daten aus einem BLOB-Container in ein Azure Managed Lustre-Dateisystem importieren, werden nur die Dateinamen (Namespace) und Metadaten in den Lustre-Namespace importiert. Der tatsächliche Inhalt eines Blobs wird importiert, wenn der erste Zugriff durch einen Client erfolgt. Es gibt eine leichte Verzögerung beim ersten Zugriff auf Daten, während das Feature Lustre Hierarchical Storage Management (HSM) den BLOB-Inhalt in die entsprechende Datei im Dateisystem abruft.

Sie können den Inhalt von Blobs mithilfe des lfs hsm_restore Befehls Lustre über einen bereitgestellten Client mit sudo-Funktionen vorab abrufen. Weitere Informationen finden Sie unter "Wiederherstellen von Daten aus Blob Storage".

Azure Managed Lustre arbeitet mit Speicherkonten mit hierarchischen Namespaces und Speicherkonten mit einem nicht hierarchischen oder flachen Namespace. Die folgenden geringfügigen Unterschiede gelten:

Für ein Speicherkonto mit aktiviertem hierarchischen Namespace liest Azure Managed Lustre POSIX-Attribute aus dem Blobheader.
Für ein Speicherkonto, das keinen hierarchischen Namespace aktiviert hat, liest Azure Managed Lustre POSIX-Attribute aus den BLOB-Metadaten. Eine separate, leere Datei mit demselben Namen wie der Inhalt des BLOB-Containers wird erstellt, um die Metadaten zu speichern. Diese Datei ist ein gleichgeordnetes Datenverzeichnis im Azure Managed Lustre-Dateisystem.

Importieren aus Blob Storage

Sie können die Integration mit Blob Storage während der Clustererstellung konfigurieren und einen Importauftrag jederzeit erstellen, nachdem der Cluster erstellt wurde.

Anforderungen für Blobcontainer

Beim Konfigurieren der Blob-Integration während der Clustererstellung müssen Sie zwei separate BLOB-Container identifizieren: den zu importierenden Container und den Protokollierungscontainer. Der zu importierende Container enthält die Daten, die Sie in das Azure Managed Lustre-Dateisystem importieren möchten. Der Protokollierungscontainer wird verwendet, um Protokolle für den Importauftrag zu speichern. Diese beiden Container müssen sich im selben Speicherkonto befinden. Weitere Informationen zu den Anforderungen für den BLOB-Container finden Sie unter Voraussetzungen für die Blob-Integration.

Präfix importieren

Beim Importieren von Daten aus einem BLOB-Container können Sie optional ein oder mehrere Präfixe angeben, um die in das Azure Managed Lustre-Dateisystem importierten Daten zu filtern. Dateinamen im BLOB-Container, die einem der Präfixe entsprechen, werden einem Metadatendatensatz im Dateisystem hinzugefügt. Wenn ein Client zum ersten Mal auf eine Datei zugreift, werden seine Inhalte aus dem BLOB-Container abgerufen und im Dateisystem gespeichert.

Verwenden Sie im Azure-Portal die Felder "Präfix importieren" auf der Registerkarte "Erweitert" während der Clustererstellung, um die Daten anzugeben, die aus Ihrem BLOB-Container importiert werden sollen. Diese Felder gelten nur für den anfänglichen Importauftrag. Sie können das Importpräfix nicht ändern, nachdem der Cluster erstellt wurde.

Bei einem Importauftrag können Sie beim Erstellen des Auftrags Importpräfixe angeben. Aus dem Azure-Portal können Sie Importpräfixe in den Importpräfixfeldern angeben. Sie können auch das Importpräfix angeben, wenn Sie die REST-API zum Erstellen eines Importauftrags verwenden.

Beachten Sie beim Angeben von Importpräfixen die folgenden Überlegungen:

Das Standardimportpräfix lautet /. Dieses Standardverhalten importiert den Inhalt des gesamten BLOB-Containers.
Wenn Sie mehrere Präfixe angeben, müssen die Präfixe nicht überlappend sein. Wenn Sie z. B. angeben /data und /data2, schlägt der Importauftrag fehl, da sich die Präfixe überlappen.
Wenn sich der BLOB-Container in einem Speicherkonto mit aktiviertem hierarchischen Namespace befindet, können Sie sich das Präfix als Dateipfad vorstellen. Elemente unter dem Pfad sind im Azure Managed Lustre-Dateisystem enthalten.
Wenn sich der BLOB-Container in einem Speicherkonto mit einem nicht hierarchischen (oder flachen) Namespace befindet, können Sie sich das Importpräfix als Suchzeichenfolge vorstellen, die mit dem Anfang des Blobnamens verglichen wird. Wenn der Name eines Blobs im Container mit der Zeichenfolge beginnt, die Sie als Importpräfix angegeben haben, wird auf diese Datei im Dateisystem zugegriffen. Lustre ist ein hierarchisches Dateisystem, und / Zeichen in Blobnamen werden verzeichnistrennzeichen, wenn sie in Lustre gespeichert sind.

Konfliktlösungsmodus

Beim Importieren von Daten aus einem BLOB-Container können Sie angeben, wie Konflikte zwischen dem BLOB-Container und dem Dateisystem behandelt werden. Diese Option gilt nur für Importaufträge, die für vorhandene Cluster ausgeführt werden. In der folgenden Tabelle sind die verfügbaren Konfliktlösungsmodi und deren Beschreibungen aufgeführt:

Mode	Beschreibung
`fail`	Der Importauftrag schlägt sofort mit einem Fehler fehl, wenn ein Konflikt erkannt wird.
`skip`	Der Importauftrag überspringt die Datei, wenn ein Konflikt erkannt wird.
`overwrite-dirty`	Der Importauftrag wertet einen konfliktierenden Pfad aus, um festzustellen, ob er gelöscht und neu importiert werden soll. Weitere Informationen finden Sie im Overwrite-Dirty-Modus.
`overwrite-always`	Der Importauftrag wertet einen widersprüchlichen Pfad aus und löscht/importiert immer, wenn er schmutzig ist, oder gibt frei, ob er sauber ist. Weitere Informationen finden Sie im Overwrite-Always-Modus.

Overwrite-Dirty-Modus

Der overwrite-dirty Modus wertet einen konfliktierenden Pfad aus, um festzustellen, ob er gelöscht und neu importiert werden soll. Auf hoher Ebene overwrite-dirty überprüft der Modus den HSM-Zustand. Wenn der HSM-Zustand "Sauber" und "Archiviert" ist, d. h., dass die Daten mit dem BLOB-Container synchronisiert werden, soweit Lustre erkennen kann, werden bei Bedarf nur die Attribute aktualisiert. Andernfalls wird die Datei gelöscht und aus dem Blobcontainer neu importiert.

Das Überprüfen des HSM-Zustands garantiert nicht, dass die Datei in Lustre mit der Datei im BLOB-Container übereinstimmt. Wenn Sie sicherstellen müssen, dass die Datei in Lustre der Datei im BLOB-Container so genau wie möglich entspricht, verwenden Sie den overwrite-always Modus.

Modus "Immer überschreiben"

Der overwrite-always Modus wertet einen widersprüchlichen Pfad aus und löscht/importiert immer, wenn er geändert wird, oder gibt frei, ob er sauber ist. Dieser Modus ist nützlich, wenn Sie sicherstellen möchten, dass das Dateisystem immer mit dem BLOB-Container synchronisiert ist. Es ist auch die teuerste Option, da jede zuvor wiederhergestellte Datei beim ersten Zugriff entweder freigegeben oder gelöscht/erneut importiert wird.

Fehlertoleranz

Beim Importieren von Daten aus einem BLOB-Container können Sie die Fehlertoleranz angeben. Die Fehlertoleranzstufe bestimmt, wie der Importauftrag vorübergehende Fehler verarbeitet, die während des Importvorgangs auftreten, z. B. Betriebssystemfehler oder Netzwerkunterbrechungen. Es ist wichtig zu beachten, dass Fehler in diesem Kontext nicht auf Dateikonflikte verweisen, die vom Konfliktlösungsmodus behandelt werden.

Die folgenden Fehlertoleranzoptionen sind für Importaufträge verfügbar:

Fehler nicht zulassen (Standard): Der Importauftrag schlägt sofort fehl, wenn während des Imports ein Fehler auftritt. Dies ist die Standardeinstellung.
Fehler zulassen: Der Importauftrag wird fortgesetzt, wenn ein Fehler auftritt, und der Fehler wird protokolliert. Nach Abschluss des Importauftrags können Sie Fehler im Protokollierungscontainer anzeigen.

Überlegungen für Blobimportaufträge

Die folgenden Elemente sind beim Importieren von Daten aus einem BLOB-Container wichtig:

Es kann jeweils nur eine Import- oder Exportaktion ausgeführt werden. Wenn beispielsweise ein Importauftrag ausgeführt wird, gibt der Versuch, einen anderen Importauftrag zu starten, einen Fehler zurück.
Importaufträge können abgebrochen werden. Sie können einen Importauftrag abbrechen, der auf einem vorhandenen Cluster gestartet wurde, oder einen Importauftrag, der während der Clustererstellung initiiert wurde.
Die Clusterbereitstellung kann erfolgreich zurückgegeben werden, bevor der entsprechende Importauftrag abgeschlossen ist. Der Importauftrag wird weiterhin im Hintergrund ausgeführt. Sie können den Fortschritt des Importauftrags auf folgende Weise überwachen:
- Azure-Portal: Die Azure-Portal zeigt den Status des Importauftrags an. Navigieren Sie zum Dateisystem, und wählen Sie blob-Integration aus, um den Status des Importauftrags anzuzeigen.
- Lustre-Datei im Stammverzeichnis: Eine Datei, die ähnlich ist, /lustre/IMPORT_<state>.<timestamp_start> wird während des Imports im Lustre-Stammverzeichnis erstellt. Der <state> Platzhalter ändert sich, während der Import fortschreitet. Die Datei wird gelöscht, wenn der Importauftrag erfolgreich abgeschlossen wurde.
Um Details zu einem abgeschlossenen Importauftrag anzuzeigen, können Sie den Protokollierungscontainer überprüfen. Der Protokollierungscontainer enthält Protokolle für den Importauftrag, einschließlich aller Fehler oder Konflikte, die während des Imports aufgetreten sind.
Wenn der Importauftrag aus irgendeinem Grund fehlschlägt, verfügen Sie möglicherweise nicht über vollständige Statistiken zum Importauftrag, z. B. die Anzahl der importierten Dateien oder die Anzahl von Konflikten.

Wiederherstellen von Daten aus Blob Storage

Standardmäßig werden die Inhalte eines Blobs beim ersten Zugriff auf die entsprechende Datei von einem Client in ein Dateisystem importiert. Für bestimmte Workloads und Szenarien sollten Sie die Daten vor dem ersten Zugriff aus einem BLOB-Container wiederherstellen. Sie können den Inhalt von Blobs vorab abrufen, um die anfängliche Verzögerung zu vermeiden, wenn nach dem Import zum ersten Mal auf das Blob zugegriffen wird. Um den Inhalt von Blobs vorab zu entfernen, können Sie den Befehl Lustre lfs hsm_restore von einem bereitgestellten Client mit sudo-Funktionen verwenden. Mit dem folgenden Befehl wird der Inhalt der Blobs im Dateisystem vorab abgerufen:

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

Dieser Befehl weist den Metadatenserver an, eine Wiederherstellungsanforderung asynchron zu verarbeiten. Die Befehlszeile wartet nicht, bis die Wiederherstellung abgeschlossen ist. Dies bedeutet, dass die Befehlszeile das Potenzial hat, eine große Anzahl von Einträgen für die Wiederherstellung auf dem Metadatenserver in die Warteschlange zu stellen. Dieser Ansatz kann den Metadatenserver überwältigen und die Leistung für Wiederherstellungen beeinträchtigen.

Um dieses potenzielle Leistungsproblem zu vermeiden, können Sie ein einfaches Skript erstellen, das versucht, den Pfad zu durchlaufen und Wiederherstellungsanforderungen in Batches einer bestimmten Größe zu beheben. Um eine angemessene Leistung zu erzielen und den Metadatenserver zu überwältigen, empfiehlt es sich, Batchgrößen von 1.000 bis 5.000 Anforderungen zu verwenden.

Beispiel: Erstellen eines Batchwiederherstellungsskripts

Das folgende Beispiel zeigt, wie Sie ein Skript erstellen, um Daten aus einem BLOB-Container in Batches wiederherzustellen. Erstellen Sie eine Datei namens file_restorer.bash mit folgendem Inhalt:

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

Das folgende Beispiel zeigt, wie das Skript zusammen mit der Beispielausgabe ausgeführt wird:

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

Hinweis

Derzeit stellt Azure Managed Lustre Daten aus Blob Storage mit einer maximalen Durchsatzrate von ~7,5GiB/Sekunde wieder her.

Exportieren von Daten in Blob Storage mithilfe eines Exportauftrags

Sie können Daten aus Ihrem Azure Managed Lustre-Dateisystem in einen langfristigen Speicher in Azure Blob Storage kopieren, indem Sie einen Exportauftrag erstellen.

Welche Dateien werden während eines Exportauftrags exportiert?

Wenn Sie Dateien aus Ihrem Azure Managed Lustre-System exportieren, werden nicht alle Dateien in den BLOB-Container kopiert, den Sie beim Erstellen des Dateisystems angegeben haben. Die folgenden Regeln gelten für Exportaufträge:

Exportaufträge kopieren nur Dateien, die neu sind oder deren Inhalt geändert werden. Wenn die Datei, die Sie während der Erstellung des Dateisystems aus dem BLOB-Container importiert haben, unverändert ist, exportiert der Exportauftrag die Datei nicht.
Dateien mit Metadatenänderungen werden nur nicht exportiert. Metadatenänderungen umfassen: Besitzer, Berechtigungen, erweiterte Attribute und Namensänderungen (umbenannt).
Im Azure Managed Lustre-Dateisystem gelöschte Dateien werden während des Exportauftrags nicht im ursprünglichen BLOB-Container gelöscht. Der Exportauftrag löscht keine Dateien im BLOB-Container.

Ausführen von Exportaufträgen in aktiven Dateisystemen

In aktiven Dateisystemen können Änderungen an Dateien während des Exportauftrags zu Einem Fehlerstatus führen. Dieser Fehlerstatus teilt Ihnen mit, dass nicht alle Daten im Dateisystem in Blob Storage exportiert werden können. In dieser Situation können Sie den Export wiederholen, indem Sie einen neuen Exportauftrag erstellen. Der neue Auftrag kopiert nur die Dateien, die nicht im vorherigen Auftrag kopiert wurden.

In Dateisystemen mit vielen Aktivitäten können Wiederholungen mehrmals fehlschlagen, da Dateien häufig geändert werden. Um zu überprüfen, ob eine Datei erfolgreich in Blob Storage exportiert wurde, überprüfen Sie den Zeitstempel für das entsprechende Blob. Nach Abschluss des Auftrags können Sie auch den protokollierungscontainer anzeigen, der zur Bereitstellungszeit konfiguriert ist, um detaillierte Informationen zum Exportauftrag anzuzeigen. Der Protokollierungscontainer enthält Diagnoseinformationen dazu, welche Dateien fehlgeschlagen sind und warum sie fehlgeschlagen sind.

Wenn Sie die Außerbetriebnahme eines Clusters vorbereiten und einen endgültigen Export in Blob Storage durchführen möchten, sollten Sie sicherstellen, dass alle E/A-Aktivitäten angehalten werden, bevor Sie den Exportauftrag initiieren. Dieser Ansatz trägt dazu bei, sicherzustellen, dass alle Daten exportiert werden, indem Fehler aufgrund von Dateisystemaktivitäten vermieden werden.

Metadaten für exportierte Dateien

Wenn Dateien aus dem Azure Managed Lustre-Dateisystem in den BLOB-Container exportiert werden, werden zusätzliche Metadaten gespeichert, um die Neuimportierung der Inhalte in ein Dateisystem zu vereinfachen.

In der folgenden Tabelle sind POSIX-Attribute aus dem Lustre-Dateisystem aufgeführt, die in den BLOB-Metadaten als Schlüsselwertpaare gespeichert werden:

POSIX-Attribut	type
`owner`	int
`group`	int
`permissions`	oktales oder rwxrwxrwx-Format; Sticky Bit wird unterstützt

Verzeichnisattribute werden in einem leeren Blob gespeichert. Dieser Blob hat denselben Namen wie der Verzeichnispfad und enthält das folgende Schlüsselwertpaar in den BLOB-Metadaten: hdi_isfolder : true

Sie können die POSIX-Attribute manuell ändern, bevor Sie den Container verwenden, um einen neuen Lustre-Cluster zu hydratisieren. Bearbeiten oder Hinzufügen von BLOB-Metadaten mithilfe der zuvor beschriebenen Schlüsselwertpaare.

Überlegungen für Exportaufträge

Die folgenden Elemente sind beim Exportieren von Daten mit einem Exportauftrag wichtig:

Es kann jeweils nur eine Import- oder Exportaktion ausgeführt werden. Wenn beispielsweise ein Exportauftrag ausgeführt wird, gibt der Versuch, einen anderen Exportauftrag zu starten, einen Fehler zurück.

Kopieren eines Lustre Blob-Containers mit AzCopy oder Storage-Explorer

Sie können den Blobcontainer Lustre mithilfe von AzCopy oder Storage-Explorer verschieben oder kopieren.

Für AzCopy können Sie Verzeichnisattribute einschließen, indem Sie das folgende Flag hinzufügen:

--include-directory-stub

Durch Das Einschließen dieses Flags bleiben die POSIX-Verzeichnisattribute während einer Übertragung erhalten, ownerz. B. , , groupund permissions. Wenn Sie azcopy den Speichercontainer ohne dieses Flag oder das Kennzeichen falseverwenden, werden die Daten und Verzeichnisse in die Übertragung einbezogen, aber die Verzeichnisse behalten ihre POSIX-Attribute nicht bei.

In Storage-Explorer können Sie dieses Kennzeichen in "Einstellungen" aktivieren, indem Sie "Übertragungen" aktivieren und das Kontrollkästchen für "Verzeichnis-Stubs einschließen" aktivieren.

Freigeben über