Dateisystemkontingente

Google Cloud Managed Lustre-Dateisysteme unterstützen Nutzer-, Gruppen- und Projektkontingente. So können Administratoren die Speichernutzung verwalten und eine faire Ressourcenzuweisung sicherstellen. In diesem Dokument wird beschrieben, wie Sie diese Kontingente konfigurieren, aufrufen und verwalten.

Was sind Dateisystemkontingente?

Mit Kontingenten in Managed Lustre können Sie Grenzwerte für den Speicherplatz und die Anzahl der Dateien festlegen, die Nutzer, Gruppen oder Projekte in Ihrem Dateisystem belegen können.

Kontingente werden auf verschiedene Einheiten angewendet:

  • Nutzerkontingente begrenzen den von einem einzelnen Nicht-Root-Nutzer belegten Speicherplatz.
  • Gruppenkontingente begrenzen den von allen Nicht-Root-Mitgliedern einer bestimmten Gruppe genutzten Speicherplatz.
  • Projektkontingente begrenzen den Speicherplatz, der von Dateien und Verzeichnissen belegt wird, die mit einer bestimmten Projekt-ID verknüpft sind. Diese Projekt-ID ist eine Lustre-Dateisystem-ID, die mit lfs project definiert wird, und nicht IhreGoogle Cloud -Projekt-ID. Weitere Informationen finden Sie unter Projektkontingent festlegen.

Kontingente werden für zwei Ressourcentypen konfiguriert:

  • Blocklimits begrenzen die Menge an Speicherplatz, die verwendet werden kann.
  • Inode-Limits beschränken die Anzahl der Dateien und Verzeichnisse, die erstellt werden können.

Für jeden Ressourcentyp kann es zwei Arten von Limits geben:

  • Ein weiches Limit ist ein Kontingentschwellenwert, der bei Überschreitung einen konfigurierbaren Kulanzzeitraum auslöst. Während dieser Kulanzfrist können Nutzer, Gruppen oder Projekte das Softlimit vorübergehend überschreiten, bis zum Hardlimit, falls vorhanden. So haben sie Zeit, die Nutzung zu reduzieren, bevor sie gesperrt werden. Wenn die Nutzung nach Ablauf des Kulanzzeitraums immer noch über dem Softlimit liegt, wird das Softlimit als Hardlimit durchgesetzt. Alle neuen Schreibvorgänge werden blockiert, bis der Festplattenspeicher oder die Inode-Anzahl unter das Softlimit fällt.

    Standardmäßig beträgt die Kulanzfrist eine Woche.

  • Ein hartes Limit definiert das absolute Maximum. Wenn dieses Limit erreicht ist, schlagen alle weiteren Schreibvorgänge fehl und es wird der Fehler „Disk quota exceeded“ (Festplattenkontingent überschritten) zurückgegeben.

Nutzer und Gruppen verwalten

Lustre verwendet die POSIX-Attribute des Clients für Nutzer- und Gruppennamen und ‑IDs.

Wenn ein Client eine Dateisystemanfrage stellt, sendet er die lokale UID und GID an die Lustre-Server. Die Server verwenden diese POSIX-Attribute, um Standarddateiberechtigungen zu erzwingen und die Kontingentnutzung zu verfolgen.

Damit das Verhalten in einer Umgebung mit mehreren Nutzern konsistent ist, müssen alle Clients, die das Lustre-Dateisystem einbinden, synchronisierte UID- und GID-Zuweisungen haben, die in der Regel über einen zentralen Dienst wie LDAP oder NIS verwaltet werden.

Für Root-Nutzer gelten keine Kontingente. Bei Befehlen, die mit sudo ausgeführt werden, werden auch keine Kontingentprüfungen durchgeführt.

Hinweise

Zum Verwalten von Lustre-Kontingenten benötigen Sie:

  • Clientzugriff auf ein aktives Google Cloud Managed Lustre-Dateisystem.
  • sudo- oder Root-Berechtigungen auf dem Clientsystem zum Ausführen von lfs-Befehlen.

