Configuração do HP ProCurve 2810-24G para iSCSI?

8

Eu tenho um par de ProCurve 2810-24G que usarei com um Dell Equallogic SAN e Vmware ESXi. Como o ESXi faz o MPIO, estou um pouco incerto sobre a configuração dos links entre os comutadores. Um tronco é o caminho certo entre os comutadores?

Sei que as portas para os hosts da SAN e ESXi devem estar desmarcadas. Isso significa que quero uma VLAN marcada nas portas do tronco?

Esta é mais ou menos a configuração:

trunk 1-4 Trk1 Trunk 
snmp-server community "public" Unrestricted 
vlan 1 
    name "DEFAULT_VLAN" 
    untagged 24,Trk1 
    ip address 10.180.3.1 255.255.255.0 
    no untagged 5-23 
exit 
vlan 801 
    name "Storage" 
    untagged 5-23 
    tagged Trk1 
    jumbo 
exit 
no fault-finder broadcast-storm 
stack commander "sanstack" 
spanning-tree
spanning-tree Trk1 priority 4
spanning-tree force-version RSTP-operation

A Equallogic PS4000 SAN possui dois controladores, com duas interfaces de rede cada. A Dell recomenda que cada controlador seja conectado a cada um dos comutadores. Na documentação do vmware, parece que é recomendável criar um vmkernel por pNIC. Com o MPIO, isso pode permitir mais de 1 Gbps de taxa de transferência.

insira a descrição da imagem aqui

3molo
fonte

Respostas:

12

Houve algum debate nos comentários à resposta do Chopper3 que não está bem informado por causa de alguns aspectos pouco compreendidos dos requisitos de rede e do comportamento de caminhos múltiplos da Equallogic.

Primeiro, o lado VMware: para iniciantes no ESXi, a recomendação atual, ao usar o iSCSI Software Initiator, da VMware (para ESX \ ESXi 4.1) e da Dell é que você tenha um único Nic físico mapeado para cada porta do VMkernel que será usado para iSCSI. O processo de ligação agora recomendado reforça isso. Ele requer que você tenha apenas um nic físico ativo e nenhuma placa de rede em espera para cada porta do VMkernel. Nenhuma ligação permitida. Agora você pode trapacear e voltar depois e adicionar um nicho de failover, mas a intenção é que o MPIO lide com o failover, para que isso não sirva para nenhum propósito útil (pelo menos quando tudo estiver funcionando como pretendido pela VMware).

A política de caminhos múltiplos padrão permitirá conexões ativas e ativas com uma matriz Equallogic usando round robin.

Segundo, o lado Equallogic: matrizes Equallogic possuem controladores duplos que atuam no modo ativo \ em espera. Para o PS4000, eles têm duas placas de rede Gigabit em cada controlador. Para o controlador ativo, essas duas placas de rede estão ativas e podem receber E / S da mesma fonte. A configuração de rede recomenda que as placas de rede da matriz sejam conectadas a switches separados. Do lado do servidor, você tem vários links que também devem ser distribuídos para switches separados. Agora, a parte ímpar - matrizes Equallogic esperam que todas as portas do iniciador possam ver todas as portas ativas nas matrizes. Esse é um dos motivos pelos quais você precisa de um tronco entre os dois comutadores. Isso significa que, com um host com duas portas iSCSI VMkernel e um único PS4000, existem 4 caminhos ativos entre o iniciador e o destino - dois são "diretos"

Para as conexões do controlador em espera, as mesmas regras se aplicam, mas essas placas de rede só se tornam ativas após um failover do controlador e os mesmos princípios se aplicam. Após o failover nesse ambiente, ainda haverá quatro caminhos ativos.

Terceiro, para caminhos múltiplos mais avançados: o Equallogic agora possui um módulo de extensão de caminhos múltiplos que se conecta à arquitetura de armazenamento plugável da VMware que fornece balanceamento de carga inteligente (usando menos profundidade da fila, Round Robin ou MRU) nas portas do VMkernel. Isso não funcionará se todas as uplink nics do vmkernel não conseguirem se conectar a todas as portas Equallogic ativas. Isso também garante que o número de caminhos realmente usados ​​permaneça razoável - em grandes ambientes Equallogic, o número de caminhos válidos entre um host e um Grupo Equallogic pode ser muito alto porque todas as placas de destino estão ativas e todas as placas de origem podem ver todas as placas de destino.

