Introdução #
Entre os quatro tipos de Network Address Translation(NAT) suportados em RELIANOID ADC, temos Fonte NAT (NAT), NAT Dinâmico (DNAT), Retorno direto do servidor (DSR) e DNAT sem estado. Neste artigo, vamos nos aprofundar nas complexidades do Direct Server Return (DSR), explorando sua arquitetura, benefícios e potenciais obstáculos. Também configuraremos o DSR no Relianoid ADC.
DSR é quando os servidores de aplicativos de back-end respondem diretamente às solicitações do cliente ao receber e processar uma solicitação. Mas como isso funciona? Aqui está como a comunicação flui entre os servidores e os clientes da web.
Fluxo de Comunicação DSR #
Solicitação do cliente: Um cliente inicia uma solicitação, como acessar arquivos de mídia transmitíveis ou enviar dados para servidores de aplicativos via Relianoid ADC.
Interação do balanceador de carga: Ao receber a solicitação, a Relianoid não modifica o conteúdo da solicitação, exceto o Endereço MAC de destino. O endereço MAC modificado é o do servidor de back-end para processar a solicitação. O balanceador de carga encaminha a solicitação para o servidor de back-end apropriado com base no conjunto de algoritmos de balanceamento de carga.
Servidor de aplicativos de back-end: Ao receber a solicitação, o servidor de back-end processa a solicitação e gera uma resposta.
Resposta Direta: O servidor Backend então envia a resposta diretamente para o dispositivo cliente, completando o loop de comunicação.
Nota Importante
- O Relianoid normalmente responde a solicitações ARP em nome dos servidores backend para preservar a comunicação cliente-servidor original. Portanto, configurações ARP adequadas são cruciais para garantir o roteamento adequado de pacotes.
- Deve-se planejar cuidadosamente o esquema de endereçamento IP para evitar conflitos e garantir a comunicação adequada entre clientes e servidores de back-end. Normalmente, configuramos os servidores de back-end para que tenham endereços IP semelhantes ao IP virtual (VIP) usado pelo farm L4xNAT, mas os back-end podem não anunciá-lo nas chamadas ARP para evitar conflitos.
Por que usar DSR para sua infraestrutura de rede #
O DSR tornou-se extremamente importante na infraestrutura de rede atual devido à sua capacidade de lidar com grandes quantidades de dados sem causar grandes gargalos. Isso, aqui, é um grande negócio. Além da escalabilidade, versatilidade, alta disponibilidade e tolerância a falhas, os principais motivos pelos quais o DSR se destaca são:
Desempenho Turboalimentado: Ao eliminar os saltos adicionais introduzidos pelos métodos de roteamento tradicionais, o DSR reduz significativamente a latência e a perda de pacotes. Poderíamos usar essa configuração em jogos e streaming de vídeo, onde a entrega eficiente de blocos de dados substanciais é crucial.
Por exemplo, em jogos multijogador, o DSR permite a comunicação direta entre os clientes do jogo e os servidores do jogo sem que o balanceador de carga medeie cada pacote de dados. Essa comunicação direta permite uma transmissão mais rápida e eficiente de dados relacionados ao jogo, como movimentos, ações e atualizações do jogador. Como resultado, o DSR reduz a latência, aprimora a experiência de jogo e contribui para uma jogabilidade mais suave.
Da mesma forma, no streaming de vídeo, quando um cliente solicita um streaming de vídeo, os servidores de back-end podem transmitir os dados de vídeo diretamente para o cliente sem roteá-los por meio do balanceador de carga. Ao remover o balanceador de carga no caminho de dados, minimizamos possíveis gargalos, garantindo uma experiência de streaming perfeita para os visualizadores. Isso é particularmente benéfico para conteúdo de vídeo de alta qualidade ou alta resolução, onde o manuseio eficiente de grandes blocos de dados é essencial para reprodução ininterrupta.
Carga reduzida no balanceador de carga: Com o DSR, aliviamos o balanceador de carga que lida com o tráfego de retorno do servidor de back-end. Esse descarregamento reduz significativamente a carga de processamento no balanceador de carga, permitindo que ele se concentre na distribuição eficiente das solicitações recebidas. Como resultado, o balanceador de carga lidará com um volume maior de tráfego e obterá melhor escalabilidade geral.
Não há necessidade de manter uma tabela de roteamento: O roteamento pode ser complexo, especialmente em redes de grande escala com várias sub-redes e políticas de roteamento intrincadas. Ao não manter uma tabela de roteamento para o tráfego de retorno, o balanceador de carga evita a necessidade de manipular e gerenciar configurações de roteamento complexas, reduzindo as chances de configurações incorretas ou problemas relacionados ao roteamento.
Configurações Relianoid para servidores backend Linux e Windows #
Para ativar o DSR, primeiro você deve configurar um servidor virtual de camada 4 ou um farm L4xNAT. Ler esse artigo para criar um.
Requisitos para DSR: #
- O IP virtual e back-ends devem estar na mesma rede.
- O Porta virtual e as portas de back-end devem ser as mesmas.
- É preciso configurar os back-ends loopback interfaces com o mesmo endereço IP do VIP configurado no balanceador de carga e desativar ARP nesta interface.
Servidores de back-end Linux #
# ifconfig lo:0 192.168.0.99 máscara de rede 255.255.255.255 -arp up
Com este comando, criamos uma interface de rede virtual eis:0 com o endereço IP 192.168.0.99 e uma máscara de sub-rede de 255.255.255.255.
O -arp sinalizador desativa o Address Resolution Protocol (ARP) nesta interface.
Desativando respostas ARP inválidas no back-end. #
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
Este comando define o valor de arp_ignore como 1 no /proc/sys/net/ipv4/conf/all arquivo. Este parâmetro determina como o kernel responde às solicitações ARP. Defini-lo como 1 significa que o sistema deve ignorar solicitações ARP para endereços IP não configurados na interface de rede.
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
Este comando modifica o parâmetro arp_announce nos servidores back-end. Nas configurações DSR, configurar arp_announce para 2 garante que, quando os servidores de back-end responderem às solicitações ARP, eles usem o endereço IP de destino da solicitação como o endereço IP de origem na resposta ARP. Isso mantém a comunicação adequada entre os servidores de back-end e o cliente, pois o cliente espera receber a resposta do endereço IP para o qual enviou a solicitação.
Servidores de back-end do Windows #
- Começar->Configurações->Painel de controle->Rede e conexões dial-up.
- Clique com o botão direito do mouse no seu adaptador de rede e clique em Propriedades.
- Preço: Protocolo Internet deve ser selecionado (Desmarque “Cliente para redes MS” e “Compartilhamento de arquivos e impressoras”)
- Propriedades TCP/IP-> Insira o endereço IP do VIP no farm Relianoid ADC. O gateway padrão é opcional. Insira a máscara 255.255.255.255
- Definir métrica de interface para 254. Esta configuração é necessária para parar de responder a qualquer resposta ARP ao VIP
- Imprensa OK e salve as alterações.
Depois, configure o modelo de segurança do Host para aceitar tráfego do Relianoid ADC na interface NIC. Além disso, permita que o Relianoid ADC envie e receba tráfego pela interface NIC padrão. Abra o CMD como administrador e execute os três comandos fornecidos.
interface netsh ipv4 definir interface NIC fracohostreceive=ativado interface netsh ipv4 definir loopback de interface fracohostreceive=ativado interface netsh ipv4 definir loopback de interface fracohostsend=ativado
Nota Importante
Altere a NIC e volte para os nomes de interface padrão do seu computador com Windows.
Desafios do uso do DSR #
Embora o Direct Server Return (DSR) ofereça inúmeros benefícios, às vezes pode apresentar desafios potenciais que as organizações precisam considerar e abordar. Compreender esses desafios ajudará a planejar e implementar DSR de forma eficaz. Aqui estão alguns desafios comuns associados ao DSR:
Roteamento assimétrico: Isso significa que os caminhos de ida e volta seguem rotas diferentes. Embora isso possa ter méritos, o roteamento assimétrico pode complicar a solução de problemas e o monitoramento da rede, pois o fluxo de tráfego não é simétrico.
Compatibilidade do servidor: Nem todos os servidores suportarão DSR com todos os tipos de aplicativos. Por exemplo, podemos executar DSR somente com servidores Linux ou Windows ao usar Relianoid.
Operações com estado: Para operações com monitoramento de estado que dependem da manutenção de informações de sessão, o DSR pode apresentar desafios. Ao usar outros tipos de NAT, os balanceadores de carga lidam com todas as formas de persistência de sessão, mas com DSR, o roteamento direto ignora esses intermediários. Uma maneira de contornar isso é usar o endereço IP de origem na camada 4 e a inserção de cookie na camada 7 para persistência da sessão.
Visibilidade e monitoramento de rede: O DSR pode afetar a visibilidade e o monitoramento da rede, pois o tráfego ignora balanceadores de carga ou proxies reversos. As ferramentas e sistemas de monitoramento que dependem da inspeção ou interceptação de tráfego nesses intermediários podem não capturar a imagem completa do tráfego de rede. As organizações podem implementar soluções alternativas de monitoramento para garantir a visibilidade do tráfego que flui pelos caminhos DSR.
Complexidade de implantação: A implementação do DSR pode apresentar complexidade adicional durante a implantação e configuração. Planejamento, design e testes adequados são cruciais para garantir uma implementação tranquila. Por exemplo, pode ser necessário configurar cada servidor de back-end para executar o descarregamento e registro de SSL.
Considerações de segurança: O DSR pode apresentar desafios de segurança, especialmente quando o tráfego ignora diretamente as medidas de segurança implementadas nos balanceadores de carga. Às vezes, pode ser necessário alterar os detalhes dos cabeçalhos de resposta, o que é impossível com as configurações de DSR.
Ao abordar proativamente esses desafios, as organizações podem implementar com êxito o DSR e aproveitar seus benefícios, minimizando possíveis desvantagens.
Conclusão #
O Direct Server Return (DSR) apresenta uma abordagem cativante de balanceamento de carga com o potencial de enriquecer sua infraestrutura com vantagens significativas. Ao descarregar o tráfego de retorno dos servidores de back-end e permitir que eles enviem respostas diretamente aos clientes, o DSR reduz a carga no balanceador de carga e melhora a escalabilidade geral do sistema.
Outra vantagem pode ser a menor latência da rede, pois as respostas seguem um caminho mais direto para os clientes, ignorando o balanceador de carga. Isso pode ser particularmente vantajoso para aplicativos sensíveis à latência, garantindo entrega mais rápida de conteúdo e melhor experiência do usuário.
No entanto, avalie cuidadosamente os requisitos específicos de sua arquitetura de rede e as necessidades do aplicativo antes de implementar o DSR. Considere fatores como topologia de rede, protocolos de roteamento, necessidade de persistência de sessão e possíveis desafios associados.
Aproveitando os benefícios do DSR, você pode otimizar sua infraestrutura para lidar com cargas de tráfego crescentes e oferecer uma experiência de usuário perfeita.
