Collectez ou estimez :

Utilisez les valeurs maximales plutôt que les moyennes journalières. Les pipelines de build, les tâches d’analyse, les migrations et les flux de travail temporaires créent souvent leur plus grand espace de noms pendant une courte période, puis le nettoient, mais les fichiers d’inode et de répertoire peuvent conserver des valeurs maximales après le nettoyage.

Établir deux prévisions distinctes :

Ne déduisez pas une valeur de l'autre. Un espace de noms partitionné (fichiers répartis dans plusieurs répertoires) peut épuiser maxfiles sans créer un grand répertoire. Un seul répertoire plat peut atteindre la limite maxdir-size alors que le volume dispose de millions d'inodes libres.

Ne vous basez pas maxfiles uniquement sur le nombre de fichiers visibles pour dimensionner un système de fichiers NTFS ou des espaces de noms fortement protégés par des ACL. Incluez les répertoires, les inodes ACL, les flux nommés et autres objets publics dans vos projections. Lorsque les ACL sont omniprésentes, utilisez jusqu'à deux fois le nombre projeté de fichiers et de répertoires comme estimation initiale prudente pour files, puis validez avec des données représentatives, car le partage d'ACL peut réduire l'utilisation réelle.

Voir "Types d'inodes ONTAP" et "Maxdir-size et grands répertoires ONTAP".

Il existe trois configurations d'espace de noms courantes.

Dans la mesure du possible, évitez de placer des millions de noms dans un seul niveau de répertoire plat si l'application peut utiliser une hiérarchie large ou profonde. Les structures plates concentrent la mémoire et le travail du processeur et peuvent augmenter la latence lors des opérations massives GETATTR, READDIR de recherche et de suppression. Dans un volume FlexGroup, un grand répertoire plat peut également générer davantage d'entrées distantes, ce qui fait que son fichier de répertoire approche maxdir-size plus rapidement que le même nombre de noms visibles dans un FlexVol.

Les volumes FlexGroup fonctionnent généralement mieux avec de nombreux petits répertoires plutôt qu’avec un seul grand répertoire plat. Les répertoires de moins de 2 Mio environ restent sur le chemin d’analyse simple. À partir de ONTAP 9.2, les répertoires plus volumineux sont indexés automatiquement, ce qui facilite les recherches ciblées. L’indexation ne rend pas un très grand répertoire équivalent à une hiérarchie partitionnée : l’énumération, les analyses avec caractères génériques et la sérialisation de la création dans un seul répertoire restent applicables. ONTAP peut placer à distance les répertoires enfants FlexGroup tout en privilégiant la localité des fichiers par rapport au répertoire parent, ce qui réduit la latence à distance pour ces fichiers.

Répartir les fichiers dans une hiérarchie implique d'utiliser davantage de répertoires avec moins de fichiers dans chacun d'eux.

Les clés de partitionnement courantes incluent :

Choisissez un nombre suffisant de partitions pour que les opérations sur les répertoires restent gérables, mais évitez de créer trop de répertoires presque vides, au risque de rendre leur nombre excessif. Un schéma déterministe garantit un placement prévisible et permet aux clients de localiser les fichiers sans avoir à analyser chaque partition.

Les configurations larges et profondes peuvent toutes deux fonctionner. Veillez à ce que la longueur totale des chemins d'accès reste dans les limites du protocole NAS, du système d'exploitation client et de l'application. Si une configuration plate est inévitable, surveillez la taille actuelle du plus grand fichier de répertoire et la marge disponible comme décrit dans `maxdir-size`"Afficher la taille maximale du répertoire et la taille du répertoire actuel", et déterminez si une augmentation contrôlée est appropriée.

Ne prévoyez pas un fonctionnement stable à 100 % des inodes utilisés ou du plus grand fichier de répertoire. Prévoyez une marge pour la croissance imprévue, les objets temporaires, les métadonnées conservées par les snapshots, les listes de contrôle d'accès et les flux, le chevauchement des migrations, les opérations de sauvegarde, les déséquilibres de placement de FlexGroup et les modifications logicielles qui altèrent les noms de fichiers.

Le paramétrage files à la valeur maximale actuelle constitue un plafond, et non une autorisation de fonctionnement jusqu'à épuisement du dernier inode. Déclenchez une alerte files-used bien avant d'atteindre ce plafond. Par maxdir-size exemple, la recommandation d'augmentation d'environ 2 % dans "Que se passe-t-il lorsque la taille maximale du répertoire est dépassée ?" indique comment relever le plafond, et non une marge opérationnelle universelle.

Budgétisez séparément les fichiers inode, les fichiers de répertoire, l’index, les Snapshot et les métadonnées de l’agrégat. Utilisez 288 octets par inode public alloué comme estimation de base du fichier inode ; voir "Impact sur la capacité". L’augmentation de `files`n’alloue pas cet espace immédiatement. Traitez la capacité maximale allouée au fichier inode comme persistante.

Utilisez volume show-space pour inspecter la capacité des inodes et des métadonnées plutôt que de convertir chaque compteur CLI comme s'il s'agissait d'une valeur en octets.

Testez au moins :

La longueur du chemin et celle du nom de base ne sont pas interchangeables. Un long chemin réparti sur plusieurs répertoires affecte les limites du protocole et le nombre d'inodes, tandis que chaque répertoire ne stocke que son composant immédiat.