Quarto para ambientes Equalógicos maiores: ao escalonar um ambiente Equalógico, você adiciona matrizes adicionais a um grupo compartilhado. Todas as portas ativas em todas as matrizes membros de um grupo devem poder ver todas as outras portas ativas em todas as outras matrizes do mesmo grupo. Esse é outro motivo pelo qual você precisa de tubos de gordura fornecendo conexões entre comutadores entre todos os comutadores em sua estrutura Equallogic iSCSI. Esse dimensionamento também aumenta drasticamente o número de caminhos ativos válidos entre iniciadores e destinos. Com um Equallogic Group composto por 3 matrizes PS6000 (quatro nics por controlador vs 2 para o PS4000) e um host ESX com duas portas vmkernel, haverá 24 caminhos ativos possíveis para a pilha MPIO escolher.

Quinta agregação de vínculo \ link e links Inter Switch em um ambiente equallogic: Todas as conexões entre array e iniciador <-> array são ponto a ponto para conexões Gigabit (ou 10Gig se você tiver um array 10Gig). Não há necessidade nem benefícios a serem obtidos na ligação no servidor ESX e você não pode conectar as portas nas matrizes Equallogic. A única área em que a agregação de links \ ligação \ o que você quiser chamar é relevante em uma malha Ethernet comutada Equallogic está nos links entre interruptores. Esses links precisam transportar fluxos simultâneos que podem ser iguais ao número total de portas Equallogic ativas em seu ambiente - você pode precisar de muita largura de banda agregada lá, mesmo que cada link ponto a ponto entre portas de matriz e portas de iniatador seja limitado a 1gbps.

Finalmente: em um ambiente Equallogic, o tráfego de um host (iniciador) para uma matriz pode e irá atravessar o link entre comutadores. Se um caminho específico faz isso depende do endereço IP de origem e destino para esse caminho específico, mas cada porta de origem pode se conectar a cada porta de destino e pelo menos um desses caminhos exigirá atravessar o ISL. Em ambientes menores (como este), todos esses caminhos serão usados ​​e ativos. Em ambientes maiores, apenas um subconjunto de caminhos possíveis é usado, mas a mesma distribuição ocorrerá. A largura de banda iSCSI agregada disponível para um host (se configurada corretamente) é a soma de toda a largura de banda da porta do iSCSI vmkernel, mesmo se você estiver se conectando a uma única matriz e um único volume. Quão eficiente isso pode ser é outra questão e essa resposta já é longa demais.

Helvick
fonte
1
Você precisa seguir este conselho! Eu trabalho para o maior revendedor EQL do centro-oeste, eu coloco esses sistemas diariamente. A marcação / troncos é o caminho a seguir e permite que o plug-in MEM crie seus vswitches para você. Seu ISL deve ser tão grande quanto você puder pagar para ser uma conexão inteligente. Normalmente, usamos switches empilháveis. Os Juniper EX4200 são INCRÍVEIS para iSCSI.
quer
Uau, resposta incrível. Não vi essa mensagem até agora, mas consegui colocar tudo em funcionamento conforme o esperado, e os resultados do iometer mostram que ele tem o melhor desempenho possível. Ainda tem que verificar toda redundância. Muito obrigado pela sua resposta extremamente informativa!
3molo
6
Since ESXi does MPIO, I am a little uncertain on the configuration for links between the switches. Is a trunk the right way to go between the switches?

O ESX / i faz seu próprio gerenciamento de caminho - ele não ficará ativo / ativo em seus links, a menos que dois ou mais links estejam no mesmo comutador ou os comutadores estejam no modo de compartilhamento de CAM, como o VSS da Cisco - qualquer coisa caso contrário, será uma configuração ativa / passiva.

