Аннотация

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

Для решения такого рода задач мы в Facebook создали и развернули Edge Fabric — систему на основе SDN (программно‑конфигурируемая сеть), которая обслуживает более двух миллиардов пользователей из десятков точек присутствия на шести континентах. В этой статье мы впервые предоставляем публичную информацию о сетевых возможностях провайдера такого масштаба, а также связанные с этим потенциал и сложности. Мы постарались описать, как Edge Fabric работает в режиме почти‑реального времени, чтобы избежать перегрузки каналов связи в сетевой периферии Facebook.

Наша оценка производственного трафика по всему миру наглядно демонстрирует, как Edge Fabric эффективно использует межсетевые соединения, не перегружая их и не снижая производительности. Мы также демонстрируем измерение производительности доступных маршрутов в режиме реального времени и изучение возможности их включения в решения по маршрутизации. Мы рассказываем о проблемах, их решениях и уроках, полученных за четыре года эксплуатации и развития Edge Fabric.

1. Введение

Интернет‑трафик сегодня имеет совершенно другие характеристики, нежели десять лет назад. Трафик все больше исходит от небольшого числа крупных поставщиков контента, облачных провайдеров и сетей доставки контента. Сегодня только десять автономных систем генерируют 70% трафика [20], тогда как в 2007 году, чтобы сгенерировать такую долю, требовались тысячи автономных систем [15]. Эта консолидация контента во многом связана с ростом потокового видео, которое в настоящее время составляет большую часть трафика в Северной Америке [23]. Этот видеотрафик требует высокой пропускной способности и накладывает на задержку ограничения мягкого реального времени (soft real‑time), ведь качество доставки может повлиять на пользовательский опыт [6].

Чтобы доставлять этот колоссальный объем притязательного трафика и повысить доступность и воспринимаемую пользователями производительность, этим провайдерам пришлось изменить топологию интернета. Они обслуживают своих пользователей из многочисленных точек присутствия (PoP), разбросанных по всему миру [3], через которые они соединяются с множеством других автономных систем [15]. Точка присутствия обычно имеет несколько доступных маршрутов для доступа к пользовательской сети, что увеличивает вероятность того, что найдется «короткий» путь [5]. Это богатое межсетевое взаимодействие дает провайдерам контроль над большими фракциями маршрутов [15] и в совокупности обеспечивает необходимую пропускную способность. Напротив, традиционная иерархия интернет‑провайдеров [15] может испытывать трудности с обеспечением пропускной способности, необходимой для удовлетворения быстро растущего спроса на контент.

Хотя такие широкие сетевые возможности потенциально обеспечивают повышение производительности, поставщики приложений сталкиваются с трудностями при реализации этих преимуществ. Поразительно то, что, несмотря на эти огромные изменения в доставке трафика и топологии, по которой он доставляется, протокол, используемый для маршрутизации трафика по этой топологии, а именно BGP (протокол пограничного шлюза), практически не изменился, и даже существуют значительные препятствия для его замены [5, 22]. Хотя впечатляет и то, что BGP кое‑как приспособился к этим изменениям. Но все‑таки он плохо подходит для задачи доставки больших объемов консолидированного трафика по плоской топологии:

BGP не учитывает пропускную способность. Соединения и маршруты имеют ограниченную пропускную способность. Наши замеры для сети крупного поставщика контента показывают, что он не может получить достаточную пропускную способность во многих соединениях для маршрутизации всего трафика по путям, предпочитаемым его политикой BGP. Решения провайдера по маршрутизации должны учитывать эти ограничения, особенно потому, что провайдер может вызвать перегрузку огромными объемами видеотрафика с адаптивным битрейтом, который расширяется, чтобы увеличить битрейт, когда пропускная способность это позволяет.
BGP не учитывает производительность. Перенаправление трафика из любой точки присутствия на IP‑префикс по лучшему маршруту, выбранному BGP, не гарантирует оптимальную производительность. Атрибуты, на которые BGP опирается при выборе маршрута, такие как длина маршрута в автономной системе и дискриминаторы с несколькими выходами (MED), не всегда коррелируют с производительностью. Переопределить выбор BGP маршрута на выбор маршрута с учетом производительности сложно по нескольким причинам. Во‑первых, BGP не включает информацию о производительности, а решения, учитывающие производительность, требуют внешнего механизма для сбора данных о производительности. Во‑вторых, относительная производительность маршрутов к месту назначения может меняться со временем (например, в ответ на нагрузку), но BGP изменяет маршруты только в ответ на изменения в политике или наборе доступных маршрутов. В‑третьих, провайдеру может потребоваться измерять несколько неэквивалентных маршрутов в режиме почти‑реального времени, чтобы отслеживать относительную производительность, однако BGP по традиции позволяет использовать только один маршрут для достижения пункта назначения в любой момент времени. В‑четвертых, поскольку BGP позволяет только один маршрут для каждого пункта назначения, он в корне не поддерживает назначение чувствительного к производительности трафика и эластичного трафика по разным маршрутам, чтобы наилучшим образом обходить ограничения пропускной способности на лучших маршрутах.

