Verwendung von NFS-gestütztem Blob-Speicher mit Azure HPC Cache

Sie können NFS-verbundene Blob-Container mit Azure HPC Cache verwenden. Erfahren Sie mehr über die NFS 3.0-Protokollunterstützung in Azure Blob Storage auf der Dokumentationswebsite für Blob-Speicher.

Azure HPC Cache verwendet NFS-fähigen BLOB-Speicher im ADLS-NFS Speicherzieltyp. Diese Speicherziele ähneln regulären NFS-Speicherzielen, weisen aber auch einige Überlappungen mit normalen Azure Blob-Zielen auf.

In diesem Artikel werden Strategien und Einschränkungen erläutert, die Sie verstehen sollten, wenn Sie ADLS-NFS Speicherziele verwenden.

Außerdem sollten Sie die NFS-BLOB-Dokumentation lesen, insbesondere die folgenden Abschnitte, die kompatible und inkompatible Szenarien beschreiben, und Tipps zur Problembehandlung geben:

• Übersicht der Funktionen
• Überlegungen zur Leistung
• Einschränkungen und bekannte Probleme
• Anleitung zur Vorgehensweise und Problembehandlung

Grundlegendes zu Konsistenzanforderungen

HPC-Cache erfordert eine starke Konsistenz für ADLS-NFS Speicherziele. Standardmäßig aktualisiert NFS-fähige BLOB-Speicher dateimetadaten nicht streng, was verhindert, dass HPC-Cache Dateiversionen genau vergleicht.

Um diesen Unterschied zu umgehen, deaktiviert Azure HPC Cache automatisch die NFS-Attributzwischenspeicherung für jeden NFS-fähigen BLOB-Container, der als Speicherziel verwendet wird.

Diese Einstellung wird für die Lebensdauer des Containers beibehalten, auch wenn Sie sie aus dem Cache entfernen.

Daten mit dem NFS-Protokoll vorladen

Bei einem NFS-fähigen BLOB-Container kann eine Datei nur mit demselben Protokoll bearbeitet werden, das beim Erstellen verwendet wurde. Das heißt, wenn Sie die Azure REST-API zum Auffüllen eines Containers verwenden, können Sie NFS nicht verwenden, um diese Dateien zu aktualisieren. Da Azure HPC-Cache nur NFS verwendet, kann er keine Dateien bearbeiten, die mit der Azure REST-API erstellt wurden. (Weitere Informationen zu bekannten Problemen mit BLOB-Speicher-APIs)

Es ist kein Problem für den Cache, wenn Ihr Container leer ist oder wenn die Dateien mithilfe von NFS erstellt wurden.

Wenn die Dateien in Ihrem Container mit der Azure Blob REST-API anstelle von NFS erstellt wurden, ist azure HPC Cache auf diese Aktionen für die ursprünglichen Dateien beschränkt:

• Listet die Datei in einem Verzeichnis auf.
• Lesen Sie die Datei (und halten Sie sie im Cache für nachfolgende Lesevorgänge).
• Löschen der Datei
• Leeren Sie die Datei (kürzen Sie sie auf 0).
• Speichern Sie eine Kopie der Datei. Die Kopie ist als NFS-erstellte Datei gekennzeichnet und kann mit NFS bearbeitet werden.

Der Azure HPC-Cache kann den Inhalt einer Datei, die mit REST erstellt wurde, nicht bearbeiten. Dies bedeutet, dass der Cache keine geänderte Datei von einem Client wieder im Speicherziel speichern kann.

Es ist wichtig, diese Einschränkung zu verstehen, da sie Probleme mit der Datenintegrität verursachen kann, wenn Sie Verwendungsmodelle zum Lesen/Schreiben von Cachenutzungsmodellen für Dateien verwenden, die nicht mit NFS erstellt wurden.

Zwischenspeicherungsszenarien schreiben

Zu diesen Cacheverwendungsmodellen gehört die Schreib-Caching:

• Mehr als 15% Schreibvorgänge
• Bei mehr als 15% Schreiboperationen wird der Sicherungsserver alle 30 Sekunden auf Änderungen überprüft.
• Bei mehr als 15% Schreibaufkommen wird alle 60 Sekunden der Sicherungsserver auf Änderungen überprüft.
• Mehr als 15% Schreibvorgänge, alle 30 Sekunden zurück auf den Server schreiben

Verwendungsmodelle für die Schreibzwischenspeicherung sollten nur für Dateien verwendet werden, die mit NFS erstellt wurden.

