Eu tenho o desejo de passar o tráfego iSCSI entre meu sistema de laboratório do Windows 2K8 Server e meu arquivador NetApp através de duas pilhas de rede separadas *.
Minha configuração é a seguinte:
- um servidor Win2K8 com o iniciador de software iSCSI instalado, o componente MPIO instalado e duas interfaces de rede: 192.168.201.85/24 e 192.168.202.85/24
- um arquivador NetApp com um LUN publicado no IQN do servidor Windows e duas interfaces: 192.168.201.200/24 e 192.168.202.200/24
- dois comutadores separados, um para 192.168.201.0/24 e outro para 192.168.202.0/24. Ambos são planos (não-VLAN) e não estão conectados a nenhum outro equipamento de rede - incluindo o outro.
Eu configurei o componente MPIO para registrar a classe "adaptadora" do iniciador de software iSCSI.
Depois, entrei no painel de controle do iniciador iSCSI e adicionei os endereços dos arquivadores como "destinos" e executei a descoberta contra eles. Isso mostra o único LUN disponível.
Eu "conectei-me" ao LUN duas vezes, selecionando um endereço IP de "origem" diferente para cada conexão. Ambas as conexões têm "re-connect at boot" marcado e "MPIO" verificado.
Quando examino o destino, vejo duas conexões para o destino, uma para cada endereço IP que a NetApp está usando.
Quando examino minhas conexões persistentes, vejo duas conexões, uma para cada endereço IP que a NetApp está usando.
(Eu deveria mencionar neste momento que eu testei ambos os IPs do arquivador, demonstrando uma conexão única para cada IP, montando e usando uma unidade através desse IP.)
Eu entro no meu Disk Mangler, configuro a partição no LUN e marquei on-line. O disco funciona como esperado.
Agora vou para as propriedades do novo disco e clico na guia MPIO. Eu posso ver duas conexões em uso para este disco. No entanto, eu não sei como associar a conexão que vejo nesta guia com a conexão que vejo nas telas do iniciador iSCSI - então, embora eu presuma que exista uma conexão para cada conexão na tela do iniciador iSCSI, não posso prová-la .
Na guia MPIO, tenho várias opções.
Reduzi os timers para 1 segundo cada e ativei a Verificação de caminho. Então, meu entendimento dessas configurações significa:
- a cada segundo, o servidor Windows verificará se o caminho é válido, ou seja, se o IP do destino remoto está respondendo corretamente;
- o servidor tentará novamente apenas uma vez após a detecção de uma falha, um segundo após a falha ser detectada;
- o servidor marcará como inválido e removerá o caminho um segundo depois de uma falha.
Em relação à redundância, há algumas coisas que tentei:
- Se eu configurar ambas as conexões como Ativo / Ativo e selecionar o uso do Round Robin, o disco funcionará. Se eu configurar uma operação de cópia no disco e simular uma falha de rede, removendo um dos cabos de rede, a conexão será interrompida por ~ 30 segundos e depois continuará.
- Se eu configurar a conexão como um Failover apenas marcando uma conexão como Em espera / Passivo e selecionando Apenas failover, novamente a conexão funcionará. (Curiosamente, cópias de disco para disco parecem fluir consistentemente a cerca de duas vezes a velocidade do Round Robin, mas de qualquer forma.) Se eu simular uma falha puxando o cabo de espera para fora, a conexão para por cerca de 1 segundo e então continua . Se eu simular uma falha puxando o cabo Ativo para fora, a conexão é interrompida - e não consigo fazer o ping do filer em nenhum dos fios. Eventualmente, o sistema operacional informa que o disco falhou. A rede permanece nesse estado por várias horas (depois disso, cansei de esperar e reiniciei o servidor).
Fiz algumas pesquisas e encontrei um Microsoft KB 968287 que fala sobre o failover não ser concluído devido a um erro de contador no driver MPIO.sys no Win2K8 e no Vista, mas a instalação desse hotfix não alterou nada que eu possa ver.
Tudo isso me faz suspeitar que estou perdendo algo fundamental. Estou fazendo isso errado?
O objetivo real é fornecer um transporte iSCSI mais confiável sobre o qual executar VMs e montar armazenamentos do Exchange no meu cluster do Hyper-V. Sabemos que o Exchange, em particular, desmontará os armazenamentos de informações muito rapidamente, se um hiccup de disco for detectado, por isso esperávamos que o MPIO permitisse que os dados fluam mesmo se um caminho falhasse.
* = Atualmente, temos um único switch iSCSI, mas quando isso começou a se comportar mal, tivemos que derrubar todo o nosso mundo para fazer o firmware piscar em um único switch. Portanto, queremos dois caminhos de rede totalmente isolados - NICs, switches e interfaces do outro lado - para que possamos tirar metade deles de serviço em um determinado momento para manutenção sem matar o mundo.