Хотя эти ограничения уже давно известны, в нашей статье обсуждается, как они проявляются в производственной среде. В этой статье представлен наш опыт решения этих проблем в Facebook — компании, которая задействует десятки точек присутствия для обслуживания двух миллиардов пользователей практически во всех странах мира. Мы ведем работу в трех основных направлениях.

Во‑первых, поскольку влияние упомянутых выше ограничений BGP зависит от структуры сети, мы говорим о такой топологии сети и характеристиках трафика, при которых поставщикам популярных приложений сложно управлять своим исходящим трафиком. В Facebook точки присутствия обычно имеют четыре или более маршрутов ко множеству клиентских сетей. Хотя многие межсетевые соединения в США имеют избыточную пропускную способность [8], по нашим измерениям в 20 точках присутствия, 10% выходных интерфейсов испытывают период, в течение которого политика BGP Facebook приводит к тому, что BGP назначает вдвое больше трафика, чем пропускная способность интерфейса!

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

Во‑вторых, мы представляем архитектуру Edge Fabric — системы для оптимизированной маршрутизации исходящего трафика. Edge Fabric получает маршруты BGP от пиринговых маршрутизаторов, отслеживает пропускную способность и спрос на исходящий трафик и определяет, как распределить трафик по маршрутам. Edge Fabric реализует свой выбор маршрутов, внедряя их (используя BGP) в пиринговые маршрутизаторы, заменяя там то, что выбрал BGP. Edge Fabric работает в продакшене уже более четырех лет. Мы оцениваем, как Edge Fabric работает в производственной среде, и рассказываем, как архитектура Edge Fabric развивалась с течением времени. Кроме того, мы обсуждаем технические проблемы, с которыми сталкивается Facebook, и извлеченные из них уроки.

В‑третьих, мы используем Edge Fabric для постоянного измерения производительности по альтернативным маршрутам для каждого префикса, а не только для лучшего выбора. Edge Fabric собирает эти метрики, направляя небольшую часть трафика на каждый префикс по альтернативным маршрутам. Наши метрики для 4 точек присутствия показывают, что 5% префиксов могут наблюдать снижение средней задержки на 20 и более мс при выборе альтернативы предпочтительному маршруту, выбранному BGP.

2. Сеттинг

2.1. Точки присутствия

Чтобы сократить задержку для пользователей, Facebook развернул точки присутствия (Points of Presence — PoP) в десятках мест по всему миру. PoP обслуживает пользователей из серверных стоек, которые подключаются через коммутаторы промежуточной агрегации (Aggregation Switches — ASW) к нескольким пиринговым маршрутизаторам (Peering Routers — PR), как показано на рисунке 1. ASW поддерживают BGP‑сессии с PR и коммутаторами стойки. Каждая точка присутствия включает в себя несколько пиринговых маршрутизаторов (PR), которые обмениваются BGP маршрутами и трафиком с другими автономными системами (AS). Использование нескольких точек присутствия снижает задержки двумя способами: 1) они кэшируют контент для непосредственной отправки пользователям и 2) когда пользователю все‑таки необходимо связаться с дата‑центром, TCP‑соединение пользователя завершается в точке присутствия, которая поддерживает отдельные соединения с дата‑центрами, пользуясь преимуществами разделения терминации TCP [9] и TLS.

