Один произвольный IP-адрес не дает такой же избыточности, как два одноадресных IP-адреса с разными IP-префиксами.
Часто самая сложная проблема для избыточности заключается не в том, когда что-то выходит из строя полностью, а в том, что оно ведет себя не так, как нужно, чтобы пройти проверку работоспособности, но на самом деле не работает.
Я видел настройку anycast DNS, где DNS-сервер отключался, но пакеты все равно передавались на этот DNS-сервер. Что бы ни заботилось о рекламе, префикс мог бы просто не знать, что DNS-сервер вышел из строя.
Становится еще сложнее, если рассматриваемый DNS-сервер не является авторитетным DNS-сервером, а скорее рекурсивным распознавателем.
Такой рекурсивный распознаватель должен иметь как адрес anycast для получения запросов от клиентов, так и адреса одноадресной рассылки для запросов к авторитетным DNS-серверам. Но если адреса одноадресной рассылки будут недоступны, она может легко выглядеть достаточно здоровой, чтобы все равно обрабатывать запросы.
Anycast - отличный инструмент для масштабируемости и снижения задержек. Но для избыточности он не должен стоять один.
Однако несколько избыточных пулов anycast - хорошее решение для доступности. Хорошо известным примером являются 8.8.8.8 и 8.8.4.4. Оба являются произвольными адресами, но их никогда не следует направлять на один и тот же физический DNS-сервер (при условии, что Google хорошо справился со своей работой).
Если у вас есть 10 физических DNS-серверов, вы можете настроить их как 2 пула по 5 серверов в каждом пуле или 5 пулов по 2 в каждом пуле. Вы хотите избежать одновременной работы одного физического DNS-сервера в нескольких пулах.
Так сколько IP адресов вы должны выделить? Вам нужно иметь IP-адреса, которые можно настроить как anycast независимо друг от друга. Обычно это означает, что вам нужно выделить полное / 24 адресного пространства IPv4 или / 48 адресного пространства IPv6 для каждого пула. Это может очень хорошо ограничить количество пулов, которые вы можете иметь.
Кроме того, если мы говорим об авторитетных серверах, DNS-ответ со всеми вашими записями NS и клеем A и AAAA должен помещаться в одном 512-байтовом пакете. Для корневых серверов это сработало до 13 адресов. Но это не включает клей и IPv6, поэтому число, которое вы достигнете, будет ниже.
Каждый пул должен быть как можно более географически распределен. Если у вас есть 5 серверов в Европе и 5 в Северной Америке и 2 альтернативных IP-адреса, вы не создадите один пул, охватывающий каждый континент. Вы кладете 2 из Европы в пул с 3 из Северной Америки, а остальные 5 в другой пул.
Если у вас более двух пулов anycast, вы можете временно разрешить физическому серверу работать в нескольких пулах. Но вы никогда не должны позволять физическому серверу находиться во всех пулах одновременно.
Комбинация anycast и unicast возможна, но нужно соблюдать осторожность. Если у вас есть IP для двух пулов, я бы не совмещал. Но если у вас есть только один альтернативный IP-адрес, возможно, имеет смысл также включить одноадресные IP-адреса. Проблема заключается в том, что включение одноадресных IP-адресов не обеспечит хорошую задержку и балансировку нагрузки.
Если физический сервер становится доступным как для одноадресной, так и для любой рассылки, вы можете подвергнуть пользователей риску получить доступ к одному и тому же серверу как первичному и вторичному и потерять доступ в случае его отказа. Этого можно избежать, используя только одноадресные адреса серверов, не входящих в пул anycast, или всегда предоставляя пользователям два одноадресных адреса.
Чем больше адресов одноадресной рассылки вы добавите в микс, тем меньше запросов будет отправлено на адрес anycast, и тем меньше преимуществ вы получите от anycast с точки зрения задержки и масштабируемости.