SNAT vs PBR para balanceamento de carga do servidor

Em uma configuração SLB de um braço, o SNAT é usado para forçar o tráfego de retorno a passar pelo SLB. Isso tem um aspecto negativo: simplesmente que os logs da web não podem capturar o IP do cliente verdadeiro, a menos que sejam passados no cabeçalho XFF (X-Forwarded-For) e o servidor da web possa fazer logon.

Uma alternativa é usar o PBR (roteamento baseado em políticas) para obter o tráfego de retorno de volta ao SLB, mas tento evitar o PBR, a menos que não exista outra / melhor solução Na plataforma 6500E com SUP720 / PFC3B - e eu sei o particular A versão do IOS também pode ser um fator - o PBR adiciona alguma latência ao fazer o SNAT, assumindo que o PBR é todo feito em hardware? Se o PBR for feito em hardware usando apenas os comandos suportados por ele hoje, é possível que o upgrade do IOS no futuro possa mudar o PBR para ser feito em software / comutado por processo?

Hoje, nossos balanceadores de carga têm a maioria das VLANs de servidores da Web diretamente atrás deles - g / w padrão apontando para SLB - e outros servidores como SQL em VLANs não SLB. No entanto, esse tráfego da web sql transita pelo SLB. Nosso objetivo seria evitar cruzar o SLB e apenas manter o tráfego SQL separado e ainda manter o verdadeiro cliente nos logs da web. Prefiro não introduzir a complexidade da solução de problemas com o PBR e possivelmente ter essa alteração de hardware para software processada no futuro. Com exceção do XFF e do SNAT mencionados anteriormente, a PBR é a única opção aqui e qual é a melhor maneira de manter a PBR bem configurada?

— generalnetworkerror
fonte

Não tenho 100% de certeza de que compreendo a topologia, seu servidor tem duas interfaces e você precisa do SNAT para que o servidor possa ter uma rota estática única para retornar o tráfego de 'produção' à interface voltada para o SLB? Mas a configuração SNAT na 1: N implica estados, que sempre devem ser evitados, o PBR é sem estado, por isso é muito melhor.

— ytti 7/09/13

Normalmente, aconselho contra o design do balanceador de carga com um braço (ou você pode chamá-lo de balanceador de carga em um stick) e opto por uma sub-rede frontal para VIPs com balanceamento de carga e uma sub-rede traseira para o servidor piscinas. Os servidores são padronizados por meio da interface traseira no balanceador de carga. Isso elimina completamente a necessidade de SNAT ou PBR.

— 9788 Mike Pennington #

Além do meu comentário sobre topologias do balanceador de carga ... você poderia adicionar alguns diagramas para referência, porque algumas das perguntas não são claras quando você não tem certeza de como é a imagem maior.

— 9788 Mike Blumenau

@ytti, a topologia atual tem SLB embutido com o g / w padrão dos servidores apontando para SLB - NIC / servidor único. Temos essencialmente o que Mike descreveu com as VLANs do lado do cliente e do servidor em duas interfaces do SLB agora, mas esta é uma questão de mudar para uma topologia diferente, como uma arma, para que o tráfego do servidor para o SQL não precise atravessar o SLB e preferimos não adicionar complexidade aos servidores, como placas de rede duplas com rotas estáticas, etc. Entender a latência do SNAT vs PBR é essencial, assim como outros projetos que eu perdi (como o Direct Server Return descrito em uma resposta )

— generalnetworkerror

Quais servidores eles são? No Linux (ou * BSD), é fácil configurar, para que o pacote retorne à interface de onde veio, o que é útil nas configurações SLB (usamos isso para conectar servidores de forma redundante a duas caixas SLB desconectadas, os VIPs são ECMPd, portanto, ambos são quentes, mas podem ser de fornecedores diferentes, pois desconhecem um ao outro).

— ytti 12/09

Respostas:

o PBR adiciona alguma latência ao fazer o SNAT, assumindo que o PBR é todo feito em hardware?

O Sup720 suporta PBR em HW , a latência adicional (se houver) é insignificante porque o PBR não adiciona mais filas de interface. Acho que a PBR tornaria as coisas mais difíceis do que precisam (e ainda não tenho certeza se funcionaria ... as especificidades dessa opção não são totalmente claras)

Com exceção do XFF e do SNAT mencionados anteriormente, a PBR é a única opção aqui e qual é a melhor maneira de manter a PBR bem configurada?

PBR não é a única opção. Sua opção proposta não é clara, mas o PBR normalmente se resume a nada mais do que uma maneira mais sofisticada de fazer o roteamento estático.

Normalmente, essa é a melhor topologia para serviços com balanceamento de carga que requerem consultas SQL ...

Coloque seus VIPs em uma sub-rede frontal ... 172.16.1.0/24 no diagrama
Coloque seus pools de servidores em uma sub-rede traseira ... 172.16.2.0/24 no diagrama
Coloque suas consultas SQL em outra interface ... 172.16.3.0/24 no diagrama. Adicione uma segunda interface a todos os servidores que requerem consultas SQL. Faça todas as suas consultas SQL para endereços nesta sub-rede. Essa topologia funciona para Unix e Windows, pois você depende apenas de ARP ou rotas de host (dependendo da sua preferência) para conectividade SQL.