Рисунок 1: В точке присутствия есть пиринговые маршрутизаторы, коммутаторы агрегации и серверы. Частная глобальная сеть (WAN) подключается к дата-центрам и другим точкам присутствия.

Только одна точка присутствия объявляет каждый most(more?)‑specific префикс Facebook, поэтому точка присутствия, через которую трафик поступает в сеть Facebook, зависит только от IP‑адреса назначения (покрывающий префикс, объявляемый в точках присутствия, защищает от черных дыр, если more‑specific маршрут не был передан маршрутизатору). Глобальная система балансировки нагрузки назначает пользователей точкам присутствия через DNS (возвращая IP‑адрес конкретной точки присутствия в ответ на DNS‑запрос текущего имени хоста) и путем внедрения URL‑адресов, специфичных для точки присутствия, в ответы (которые разрешаются только в IP‑адреса в конкретной точке присутствия). Подобно аналогичным системам [4], она вводит измерения, чтобы зафиксировать производительность для пользователей из альтернативных точек присутствия.

Система балансировки нагрузки использует эти измерения, чтобы направить пользователей к их точкам присутствия с «наилучшей» производительностью (с учетом ограничений, таких как пропускная способность; точки присутствия, которые в настоящее время не обслуживают пользователей по техническим причинам, из‑за устранения неполадок или тестирования; и соглашений с другими сетями). Для 80% пользовательских сетей она направляет все запросы из сети в одну (ближайшую) точку присутствия (в течение дня в январе 2017 г.). Детали балансировки нагрузки выходят за рамки этой статьи, и мы разрабатываем Edge Fabric, предполагая, что он не может контролировать, какая точка присутствия обслуживает данного пользователя.

На рисунке 2 показан относительный объем трафика, обслуживаемого 20 точками присутствия — подмножеством, выбранным из‑за географического разнообразия и разнообразия подключений, которые в совокупности обслуживают большую часть трафика Facebook. В статье эти точки присутствия последовательно упоминаются по номерам, упорядоченным по объему. На этих точках присутствия 95% трафика приходится на клиентов с ≈ 65 000 префиксов (в течение дня в январе 2017 г.). Беря в расчет только клиентские префиксы, необходимые для учета 95% трафика точки присутствия, на рисунке 3 показано, что каждая точка присутствия обслуживает от ≈ 700 до ≈ 13 000 префиксов, а 16 точек присутствия отправляют 95% своего трафика менее чем 6500 префиксам.

Рисунок 2: Относительный объем исходящего трафика (округленный) для 20 точек присутствия.

Рисунок 3: Количество префиксов BGP, составляющих 95% трафика точек присутствия.

2.2. Междоменное сетевое взаимодействие

BGP‑подключения PR к другим AS бывают разных типов:

Транзитные провайдеры предоставляют маршруты ко всем префиксам через частный сетевой интерконнект (PNI) с выделенной пропускной способностью исключительно для трафика между Facebook и провайдером.
Пиры (одноранговые узлы) предоставляют маршруты к префиксам пира и к префиксам в его клиентском конусе [18]. Пиры различаются по типу подключения:
Приватные пиры: PR подключается к пиру через выделенный PNI.
Публичные пиры: BGP‑сессия PR к пиру и трафик к пиру проходят через общую структуру точки обмена интернет‑трафиком (IXP).
Пиры сервера маршрутизации: PR получает маршруты пиров косвенно через сервер маршрутизации [2] и обменивается трафиком через IXP‑фабрику.

Точка присутствия может поддерживать несколько пиринговых BGP‑сессий с одной и той же AS (например, приватный пиринг и публичный пиринг, или на нескольких PR). Большинство точек присутствия подключаются к двум и более транзитным провайдерам, при этом каждый транзитный провайдер поддерживает BGP‑сессию с двумя и более PR точек присутствия для поддержания пропускной способности и обеспечения отказоустойчивости. Когда это возможно, все PR поддерживают равную пропускную способность PNI для данного пира, хотя иногда некоторые PR имеют разную пропускную способность или вообще не подключаются к пиру.

