Como exatamente e especificamente o trabalho de hashing de endereço de destino de camada 3 LACP?

52

Com base em uma pergunta anterior há mais de um ano ( Ethernet de 1 Gbps multiplexada? ), Eu saí e configurei um novo rack com um novo ISP com links LACP em todo o lugar. Precisamos disso porque temos servidores individuais (um aplicativo, um IP) que atendem milhares de computadores clientes em toda a Internet em excesso de 1Gbps cumulativos.

Essa idéia do LACP deve nos permitir quebrar a barreira de 1Gbps sem gastar uma fortuna em switches 10GoE e NICs. Infelizmente, encontrei alguns problemas relacionados à distribuição de tráfego de saída. (Isso apesar do aviso de Kevin Kuphal na pergunta relacionada acima.)

O roteador do ISP é um tipo de Cisco. (Eu deduzi isso do endereço MAC.) Meu switch é um HP ProCurve 2510G-24. E os servidores são HP DL 380 G5s que executam o Debian Lenny. Um servidor é um hot standby. Nosso aplicativo não pode ser armazenado em cluster. Aqui está um diagrama de rede simplificado que inclui todos os nós de rede relevantes com IPs, MACs e interfaces.

Emboratenhatodososdetalhes,éumpoucodifíciltrabalharedescrevermeuproblema.Então,parasimplificar,aquiestáumdiagramaderedereduzidoparaosnóselinksfísicos.

Então eu saí e instalei o meu kit no novo rack e conectei o cabeamento do meu provedor do roteador. Ambos os servidores têm um link LACP para o meu switch, e o switch tem um link LACP para o roteador do ISP. Desde o início, percebi que minha configuração de LACP não estava correta: os testes mostraram que todo o tráfego de e para cada servidor passava por um link físico do GoE exclusivamente entre servidor a comutador e comutador a roteador.

ComalgumaspesquisasnogoogleeummontedetempoRTMFsobreligaçõesdeNICsdoLinux,descobriquepodiacontrolaraligaçãoNICmodificando/etc/modules

#/etc/modules:kernelmodulestoloadatboottime.#mode=4isforlacp#xmit_hash_policy=1meanstouselayer3+4(TCP/IPsrc/dst)&notdefaultlayer2bondingmode=4miimon=100max_bonds=2xmit_hash_policy=1loop

IssofezcomqueotráfegodeixassemeuservidoremambososNICscomoesperado.Masotráfegoestavapassandodoswitchparaoroteadorporapenasumlinkfísico,ainda.

Precisamos que o tráfego atinja os dois links físicos. Depois de ler e reler o Guia de Gerenciamento e Configuração do 2510G-24, eu encontro:

[LACP uses] source-destination address pairs (SA/DA) for distributing outbound traffic over trunked links. SA/DA (source address/destination address) causes the switch to distribute outbound traffic to the links within the trunk group on the basis of source/ destination address pairs. That is, the switch sends traffic from the same source address to the same destination address through the same trunked link, and sends traffic from the same source address to a different destination address through a different link, depending on the rotation of path assignments among the links in the trunk.

Parece que um link vinculado apresenta apenas um endereço MAC e, portanto, meu caminho de servidor para roteador sempre estará em um caminho de switch para roteador, porque o switch vê apenas um MAC (e não dois). -uma de cada porta) para ambos os links LACP.

Entendi. Mas isso é o que eu quero:

UmswitchHPProCurvemaiscaroéo2910alusasource&endereçosdedestinoemseuhash.Daseção"Distribuição de tráfego de saída através de links troncalizados" do Guia de gerenciamento e configuração do ProCurve 2910al :

The actual distribution of the traffic through a trunk depends on a calculation using bits from the Source Address and Destination address. When an IP address is available, the calculation includes the last five bits of the IP source address and IP destination address, otherwise the MAC addresses are used.

OK. Então, para que isso funcione do jeito que eu quero, o endereço de destino é a chave, pois meu endereço de origem é fixo. Isso leva à minha pergunta:

Como exatamente & especificamente faz o trabalho de hashing LACP da camada 3?

Preciso saber qual endereço de destino é usado:

  • o IP do cliente , o destino final?
  • Ou o IP do roteador , o próximo destino de transmissão do link físico.

Ainda não compramos um interruptor de substituição. Por favor, ajude-me a entender exatamente se o hashing de endereço de destino da camada 3 do LACP é ou não o que eu preciso. Comprar outro switch inútil não é uma opção.

    
por Stu Thompson 17.08.2010 / 12:33