Wenn Sie versuchen, das Zwischenspeichern von REST-erstellten Dateien zu verwenden, gehen ihre Dateiänderungen möglicherweise verloren. Dies liegt daran, dass der Cache nicht versucht, Dateibearbeitungen sofort im Speichercontainer zu speichern.

Hier erfahren Sie, wie das Zwischenspeichern von Schreibvorgängen in von REST erstellten Dateien Daten gefährden kann:

1. Der Cache akzeptiert Bearbeitungen von Clients und gibt eine Erfolgsmeldung für jede Änderung zurück.

2. Der Cache behält die geänderte Datei im Speicher bei und wartet auf weitere Änderungen.

3. Nach einiger Zeit versucht der Cache, die geänderte Datei im Back-End-Container zu speichern. An diesem Punkt wird eine Fehlermeldung angezeigt, da sie versucht, in eine REST-erstellte Datei mit NFS zu schreiben.

   Es ist zu spät, um dem Clientcomputer mitzuteilen, dass seine Änderungen nicht akzeptiert wurden, und der Cache hat keine Möglichkeit, die originale Datei zu aktualisieren. Damit gehen die Änderungen von Clients verloren.

Zwischenspeicherungsszenarien lesen

Lesezwischenspeicherungsszenarien eignen sich für Dateien, die entweder mit NFS oder der Azure Blob REST-API erstellt wurden.

Diese Nutzungsmodelle verwenden nur Lesezwischenspeicherung.

• Leseintensive, seltene Schreibvorgänge
• Clients schreiben in das NFS-Ziel und umgehen den Cache
• Lesen Sie schwer, überprüfen Sie den Sicherungsserver alle 3 Stunden.

Sie können diese Verwendungsmodelle mit Dateien verwenden, die von der REST-API oder von NFS erstellt wurden. Alle NFS-Schreibvorgänge, die von einem Client an den Back-End-Container gesendet werden, schlagen weiterhin fehl, aber sie schlagen sofort fehl und geben eine Fehlermeldung an den Client zurück.

Ein Lesecaching-Workflow kann weiterhin Dateiänderungen umfassen, solange diese nicht in den Cache aufgenommen werden. Beispielsweise können Clients auf Dateien aus dem Container zugreifen, aber ihre Änderungen als neue Datei zurückschreiben oder geänderte Dateien an einem anderen Speicherort speichern.

Erkennen der Einschränkungen des Netzwerksperrdienstes (NLM)

NFS-fähige BLOB-Container unterstützen Network Lock Manager (NLM) nicht, was ein häufig verwendetes NFS-Protokoll ist, um Dateien vor Konflikten zu schützen.

Wenn Ihr NFS-Workflow ursprünglich für Hardwarespeichersysteme geschrieben wurde, können Ihre Clientanwendungen NLM-Anforderungen enthalten. Um diese Einschränkung beim Verschieben des Prozesses in NFS-fähigen Blob-Speicher zu umgehen, stellen Sie sicher, dass Ihre Clients NLM deaktivieren, wenn sie den Cache bereitstellen.

Um NLM zu deaktivieren, verwenden Sie die Option -o nolock im Befehl Ihres Clients mount . Diese Option verhindert, dass die Clients NLM-Sperren anfordern und dadurch Fehler empfangen. Die nolock Option wird in unterschiedlichen Betriebssystemen unterschiedlich implementiert. Details finden Sie in der Clientbetriebssystemdokumentation (Man 5 nfs).

Vereinfachen von Schreibvorgängen in NFS-fähige Container mit HPC-Cache

Der Azure HPC-Cache kann die Leistung in einer Workload verbessern, die das Schreiben von Änderungen an einem ADLS-NFS Speicherziel umfasst.

Eine der in dem Artikel „Leistungsüberlegungen zu NFS-aktivierten Blobs“ beschriebenen Einschränkungen ist, dass der ADLS-NFS-Speicher beim Überschreiben vorhandener Dateien nicht sehr effizient ist. Wenn Sie Azure HPC-Cache mit NFS-bereitgestelltem BLOB-Speicher verwenden, verarbeitet der Cache intermittierende Neuschreibungen, wenn Clients eine aktive Datei ändern. Die Latenz beim Schreiben einer Datei in den Back-End-Container wird von den Clients ausgeblendet.

Beachten Sie die oben erläuterten Einschränkungen beim Vorladen von Daten mit dem NFS-Protokoll.

Nächste Schritte

• Erfahren Sie ADLS-NFS-Voraussetzungen für Speicherziele
• Erstellen eines NFS-fähigen BLOB-Speicherkontos