Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die Verwendung von Lustre Speicherkontingente

Sie können Speicherkontingente für Benutzer, Gruppen und Projekte auf FSx Lustre-Dateisystemen erstellen. Mit Speicherkontingenten können Sie den Speicherplatz und die Anzahl der Dateien, die ein Benutzer, eine Gruppe oder ein Projekt verbrauchen kann, einschränken. Speicherkontingente verfolgen automatisch die Nutzung auf Benutzer-, Gruppen- und Projektebene, sodass Sie den Verbrauch überwachen können, unabhängig davon, ob Sie Speicherlimits festlegen oder nicht.

Amazon FSx setzt Kontingente durch und verhindert, dass Benutzer, die diese überschritten haben, auf den Speicherplatz schreiben. Wenn Benutzer ihre Kontingente überschreiten, müssen sie genügend Dateien löschen, um die Kontingentgrenzen zu überschreiten, sodass sie wieder in das Dateisystem schreiben können.

Durchsetzung von Kontingenten

Die Durchsetzung von Benutzer-, Gruppen- und Projektkontingenten wird automatisch auf allen Dateisystemen FSx für Lustre aktiviert. Die Durchsetzung von Kontingenten kann nicht deaktiviert werden.

Arten von Kontingenten

Systemadministratoren mit AWS Root-Benutzeranmeldedaten können die folgenden Arten von Kontingenten erstellen:

Wenn Sie Kontingente für einen bestimmten Benutzer und eine Gruppe festlegen und der Benutzer Mitglied dieser Gruppe ist, gilt die Datennutzung des Benutzers für beide Kontingente. Es ist auch durch beide Kontingente begrenzt. Wenn eine der Kontingentgrenzen erreicht wird, wird der Benutzer daran gehindert, in das Dateisystem zu schreiben.

Kontingentgrenzen und Übergangsfristen

Amazon FSx setzt Nutzer-, Gruppen- und Projektkontingente als festes Limit oder als Soft-Limit mit konfigurierbarem Kulanzzeitraum durch.

Das harte Limit ist das absolute Limit. Wenn Benutzer ihr festes Limit überschreiten, schlägt eine Block- oder Inode-Zuweisung fehl und es wird eine Meldung angezeigt, dass das Festplattenkontingent überschritten wurde. Benutzer, die ihr festes Kontingentlimit erreicht haben, müssen genügend Dateien oder Verzeichnisse löschen, um das Kontingentlimit zu unterschreiten, bevor sie wieder in das Dateisystem schreiben können. Wenn ein Kulanzzeitraum festgelegt ist, können Benutzer das Soft-Limit innerhalb des Kulanzzeitraums überschreiten, wenn das Hard-Limit unterschritten wird.

Für Soft-Limits konfigurieren Sie eine Kulanzzeit in Sekunden. Das Soft-Limit muss kleiner als das Hard-Limit sein.

Sie können unterschiedliche Übergangsfristen für Inode- und Blockkontingente festlegen. Sie können auch unterschiedliche Kulanzzeiträume für ein Benutzerkontingent, ein Gruppenkontingent und ein Projektkontingent festlegen. Wenn Benutzer-, Gruppen- und Projektkontingente unterschiedliche Kulanzzeiträume haben, wird das weiche Limit nach Ablauf der Kulanzzeit eines dieser Kontingente in ein festes Limit umgewandelt.

Wenn Benutzer ein Soft-Limit überschreiten, FSx erlaubt Amazon ihnen, ihr Kontingent weiter zu überschreiten, bis die Karenzzeit abgelaufen ist oder bis das harte Limit erreicht ist. Nach Ablauf der Karenzzeit wird das weiche Limit in ein festes Limit umgewandelt, und Benutzer werden für weitere Schreibvorgänge gesperrt, bis ihre Speichernutzung wieder unter die definierten Block- oder Inode-Kontingentgrenzen fällt. Benutzer erhalten keine Benachrichtigung oder Warnung, wenn die Kulanzfrist beginnt.

Kontingente festlegen und anzeigen

Sie legen Speicherkontingente fest mit Lustre lfsDateisystembefehle in Ihrem Linux-Terminal. Der lfs setquota Befehl legt Kontingentgrenzen fest und der lfs quota Befehl zeigt Kontingentinformationen an.

Weitere Informationen zur Lustre Quota-Befehle finden Sie im Lustre-Betriebshandbuch auf der Lustre Website zur Dokumentation.

Festlegung von Benutzer-, Gruppen- und Projektkontingenten

Die Syntax des setquota Befehls zum Festlegen von Benutzer-, Gruppen- oder Projektkontingenten lautet wie folgt.

lfs setquota {-u|--user|-g|--group|-p|--project} username|groupname|projectid
             [-b block_softlimit] [-B block_hardlimit]
             [-i inode_softlimit] [-I inode_hardlimit]
             /mount_point

Wobei gilt:

Beispiel für ein Benutzerkontingent: Mit dem folgenden Befehl wird ein Softblock-Limit von 5.000 KB, ein Hardblock-Limit von 8.000 KB, ein Soft-Inode-Limit von 2.000 KB und ein Hard-Inode-Limit von 3.000 KB für das Dateisystem festgelegt, user1 auf das gemountet ist. /mnt/fsx

sudo lfs setquota -u user1 -b 5000 -B 8000 -i 2000 -I 3000 /mnt/fsx

Beispiel für ein Gruppenkontingent: Mit dem folgenden Befehl wird ein Hardblock-Limit von 100.000 KB für die Gruppe festgelegt, die auf dem Dateisystem benannt ist, group1 auf das gemountet wurde. /mnt/fsx

