Round Robins ponderados via TTL - possível?

9

Atualmente, uso round robin de DNS para balanceamento de carga, o que funciona muito bem. Os registros se parecem com isso (eu tenho um TTL de 120 segundos)

;; ANSWER SECTION:
orion.2x.to.        116 IN  A   80.237.201.41
orion.2x.to.        116 IN  A   87.230.54.12
orion.2x.to.        116 IN  A   87.230.100.10
orion.2x.to.        116 IN  A   87.230.51.65

Aprendi que nem todo ISP / dispositivo trata essa resposta da mesma maneira. Por exemplo, alguns servidores DNS giram os endereços aleatoriamente ou sempre os percorrem. Alguns apenas propagam a primeira entrada, outros tentam determinar qual é a melhor (regionalmente próxima) olhando o endereço IP.

No entanto, se a base de usuários for grande o suficiente (distribuída por vários ISPs, etc.), ela será bem equilibrada. As discrepâncias do maior para o menor servidor carregado dificilmente excedem 15%.

No entanto, agora tenho o problema de introduzir mais servidores nos sistemas e nem todos têm as mesmas capacidades.

Atualmente, tenho apenas servidores de 1 Gbps, mas também quero trabalhar com servidores de 100 Mbps e também de 10 Gbps.

Então, o que eu quero é apresentar um servidor com 10 Gbps com peso de 100, um servidor de 1 Gbps com peso de 10 e um servidor de 100 Mbps com peso de 1.

Eu adicionei servidores anteriormente duas vezes para trazer mais tráfego para eles (o que funcionou bem - a largura de banda quase dobrou). Mas adicionar um servidor de 10 Gbps 100 vezes ao DNS é um pouco ridículo.

Então, pensei em usar o TTL.

Se eu der ao servidor A 240 segundos TTL e servidor B apenas 120 segundos (que é aproximadamente o mínimo para usar round robin, como muitos servidores DNS configurados para 120 se um TTL menor for especificado (então eu ouvi )). Acho que algo assim deveria ocorrer em um cenário ideal:

First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds

