Coletar ou estimar:

Use valores máximos de uso em vez de médias diárias. Pipelines de compilação, trabalhos de análise, migrações e workflows temporários de scratch geralmente criam seu maior namespace por um curto período e depois o limpam, mas os arquivos de inode e de diretório podem reter marcas máximas de uso após a limpeza.

Mantenha duas previsões separadas:

Não derive um valor do outro. Um namespace fragmentado (arquivos distribuídos por vários diretórios) pode se esgotar maxfiles sem a necessidade de criar um diretório grande. Um único diretório plano pode atingir o maxdir-size limite mesmo que o volume tenha milhões de inodes livres.

Não utilize maxfiles`apenas a contagem de arquivos visíveis como base para o dimensionamento em sistemas NTFS ou namespaces com muitas ACLs. Inclua diretórios, inodes de ACL, fluxos nomeados e outros objetos públicos em suas projeções. Em ambientes com grande presença de ACLs, utilize até o dobro da contagem projetada de arquivos e diretórios como uma estimativa inicial conservadora para `files, depois valide com dados representativos, pois o compartilhamento de ACLs pode reduzir o uso real.

Consulte "Tipos de inode do ONTAP" e "Tamanho máximo de diretório e diretórios grandes do ONTAP".

Existem três layouts de namespace comuns.

Sempre que possível, evite colocar milhões de nomes em um único nível de diretório plano se o aplicativo puder usar uma hierarquia ampla ou profunda. Layouts planos concentram memória e trabalho da CPU e podem aumentar a latência durante operações em massa de inserção GETATTR, READDIR, busca e exclusão. Em um volume FlexGroup, um diretório plano grande também pode produzir mais entradas remotas, fazendo com que seu arquivo de diretório se aproxime maxdir-size mais cedo do que a mesma contagem de nomes visíveis em um FlexVol.

Os volumes FlexGroup geralmente funcionam melhor com muitos diretórios menores do que com um único diretório grande e plano. Diretórios com menos de cerca de 2 MiB permanecem no caminho de varredura simples. A partir do ONTAP 9.2, diretórios maiores são indexados automaticamente, o que ajuda nas pesquisas direcionadas. A indexação não torna um diretório muito grande equivalente a uma hierarquia fragmentada: a enumeração, as varreduras com curinga e a serialização de criação em um único diretório ainda se aplicam. O ONTAP pode colocar remotamente diretórios filhos do FlexGroup, ao mesmo tempo que favorece a localidade dos arquivos em relação ao diretório pai, o que reduz a latência remota desses arquivos.

Distribuir arquivos em uma hierarquia significa usar mais diretórios com menos arquivos em cada diretório.

As chaves de fragmentação comuns incluem:

Escolha shards suficientes para manter as operações de diretório gerenciáveis, mas não crie tantos diretórios quase vazios a ponto de a contagem de diretórios se tornar excessiva. Um esquema determinístico torna o posicionamento previsível e permite que os clientes localizem arquivos sem precisar examinar cada shard.

Layouts amplos e profundos podem funcionar bem. Mantenha os comprimentos completos dos caminhos dentro dos limites do protocolo NAS, do sistema operacional cliente e do aplicativo. Se um layout plano for inevitável, monitore o tamanho atual e `maxdir-size`a margem disponível do maior arquivo de diretório, conforme descrito em "Exibir maxdir-size e o tamanho do diretório atual", e verifique se um aumento controlado é apropriado.

Não planeje a operação em estado estacionário com 100% dos inodes utilizados ou do maior arquivo de diretório. Mantenha uma margem para crescimento inesperado, objetos temporários, metadados retidos por Snapshot, ACLs e fluxos, sobreposição de migração, trabalho de backup, desequilíbrio de posicionamento do FlexGroup e alterações de software que alteram os nomes dos arquivos.

Definir files o máximo atual é um limite, não uma permissão para executar até que o último inode seja consumido. Ative o alerta em files-used muito antes desse limite. Para maxdir-size, a orientação de aumento de aproximadamente 2% em "O que acontece quando o tamanho máximo do diretório é excedido?" é como elevar o limite, não uma margem operacional universal.

Faça o orçamento de arquivo de inode, arquivo de diretório, índice, Snapshot e metadados do agregado separadamente. Use 288 bytes por inode público alocado como a estimativa base do arquivo de inode; veja "Impacto na capacidade". Aumentar files não aloca esse espaço imediatamente. Considere a capacidade máxima alocada do arquivo de inode como persistente.

Use volume show-space para inspecionar a capacidade de inode e metadados, em vez de converter cada contador da CLI como se fosse um valor em bytes.

Teste pelo menos:

O comprimento do caminho e o comprimento do nome base não são intercambiáveis. Um caminho longo distribuído em vários diretórios afeta os limites do protocolo e a contagem de inodes, enquanto cada diretório armazena apenas seu componente imediato.

Testes sequenciais de largura de banda não preveem o comportamento em situações com grande número de arquivos. Inclua:

