Я хочу получить любую трансляцию для моего веб-сервиса, но я не могу найти никакой информации о том, как этого добиться, или какой-либо компании, которая могла бы помочь.
Я нашел множество компаний, предлагающих Anycast DNS, но это не то, что мне нужно.
У меня есть веб-служба без отслеживания состояния, которую я хочу распределить географически, используя anycast для балансировки нагрузки и увеличения времени безотказной работы. Есть ли какие-либо технические причины, по которым компания не может просто рекламировать для меня IP-адрес в нескольких центрах обработки данных?
О каких технических аспектах Anycasting мне нужно знать, чтобы оценить существующие предложения и помочь мне найти компании, которые могут мне помочь? Какие подводные камни мне нужно остерегаться?
Есть два отдельных аспекта anycast, которые необходимо понять, чтобы удовлетворить ваш конкретный запрос. Первая часть - это то, как анонсируются и маршрутизируются адреса anycast. Во-вторых, каковы проблемы TCP с произвольным адресом и как их можно решить.
Объявление и маршрутизация
Чтобы сохранить приемлемый размер таблицы BGP, большинство AS будет фильтровать входящие объявления, если префиксы слишком длинные. Для IPv4 порогом обычно является префикс / 24, что означает 256 адресов. Это означает, что для трансляции в общедоступном Интернете вам потребуется как минимум 256 адресов.
Если у вас уже есть собственный префикс / 24, то хостинг-провайдер вряд ли сможет объявить его от вашего имени. Если это так, anycasting может быть для вас таким же простым, как поиск множества разных хостинг-провайдеров, готовых предоставить эту услугу по правильной цене. Затем вы просто попросите их всех объявить префикс от вашего имени.
Вы можете просмотреть общедоступную информацию о рекламируемых маршрутах, чтобы найти поставщиков, которые уже объявляют префиксы от имени своих клиентов, чтобы указать вам поставщиков, которые могут предложить такой вид услуг. Один из инструментов для поиска этого в таблицах маршрутизации: bgp.he.net.
Если у вас нет собственного префикса и вы хотите получить его от провайдера, важно понимать, что упомянутые выше ограничения означают для этого провайдера.
У провайдера достаточно IP-адресов, чтобы они могли настроить произвольный префикс. Однако, как только они это сделают, они обязались использовать все 256 адресов как anycast. И все 256 адресов должны быть размещены в одном и том же наборе местоположений.
По этой причине вы иногда видите 256 адресов, выделенных для того, чтобы использовать только один из них для какой-либо услуги. Возможно, это первая возможность для вас. Провайдер, уже использующий произвольный префикс, может иметь 250 неиспользуемых произвольных адресов. Если ваша услуга достаточно «интересна» для провайдера, он может согласиться арендовать вам хостинг на одном из оставшихся адресов. Одно важное предостережение заключается в том, что вы должны быть размещены в тех же местах, что и их основная служба 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, будет почти идеально сбалансированной. В описанной выше настройке с распределенным уровнем балансировки нагрузки сами балансировщики нагрузки могут не получать равномерную нагрузку, но они могут равномерно распределять нагрузку между бэкэндами.
Не полагайтесь на один-единственный IP-адрес для обеспечения доступности. Если один из ваших узлов выходит из строя, маршрутизация может не подобрать его автоматически. Это не влияет на всех клиентов, но подмножество клиентов может направлять свои пакеты на узел, который не работает. Следовательно, для этих клиентов ваш произвольный IP-адрес не работает. Если вам нужна избыточность, вам понадобится несколько произвольных IP-адресов.
Задержка может быть хорошей, если маршруты не меняются в середине соединения. Но как только рукопожатие TCP завершится, вы обязуетесь использовать конкретный бэкэнд на время TCP-соединения. Пакеты должны идти от клиента к балансировщику нагрузки, к бэкэнду и к клиенту. Эта треугольная маршрутизация может увеличить задержку. Существует сокращение задержки от anycast и возможность выбора ближайшего бэкэнда, но наличие трех ветвей на пути туда и обратно, а не только двух, может увеличить задержку. Только сбор большого количества реальных измерений скажет вам, какой из двух факторов весит больше.
Эта реалистичная статья также может помочь https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality
LinkedIn использовал систему мониторинга реальных пользователей, чтобы оценить, будет ли глобальная трансляция Anycast более эффективной, чем региональная. В конце концов, они реализовали и фактически внедрили региональный Anycast, в котором разные адреса Anycast использовались для другого региона. Они используют сочетание балансировки нагрузки на основе DNS и регионального Anycast.
Упомянутое выше решение является хорошим, поскольку оно в некоторой степени обеспечивает разделение между местоположениями и идентификаторами серверов, но оно основано на туннелировании. Я считаю, что гораздо лучше будет использовать тот же подход разделения без туннелирования, но тогда его реализация на этот раз весьма ограничена. Это в настоящее время активно исследуется, например, Управление трафиком через ILNP (сетевой протокол идентификатора локатора) дает ответы на эти запутанные вопросы. ура
Вам нужно будет согласовать физическое оборудование веб-сервера с сетевым провайдером, который сделает все за вас.
Если вы пойдете по этому маршруту, вы, вероятно, также захотите настроить туннель к картам управления (drac и т. Д.) На машинах, чтобы вам не приходилось посещать их на месте.
Мы делаем это для нашего сайта.