DNS-серверы уже используют anycast. Будет ли добавление большего количества IP-адресов повысить масштабируемость?
RFC 1034 требует от нас назначить как минимум два IP-адреса для DNS-серверов. Однако избыточность уже может быть достигнута одним IP-адресом, если мы используем произвольную адресацию. Anycast BGP, кажется, хорошо масштабируется на сотни или даже тысячи серверов.
Если так, почему нам все еще нужно несколько IP-адресов для DNS-серверов? Действительно ли это увеличивает избыточность (способствует доступности), если у нас уже есть anycast, или это просто миф?
С какими проблемами и ошибками мы можем столкнуться, если будем использовать только один IP-адрес?
Под этим я подразумеваю полное исключение вторичных адресов DNS или использование поддельного IP (например, 1.2.3.4) для второго адреса, когда для некоторых настроек требуется как минимум два.
3 ответа
Один произвольный 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 с точки зрения задержки и масштабируемости.
Рекомендуется использовать как минимум два адреса из разных префиксов и присваивать им имена под двумя разными TLD. Оба эти адреса могут быть в любом случае, если хотите. Наличие только одного IP-адреса даст вам единственную точку отказа. Если маршрутизация на этот адрес не работает (ошибка конфигурации, некачественный экземпляр anycast, угон префикса и т. Д.), Тогда весь ваш домен становится недоступным.
Каждый произвольный адрес потребует как минимум /24 IPv4 или /48 Префикс IPv6 для маршрутизации в BGP. Меньшие (более длинные) префиксы обычно не принимаются в глобальной таблице маршрутизации во многих местах.
Никогда не вставляйте поддельный IP-адрес в качестве DNS-сервера. Это приведет к серьезным задержкам для распознавателей.
RFC 1034 только утверждает, что вам требуется два DNS-сервера. Это не обязательное требование, а рекомендация, поэтому делайте с ним что хотите. В любом случае, если вы хотите HA, вашим 2 DNS-серверам может быть назначен один и тот же IP-адрес с помощью anycast, и единственное, что ваши конечные пользователи заметят при сбое одного DNS-сервера, - это кратковременное отсутствие соединения при повторном сближении сети.
Таким образом, в общем, да, использование anycast достаточно для соответствия RFC 1034.