5 respostas

13

O que você está procurando é comumente chamado de "política de hash de transmissão" ou "algoritmo de hash de transmissão". Controla a seleção de uma porta de um grupo de portas agregadas com as quais transmitir um quadro.

Colocar minhas mãos no padrão 802.3ad provou ser difícil porque não estou disposto a gastar dinheiro com isso. Dito isso, consegui coletar algumas informações de uma fonte semi-oficial que esclarece o que você está procurando. Por esta apresentação da reunião do Grupo de Estudo de Alta Velocidade Ottawa, ON, CA IEEE 2007 O padrão 802.3ad não exige algoritmos específicos para o "distribuidor de quadros":

This standard does not mandate any particular distribution algorithm(s); however, any distribution algorithm shall ensure that, when frames are received by a Frame Collector as specified in 43.2.3, the algorithm shall not cause a) Mis-ordering of frames that are part of any given conversation, or b) Duplication of frames. The above requirement to maintain frame ordering is met by ensuring that all frames that compose a given conversation are transmitted on a single link in the order that they are generated by the MAC Client; hence, this requirement does not involve the addition (or modification) of any information to the MAC frame, nor any buffering or processing on the part of the corresponding Frame Collector in order to re-order frames.

Assim, qualquer algoritmo que um switch / driver de NIC use para distribuir quadros transmitidos deve aderir aos requisitos, conforme indicado naquela apresentação (que, presumivelmente, estava citando o padrão). Não há algoritmo específico especificado, apenas um comportamento compatível definido.

Embora não exista nenhum algoritmo especificado, podemos analisar uma implementação específica para ter uma ideia de como esse algoritmo pode funcionar. O driver "bonding" do kernel do Linux, por exemplo, tem uma política de hash de transmissão compatível com 802.3ad que aplica a função (consulte bonding.txt no diretório Documentation \ networking da origem do kernel):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

Isso faz com que os endereços IP de origem e destino, assim como os endereços MAC de origem e destino, influenciem a seleção de portas.

O endereço IP de destino usado nesse tipo de hashing seria o endereço presente no quadro. Tome um segundo para pensar sobre isso. O endereço IP do roteador, em um cabeçalho de quadro Ethernet distante do servidor para a Internet, não é encapsulado em nenhum lugar desse tipo. O endereço MAC do roteador está presente no cabeçalho de tal quadro, mas o endereço IP do roteador não está. O endereço IP de destino encapsulado na carga útil do quadro será o endereço do cliente da Internet que faz a solicitação ao seu servidor.

Uma política de hash de transmissão que leva em consideração os endereços IP de origem e destino, supondo que você tenha um grupo de clientes amplamente variado, deve fazer muito bem para você. Em geral, endereços IP de origem e / ou destino mais amplamente variados no tráfego que flui através de tal infraestrutura agregada resultarão em agregação mais eficiente quando uma política de hash de transmissão baseada em camada 3 for usada.

Seus diagramas mostram solicitações que chegam diretamente aos servidores da Internet, mas vale a pena apontar o que um proxy pode fazer para a situação. Se você estiver intermediando solicitações de clientes para seus servidores, como chris fala em sua resposta então você pode causar gargalos. Se esse proxy estiver fazendo a solicitação a partir de seu próprio endereço IP de origem, em vez do endereço IP do cliente da Internet, você terá menos "fluxos" possíveis em uma política de hash de transmissão estritamente baseada na camada 3.

Uma política de hash de transmissão também pode levar em conta a informação da camada 4 (números de porta TCP / UDP), desde que ela atenda aos requisitos do padrão 802.3ad. Esse algoritmo está no kernel do Linux, conforme você faz referência à sua pergunta. Tenha em atenção que a documentação para esse algoritmo adverte que, devido à fragmentação, o tráfego pode não fluir necessariamente ao longo do mesmo caminho e, como tal, o algoritmo não é estritamente compatível com 802.3ad.

    
por 20.08.2010 / 00:47
5

muito surpreendentemente, alguns dias atrás, nossos testes mostraram que xmit_hash_policy = layer3 + 4 não terá nenhum efeito entre dois servidores linux conectados diretamente, todo o tráfego usará uma porta. ambos correm xen com 1 ponte que tem o dispositivo de ligação como um membro. Obviamente, a ponte poderia causar o problema, apenas que não faz sentido EM TODOS considerando que o hashing baseado em porta ip + seria usado.

