Compartilhamentos de rede acima de 4 TB

Question

Temos nossos arquivos de projeto armazenados em um Windows 2008R2. Agora, o espaço nessa unidade de 4 TB está se enchendo rapidamente e logo seremos forçados a expandir a unidade ou remover arquivos antigos da unidade. A questão é (alguém em nossa equipe de TI alegou isso) haverá problemas com alguns aplicativos se expandirmos o compartilhamento para mais de 4 TB. Nossa organização usa alguns aplicativos antigos que dizem ter problemas, mas ninguém pode dizer com certeza se haverá problemas ou não.

Então, superar o limite de 4 TB causa problemas com aplicativos mais antigos em unidades compartilhadas? 4 TB tem sido um problema em unidades locais em computadores mais antigos, mas será um problema na unidade compartilhada em aplicativos cliente?

Informações técnicas: O servidor é um servidor virtual VMware ESXi 5.1. A unidade de 4 TB é uma unidade iSCSI direta (não via VMware) da Dell Equallogic.

    

Answer 1

A única preocupação que tenho é que o 4TB é, na minha experiência, um grande volume de NTFS. O CHKDSK ficou muito melhor nos últimos lançamentos do Windows, mas você provavelmente ainda terá uma interrupção de várias horas se pegar uma corrupção do sistema de arquivos em um volume tão grande. (Menos arquivos grandes fariam uma execução mais rápida do CHKDSK em comparação com arquivos pequenos com mais números.)

Se essa interrupção for aceitável, acho que você está bem para aumentar o volume. O Windows pode definitivamente lidar com isso.

Você pode considerar a realocação de arquivos críticos para os quais você pode querer manter mais disponibilidade para outro volume NTFS menor e usar um ponto de montagem ou DFS-N para "colá-lo" no volume maior.

Tendo visto várias execuções do CHKDSK, estou um pouco reticente em usar volumes NTFS que são tão grandes em produção. No mínimo, tento usá-los para dados de "arquivamento" que podem tolerar alguma perda de disponibilidade.

Edit: Eu não me importo muito com os aplicativos. O Kit de Ferramentas de Compatibilidade de Aplicativos (ACT) da Microsoft muita funcionalidade para "coagir" aplicativos indesejáveis em funcionamento. Como exemplo, a correção EmulateGetDiskFreeSpace pode fazer com que o Windows fabrique uma número de espaço livre que permite aplicativos herdados que possuem overlows de inteiros com > 2 GB de espaço livre em disco para trabalhar.

Eu tive um lote de sucesso para conseguir aplicativos exigentes para trabalhar usando o ACT.

    

Answer 2

Eles podem ser problemas. A questão é quão baixo o seu aplicativo será colocado ao acessar o sistema de arquivos. Normalmente, eles não devem ser problema se o Windows puder lidar com isso, pois seus aplicativos devem usar a API do Windows para acessar o sistema de arquivos em um nível inferior.

Claro que é melhor prevenir do que remediar, por isso teste antes de passar para a produção.

    

Answer 3

Eu ficaria mais preocupado com o mapeamento iSCSI direto de armazenamento (versus algo que está no cluster do vSphere e tem essas proteções) .

Você pode aumentar o tamanho da LUN na Dell, portanto, obviamente, há mais recursos de armazenamento disponíveis para você. Mas neste momento, faria mais sentido criar um novo LUN e mover arquivos para ele? Se essa é uma opção e seus aplicativos não exigem uma única partição contígua, é o que eu faria. Isso é mais uma sugestão de gerenciamento e não uma limitação técnica. Este já é um disco GPT e a barreira mágica era de 2,2 TB no tamanho da partição.

    

Answer 4

Pessoalmente, não gosto de volumes enormes de NTFS devido a problemas de chkdsk. Veja a resposta de Evan Anderson sobre isso.
Também tenha em mente que o chkdsk não só vai demorar anos se entrar em vigor, mas também pode precisar de mais memória RAM do que a VM tem disponível. A regra geral é de aproximadamente 1 GB de RAM para cada 1 TB de espaço em disco, para estar no lado seguro. (Especialmente em volumes com muitos arquivos pequenos.)

A grande preocupação com os aplicativos legados é que eles confundem as verificações de espaço livre em disco.
Apenas ler / gravar arquivos geralmente é OK, porque isso passa pelas chamadas de sistema do Windows e o próprio aplicativo não cria nada maior do que ele pode (esperançosamente ...).
Mas se ele perguntar ao Windows "quanto espaço livre em disco existe?" (prática comum antes de escrever um novo arquivo) ele pode obter uma resposta para a qual ele não está preparado.
Por exemplo. Os antigos programas Borland C / C ++, Pascal, Object-Pascal e Delphi são um pouco conhecidos por isso. As bibliotecas de tempo de execução da Borland compartilhadas por esses programas são um pouco esquisitas a esse respeito. E ainda há muitos desses por aí. O Visual Basic 4 também é um caso de problema bem conhecido.

É claro que também pode ser que seus aplicativos herdados nunca desencadeiem esse comportamento. Não há como prever o que acontecerá.

Eu configuraria uma unidade separada extra com menos de 1 TB de tamanho nesta VM. Mova as pastas para o material legado nesta unidade. Então você pode expandir com segurança o disco original sem ter que se preocupar com isso.
Se os aplicativos legados abordarem os dados por meio de compartilhamentos, nem perceberão que agora estão falando com outro disco.
Se o material legado está sendo executado no próprio servidor, depende de um determinado layout de disco e não vai lidar bem com uma mudança de caminho, você sempre pode montar o volume extra no topo da pasta original no disco maior. Um pouco confuso, mas isso funciona.

    

Answer 5

Embora você não deva ter problemas com discos maiores que 4 TB, sempre tem a opção de mover diretórios inteiros para outros discos e criar hardlinks para eles. Isso só funcionará se você tiver diretórios de arquivos e não um arquivo enorme de 4Tb. Se você tiver vários diretórios, poderá mover qualquer um deles para outro disco e ter o espaço nesse outro disco acessível. A ferramenta para isso é mklink.