Estou ciente de que você não pode montar um único LUN em dois volumes iscsi de leitura / gravação NTFS sem grandes problemas, a menos que esteja usando servidores em cluster. No entanto, estou curioso sobre a montagem de 1 iscsi lun leitura / gravação em um servidor (digamos, um servidor de banco de dados) e o mesmo iscsi lun como somente leitura em outro servidor (digamos, servidor de backup) para facilitar backups como uma solução provisória .
Agora, isso é apenas para os arquivos .bak do banco de dados do SQL Server 2008 - o motivo é que estou tendo outros problemas de rede que ainda não podem ser resolvidos (a equipe de rede é diferente da empresa, não tenha acesso para corrigir nosso problema) fazendo com que os backups demorem de 20 a 25 horas. No entanto, como ambos têm conexões com a mesma SAN iscsi, imaginei que isso tornaria as coisas melhores.
Ainda não testei isso no meu sistema de produção, mas não pareci ter problemas para executar um teste semelhante no meu LAB - no entanto, com tamanhos de arquivo muito menores (2 GB comparado a 800 GB), queria ver se alguém teve experiências em fazer isso e se vai funcionar ou não.
Editar: Apenas para referência, os dois servidores são Server 2008 R2 (o SQL Server é Ent, o Backup é Std) conectado a uma SAN iscsi HP P4500 (à esquerda).
Não vejo por que isso não funcionaria. O que eu recomendaria fazer em vez disso seria tirar um instantâneo do LUN de produção e, em seguida, apresentar esse instantâneo ao servidor de backup. Dessa forma, se o LUN de produção mudar, o servidor de backup ainda verá a visualização consistente dos dados. Então, quando o backup for concluído, exclua o instantâneo e, no dia seguinte, inicie o processo.
Eu também enfrentei o mesmo problema. A equipe da SAN publicou o lun único em dois servidores, depois que enfrentamos o problema de corrupção da unidade & até mesmo a conexão da fibra estava flutuando. Depois disso, desmontamos a unidade em um servidor & não publicado que lun daquele servidores. Então ele começou a trabalhar no primeiro servidor depois de executar o comando checkdisk. O comando chkdsk do Eariler não estava sendo concluído quando o mesmo lun foi publicado nos dois servidores.