Meça as distribuições de latência, o uso da CPU, o comportamento do cache, a carga da rede e o tempo de conclusão. Repita os testes durante o Snapshot, a replicação, a análise, o backup e a verificação de segurança, caso essas operações coexistam em produção.

Teste mais do que apenas a ingestão inicial:

Pode ser necessário criar ou transferir índices de diretório no destino. Habilite a transferência de índice público somente quando evitar reconstruções melhorar significativamente a recuperação; isso não melhora a pesquisa local. Consulte "Quando habilitar as transferências de índice de diretório público".

Monitore files-used em relação a files e inodefile-public-capacity conforme descrito em "Monitorar arquivos maxfile, eventos EMS e melhorias do ONTAP". Alerte antes que files-used atinja files. Para os volumes FlexGroup, investigue eventos em nível de constituinte, mesmo quando o total geral parecer ter espaço.

Meça o tamanho do arquivo do diretório e resolva os IDs de arquivo do EMS conforme descrito em "Exibir maxdir-size e o tamanho do diretório atual". Faça o inventário de diretórios conhecidos por serem planos ou com alta rotatividade antes que gerem avisos.

Para avisos de inode:

Para avisos sobre o tamanho do diretório:

Não espere por callhome.no.inodes ou wafl.dir.size.max; nesse ponto, as criações de cliente já estão falhando.

A exclusão de arquivos libera inodes públicos para reutilização, mas não reduz o arquivo de inodes públicos. Da mesma forma, a exclusão de nomes de um diretório torna os slots de diretório reutilizáveis, mas normalmente não reduz o tamanho máximo do arquivo de diretório.

Exclusões de grande porte podem exigir muitos metadados e aumentar temporariamente o número de inodes privados "zumbis". Limite a taxa de exclusões recursivas do lado do cliente (rm -rf quando elas competirem com o tráfego de produção.

A partir do ONTAP 9.8, volume file async-delete o recurso remove um diretório do cluster em vez de usar NFS ou SMB, o que evita contenção de cliente e de rede. Isso se aplica aos volumes FlexVol e FlexGroup. O ONTAP examina o caminho, exclui primeiro o conteúdo dos subdiretórios e executa tarefas de exclusão em paralelo (padrão de 5.000 tarefas simultâneas; configurável de 50 a 100.000). Nos testes do TR-4571, isso foi cerca de 10× mais rápido do que uma operação de exclusão com um único thread rm -rf em uma árvore de 24.000 entradas.

Restrições: o volume deve estar online e montado, o caminho deve ser um diretório (não um único arquivo) e apenas uma tarefa de exclusão assíncrona pode ser executada por vez.

Se um diretório esparso grande continuar sendo um problema, copie as entradas restantes para um novo diretório. Reduzir maxdir-size não o compacta. Veja "Diretórios esparsos e perfuração de furos".

Operações com grande número de arquivos consomem CPU, memória, cache e E/S de armazenamento mesmo quando a taxa de transferência de dados é baixa. Mantenha espaço livre para:

Equilibre as cargas de trabalho usando a demanda de metadados observada, não apenas a capacidade ou a taxa de transferência. Um nó pode ficar limitado por metadados enquanto a largura de banda da rede e do disco parecem disponíveis.

Sistemas NAS com grande quantidade de arquivos geralmente são limitados por metadados. Uma montagem NFS ou SMB normalmente usa uma conexão TCP para uma LIF de dados, e essa LIF reside em um nó. Se muitos clientes, scanners ou tarefas de backup montarem o mesmo endereço, esse nó consumirá CPU no processamento do protocolo mesmo quando o restante do cluster estiver ocioso. Um FlexGroup pode redirecionar as operações de arquivo pela rede do cluster, mas isso não elimina a carga no nó que possui a conexão do cliente.

Um único cliente que oferece suporte a NFS nconnect ou SMB multicanal pode abrir conexões adicionais em um ponto de montagem. Isso ajuda esse cliente; não substitui a distribuição de vários clientes entre LIFs e nós.

As versões posteriores do ONTAP incluem indexação de diretórios, melhorias no gerenciamento de inode, otimizações para diretórios esparsos, transferência de índice de diretório e outros aprimoramentos para grandes contagens de arquivos. As decisões de atualização ainda devem levar em consideração o suporte da plataforma, a compatibilidade com a proteção de dados e a qualificação do aplicativo.

Não habilite um recurso apenas porque ele está relacionado a uma alta contagem de arquivos:

A partir do ONTAP 9.17.1, a Análise do Sistema de Arquivos pode ser ativada por padrão em novos volumes em uma SVM NAS recém-criada. Verifique -analytics-state em vez de presumir que esteja desativada e leve em consideração a verificação do namespace ao qualificar uma carga de trabalho com grande número de arquivos.

Registro:

Reavalie o modelo quando houver alterações nas versões dos aplicativos, formatos de nomes de arquivos, retenção, protocolos ou fluxos de trabalho de proteção de dados.