Definindo permissões recursivas: como aumentar o desempenho?

1

Temos uma enorme árvore de diretórios, com muitos níveis de profundidade e com um número (muito) grande de arquivos pequenos em cada nível.

Ocasionalmente, temos grandes alterações de dados de arquivos em que partes da árvore são substituídas e as permissões para essas partes precisarão ser redefinidas. Não é possível prever quais partes serão alteradas na próxima vez.

Os arquivos atualmente residem em uma partição Windows NTFS.

A redefinição de permissões precisa ser feita recursivamente a partir da raiz. Isso leva a melhor parte de um dia de trabalho, em que a necessidade real é quase instantânea (ou a empresa sofre).

Eu tentei GUI. Eu tentei robocopy. Eu tentei o powershell. Eu tentei uma biblioteca Go (Wrapper para a API do Windows), como Go tem uma reputação de ser rápido, mas acabou pouco foi adquirido.

Eu tenho pensado em deixar os aplicativos trabalharem através de links simbólicos, onde os links simbólicos têm permissões restritivas e os dados têm permissões (muito) permissivas. Mas o problema da raiz permaneceria: após uma substituição de dados, ainda precisaríamos vasculhar a árvore e definir essas permissões permissivas.

Definir acl do grupo: s não é uma solução, já usamos isso. Os dados de substituição têm um conjunto diferente de permissões e precisam ser substituídos.

O Windows não é um requisito, também executamos o Linux. Se outras plataformas do sistema operacional pudessem resolver a tarefa de configurar permissões massivas de arquivos e tornar os arquivos acessíveis através de protocolos comuns de compartilhamento de arquivos (http, smb et c), tal sistema operacional poderia ser considerado.

Portanto, minha pergunta é: Usando o Windows NTFS como uma linha de base, existem combinações de sistema de arquivos / sistema operacional que fornecem operações de sistema de arquivos recursivas significativamente mais rápidas (definindo permissões), enquanto ainda servindo os arquivos através de um protocolo comum?

Sugestões de procedimentos também são bem-vindas - eu e meus colegas acabamos de perder alguma solução obviamente mais simples do que substituir o sistema de arquivos ou SO?

EDIT com base em comentários construtivos: sim, nós temos um time de desenvolvimento interno e podemos potencializar qualquer coisa entre hacks de sysadmin (eu) para código bem projetado (devs).

EDIT2 Respondendo a perguntas do @GregAskew (aproximações como no feriado até segunda-feira)

  1. Quantas ACEs estão no ACL?

    • Aproximadamente 8 ACEs por ACL.
  2. O sistema de arquivos é otimizado para desempenho (nomes de arquivos curtos desativados, último tempo de acesso desativado)?

    • Não, eu não estava ciente dessas otimizações e vou testá-las.
  3. Qual é o número máximo de arquivos em um diretório >

    • Terá que medir.
  4. Qual é o estado da fragmentação do sistema de arquivos e da fragmentação do índice de diretório antes de definir a ACL?

    • Desconhecido, investigará.
  5. Qual é o tamanho da unidade de alocação do volume? Qual versão do sistema operacional hospeda o volume?

    • Atualmente, um VMware vSAN que hospeda um Windowws 2008 R2 Std, atualiza iminente para o Win2016 Std.
  6. Você está definindo as permissões localmente (com base em outro comentário, parece que você está fazendo isso pela rede)?

    • Estamos definindo as permissões localmente na VM, mas depois permitimos que elas sejam replicadas para redundância (excruciantes e isso será reprojetado). Temos controle total sobre o design, é apenas a implementação da entrega de arquivos inicial que está fora de nosso controle (mas com base em um comentário, podemos tentar mudar isso). A questão é apenas sobre mudar as permissões de arquivos locais (percebo que a SAN subjacente está conectada à rede, mas de bom grado levará sugestões construtivas nesse sentido).
por ErikE 31.10.2018 / 12:47

3 respostas

2

O processo padrão (desde os anos 1990, pelo menos) para evitar alterações recursivas freqüentes no ACL é usar "grupos de acesso" para atribuir permissões.

Assim, os usuários são colocados em grupos de funções e grupos de funções são colocados em grupos de acesso. As permissões são realmente concedidas usando o grupo de acesso e nunca concedido diretamente a usuários ou grupos de funções.

No seu caso, você desejaria um "grupo de acesso" para cada nível de sua estrutura de pastas até o limite necessário para permissões exclusivas.

Quando novos dados chegam, você cria os grupos “AccessReadFolderX” e “AccessWriteFolderX” e, em seguida, define permissões em uma nova pasta (bloqueando a herança de seus pais). Você copia os novos dados para esta pasta.

Com esse método, você nunca altera as ACLs no sistema de arquivos. Em vez disso, você apenas modifica o aninhamento de grupos e usuários no AD.

    
por 01.11.2018 / 13:18
1

TL; DR answer: use discos mais rápidos.

Sério, essa é a resposta simples. Se você quiser ter "uma árvore de diretórios enorme, com vários níveis de profundidade e um número (muito) grande de arquivos pequenos em cada nível", para redefinir permissões em qualquer parte da árvore de diretórios, é necessário executar operações de E / S em cada arquivo. Isso leva tempo, e se você estiver usando algo como discos SATA S-L-O-W 5400-rpm para armazenamento, isso leva ainda mais tempo. Discos lentos como esse são limitados a cerca de 40-50 operações IO por segundo, e não há nada que você possa fazer para melhorar isso. Se você precisar atualizar milhões de arquivos em cerca de 15 a 20 arquivos por segundo por disco, isso levará tempo. O sistema de arquivos realmente não importa muito quando esse é o trabalho que você tem que fazer.

Boas unidades SATA de 7.200 RPM RPM podem obter cerca de 70 operações IO por segundo, e unidades SAS realmente boas e rápidas podem obter 200-300 operações IO por segundo. SSDs podem fazer milhares.

E como os metadados do arquivo tendem a ser espalhados pelo disco em praticamente todos os sistemas de arquivos, não há muito que um sistema de arquivos possa fazer para melhorar o desempenho, a menos que você entre em sistemas de arquivos complexos e caros como o IBM GPFS ou o Oracle QFS. eles estão chamando eles agora. Ibrix da HP também pode funcionar para você, se ainda estiver vendendo. Mas esses sistemas de arquivos são caros e exigem experiência significativa para administrar.

Você pode tentar limitar as operações de E / S feitas pelo NTFS definindo HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate a 1 do padrão 0 . Isso, pelo menos, desativará as atualizações de tempo de acesso quando você estiver vasculhando as permissões de atualização da árvore de diretórios. Pode ajudar um pouco.

A melhor resposta é projetar um sistema que não exija grandes alterações em um armazenamento massivo de dados. Porque esse é um projeto realmente muito ruim quando "o requisito real é uma mudança quase instantânea (ou o negócio sofre)".

    
por 01.11.2018 / 11:07
1

Supondo que todos os arquivos precisam da mesma permissão de uma determinada raiz, pode ser útil escrever um "acl setter" em c ++ ou c #. Ele deve verificar primeiro a permissão se ela já estiver correta antes de escrevê-la e trabalhar com encadeamentos assíncronos.

    
por 01.11.2018 / 20:46