Anycast для бедных: как это работает у больших и что из этого реально повторить

Один IP-адрес, который физически находится в двадцати местах одновременно. Вы отправляете пакет, он уходит в ближайшую к вам точку, а ваш сосед по континенту отправляет пакет на тот же адрес и попадает в другую. Никакого переключения, никакого выбора на стороне клиента, адрес буквально один.

Называется это anycast, работает с восьмидесятых и держит на себе половину инфраструктуры интернета. Выглядит как магия, а на деле это свойство маршрутизации, которое кто-то однажды решил использовать не по прямому назначению.

А теперь к заголовку, потому что я в нём слукавил. Дешёвым anycast не бывает. Порог входа начинается с собственного блока из 256 адресов, который стоит как подержанная машина, и упирается в провайдера, который согласится говорить с вами на языке маршрутизации. «Повторить дома» не выйдет, и я это честно покажу с цифрами.

Зато задача, ради которой его обычно хотят, в девяти случаях из десяти решается двумя дешёвыми серверами и правильными записями в DNS. Разобраться, в каком вы случае, и есть смысл этой статьи.

🌍 Корневых серверов

13 адресов

🖥 А машин за ними

2049 экземпляров

💸 Порог входа

~8000 долларов

Кому пригодится: если ваша аудитория размазана по разным странам; если задумывались про несколько серверов в разных локациях и не поняли, как между ними делить трафик; или если просто интересно, как один адрес оказывается в двадцати местах.

Содержание

Как один адрес живёт в двадцати местах
Тринадцать адресов и две тысячи машин
Сколько точек реально нужно
Где anycast врёт про «ближайший»
Почему дома так не получится
Сколько это стоит на самом деле
Вариант для бедных, который работает
Чего дешёвый вариант не даст
Когда всё это не нужно
Частые ошибки
Короткий итог

Источники

Как один адрес живёт в двадцати местах

Механика проще, чем кажется, если знать, что такое BGP.

Интернет состоит из автономных систем. Автономная система это сеть под единым управлением, у неё есть номер, и она рассказывает соседям, до каких блоков адресов через неё можно добраться. Соседи пересказывают это дальше. Так у каждого маршрутизатора складывается таблица: для такого-то блока адресов следующий шаг такой-то.

Теперь внимание, вся идея в одном абзаце. Ничто в этой схеме не запрещает объявить один и тот же блок адресов из нескольких разных мест. Вы ставите сервер в Амстердаме и говорите «блок 198.51.100.0/24 доступен через меня». Ставите второй в Сингапуре и говорите то же самое. Теперь у маршрутизаторов по всему миру есть два пути к одному блоку, и каждый выбирает тот, который считает лучшим по своим правилам.

Пакет уходит по выбранному пути и приезжает на один из серверов. На какой именно, зависит от того, откуда вы отправляли. Клиент при этом ничего не знает и ничего не выбирает: для него адрес один, и он просто работает.

Магии нет вообще. Есть обычная маршрутизация, у которой решили не исправлять особенность, а воспользоваться ей.

	Обычный адрес	Anycast-адрес
Сколько машин за адресом	одна	сколько угодно
Кто выбирает, куда пойдёт пакет	выбора нет	маршрутизаторы по дороге
Знает ли клиент о выборе	нет, для него это просто адрес	тоже нет
Что происходит при падении точки	адрес недоступен	маршрут исчезает, пакеты едут в следующую
Что нужно, чтобы так сделать	ничего	свой блок /24, номер системы, BGP

Отдельно про слово «ближайший», потому что оно главный источник заблуждений. Маршрутизатор выбирает не географически близкий путь, а лучший по своим критериям, и первый критерий там коммерческий: через кого дешевле. Дальше смотрится длина пути в количестве автономных систем, а не в километрах. Так что трафик из Казахстана может уйти во Франкфурт, хотя Сингапур ближе, если через Франкфурт у операторов выгоднее стык.

И сразу про страх, который обычно возникает следом: а что с TCP, он же требует, чтобы соединение шло на один и тот же сервер? Требует. Работает это потому, что маршруты в интернете меняются редко, на порядки реже, чем живёт среднее соединение. Вопрос обсуждён много лет назад, на конференции NANOG в 2006 году был доклад с говорящим названием «TCP Anycast: Don't believe the FUD». Проблема существует и проявляется при перестройке маршрутов, когда идущее соединение приезжает на другой сервер и рвётся. У больших это лечится в том числе на уровне балансировщиков, об этом ниже.