В общем, мы настроили сеть Facebook таким образом, чтобы поток исходил только в той точке присутствия, в которую поток входит, а не маршрутизировался через глобальную сеть с серверов в одной точке присутствия на исходящие ссылки в другой точке присутствия. Изоляция трафика в точке присутствия снижает нагрузку на магистраль, упрощает решения о маршрутизации и повышает стабильность системы (§ 8,1.3). Даже с учетом этого упрощения у Facebook есть различные варианты маршрутизации. На рисунке 4 показано распределение количества маршрутов, которые каждая точка присутствия может выбрать для доступа к префиксам, составляющим 95% ее трафика. Если пир предоставляет один и тот же путь через публичный пиринг и сервер маршрутизации, или если несколько PR получают один и тот же маршрут от одного и того же пира, мы учитываем его только один раз. Хотя это и не следует из графика (который объединяет пункты назначения с 1–3 маршрутами), все точки присутствия, кроме одной, имеют как минимум два маршрута к каждому пункту назначения, и многие имеют четыре или более маршрутов к большинству префиксов.

Рисунок 4: # маршруты к префиксам, на долю которых приходится 95% трафика точек присутствия.

Мы настраиваем PR так, чтобы они предпочитали одноранговые маршруты транзитным маршрутам (через local_pref), опираясь на длину маршрута в автономной сети в разрешении конфликтов. Когда маршруты остаются привязанными, PR отдают предпочтение маршрутам из следующих источников в следующем порядке: приватные пиры > публичные пиры > сервера маршрутизации (Мы снижаем приоритетность нескольких приватных пиров по сравнению с публичными из соображений политики, но в контексте данной статьи эффект от этого незначителен). Мы кодируем тип пира в MED (и удаляем MED, установленные пиром, которые обычно выражают предпочтения пира в отношении точек пиринга, но не имеют значения, учитывая, что Facebook выпускает поток трафика в точке присутствия, где он входит).

Предпочтение пиринговых перед транзитом означает, что AS, взаимодействующая с Facebook, ожидает получать свой трафик по этой ссылке. Кроме того, мы обнаружили, что пиринговые маршруты часто имеют лучшую производительность и меньший риск перегрузки в нисходящем направлении. Короткие пути AS могут быть более прямыми или доставлять трафик к AS назначения раньше [5]. Предпочитая выделенную пропускную способность приватного пиринга соединению через публичную IXP‑фабрику, наша политика позволяет избежать возможности перекрестной перегрузки на выходе и учитывает, что пир выделяет ресурсы для получения трафика Facebook.

Мы настроили BGP на PR и ASW для использования многопутевого протокола BGP. Когда PR или ASW имеет несколько эквивалентных лучших BGP маршрутов для одного и того же префикса пункта назначения (как определено алгоритмом BGP для выбора лучшего маршрута), он распределяет трафик по эквивалентным маршрутам, используя многопутевую маршрутизацию с равной стоимостью (ECMP).

В целом, Facebook имеет тысячи одноранговых AS. Таблица 1 показывает, например, долю пиров каждого типа для нескольких точек присутствия. Каждая отраженная точка присутствия имеет в общей сложности сотни пиров, что обеспечивает широкие возможности подключения. В таблице также показана доля трафика, которую каждая точка присутствия может обслуживать по типу пира (при условии, что весь трафик назначается наиболее предпочтительному маршруту без учета пропускной способности). Хотя приватные пиры составляют не более четверти пиров в любой точке присутствия, они в целом получают большую часть трафика, кроме точки присутствия 11. Типично использовать выделенную пропускную способность приватных интерконнектов для пиринговых соединений с большими объемами. Во всех, кроме 11-й точки присутствия, 80+% трафика уходит на приватные и публичные пиры, и пиры серверов маршрутизации, а не на транзит, что есть яркий пример того, как сегодняшние крупные провайдеры «выравнивают» интернет [5, 15]. Однако распределение типов пиров в точках присутствия сильно варьируется по количеству и трафику.

Таблица 1: Доля пиров и трафика к пирам различных типов на примерах точек присутствия в Европе, Азии и Северной Америке. Пир с приватным и публичным соединением будет учитываться в обоих случаях. Пир с публичным соединением и сервером маршрутизации считается публичным (у них общий порт IXP). Трафик на публичные пиры и серверы маршрутизации объединяется.

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

Инжиниринг исходящего трафика с Edge Fabric. Часть 1