Um único endereço IP anycast não oferece a mesma redundância que dois endereços IP unicast em prefixos IP distintos.
Muitas vezes, o problema mais difícil para a redundância não é quando algo falha completamente, mas quando ele está se comportando mal o suficiente para passar nas verificações de integridade, mas não é realmente 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. Seja o que for que estivesse cuidando da publicidade, o prefixo poderia simplesmente não estar ciente de 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 sim 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 de unicast fossem desativados, poderia facilmente parecer saudável o suficiente para continuar sendo consultas roteadas.
O Anycast é uma ótima ferramenta para escalabilidade e redução de 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 fez bem o seu trabalho).
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 uns dos outros. 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 autoritativos, a resposta do DNS com todos os seus registros NS e cola A e AAAA deve caber em um único pacote de 512 bytes. Para os servidores raiz, isso funcionou para 13 endereços. Mas isso não inclui cola e IPv6, então o número que você alcançaria seria menor.
Cada pool deve ser o mais geograficamente distribuído possível. Se você tiver 5 servidores na Europa e 5 na América do Norte e 2 IPs de anycast, você não criará uma piscina 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 anycast, poderá permitir que um servidor físico fique temporariamente em mais de um pool. Mas você nunca deve permitir que um servidor físico esteja em todos os pools ao mesmo tempo.
Combinar anycast e unicast é possível, mas é preciso ter cuidado. Se você tiver IPs para dois pools, eu não combinaria. Mas se você tiver apenas um único IP anycast com o qual trabalhar, pode fazer sentido incluir também IPs unicast. O problema é que incluir IPs unicast não fornecerá a você uma latência e um balanceamento de carga satisfatórios.
Se um servidor físico for disponibilizado tanto por unicast quanto por 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 ficar inativo. Isso pode ser evitado usando somente 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 no mix, menos consultas serão enviadas para o endereço anycast e menos benefícios serão obtidos com anycast em termos de latência e escalabilidade.