Тринадцать адресов и две тысячи машин

Лучшая демонстрация технологии работает прямо сейчас у вас в DNS-запросах.

Корневых серверов имён, как известно каждому, кто читал про устройство DNS, тринадцать. Это ограничение из прошлого: тринадцать адресов было максимумом, который гарантированно влезал в один пакет DNS по старым правилам.

Тринадцать серверов на весь интернет звучит как катастрофическая точка отказа. А теперь факт: на момент написания статьи корневая система состоит из 2049 работающих экземпляров, которыми управляют двенадцать независимых организаций.

Две тысячи машин на тринадцать адресов. Каждый из тринадцати адресов объявлен из десятков и сотен мест по всему миру, и ваш запрос уходит в тот экземпляр, до которого короче путь от вашего оператора. Тринадцать это количество имён, а не количество железа, и путаница между этими двумя числами живёт в интернете десятилетиями.

Второй пример, уже из прикладной области. Google опубликовала описание своего балансировщика Maglev на конференции NSDI в 2016 году, и там видно, как anycast сочетается с балансировкой внутри точки. Маршрутизаторы раскидывают пакеты между машинами балансировщика через ECMP, то есть несколько равнозначных маршрутов. Каждая машина дальше распределяет соединения по серверам приложения, причём использует согласованное хеширование и отслеживание соединений, чтобы при изменении состава машин уже установленные соединения не разваливались. Одна такая машина, по их данным, забивает десятигигабитный канал мелкими пакетами.

Дата в статье показательнее технических деталей: «Maglev has been serving Google's traffic since 2008». Публикацию сделали через восемь лет после запуска.

Сколько точек реально нужно

Вопрос, на который есть исследованный ответ, и он приятно скромный.

Группа исследователей разобрала четыре разных реальных развёртывания anycast и опубликовала работу на конференции PAM в 2017 году. Вывод формулируется так: «After carefully studying four very different anycast deployments, we claim that 12 anycast sites would be enough for good overall latency. Two sites per continent, in well chosen and well connected locations».

Двенадцать точек. Две на континент, в хорошо связанных местах.

Почему не двести, объясняется физикой, которую я уже разбирал в статье про пинг. Свет в оптике идёт примерно двести тысяч километров в секунду, отсюда простое правило: расстояние в километрах не бывает больше, чем пинг в миллисекундах, умноженный на сто. Когда точка уже в вашем регионе, задержка упирается в скорость света и количество промежуточных узлов, и добавление ещё одной точки в том же регионе даёт выигрыш в единицы миллисекунд.

То есть кривая выигрыша загибается быстро. Первая точка в новом регионе даёт сотни миллисекунд. Вторая в том же регионе даёт десятки. Пятая даёт единицы. Двести точек это уже не про задержку, а про ёмкость и про фильтрацию атак.

Хорошая новость для разговора «для бедных»: если двенадцати точек хватает Google и корневым серверам для хорошей задержки по всей планете, то вашему проекту с аудиторией в двух-трёх странах хватает двух-трёх. Это уже совсем другие деньги.

Где anycast врёт про «ближайший»

Раздел для честности, потому что без него получается реклама.

Исследователи из Microsoft разобрали работу своей anycast-сети для поисковика Bing на миллионах клиентских измерений и опубликовали результат на конференции IMC в 2015 году. Главный вывод: сеть работает хорошо, однако примерно 20% клиентов направляются не в оптимальную точку.

Каждый пятый. И причина не в ошибке настройки, а в устройстве: BGP не знает про географию, про загрузку точек и про текущее качество связи. Он знает коммерческие отношения операторов и длину пути в количестве автономных систем. Соответствие этих критериев географии получается само собой и получается неточно.

Из этого следуют два практических вывода.

Первый: anycast даёт хорошую среднюю задержку без всякого управления, и это его главная ценность. Вы ничего не настраиваете, ничего не измеряете, оно просто работает прилично для почти всех.

Второй: если вам нужна точная маршрутизация, anycast её не даст. Для этого берут DNS с геопривязкой и измерениями: там точку выбирают по собственным замерам, а не по чужим коммерческим предпочтениям. У больших обычно стоят обе схемы сразу, потому что они решают разные части задачи.

Почему дома так не получится

Переходим к вопросу из заголовка. Я специально оставил его на середину, потому что без предыдущих разделов ответ выглядит как отказ, а не как объяснение.