Eu sei que algumas pessoas realmente conseguem empurrar 180MB + em links (isto é, usuários ceph), então funciona em geral. Possíveis coisas para olhar: - Usamos o antigo CentOS 5.4 - O exemplo de OPs significaria que o segundo LACP "desenha" as conexões - isso faz sentido, nunca?

O que esta discussão, documentação, leitura, etc., etc. me mostrou:

  • Em geral, todo mundo sabe muito sobre isso, é bom em recitar a teoria a partir dos padrões de ligação ou até mesmo dos padrões do IEEE, enquanto a experiência prática é quase nula.
  • A documentação do RHEL está incompleta na melhor das hipóteses.
  • A documentação de ligação é de 2001 e não é atual o suficiente
  • o modo layer2 + 3 aparentemente não está no CentOS (ele não é exibido no modinfo e, em nosso teste, ele descartou todo o tráfego quando ativado)
  • Não ajuda que o SUSE (BONDING_MODULE_OPTS), o Debian (-o bondXX) e o RedHat (BONDING_OPTS) tenham maneiras diferentes de especificar as configurações do modo por vínculo
  • O módulo do kernel do CentOS / RHEL5 é "seguro para SMP", mas não "compatível com SMP" (consulte a palestra de alto desempenho do Facebook) - ele não escala acima de um CPU, portanto, com maior relógio cpu de conexão > muitos núcleos

Se qualquer pessoa acaba com uma boa configuração de ligação de alto desempenho, ou realmente sabe o que está falando, seria fantástico se eles levassem meia hora para escrever um novo pequeno howto que documenta ONE exemplo de trabalho usando LACP, sem coisas estranhas e largura de banda > um link

    
por 16.06.2011 / 14:30
2

Se o seu switch vir o verdadeiro destino L3, ele pode ficar com hash. Basicamente, se você tem 2 links, acho que o link 1 é para destinos com números ímpares, o link 2 é para destinos com números pares. Eu não acho que eles usem o IP do próximo salto, a menos que estejam configurados para isso, mas é praticamente o mesmo que usar o endereço MAC do alvo.

O problema que você vai encontrar é que, dependendo do seu tráfego, o destino sempre será o único endereço IP do servidor único, então você nunca usará esse outro link. Se o destino for o sistema remoto na Internet, você obterá distribuição uniforme, mas se for algo como um servidor da Web, onde seu sistema é o endereço de destino, o switch sempre enviará tráfego sobre apenas um dos links disponíveis.

Você estará em pior situação se houver um balanceador de carga em algum lugar, porque o IP "remoto" sempre será o IP do balanceador de carga ou o servidor. Você poderia contornar isso um pouco usando muitos endereços IP no balanceador de carga e no servidor, mas isso é um truque.

Você pode expandir seu horizonte de fornecedores um pouco. Outros fornecedores, como redes extremas, podem interferir em coisas como:

L3_L4 algorithm—Layer 3 and Layer 4, the combined source and destination IP addresses and source and destination TCP and UDP port numbers. Available on SummitStack and Summit X250e, X450a, X450e, and X650 series switches.

Então, basicamente, desde que a porta de origem do cliente (que normalmente muda muito) seja alterada, você distribuirá o tráfego uniformemente. Tenho certeza de que outros fornecedores têm recursos semelhantes.

Mesmo o hash no IP de origem e destino seria suficiente para evitar pontos de acesso, contanto que você não tenha um balanceador de carga no mix.

    
por 19.08.2010 / 21:53
0

Eu acho que está fora do IP do cliente, não do roteador. Os IPs de origem e destino reais estarão em um deslocamento fixo no pacote, e isso será rápido para fazer o hash. Hashing o IP do roteador exigiria uma pesquisa baseada no MAC, certo?

    
por 19.08.2010 / 18:47
-1

Desde que acabei de voltar aqui, algumas coisas que aprendi agora: Para evitar cabelos grisalhos, você precisa de um switch decente que suporte uma política layer3 + 4, e o mesmo também no Linux.

Em alguns casos, o maçarico de perversão de padrões chamado ALB / SLB (mode6) pode funcionar melhor. Operacionalmente, é uma droga.

Eu mesmo tento usar 3 + 4 sempre que possível, já que muitas vezes eu quero essa largura de banda entre dois sistemas adjacentes.

Eu também tentei com OpenVSwitch e tive uma vez uma instância em que o tráfego interrompido flui (cada primeiro pacote perdido ... eu não tenho idéia)

    
por 26.03.2016 / 19:24