POSIX-Konformität

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

  • atime-Updates: atime ist in Lustre standardmäßig aktiviert. Aus Leistungsgründen können die Updates 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 BSD-basierte, dateiweite Empfehlungssperre, die nicht von POSIX definiert wird. Lustre unterstützt standardmäßig die flock-Semantik im BSD-Stil im gesamten Cluster.
    • fcntl: Dies ist die POSIX-definierte Locking API, die Bytebereichssperren 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, einschließlich Lustre, alle fcntl-Anforderungen von POSIX zu 100% erfüllen. fcntl() gibt beispielsweise 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 Lustre-FAQs.

Änderungen der Inode-Nummer aufgrund der Metadatenmigration

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

Bei einem Metadaten-Rebalancing-Vorgang, z. B. einem von lfs migrate initiierten, 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 so konzipiert sind, dass sie für die Lebensdauer einer Datei eine persistente Inode-Nummer erwarten. Dazu zählt unter anderem Folgendes:

  • NFS- und SMB-Frontends: Bei diesen Diensten werden Dateihandles häufig aus Inode-Nummern abgeleitet. Eine Änderung kann zu Stale file handle-Fehlern für Clients führen.

  • Archivierungs- und Sicherungstools: 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 Logaggregatoren, Intrusion Detection Systems und benutzerdefinierte Anwendungen, die stat() verwenden und st_ino speichern, können betroffen sein.

Administratoren sollten sich dieses Verhalten und seine potenziellen Auswirkungen auf Anwendungen bewusst sein, bevor sie eine manuelle Neuausrichtung der Metadaten vornehmen.

Strategien zur Risikominderung

Die Neuausrichtung von Metadaten sollte als geplante, störende Wartung betrachtet werden.

  1. Planen Sie ein Wartungsfenster. Informieren Sie alle Nutzer und Anwendungsbesitzer über einen geplanten Ausfall. Führen Sie möglichst keine umfangreichen lfs migrate-Vorgänge in einem aktiven Produktionssystem aus.

  2. Trennen Sie das Dateisystem nach der Migration bei Bedarf und hängen Sie es wieder ein.

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