Организация отказоустойчивого DNS-сервиса — одна из базовых задач для корпоративной сети, особенно при росте инфраструктуры и появлении новых площадок. VRRP справляется до поры до времени, но при переходе к распределенной архитектуре его возможностей становится недостаточно. Anycast позволяет решить эту задачу, но требует аккуратной настройки, особенно если в основе сети фабрика Cisco ACI.
В статье ведущий бизнес-консультант компании «АРБАЙТ» Илья Глейкин рассмотрит, как перейти от локального VRRP к полноценному anycast-сервису, способному пережить сбои, потерю площадки и отказ отдельных узлов, — и почему «просто анонсировать /32 через BGP» недостаточно.
Целевая схема
В качестве изначального состояния рассмотрим два DNS-сервера, размещенных на одной площадке в одной IP-подсети, которые используют протокол VRRP и VIP-адрес в качестве адреса, по которому доступен DNS-сервис для клиентов.
Компания вводит новую площадку и хочет организовать отказоустойчивый и катастрофоустойчивый сервис DNS. В целевой схеме необходимо ввести в эксплуатацию еще два DNS-сервера, размещенных на второй площадке, и реализовать высокодоступный сервис DNS, независимый от площадки или конкретного сервера. Также необходимо обеспечить плавный переход на anycast DNS-адрес – существующий адрес DNS для клиентов тоже должен быть доступен.
Для организации такого сервиса подойдет технология Anycast — технология сетевой адресации и маршрутизации, при использовании которой пользовательский трафик отправляется на сервер, наиболее близкий к пользователю. Она предполагает назначение одинакового IP-адреса на несколько разных серверов. Такой адрес называется anycast-адресом. Он не должен использоваться где-либо еще, кроме нужных серверов.
В отличие от мультикаст-адресов, нет заранее определенного диапазона, зарезервированного для Anycast, поэтому лучшей практикой обычно является выделение отдельной подсети для anycast-адресов, из которой будут браться только /32 адреса для anycast-сервисов. Такой подход исключит возможные проблемы с маршрутизацией, связанные с суммаризацией маршрутов на транзитных маршрутизаторах.
На сервере такой адрес обычно настраивается на loopback-интерфейсе. Маршрут к anycast-адресу можно получать динамически через протоколы маршрутизации OSPF или BGP или через статический маршрут. Чаще всего используется BGP, о его плюсах расскажем ниже.
Реализация в классической сети
Сначала рассмотрим классическую сеть. В классическом случае необходимо построить BGP-соединение между сервером и точкой терминации подсети, в которой находятся серверы (чаще всего это ядро сети). По протоколу BGP от сервера будет анонсироваться маршрут /32 (anycast-адрес), который настроен на loopback-интерфейсе.
При этом для большей информативности самого маршрута рекомендуется на каждый сервер выделить отдельную BGP-AS 65xxx. Тогда просто по атрибутам BGP-маршрута будет понятно, от какого сервера он получен, это существенный плюс использования BGP-протокола (в атрибуте AS Path будет присутствовать уникальный номер AS сервера).
Так как у нас два сервера на площадке, то для BGP-сессии необходимо настроить BFD для быстрого переключения (иначе стандартное время переключения на резервный сервер составит 180 секунд).
Для того чтобы настроить на сервере BGP и BFD, чаще всего используют пакет FRRouting или просто FRR. Этот инструмент имеет богатый функционал и схожий с Cisco синтаксис конфигурации, поэтому получил широкое распространение.
Реализация с использованием фабрики Cisco ACI
Фабрика Cisco ACI — это, по сути, кусочек программно определяемой сети (SDN) в вашем ЦОДе, поэтому изначально хотелось найти способ генерировать anycast-маршрут средствами фабрики. И действительно, некоторые возможности у фабрики имеются.
Например, в настройках EPG можно указать /32 префикс с указанием anycast mac. Но для того, чтобы функционал заработал, требуется, чтобы существовал endpoint с таким IP-адресом, то есть адрес должен быть настроен на интерфейсе сервера, подключенном к фабрике. В нашем случае это не так, так как требуется сохранить существующий DNS-адрес и anycast можно настроить только на loopback-интерфейсе, то есть фабрика не будет знать о таком endpoint-е.
Еще один вариант — это функционал EP reachability. Этот функционал позволяет простым способом создавать маршрут для подсети за подсетью EPG. В настройках EPG также нужно указать /32 префикс для маршрута.
В качестве next-hop для такого маршрута указывается VIP-адрес, настроенный для VRRP-группы на двух серверах DNS. При такой конфигурации маршрут всегда будет указывать на активный сервер (тот, на котором в данный момент находится VIP-адрес).
С опцией Advertised Externally такой маршрут будет отдаваться в L3Out в сторону внешней сети (за пределы фабрики) по протоколу маршрутизации, настроенному для взаимодействия с внешней сетью (чаще всего это тоже BGP). Однако у такого варианта есть существенный недостаток — маршрут для anycast-адреса, созданный таким способом, не удаляется автоматически в случае недоступности обоих серверов.
Даже если оба сервера будут недоступны, на фабрике будет маршрут на anycast-адрес для DNS-сервиса, указывающий на VIP-адрес, который не будет доступен. Для пользователей, которые находятся на той же площадке, сервис DNS становится недоступен, даже если на другой площадке будет работающий сервер DNS, так как маршрут от фабрики будет более приоритетный.
Последний вариант упрощенной схемы — создание и удаление статического маршрута через API фабрики. Можно осуществлять мониторинг доступности VIP-адреса серверов DNS, в случае недоступности VIP-адреса удалять сконфигурированный статический маршрут для anycast-адреса, в случае восстановления доступности VIP-адреса снова создавать маршрут.
Непосредственно с фабрики это делать не получится, так как на фабрике ограничена возможность запуска скриптов. Для реализации такого варианта потребуется отдельный хост, с которого будет осуществляться мониторинг и выполняться скрипт, создающий и удаляющий статический маршрут через API фабрики. Такой способ подойдет в случае, если по какой-либо причине нельзя существенно менять конфигурацию DNS-сервера.
Так как упрощенный вариант средствами фабрики реализовать не получается (либо он не подходит), рассмотрим организацию схемы, в которой между сервером и фабрикой устанавливается BGP-сессия для передачи маршрута на anycast-адрес.
Для этого потребуется создать отдельный L3Out. Чаще всего используются виртуальный DNS-серверы, поэтому будем рассматривать L3Out с типом интерфейса SVI (в случае с виртуальными серверами физические порты будут настроены в trunk и не могут быть выбраны для L3Out).
Вывод
Anycast — инструмент, который не про «чтобы было», а про точную работу под нагрузкой и в отказе. Его настройка в классической сети и в ACI-фабрике требует понимания не только сетевой теории, но и особенностей поведения платформы. Один и тот же маршрут может спасти отказоустойчивость — или разрушить ее, если остался в таблице после потери узла.