Чтобы объявлять свой блок адресов из нескольких мест, нужны три вещи, и ни одной из них нет у вас дома.

Собственный блок адресов не меньше /24. Это не прихоть, а практика фильтрации. Операторы по всему миру не принимают анонсы блоков меньше /24, иначе глобальная таблица маршрутизации распухла бы до неработоспособного состояния. Документация Vultr пишет об этом без обиняков: «You will need at minimum a /24 of IPv4 space, or a /48 of IPv6 space. Smaller subnets are not routable on the internet».

То есть минимальная единица входа это 256 адресов. Не один адрес и не восемь, а блок целиком.

Номер автономной системы. Чтобы объявлять маршруты от своего имени, нужен свой номер, оформленный в региональном регистраторе. Технически можно обойтись приватным номером, который выдаст провайдер, но тогда блок будет виден снаружи как часть его сети, и переносимость между операторами пропадёт.

Провайдер, который согласен поднять с вами сессию BGP. Самое неожиданное из трёх. Обычный хостинг вам порт в маршрутизаторе не отдаст. Нужна услуга, которая так и называется, и она есть далеко не у всех.

Как выглядит конфигурация у тех, у кого есть, видно на том же примере. Для виртуальных машин указываются внутренний номер системы 64515, адрес соседа 169.254.169.254 и значение multihop равное двум, потому что сосед не на одном канале с вами. Демон маршрутизации вроде BIRD поднимает сессию и объявляет ваш блок. В документации есть отдельное примечание, которое стоит процитировать как пример жизни: BGP не заработает на уже существующих машинах, пока их не перезагрузят через панель управления, причём перезагрузка командой изнутри не считается.

Домашний интернет из этой схемы исключён целиком, и причина даже не в деньгах. Провайдер не станет принимать от вас анонсы, потому что ваш канал это клиентское подключение, а не стык между сетями.

Сколько это стоит на самом деле

Посчитаем, потому что порядок цифр многое объясняет.

Блок адресов. Свободных блоков IPv4 у регистраторов нет, их покупают на вторичном рынке. Цена в 2026 году держится в районе двадцати пяти-тридцати долларов за адрес для блоков размером /24. Умножаем на 256 и получаем порядка семи-восьми тысяч долларов за минимальную единицу входа.

Есть вариант аренды: ставки по рынку держатся около тридцати центов за адрес в месяц, то есть /24 обходится примерно в восемьдесят долларов в месяц. Дешевле на входе, зато адреса не ваши, и вместе с ними вы наследуете их историю.

Номер автономной системы. Оформляется через регистратора или через посредника, у которого есть статус локального регистратора. Порядок цен на такие услуги на российском рынке начинается от десяти тысяч рублей за регистрацию номера, полный комплект с блоком /24 и сетью IPv6 обойдётся дороже. Плюс ежегодная поддержка объектов в базе регистратора.

Серверы в точках присутствия. Тут как раз дешёво: три недорогие машины в трёх локациях это копейки по сравнению с предыдущими двумя пунктами.

Складываем:

Статья расхода	Сколько
Блок /24 на вторичном рынке	7000–8000 $ разово
Либо аренда того же /24	~80 $ в месяц
Номер автономной системы	от 10 000 ₽ плюс поддержка в год
Три машины в трёх локациях	копейки на фоне остального

И после этого вам ещё предстоит разбираться с BGP, фильтрами анонсов и тем, почему из половины стран ваш блок не виден.

Отсюда честный вывод, который я и хотел донести этой статьей: настоящий anycast это не бюджетная технология. Он доступен, он не требует быть корпорацией, и порог входа измеряется тысячами долларов, а не миллионами. Но назвать это «повторить дома» не получится.

Хорошая новость в том, что вам почти наверняка нужно не это.

Вариант для бедных, который работает

Вернёмся к тому, зачем вам вообще anycast. Задача формулируется так: посетитель должен попасть на сервер, который рядом с ним и при этом работает. Anycast один из способов её решить, а не сама задача.

Второй способ стоит ноль и решает ту же задачу на восемьдесят процентов. Он называется DNS с проверкой доступности.

Схема такая. Два или три сервера в разных регионах, у каждого свой обычный адрес. На домене настроены записи так, что человеку из Европы отдаётся европейский адрес, человеку из Азии азиатский. Сверху стоит проверка доступности: если сервер не отвечает, его адрес перестаёт отдаваться, и трафик идёт на живой. Такое умеют почти все нормальные провайдеры DNS, многие в бесплатном тарифе.

