Erfassung oder Schätzung:

Es empfiehlt sich, Höchstwerte anstelle von Tagesdurchschnitten zu verwenden. Build Pipelines, Analyseaufträge, Migrationen und temporäre Scratch-Workflows erstellen oft für kurze Zeit ihren größten Namespace und bereinigen ihn anschließend, aber die Inode- und Verzeichnisdateien können nach der Bereinigung Höchststände beibehalten.

Zwei separate Prognosen werden beibehalten:

Ein Wert darf nicht vom anderen abgeleitet werden. Ein Sharded Namespace (Dateien verteilt auf viele Verzeichnisse) kann `maxfiles`auch ohne Erstellung eines großen Verzeichnisses an seine Grenzen stoßen. Ein einzelnes flaches Verzeichnis kann die `maxdir-size`Grenze erreichen, obwohl das Volume Millionen freier Inodes aufweist.

Die Größe sollte bei NTFS oder stark durch ACLs eingeschränkten Namensräumen nicht allein anhand der Anzahl sichtbarer Dateien berechnet werden maxfiles. Verzeichnisse, ACL-Inodes, benannte Datenströme und andere öffentliche Objekte sollten in die Prognosen einbezogen werden. Bei starker ACL-Nutzung sollte als konservative Ausgangsschätzung für `files`bis zum Doppelten der prognostizierten Anzahl von Dateien und Verzeichnissen angesetzt und dies anschließend mit repräsentativen Daten validiert werden, da die gemeinsame Nutzung von ACLs die tatsächliche Nutzung reduzieren kann.

Siehe "ONTAP Inode-Typen" und "Maxdir-Größe und große ONTAP Verzeichnisse".

Es gibt drei gängige Namespace-Layouts.

Wenn möglich, sollte vermieden werden, Millionen von Namen auf einer einzigen flachen Verzeichnisebene zu speichern, falls die Anwendung eine breite oder tiefe Hierarchie nutzen kann. Flache Verzeichnisstrukturen konzentrieren Speicher- und CPU-Last und können die Latenz bei Massen GETATTR, READDIR, Such- und Löschvorgängen erhöhen. In einem FlexGroup Volume kann ein großes flaches Verzeichnis außerdem mehr entfernte Einträge erzeugen, wodurch sich die Verzeichnisdatei `maxdir-size`früher annähert als bei derselben Anzahl sichtbarer Namen in einem FlexVol.

FlexGroup Volumes funktionieren im Allgemeinen besser mit vielen kleineren Verzeichnissen als mit einem großen, flachen Verzeichnis. Verzeichnisse mit weniger als etwa 2 MiB bleiben auf dem einfachen Scanpfad. Ab ONTAP 9.2 werden größere Verzeichnisse automatisch indiziert, was gezielte Suchvorgänge erleichtert. Die Indizierung macht ein sehr großes Verzeichnis jedoch nicht mit einer Sharded-Hierarchie gleichwertig: Enumeration, Wildcard-Scans und die Serialisierung beim Erstellen in einem einzelnen Verzeichnis gelten weiterhin. ONTAP kann FlexGroup untergeordnete Verzeichnisse remote platzieren und dabei die Dateilokalität zum übergeordneten Verzeichnis bevorzugen, wodurch die Remote-Latenz für diese Dateien reduziert wird.

Die Verteilung von Dateien über eine Hierarchie hinweg bedeutet die Verwendung von mehr Verzeichnissen mit jeweils weniger Dateien in jedem Verzeichnis.

Gängige Sharding-Schlüssel sind:

Es sollten genügend Shards gewählt werden, um die Verzeichnisoperationen überschaubar zu halten, aber nicht so viele nahezu leere Verzeichnisse erstellt werden, dass die Verzeichnisanzahl selbst übermäßig wird. Ein deterministisches Schema macht die Platzierung vorhersehbar und ermöglicht es Clients, Dateien zu finden, ohne jeden Shard durchsuchen zu müssen.

Sowohl breite als auch tiefe Layouts können funktionieren. Die vollständigen Pfadlängen sollten innerhalb der Grenzen des NAS-Protokolls, des Client-Betriebssystems und der Anwendung bleiben. Wenn ein flaches Layout unvermeidbar ist, sollten die aktuelle Größe und der verfügbare Spielraum der größten Verzeichnisdatei wie in `maxdir-size`"maxdir-size und aktuelles Verzeichnis Größe anzeigen" beschrieben überwacht und geprüft werden, ob eine kontrollierte Vergrößerung angemessen ist.

