Как я могу получить anycast для моих серверов?

Есть два отдельных аспекта о anycast, которые необходимо понять, чтобы удовлетворить ваш конкретный запрос. Первая часть - как анкаст-адреса рекламируются и маршрутизируются. Во-вторых, каковы проблемы в TCP с адресом anycast и как их можно решить.

Объявление и маршрутизация

Чтобы поддерживать приемлемый размер таблицы BGP, большинство AS будет фильтровать входящие объявления, если префиксы слишком длинные. Для IPv4 порог обычно составляет префикс /24, что означает 256 адресов. Это означает, что для того, чтобы сделать anycast в общедоступном интернете, вам нужно как минимум 256 адресов.

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

Вы можете просмотреть общедоступную информацию о рекламируемых маршрутах, чтобы найти провайдеров, которые уже объявляют префиксы от имени своих клиентов, чтобы найти поставщиков, которые могут предложить этот вид услуг. Одним из инструментов для поиска этого в таблицах маршрутизации является http://bgp.he.net/.

Если у вас нет собственного префикса и вы хотите получить его от поставщика, важно понять, что ограничения, указанные выше, означают для этого поставщика.

У провайдера достаточно IP-адресов, чтобы они могли настроить префикс anycast. Однако, как только они это сделают, они будут использовать все 256 адресов в качестве anycast. И все 256 адресов должны быть размещены в одном и том же наборе мест.

По этой причине вы иногда видите 256 адресов, выделенных для использования только одного из них для любой услуги. Это может быть первая возможность для вас. Поставщик, уже отправляющий префикс, может фактически иметь 250 неиспользуемых адресов anycast. Если ваш сервис достаточно интересен для провайдера, он может пожелать арендовать ваш хостинг по одному из оставшихся адресов. Одним из важных предостережений является то, что вы должны быть размещены в тех же местах, что и их основной сервис anycast. И, вероятно, потребуется соглашение, при котором они перемещают ваш сервис так, как они считают нужным, потому что именно их первичный анкастный сервис решает, где нужен хостинг.

Большинство из вышеперечисленного предполагает примерно 1:1 соответствие между тем, где провайдер предоставляет услугу и где они объявляют префиксы.

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

Например, если провайдер объявляет /22 в четырех различных POP, и у них есть избыточная сеть между ними (например, кольцо из четырех каналов), он может внутренне направить /24 или /25 к каждой POP и, возможно, отложить в сторону /28 должен быть передан всем POP (что фактически означает, что POP обслуживает их, когда пакеты сначала входят в их сеть).

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

TCP и anycast

Как отмечалось в некоторых комментариях, TCP является протоколом с состоянием. Поэтому, даже если вы считаете, что ваш веб-сервис не имеет состояния, он все еще имеет состояние на уровне TCP. Следствием этого является то, что наивно любое вещание службы на основе TCP будет приводить к тому, что пользователи будут очень часто сбрасывать соединение.

Эту проблему можно решить, разместив еще один слой перед реальными веб-серверами. Требуется слой узлов, который может пересылать полученные TCP-пакеты на соответствующий веб-сервер и последовательно делать это через соединение. Пока это в значительной степени описывает стандартный балансировщик нагрузки на основе DSR.

Однако, поскольку существует несколько экземпляров этого балансировщика нагрузки, они должны совместно использовать состояние. Распределенная хеш-таблица - это структура данных, которую можно использовать для этого уровня.

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

Типичные балансировщики нагрузки решают эту проблему, изменяя MAC-адрес назначения и пересылая его, тем самым обходя IP-маршрутизацию. Это работает только в том случае, если ваш балансировщик нагрузки и бэкэнды были расположены в одном месте и сеть между ними полностью переключена без каких-либо маршрутизаторов между балансировщиком нагрузки и бэкэндами.

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

В этой настройке исходный IP внешнего заголовка в основном не используется. В принципе это должен быть одноадресный адрес балансировщика нагрузки, получающего пакет. Однако некоторые службы (например, facebook) копируют IP-адрес клиента из внутреннего заголовка как IP-адрес источника во внешний заголовок. Эта ошибка со стороны Facebook может быть обнаружена извне, потому что иногда туннелированные пакеты вызывают ошибку ICMP, которая отправляется непосредственно клиенту.

Нет необходимости для внутреннего и внешнего заголовка использовать одну и ту же версию IP. Таким образом, одноадресные адреса, необходимые для подсистем балансировки нагрузки и бэкэндов, могут быть IPv6, так что количество подсистем балансировки нагрузки и бэкэндов не ограничено доступностью адресов IPv4.

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

Ловушки

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

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

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

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

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