Überwachung von Maxfiles, EMS-Ereignissen und ONTAP Erweiterungen
Sowohl die aktuelle Nutzung öffentlicher Inodes als auch die zugewiesene Auslastungsgrenze der öffentlichen Inode-Datei werden überwacht. EMS-Ereignisse dienen zur Erkennung von Erschöpfung und Ungleichgewichten zwischen den Bestandteilen.
EMS-Meldungen im Zusammenhang mit maxfiles
callhome.no.inodes
Dieses ERROR-Ereignis weist darauf hin, dass dem Volume die Inodes ausgegangen sind. Neue Dateisystemobjekte können erst erstellt werden, wenn Inodes verfügbar sind oder der konfigurierte Maximalwert erhöht wird. Vor dem Ändern des Grenzwerts sollten files, files-used, files-maximum-possible und die Volume-Kapazität überprüft werden.
FlexGroup konstituierende Ereignisse
-
fg.inodes.member.nearlyFullgibt an, dass bei einem Konstituenten die Inodes fast erschöpft sind. ONTAP leitet weniger Erstellungen an diesen Konstituenten weiter, was sich potenziell auf die Verteilung und Leistung auswirken kann. -
fg.inodes.member.fullweist darauf hin, dass einem Bestandteil die Inodes ausgegangen sind und er keine neuen Dateien mehr annehmen kann. -
fg.inodes.member.allOKbedeutet, dass die Bedingungen, die die Ereignisse „beinahe voll“ oder „voll“ ausgelöst haben, nicht mehr zutreffen.
Bei FlexGroup Ereignissen sollten sowohl die Verteilung der Constituents als auch die Gesamtwerte auf FlexGroup Ebene untersucht werden. Die Dateikontingentgrenze für FlexGroup sollte erhöht werden, anstatt files direkt für nur einen Constituent festzulegen. Ein Constituent, dessen Daten-Kapazität erschöpft ist, kann dazu führen, dass die gesamte FlexGroup ENOSPC meldet und sogar bei ls fehlschlägt; siehe "FlexGroup Bestandteil ohne freien Speicherplatz".
Überwachungsbeispiel
Mit der CLI lassen sich die öffentliche Obergrenze und die aktuelle Nutzung anzeigen:
volume show -vserver <svm> -volume <volume> -fields files,files-used
Bei erweiterten Berechtigungen sollten der maximal mögliche Wert und die zugewiesene öffentliche Inode-Dateikapazität angegeben werden:
set -privilege advanced volume show -vserver <svm> -volume <volume> -fields files,files-used,files-maximum-possible,files-set-maximum,inodefile-public-capacity volume show-space -vserver <svm> -volume <volume>
Mithilfe der REST API können die öffentliche files Obergrenze und die aktuelle Nutzung abgerufen werden:
GET /api/storage/volumes?name=<volume>&fields=files
Die REST files.maximum- und files.used Felder entsprechen CLI files- und files-used. Das erweiterte CLI-Feld wird für inodefile-public-capacity verwendet.
files-used umfasst öffentliche ACL-Inodes, benannte Streams, Stream-Verzeichnisse, öffentliche Verzeichnisindizes und andere öffentliche Objekte. volume show stellt keinen separaten ACL-Inode-Zähler bereit.
Sowohl die aktuelle Nutzung als auch die Inode-Dateikapazität werden erfasst. Ein niedriger files-used Wert nach einer großen Löschung bedeutet nicht, dass die Inode-Dateikapazität wiederhergestellt wurde.
ONTAP Funktionalität und Erweiterungen im Zusammenhang mit maxfiles
| ONTAP Release | Funktionalität |
|---|---|
Frühere ONTAP 9 Versionen |
Administratoren können |
ONTAP 9.9.1 |
Hinzugefügt wurde |
ONTAP 9.13.1 |
Die automatische Standard-Inode-Größenanpassung wird fortgesetzt, wenn volumes über das frühere Plateau von etwa 21 Millionen hinauswachsen. |
ONTAP 9.17.1 |
Die Option zum Platzieren und Migrieren von directory-index inodes in den öffentlichen Inode-Bereich wurde hinzugefügt. Siehe "Über private und öffentliche Index-Inodes". |
Die Unterstützung und die Beschränkungen können je nach Plattform und volume type variieren. Das Verhalten kann in der Befehlsreferenz für die verwendete ONTAP Version überprüft werden.
Verwandte Informationen
-
"Ermitteln der Datei- und Inode-Nutzung für ein ONTAP Volume"
-
Link:https://docs.netapp.com/us-en/ontap-ems/callhome-no-events.html[
callhome.no.inodesEMS-Referenz^]