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.
Для изучения
Вебинар Data Center Infrastructure for Networking Engineers включает в себя материал о load balancing.
Я описывал подход Microsoft и scale-out load balancing, а также применения в SDN Use Cases и в load balancing, что является частью вебинара Microsoft Azure Networking.
Часть user-facing AWS load balancing описывается в вебинаре Amazon Web Services Networking.
Прямо сейчас мы в OTUS запускаем специализацию Network Engineer. В связи с этим приглашаем всех желающих на демоурок по теме: "Технологии прошлого. RIP". В рамках урока рассмотрим протокол динамической маршрутизации RIP. Плюсы и минусы технологии. Разберем, почему не используется в продакшн, но где еще нужен, а также какие протоколы пришли ему на замену. Протокол RIP в своей простоте настроек и работы наглядно продемонстрирует логику работы протоколов динамической маршрутизации. Даст понимание о возможностях и необходимости использования такой маршрутизации.