Verwenden Sie Azure BLOb Speicher mit Azure verwaltetem Lustre

Azure Managed Lustre integriert sich mit Azure Blob Storage, um den Prozess des Importierens von Daten aus einem Blob-Container in ein Dateisystem zu vereinfachen. Sie können auch Daten vom Dateisystem zu einem Blob-Container für die langfristige Speicherung exportieren. Dieser Artikel erklärt Begriffe für die Verwendung der Blob-Integration mit verwalteten Azure Lustre-Dateisystemen.

Um die Anforderungen und die Konfiguration, die für einen kompatiblen Blob-Container erforderlich sind, zu verstehen, siehe Blob-Integrationsvoraussetzungen.

BLOb-Integration Übersicht

Sie können die Blob-Integration während der Clustererstellung konfigurieren, und Sie können jederzeit nach der Erstellung des Clusters einen Einzelvorgang importieren. Sobald die Daten importiert sind, können Sie mit den Daten arbeiten, wie Sie es mit anderen Dateisystemdaten tun würden. Wenn neue Dateien im Dateisystem erstellt oder vorhandene Dateien 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 indem Sie die Daten mit Datenexportaufträgen exportieren.

Wenn Sie Daten aus einem Blob-Container in ein Azure verwaltetes Lustre-Dateisystem importieren, werden nur die Dateinamen (Namespace) und Metadaten in den Lustre-Namespace importiert. Der aktuelle Inhalt eines Blobs wird importiert, wenn ein Client erstmals darauf zugreift. Es gibt eine leichte Verzögerung, wenn Sie zum ersten Mal auf Daten zugreifen, während die Lustre Hierarchische Speicherverwaltung (HSM)-Funktion den Blob-Inhalt mithilfe von Pull in die entsprechende Datei im Dateisystem überträgt.

Sie können den Inhalt von Blobs mit dem lfs hsm_restore Befehl von Lustre von einem eingebundenen Client mit sudo-Fähigkeiten abrufen. Um Weitere zu erfahren, siehe Wiederherstellung von Daten aus dem Blob-Speicher.

Azure Managed Lustre arbeitet mit Speicherkonten, die einen aktivierten hierarchischen Namespace haben, und mit Speicherkonten mit einem nicht-hierarchischen oder flachen Namespace. Die folgenden geringfügigen Unterschiede anwenden:

• Für ein Speicherkonto mit hierarchischem Namespace aktiviert, liest Azure Managed Lustre POSIX-Attribute aus dem Blob-Header.
• Für ein Speicherkonto, das nicht über einen aktivierten hierarchischen Namespace verfügt, liest Azure Managed Lustre POSIX-Attribute aus den Blob-Metadaten. Eine separate, leere Datei mit dem gleichen Namen wie der Inhalt Ihres Blob-Containers wird erstellt, um die Metadaten zu halten. Diese Datei ist ein Geschwister des aktuellen Datenverzeichnisses im verwalteten Azure Lustre-Dateisystem.

Importieren aus Blob-Speicher

Sie können die Integration mit Blob-Speicher während der Clustererstellung konfigurieren, und Sie können jederzeit nach der Erstellung des Clusters einen Importeinzelvorgang erstellen.

Blob-Container-Anforderungen

Wenn Sie die Blob-Integration während der Clustererstellung konfigurieren, müssen Sie zwei separate Blob-Container identifizieren: den Container zum Importieren und den Protokollierungscontainer. Der Container zum Importieren enthält die Daten, die Sie in das verwaltete Azure Lustre-Dateisystem importieren möchten. Der Protokollierungscontainer wird verwendet, um Protokolle für den Import-Einzelvorgang zu speichern. Diese beiden Container müssen sich im selben Speicherfirma befinden. Um Weitere über die Anforderungen für den Blob-Container zu erfahren, siehe Blob-Integrationsanforderungen.

Importieren des Präfixes

Wenn Sie Daten aus einem Blob-Container importieren, können Sie optional einen oder mehrere Vorfilter angeben, um die importierten Daten in das Azure verwaltete Lustre-Dateisystem zu filtern. Dateinamen im Blob-Container, die mit einem der Präfixe übereinstimmen, werden einem Metadatensatz im Dateisystem hinzugefügt. Wenn ein Client zuerst auf eine Datei zugreift, wird ihr Inhalt aus dem Blob-Container abgerufen und im Dateisystem gespeichert.

Verwenden Sie im Azure-Portal die Importpräfix Felder auf der Erweitert Registerkarte während der Clustereerstellung, um die Daten zu spezifizieren, die aus Ihrem Blob-Container importiert werden sollen. Diese Felder gelten nur für den ersten Import-Einzelvorgang. Sie können das Importpräfix nach der Erstellung des Clusters nicht ändern.