sudo lfs setquota -g group1 -B 100000 /mnt/fsx

Beispiel für ein Projektkontingent: Stellen Sie zunächst sicher, dass Sie den project Befehl verwendet haben, um die gewünschten Dateien und Verzeichnisse dem Projekt zuzuordnen. Mit dem folgenden Befehl werden beispielsweise alle Dateien und Unterverzeichnisse des /mnt/fsxfs/dir1 Verzeichnisses dem Projekt zugeordnet, dessen Projekt-ID lautet100.

sudo lfs project -p 100 -r -s /mnt/fsxfs/dir1

Verwenden Sie dann den setquota Befehl, um das Projektkontingent festzulegen. Mit dem folgenden Befehl wird ein Softblock-Limit von 307.200 KB, ein Hardblock-Limit von 309.200 KB, ein Soft-Inode-Limit von 10.000 KB und ein Hard-Inode-Limit von 11.000 KB für das Projekt 250 auf dem Dateisystem festgelegt, auf das gemountet ist. /mnt/fsx

sudo lfs setquota -p 250 -b 307200 -B 309200 -i 10000 -I 11000 /mnt/fsx

Kulanzfristen festlegen

Die Standard-Nachfrist beträgt eine Woche. Sie können den Standard-Kulanzzeitraum für Benutzer, Gruppen oder Projekte mithilfe der folgenden Syntax anpassen.

lfs setquota -t {-u|-g|-p}
             [-b block_grace]
             [-i inode_grace]
             /mount_point

Wobei gilt:

Mit dem folgenden Befehl werden Übergangsfristen von 1.000 Sekunden für Benutzerblockkontingente und von 1 Woche und 4 Tagen für Benutzer-Inode-Kontingente festgelegt.

sudo lfs setquota -t -u -b 1000 -i 1w4d /mnt/fsx

Kontingente anzeigen

Der quota Befehl zeigt Informationen zu Benutzerkontingenten, Gruppenkontingenten, Projektkontingenten und Kulanzfristen an.

Kontingente und mit Amazon S3 verknüpfte Buckets

Sie können Ihr FSx for Lustre-Dateisystem mit einem Amazon S3 S3-Daten-Repository verknüpfen. Weitere Informationen finden Sie unter Ihr Dateisystem mit einem Amazon S3 S3-Bucket verknüpfen.

Sie können optional einen bestimmten Ordner oder ein bestimmtes Präfix innerhalb eines verknüpften S3-Buckets als Importpfad zu Ihrem Dateisystem wählen. Wenn ein Ordner in Amazon S3 angegeben und von S3 in Ihr Dateisystem importiert wird, werden nur die Daten aus diesem Ordner auf das Kontingent angerechnet. Die Daten des gesamten Buckets werden nicht auf die Kontingentgrenzen angerechnet.

Dateimetadaten in einem verknüpften S3-Bucket werden in einen Ordner importiert, dessen Struktur dem importierten Ordner aus Amazon S3 entspricht. Diese Dateien werden auf die Inode-Kontingente der Benutzer und Gruppen angerechnet, denen die Dateien gehören.

Wenn ein Benutzer eine Datei hsm_restore verzögert oder verzögert lädt, wird die volle Größe der Datei auf das Blockkontingent angerechnet, das dem Eigentümer der Datei zugewiesen ist. Wenn Benutzer A beispielsweise eine Datei verzögert lädt, deren Eigentümer Benutzer B ist, werden der Speicherplatz und die Inode-Nutzung auf das Kontingent von Benutzer B angerechnet. In ähnlicher Weise werden die Daten, wenn ein Benutzer Amazon verwendet, FSx API um eine Datei freizugeben, von den Blockquoten des Benutzers oder der Gruppe befreit, der die Datei gehört.

Da HSM Wiederherstellungen und verzögertes Laden mit Root-Zugriff durchgeführt werden, umgehen sie die Einhaltung von Kontingenten. Sobald Daten importiert wurden, werden sie auf der Grundlage der in S3 festgelegten Eigentumsrechte dem Benutzer oder der Gruppe angerechnet, was dazu führen kann, dass Benutzer oder Gruppen ihre Blocklimits überschreiten. In diesem Fall müssen sie Dateien freigeben, um wieder in das Dateisystem schreiben zu können.

In ähnlicher Weise erstellen Dateisysteme mit aktiviertem automatischem Import automatisch neue Inodes für Objekte, die zu S3 hinzugefügt wurden. Diese neuen Inodes werden mit Root-Zugriff erstellt und umgehen die Einhaltung von Kontingenten, während sie erstellt werden. Diese neuen Inodes werden auf die Benutzer und Gruppen angerechnet, je nachdem, wem das Objekt in S3 gehört. Wenn diese Benutzer und Gruppen aufgrund der automatischen Importaktivität ihre Inode-Kontingente überschreiten, müssen sie Dateien löschen, um zusätzliche Kapazität freizugeben und ihre Kontingentgrenzen zu unterschreiten.

Kontingente und Wiederherstellung von Backups

Wenn Sie ein Backup wiederherstellen, werden die Kontingenteinstellungen des ursprünglichen Dateisystems im wiederhergestellten Dateisystem implementiert. Wenn beispielsweise Kontingente in Dateisystem A festgelegt sind und Dateisystem B aus einer Sicherung von Dateisystem A erstellt wird, werden die Kontingente von Dateisystem A in Dateisystem B durchgesetzt.