A forma mais resiliente de clusters DNS (privados)?

3

Estou trabalhando em uma configuração com dois datacenters vinculados por um MAN (em ponte) e tudo é duplicado entre eles, no modo failover com o RedHat Cluster, o DRBD e esse tipo de coisa.

Eu tenho um servidor DNS para cada local, mas acontece que ter ambos em /etc/resolv.conf não ajuda muito; se um deles cair, o cliente aguarda 10 segundos ou mais na metade do tempo. Em outras palavras, ele está sendo usado para balanceamento de carga, não failover. Então eu configurei os dois servidores para usar um VIP com o ucarp (≈VRRP).

Existe uma maneira de ter meus dois servidores DNS funcionando e, por exemplo, responder ao mesmo IP, o tempo todo? Não é grande coisa se um teste NS receber duas respostas.

Existe uma maneira de fazer isso com Anycast / Multicast e assim por diante?

Edit: acontece que anycast não me faz bem no meu cenário, eu tenho apenas rotas estáticas, e a maior parte do tráfego é na verdade uma ponte.

O que seria interessante seria uma forma de ter dois servidores DNS respondendo a solicitações no mesmo IP, se possível.

    
por niXar 31.05.2009 / 11:37

11 respostas

5

O Anycast DNS permite que você configure um IP de resolução em todos os seus clientes; solicitações de clientes seriam encaminhadas para o servidor 'mais próximo' (de uma perspectiva de roteamento de rede).

Se você vinculou o anúncio do VIP anycast a uma verificação de saúde (por exemplo, solicitando o registro A para um domínio bem conhecido), um dos seus servidores falhará se sua rota for retirada. Uma vez que a rede reconverte, todas as solicitações serão encaminhadas para o outro dispositivo sem qualquer reconfiguração manual.

Em termos de implementação, isso pode ser feito por meio do uso de dispositivos de hardware (por exemplo, F5 Big IP, Citrix Netscaler) ou por meio de sua própria configuração. Você pode executar um daemon de roteamento (por exemplo, Quagga) em execução nos seus servidores DNS ou ter alguns scripts personalizados que fazem login nos seus roteadores para alterar o estado de cada VIP do anycast.

    
por 31.05.2009 / 11:44
6

Você pode minimizar os problemas definindo algumas opções no seu resolv.conf:

options rotate timeout:2

girar faz o resolvedor escolher um dos seus servidores de nomes aleatoriamente, em vez de usar o primeiro, a menos que expire. tempo limite: 2 reduz o tempo limite do DNS para dois segundos, em vez do valor padrão.

(NB: isto foi testado no Debian / Ubuntu, mas eu não acho que esta é uma mudança específica do Debian)

    
por 04.06.2009 / 13:48
3

Corrija o cliente - use um resolvedor melhor.

lwresd faz parte do Bind. Ele é executado como um serviço local. Você configura a libc para usá-la via /etc/nsswitch.conf, então usá-la é transparente para todos os programas, exceto estaticamente compilados.

O lwresd monitora o desempenho e a disponibilidade dos servidores de nome configurados (isso é o comportamento padrão do Bind). Se um host se tornar indisponível, o lwresd recuará de um servidor e enviará todas as consultas para outros servidores configurados. Como é executado localmente em cada host, normalmente deve enviar todas as consultas para o servidor mais próximo.

    
por 23.09.2009 / 08:16
2

Eu executo um cluster de DNS recursivo BGP anycast interno em dois Loadbalancers do Linux Virtual Server (IPVS) e funciona como um encanto.

A configuração básica é descrita aqui: ótimo: desculpe, novos usuários não podem adicionar hiperlinks ... (veja o link abaixo e depois)

O problema com o uso do VRRP para o IP de Serviço é que ele vagará entre seus dois servidores e, portanto, seu servidor de nomes precisará se ligar a ele rapidamente para poder responder às consultas no caso de um failover. Você poderia contornar isso usando o NAT, assim como na minha configuração de IPVS, mas eu recomendaria o balanceamento de carga com verificações de serviço ativas para que você saiba quando algo está errado.

Observe que, embora haja implementações de DNS que usam multicast (Apple Bonjour / mdns, por exemplo), elas geralmente não são adequadas para serviços DNS recursivos de alto volume ou dependentes e também são normalmente limitadas ao uso no mesmo domínio de colisão ou seja, LAN.

    
por 01.06.2009 / 22:41
2

A maneira burra simples:

Pergunte ao seu Linux para ser muito mais agressivo em servidores DNS no resolv.conf: tempo limite das opções: 0,1 rotação

Portanto, o tempo limite é rápido e gire para que ele use ambos para arredondar a carga, sem que nenhum VIP / VRRP / equipe gerencie, apenas 2 servidores de DNS fazendo seu trabalho ...

    
por 09.06.2009 / 22:57
1

O anycast é usado com freqüência para solucionar esse requisito. O DNS Anycast é o uso de políticas de roteamento e endereçamento para afetar o caminho mais eficiente entre uma única origem (Cliente DNS) e vários destinos geograficamente dispersos que "escutam" um serviço (DNS) dentro de um grupo receptor. Em Anycast, os mesmos endereços IP são usados para endereçar cada um dos destinos de escuta (servidores DNS, neste caso). O roteamento da camada 3 manipula dinamicamente o cálculo e a transmissão de pacotes de nossa origem (cliente DNS) para o destino mais apropriado (servidor DNS).

Por favor, visite www.netlinxinc.com para uma série completa de posts dedicados ao DNS Anycast. Lá você encontrará receitas de como configurar o Anycast DNS. A série cobriu Anycast DNS usando Static Routing, RIP, e eu vou postar receitas em OSPF e BGP em breve.

    
por 31.05.2009 / 18:53
0

