Pisco de peito vermelho redondo ponderado via TTL - possível?

Atualmente, uso o round robin do DNS para balanceamento de carga, o que funciona muito bem. Os registros ficam assim (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 alternam os endereços aleatoriamente ou sempre os alternam. Alguns apenas propagam a primeira entrada, outros tentam determinar qual é o melhor (regionalmente próximo) observando o endereço IP.

No entanto, se a base de usuários for grande o suficiente (se espalha por vários ISPs etc.), ela se equilibra muito bem. As discrepâncias do servidor carregado do mais alto para o mais baixo quase nunca ultrapassam 15%.

No entanto, agora eu tenho o problema de introduzir mais servidores nos sistemas e que 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 10 Gbps.

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

Eu adicionei servidores duas vezes anteriormente 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 o servidor A 240 segundos TTL e o servidor B apenas 120 segundos (o que é quase o mínimo para usar o round robin, como muitos servidores DNS configurados para 120 se um TTL inferior for especificado (pelo que ouvi dizer)). Eu acho que algo assim deve 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 fica bastante complicado de prever e com certeza não funcionará dessa maneira na prática. Mas definitivamente deve ter um efeito na 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 pesar perfeitamente, tudo bem, mas deve seguir na direção certa.

Eu 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, economizando recursos - o que, na minha opinião, é o ponto principal do balanceamento de carga DNS versus balanceadores de carga de hardware.

Minha pergunta agora é: Existem práticas recomendadas / métodos / regras práticas para ponderar a distribuição de rodízios 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 suportar. Então, preciso de uma solução de balanceamento que distribua a largura de banda para vários servidores. Existem métodos alternativos para usar o DNS? É claro que posso usar um balanceador de carga com canal de fibra etc., mas os custos são ridículos e também aumentam apenas a largura do gargalo e não o eliminam. A única coisa em que consigo pensar são nos endereços IP anycast (é anycast ou multicast?), Mas não tenho os meios para configurar esse sistema.

Primeiro, concordo completamente com o @Alnitak que o DNS não foi projetado para esse tipo de coisa, e a melhor prática é não (ab) usar o DNS como um balanceador de carga ruim.

Minha pergunta agora é ... existem melhores prectices / methos / regras práticas para ponderar a distribuição de rodízios usando o atributo TTL dos registros DNS?

Para responder à premissa da pergunta, a abordagem usada para executar round robin ponderado com basix usando DNS é:

• Ajuste a ocorrência relativa de registros nas respostas DNS autoritativas. Ou seja, se Server Ahouver 1/3 de tráfego e Server B2/3, 1/3 das respostas DNS autoritativas aos proxies DNS conterão apenas A o IP e 2/3 das respostas apenas B. (Se 2 ou mais servidores compartilharem o mesmo 'peso', eles poderão ser agrupados em uma resposta).
• Mantenha um TTL DNS baixo, para que a carga não balanceada seja nivelada relativamente rapidamente. Como os proxies DNS a jusante têm um número muito desigual de clientes por trás deles, convém reorganizar os registros com frequência.

O serviço DNS da Route 53 da Amazon usa esse método .

A quantidade de largura de banda (não solicitações) excede o que um único servidor com Ethernet pode suportar. Então, preciso de uma solução de balanceamento que distribua a largura de banda para vários servidores.

Direita. Pelo que entendi, você tem algum tipo de serviço de downloads / distribuição de vídeo / download de arquivos grandes 'barato', em que a taxa de bits total do serviço excede 1 GBit.

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

• Rodízio de DNS para duas ou mais instâncias do balanceador de carga no nível TCP / IP ou HTTP.
• Cada instância do balanceador de carga está altamente disponível (2 balanceadores de carga idênticos cooperando para manter sempre um endereço IP).
• Cada instância do balanceador de carga usando round robin ponderado ou manipulação de conexão aleatória ponderada com os servidores back-end.

Esse tipo de configuração pode ser criado com software de código aberto ou com dispositivos criados por finalidade de muitos fornecedores. A tag de balanceamento de carga aqui é um excelente ponto de partida, ou você pode contratar administradores de sistemas que fizeram isso antes para consultar você ...

Minha pergunta agora é ... existem melhores prectices / methos / regras práticas para ponderar a distribuição de rodízios usando o atributo TTL dos registros DNS?

Sim, a melhor prática é não fazê-lo !

Por favor, repita depois de mim

• DNS não é para balanceamento de carga
• 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 equilíbrio subsequente que você obtiver é por sorte, não por design.

Dê uma olhada no PowerDNS . Permite criar um back-end de tubo personalizado. Modifiquei um exemplo de back-end DNS do balanceador de carga escrito em perl para usar o módulo Algorithm :: ConsistentHash :: Ketama. Isso permite definir pesos arbitrários da seguinte forma:

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 um 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);

Adicionei um cname do domínio de nível superior desejado a um subdomínio que chamo gslb, ou Global Server Load Balancing. A partir daí, invoco esse servidor DNS personalizado e envio registros A de acordo com meus pesos desejados.

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

Eu recomendo a leitura de servidores DNS alternativos, de Jan-Piet Mens. Ele tem muitas boas idéias e código de exemplo.

Eu também recomendo abandonar a modulação TTL. Você já está muito longe e adicionar outro kludge na parte superior tornará a solução de problemas e a documentação extremamente difíceis.

Você pode usar o PowerDNS para executar round robin ponderado, embora a distribuição de carga de maneira tão desequilibrada (100: 1?) Possa ficar muito interessante, pelo menos com os algoritmos que usei na minha solução, em que cada entrada RR tem um peso associado a ela , entre 1 e 100, e um valor aleatório é usado para incluir ou excluir registros.

Aqui está um artigo que escrevi sobre o uso do back-end do MySQL no PowerDNS para fazer o DNS RR ponderado: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

O RIPienaar também possui alguns exemplos baseados em Ruby (usando o back-end do tubo PowerDNS): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

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