Estou fazendo uma experiência com o iSCSI MPIO entre o FreeNAS 9.3 e dois hosts XenServer 6.5. Eu gostaria de usar o iSCSI MPIO para servir como armazenamento de VM. Ambiente bastante comum, mas sem uma opção para reduzir o custo da solução e minimizar a sobrecarga adicionada por um switch na rede iSCSI.
A arquitetura é a seguinte: Existem 10 interfaces GigE no FreeNAS Server, duas placas intel integradas na placa-mãe e duas placas combinadas 4x GigE.
Criei / 30 links entre as placas de combinação e os dois hosts XenServer, da seguinte maneira:
Connection to Host #1:
igb0: 192.168.10.1/30
igb4: 192.168.11.1/30
Connection to Host #2:
igb1: 192.168.20.1/30
igb5: 192.168.21.1/30
Como você pode ver, é bastante explicativo, os hosts XenServer têm os seguintes IPs correspondentes:
192.168.10.2/30
192.168.11.2/30
192.168.20.2/30
192.168.21.2/30
Mas aqui o problema começa. Não consigo iniciar uma conexão iSCSI com um Portal com esses 4 endereços. Ele falha ao procurar pelo LUN, durante a fase do IQN. Se eu esquecer completamente os endereços IP 192.168.20.1,192.168.21.1, eu posso encontrar o LUN, mas o host # 2 estará sem uma rede iSCSI, já que as redes 192.168.10.0/30 e 192.168.11.0/30 estão inacessíveis. Eles são links ponto-a-ponto.
De acordo com a documentação do FreeNAS, posso criar vários portais. O que parece ser uma solução, mas tentei fazer isso sem sucesso. Não consigo mapear o mesmo LUN em diferentes portais, por isso é impossível.
Outra solução seria usar mais de um IP na mesma sub-rede na caixa FreeNAS, mas como todos sabemos, isso é uma falha na rede TCP.
O último esforço é criar o XenServer iSCSI SR sobre o CLI com uma configuração muito específica. Mas eu não fui capaz de tentar isso sozinho.