POSIX-Konformität

Die folgenden Ausnahmen gelten für die POSIX-Compliance von Google Cloud Managed Lustre:

  • atime -Aktualisierungen: atime ist in Lustre standardmäßig aktiviert. Aus Leistungsgründen können Aktualisierungen jedoch verzögert werden. Das bedeutet, dass die Zugriffszeit einer Datei möglicherweise nicht sofort nach jedem Lesevorgang aktualisiert wird.

  • flock/lockf: Diese beziehen sich auf zwei Haupt-APIs für die Dateisperrung: flock(2) und fcntl(2).

    • flock: Dies ist eine beratende Sperre für die gesamte Datei im BSD-Stil, die nicht von POSIX definiert wird. Lustre unterstützt standardmäßig die Semantik von flock im BSD-Stil im gesamten Cluster.
    • fcntl: Dies ist die von POSIX definierte API für die Sperrung, die Sperren für Bytebereiche unterstützt. Die Implementierung von fcntl-Sperren in Lustre ist nahezu POSIX-konform und funktioniert für die meisten Anwendungen wie erwartet. Da fcntl jedoch ursprünglich für lokale Dateisysteme entwickelt wurde, kann kein verteiltes Dateisystem alle fcntl-Anforderungen von POSIX zu 100% erfüllen, einschließlich Lustre. Beispielsweise gibt fcntl() an, dass Sperren sofort freigegeben werden müssen, wenn der zugehörige Prozess beendet wird. Die Freigabe von Lustre-Sperren kann jedoch verzögert werden, wenn der Client abstürzt.

Weitere Informationen finden Sie in den FAQs zu Lustre.

Änderungen der Inode-Nummer aufgrund der Metadatenmigration

Die Inode-Nummer einer Datei in einem Lustre-Dateisystem ist keine unveränderliche Kennung.

Bei einem Metadaten-Neuausgleichsvorgang, z. B. einem Vorgang, der mit lfs migrate initiiert wird, werden die Metadaten einiger Dateien von einem MDT zu einem anderen migriert. Als direkte Folge dieser Migration zu einem neuen MDT wird diesen Dateien eine neue Inode-Nummer zugewiesen.

Dieses Verhalten entspricht zwar dem POSIX-Standard, kann aber die Annahmen vieler gängiger Unix-/Linux-Anwendungen und ‑Dienste verletzen, die eine dauerhafte Inode-Nummer für die Lebensdauer einer Datei erwarten. Dazu zählt unter anderem Folgendes:

  • NFS- und SMB-Frontends: Diese Dienste leiten Dateihandles häufig von Inode-Nummern ab. Eine Änderung kann zu Stale file handle-Fehlern für Clients führen.

  • Archivierungs- und Sicherungsprogramme: Tools wie tar, die Dateien anhand ihrer Geräte- und Inode-Nummer verfolgen, behandeln eine migrierte Datei möglicherweise als neue Datei, was zu ineffizienten inkrementellen Sicherungen führt.

  • Auch Log-Aggregatoren, Intrusion-Detection-Systeme und benutzerdefinierte Anwendungen, die stat() verwenden und st_ino speichern, können betroffen sein.

Administratoren sollten sich dieses Verhaltens und seiner potenziellen Auswirkungen auf Anwendungen bewusst sein, bevor sie einen manuellen Metadaten-Neuausgleich initiieren.

Strategien zur Aussetzung von Maßnahmen

Der Metadaten-Neuausgleich sollte als geplante, störende Wartung betrachtet werden.

  1. Planen Sie ein Wartungsfenster. Informieren Sie alle Nutzer und Anwendungsbesitzer über den geplanten Ausfall. Führen Sie nach Möglichkeit keine umfangreichen lfs migrate-Vorgänge auf einem Live-Produktionssystem aus.

  2. Trennen Sie das Dateisystem nach der Migration und stellen Sie die Verbindung wieder her.

  3. Einige Anwendungen müssen nach einer Migration möglicherweise geleert oder neu gestartet werden.