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