Second 120 seconds
50% of requests still  have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds

Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B  (from the 50% of Server A  that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec

Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...

Como você pode ver, isso é bastante complicado de prever e, com certeza, não funcionará assim na prática. Mas definitivamente deve ter um efeito sobre a distribuição!

Eu sei que o round robin ponderado existe e é apenas controlado pelo servidor raiz. Ele apenas percorre os registros DNS ao responder e retorna registros DNS com uma probabilidade definida que corresponde à ponderação. Meu servidor DNS não suporta isso e meus requisitos não são tão precisos. Se não pesa perfeitamente, tudo bem, mas deve ir na direção certa.

Acho que usar o campo TTL poderia ser uma solução mais elegante e fácil - e não exige um servidor DNS que controle isso dinamicamente, o que economiza recursos - que, na minha opinião, é o ponto inteiro do balanceamento de carga DNS versus hardware balanceadores de carga.

A minha pergunta agora é: Existe alguma melhor prática / método / regra para ponderar a distribuição round-robin usando o atributo TTL dos registros DNS?

Editar:

O sistema é um sistema de servidor proxy de encaminhamento. A quantidade de largura de banda (não solicitações) excede o que um único servidor com Ethernet pode manipular. Então eu preciso de uma solução de balanceamento que distribua a largura de banda para vários servidores. Existem métodos alternativos do que usar o DNS? Claro que eu posso usar um balanceador de carga com canal de fibra etc, mas os custos são ridículos e também aumenta apenas a largura do gargalo e não o elimina. A única coisa em que consigo pensar são os endereços IP anycast (é anycast ou multicast?), Mas não tenho meios para configurar tal sistema.

    
por The Shurrican 07.02.2012 / 16:11

5 respostas

2
Primeiro, concordo completamente com o @Alnitak que o DNS não é projetado para esse tipo de coisa, e a melhor prática é não usar o DNS como balanceador de carga de um homem pobre.

My question now is... are there any best prectices / methos / rules of thumb to weight round robin distribution using the TTL attribute of DNS records?

Para responder sobre a premissa da questão, a abordagem usada para realizar o round robin ponderado basix usando o DNS é:

  • Ajusta a ocorrência relativa de registros em respostas DNS autoritativas. Ou seja se Server A tiver 1/3 do tráfego e Server B tiver 2/3, então 1/3 das respostas DNS autoritativas para os proxies DNS conterão somente A do IP e 2/3 das respostas apenas do IP de B . (Se dois ou mais servidores compartilham o mesmo 'peso', eles podem ser agrupados em uma resposta).
  • Mantenha um TTL de DNS baixo para que a carga não balanceada seja nivelada de forma relativamente rápida. Como os proxies DNS downstream têm números muito baixos de clientes por trás deles, você deve reorganizar os registros com frequência.

O serviço DNS do Route 53 usa este método .

The amount of Bandwidth (not requests) exceeds what one single server with ethernet can handle. So I need a balancing solution that distributes the bandwidth to several servers.

Então, como eu entendo isso, você tem algum tipo de serviço de downloads / distribuição de vídeo / download de arquivos grandes, em que a taxa de bits total do serviço excede 1 GBit.

Sem saber as especificidades exatas do seu serviço e o layout do servidor, é difícil ser preciso. Mas uma solução comum neste caso é:

  • DNS round robin para duas ou mais instâncias do balanceador de carga de nível TCP / IP ou HTTP.
  • Cada instância do balanceador de carga é altamente disponível (dois balanceadores de carga idênticos que cooperam para manter um endereço IP sempre ativo).
  • Cada instância do balanceador de carga usando round robin ponderado ou manipulação de conexão aleatória ponderada para os servidores de backend.

Esse tipo de configuração pode ser criado com software de código aberto ou com appliances criados por vários fabricantes. A tag de balanceamento de carga aqui é um ótimo ponto de partida, ou você pode contratar administradores de sistema quem já fez isso antes de consultar para você ...

    
por 09.02.2012 / 04:06
4

My question now is... are there any best prectices / methos / rules of thumb to weight round robin distribution using the TTL attribute of DNS records?

Sim, a prática recomendada é não faça isso !!

Por favor, repita depois de mim

  • DNS não é para balanceamento de carga
  • o DNS não fornece resiliência
  • O DNS não fornece recursos de failover

DNS é para mapear um nome para um ou mais endereços IP . Qualquer balanceamento subsequente que você obtiver é por sorte, não por design.

    
por 07.02.2012 / 17:26
2

Dê uma olhada no PowerDNS . Ele permite que você crie um back-end de pipe personalizado. Eu modifiquei um exemplo de backend de DNS com balanceador de carga escrito em perl para usar o módulo Algorithm :: ConsistentHash :: Ketama. Isso me permite definir pesos arbitrários assim:

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

E outro:

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

Eu adicionei um cname do meu domínio de nível superior desejado a um subdoman que chamo de gslb ou Global Server Load Balancing. De lá, eu invoco esse servidor DNS personalizado e envio registros A de acordo com meus pesos desejados.

Funciona como um campeão. O hash ketama tem a propriedade nice de interrupção mínima na configuração existente à medida que você adiciona servidores ou ajusta pesos.

Eu recomendo ler Servidores DNS Alternativos, por Jan-Piet Mens. Ele tem muitas boas ideias e códigos de exemplo.

Eu também recomendaria o abandono da modulação TTL. Você já está indo muito longe e adicionar outro kludge no topo dificultará a resolução de problemas e a documentação.

    
por 09.02.2012 / 05:17
1

Você pode usar o PowerDNS para realizar round robin ponderado, embora a distribuição de carga de maneira desequilibrada (100: 1?) possa ser muito interessante, pelo menos com os algoritmos usados na minha solução, onde cada entrada RR tem um peso associado a ele, entre 1-100, e um valor aleatório é usado para incluir ou excluir registros.

Aqui está um artigo que escrevi sobre o uso do backend do MySQL no PowerDNS para fazer DNS RR ponderado: link

O RIPienaar também tem alguns exemplos baseados em Ruby (usando o backend de pipe do PowerDNS): link

    
por 12.04.2012 / 18:45
1

Para lidar com esse tipo de configuração, você precisa analisar uma solução real de balanceamento de carga. Leia o Servidor Virtual Linux e o HAProxy . Você obtém o benefício adicional de os servidores serem automaticamente removidos do pool se eles falharem e os efeitos forem muito mais facilmente compreendidos. A ponderação é simplesmente uma configuração a ser ajustada.

    
por 07.02.2012 / 17:47