Quantcast
Channel: Conceito Negócios Inteligência em Tecnologia LTDA » CISCO
Viewing all articles
Browse latest Browse all 4

Balanceamento de carga para links redundantes de internet

0
0
balanceamento de carga de links redundantes

Balanceamento de carga em links internet redundantes

Este artigo tem o objetivo de elucidar com um exemplo prático um dos maiores fantasmas na lista de preocupações dos gestores de TI quando se trata de continuidade de negócios, que é a estratégia de manter dois ou mais links de acesso à internet em regime de redundância, mas trabalhando em conjunto quando ambos estão funcionando.

Esta estratégia permite que todo o tráfego de conexões à internet seja distribuído entre os links existentes, oferecendo o benefício de um aumento de banda, que não seria possível em um ambiente onde a estratégia de redundância fosse manter um link ativo e outro em stand by.

Neste artigo você será apresentado a uma maneira inteligente e prática de implementar o balanceamento de carga, utilizando uma ferramenta open source (e por tanto gratuita), o que torna sua utilização financeiramente atraente. Esta ferramenta é o iptables, um módulo nativo na maioria das distribuições linux.

Para acompanhar este artigo, um pré-requisito é que você conheça um pouco sobre firewall, nat (network address translation) e roteamento IPv4. Se você não domina estes assuntos (ou se não conhece pelo menos os seus fundamentos básicos) é conveniente interromper a leitura, buscar no Google um pouco de informação e voltar aqui com um mínimo de introdução técnica, do contrário a compreensão deste artigo poderá se tornar um pouco complicada.

Apesar de abordar o assunto de uma maneira prática e através de um estudo de caso, este artigo não é uma receita de bolo. Quando você for implementar a sua redundância de links internet é conveniente avaliar todos os prós e contras de implementar uma solução semelhante, bem como todas as customizações que o seu ambiente pode precisar.

Desde já, sugiro que entre em contato com a equipe da Conceito Negócios para pedir uma proposta de consultoria, caso este cenário seja muito novo para você.

Vamos à prática!

O cenário que estudaremos neste artigo utiliza basicamente duas ferramentas principais, ambas open source: o iptables e o iproute2.

O endereçamento das redes IP foram propositadamente substituídos neste artigo, visando evitar publicação indevida de informações sensíveis. Contudo, todos os exemplos aqui utilizam endereçamentos aplicáveis, e com um mínimo de conhecimento em redes IP é possível adaptar este exemplo à sua realidade, conforme os CIDR aplicáveis na sua empresa.

Rede interna: 172.16.0.0 / 255.240.0.0 (12 bits)
Sub-redes internas: 172.16.0.0/255.255.0.0 (16 bits) até 172.31.0.0/255.255.0.0 (16 bits), distribuídas entre as filiais
VLans por Filial: 172.X.1.0/255.255.255.0 (24 bits) até 172.X.254.0/255.255.255.0 (24 bits), distribuídas por andar/departamento.
Rede Operadora A: 200.245.251.16/255.255.255.240 (28 bits)
Rede Operadora B:187.14.57.192/255.255.255.248 (29 bits)

No caso de ambas as operadoras trata-se de link dedicado com uma faixa de endereços IP públicos disponíveis. Este cenário favorece a implementação de DMZ, o que pode ser feito com nat para uma faixa da rede interna, nat IP por IP ou nat real-para-real. Futuramente escreverei um artigo sobre isso.

O ponto em questão aqui é que mesmo que você utiliza links assíncronos de banda-larga o exemplo pode ser adaptado. Você obviamente precisará preparar os seus scripts para conexão, caso utilize PPPoE ou DHCP (é possível utilizar até mesmo um acesso discado como um terceiro método de failover – assunto para outro artigo).

No nosso exemplo, a interface eth0 é a interface interna, onde está o switch do datacenter (ou o roteador de acesso das filiais, caso você esteja implementando um ponto concentrador). Os links das operadoras estão nas interfaces eth1 e eth2.

Então, o primeiro passo é editar o arquivo /etc/network/interfaces para que ambas as interfaces externas sejam inicalizadas. Note que no bloco inserido ao /etc/network/interfaces as rotas default são removidas. A única rota que é preservada é a rota das redes internas.

#--/etc/network/interfaces--
#Bloco para subir a interface interna
auto eth0
iface eth0 inet static
    address    172.17.1.2
    netmask    255.255.255.0
    up /sbin/route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.17.1.3
    up /sbin/route del default
    down /sbin/route del -net 172.16.0.0 netmask 255.240.0.0
    down /sbin/route del -net 172.17.1.0 netmask 255.255.255.0

#bloco para subir a interface da operadora A
auto eth1
iface eth1 inet static
    address    200.245.251.18
    netmask    255.255.255.240
    up /sbin/route del default
    down /sbin/route del -net 200.245.251.16 netmask 255.255.255.240

#bloco para subir a interface da operadora B
auto eth2
iface eth2 inet static
    address    187.14.57.194
    netmask    255.255.255.248
    up /sbin/route del default
    down /sbin/route del -net 187.14.57.192 netmask 255.255.255.248

Você certamente reparou que em todas as interfaces é inserido um comando para remover a rota para a qual ela aponta no caso de a interface ser desabilitada (ifdown ou ifconfig ethX down). Isso é necessário pois o nosso balanceamento de carga será baseado no princípio de “next hop”, e cada interface terá o seu “next hop” distinto.

Você provavelmente reparou também que eu pulei o primeiro endereço disponível em cada rede, inclusive na rede interna. Nas redes externas fica fácil entender – este será o endereço do próximo salto (next hop), ou seja, o equipamento da operadora.