Diagrama:

Rede de consulta LB w SQL

Essa topologia possui benefícios adicionais:

Ele separa as interfaces SQL do tráfego da Web, pois as consultas SQL são explosivas e podem acabar com o tráfego da Web.
Ele fornece MTUs diferentes para seus serviços de balanceamento de carga (que geralmente precisam permanecer em 1500 ou menos, se eles transitarem na Internet) e para os serviços SQL (que favorecem os jumbo-frames).

Qualquer topologia de balanceador de carga com um braço é uma opção menos desejável, pois você acaba cortando pela metade o rendimento máximo por causa da topologia com um braço.

Edição para pergunta sobre HW vs SW comutação no Sup720

Este é um tópico profundo, mas darei a versão resumida ... Sup720 aplica uma ACL em cada direção (entrada / saída) e a ACL deve caber no TCAM com base no algoritmo de mesclagem escolhido pela plataforma. O Gerenciador de recursos do Sup720 (ou seja, fm) é responsável por mediar os recursos no TCAM e informar se você tem uma adjacência de pontapé (ou seja, comutação SW) ou se a combinação de protocolo e direção é alternada no HW. Para isolar se

Primeiro, identifique todas as interfaces Layer3 de entrada e saída que o tráfego PBR pode transitar
Em seguida, examine a saída de show fm fie int <L3_intf_name> | i ^Interf|Result|Flow|Config(você deve examinar as direções de entrada e saída para todas as interfaces na Etapa 1 ). Seu tráfego será HW comutado se os valores no CAPS corresponderem aos valores que você vê abaixo ... observe que a saída do comando que estou usando é muito semelhante à que você vê em show fm fie summary...

Tx.Core01#sh fm fie int Vl220 | i ^Interf|Result|Flow|Config
Interface Vl220:
 Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS      <--- in HW
 Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS   <--- in HW
 Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_SUCCESS    <--- in HW
Interface Vl220 [Ingress]:
 FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT                        <--- in HW
 Features Configured : V4_DEF   - Protocol : IP
 FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT                     <--- in HW
 Features Configured : OTH_DEF   - Protocol : OTHER
 FIE Result for protocol IPV6 : FIE_SUCCESS_NO_CONFLICT                      <--- in HW
 Features Configured : V6_DEF   - Protocol : IPV6
Interface Vl220 [Egress]:
 No Features Configured
No IP Guardian Feature Configured
No IPv6 Guardian Feature Configured
No QoS Feature Configured
Tx.Core01#

A interface acima não mostra a saída de saída, mas isso é irrelevante ... a saída é semelhante à direção de entrada. Ricky Micky escreveu uma excelente explicação da 'interface sh fm fie' se você quiser obter mais detalhes sobre a dinâmica dos resultados de mesclagem / bancos do TCAM.

— Mike Pennington
fonte

Eu já havia eliminado essa opção de design, pois requer adjacência L2 entre a camada de front-end e a de back-end, além de não ter uma escala adequada para nossas várias VLANs de back-end e por causa da potencial necessidade de colocar um firewall (não transparente ) entre camadas. No entanto, ainda é uma excelente opção para quem não tem essas preocupações. Bom ponto sobre as MTUs.

— generalnetworkerror 14/09/13

Com falta de documentação de consulta do PBR para versões específicas do IOS para saber se um determinado recurso do PBR aciona a necessidade de ser feito em software, isso pode ser determinado no IOS? Isso é o que eu quis dizer com "rigidamente configurado" para o PBR para mantê-lo operando no hardware.

— generalnetworkerror 14/09/13

@generalnetworkerror, em que hardware você quer fazer o PBR? Se Sup720 / Sup2T, não é tão difícil identificar se você está alternando entre HW e SW ... precisamos de mais detalhes para ajudar. Na verdade, se você não se importaria de um diagrama de como este PBR conceito funciona seria realmente útil

— Mike Pennington

SUP720 / PFC3B ... olhando para ver como você pode determinar a partir CLI se um determinado recurso PBR forçado isso em s / w comutação

— generalnetworkerror

@generalnetworkerror, sh fm fie summary... ou ler a minha resposta para mais informações ...

— Mike Pennington

Se o seu balanceador de carga oferecer suporte, o Direct Server Return também faria o que você deseja. Ele precisa ser suportado pelo seu balanceador de carga e há algumas preocupações com o sistema operacional. Isso envolve a colocação de interfaces de 'loopback' em cada servidor com todos os endereços IP do VIP, o balanceador de carga e os endereços reais do servidor, usando apenas o endereço MAC do servidor real para encaminhar o pacote, pois o servidor possui a interface de loopback com o VIP nele, o servidor aceita o pacote.

Você precisa consultar o documento do fornecedor LB específico e suas equipes de servidores devem poder gerenciar o adaptador virtual (não usamos esse recurso porque não achamos que nosso provisionamento de servidor automatizado pudesse gerenciar um adaptador de loopback da Microsoft.

Mas isso não usa o NAT no LB e você não precisa fazer o PBR.

— fredpbaker
fonte