Kontingente festlegen

Verwenden Sie den Befehl lfs setquota, um Block- und Inode-Limits zu konfigurieren. Sie können nur Blocklimits, nur Inodelimits oder beides angeben. Ebenso können Sie feste Limits, weiche Limits oder beides angeben.

sudo lfs setquota -u | g | p | U | G | P UGP_VALUE \
      -b SOFT_BLOCK_LIMIT -B HARD_BLOCK_LIMIT \
      -i SOFT_INODE_LIMIT -I HARD_INODE_LIMIT \
      MOUNT_DIR

Wobei:

  • Mit -u wird ein Nutzer anhand des Nutzernamens oder der UID angegeben.
  • -g gibt eine Gruppe nach Gruppennamen oder GID an.
  • -p gibt ein Projekt anhand der Projekt-ID an.
  • Mit U, G und P wird das Standardkontingent für alle Nutzer, Gruppen oder Projekte festgelegt, für die kein bestimmtes Kontingent festgelegt ist.
  • UGP_VALUE ist der Nutzername, Gruppenname, die UID, die GID oder die Projekt-ID. Lassen Sie diesen Wert weg, wenn Sie Standardkontingente für Nutzer, Gruppen oder Projekte angeben.
  • -b und -B sind weiche und harte Limits für die Blocknutzung. Die weichen Limits sollten kleiner als die harten Limits sein. Werte können in Byte (B), Kilobyte (K), Megabyte (M), Gigabyte (G) oder Terabyte (T) angegeben werden. Die Standardeinheit ist Kilobyte.
  • -i und -I sind weiche und harte Limits für die Inode-Nutzung. Die weichen Limits sollten kleiner als die harten Limits sein.
  • MOUNT_DIR ist der Bereitstellungspunkt des verwalteten Lustre-Dateisystems.

Sie können die Kulanzfrist nicht gleichzeitig mit der Erstellung eines Kontingents konfigurieren. Der standardmäßige Kulanzzeitraum für weiche Limits beträgt eine Woche. Informationen zum Aktualisieren des Kulanzzeitraums finden Sie unter Kulanzzeiträume konfigurieren.

Beispiele

Nutzerkontingent festlegen

So legen Sie für user1 auf /mnt/lustre ein weiches Blocklimit von 100 GB, ein hartes Blocklimit von 120 GB, ein weiches Inodelimit von 10.000 und ein hartes Inodelimit von 12.000 fest:

sudo lfs setquota -u user1 -b 100G -B 120G -i 10000 -I 12000 /mnt/lustre

Gruppenkontingent festlegen

Legen Sie ein festes Blocklimit von 50 TB für groupA auf /mnt/lustre fest:

sudo lfs setquota -g groupA -B 50T /mnt/lustre

Projektkontingent festlegen

Für Projektkontingente ist ein zusätzlicher Schritt erforderlich, um Verzeichnisse und Dateien einer Projekt-ID zuzuordnen:

  1. Verwenden Sie den Befehl lfs project, um eine Projekt-ID zuzuweisen. Diese ID ist eine beliebige Ganzzahl, die das Projekt identifiziert.

    sudo lfs project -spr LFS_PROJECT_ID PATH/TO/DIR/OR/FILE
    

    Wobei:

    • Mit -s wird die Vererbung festgelegt, sodass neue Dateien und Verzeichnisse, die im angegebenen Verzeichnis erstellt werden, die Projekt-ID erben.
    • Mit -r wird die Projekt-ID rekursiv auf alle untergeordneten Verzeichnisse und Dateien angewendet.
    • -p weist den Befehl an, die angegebene Projekt-ID für die angegebene Datei oder das angegebene Verzeichnis festzulegen.
    • PATH/TO/DIR/OR/FILE ist der Pfad zu einem Verzeichnis oder einer Datei, für die die Projekt-ID festgelegt werden soll. Es kann nur ein Pfad oder eine Datei angegeben werden.

    Weitere Flags und Informationen erhalten Sie, wenn Sie man lfs project auf Ihrem Client ausführen.

    Wenn Sie beispielsweise das Projekt 101 dem Projekt /mnt/lustre/my-project und allen untergeordneten Elementen (neuen und vorhandenen) zuweisen möchten:

    sudo lfs project -spr 101 /mnt/lustre/my-project
    
  2. So legen Sie das Kontingent mit lfs setquota fest:

    sudo lfs setquota -p LFS_PROJECT_ID \
      -b SOFT_BLOCK_LIMIT -B HARD_BLOCK_LIMIT \
      -i SOFT_INODE_LIMIT -I HARD_INODE_LIMIT \
      MOUNT_DIR
    

