Configurar rede iSCSI redundante com 2 switches, SAN e ESX

4

Estou no processo de refazer a rede iSCSI no meu trabalho. Atualmente, temos os seguintes equipamentos:

  • 1x comutador Dell PowerConnect 6224
  • 1x SAN Dell PowerVault MD3000 conectado a 2 servidores Dell PowerEdge 1950 fornecendo iSCSI
  • 1x SAN Dell PowerVault MD3000i
  • 2x servidores Dell PowerEdge 2950 executando o ESX 3.5 que em breve será o ESX 4 - tem 6 NICs
  • 2x Dell ??? servidores que acabaram de ser pedidos para mais 2 hosts ESX - tem 8 NICs

Configuração atual:
Todo o tráfego iSCSI está em seu próprio switch e está na rede 192.168.1.x. Todos os outros tráfegos de rede estão em seu próprio switch de rede e estão na rede 10.10.x.x. Temos 2 NICs agrupadas (1 NIC Broadcom onboard e 1 NIC Intel Pro 1000) para cada servidor ESX em estado ativo / ativo, sendo conectado ao único switch PC 6224 dedicado ao iSCSI. Todas as 4 portas NIC na parte traseira do MD3000i também estão conectadas ao mesmo switch.

O problema com essa configuração é que o switch fornece um grande ponto único de falha. Estamos tentando corrigir / corrigir isso com a configuração de uma rede de 2 switches para o tráfego iSCSI para redundância. Eu tenho dois novos switches PowerConnect 6224 que usaremos para essa nova rede. O switch atual que temos para o tráfego iSCSI será então usado para redundância no lado da rede local ou usado como uma rede do vMotion apenas entre 4 servidores ESX. (O vMotion é atualmente uma conexão cruzada entre os 2 servidores ESX

Falei com a Dell em algumas ocasiões tentando descobrir essa nova configuração de rede antes de obter os dois novos servidores ESX que se conectarão ao MD3000i onde nossas máquinas virtuais estão armazenadas. Cheguei à conclusão de que seria melhor:

  • Ativar flowcontrol em switches - não configurados no momento
  • Ativar portfast de spanning tree em switches - não configurados no momento
  • Configure quadros jumbo nos comutadores, NICs e SAN - não configurados no momento
  • Configure um LAG de 2 portas entre os 2 switches

Não tenho certeza se o empilhamento dos dois switches PowerConnect é a melhor ideia. Devido ao fato de que, se o switch master falhasse, a pilha reinicializaria, causando a interrupção da rede, enquanto a pilha re-elegeria um novo master. O que para mim parece que não forneceria a redundância / HA que estamos procurando.

Como o MD3000i tem 4 conexões para o tráfego iSCSI (2 para o controlador 0 e 2 para o controlador 1), conecte o lado 0 ao switch A e depois o 1 lado ao switch B. Depois, faça uma conexão dos nossos servidores ESX para cada comutador para o tráfego iSCSI.

Minha confusão sobre a configuração vem com o modo como o servidor ESX está configurado. Não tenho certeza de como as duas NICs agrupadas devem ser manipuladas. Do meu entendimento, os NICs em equipe precisam estar conectados ao mesmo switch, mas estaríamos conectando-os a dois switches. Será que precisamos quebrar o agrupamento e criar um novo vSwitch para cada conexão para alternar A e B?

Existe uma maneira melhor de configurar essa rede ou a direção para a qual estou tentando ir melhor?

Atualização: Estou no processo de leitura do guia de configuração do iSCSI para o ESX 4. Vou postar de volta / marcar a resposta assim que terminar de ler o documento.

    
por DanielJay 12.02.2010 / 22:07

2 respostas

3

Uma abordagem bem estruturada e você está fazendo todas as perguntas certas. Sua reformulação sugerida é excelente.

O ESX 3.5 não faz realmente vários caminhos de Iniciador de Software iSCSI, mas terá um failover feliz para outro uplink ativo ou de espera no vSwitch se um link falhar por algum motivo. O Guia de configuração de SAN iSCSI VI3.5 tem algumas informações sobre isso, não tanto quanto Eu gostaria, mas está claro o suficiente. Você não deveria ter que fazer nada no lado do ESX quando muda, mas não terá mais nenhum efeito de agregação de link (porque seus uplinks estão indo para dois switches não empilhados separados), somente failover. Dada a fraqueza do multipathing na pilha iSCSI do ESX 3.5, isso provavelmente não terá nenhum efeito material, mas pode ser porque você tem vários destinos iSCSI, portanto, tenha isso em mente. Tenho certeza de que você já sabe disso, mas os Jumbo Frames não são compatíveis com o Iniciador de Software no ESX 3.5, de modo que não farão nada por você até que você mude para o ESX 4.

Ao configurar as portas ESX vSwitch e VMkernel para iSCSI com ESX4, a recomendação é criar várias portas VMkernel com um mapeamento 1: 1 para NICs phyiscais de uplink. Se você quiser criar vários vSwitches para isso, você pode ou pode usar as opções de agrupamento de NICs no nível da porta para que você tenha uma única NIC designada como ativa por porta VMkernel com 1 ou mais como espera. Depois de configurar as portas \ vSwitch, você precisará vincular as portas à pilha de múltiplos caminhos iSCSI e, então, manipulará os caminhos múltiplos e o failover de maneira mais eficiente. Dada a maneira como isso funciona, não há necessidade de se preocupar com o agrupamento entre os switches, o driver multipath está fazendo o trabalho na camada ip. Esta é apenas uma ideia rápida de como funciona, está descrita com muito detalhe no VI iSCSI SAN Guia de configuração . Isso explicará tudo o que você precisa fazer, incluindo como configurar o suporte a quadros Jumbo corretamente.

No que diz respeito ao empilhamento, não acho que você precise ou deseje fazer isso para essa configuração. Na verdade, o design recomendado pela Dell para ambientes iSCSI MD3000i não é empilhar os switches, tanto quanto a razão que você mencionou. Para outras soluções iSCSI (Equallogic), são necessários links de alta largura de banda entre arrays, então o empilhamento é recomendado pela Dell, mas nunca tive uma explicação satisfatória do que acontece quando o mestre falha. Tenho certeza de que a interrupção durante a nova eleição do mestre será menor do que os tempos limite do iSCSI, portanto, as VMs não devem falhar, mas não é algo que me agrada e as coisas definitivamente vão parar por um período de tempo desconfortável.

    
por 13.02.2010 / 00:18
0

o mesmo switch significará ligação do modo 4, você pode optar pelo failover (o ESX deve ser capaz de suportar isso) Qualquer tipo de ligação que forneça failover e não precisa ser configurado no switch para fazer o IMO

    
por 12.02.2010 / 23:28