Na minha rede, tenho vários tipos de arquivos que desejo salvar em uma SAN:
Agora estou pensando se devo criar um iSCSI Target com um grande volume e iniciá-lo em um dos servidores. (e compartilhá-lo para que outros servidores possam usá-lo também)
Ou eu deveria criar Destinos separados para que cada servidor use seu próprio armazenamento.
Para o registro, o armazenamento pode ser separado porque os servidores não estão usando os dados compartilhados. Por um motivo eu estava pensando em um armazenamento é a facilidade de backup. (mas talvez o desempenho possa ser um problema?)
Qual seria uma configuração recomendável para esses tipos de dados?
Você precisará fazer alvos separados. O NTFS não é um sistema de arquivos em cluster, portanto, ter várias caixas gravando no mesmo disco trash seu sistema de arquivos ou, no mínimo, os arquivos em seu sistema de arquivos, pois eles não estarão cientes do que os outros sistemas estão fazendo.
Razões para um único destino
Existe um motivo: sem fragmentação do espaço de armazenamento.
Não há necessidade de planejar a capacidade com antecedência. Como aponta @Zypher, o NTFS não é um sistema de arquivos em cluster, portanto, você terá apenas um iniciador se comunicando com o destino.
Você pode configurar o host do iniciador como um host CIFS para os outros servidores compartilharem o armazenamento. Como muitos mecanismos de banco de dados, como o SQL Server 2005, se recusam a trabalhar em volumes de armazenamento conectados à rede, seu melhor candidato para a função de iniciador é o host de banco de dados. O armazenamento de arquivos e Exchange pode usar o CIFS.
Razões para vários destinos
Se algum servidor único ficar inativo, o restante funcionará como se nada tivesse acontecido.
O CIFS ou o NFS não podem fornecer latência tão boa quanto um armazenamento em bloco.
Muitas matrizes de disco atualmente têm opções como provisionamento thin que facilitam a expansão de vários volumes lógicos em uma única área de armazenamento para que cada volume possa crescer até que haja espaço livre na área de armazenamento sem qualquer interferência em nome do administrador de armazenamento ou do sistema operacional host.
Os arquivos aleatórios provavelmente não são tão críticos quanto o DB ou o Exchange para os negócios e tendem a ser mais difíceis de planejar. Pode ser mais barato tê-los nas camadas de capacidade, embora seja preferível ter arquivos de banco de dados na camada de desempenho, a menos que o banco de dados seja pequeno e funcione da memória.
Mesmo sem provisionamento thin, os volumes lógicos podem ser estendidos para acomodar o crescimento de dados, mas isso exigiria interação em nome do administrador de armazenamento e dos administradores dos servidores.
Conclusão
Se você puder planejar a capacidade antecipadamente ou se o sistema de armazenamento tiver uma opção de provisionamento thin, ou se a classificação por níveis de armazenamento for importante, é aconselhável escolher vários destinos. Se nada disso se aplicar, escolher um único alvo compartilhando-o com o CIFS pode ser uma opção viável.