Arquiteturas de Alta Disponibilidade
Introdução
Esta seção é voltada para Engenheiros de Rede e Implementadores que precisam de uma solução de Alta Disponibilidade em nível de rede.
Para alcançar alta disponibilidade ou HA (High Availability), em geral, existem várias tecnologias. No caso do PDNS, a tecnologia mais efetiva em termos de HA na Internet é o ANYCAST.
Aviso
Neste seção, discutimos apenas a arquitetura dos Resolvers e Autoritativos, independentemente de a aplicação pdns-app estar na nuvem da Planisys ou On-Premise.
No gráfico a seguir, vemos um exemplo de HA para Resolvers, a partir de três Datacenters diferentes, que podem estar localizados em qualquer parte do mundo.
Para isso, precisamos ter pelo menos uma rede /24, que possa ser anunciada no backbone da Internet por meio de BGP em todos os Datacenters da rede Anycast.
Aviso
Para implementar serviços com HA anycast, eles precisam ser idênticos, replicados ou executando as mesmas transações através da Internet ou de uma Intranet entre Datacenters. Cada IP utilizado dessa rede /24 deve estar presente em TODOS os Datacenters para o MESMO serviço. Quando uma rede é reservada para ANYCAST, não é possível utilizar IPs isoladas dessa rede em apenas um dos Datacenters.
Nota
Neste seção, não utilizamos o termo Cluster, pois a clusterização está implícita em todas essas Arquiteturas especiais de HA.
Anycast para Resolvers
Por exemplo, se anunciarmos a rede 179.63.249.0/24 de 3 pontos geográficos diferentes (como Planisys em Miami, Amsterdã e São Francisco), devemos ativar as mesmas IPs e serviços nos 3 Datacenters.
No caso dos DNS Resolvers, é uma tarefa simples, pois será necessário instalar o mesmo servidor DNS Resolver com o mesmo IP nos 3 Datacenters (por exemplo, 179.63.249.221). Assim, um cliente que utilize nosso serviço de resolução de nomes nessa IP poderá acessá-lo mesmo que dois dos três Datacenters ou Roteadores estejam fora do ar.
Um serviço de Internet local-loop, ADSL ou Cablemodem de um cliente final em um computador, laptop, celular ou tablet que queira acessar nossa IP 179.63.249.221 para resolver um nome poderá fazê-lo mesmo que dois dos três Datacenters estejam fora do ar, sem qualquer impacto ou atraso.
Nota
No caso do PDNS, os resolvers em modo Anycast exigem uma 2ª IP única, nativa do Datacenter, além da 1ª IP anycast que é replicada em todos os Datacenters. Esta IP nativa é uma IP de gerenciamento para manter cada resolver conectado ao sistema central por meio do pipeline CI/CD e, por exemplo, receber informações sobre domínios a serem colocados na lista negra.
Anycast para Autoritativos
Este caso é muito semelhante ao dos Resolvers.
Se tivermos vários Datacenters, é muito conveniente ter endereços IP anycast para pelo menos 1 autoritativo.
A diferença entre ter 1 IP anycast em 3 Datacenters para 1 autoritativo e ter 3 IPs diferentes em cada Datacenter para 3 autoritativos é que, no caso do anycast, se um Datacenter falhar, o tempo de convergência BGP no backbone geralmente é muito curto, apenas alguns milissegundos. No entanto, no caso de IPs diferentes, se uma falhar, o tempo necessário para mudar para a 2ª IP autoritativa depende do timeout do dispositivo e pode levar vários segundos.
Nota
No caso do PDNS, os autoritativos em modo Anycast exigem uma 2ª IP única, nativa do Datacenter, além da 1ª IP anycast replicada em todos os Datacenters. Esta IP nativa é uma IP de gerenciamento para manter cada autoritativo conectado ao sistema central por meio do pipeline CI/CD e, por exemplo, realizar mudanças nos registros de uma zona ou adicionar/remover uma zona. Assim, os 3 autoritativos executam as mesmas tarefas e são idênticos, exceto pela IP nativa.
Resolver Edge
No caso de ter uma grande capilaridade Edge (ou seja, presença em muitos Datacenters ao redor do mundo), é possível alcançar uma latência muito curta para nossos resolvers e autoritativos em qualquer geografia.
Por exemplo, os resolvers do Google 8.8.8.8 e 8.8.4.4 vêm de anúncios de borda ou edge em inúmeros Datacenters, nas redes 8.8.8.0/24 e 8.8.4.0/24 no modo anycast.
Esses anúncios de borda criam a impressão de proximidade, com latências de por exemplo 10ms, enquanto servidores com IPs unicast localizados em outros países ou através de um salto oceânico podem exceder 200 milissegundos.
Aviso
A resolução de nomes com baixa latência e a alta disponibilidade dos resolvers e autoritativos são a chave para melhorar a experiência de navegação na Internet e também são essenciais para os rankings SEO. Por outro lado, existem serviços críticos que exigem alta disponibilidade, mesmo que não seja anycast (por exemplo, presença em vários Datacenters de diferentes nuvens públicas com diferentes IPs).
Nota
Se desejar hospedar um serviço em uma nuvem pública como AWS, GCP ou Azure, é importante considerar que uma IP elástica fornecida por esses provedores sempre será Unicast, ou seja, o serviço estará localizado em um único ponto geográfico. Como essas nuvens públicas possuem recursos de HA em seus Datacenters, elas podem ser usadas para alguns nameservers, enquanto, paralelamente, são usados nameservers Anycast desde que tenhamos uma rede /24 disponível e a possibilidade de anunciá-la a partir de pelo menos dois roteadores em dois Datacenters diferentes.
Exemplo de espelhamento em dois Datacenters
Esta seção é direcionada a empresas que gerenciam ou possuem Datacenters.
Neste caso, temos dois Datacenters, A e B, interconectados através de uma VLAN de Gerenciamento, onde estão localizados os servidores PDNS. Para cada resolver e autoritativo no Datacenter A, há um equivalente no Datacenter B. Cada resolver e autoritativo possui duas IPs: uma local do Datacenter e outra anycast. Define-se uma rede anycast que é anunciada tanto a partir de A quanto de B, por exemplo, 10.11.12.0/24 (mesmo que a rede 10.0.0.0/8 não seja roteável na Internet, usamos como exemplo).
A IP anycast dos resolvers é 10.11.12.2 e a do autoritativo é 10.11.12.3. Cada um possui uma IP de gerenciamento própria do Datacenter, que, por estarem interconectados por uma VLAN de Gerenciamento, podem ser não roteáveis, por exemplo, resolvers em 172.16.40.2 e 172.16.41.2 e autoritativos em 172.16.40.3 e 172.16.41.3.
Isso significa que a rede 172.16.40.0/24 é anunciada apenas a partir de A, a rede 172.16.41.0/24 é anunciada apenas a partir de B, e a rede 10.11.12.0/24 é anunciada a partir de ambos.
Espelhamento com Planisys como provedor Anycast
Planisys é um Cloud Provider além de ser uma Software Factory. A Planisys desenvolve software, oferece serviços em sua nuvem e também implementa soluções OnPremise, em Datacenters de terceiros e em nuvens de terceiros como AWS, GCP e Azure.
A Planisys, dentro do seu produto PDNS, além de fornecer este software que pode ser implantado OnPremise ou utilizado em sua versão em nuvem no Cloud da Planisys, também realiza anúncios BGP para terceiros, auxiliando na
A Planisys utiliza seu sistema autônomo AS52438 para anunciar redes via BGP, e, por meio do RPKI, é possível permitir que anuncie redes de » «terceiros.implementação do Anycast no produto PDNS.
Este gráfico ilustra o caso anterior, com a adição dos serviços Resolver e Autoritativo na nuvem da Planisys. Dessa forma, esses servidores terão a mesma funcionalidade nos Datacenters A e B, bem como na nuvem da Planisys.