Standardkontingent festlegen

Legen Sie ein festes Blockierungslimit von 50 TB für alle Nutzer ohne spezifische Kontingenteinstellung fest:

sudo lfs setquota -U -B 50T /mnt/lustre

Kontingente ändern

Wenn Sie ein vorhandenes Kontingent ändern möchten, führen Sie lfs setquota noch einmal mit den neuen Werten aus. Mit dem Befehl werden die vorherigen Einstellungen für den angegebenen Nutzer, die Gruppe oder das Projekt überschrieben.

Kulanzzeiträume konfigurieren

Mit Kulanzzeiträumen wird festgelegt, wie lange ein Nutzer, eine Gruppe oder ein Projekt ein Soft Limit überschreiten darf, bevor es als Hard Limit gilt. Standardmäßig ist dieser Wert eine Woche. Kulanzzeiträume werden für alle Nutzer, Gruppen oder Projekte festgelegt und können nicht für bestimmte IDs festgelegt werden.

Verwenden Sie den Befehl lfs setquota -t, um eine Kulanzfrist zu aktualisieren:

sudo lfs setquota -t -u | g | p \
  -b BLOCK_GRACE_PERIOD -i INODE_GRACE_PERIOD \
  MOUNT_DIR

Wobei:

  • -u wendet den Kulanzzeitraum auf Nutzerkontingente an.
  • -g wendet den Kulanzzeitraum auf Gruppenkontingente an.
  • -p wendet den Kulanzzeitraum auf Projektkontingente an.
  • -b und -i geben die Kulanzzeiten für Blöcke bzw. Inodes an. Die Standardeinheit ist „Sekunden“. Sie können auch andere Einheiten im Format XwXdXhXmXs verwenden (Wochen, Tage, Stunden, Minuten, Sekunden). Sie können Limits für einen oder beide Kontingenttypen festlegen.

    Geben Sie 'notify' anstelle eines Zeitwerts an, um die Ausgabe von lfs quota mit einem Sternchen zu markieren, wenn das Soft Limit überschritten wurde. Neue Schreibvorgänge werden nicht blockiert, wenn 'notify' angegeben ist, bis das Hard Limit erreicht ist.

So legen Sie beispielsweise eine Kulanzfrist von 7 Tagen für alle Nutzerkontingente fest:

sudo lfs setquota -t -u -b 7d /mnt/lustre

So legen Sie eine Kulanzzeit von 24 Stunden für Inodes für Projektkontingente fest:

sudo lfs setquota -t -p -i 24h /mnt/lustre

So werden Sie benachrichtigt, wenn ein „weiches“ Blocklimit überschritten wird:

sudo lfs setquota -t -u -b 'notify' /mnt/lustre

Vorhandene Kontingente ansehen

Mit dem Befehl lfs quota werden die Nutzung und die Limits für den aktuellen Nutzer angezeigt:

lfs quota MOUNT_DIR

Eine vollständige Liste der Optionen erhalten Sie mit dem Befehl man lfs quota.

So rufen Sie beispielsweise das Kontingent von user1 für /mnt/lustre auf:

sudo lfs quota -u user1 /mnt/lustre

Wenn Sie das Kontingent und die Nutzung eines anderen Nutzers aufrufen möchten, müssen Sie den Befehl mit sudo ausführen.

