Русский
Русский
English
Статистика
Реклама

Перевод Локальный TCP Anycast это действительно сложно

Pete Lumbis и Network Ninja в своих комментариях к моим записям, посвященным UCMP, упомянули интересный случай использования UCMP в центре обработки данных: а именно серверы anycast.

Вот типичный сценарий, который они упомянули: группа серверов, случайно подключенных к нескольким leaf-коммутаторам, предоставляет услугу на одном и том же IP-адресе (отсюда и происходит anycast).

Прежде чем вдаваться в подробности, давайте зададим себе простой вопрос: Работает ли это за пределами PowerPoint? Безусловно. Это идеальная конструкция для масштабируемой UDP-службы, такой как DNS, и крупные фермы DNS-серверов обычно строятся именно таким образом.


Сложности TCP Anycast

Действительно интересный вопрос: Работает ли это для сервисов TCP? Теперь мы подходим к действительно сложной части - поскольку spine и leaf-коммутаторы выполняют ECMP или UCMP в отношении anycast IP-адреса. Кто-то должен следить за назначениями сессий серверам, иначе весь хаос выйдет из-под контроля.

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

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

Потеря соединения и узла

Большинство серийных разработок ECMP используют хэш-бакеты (подробнее), и если количество next-hops (соседние маршрутизаторы) меняется из-за изменения топологии, хэш-бакеты переназначаются, отправляя большую часть трафика на сервер, который понятия не имеет, что с ним делать. Современные варианты реализации ECMP позволяют избежать этого с помощью согласованного хэширования. Согласованное хэширование позволяет избежать повторного вычисления хэш-бакетов после изменения топологии:

Хеш-бакеты для действительных next-hops не трогаются.

Недействительные хэш-бакеты (из-за недействительного next-hop) переназначаются на действительные next-hops.

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

Добавление новых серверов

Самое интересное начинается, когда вы пытаетесь добавить сервер. Для этого коммутатор последнего хопа должен взять несколько бакетов из каждого действительного next-hop и назначить их новому серверу. Это очень трудно сделать, не нарушив работу сервера2. Даже ожидание того, пока бакет не станет нерабочим (подход балансировки нагрузки флоулетов), не помогает. Нерабочий бакет не означает, что нет активной TCP-сессии, использующей его.

И, наконец, ICMP: ICMP-ответы включают оригинальные номера портов TCP/UDP, но ни один аппаратный коммутатор не в состоянии копаться в пакете так глубоко, поэтому ICMP-ответ обычно отправляется на какой-то случайный сервер, который понятия не имеет, что с ним делать. Добро пожаловать в хаос PMTUD.

Обеспечить работу Локальный TCP Anycast

Значит ли это, что невозможно выполнить локальную балансировку нагрузки TCP anycast? Конечно, нет - каждый гипермасштабируемый центр обработки данных использует этот трюк для реализации масштабируемой балансировки нагрузки в сети. Инженеры Microsoft писали о своем решении в 2013 году, Fastly задокументировал свое решение в 2016 году, у Google есть Maglev, Facebook открыла Katran, мы знаем, что у AWS есть Hyperplane, но все, что мы получили из видеороликов re:Invent, - это потрясающая магия. На конференции Networking @Scale 2018 они рассказали еще несколько подробностей, но это все еще было на уровне Karman.

Вы можете сделать нечто подобное в гораздо меньшем масштабе с кластером firewalls или балансировкой нагрузки (при условии, что вашему поставщику удастся посчитать больше двух активных узлов), но производительность кластеров сетевых служб обычно далека от линейной - чем больше блоков вы добавляете в кластер, тем меньше производительности вы получаете с каждым дополнительным блоком - из-за обслуживания состояния кластера в целом.

Существует, по крайней мере, несколько программных решений с открытым исходным кодом, которые можно использовать для создания крупномасштабных служб anycast TCP. Если вы не чувствуете себя комфортно при использовании таких "горячих" новинок, как XDP, есть BalanceD от Demonware, использующий Linux IPVS.

С более академической стороны, есть Cheetah... и в радужном будущем мы, возможно, получим довольно оптимальное решение, напоминающее сеансовый уровень с Multipath TCP v1.

Для изучения


Прямо сейчас мы в OTUS запускаем специализацию Network Engineer. В связи с этим приглашаем всех желающих на демоурок по теме: "Технологии прошлого. RIP". В рамках урока рассмотрим протокол динамической маршрутизации RIP. Плюсы и минусы технологии. Разберем, почему не используется в продакшн, но где еще нужен, а также какие протоколы пришли ему на замену. Протокол RIP в своей простоте настроек и работы наглядно продемонстрирует логику работы протоколов динамической маршрутизации. Даст понимание о возможностях и необходимости использования такой маршрутизации.

Источник: habr.com
К списку статей
Опубликовано: 17.06.2021 18:06:38
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании otus

Сетевые технологии

Data center

Tcp

Anycast

Категории

Последние комментарии

  • Имя: Билал
    04.12.2024 | 19:28
  • Имя: Murshin
    13.06.2024 | 14:01
    Нейросеть-это мозг вселенной.Если к ней подключиться,то можно получить все знания,накопленные Вселенной,но этому препятствуют аннуннаки.Аннуннаки нас от неё отгородили,установив в головах барьер. Подр Подробнее..
  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru