Um único endereço IP de anycast não oferece a mesma redundância que dois endereços IP unicast em prefixos IP distintos.
Freqüentemente, o problema mais difícil de redundância não ocorre quando algo falha completamente, mas quando se comporta mal o suficiente para passar nas verificações de integridade, mas na verdade não é funcional.
Eu vi uma configuração de DNS anycast em que um servidor DNS caiu, mas os pacotes ainda seriam roteados para esse servidor DNS. O que quer que estivesse cuidando da publicidade, o prefixo simplesmente não sabia, que o servidor DNS havia caído.
Torna-se ainda mais complicado se o servidor DNS em questão não for um servidor DNS autoritativo, mas um resolvedor recursivo.
Esse resolvedor recursivo precisaria ter o endereço anycast para receber consultas de clientes e endereços unicast para consultar servidores DNS autoritativos. Mas, se os endereços unicast diminuíssem, poderia facilmente parecer saudável o suficiente para que ainda fossem consultas roteadas.
Anycast é uma ótima ferramenta para escalabilidade e redução da latência. Mas, para redundância, não deve ficar sozinho.
Vários pools anycast redundantes são, no entanto, uma boa solução para disponibilidade. Um exemplo bem conhecido é 8.8.8.8 e 8.8.4.4. Ambos são endereços anycast, mas nunca devem ser roteados para o mesmo servidor DNS físico (supondo que o Google tenha feito seu trabalho bem).
Se você tiver 10 servidores DNS físicos, poderá configurá-los como 2 pools com 5 servidores em cada pool ou 5 pools com 2 em cada pool. Você deseja evitar que um servidor DNS físico esteja em vários pools simultaneamente.
Então, quantos IPs você deve alocar? Você precisa ter IPs que possam ser configurados como anycast independentemente um do outro. Isso geralmente significa que você precisará alocar um espaço de endereço inteiro / 24 de IPv4 ou / 48 de espaço de endereço IPv6 para cada pool. Isso pode muito bem limitar o número de pools que você pode ter.
Além disso, se estivermos falando de servidores autorizados, a resposta DNS com todos os seus registros NS e a cola A e AAAA devem caber em um único pacote de 512 bytes. Para os servidores raiz, isso resultou em 13 endereços. Mas como isso não incluía cola e IPv6, o número que você alcançaria seria menor.
Cada pool deve ser o mais geograficamente distribuído possível. Se você possui 5 servidores na Europa e 5 na América do Norte e 2 IPs anycast, não cria um pool abrangendo cada continente. Você coloca 2 da Europa em uma piscina com 3 da América do Norte e os outros 5 na outra piscina.
Se você tiver mais de dois pools de anycast, poderá deixar um servidor físico temporariamente em mais de um pool. Mas você nunca deve permitir que um servidor físico esteja em todos os pools ao mesmo tempo.
É possível combinar anycast e unicast, mas é preciso ter cuidado. Se você tem IPs para dois pools, eu não combinaria. Mas se você tiver apenas um único IP anycast para trabalhar, pode fazer sentido incluir também IPs unicast. O problema é que a inclusão de IPs unicast não fornecerá uma boa latência e balanceamento de carga.
Se um servidor físico for disponibilizado pelo unicast e pelo anycast, você poderá arriscar que os usuários cheguem ao mesmo servidor que o primário e o secundário e perder o acesso se ele cair. Isso pode ser evitado usando apenas endereços unicast de servidores que não estão no pool anycast ou sempre fornecendo aos usuários dois endereços unicast.
Quanto mais endereços unicast você colocar na mistura, menos consultas serão enviadas para o endereço anycast e menos benefício você obterá do anycast em termos de latência e escalabilidade.