Ein Dauerbetrieb mit 100 % ausgelasteten Inodes oder der größten Verzeichnisdatei sollte nicht eingeplant werden. Es sollte Marge für unerwartetes Wachstum, temporäre Objekte, in Snapshots gespeicherte Metadaten, ACLs und Streams, Migrationsüberschneidungen, Backup-Arbeiten, FlexGroup Platzierungsungleichgewichte und Softwareänderungen, die Dateinamen verändern, vorgesehen werden.

Die Einstellung files auf den aktuellen Maximalwert stellt eine Obergrenze dar und erlaubt nicht, den Betrieb bis zum Verbrauch des letzten Inodes fortzusetzen. Eine Warnung sollte files-used deutlich vor dieser Obergrenze erfolgen. Für maxdir-size die Anleitung zur Erhöhung um ca. 2 % in "Was passiert, wenn maxdir-size überschritten wird?" gilt, dass sie beschreibt, wie die Obergrenze erhöht wird, und keine allgemeine Betriebsmarge darstellt.

Inode-Datei, Verzeichnisdatei, Index, Snapshot und Aggregat-Metadaten sind separat zu budgetieren. Als Basisschätzung für die Inode-Datei sind 288 Byte pro zugewiesenem öffentlichen Inode zu verwenden; siehe "Kapazitätsauswirkungen". Eine Erhöhung files weist diesen Speicherplatz nicht sofort zu. Die maximale zugewiesene Inode-Datei-Kapazität ist als persistent zu behandeln.

Verwenden Sie volume show-space, um die Inode- und Metadatenkapazität zu überprüfen, anstatt jeden CLI-Zähler so umzuwandeln, als wäre er ein Byte-Wert.

Mindestens zu testen:

Pfadlänge und Basisnamenslänge sind nicht austauschbar. Ein langer Pfad, der sich über mehrere Verzeichnisse erstreckt, beeinflusst Protokollgrenzen und die Anzahl der Inodes, während jedes Verzeichnis nur seine unmittelbare Komponente speichert.

Sequenzielle Bandbreitentests sagen das Verhalten bei einer hohen Anzahl von Dateien nicht voraus. Folgendes ist zu berücksichtigen:

Latenzverteilungen, CPU-Auslastung, Cache-Verhalten, Netzwerklast und Abschlusszeiten werden gemessen. Tests werden während Snapshot-, Replikations-, Analyse-, Backup- und Sicherheitsscan-Vorgängen wiederholt, falls diese Prozesse in der Produktionsumgebung gleichzeitig stattfinden.

Mehr als nur die erste Aufnahme wird getestet:

Verzeichnisindizes müssen möglicherweise am Zielort erstellt oder übertragen werden. Die Übertragung öffentlicher Indizes sollte nur dann aktiviert werden, wenn die Vermeidung von Neuaufbauten die Wiederherstellung wesentlich verbessert; die lokale Suche wird dadurch nicht verbessert. Siehe "Zeitpunkt für die Aktivierung öffentlicher Verzeichnisindexübertragungen".

Verfolgung von files-used im Vergleich zu files und inodefile-public-capacity, wie in "Überwachung von Maxfiles, EMS-Ereignissen und ONTAP Erweiterungen" beschrieben. Warnung, bevor files-used files erreicht. Bei FlexGroup Volumes sollten Ereignisse auf Constituent-Ebene untersucht werden, selbst wenn die Gesamtsumme noch Spielraum zu haben scheint.

Die Verzeichnisdateigröße ist zu messen und EMS-Datei-IDs sind wie in "maxdir-size und aktuelles Verzeichnis Größe anzeigen" beschrieben aufzulösen. Bekannte flache oder Verzeichnisse mit hoher Änderungsrate sind zu inventarisieren, bevor sie Warnungen generieren.

Für Inode-Warnungen:

Bei Warnungen bezüglich der Verzeichnisgröße:

Warten Sie nicht auf callhome.no.inodes oder wafl.dir.size.max; zu diesem Zeitpunkt schlagen Client-Erstellungsvorgänge bereits fehl.

Das Löschen von Dateien gibt öffentliche Inodes zur Wiederverwendung frei, verkleinert aber nicht die öffentliche Inode-Datei. Ebenso macht das Löschen von Namen aus einem Verzeichnis Verzeichniseinträge wiederverwendbar, reduziert aber normalerweise nicht die Höchstgröße der Verzeichnisdatei.