Сравнение по пунктам:

	Anycast	DNS с проверками
Порог входа	свой /24, номер системы, провайдер с BGP	одна учётная запись
Стоимость входа	тысячи долларов	ноль
Точность выбора точки	средняя, ~20% не в оптимальной	выше, по измерениям
Переключение при аварии	секунды, само	ограничено TTL и кэшами
Поведение при атаке	размазывается по точкам	весь трафик в один адрес
Нужен контроль над адресами	да	нет

Третий и четвёртый ряды это ровно то, за что платят. Остальное дешёвый вариант закрывает.

Что нужно сделать руками, если собираете дешёвый вариант.

Поставьте короткий TTL на записи, секунд триста. Это прямо определяет, как быстро люди уедут с упавшего сервера.

Включите проверку доступности на стороне провайдера DNS, а не придумывайте свою. И проверяйте не главную страницу, а отдельный адрес вроде /healthz, который отвечает дёшево. История Stack Overflow, где балансировщик проверял главную страницу и вывел из обслуживания все серверы разом, разобрана у меня в соседней статье, про анатомию DDoS, и повторять её не стоит.

Решите вопрос с состоянием. Вот это главное, про что забывают: пока у вас на двух серверах два разных набора данных, вы не балансируете трафик, а держите два разных сайта. Сессии в общем хранилище, загруженные файлы в общем объектном хранилище, база с репликой и понятным ответом на вопрос, кто принимает запись.

Посмотрите на свои серверы снаружи, из разных мест. Собрать это на отдельной дешёвой машине недолго, у меня есть отдельная статья про мониторинг.

Чего дешёвый вариант не даст

Один сценарий, в котором разница принципиальная, и это не скорость.

Anycast размазывает атаку. Когда адрес объявлен из двадцати мест, трафик атаки приходит не в одну точку, а делится между всеми по тому же принципу, по которому делится обычный трафик. Ботнет, распределённый по миру, сам себя распределяет и по вашим точкам присутствия.

Это главная причина, по которой anycast стоит в основе всех защитных сетей, и её невозможно воспроизвести записями в DNS: там весь трафик идёт на тот адрес, который резолвер уже выдал, и он никуда не поделится.

Anycast переключается мгновенно и без кэшей. Упала точка, маршрут исчез, пакеты поехали в следующую. Секунды, без участия человека и без ожидания истечения TTL. В схеме с DNS вы всегда ждёте, пока записи обновятся у клиентов, и часть людей будет видеть мёртвый адрес ещё долго после того, как вы его убрали, потому что кэши не всегда соблюдают TTL.

И третье, менее очевидное. С anycast у вас один адрес, который не меняется никогда. Это важно для всего, где адрес прописан жёстко: в чужих конфигурациях, в правилах файрволов у клиентов, в приложениях. Собственно, ровно по этой причине anycast используют для публичных DNS-резолверов: адрес 1.1.1.1 запоминаемый и неизменный, а машин за ним много.

Если ваша задача это защита от атак или переключение за секунды без оглядки на кэши, дешёвый вариант вам не подойдёт, и выбор будет между своим anycast и готовой защитной сетью перед сайтом. У второго свои издержки, про которые у меня есть отдельная статья, про Cloudflare.

Когда всё это не нужно

Самый полезный раздел, потому что он экономит деньги.

Если ваша аудитория в одной стране, вам не нужно ничего из этого. Один хороший сервер в правильной локации обгонит три плохих, размазанных по миру. Задержка внутри одной страны и так в пределах десятков миллисекунд, и улучшать там нечего. Вместо этого лучше потратить то же время на кэш и на нормальные настройки, выигрыш будет больше.

Если у вас нет общего состояния, несколько серверов сделают хуже. Два сервера с двумя разными базами это два разных сайта, между которыми случайно прыгают пользователи. Проблема начнётся не сразу, а потом, когда кто-то не найдёт свой заказ.

Если вы не умеете это обслуживать, оно сломается именно так. Три сервера это три комплекта обновлений, три набора сертификатов и три места, где может разъехаться конфигурация. Один сервер, за которым следят, надёжнее трёх, за которыми не следят.

Проверка перед тем, как всё это затевать, из одного вопроса: знаете ли вы, откуда к вам приходят люди. Если в аналитике девяносто процентов из одной страны, закройте эту статью и просто возьмите сервер поближе к этой стране. Пригодится она тем, у кого в этой же аналитике два-три заметных региона, и тогда разговор становится предметным.

