Como 8.8.8.8 é mantido * sempre * vivo?

Eu sei como você pode gerenciar a redundância do datacenter se houver um servidor DNS ativo que possa apontar para qualquer site de trabalho da sua empresa - há VRRP, multi WAN etc. etc. Mas como os próprios servidores DNS são mantidos online? É o primeiro sucesso quando alguém se conecta ao serviço e ele não pode realmente ser provisionado. Quero dizer, por exemplo 8.8.8.8ou 8.8.4.4. Não me lembro de eles terem caído. Sempre. Como os ISPs conseguem manter esses IPs sempre online?

Eu sei que é provavelmente uma pergunta muito ampla, mas eu gostaria de ouvir apenas nomes de protocolos / técnicas que podem ser usados ​​para isso. Eu posso ler detalhes sobre eles sozinho.

Primeiro de tudo, o VRRP não depende de DNS de forma alguma. Para redundância em um único site, você pode executar servidores DNS em um endereço VRRP compartilhado.

Mas, como outros mencionaram nos comentários, os serviços também usam o roteamento anycast , o que significa essencialmente que o mesmo endereço IP existe em vários lugares do mundo. Quando um site inteiro fica inoperante, as rotas em todo o mundo são recalculadas para que seus pacotes acabem indo para outro site em funcionamento.

Um exemplo melhor do que o DNS público do Google seria a raiz servidores DNS - aqueles que servem os .ponteiros zona e segure para com, org, eue assim por diante -, porque eles têm um mapa de todas as instâncias dos endereços lógicos 13. O "L" da ICANN é exibido em 160 sites diferentes!

Observe que o anycast não tem nada a ver com round-robins baseados em DNS (onde o mesmo nome tem vários endereços). Anycast é feito essencialmente mentindo para o protocolo de roteamento.

A Internet usa o BGP para trocar informações de roteamento entre organizações.

BGP suporta inerentemente a seleção do melhor de várias rotas para a mesma rede, com base em vários critérios. Por exemplo, o mesmo cliente pode ter uplinks redundantes para o mesmo ISP (anunciando duas rotas que diferem apenas em peso / preferência). Ou o cliente pode ter uplinks através de vários ISPs, e todos selecionarão sua rota preferida (principalmente o caminho AS mais curto) - essa é a essência da multi-WAN "verdadeira".

Multihoming

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter--+            │
             ¦    │             ¦--DNSserver │
client 2 ---ISP---│--BGProuter--+            │
                  └──────────────────────────┘

No entanto, o BGP apenas direciona o tráfego para as portas de entrada, mas não se importa com o que acontece além disso. Portanto, se você configurar internamente as duas rotas para o mesmo servidor, obterá o multihoming. Mas se cada "entrada" leva a um servidor diferente (configurado para o mesmo IP), você obtém o anycast.

Anycast... kind of?

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    │                          │
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

Importante, isso também significa que o BGP não se importa se o AS não é contíguo. Para obter redundância em todo o mundo, basta anunciar a mesma rede a partir de vários locais físicos - se você conectar esses locais (para que eles direcionem essa rede para um local), você terá o multihoming; se são ilhas, você obtém anycast.

Anycast

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    └──────────────────────────┘
             ¦
             ¦    ┌────────[AS 65535]────────┐
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

(Na verdade, ele nem precisa ser o mesmo AS - por exemplo, os relés 6to4 são executados por várias organizações independentes, cada uma anunciando seu próprio caminho 192.88.99.0/24.)

Ressalvas:

• O Anycast fornece redundância, mas não balanceamento de carga. Depois que o BGP converge, cada roteador escolhe uma única rota preferida (ou ocasionalmente algumas) e continua a usá-la até que a rede mude.

• No entanto, você não pode prever quanto tempo as rotas permanecerão estáveis; portanto, qualquer serviço de transmissão de estado pode ser complicado. O DNS se livra disso devido ao estado sem estado e ao uso principalmente de UDP (o EDNS reduziu a necessidade de conexões TCP).

• Deve haver coordenação entre o serviço real e o roteador BGP, para que a rota seja retirada se o serviço travar.

Veja também "História do 4.2.2.2. Qual é a história?" na lista de discussão NANOG: postagem 1 , publicação 2 .

Uma maneira de conseguir isso é usar balanceadores do lado do servidor . Quando você se conecta ao gateway no IP 8.8.8.8, ele distribui a solicitação para um servidor gratuito dentro do sistema. Como resultado, quando um servidor morre, ele não desativa todo o sistema.

Para serviços de Internet, o balanceador de carga no servidor geralmente é um programa de software que está escutando na porta em que clientes externos se conectam para acessar serviços. O balanceador de carga encaminha solicitações para um dos servidores "back-end", que geralmente responde ao balanceador de carga. Isso permite que o balanceador de carga responda ao cliente sem que ele saiba sobre a separação interna de funções. Isso também impede que os clientes entrem em contato diretamente com os servidores back-end, o que pode trazer benefícios de segurança ocultando a estrutura da rede interna e impedindo ataques à pilha de rede do kernel ou serviços não relacionados em execução em outras portas.

Alguns balanceadores de carga fornecem um mecanismo para fazer algo especial no caso de todos os servidores de back-end estarem indisponíveis. Isso pode incluir o encaminhamento para um balanceador de carga de backup ou a exibição de uma mensagem sobre a interrupção.

Também é importante que o próprio balanceador de carga não se torne um ponto único de falha. Geralmente, os balanceadores de carga são implementados em pares de alta disponibilidade, que também podem replicar dados de persistência da sessão, se exigidos pelo aplicativo específico. [5]