Die Ausgabe zeigt:

  • Filesystem: Der Lustre-Bereitstellungspunkt.
  • kbytes: Aktuelle Festplattennutzung in Kilobyte.
  • bquota: Das Limit für Softblocks in Kilobyte.
  • blimit: Limit für harte Blöcke in Kilobyte.
  • bgrace: Verbleibende Kulanzfrist, wenn das Softlimit für Blöcke überschritten wird. Ein Sternchen (*) gibt an, dass das vorläufige Limit überschritten wurde.
  • files: Anzahl der verwendeten Inodes.
  • iquota: Weiches Inode-Limit.
  • ilimit: Hartes Inode-Limit.
  • igrace: Verbleibender Kulanzzeitraum, wenn das Inode-Softlimit überschritten wird. Ein Sternchen (*) gibt an, dass das vorläufige Limit überschritten wurde.

So rufen Sie die konfigurierten Kulanzzeiträume für alle Nutzerkontingente auf:

lfs quota -t -u /mnt/lustre

Kontingente entfernen

Wenn Sie ein Kontingent entfernen möchten, legen Sie die weichen und harten Limits auf 0 fest.

sudo lfs setquota -u | g | p | U | G | P UGP_VALUE -b 0 -B 0 -i 0 -I 0 MOUNT_DIR

So entfernen Sie beispielsweise die Block- und Inode-Kontingente von user1:

sudo lfs setquota -u user1 -b 0 -B 0 -i 0 -I 0 /mnt/lustre

So entfernen Sie das Standardlimit für Projektblöcke:

sudo lfs setquota -P -b 0 -B 0 /mnt/lustre

Allgemeine Probleme

Beachten Sie bei der Arbeit mit Lustre-Kontingenten die folgenden häufigen Probleme:

  • Gewährter Cache: Gewährter Cache ist eine Lustre-Funktion, mit der Clients einen Speicherblock als „Gewährung“ vom Objektspeicherziel (Object Storage Target, OST) zum Schreiben von Daten erhalten können. Wenn ein Client diesen Cache hat, kann er dem Nutzer sofort eine Erfolgsmeldung für einen Schreibvorgang zurückgeben, auch wenn sich die Daten noch im lokalen Cache des Clients befinden und bevor die Daten physisch auf die Festplatte geschrieben werden. Dies ist eine Leistungsoptimierung, die die Latenz minimiert.

    Durch den gewährten Cache besteht die Gefahr von Kontingentüberschreitungen. Da der gewährte Cache es Clients ermöglicht, weiterhin Daten in ihren Cache zu schreiben, auch wenn ihr serverseitiges Kontingent inzwischen erschöpft ist, kann ein Nutzer sein hartes Limit überschreiten.

  • Falsche Zuweisung der Projekt-ID: Damit Projektkontingente funktionieren, muss Verzeichnissen und Dateien mit lfs project -spr eine Projekt-ID zugewiesen werden. Wenn Sie -r weglassen, wird die Projekt-ID nicht auf vorhandene Dateien und Unterverzeichnisse angewendet. Wenn Sie -s weglassen, wird die Projekt-ID nicht an neue Dateien und Verzeichnisse weitergegeben, die später erstellt werden.

  • Mehrere Kontingente und „das restriktivste gewinnt“: Ein Nutzer kann gleichzeitig einem Nutzerkontingent, einem oder mehreren Gruppenkontingenten und einem oder mehreren Projektkontingenten unterliegen. Lustre erzwingt die restriktivste dieser Beschränkungen. Das bedeutet, dass ein Nutzer zwar ein großes persönliches Kontingent haben kann, aber durch ein kleineres Projektkontingent für Dateien im Verzeichnis dieses Projekts eingeschränkt sein kann.

  • Umgehung des Administratorkontingents: Schreibvorgänge eines root-Nutzers umgehen die Kontingenterzwingung. Das Dateisystem kann dadurch durch administrative Aufgaben gefüllt werden, auch wenn für andere Nutzer Kontingente gelten.

  • fallocate berücksichtigt keine Kontingente: Nutzer können mit fallocate Speicherplatz im Dateisystem reservieren, der das Hardlimit überschreitet.