Por todos os meios, o tronco entre os switches, se você quiser, mas presumivelmente os dois têm uplinks para algum switch ou roteador principal? Nesse caso, não sei por que você entraria em tronco entre apenas dois comutadores dessa maneira, pois as caixas ESX / i mudarão para o segundo comutador se o primeiro for desativado (se configurado corretamente).

I know that the ports for the SAN and the ESXi hosts should be untagged, so does that mean that I want tagged VLAN on the trunk ports?

Não sei de onde vem essa suposição; o ESX / i é tão confortável quanto trabalhando em uma instalação com ou sem etiqueta, seja para tráfego de visitantes ou iSCSI. Dito isso, tive problemas com a mistura de marcados e não marcados ao usar vlans padrão, por isso sempre identifico tudo agora e não tenho vlan padrão, é uma configuração muito flexível e não apresenta desempenho discernível na minha experiência.

Chopper3
fonte
Tenho certeza de que a documentação do ESXi para armazenamento SAN afirma que não se deve vincular as placas de rede, mas sim confiar no MPIO para aumentar o desempenho e os benefícios da redundância (não importa se os links vão para o mesmo comutador). Obviamente, não haverá uplinks nos comutadores principais, este é um par de comutadores apenas para armazenamento. Afirmo também que pretendo usar vlans sem marcação para hosts e SAN, para que ainda faça minha pergunta válida; devo ou não devo usar TAGGED nos links de tronco?
3molo
1
O motivo para usar portas marcadas é se você precisa transportar mais de uma VLAN por ela. A marcação das VLANs permite distinguir entre elas. Você também não precisa usar o LACP para criar um pacote agregado de link (tronco para HP, Etherchannel para Cisco). Você pode definir um grupo de agregação estático e se beneficiar do equilíbrio e do failover do lado do comutador. Dito isso, também é comum deixar o lado do switch em paz e deixar o ESX lidar com a tomada de decisões de tráfego.
Mcmeel
mcmeel, considere escrever uma resposta real. É mais fácil comentar. Não tem certeza de como seria a configuração entre switches, se eu deixasse o ESXi tomar a decisão?
3molo
-1 helicóptero, sinto que você não sabe o suficiente sobre o assunto ou não leu bem a minha pergunta.
3molo
1
O GAL funciona como esperado. Eu tenho dois links de 1 Gbit e o EQ está conectado a um switch cada. Recebo até 235 MB / s de leituras e gravações sequenciais. Ou nós não nos entendemos, ou eu estava correto em minhas declarações sobre a configuração. Btw, seu round-robin, mas afirma ativo / ativo.
3molo
1

É o controlador de matriz SAN que define como você deve conectar isso. Está fornecendo o mesmo LUN nas duas portas do mesmo controlador? Então a porta0 vai para o switchA, a porta1 para o switchB e o mesmo com o próximo controlador.

Por que você deseja usar o LACP / etherchannel em uma SAN iSCSI com portas de uplink de 1gbit? Isso não ajuda em nada. Crie 2 comutadores v com um único pNic em cada vSwitch e conecte o primeiro pNic ao switchA, o segundo pNic ao switchB. Isso fornecerá redundância total contra falhas do controlador / switch / nic.

pauska
fonte
O etherchannel / LACP é apenas entre switches, mas isso não me ajuda em nada? Imaginei que as conexões pudessem atravessar os comutadores por causa do MPIO, por exemplo, uma porta no comutador em que um dos controladores está conectado.
3molo
Por que as conexões atravessam os comutadores? Isso não faz sentido.
pauska
1
Cada iniciador entra em contato com o IP do grupo, que é redirecionado para o IP de uma das NICs do grupo. Não há nada que impeça um iniciador no Switch A de se conectar à matriz em sua NIC conectada ao Switch B. Com base no número de conexões, um link LACP de 4 GB entre os switches deve ser suficiente para evitar problemas. Pessoalmente, prefiro conectar todas as portas de um controlador a um switch. Quando você os divide, reduz pela metade sua largura de banda na matriz em uma situação de falha.
SpacemanSpiff 23/02
Ótima resposta SpacemanSpiff, fui com 2 links LACP.
3molo