Uma coisa que sempre me deixou perplexo são as práticas recomendadas de armazenamento. Os sistemas de arquivos se gabam de como podem ter petabytes ou exabytes em tamanho. No entanto, eu não conheço muitos administradores que estão dispostos a deixar um único volume crescer ao longo de vários terrabytes. Eu sei que a principal razão por trás disso é quanto tempo levaria para reconstruir a matriz caso uma unidade falhe. Quanto mais unidades em um único LUN, mais tempo isso leva e maior o risco de perder outro disco enquanto a reconstrução está ocorrendo.
Depois, há motivos de uso. Os administradores irão criar um LUN com base em quanto espaço eles acham que precisa ser alocado para o projeto. Parece-me mais prático que o LUN seja um grande array e use cotas. Eu entendo que isso não satisfaria todos os requisitos (iSCSI), mas vejo muitos sistemas NAS (NFS) gerenciados dessa maneira. Eu também entendo que os volumes subjacentes podem ser crescidos / encolhidos conforme a necessidade facilmente, mas não seria menos "arriscado" usar as cotas do que manipular volumes e trazer a possível perda de dados para a equação?
Pode haver algumas outras razões que me faltam, então, por favor, me esclareça. Não podemos esperar que os sistemas de arquivos sejam tão grandes? Estamos esperando que o hardware seja mais rápido para reduzir os tempos de reconstrução?
A separação do fuso é uma boa razão para não ter um grande volume. Se você estiver executando o Exchange, o SQL Server e outras coisas aleatórias (talvez convidados do ESXi) fora de um único dispositivo NFS, certamente desejará a separação do fuso. Os dados do Exchange e os longos devem estar em fusos separados uns dos outros, bem como em bancos de dados e logs do SQL.
Para reconstruir uma unidade, não depende do sistema de arquivos, mas da própria unidade. Se você usou drives de 2 TB, precisará de muito tempo para reconstruir.
Reconstruir é um problema de raid 5. Por isso, agora os controladores podem suportar raid 6 ou muito melhor, você poderia fazer um raid 10 (se você quer o melhor desempenho).
Exportar um lun é uma tarefa para uma SAN, exportar um sistema de arquivos é uma tarefa do NAS.
Ambos têm seus prós e contras (pesquisa no google, há toneladas de papel sobre).
Fazer muitas linas independentes (ou sistemas de arquivos) tem a vantagem de fazer backups de snapshots.
Pessoalmente, eu não executaria tráfego corporativo verdadeiro (Oracle, MSSQL, Production ESX) sobre iSCSI ou NFS - conheço e confio em FC, tanto para desempenho geral quanto durante situações de falha. Claro que isso significa que não posso simplesmente criar LUNs massivos e subdividir e criar um pouco de complexidade / trabalho, mas a disponibilidade do nosso sistema e os números de experiência do usuário final foram melhores e mais consistentes do que esperávamos.
Quanto à sua resposta real - bem suas postagens parecem muito orientadas para NetApp / filer, daí meu último parágrafo - mas você mesmo expôs as razões. Interfaces de disco caíram significativamente atrás da capacidade do disco - o que significa que os tempos de reconstrução podem ser ridículos, especialmente se você quiser ver um desempenho decente durante a reconstrução do tráfego existente. Os discos morrem o tempo todo e a ideia de afetar o desempenho de múltiplas plataformas durante uma reconstrução para simplesmente tornar a vida mais fácil para o administrador seria, de fato, um método de curta duração. Também puramente a partir de uma perspectiva de segurança de plataforma, você pode querer particionar seus sistemas e a abordagem 'grande LUN' pode não funcionar nesse cenário (baseado em hardware, é claro).
Por fim, as empresas SANs são inerentemente comerciais ou de missão crítica, exigindo disponibilidade e consistência em relação ao custo, facilidade de administração ou até mesmo desempenho final.