Une seule adresse IP anycast ne vous donne pas la même redondance que deux adresses IP unicast dans des préfixes IP distincts.
Souvent, le problème le plus difficile pour la redondance n'est pas quand quelque chose échoue complètement, mais plutôt quand il se comporte mal juste assez pour réussir les tests de santé, mais pas réellement fonctionnel.
J'ai vu une configuration DNS anycast où un serveur DNS est tombé, mais les paquets seraient toujours acheminés vers ce serveur DNS. Tout ce qui s'occupait de la publicité du préfixe ne savait tout simplement pas que le serveur DNS était tombé en panne.
Cela devient encore plus délicat si le serveur DNS en question n'est pas un serveur DNS faisant autorité, mais plutôt un résolveur récursif.
Un tel résolveur récursif devrait avoir à la fois l'adresse anycast pour recevoir les requêtes des clients et les adresses unicast pour interroger les serveurs DNS faisant autorité. Mais si les adresses de monodiffusion diminuaient, elles pourraient facilement sembler suffisamment saines pour que ce soient toujours des requêtes routées.
Anycast est un excellent outil pour l'évolutivité et la réduction de la latence. Mais pour la redondance, il ne devrait pas être autonome.
Plusieurs pools anycast redondants sont cependant une bonne solution pour la disponibilité. Un exemple bien connu est 8.8.8.8 et 8.8.4.4. Les deux sont des adresses anycast, mais elles ne doivent jamais être acheminées vers le même serveur DNS physique (en supposant que Google a bien fait son travail).
Si vous avez 10 serveurs DNS physiques, vous pouvez les configurer en 2 pools avec 5 serveurs dans chaque pool ou 5 pools avec 2 dans chaque pool. Vous voulez éviter d'avoir un serveur DNS physique dans plusieurs pools simultanément.
Alors, combien d'adresses IP devez-vous allouer? Vous devez avoir des adresses IP qui peuvent être configurées comme anycast indépendamment les unes des autres. Cela signifie généralement que vous devrez allouer un / 24 d'espace d'adressage IPv4 ou / 48 d'espace d'adressage IPv6 pour chaque pool. Cela peut très bien limiter le nombre de pools que vous pouvez avoir.
De plus, si nous parlons de serveurs faisant autorité, la réponse DNS avec tous vos enregistrements NS et la colle A et AAAA doit tenir dans un seul paquet de 512 octets. Pour les serveurs racine, cela a fonctionné pour 13 adresses. Mais cela n'incluait pas la colle et IPv6, donc le nombre que vous atteindriez serait inférieur.
Chaque pool doit être aussi géographiquement distribué que possible. Si vous avez 5 serveurs en Europe et 5 en Amérique du Nord et 2 adresses IP anycast, vous ne créez pas un pool couvrant chaque continent. Vous mettez 2 d'Europe dans une piscine avec 3 d'Amérique du Nord et les 5 autres dans l'autre piscine.
Si vous avez plus de 2 pools anycast, vous pouvez autoriser temporairement un serveur physique à appartenir à plusieurs pools. Mais vous ne devez jamais autoriser un serveur physique à être dans tous les pools en même temps.
Il est possible de combiner anycast et unicast, mais il faut faire attention. Si vous avez des adresses IP pour deux pools, je ne combinerais pas. Mais si vous ne disposez que d'une seule adresse IP anycast, il peut être judicieux d'inclure également des adresses IP monodiffusion. Le problème est que l'inclusion d'adresses IP unicast ne vous donnera pas une bonne latence et un bon équilibrage de charge.
Si un serveur physique est mis à disposition à la fois par unicast et par anycast, vous risquez que les utilisateurs atteignent le même serveur en tant que serveur principal et secondaire et perdent l'accès en cas de panne. Cela peut être évité en utilisant uniquement des adresses unicast de serveurs ne faisant pas partie du pool anycast ou en fournissant toujours aux utilisateurs deux adresses unicast.
Plus vous mettez d'adresses unicast dans le mix, moins de requêtes seront envoyées à l'adresse anycast, et moins vous profiterez de anycast en termes de latence et d'évolutivité.