[GTER] Balanceamento de carga - BIND 9

[Gerson Abdon Caldeira]

On Mar 31, 2005 1:39 AM, Rubens Kuhl Jr. <rubensk at gmail.com> wrote:
> >    Exato. Rodei, rodei, rodei e cheguei no LVS
> > (www.linuxvirtualserver.org). Nele dá pra você balancear pacotes UDP
> > (nem todas as soluções funcionam com ele). O problema é que do jeito
> 
> Qual a questão com UDP ? É stateless, me parece até mais simples. Veja
> que só o tráfego inbound ao cluster precisa ser balanceado; o tráfego
> de pergunta e resposta dos recursivos para o mundo deve ser feito em
> outro IP/porta que não seja do cluster, para que as respostas sejam
> dirigidas ao recursivo que fez as perguntas.
> 

   De fato eu acreditei também que não teria problemas. O que entendi
no código (humildemente) é que todas as conexões são colocadas em hash
numa tabela (tipo nat) para que então elas possam ser direcionadas
para outro IP de destino (Estação -> Diretora -> Real Server (#1, #2,
#3...). Eles puseram então estado nas conexões UDP. Eu imaginei o uso
em servidores de jogo, nos quais cada um teria sua própria instância
de jogo/sala/escore/time/etc e que é necessário que os pacotes sejam
enviados para aquele servidor enquando houver conexão (a única forma
de mudar isso é com timeout, óbviamente). O que fiz foi basicamente
não usar o hash, pois não quero "viciar" IP de origem em um servidor
só, nem gastar tempo de CPU (e memória) pra montar essa tabela.
   O modelo Direct Routing do LVS funciona da seguinte forma: uma
diretora terá o IP/porta do cluster e todas as trabalhadoras terão
também esse IP, mas numa interface "local". O truque aí é usar um
recurso do kernel que fará com que determinadas interfaces não
respondam à ARP Requests. Assim, poderia configurar o serviço com
aquele IP, que "geraria" pacotes com essa origem. Com o destino
definido, as respostas nem passam pelo diretor mais.
(http://www.linuxvirtualserver.org/VS-DRouting.html)
   Aproveitando, há como forçar o uso de um IP apenas para uso de
consultas recursivas no BIND 9?

> > que ele foi implementado, se muitas requisições forem feitas de um
> > host (em intervalo de tempo mínimo), o diretor (Director) só repassará
> > os pacotes para um servidor (Real Server). Resolvi esse "pequeno
> > problema" me metendo a fuçar no código do LVS no Kernel 2.6. Achei um
> > patch (ops - one-packet scheduling -, acho que de um dos autores. Tem
> > referência na página do projeto) e adaptei para o 2.6 (diacho, tive
> > que fazer praticamente outro porque mudou muuuita coisa).
> 
> Já submeteu de volta aos mantenedores ?
> 

Ainda não. Preciso saber mais aonde estou pisando, entende? Depois
disso, submeterei com o maior prazer.

> >    A performance dos "trabalhores", juntos, é fantástica. As perdas
> > mostraram-se, em testes simples (usando queryperf), muito pequenas.
> >    Outro grande problema que encontrei foi quanto às atualizações de
> > zona (imagina, o DNS é não-recursivo - zonas master e zonas slave - e
> > recursivo). Foi uma mistureba de script perl + rsync + ssh + rndc +
> > mecanismos de locking. Acho que consegui resolver isso de forma
> > simples. Tentei usar algum FS distribuido mas é impraticável tamanho
> > trabalho por tão pouca informação.
> 
> Me parece que vc tinha um DNS autoritativo com número de zonas
> suficientemente grande para justificar sincronismo automático da
> configuração e não apenas das zonas em si.

Não, foi o tal "legado" que fez com que o DNS fosse autoritário (pra
zonas) e recursivo para usuários. É a situação não recomendada e, de
certo modo, perigosa. Adiante, acredito que isso terá que ser
modificado pois, na iminência de algum furo de segurança, as zonas
poderia ser comprometidas, visto que é um DNS muito "público", já que
é utilizado por estações diretamente (além dos outros DNSses). Você
saberia me dizer o que exatamente eu deveria ter medo nesse cenário?
Só ouço dizer que "não é bom". Ainda assim, as consultas recursivas
ficam pesadas para uma máquina só.

> Esse é um problema que seria melhor resolvido com algo baseado em
> banco de dados (tipo PowerDNS com MySQL)... mas que em geral não
> poderia ser também recursivo.
> 

Sim, esse seria o objetivo final ideal. Uma base "distribuível" por
natureza, mas que possa oferecer o cache em memória e persistência
usando LDAP. Confesso que não li muito sobre e não sei como são as
implementações usando BIND 9. Acho que existem dois cenários: ou cada
requisição gera uma consulta à base - que, em princípio, deve custosa
pra dedéu -, ou, ao acontecer alguma modificação de informações de
zona (transfer, update ou à mão), o motor atualizará em memória as
informações. A última parece mais sensata.

> >
> > > Vale lembrar que antes de colocar um MAC multicast/broadcast numa rede
> > > switched, é bom verificar se é possível limitar esse flood às portas
> > > do cluster (configuração manual ou IGMP), ou deixar essas portas numa
> > > VLAN separada.
> > >
> >
> >    Essa parte eu não entendi muito bem. Poderia me ajudar a entender?
> > A gente utilizou o "Direct Routing" pra não criar um gargalo no
> > director.
> 
> No mecanismo de balanceamento ativo-ativo distribuído, as máquinas
> todas tem um mesmo IP e um mesmo endereço MAC. Para que elas recebam
> sempre todos os pacotes e possam então selecionar tráfego, algum
> desses cenários acaba acontecendo:
> 1) A conexão é por hub, que naturalmente faz broadcast para todas as portas

Hmm... tráfego "n-plicado". Imagina só...

> 2) A conexão é por switch, o endereço MAC é multicast e foi
> configurado hard-coded nas portas das máquinas do cluster, ou
> aprendido por IGMP. Apenas as máquinas do cluster recebem esses
> pacotes.

... também "n-plicado", mas só pra determinadas portas...

> 3) A conexão é por switch, o endereço MAC é broadcast e todas as
> máquinas na mesma VLAN recebem todos os pacotes.
> 

... também pinta aí a geração de muitos pacotes.

A solução do LVS é bem interessante, pois os pacotes enviados para o
cluster serão recebidos apenas pelo diretor (é o MAC dele que ficará
na tabela ARP) e então os repassará para os servidores reais apenas
modificando o endereço MAC. É algo simples que não precise de nenhum
protocolo, nem "hardware-muito-caro" e que ofereça redundância e
balanceamento.

Gerson.