Conteúdo
Introdução
Entre os quatro tipos de Network Address Translation (NAT) suportados no ZEVENET 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 ZEVENET 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 passíveis de streaming ou enviar dados para servidores de aplicativos via ZEVENET ADC.
Interação do balanceador de carga: Ao receber a solicitação, a ZEVENET 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 ZEVENET normalmente responde a solicitações ARP em nome dos servidores de back-end para preservar a comunicação cliente-servidor original. Portanto, configurações adequadas de ARP 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 ZEVENET para servidores de back-end Linux e Windows
Para ativar o DSR, primeiro você deve configurar um servidor virtual de camada 4 ou um farm L4xNAT. Ler isto 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 netmask 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
- Início->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.
- Somente Protocolo Internet deve ser selecionado (Desmarque “Cliente para redes MS” e “Compartilhamento de arquivos e impressoras”)
- Propriedades TCP/IP-> Digite o endereço IP do VIP no farm ZEVENET ADC. O gateway padrão é opcional. Digite 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
- Press OK e salve as alterações.
Depois, configure o modelo de segurança do host para aceitar o tráfego do ZEVENET ADC na interface NIC. Além disso, permita que o ZEVENET ADC envie e receba tráfego por meio da interface NIC padrão. Abra o CMD como administrador e execute os três comandos fornecidos.
netsh interface ipv4 set interface NIC weakhostreceive=enabled netsh interface ipv4 set interface loopback weakhostreceive=enabled netsh interface ipv4 set interface loopback weakhostsend=enabled
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 suportam DSR com todos os tipos de aplicativos. Por exemplo, podemos executar DSR apenas com servidores Linux ou Windows ao usar o ZEVENET.
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.