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 de tamanho. No entanto, não conheço muitos administradores de sistemas que estejam dispostos a permitir que um único volume cresça em vários terabytes. Eu sei que a principal razão por trás disso é quanto tempo levaria para reconstruir o array caso uma unidade falhasse. Quanto mais unidades houver em um único LUN, mais tempo levará e maior será o risco de perder outra unidade durante a reconstrução.
Depois, há motivos de uso. Os administradores criarão um LUN com base na quantidade de espaço que eles acham que precisa ser alocado para o projeto. Parece-me mais prático que o LUN seja um grande array e use cotas. Entendo que isso não satisfaria todos os requisitos (iSCSI), mas vejo muitos sistemas NAS (NFS) gerenciados dessa maneira. Também entendo que os volumes subjacentes podem ser aumentados/diminuídos conforme necessário com bastante facilidade, mas não seria menos "arriscado" usar cotas em vez de manipular volumes e trazer possível perda de dados para a equação?
Pode haver outros motivos pelos quais estou ausente, 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 fique mais rápido para reduzir o tempo de reconstrução?
Responder1
A separação do fuso é uma boa razão para não ter um grande volume. Se você estiver executando Exchange, SQL Server e outras coisas aleatórias (talvez convidados ESXi) em um único dispositivo NFS, certamente desejará a separação do eixo. Os dados e os longos do Exchange devem estar em eixos separados uns dos outros, bem como bancos de dados SQL e logs.
Responder2
Reconstruir uma unidade não depende do sistema de arquivos, mas da própria unidade. Se você usou unidades de 2 TB, precisará de muito tempo para reconstruí-las.
A reconstrução é um problema do raid 5. Para isso agora os controladores podem suportar o raid 6 ou muito melhor você poderia fazer um raid 10 (se quiser o melhor desempenho). Exportar um lun é um trabalho para uma SAN, exportar um sistema de arquivos é um trabalho para NAS.
Ambos têm seus prós e contras (pesquise no Google, há muitos artigos sobre isso). Criar muitos luns independentes (ou sistemas de arquivos) tem a vantagem de fazer backups de instantâneos.
Responder3
Pessoalmente, eu não executaria tráfego corporativo verdadeiro (Oracle, MSSQL, Production ESX) por meio de iSCSI ou NFS - conheço e confio no FC, tanto para desempenho geral quanto durante situações de falha. Claro, isso significa que não posso simplesmente criar LUNs massivos e subdividir, e isso cria um pouco de complexidade/trabalho, mas a disponibilidade do nosso sistema e os números da experiência do usuário final têm sido melhores e mais consistentes do que esperávamos.
Quanto à sua resposta real - bem, suas postagens parecem muito orientadas para NetApp/arquivador, daí meu último parágrafo - mas você mesmo expôs os motivos. As interfaces de disco ficaram significativamente aquém 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 uma 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 facilitar a vida do administrador seria, de fato, um método de curta duração. Também puramente do ponto de vista da segurança da plataforma, você pode querer particionar seus sistemas e a abordagem 'grande LUN' pode não funcionar nesse cenário (com base no hardware, é claro).
Em última análise, as SANs corporativas são inerentemente críticas para os negócios ou para a missão, exigindo disponibilidade e consistência em relação ao custo, facilidade de administração ou até mesmo desempenho máximo.