Un singolo indirizzo IP anycast non offre la stessa ridondanza di due indirizzi IP unicast in prefissi IP distinti.
Spesso il problema più difficile per la ridondanza non è quando qualcosa fallisce completamente, ma piuttosto quando si sta comportando male abbastanza per passare ancora i controlli sanitari, ma in realtà non essere funzionale.
Ho visto una configurazione DNS anycast in cui un server DNS non funzionava, ma i pacchetti verrebbero comunque instradati a quel server DNS. Qualunque cosa si occupasse della pubblicità del prefisso potrebbe semplicemente non essere consapevole del fatto che il server DNS non funzionava.
Diventa ancora più complicato se il server DNS in questione non è un server DNS autorevole, ma piuttosto un risolutore ricorsivo.
Un risolutore ricorsivo di questo tipo dovrebbe avere sia l'indirizzo anycast per la ricezione di query dai client sia gli indirizzi unicast per l'interrogazione di server DNS autorevoli. Ma se gli indirizzi unicast scendessero, potrebbe facilmente sembrare abbastanza sano da essere comunque indirizzati alle query.
Anycast è un ottimo strumento per la scalabilità e la riduzione della latenza. Ma per ridondanza non dovrebbe essere solo.
Più pool anycast ridondanti sono tuttavia un'ottima soluzione per la disponibilità. Un esempio ben noto è 8.8.8.8 e 8.8.4.4. Entrambi sono indirizzi anycast, ma non devono mai essere indirizzati allo stesso server DNS fisico (supponendo che Google abbia svolto bene il proprio lavoro).
Se si dispone di 10 server DNS fisici, è possibile configurarli come 2 pool con 5 server in ciascun pool o 5 pool con 2 pool in ciascun pool. Si desidera evitare che un server DNS fisico si trovi contemporaneamente in più pool.
Quindi quanti IP dovresti allocare? È necessario disporre di IP che possono essere configurati come anycast indipendentemente l'uno dall'altro. Ciò significa in genere che è necessario allocare un intero / 24 di spazio di indirizzi IPv4 o / 48 di spazio di indirizzi IPv6 per ciascun pool. Questo potrebbe benissimo limitare il numero di pool che puoi avere.
Inoltre, se stiamo parlando di server autorevoli, la risposta DNS con tutti i tuoi record NS e la colla A e AAAA dovrebbero rientrare in un singolo pacchetto da 512 byte. Per i server root questo ha funzionato a 13 indirizzi. Ma questo non includeva colla e IPv6, quindi il numero che raggiungeresti sarebbe inferiore.
Ogni pool dovrebbe essere il più geograficamente possibile distribuito. Se hai 5 server in Europa e 5 in Noth America e 2 IP anycast, non crei un pool in ogni continente. Metti 2 dall'Europa in un pool con 3 dal Nord America e gli altri 5 nell'altro pool.
Se si dispone di più di 2 pool anycast, è possibile lasciare temporaneamente un server fisico in più pool. Ma non dovresti mai consentire a un server fisico di essere in tutti i pool contemporaneamente.
La combinazione di anycast e unicast è possibile, ma è necessario prestare attenzione. Se si dispone di IP per due pool, non combinerei. Ma se hai un solo IP anycast con cui lavorare, può avere senso includere anche IP unicast. Il problema è che includere gli IP unicast non ti darà la stessa latenza e bilanciamento del carico.
Se un server fisico è reso disponibile sia da Unicast che da Anycast, è possibile rischiare che gli utenti raggiungano lo stesso server primario e secondario e perdere l'accesso in caso di interruzione. Questo può essere evitato usando solo indirizzi unicast di server non nel pool anycast o fornendo sempre agli utenti due indirizzi unicast.
Più indirizzi unicast vengono inseriti nel mix, meno query verranno inviate all'indirizzo anycast e minore sarà il vantaggio che si otterrà da qualsiasicast in termini di latenza e scalabilità.