Raccogli o stima:

Utilizza i valori massimi di utilizzo anziché le medie giornaliere. Le pipeline di build, i processi di analisi, le migrazioni e i flussi di lavoro temporanei spesso creano il loro namespace più grande per un breve periodo e poi lo eliminano, ma gli inode e i file di directory possono conservare i valori massimi di utilizzo anche dopo l'eliminazione.

Mantieni due previsioni separate:

Non derivare un valore dall'altro. Uno spazio dei nomi frammentato (file suddivisi in molte directory) può esaurirsi `maxfiles`senza creare una directory di grandi dimensioni. Una singola directory piatta può raggiungere il `maxdir-size`limite mentre il volume ha milioni di inode liberi.

Non dimensionare maxfiles`in base al solo numero di file visibili su NTFS o su namespace con molte ACL. Includi directory, inode ACL, stream denominati e altri oggetti pubblici nelle tue proiezioni. Dove le ACL sono molto diffuse, usa fino al doppio del numero previsto di file e directory come stima iniziale prudenziale per `files, quindi convalida con dati rappresentativi, perché la condivisione delle ACL può ridurre l'utilizzo effettivo.

Vedi "Tipi di inode ONTAP" e "Dimensione massima delle directory e directory ONTAP di grandi dimensioni".

Esistono tre layout di namespace comuni.

Quando possibile, evita di posizionare milioni di nomi su un singolo livello di directory piatto se l'applicazione può utilizzare una gerarchia ampia o profonda. I layout piatti concentrano la memoria e il lavoro della CPU e possono aumentare la latenza durante le operazioni di inserimento di massa GETATTR, READDIR ricerca ed eliminazione. In un volume FlexGroup, una directory piatta di grandi dimensioni può anche produrre più voci remote, facendo sì che il relativo file di directory si avvicini prima a maxdir-size rispetto allo stesso numero di nomi visibili in un FlexVol.

I volumi FlexGroup in genere funzionano meglio con molte directory di piccole dimensioni piuttosto che con una grande directory piatta. Le directory di dimensioni inferiori a circa 2 MiB rimangono sul percorso di scansione semplice. A partire da ONTAP 9.2, le directory più grandi vengono indicizzate automaticamente, il che facilita le ricerche mirate. L'indicizzazione non rende una directory molto grande equivalente a una gerarchia partizionata: continuano ad applicarsi l'enumerazione, le scansioni con caratteri jolly e la serializzazione della creazione in una singola directory. ONTAP può posizionare in remoto le directory figlie di FlexGroup, favorendo la località dei file rispetto alla directory padre, il che riduce la latenza remota per tali file.

Distribuire i file in una gerarchia significa usare più directory con meno file in ciascuna directory.

Le chiavi di sharding più comuni includono:

Scegli un numero sufficiente di shard per mantenere gestibili le operazioni sulle directory, ma evita di creare così tante directory quasi vuote da rendere eccessivo il numero stesso di directory. Uno schema deterministico rende il posizionamento prevedibile e consente ai client di individuare i file senza dover scansionare ogni shard.

Sia i layout ampi che quelli profondi possono funzionare. Mantieni la lunghezza dei percorsi completi entro i limiti del protocollo NAS, del sistema operativo client e dell'applicazione. Se un layout piatto è inevitabile, monitora la dimensione corrente e `maxdir-size`lo spazio disponibile del file di directory più grande, come descritto in "Visualizza maxdir-size e la dimensione dell'attuale directory", e verifica se un aumento controllato è appropriato.

Non pianificare un funzionamento a regime con il 100% degli inode utilizzati o del file di directory più grande. Lascia un margine per la crescita imprevista, gli oggetti temporanei, i metadati conservati da Snapshot, gli ACL e i flussi, la sovrapposizione della migrazione, le operazioni di backup, gli squilibri di posizionamento di FlexGroup e le modifiche software che alterano i nomi dei file.

Impostare files al massimo corrente rappresenta un limite massimo, non un'autorizzazione a continuare fino all'esaurimento dell'ultimo inode. Imposta un avviso su files-used molto prima di raggiungere tale limite massimo. Per maxdir-size, l'aumento di circa il 2% indicato in "Cosa succede quando viene superato maxdir-size?"spiega come alzare il limite, non un margine operativo universale.

Calcola separatamente lo spazio per inode-file, directory-file, indice, Snapshot e metadati dell'aggregato. Utilizza 288 byte per ogni inode pubblico allocato come stima di base per inode-file; vedi "Impatto sulla capacità". L'aumento files non alloca immediatamente tale spazio. Considera la capacità di picco allocata per inode-file come persistente.

Usa volume show-space per ispezionare la capacità di inode e metadati anziché convertire ogni contatore CLI come se fosse un valore in byte.

Esegui almeno questi test:

La lunghezza del percorso e la lunghezza del nome base non sono intercambiabili. Un percorso lungo distribuito su più directory influisce sui limiti del protocollo e sul conteggio degli inode, mentre ogni directory memorizza solo il proprio componente immediato.

I test sequenziali della larghezza di banda non prevedono il comportamento in presenza di un elevato numero di file. Includi:

Misura le distribuzioni della latenza, l'utilizzo della CPU, il comportamento della cache, il carico di rete e il tempo di completamento. Ripeti i test durante Snapshot, replica, analisi, backup e scansione di sicurezza, se tali operazioni coesistono in produzione.

Testa più dell'acquisizione iniziale:

Potrebbe essere necessario creare o trasferire gli indici di directory nella destinazione. Abilita il trasferimento dell'indice pubblico solo quando evitare la ricostruzione migliora significativamente il ripristino; non migliora la ricerca locale. Vedi "Quando abilitare i trasferimenti dell'indice della directory pubblica".

Monitora files-used rispetto a files e inodefile-public-capacity come descritto in "Monitora i maxfiles, gli eventi EMS e i miglioramenti di ONTAP". Avvisa prima che files-used raggiunga files. Per i volumi FlexGroup, esamina gli eventi a livello di costituente anche quando il totale complessivo sembra avere ancora spazio.

Misura le dimensioni dei file di directory e risolvi gli ID dei file EMS come descritto in "Visualizza maxdir-size e la dimensione dell'attuale directory". Esegui l'inventario delle directory note per essere piatte o soggette a frequenti modifiche prima che generino avvisi.

Per gli avvisi inode:

Per gli avvisi relativi alle dimensioni della directory:

Non aspettare callhome.no.inodes o wafl.dir.size.max; a quel punto le creazioni del client stanno già fallendo.

L'eliminazione dei file libera gli inode pubblici per il riutilizzo, ma non riduce il file degli inode pubblici. Allo stesso modo, l'eliminazione dei nomi da una directory rende riutilizzabili gli slot della directory, ma normalmente non riduce la dimensione massima del file della directory.

Le eliminazioni di grandi dimensioni possono richiedere un uso intensivo dei metadati e possono aumentare temporaneamente gli inode zombie privati. Limita la frequenza delle eliminazioni ricorsive lato client (rm -rf quando competono con il traffico di produzione.

A partire da ONTAP 9.8, volume file async-delete`rimuove una directory dal cluster anziché tramite NFS o SMB, evitando così conflitti tra client e rete. Si applica ai volumi FlexVol e FlexGroup. ONTAP analizza il percorso, elimina prima il contenuto delle sottodirectory ed esegue attività di eliminazione in parallelo (5.000 attività simultanee per impostazione predefinita; configurabili da 50 a 100.000). Nei test TR-4571, è risultato circa 10× più veloce di un'eliminazione a singolo thread `rm -rf su una struttura ad albero con 24.000 voci.

Vincoli: il volume deve essere online e montato, il percorso deve essere una directory (non un singolo file) e può essere eseguito un solo processo di eliminazione asincrona alla volta.

Se una directory di grandi dimensioni e con pochi elementi continua a essere un problema, copia le voci rimanenti in una nuova directory. Ridurne `maxdir-size`non la compatta. Vedi "Directory sparse e hole punching".

Le operazioni con un elevato numero di file consumano CPU, memoria, cache e I/O di archiviazione anche quando il throughput è basso. Mantieni un margine di sicurezza per:

Bilancia i carichi di lavoro utilizzando la domanda di metadati osservata, non solo la capacità o il throughput. Un nodo può diventare limitato dai metadati mentre la larghezza di banda di rete e del disco sembra disponibile.

I sistemi NAS con un elevato numero di file sono spesso limitati dai metadati. Un mount NFS o SMB utilizza in genere una connessione TCP a un singolo data LIF, e tale LIF risiede su un nodo. Se molti client, scanner o processi di backup montano lo stesso indirizzo, quel nodo impiega CPU per l'elaborazione del protocollo anche quando il resto del cluster è inattivo. Un FlexGroup può reindirizzare le operazioni sui file attraverso la rete del cluster, ma ciò non elimina il carico sul nodo che gestisce la connessione del client.

Un singolo client che supporta NFS nconnect o SMB multicanale può aprire connessioni aggiuntive su un singolo punto di montaggio. Questo aiuta quel client; non sostituisce la distribuzione di più client tra LIF e nodi.

Le versioni successive di ONTAP includono indicizzazione delle directory, miglioramenti alla gestione degli inode, ottimizzazioni per directory sparse, trasferimento degli indici delle directory e altri miglioramenti per un elevato numero di file. Quando decidi di eseguire l'upgrade, devi comunque tenere conto del supporto della piattaforma, della compatibilità con la protezione dei dati e della qualificazione delle applicazioni.

Non abilitare una funzionalità solo perché è correlata a un numero elevato di file:

A partire da ONTAP 9.17.1, l'analisi del file system può essere abilitata per impostazione predefinita sui nuovi volumi in una NAS SVM appena creata. Controlla -analytics-state invece di dare per scontato che sia disabilitata e tieni conto della scansione del relativo namespace quando valuti un carico di lavoro con un numero elevato di file.

Record:

Rivedi il modello quando cambiano le versioni delle applicazioni, i formati dei nomi dei file, i criteri di conservazione, i protocolli o i flussi di lavoro per la protezione dei dati.