Les tests de bande passante séquentiels ne permettent pas de prédire le comportement en cas de grand nombre de fichiers. Inclure :

Mesurez les distributions de latence, le comportement du processeur et du cache, la charge réseau et le temps d’exécution. Répétez les tests pendant les opérations de Snapshot, de réplication, d’analyse, de sauvegarde et d’analyse de sécurité si ces opérations coexistent en production.

Testez au-delà de l’ingestion initiale :

Il peut être nécessaire de créer ou de transférer les index de répertoire à la destination. N'activez le transfert d'index public que si le fait d'éviter les reconstructions améliore sensiblement la récupération ; cela n'améliore pas la recherche locale. Voir "Quand activer les transferts d'index de répertoires publics".

Effectuer le suivi files-used par rapport à files et inodefile-public-capacity comme décrit dans "Surveillez maxfiles, les événements EMS et les améliorations de ONTAP". Alerter avant que files-used n’atteigne files. Pour les volumes FlexGroup, examiner les événements au niveau des constituants même lorsque le total global semble avoir de la marge.

Mesurez la taille des fichiers de répertoire et résolvez les ID de fichiers EMS comme décrit dans "Afficher la taille maximale du répertoire et la taille du répertoire actuel". Inventoriez les répertoires connus pour être plats ou à forte rotation avant qu'ils ne génèrent des avertissements.

Pour les avertissements relatifs aux inodes :

Pour les avertissements concernant la taille des répertoires :

N’attendez pas callhome.no.inodes ou wafl.dir.size.max ; à ce stade, les créations du client échouent déjà.

La suppression de fichiers libère des inodes publics pour leur réutilisation, mais ne réduit pas la taille du fichier d'inodes publics. De même, la suppression de noms dans un répertoire permet la réutilisation des emplacements de répertoire, mais ne réduit généralement pas la taille maximale du fichier de répertoire.

Les suppressions importantes peuvent être gourmandes en métadonnées et augmenter temporairement le nombre d'inodes zombies privés. Limitez le débit des suppressions récursives côté client (rm -rf lorsqu'elles entrent en concurrence avec le trafic de production.

À partir de ONTAP 9.8, `volume file async-delete`supprime un répertoire depuis le cluster plutôt que via NFS ou SMB, ce qui évite les conflits entre les clients et le réseau. Cela s'applique aux volumes FlexVol et FlexGroup. ONTAP analyse le chemin, supprime d'abord le contenu des sous-répertoires, puis exécute des tâches de suppression en parallèle (5 000 tâches simultanées par défaut ; configurable de 50 à 100 000). Lors des tests TR-4571, cela s'est avéré environ 10 fois plus rapide qu'une suppression monothread `rm -rf`sur une arborescence de 24 000 entrées.

Contraintes : le volume doit être en ligne et monté, le chemin doit être un répertoire (et non un fichier unique), et une seule tâche de suppression asynchrone peut s'exécuter à la fois.

Si un répertoire volumineux et clairsemé pose toujours problème, copiez les entrées restantes dans un nouveau répertoire. Le fait de le réduire maxdir-size ne le compacte pas. Voir "Répertoires clairsemés et perforation de trous".

Les opérations impliquant un grand nombre de fichiers consomment du processeur, de la mémoire, du cache et des E/S de stockage, même lorsque le débit de données est faible. Prévoyez une marge de sécurité pour :

Équilibrez les charges de travail en fonction de la demande de métadonnées observée, et non uniquement de la capacité ou du débit. Un nœud peut être limité par les métadonnées alors que la bande passante réseau et disque semble disponible.

Les NAS à grand nombre de fichiers sont souvent limités par les métadonnées. Un montage NFS ou SMB utilise généralement une connexion TCP vers une LIF de données, et cette LIF réside sur un nœud. Si de nombreux clients, scanners ou tâches de sauvegarde montent la même adresse, ce nœud consomme des ressources CPU pour le traitement du protocole, même lorsque le reste du cluster est inactif. Un FlexGroup peut rediriger les opérations sur les fichiers via le réseau du cluster, mais cela ne supprime pas la charge sur le nœud propriétaire de la connexion client.

Un seul client prenant en charge NFS nconnect ou SMB multicanal peut ouvrir des connexions supplémentaires sur un même point de montage. Cela aide ce client ; cela ne remplace pas la répartition de plusieurs clients entre les LIF et les nœuds.

Les versions ultérieures d'ONTAP incluent l'indexation des répertoires, des améliorations de la gestion des inodes, des optimisations pour les répertoires clairsemés, le transfert d'index de répertoire et d'autres améliorations pour les systèmes comportant un grand nombre de fichiers. Les décisions de mise à niveau doivent toujours tenir compte de la prise en charge de la plateforme, de la compatibilité de la protection des données et de la qualification des applications.

N’activez pas une fonctionnalité uniquement parce qu’elle est liée à un nombre élevé de fichiers :

À partir d'ONTAP 9.17.1, File System Analytics peut être activé par défaut sur les nouveaux volumes d'une SVM NAS nouvellement créée. Vérifiez -analytics-state plutôt que de supposer qu'il est désactivé, et tenez compte de son analyse de l'espace de noms lors de la qualification d'une charge de travail comportant un grand nombre de fichiers.

Enregistrement :

Revoyez le modèle lorsque les versions de l’application, les formats de nom de fichier, la durée de conservation, les protocoles ou les flux de travail de protection des données changent.