Частые ошибки

Считать, что anycast выбирает географически ближайшую точку. Он выбирает лучший путь по критериям операторов, и первый из них коммерческий.
Путать тринадцать корневых серверов с тринадцатью машинами. Адресов тринадцать, работающих экземпляров больше двух тысяч.
Думать, что anycast можно поднять на обычном VPS. Нужен свой блок не меньше /24, номер автономной системы и провайдер, который согласится поднять сессию BGP.
Пытаться объявить блок меньше /24. Такие анонсы не принимают, и это не настраивается.
Строить несколько точек раньше, чем решён вопрос общего состояния. Иначе получится не балансировка, а несколько разных сайтов.
Проверять доступность по главной странице. Тяжёлая проверка превращает любую нагрузку в вывод живых серверов из обслуживания.
Оставлять суточный TTL в схеме с DNS. Тогда переключение при аварии растягивается на сутки.
Ждать от DNS-схемы защиты от атак. Трафик пойдёт на выданный адрес целиком, делиться он не умеет.
Разносить серверы по миру при аудитории из одной страны. Один сервер рядом с людьми лучше трёх далеко.

Где это держать

Практическая часть, раз уж весь текст про то, что порог входа в эту тему определяется не серверами, а адресами и номерами.

Для дешёвого варианта нужны просто несколько машин в разных локациях, причём самых младших: они занимаются раздачей, а не вычислениями. Тут выбирать особо нечего, подойдёт любой хостер с нужными вам странами.

Я беру serv.host промокод promo22382: локации есть и в России, и в Европе, и в США, а собственные дата-центры уровня Tier III стоят в Москве и Новосибирске. Для разнесения по регионам этого хватает с запасом.

А вот если дело дойдёт до настоящих анонсов, там отдельной услугой оформляют сетевые ресурсы: регистрация автономной системы от десяти тысяч рублей, полный комплект с блоком /24 и сетью IPv6 дороже. Блок адресов можно и просто арендовать помесячно начиная с /29, чтобы не выкупать сразу весь /24. Оговорюсь честно: оформление ресурсов и возможность поднять с провайдером сессию BGP это две разные вещи, и вторую надо спрашивать у поддержки отдельно, под конкретную услугу. Реально такие анонсы живут на выделенных серверах и colocation, а не на младшем виртуальном тарифе.

Начинать я бы советовал с двух машин и записей в DNS с проверками. Это ноль дополнительных денег, закрывает большую часть задачи и заодно показывает, упираетесь ли вы вообще в то, что лечится anycast.

Короткий итог

Anycast это один блок адресов, объявленный по BGP из нескольких мест. Маршрутизация сама разводит клиентов, клиент ничего не выбирает и ничего не знает.
«Ближайший» означает лучший по критериям операторов, а не географически близкий. География получается побочным эффектом.
Тринадцать корневых серверов это тринадцать адресов и больше двух тысяч работающих экземпляров у двенадцати независимых организаций.
Двенадцати точек достаточно для хорошей задержки по всему миру, по выводам исследования четырёх реальных развёртываний. Две на континент.
Около 20% клиентов попадают не в оптимальную точку, по измерениям на данных поисковика Bing. Anycast даёт хорошее среднее, а не точность.
Порог входа: блок не меньше /24, свой номер системы, провайдер с BGP. Блоки меньше /24 в интернете не маршрутизируются.
Цена входа порядка семи-восьми тысяч долларов за блок по рыночной цене, либо около восьмидесяти долларов в месяц за аренду, плюс оформление номера системы.
Дешёвая альтернатива это DNS с проверкой доступности: стоит ноль, точность выше, скорость переключения ограничена TTL и кэшами.
Две вещи дешёвым вариантом не повторить: размазывание атаки по всем точкам и переключение за секунды без ожидания кэшей.
При аудитории из одной страны не нужно ни то, ни другое. Один сервер рядом с людьми обгонит три далеко.

Главная мысль такая. Anycast оказывается побочным свойством маршрутизации, которым научились пользоваться, и ничем больше. Дешёвым он при этом не бывает: минимальный вход упирается в блок из 256 адресов. Зато задача, ради которой его обычно хотят, в девяти случаях из десяти решается двумя дешёвыми машинами и правильно настроенными записями DNS. А понимание разницы между этими двумя вариантами стоит ровно столько, сколько вы потратили на чтение.

Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

Сторонний мой проект: Zapret2UI.