LAG estático padrão do vSwitch com iniciadores de hardware iSCSI - configuração impossível?

Question

Em um site, temos hosts do vSphere com 2 NICs 10G.

• Ambas as NICs estão em um vSwitch
• Hash IP da política de failover para LAG estático (isso é para equilibrar / tráfego de VM de failover)
• As duas NICs (HPE 534FLR-SFP + / QLogic 57810) possuem iniciadores iSCSI de hardware habilitados
• Cada iniciador é ligado a uma porta vmkernel, um a um.
• Uma sub-rede iSCSI
• Os dois HBAs podem acessar todos os destinos da SAN na pilha de switches

Os switches são da série Cisco C3850 e o MPIO funciona como um encanto - testado (failover no nível do caminho, etc.).

Implementamos configurações semelhantes em outro site há alguns dias. Mesma configuração do vSphere, as mesmas NICs. No entanto, desta vez, esta configuração não funciona corretamente.

Os iniciadores só podem acessar os Destinos nas portas do mesmo comutador (ao qual o iniciador está conectado), mas não nas portas do outro comutador.

Com o tcpdump eu posso ver que portas vmkernel fazem descoberta para todos os alvos (feitas pelo vSphere de acordo com a documentação), alvos de descoberta estáticos aparecem (a SAN vê que ele foi picado), mas caminhos nunca são criados e esxcli mostra erro 0x0004 (erro de transporte?) para alvos em outro switch. Isso é muito difícil de investigar, assim como não podemos ver diretamente o tráfego de HBA. O software iSCSI funciona como um charme (ligado às mesmas portas vmkernel).

Os switches são Cisco Nexus desta vez (atualizarei o modelo quando souber) e o empilhamento é VCP (?) em vez de C3850 nativo (?). Caso contrário, os sites são praticamente os mesmos, mas as diferenças IMHO são tão pequenas que não fazem diferença. Apenas para apontar alguns:

• HPE Proliant Gen9 vs Gen10
• vSphere 6.5 vs 6.7 - como nosso backup agora suporta 6.7, atualizaremos o site antigo em breve.

Eu pesquisei a documentação da VMware e não encontrei nada que diga que a rede convergente não deveria funcionar. Consultamos nosso parceiro de rede, mas eles não entenderam como isso funcionava e achavam que não deveria funcionar.

Esta configuração é normal ou estamos dependendo de alguma peculiaridade de implementação do C3850 que não funciona em outros switches? Ou há algo obviamente errado com interruptores?

    

Answer 1

Para responder a minha própria pergunta… O GAL não é recomendado / suportado ("não deve", "contra-indicado" - texto fraco) com ligação de porta:

1. link

LACP support is not compatible with software iSCSI multipathing. iSCSI multipathing should not be used with normal static etherchannels or with LACP bonds.

2. link

Software iSCSI Port Binding is also contraindicated when LACP or other link aggregation is used on the ESXi host uplinks to the pSwitch

Aparentemente, o Catalyst 3850 Stackwise funciona de forma muito diferente (funciona…) do Nexus Virtual Port Channel. O tráfego nunca atravessa o canal entre comutadores sob condições normais, portanto, o iSCSI de hardware nunca obtém seus pacotes de volta das portas SAN de outros comutadores. A solução é voltar para o balanceamento baseado em ID da porta no vSwitch e desabilitar o LAG. O balanceamento de tráfego não é tão importante com 10G (o hash de IP ajudou com links 1G facilmente sobrecarregados).

Existem algumas reclamações fracas do Google que a VCP exige que o LACP funcione corretamente. Nós tivemos algumas perdas de pacotes no Switch - > A conexão do vSphere desapareceu quando desabilitamos o LAG e voltamos ao balanceamento do ID da porta. Eu estava ciente de que o vSwitch elimina o tráfego proveniente do uplink incorreto (se a VM estiver com hash no vmnic0, mas o tráfego voltar do vmnic1, ele é descartado), mas não tenho certeza se isso se aplica ao balanceamento de hash do IP. Por outro lado, a documentação afirma que apenas o IP-SRC-DST é suportado no lado do comutador. Se o VPC enviasse tráfego para o vSphere em vez da interface local do switch em vez da interface baseada em hash IP correta, ele poderia ser considerado uplink e drop "incorreto". Novamente, desabilitar o LAG funcionou bem.