Dicas para Configurar Balanceamento de Links Internet com o NetScaler – Parte 1

Em minhas experiências como parte do time Citrix Consulting na América Latina, um dos casos de uso comuns do NetScaler é o balanceamento de links Internet.

Uma tarefa aparentemente simples, mas que na verdade esconde alguns detalhes importantes que podem passar despercebidos para os clientes. De fato, os tópicos deste artigo são baseados em casos reais de projetos que participei.

Mas o que é o balanceamento de links Internet?

Em geral, os clientes têm os seguintes objetivos:

• Alta disponibilidade: não depender apenas de um provedor para conexão com a Internet, contratando dois ou mais links
• Performance: utilizar ao máximo os links disponíveis, não deixando links de backup ociosos, agregando a banda dos diversos links para melhorar a performance para os usuários

Implementar este tipo de solução usando roteadores traz alguns desafios:

• Monitoramento do status dos links

Roteadores em geral conseguem detectar o status dos links diretamente conectados a eles (no caso o link Internet), mas e se houver uma falha em outros links mais adiante na infraestrutura do provedor? O roteador não irá detectar esta falha e continuará tentando enviar tráfego ao provedor que não está funcionando, ao invés de enviar somente aos outros links. Sim, é possível configurar alguns monitoramentos mais avançados ou roteamento dinâmico nos roteadores para detectar este tipo de falhas, mas ainda assim não são tão flexíveis comparados aos que o NetScaler pode fazer como veremos mais adiante.

• Balanceamento do tráfego de saída e entrada

É possível balancear o tráfego de saída com um roteador (por exemplo usuários internos navegando na web), mas e quanto ao tráfego de entrada (uma aplicação no datacenter acessível a partir da Internet, por exemplo)? O máximo que se pode fazer neste aspecto é atribuir um IP da faixa de endereços de cada provedor e configurar estes vários IPs no registro DNS da aplicação (FQDN). Assim teremos um balanceamento de entrada por DNS round-robin, onde em teoria, cada usuário externo irá conectar por um link. O problema é que o servidor DNS não monitora os links, e sempre vai responder com os IPs de todos os links, mesmo que um link esteja indisponível. E também não sabe a carga atual de cada link para direcionar o tráfego para o link com menor tráfego.

Ao usar um NetScaler, é possível resolver estes desafios, mas é importante configurá-lo corretamente para tirar o máximo proveito das funcionalidades. Então vamos lá, quais seriam estas configurações?

Vamos dividir as configurações em 2 partes principais:

1. Balanceamento do tráfego de saída
2. Balanceamento do tráfego de entrada

Isto porque cada sentido do tráfego requer o uso de diferentes funcionalidades e configurações.

Primeiro vamos ao balanceamento do tráfego de saída. Para isto utilizamos a funcionalidade de Link Load Balance (LLB).

A documentação do NetScaler (neste link) já explica bem uma configuração básica (virtual servers, serviços, monitores, rotas e RNAT) para ter o balanceamento funcionando.

Quero complementar aqui alguns detalhes que não estão na documentação:

• Monitores

Os monitores default de um serviço de load balance são do tipo PING, e fazem um ping ao roteador do link Internet. Conforme o diagrama a seguir:

Problema 1: O monitor ping default só detecta uma falha na conexão direta entre o roteador e o NetScaler. Se houver uma falha depois do roteador (no link WAN por exemplo, que é o que ocorre na maioria das vezes), mas o roteador continuar respondendo ping localmente, este monitor não irá detectar a falha no link e continuará enviando tráfego para o mesmo, que será descartado pelo roteador pois o link WAN está inoperante.

Solução 1: A própria documentação do NetScaler  recomenda a configuração de monitores do tipo transparente, para fazer uma verificação para além da comunicação local com o roteador. Mas o que é exatamente este monitor transparente?

Vamos supor que para testar se a conexão com a Internet está funcionando (incluindo aí o roteador, link WAN e backbone do provedor), queremos fazer um ping ao servidor DNS público do Google (IP 8.8.8.8). Conforme o diagrama a seguir:

Um monitor simples (não transparente) seria configurado com o seguinte comando:

add lb  monitor monitor-google-dns1 PING -destIP 8.8.8.8