Se for aceitável ter alguns segundos de falha de DNS antes da troca ocorrer, você poderá criar um script de shell simples para fazer isso. O pseudocódigo que não funciona segue:

#!/bin/sh
localns=192.168.0.1
remotens=192.168.0.2
currentns='cat /etc/resolv.conf | grep nameserver | awk '{print $2}''

while 1; do
    if ping -W1 -q -c3 -i0.5 $localns > /dev/null 2>&1; then
        # Local DNS is up
        [ $currentns != $localns ] || echo "nameserver $localns" > /etc/resolv.conf
        currentns=$localdns
    else;
        # Local DNS is down
        [ $currentns != $remotens ] || echo "nameserver $remotens" > /etc/resolv.conf
        currentns=$remotedns
    sleep 2 # Will detect failures in no more than 5 secs
    
por 31.05.2009 / 12:57
0

Se você estiver usando balanceadores de carga em qualquer lugar do seu site, poderá configurá-los para que o DNS seja um serviço virtual.

Meus Kemp Loadmaster 1500s podem ser configurados para executar round-robin com failover. Isso usaria a verificação do serviço para garantir que cada servidor DNS esteja ativo a cada poucos segundos e dividir o tráfego entre os dois servidores. Se um morre, ele sai do pool RR e somente o servidor "up" é consultado.

Você teria que apontar seu resolv.conf para o VIP no loadbalancer.

    
por 31.05.2009 / 13:33
0

Você quer que o DNS seja confiável. Adicionar uma enorme quantidade de complexidade à configuração causará um pesadelo absoluto quando algo quebrar.

Algumas das soluções propostas funcionam apenas quando os servidores DNS redundantes estão no mesmo local.

A questão fundamental é que o cliente DNS está quebrado conforme planejado. Ele não lembra quando um servidor estava inacessível e continua tentando se conectar ao mesmo servidor sem resposta.

O NIS lidou com esse problema fazendo com que o ypbind mantivesse o estado. Uma solução desajeitada, mas geralmente funciona.

A solução aqui é apoiar os fornecedores para implementar uma solução razoável para esse problema. Está ficando pior com o IPV6, já que os pedidos de AAAA estão aumentando o tempo gasto desperdiçado em tempos limite. Eu vi protocolos falharem (por exemplo, uma conexão sshd) porque eles gastaram muito tempo esperando por tempos limite de DNS devido a um único servidor DNS inacessível.

Nesse ínterim, como sugerido anteriormente, escreva um script que substitua resolv.conf por um que contenha apenas servidores de nomes válidos. Compartilhe este script com fornecedores para demonstrar a solução impura que você foi forçado a implementar.

Isto não foi seriamente testado, e assume um nslookup que analisa como o meu, e um grep que suporta "-q".

Execute isso fora do cron a cada 5 minutos ou mais.

Não estou sugerindo seriamente que alguém realmente use o cron e um script de shell para o gerenciamento crítico de failover; as surpresas de tratamento de erros são muito grandes. Esta é apenas uma prova de conceito.

Para testar isso de verdade, altere a linha "nameservers=" na parte superior, altere o resolv_conf na parte superior para /etc/resolv.conf não /tmp/resolv.conf e o cabeçalho padrão para o resolv.conf que contém example.com.

Você pode precisar reiniciar o nscd se você substituir o resolv.conf.

#!/bin/bash
# full list of nameservers
nameservers="127.0.0.1 192.168.0.1 192.168.1.1"

# resolv.conf filename, change to /etc/resolv.conf for production use
resolv_conf="/tmp/resolv.conf"

# for tracking during the test
failed_nameservers=""
good_nameservers=""

# test loop
for nameserver in $nameservers; do
    if nslookup localhost $nameserver | grep -q 'Address.*127\.0\.0\.1'; then
        good_nameservers="$good_nameservers $nameserver"
    else
        failed_nameservers="$failed_nameservers $nameserver"
    fi
done

# if none succeded, include them all
if [ -z "$good_nameservers" ]; then
    good_nameservers="$nameservers"
fi

# error reporting, consider writing to syslog
if [ -n "$failed_nameservers" ]; then
    echo warning: failed nameservers $failed_nameservers
fi

# create the temporary replacement resolv.conf
new_rc="$resolv_conf.new.$$"
echo domain example.com  > $new_rc
echo search example.com >> $new_rc
for nameserver in $good_nameservers; do
    echo nameserver $nameserver >> $new_rc
done

# don't deploy a corrupt resolv.conf
if ! grep -q nameserver $new_rc; then
    echo warning: sanity check on $new_rc failed, giving up
    exit 1
fi

# keep a backup
if [ -f $resolv_conf ]; then
    rm -f $resolv_conf.previous
    ln $resolv_conf $resolv_conf.previous
fi
# deploy the new one
mv $new_rc $resolv_conf
    
por 04.06.2009 / 07:31
0

Eu primeiro tentaria duplicar o seu VRRP, mas com um VIP adicional. Para cada VIP, alterne os nós principais e de backup.

DNS1 = vip1 primário, vip2 secundário DNS2 = vip2 primário, vip1 secundário

Em seguida, cada uma das máquinas do seu cliente terá os dois ips no resolvedor. Dessa forma, a carga é distribuída pelos servidores de nomes, mas se um deles cair, o outro apenas assume a carga adicional.

    
por 04.06.2009 / 19:37
0

Alguma chance de você ter balanceadores de carga nos dois locais? Se não você poderia homegrow com LVS.

Tenha um endereço de serviço de DNS em cada site que seja um VIP no balanceador de carga. Então ativa / passivo loadbalance cada VIP através dos dois servidores dns, favorecendo o local.

    
por 10.06.2009 / 06:41