Já na rede interna, o “next hop” é o terceiro endereço da subnet, o que quer dizer que eu realmente guardei o primeiro endereço válido para algo diferente. Você vai entender em instantes – já estamos chegando lá.

Agora vem a parte interessante do balanceamento de carga, que é o redirecionamento de tráfego para o próximo salto, ou “next hop”.

Nós faremos isso criando um endereço interno virtual, para fins de nat. No exemplo, este endereço virtual é justamente o primeiro endereço da subnet interna – o 172.17.1.1, que será o gateway default para todos os equipamentos nesta rede (ou opcionalmente você pode utilizar um protocolo de roteamento entre dispositivos, como o RIP/RIP2, o OSPF ou o EIGRP).

No nosso exemplo, nós utilizaremos uma regra de firewall que faz um nat balanceado do endereço 172.17.1.1 para os endereços do próximo salto de cada uma das operadoras, ou seja, 200.245.251.17 e 187.14.57.193.

Mas antes de seguir, existe mais uma linha que precisamos inserir no /etc/network/interfaces, pois para garantir que o endereço virtual seja mapeado para o nosso iptables na tabela arp dos outros equipamentos, precisamos instanciá-lo.

#Bloco para subir a interface virtual
auto eth0:0
iface eth0:0 inet static
    address 172.17.1.1
    netmask 255.255.255.0

Você, com um pouco mais de conhecimento técnico, pode alegar que este cuidado é desnecessário, já que estaremos inserindo este endereço na tabela nat do firewall. Isso estaria certo se você pudesse garantir que este endereço fosse sempre direcionado para arp broadcast em todos os equipamentos, ou que o equipamento de camada 2 fosse um hub ao invés de um switch (ou um switch em modo promíscuo, o que não faz o menor sentido em um ambiente seguro).

Entretanto, como contamos que o equipamento de camada 2 faça o papel de segmentar os domínios de colisão, precisamos ter em mente que os outros equipamentos na rede nem sempre são tão inteligentes para renovar arp sempre que necessário. Fora isso, respostas recebidas pela interface interna (que usaremos basicamente para gerência) poderão ser interpretadas como IP Spoofing por alguns equipamentos mais seguros (em modo “panic”).

Portanto, a menos que você realmente tenha motivos justificáveis para não criar a interface virtual, a minha sugestão é de que crie, pois vai evitar muito trabalho na hora de aplicar um troubleshoot de rede.

O próximo passo é criar efetivamente o nat.

Para isso, iremos inserir uma linha no script de firewall, logo no começo da tabela de nat. Nesta etapa eu presumo que suas regras de firewall já estão definidas, que a sua flag de IPv4 Forwarding já está configurada e que seu firewall já esteja com a funcionalidade básica. Como o propósito deste artigo não é tratar regras de firewall em si, sugiro que pesquise no Google caso não tenha esta questão bem definida.

O que vamos adicionar no script de firewall é este bloco:

#--- Bloco a ser adicionado no seu script de firewall ---

#-- Esta linha faz com que cada conexao ja estabelecida seja mantida no mesmo link,
# evitando problemas com sites que dependam do IP de origem para funcionar,
# como sites de bancos principalmente.
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

#-- As linhas seguintes fazem com que o trafego para a internet para os links de
# cada operadora sejam "mascarados" (traduzidos para o nat) com o endereco externo
# da respectiva interface.
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

#-- Agora vem as linhas que fazem o milagre do balanceamento de carga.
# Estas linhas fazem o nat um-para-varios da interface virtual para o
# next hop de cada operadora.
iptables -t nat -A PREROUTING -d 172.17.1.1 -m state --state NEW -m nth --counter 0 --every 2 --packet 0 -j DNAT --to-destination 200.245.251.17
iptables -t nat -A PREROUTING -d 172.17.1.1 -m state --state NEW -m nth --counter 0 --every 2 --packet 1 -j DNAT --to-destination 187.14.57.194

Como você notou, o grande segredo do balanceamento é marcar os pacotes com estado “NEW” – ou seja, uma conexao nova – contando a cada 2 pacotes, dirigindo-os por nat para o próximo salto de uma operadora ou de outra.

O passo seguinte é apontar o endereço 172.17.1.1 como gateway default (ou como próximo salto, conforme o caso) nos equipamentos da subnet.

Claro, existem formas muito mais sofisticadas de marcar e distribuir os pacotes, não apenas por duas operadoras, mas por várias mais. Este estudo de caso contém apenas trechos do script implementado, mas aqui estão as partes essenciais para que você entenda o processo e consiga elaborar uma solução adequada ao seu cenário.

Mais uma vez, sempre que precisar de um balanceamento de carga com um projeto elaborado especificamente para o seu caso e tendo como cenário a rede real da sua empresa, conte com a equipe da Conceito Negócios.

Se precisar de ajuda ou de consultoria técnica para implementar uma solução semelhante a esta no seu ambiente, envie-nos um e-mail.

Sobre os projetos de balanceamento de carga da Conceito Negócios:

A Conceito Negócios oferece projetos de balanceamento de carga de links internet sob medida para cada empresa, com suas particularidades de rede, de perfil de acesso à internet, de velocidades de link e de priorização de tráfego.

O telefone de contato para orçamentos e propostas comerciais é (11) 4063-6190, e o endereço de e-mail é contatos@conceitonegocios.com.


Viewing all articles
Browse latest Browse all 4

Latest Images

Trending Articles



Latest Images