Für einen Importvorgang können Sie Importpräfixe angeben, wenn Sie den Vorgang erstellen. Im Azure-Portal können Sie Import-Präfixe in den Importpräfix-Feldern angeben. Sie können auch das Importpräfix angeben, wenn Sie die REST API verwenden, um einen Import-Einzelvorgang zu erstellen.

Beachten Sie die folgenden Überlegungen bei der Spezifikation von Importpräfixen:

• Das Standardimport-Präfix ist /. Dieses Standardverhalten importiert den Inhalt des gesamten Blob-Containers.
• Wenn Sie mehrere Präfixe angeben, dürfen sich die Präfixe nicht überlappen. Wenn Sie beispielsweise /data und /data2 angeben, schlägt der Import-Einzelvorgang fehl, weil die Präfixe eine Überlappung aufweisen.
• Wenn sich der Blob-Container in einem Speicher mit aktiviertem hierarchischen Namespace befindet, können Sie das Präfix als Dateipfad betrachten. Elemente unter dem Pfad sind im Azure verwalteten Lustre-Dateisystem enthalten.
• Wenn sich der BLOB-Container in einem Speicherkonto mit einem nichthierarchischen (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 diese Datei im Dateisystem zugänglich gemacht. Lustre ist ein hierarchisches Dateisystem, und / Zeichen in Blob-Namen werden zu Verzeichnis-Trennzeichen, wenn sie in Lustre gespeichert werden.

Konfliktlösungsmodus

Beim Importieren von Daten aus einem Blob-Container können Sie festlegen, wie Konflikte zwischen dem Blob-Container und dem Dateisystem behandelt werden sollen. Diese Option gilt nur für importieren Einzelvorgänge, die für bestehende Cluster ausgeführt werden. Die folgende Tabelle zeigt die verfügbaren Konfliktauflösungsmodi und deren Beschreibungen:

Überschreibmodus-modifizierte Seite

Der overwrite-dirty Modus führt eine Auswertung eines Konfliktpfads durch, um zu sehen, ob er gelöscht und neu importiert werden sollte. Auf hoher Ebene überprüft der overwrite-dirty Modus den HSM-Zustand. Wenn der HSM-Zustand Clean und Archived ist, was bedeutet, dass seine Daten mit dem Blob-Container synchronisiert sind, soweit Lustre dies feststellen kann, werden nur die Attribute bei Bedarf aktualisiert. Andernfalls wird die Datei gelöscht und aus dem Blob-Container erneut 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 so genau wie möglich der Datei im Blob-Container entspricht, verwenden Sie den overwrite-always Modus.

Modus "überschreiben-immer"

Der overwrite-always Modus bewertet einen Konfliktpfad und löscht/importiert immer erneut, wenn er fehlerhaft ist, oder gibt ihn frei, wenn er in Ordnung 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 entweder bei der ersten Zugriff entweder freigegeben oder gelöscht bzw. erneut importiert wird.

Fehlertoleranz

Beim Importieren von Daten aus einem Blob-Container können Sie die Fehlertoleranz angeben. Das Fehlertoleranzniveau bestimmt, wie der Einzelvorgang mit vorübergehenden Fehlern umgeht, die während des Importprozesses auftreten, zum Beispiel Betriebssystemfehler oder Netzwerkunterbrechungen. Es ist wichtig zu beachten, dass Fehler in diesem Kontext nicht auf Dateikonflikte verweisen, die vom Konfliktauflösungsmodus behandelt werden.

Die folgenden Fehlertoleranzoptionen sind für Importeinzelvorgänge verfügbar:

• Fehler nicht zulassen (Standard): Der Einzelvorgang schlägt sofort fehl, wenn während des Importierens ein Fehler auftritt. Dieses Verhalten ist die Standardeinstellung.
• Fehler zulassen: Der Import-Einzelvorgang wird fortgesetzt, wenn ein Fehler auftritt, und der Fehler wird protokolliert. Nachdem der Import-Einzelvorgang abgeschlossen ist, können Sie Fehler in der Protokollierung im Container einsehen.

Überlegungen für Blob-Importeinzelvorgänge

Die folgenden Elemente sind wichtig zu berücksichtigen, wenn Sie Daten aus einem Blob-Container importieren:

• Es kann jeweils nur eine Import- oder Export-Aktion ausgeführt werden. Wenn zum Beispiel ein Importieren-Einzelvorgang in Bearbeitung ist, gibt der Versuch, einen weiteren Importieren-Einzelvorgang zu starten, einen Fehler zurück.
• Importieren von Einzelvorgängen kann abgebrochen werden. Sie können einen Import-Einzelvorgang, der auf einem vorhandenen Cluster gestartet wurde, oder einen Import-Einzelvorgang, der während der Clustereerstellung initiiert wurde, Auswahl aufheben.
• Die Clusterbereitstellung kann erfolgreich zurückgegeben werden, bevor der entsprechende Importeinzelvorgang abgeschlossen ist. Der Import-Einzelvorgang wird im Hintergrund weiter ausgeführt. Sie können den Fortschritt des Importiereneinzelvorgangs auf folgende Weise überwachen:
  • Azure-Portal: Das Azure-Portal zeigt den Status des Import-Einzelvorgangs an. Navigieren Sie zum Dateisystem und aktivieren Sie Blob-Integration, um den Status des Importeinzelvorgangs zu sehen.
  • Lustre-Datei im Stammverzeichnis: Eine Datei mit einem Dateinamen ähnlich wie /lustre/IMPORT_<state>.<timestamp_start> wird während des Importierens im Lustre-Stammverzeichnis erstellt. Der <state> Platzhalter ändert sich, während der Import fortschreitet. Die Datei wird gelöscht, wenn der Import-Einzelvorgang erfolgreich abgeschlossen ist.
• Um Details zu einem abgeschlossenen importieren Einzelvorgang anzuzeigen, können Sie den Protokollierung Container überprüfen. Der Protokollierungscontainer enthält Protokolle für den Importeinzelvorgang, einschließlich aller Fehler oder Konflikte, die während des Imports aufgetreten sind.
• Wenn der Einzelvorgang aus irgendeinem Grund fehlerhaft ist, haben Sie möglicherweise keine vollständige Statistik über den Einzelvorgang, wie die Anzahl der importierten Dateien oder die Anzahl der Konflikte.

Wiederherstellung von Daten aus Blob-Speicher

Standardmäßig wird der Inhalt eines Blobs in ein Dateisystem importiert, wenn die entsprechende Datei zum ersten Mal von einem Client zugegriffen wird. Für bestimmte Arbeitslasten und Szenarien möchten Sie möglicherweise die Wiederherstellung der Daten aus einem Blob-Container vor dem ersten Zugriff vornehmen. Sie können auswählen, den Inhalt von Blobs vorab abzurufen, um die anfängliche Verzögerung zu vermeiden, wenn auf den Blob nach dem Importieren zum ersten Mal zugegriffen wird. Um den Inhalt von Blobs abzurufen, können Sie den lfs hsm_restore Befehl von Lustre von einem eingebundenen Client mit sudo-Fähigkeiten verwenden. Der folgende Befehl wird den Inhalt der Blobs in das Dateisystem vorab abrufen:

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

Dieser Befehl weist den Metadaten-Server an, eine Wiederherstellungsanforderung asynchron zu verarbeiten. Die Befehlszeile wartet nicht auf den Abschluss der Wiederherstellung, was bedeutet, dass die Befehlszeile das Potenzial hat, eine große Anzahl von Einträgen für die Wiederherstellung im Metadaten-Server in die Warteschlange einzureihen. Dieser Ansatz kann den Metadaten-Server überfordern und die Leistung für Wiederherstellungen mindern.

Um dieses potenzielle Leistungsproblem zu vermeiden, können Sie ein grundlegendes Skript erstellen, das versucht, den Pfad zu durchlaufen und Wiederherstellungsanforderungen in Stapeln einer angegebenen Größe ausstellt. Um eine angemessene Leistung zu erzielen und zu vermeiden, dass der Metadatenserver überlastet wird, empfehlen wir die Verwendung von Batchgrößen von 1.000 bis 5.000 Anfragen.

Beispiel: Erstellen Sie ein Stapelwiederherstellungsskript

Das folgende Codebeispiel zeigt, wie Sie ein Skript erstellen, um Daten aus einem Blob-Container in Stapeln 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 Sie das Skript ausführen, zusammen mit der Stichprobenausgabe:

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

Exportieren von Daten in den Blob-Speicher mithilfe eines Datenexportauftrags

Sie können Daten von Ihrem Azure verwalteten Lustre-Dateisystem in den langfristigen Speicher in Azure Blob Storage kopieren, indem Sie einen Export-Einzelvorgang erstellen.

Welche Dateien werden während eines Export-Einzelvorgangs exportiert?

Wenn Sie Dateien aus Ihrem Azure verwalteten 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 Export-Einzelvorgänge:

• Export-Einzelvorgänge kopieren nur Dateien, die neu sind oder deren Inhalt geändert wurde. Wenn die Datei, die Sie während der Dateisystemerstellung aus dem Blob-Container importiert haben, unverändert ist, exportiert der Einzelvorgang die Datei nicht.
• Dateien mit nur Metadatenänderungen werden nicht exportiert. Metadatenänderungen umfassen: Besitzer, Berechtigungen, erweiterte Attribute und Namensänderungen (umbenannt).
• Dateien, die im Azure verwalteten Lustre-Dateisystem gelöscht werden, werden während des Export-Einzelvorgangs nicht im ursprünglichen Blob-Container gelöscht. Der Export-Einzelvorgang löscht keine Dateien im Blob-Container.
• Blobnamen müssen bestimmten Benennungsregelnentsprechen, was bedeutet, dass akzeptable BLOB-Namen geringfügig von akzeptablen POSIX-Dateinamen abweichen. Beim Exportvorgang werden Sonderzeichen in Dateinamen beibehalten, indem sie beim Exportieren in Blobs ordnungsgemäß mit Escapezeichen versehen werden. Ein Dateiname, der gegen eine Blobbenennungsregel verstößt, z. B. einen Dateinamen, der die maximale Länge des Blobnamens überschreitet, führt jedoch zu einem Fehler beim Exportieren dieser Datei.

Exportvorgänge in aktiven Dateisystemen ausführen

In aktiven Dateisystemen können Änderungen an Dateien während des Export-Einzelvorgangs zu einem Fehlerstatus führen. Dieser Fehlerstatus informiert Sie darüber, dass nicht alle Daten im Dateisystem in den Blob-Speicher exportiert werden konnten. In dieser Situation können Sie den Export RETRY, indem Sie einen neuen Export Einzelvorgang erstellen. Der neue Einzelvorgang kopiert nur die Dateien, die im vorherigen Einzelvorgang nicht 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. Nachdem der Einzelvorgang abgeschlossen ist, können Sie auch den Protokollierung-Container, der zur Bereitstellungszeit konfiguriert wurde, einsehen, um detaillierte Informationen über den Export-Einzelvorgang zu erhalten. Der Protokollierung Container stellt Diagnose Informationen darüber bereit, welche Dateien fehlerhaft waren und warum sie fehlerhaft waren.

Wenn Sie sich darauf vorbereiten, einen Cluster außer Betrieb zu setzen und einen endgültigen Export in den Blob-Speicher durchführen möchten, sollten Sie sicherstellen, dass alle I/O-Aktivitäten beendet sind, bevor Sie den Export-Einzelvorgang starten. Dieser Ansatz hilft dabei, sicherzustellen, dass alle Daten exportiert werden, indem Fehler aufgrund von Dateisystemaktivität vermieden werden.

Metadaten für exportierte Dateien

Wenn Dateien aus dem Azure verwalteten Lustre-Dateisystem in den Blob-Container exportiert werden, werden zusätzliche Metadaten gespeichert, um das Importieren des Inhalts in ein Dateisystem zu vereinfachen.

Die folgende Tabelle listet POSIX-Attribute aus dem Lustre-Dateisystem auf, die in den Blob-Metadaten als Schlüssel-Wert-Paare gespeichert sind:

Verzeichnisattribute werden in einem leeren Blob gespeichert. Dieser Blob hat denselben Namen wie der Verzeichnispfad und enthält das folgende Schlüssel-Wert-Paar 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 aktivieren. Bearbeiten oder Hinzufügen von Blob-Metadaten durch Verwendung der zuvor beschriebenen Schlüssel-Wert-Paare.

Überlegungen für Datenexportaufträge

Die folgenden Elemente sind wichtig zu berücksichtigen, wenn Sie Daten mit einem Datenexportauftrag exportieren:

• Es kann jeweils nur eine Import- oder Export-Aktion ausgeführt werden. Wenn zum Beispiel ein Export-Einzelvorgang in Bearbeitung ist, gibt der Versuch, einen weiteren Export-Einzelvorgang zu starten, einen Fehler zurück.

Kopieren Sie einen Lustre-Blob-Container mit AzCopy oder dem Speicher-Explorer

Sie können den Blob-Container, den Lustre verwendet, verschieben oder kopieren, indem Sie AzCopy oder den Speicher-Explorer verwenden.

Für AzCopy können Sie Verzeichnisattribute einbeziehen, indem Sie die folgende Kennzeichnung hinzufügen:

--include-directory-stub

Durch Einschließen dieser Kennzeichnung werden Verzeichnis-POSIX-Attribute während einer Übertragung beibehalten, zum Beispiel owner, group und permissions. Wenn Sie azcopy auf dem Speichercontainer ohne diese Kennzeichnung oder mit der Kennzeichnung auf false gesetzt verwenden, dann sind die Daten und Verzeichnisse in der Übertragung enthalten, aber die Verzeichnisse behalten ihre POSIX-Attribute nicht bei.

Im Storage Explorer können Sie diese Kennzeichnung in den Einstellungen aktivieren, indem Sie Übertragungen auswählen und das Kontrollkästchen für Verzeichnis-Stubs einbeziehen aktivieren.

Nächste Schritte

• Voraussetzungen für die Blob-Speicherintegration
• Erstellen Sie einen Import-Einzelvorgang von Blob-Speicher zu Azure verwaltetem Lustre
• Erstellen eines Exportauftrags zum Exportieren von Daten aus Azure Managed Lustre