O detalhe, é que um monitor assim vai usar a tabela de rotas para chegar ao destino. Então se a rota default aponta para o router do provedor 1 (não confundir com a rota LLB que aponta para o VIP de LLB), e usarmos este monitor para o “LB service ISP1” e também para o “LB Service ISP2”, as probes de monitoramento de ambos os serviços serão enviadas pelo roteador do provedor 1. Ou seja, não testará corretamente o link do provedor 2.

É justamente aí que o monitor transparente vem ajudar. Para criar o mesmo monitor em modo transparente, o comando seria:

add lb  monitor monitor-google-dns1 PING -destIP 8.8.8.8 -transparent YES

O monitor transparente não considera a tabela de roteamento para enviar a probe ao seu destino, e sim o endereço MAC do roteador para o qual o serviço aponta. Complicado?

Eu explico: como o NetScaler está diretamente conectado em cada roteador (um requisito neste caso), além do endereço IP (que configuramos no serviço) ele sabe o endereço MAC de cada roteador pela resolução ARP. Então para fazer o teste do link do provedor 1, ele manda um PING com IP de destino 8.8.8.8, para o endereço MAC do roteador do provedor 1. Ao receber este pacote, o roteador simplesmente encaminha adiante pelo link WAN até chegar ao servidor DNS1 do Google. Note que eu não mencionei que ele usa a tabela de rotas para chegar ao destino, justamente porque ele não usa.

Da mesma maneira, para testar o link do provedor 2, ele manda um PING com IP de destino 8.8.8.8, para o endereço MAC do roteador do provedor 2. E o roteador encaminha adiante (a resposta do PING volta pelo mesmo link, pois a configuração de RNAT faz com que os pacotes enviados por cada provedor saiam com IP de origem da faixa de IPs correspondente).

Problema 1 resolvido? Quase…

Dois pontos importantes com esta configuração:

1. Caso o servidor DNS1 do Google tenha uma falha, o monitor irá falhar e se temos apenas este monitor para ambos os links, os serviços dos dois links ficarão DOWN e consequentemente o VIP de LLB ficará DOWN, interrompendo todo o tráfego, sendo que os links estão funcionando, o que falhou foi o servidor do Google. Então não dá pra colocar todos os ovos na mesma cesta certo?

Para resolver isto basta configurar monitores para mais de um servidor na Internet (recomendo 4 pelo menos). Assim caso 1, 2 ou até 3 servidores tenham falha ao mesmo tempo, se apenas um dos 4 servidores responderem, quer dizer que o link do provedor está funcionando bem.

2. PING não é um protocolo que os servidores dão prioridade para responder e as vezes pode ser bloqueado por um Firewall (funcionou no dia que você configurou, mas 1 semana depois o administrador do Firewall resolve bloquear PING).

Então o ideal neste caso é configurar um protocolo que: 1) o servidor dará prioridade para resolver, e 2) não será bloqueado por Firewall. Ora, já que estamos usando um servidor DNS pra fazer as probes, porque não fazer uma consulta DNS ao invés de um PING?

Já que (felizmente) você está usando um NetScaler (certo?), é possível configurar um monitor que faça justamente esta consulta. Um exemplo de comando para criar um monitor assim:

add lb monitor monitor-google-dns1 DNS -query google-public-dns-a.google.com -queryType Address -interval 30 -destIP 8.8.8.8 -destPort 53 -IPAddress 8.8.8.8 -transparent YES

Vamos analisar os parâmetros deste comando:

Você pode usar monitores com outros protocolos se preferir, como por exemplo HTTP, FTP, TCP, etc.

Eu particularmente prefiro DNS, pois:

• É um tráfego leve (as consultas e respostas tem poucos bytes), então não ocupa banda e a resposta é rápida
• A probabilidade dos servidores DNS trocarem de IP ou nome (e você ter que reconfigurar seus monitores) é muito baixa. Recomendo usar os servidores de grandes provedores ou os DNS root do país. Dois nacionais e dois internacionais, alguns que costumo usar:
  • Nacionais (Brasil):
    • b.dns.br (root BR)
    • c.dns.br (root BR)
    • mon_dns-lua.na-df.rnp.br (RNP)
  • Internacionais
    • google-public-dns-a.google.com (Google DNS1)
    • google-public-dns-b.google.com (Google DNS2)
    • resolver1.opendns.com (OpenDNS)
    • resolver2.opendns.com (OpenDNS)