Große Löschvorgänge können metadatenintensiv sein und vorübergehend private Zombie-Inodes erhöhen. Eine Begrenzung von Client-seitig rekursiven Löschvorgängen (rm -rf ist sinnvoll, wenn diese mit dem Produktionsdatenverkehr konkurrieren.

Ab ONTAP 9.8 wird ein Verzeichnis volume file async-delete direkt aus dem Cluster entfernt, anstatt über NFS oder SMB, wodurch Client- und Netzwerkkonflikte vermieden werden. Dies gilt für FlexVol- und FlexGroup-Volumes. ONTAP scannt den Pfad, löscht zuerst die Inhalte der Unterverzeichnisse und führt anschließend parallele Löschvorgänge aus (standardmäßig 5.000 gleichzeitige Vorgänge; konfigurierbar von 50 bis 100.000). In den Tests gemäß TR-4571 war dies bei einem Verzeichnisbaum mit 24.000 Einträgen etwa 10× schneller als ein einzelner Thread rm -rf.

Einschränkungen: Das Volume muss online und eingebunden sein, der Pfad muss ein Verzeichnis (nicht eine einzelne Datei) sein, und es kann jeweils nur ein Job für asynchrones Löschen ausgeführt werden.

Falls ein großes, spärlich bestücktes Verzeichnis weiterhin Probleme bereitet, sollten die verbleibenden Einträge in ein neues Verzeichnis kopiert werden. Das Verkleinern maxdir-size führt nicht zu einer Komprimierung. Siehe "Dünn besetzte Verzeichnisse und Hole Punching".

Operationen mit einer hohen Anzahl an Dateien beanspruchen CPU, Arbeitsspeicher, Cache und Speicher-E/A auch bei geringem Datendurchsatz. Es sollte ausreichend Reserve für Folgendes vorhanden sein:

Arbeitslasten sollten anhand des beobachteten Metadatenbedarfs und nicht nur anhand der Kapazität oder des Durchsatzes ausgeglichen werden. Ein Knoten kann durch Metadaten begrenzt sein, obwohl Netzwerk- und Festplatten-Bandbreite scheinbar verfügbar sind.

NAS-Systeme mit vielen Dateien sind oft durch Metadaten gebunden. Eine NFS- oder SMB-Einbindung nutzt typischerweise eine TCP-Verbindung zu einem Daten-LIF, und dieses LIF befindet sich auf einem einzelnen Knoten. Wenn viele Clients, Scanner oder Backup-Aufträge dieselbe Adresse einbinden, verbraucht dieser Knoten CPU-Leistung für die Protokollverarbeitung, selbst wenn der Rest des Clusters im Leerlauf ist. Eine FlexGroup kann Dateivorgänge über das Clusternetzwerk umleiten, dies entlastet jedoch nicht den Knoten, dem die Client-Verbindung gehört.

Ein einzelner Client, der NFS nconnect oder SMB Multichannel unterstützt, kann zusätzliche Verbindungen auf einem Mount öffnen. Das hilft diesem Client; es ersetzt jedoch nicht die Verteilung vieler Clients auf LIFs und Knoten.

Spätere ONTAP Versionen beinhalten Verzeichnisindizierung, Verbesserungen im Inode-Management, Optimierungen für Sparse-Verzeichnisse, Verzeichnisindexübertragung und weitere Verbesserungen für hohe Dateianzahlen. Bei Upgrade-Entscheidungen müssen weiterhin Plattformunterstützung, Datenschutzkompatibilität und Anwendungsqualifizierung berücksichtigt werden.

Aktivieren Sie eine Funktion nicht allein deshalb, weil sie mit einer hohen Dateianzahl zusammenhängt:

Ab ONTAP 9.17.1 kann die File System Analytics standardmäßig auf neuen Volumes in einer neu erstellten NAS SVM aktiviert sein. Es sollte `-analytics-state`geprüft werden, anstatt anzunehmen, dass sie deaktiviert ist, und ihr Namespace-Scan sollte bei der Qualifizierung einer Arbeitslast mit hoher Dateianzahl berücksichtigt werden.

Datensatz:

Das Modell sollte erneut überprüft werden, wenn sich Anwendungsversionen, Dateinamenformate, Aufbewahrungsfristen, Protokolle oder Datenschutz-Workflows ändern.