Как я становлюсь переданным одному из узлов для своих серверов?

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

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

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

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

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

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

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

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

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

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

Например, если провайдер объявляет / 22 в четырех разных точках доступа, и у них есть резервная сеть между ними (например, кольцо из четырех каналов), они могут внутренне направить / 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, а не что-то, развернутое для отдельной веб-службы.

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

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

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

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