Então, um exemplo de configuração com 4 monitores em cada serviço ficaria assim:

add server router_link1 IP_router_ISP1
add server router_link2 IP_router_ISP2
add service svc_router_link1 router_link1 ANY *
add service svc_router_link2 router_link2 ANY *
#Monitores links Internet
#dns-b.dns.br
add lb monitor mon_dns-b.dns.br DNS -query b.dns.br -queryType Address -interval 30 -destIP 200.189.41.10 -destPort 53 -IPAddress 200.189.41.10 -transparent YES
#dns-google-public-dns-a
add lb monitor mon_dns-google-public-dns-a DNS -query google-public-dns-a.google.com -queryType Address -interval 30 -destIP 8.8.8.8 -destPort 53 -IPAddress 8.8.8.8 -transparent YES
#dns-lua.na-df.rnp.br
add lb monitor mon_dns-lua.na-df.rnp.br DNS -query lua.na-df.rnp.br -queryType Address -interval 30 -destIP 200.130.77.69 -destPort 53 -IPAddress 200.130.77.69 -transparent YES
#resolver1.opendns.com
add lb monitor mon_dns-resolver1.opendns.com DNS -query resolver1.opendns.com -queryType Address -interval 30 -destIP 208.67.222.222 -destPort 53 -IPAddress 200.130.2.197 -transparent YES
#Bind dos monitores aos serviços
bind service svc_router_link1 -monitorName mon_dns-b.dns.br
bind service svc_router_link1 -monitorName mon_dns-google-public-dns-a
bind service svc_router_link1 -monitorName mon_dns-lua.na-df.rnp.br
bind service svc_router_link1 -monitorName mon_dns-resolver1.opendns.com
bind service svc_router_link2 -monitorName mon_dns-b.dns.br
bind service svc_router_link2 -monitorName mon_dns-google-public-dns-a
bind service svc_router_link2 -monitorName mon_dns-lua.na-df.rnp.br
bind service svc_router_link2 -monitorName mon_dns-resolver1.opendns.com
#VIP Link Load Balance (LLB)
add lb vserver LLB_VIP_2Links ANY 0.0.0.0 0 -persistenceType SRCIPDESTIP -lbMethod ROUNDROBIN
bind lb vserver LLB_VIP_2Links svc_router_link1
bind lb vserver LLB_VIP_2Links svc_router_link2
add lb route 0.0.0.0 0.0.0.0 LLB_VIP_2Links
#RNAT
#Access-list para fazer RNAT da rede Interna (exemplo rede interna de usuários 10.20.10.0/24)
add ns acl NAT_Link_Load_Balance ALLOW -srcIP = 10.20.10.1-10.20.10.254 -priority 100
apply ns acls
#IPs publicos de cada link que serão usados pelo RNAT
add ns ip IP_Publico_da_faixa_do_provedor1 mascara -type SNIP
set rnat NAT_Link_Load_Balance -natIP IP_Publico_da_faixa_do_provedor1
add ns ip IP_Publico_da_faixa_do_provedor2 mascara -type SNIP
set rnat NAT_Link_Load_Balance -natIP IP_Publico_da_faixa_do_provedor2

Agora sim…Problema 1 resolvido!

O que mais temos? Bem, ainda na parte do tráfego de saída temos este desafio:

Problema 2: Algumas aplicações na Internet não permitem que um mesmo usuário venha de 2 IPs de origem diferentes. Isso acontece com certa frequência com Internet Banking e alguns sistemas do governo brasileiro. O acesso inicial do usuário vai para um servidor e ao acessar uma área da aplicação, é redirecionado para outro servidor. Pela natureza do funcionamento do LLB, se é um outro servidor de destino, é possível que o tráfego saia por outro link e consequentemente com outro IP público de origem.

Mas vamos deixar esse para a parte 2 deste artigo ok?

Espero ter ajudado a esclarecer a configuração de LLB até aqui.

Dúvidas e comentários são bem vindos!

Até a parte 2…