1. Проблематика
Целью данной статьи является попытка практической рационализации архитектурной модели S&L(Spine&Leaf), которая сегодня широко применяется при построении сетевой инфраструктуры в датацентрах. Основным фокусом автора являются проблемы практического применения данного типа архитектуры на высоконагруженных сервисах, в частности, на инфраструктуре оператора сети доставки контента.
Выбор столь узкой проблематики продиктован с одной стороны — опытом проектирования, строительства и эксплуатации автором статьи реальной сетевой инфраструктуры оператора сети доставки контента, с другой стороны — возникшими фундаментальными вопросами к реализации теоретической модели в реальном датацентре и на реальном оборудовании.
В частности, основная проблема с которой приходится сталкиваться — это проблема портовой емкости. Ведь, каждый spine-коммутатор должен быть связан с leaf-коммутаторами каналами достаточной емкости, но если на сети приходится иметь дело с тяжелым трафиком (VOD, онлайн‑трансляии), то каждый из узлов CDN может генерировать трафик, трех‑ или четерх‑ кратный объем которого может полностью утилизировать полосу 100Гбит/с. В этой ситуации существует вполне разумное решение увеличить ширину канала между spine и таким leaf куда включены подобные сервера сети. Но данное решение, в условиях использования коммутаторов класса datacentre может серьезно уменьшить количество портов, которые используются для включения интерконнектов всех уровней (spine‑spine, spine‑leaf, leaf‑leaf). Если же следовать экстенсивному пути развития этой архитектуры, и наложить серьезные структурные ограничения на возможности соединений типа leaf‑leaf с попутным масштабированием структуры по размеру, при этом стараясь сохранить потребную для каждого типа трафика необходимую полосу, то очень быстро возможно прийти к вопросам экономической целесообразности, а также, что более важно с точки зрения высокой доступности сервиса — возможности резервирования как самого сетевого оборудования так и доступности внешних каналов.
2. Условия применимости рассматриваемых моделей.
Прежде всего оговоримся, что далее мы будем рассматривать работу сетевой инфраструктуры в рамках резервированной на программном уровне сети доставки контента. Это означает, что подразумевается такая программная модель CDN, что падение одного физического сервера (ноды) не приводит к остановке сервиса, а приводит к переводу или перераспределению нагрузки между другими нодами кластера.
Также отдельно отметим, что рассматриваемая ситуация и модели применимы к датацентрам, которые не относятся к топ‑классу. Сегодня подавляющее большинство коммерческих датацентров в России (Москва, Санкт‑Петерубрг, Екатеринбург, Новосибирск Иркутск, Хабаровск) предлагает чаще всего электрическую емкость 5кВт (с резервированием двумя «лучами» или без, данные сведения были собраны за период с января 2024 по сентябрь 2024 года). Так как основная задача CDN — это обеспечить раздачу контента из места как можно ближе (в сетевом смысле) к конечному потребителю, что продиктовано соображениями минимизации RTT, то мы или будем сильно ограничены по предлагаемым в датацентре условиям, или же необходима модель предусматривающую возможности самой гибкой адаптации к местным условиям. Поэтому, мы исходим из условий, когда на стойку 48U выделяется средняя стандартная электрическая мощность — 5кВт. Учитывая тот факт, что на большой локации сети необходимо размещать большое количество нагруженных сетевым трафиком серверов с большими объемами дисковых массивов — это ставит серьезные ограничения по энергетике для каждой стойки.
Вышесказанное, в свою очередь, влияет на форм‑фактор выбираемого сетевого оборудования (в подавляющем случае — маршрутизирующих коммутаторов), его портовую емкость и энергетические эксплуатационные параметры. В частности, исходя из баланса технических условий и финансово‑экономических показателей, первым выбором чаще всего являются коммутаторы серий адаптированных под датацентры форм‑фактора 1–2U.
3. Проблема портовой емкости как основная
Проблема распределения и оптимального использования портовой емкости на узле CDN с высокой нагрузкой — это основная проблема с которой нам пришлось столкнуться в процессе проектирования новых и модернизации старых наших узлов(локаций). Структурно каждая локация представляет из себя от 1 до 3–4 стоек. Нами изначально была применена архитектура spine&leaf, но в силу естественных причин роста и развития, наша реальная инфраструктура не была «чиста» в плане архитектурном — горизонтальные связи типа L‑L(leaf‑leaf), пиринговые присоединения на leaf'ах, «последовательная» группировка leaf'ов — все это существовало, и со временем, из‑за значительного роста трафика это стало для нас представлять проблему из‑за возникновения многих точек на сети склонных к перегрузкам на большом трафике.
Вышесказанное относится практически к подавляющему количеству сетевых инфраструктур, которые выросли из маленьких проектов. И это нормально, но самым главным этапом на пути этого роста — это верный выбор не только архитектурной модели сети, которая должна учитывать конкретные особенности бизнеса и трафика, но и обеспечивать масштабируемость без больших капитальных затрат.
Сегодня сети доставки контента обслуживают практически весь спектр медиа‑данных. Начиная от мелкой статики и заканчивая VOD и онлайн трансляциями. Данная ситуация навязывает оператору сети в том числе и требования по классификации трафика (traffic affinity), что в свою очередь, приводит и к раздельному обслуживанию трафика. Таким образом мы приходим к тому, что разные типы трафика обслуживаются на разных нодах локации. Каждая категория трафика обладает своим уникальным профилем — это касается как временных характеристика(волнообразность трафика или его равномерность в течении суток) так и качественно‑количественных характеристик(проектируемая мощность ноды на отдачу трафика, соотношение входящего и исходящего на порту ноды, его способность по распределению между аплинками и пирами локации или же наоборот — его поляризация в какой‑то аплинк или пиринг).
В целом, если говорить о больших локациях, то на сети приходится иметь дело с широким спектром трафика, который, в идеальной ситуации равномерно и пропорционально заполняет аплинки и пиринги на локации.
Однако, как было ранее отмечено, разные ноды раздают по разному, и поэтому здесь возникает вопрос в планировании портовой емкости под все типы traffic affinity, учитывая все неравномерности и колебания трафика, запроектированную пиковую нагрузку, а также требования по работе без перегрузки как внешних так и внутреннних по отношению к локации.
В этой задаче мы рассмотрим несколько возможных моделей планирования портовой емкости с целью определить самые оптимальные, но стараясь не выйти за пределы архитектуры S&L, а также за условия обозначенные ранее.
Также следует сделать важное замечание. В рамках внутренних соединений на локации мы считаем важным переход на порты с линейными скоростями 25/40/100Gbit/s. Это продиктовано несколькими обстоятельствами: объем нагрузки на ноды, в особенности, которые обслуживают тяжелые виды трафика(Live video или VOD), распространенность сегодня как сетевых карт на 25Gbit/s так и коммутаторов с комбинированными портами 10/25G, неэффективность использования портовой емкости коммутатора при обслуживании скоростей раздачи более 30Gbit/s(для таких соединений нужно включать ноды агрегатами из 10G портов, одновременно появляются издержки на расходные материалы, а также такие агрегаты требуют большего внимания при эксплуатации, и особенно тонкой настройки со стороны ноды).
3.1 Равномерное распределение
Прежде всего мы рассмотрим такой способ использования портовой емкости на локации, что все сервера включаются равномерно как в leaf'ы так и частично в spine. И если для тех из них, которые оказываются подключенными непосредственно к spine не возникает каких‑либо ограничений по скорости раздачи, кроме как суммарной емкости апликнов, то для серверов вклюенных в leaf'ы возникает ограничение по пропускной способности канала S‑L(spine‑leaf). Эксплуатация же последовательно соединенных leaf'ов в таком случае становится еще более затруднительной, в силу полного исчерпания в таком случае портовой емкости под соединения между коммутаторами.
Поясним этот момент. В рассматриваемой модели мы стараемся включать ноды равномерно во все свитчи локации. В таком случае у нас в каждом свитче должно оказаться примерно поровну нод, который обслуживают разные traffic affinity. Соответственно объем суммарного трафика с каждого leaf планируется иметь примерно одинаковым. Включая только по одному leaf в порт spine, проблем не возникает так как не нужно планировать емкость для второго leaf'а. При его появлении же, нужно будет предусмотреть удвоенную емкость для соединения между spine и первым leaf, что равносильно его включению отдельно. Поэтому, более разумно будет его включить отдельным портом. Здесь мы косвенно находим первое существенное ограничение этой модели — ограничение полосы между spine и leaf, которое, как мы увидим далее является фундаментальным.
Но картина остается стабильной до тех пор, пока мы имеем дела с относительно умернным трафиком с leaf, и ноды подключенные в него в ЧНН отдают объем трафика не более чем 75% линейной скорости порта на коммутаторе(на самом деле это очень мало, учитывая тот факт, что каждую ноду мы включаем как минимум двумя линками, чтоб если даже один линк упал, то второй работал и ноды была доступна).
В этом случае максимальная эмпирическая нагрузка для 48-портового leaf-коммутатора с 6ю 100Gbit портами будет выглядеть как: (48x(10Gbit/s x 0,75)x0,5)x0,55 = 99Gbit/s. Коэффицент 0,55 был получен нами практическим путем как действующая величина поправки от неравномерности нагрузки. Применение коэффицента 0.5 связано с необходимостью включать ноду как минимум двумя портами в агрегате.
Как только мы захотим отдавать с ноды более чем 100% линейной скорости одного трибутарного порта на leaf'е мы очень быстро придем к существенным ограничениям по связи «наверх» — к spine. Прежде всего это связано с тем, что при портах 25G, тот факт, что есть необходимость раздавать с ноды 30–40Gbit/s в ЧНН ведет нас к быстрому исчерпанию 100Gbit соединения с spine.
В этом случае максимальная эмпирическая нагрузка для такого же leaf-коммутатора будет выглядеть как: (48x(10Gbit/s x 1,3) x 0,5) x 0,55 = 171,6Gbit/s. Конечно, такой трафик возможно пропустить только через 2 порта 100Gbit/s.
В этом случае можно было бы конечно перейти на горизонтальное расширение — принципиально ограничиться одной такой «тяжелой» нодой на leaf, а при необходимости добавления еще одной такой ноды — организовывать еще один leaf и к нему присоединять эту ноду. Однако, такая модель приведет к необходимости закупки в качестве spine коммутаторов с большим количеством 100G интерфейсов. В таком случае все leaf будут подключены к нему 1–2 соединением на 100G и проблема казалось бы исчерпана.
В этом случае проблема исчерпывается только на теоретическом уровне. Такие схемы могут быть эффективны только в развитых датацентах с большим количеством свободных стойко‑мест, и адекватным запасом по энергетике. Это касается в основном коммерческих датацентров в Москве и Санкт‑Петербурге. В регионах же, во‑первых мало где можно найти достаточно места под такие локации, а во‑вторых до сих пор существует проблема с наличием портов с линейной скоростью более 10G у операторов связи.
Отдельным ограничивающим условием становится тот факт, что не в каждом датацентре присутствует достаточное с точки зрения CDN количество операторов. Конечно, существует практика «партнерских локаций», которые размещаются у заинтересованных региональных операторов, объем трафика на которые достаточно высок(обычно крупные региональные операторы), но редко такие локации разрастаются на более чем одну стойку 48U. Поэтому, кроме «партнерских локаций» важно иметь по одной крупной локации как минимум на ФО(федеральный округ). В этом случае все партнерские локации расположенные в том же ФО будут снабжены не только качественным трафиком той affinity, что в нее была таргетирована, но и всеми остальными. В таких крупных региональных локациях все равно приходится проектировать достаточные емкости на раздачу трафика. Сегодня запросы на услуги CDN растут, на рынок приходят новые клиенты, и все чаще это клиенты с тяжелыми видами трафика. И здесь сеть доставки контента оказывается между потребностью обеспечить необходимую под все traffic affinity емкость под раздачу в регионе, и реальным наличием такой емкости у операторов — как портовой так и суммарной в регионе. Именно последним продиктована рекомендация располагать локации где имеется максимальное количество операторов — как федеральных так и региональных — чтобы не концентрировать весь трафик раздачи в одном операторе, у которого возможно существуют ограничения по ширине стыков с другими операторами в этом регионе, или что хуже, их в регионе нет вообще, а они находятся в соседнем. Здесь не стоит забывать о первоочередной задаче CDN — на раздаче быть ближе всего к конечному потребителю.
Таким образом, в реальных условиях предложенная выше модель становится трудноосуществимой в условиях необходимости множественного размещения. Выбор датацентра под локацию зажат в узких рамках технических и экономических требований. Это — и умеренная стоимость размещения, и отсутствие проблем по энергетике, наличие стойкомест, наличие нескольких операторов, у которых должны оказаться технические возможности на включение запрошенной емкости. В этих условиях, если наш spine в локации будет иметь только 100G порты, то для присоединения к оператору понадобится как минимум один коммутатор с портами 10/25G. Также не стоит забывать, что скорее всего в этот коммутатор будут включаться несколько других операторов, и его соединение со spine будет одной из точек отказа. Вопрос планирования портовой емкости по аплинки и пиринги останется за пределами этой статьи, однако, стоит сказать, что решение и этого вопроса на практике не всегда оказывается простым делом.
Подытоживая, можно сказать, что модель равномерного распределения нод между коммутаторами в локации видится излишне утяжеленной как по капитальным затратам так и по спектру вопросов, которые нужно будет решить попутно, если такую модель выбрать при включении нод раздающих на скоростях сопоставимых с 40Gbit/s. При этом, такая модель организации локации несет в себе значительное количество ограничений и необходимость организации множественных точек контроля. Также, ее возможности по масштабируемости напрямую связаны с капитальными затратами и расширением списка используемого сетевого оборудования, к которому нужно иметь ЗИП и/или возможность быстро купить и заменить вышедший из строя модуль или весь коммутатор целиком.
3.2 Распределение с учетом максимальной нагрузки
Существенно преодолеть проблемы предыдущей модели распределения нагрузки по портовой емкости мы можем если при выборе места включения ноды будем принимать во внимание ее способность к раздаче трафика. В частности, как ранее было указано, ноды раздающие в ЧНН на скорости больше чем линейная скорость одного порта (10 или 25 Gbit/s) являются основным моментом создающим проблемы и неоптимальное использование портовой емкости. Однако, если такие ноды включать непосредственно в spine портами по 25Gbit/s, а все остальные ноды не создающие столь тяжелый трафик включать в leaf‑коммутаторы, то можно достичь существенной оптимизации использования как портовой емкости так и соединений между spine и его leaf'ами.
Это достигается за счет того, что самые загруженные ноды локации оказываются ближе всего к аплинкам и пирам, и на этот трафик не требуется тратить емкость соединений между коммутаторами. А нагрузка от нод размер которой более адаптирован к линейной скорости портов оказывается включенной в leaf'ы, соединения к которым хоть и выполнены чаще всего соединениями на линейной скорости 40 или 100 Gbit/s, но все же обладают меньшей пропускной способностью, чем внутренняя шина коммутатора. В этом случае максимальная эмпирически рассчитанная нагрузка от leaf-коммутатора поддается расчету по первой формуле из предыдущего раздела.
В целом, за счет включения большой нагрузки как можно ближе к аплинкам (в порты spine или же в leaf'ы которые включены в него уже агрегатами из магистральных портов), можно добиться сбалансированности «дерева» по трафику. В особых случаях, если это позволяют объемы трафика, допускается подключение к одному leaf‑коммутатору другого leaf‑коммутатора. Несмотря на некоторых отход от архитектуры, эта схема включения позволяет сэкономить магистральные порты на spine‑коммутаоре, к которым обычно подключаются leaf'ы. Таким образом возможно выделять места включения сервисных систем, которые не обслуживают напрямую продуктовый трафик, но необходимы для функционирования внутренних систем(статистика, базы данных, хранение конфигурации и ее резервирование, различные репозитарии и пр.)
Можно, конечно, существенно возразить, что ничто не мешает ограничиться сравнительно небольшим трафиком также и для нод, которые обрабатывают тяжелый трафик. Но здесь действуют соображения энергетической эффективности, которые не могут быть проигнорированы практически ни в каком датацентре. Кратное уменьшение максимальной отдачи с ноды влечет за собой необходимость кратного увеличения числа нод, а значит многократного увеличения потребления электроэнергии.
В своей практике мы пришли к пониманию, что все ноды включенные в spine должны иметь линки 25G. Это оправданно и по экономике, и не создает накладных расходов по переключению портов 25G в режим 10G, что на коммутаторах Huawei и Juniper возможно только группами портов (обычно по 4 порта в группе).
Также, ощутимым преимуществом модели с учетом нагрузки от нод является то, что мы не оказываемся перед необходимостью ставить высокопроизводительные leaf‑коммутаторы с линейными портами на 25Gbit/s и магистральными портами на 100G. Вполне возможно обойтись и более старыми линейками с комбинацией линейных портов на 10Gbit/s и 40Gbit/s на магистральных портах. Также существуют переходные линейки со 100Gbit/s портами на магистральной части и 10Gbit/s на линейной.
Отдельно отметим, что схемы расширения портовой емкости за счет технологий mc‑lag, и уж тем более стекирования нами перестали рассматриваться в процессе эксплуатации из‑за необходимости соблюдения баланса трафика между всеми физическими шасси включенными в стек или объединенными через mc‑lag, что на практике означало бы наличие линка в каждое физическое шасси из каждого физического сервера. Учитывая практику установки по одному коммутатору в стойку, все возможные удобства от таких технологий нивелируются необходимостью межстоечных кроссировок.
В целом, такая модель распределения нагрузки по локации позволяет добиться оптимального использования портовой емкости и мощностей сетевого оборудования. Самый тяжелый трафик оказывается ближе к аплинкам, ноды обслуживающие его включатются в spine, а трафик легче приходит из leaf‑коммутаторов. Кроме того, она оказывается экономически эффективной, когда есть необходимость в активном наращивании емкости локации по раздаваемому трафику, но нет одномоментной возможности провести комплексную модернизацию сетевой инфраструктуры локации. В этом случае цикл ротации оборудования обеспечивает наибольший срок его эксплуатации.
4. Гибридизация архитектуры Spine&Leaf
Тем не менее, существуют ситуации, где и учет нагрузки от нод не может покрыть требования к оптимальному использованию портовой емкости и апликнов.
Представим себе такую ситуацию, что в датацентре А, где у нас уже стоит локация закончилось место, и какой‑то оператор предлагает разместиться у себя и предлагает также трафик по хорошей цене.
В этой ситуации возможно рассмотреть вариант с организацией отдельной локации в ДЦ этого оператора. Однако, в то же время не хочется и останавливать развитие существующей локации. В датацентре Б, который по сути является по сути датацентом оператора есть физическое размещение, но нет скорее всего того спектра коннективити(других операторов свзи), который представлен в датацентре А. Развитие отдельной локации в датацентре Б может существенно нарушить баланс раздачи в том смысле, что раздача контента из новой локации будет вестись только через одного оператора. И в случае проблем, особенно если оператор предлагает подключение как минимум 40Gbit/s, мы можем существенно потерять в емкости раздачи в регионе.
Если все же мы решаемся развить существующую локацию в датацентре А за счет размещения в датацентре Б и дополнительного включения там аплинка, мы сталкиваемся с нестандартной задачей с точки зрения архитектуры.
Сделать коммутатор установленный в датацентре Б просто leaf'ом того spin'а, который стоит в датацентре А видится самым простым решением. Но в таком случае мы не сможем полноценно использовать и новый аплинк и размещать в датацентре Б ноды для раздачи. В противном случае придется соединять датацентр А и Б весьма широким каналом. Но даже при наличии такого канала, при его падении мы получим не только отпадение одного аплинка на локации, но и недоступность тех серверов, которые находятся в датацентре Б.
Для того чтобы решить эту проблему возможно воспользоваться гибридизацией, где свитч в датацентре Б становится маршрутизатором. В него включается доступ в Интернет от оператора в датацентре Б, устанавливается BGP‑сессия с этим оператором, но кроме того, через канал между датацентрами устанавливается BGP‑сессия и со spine‑коммутатором в датацентре А. Подробно осветить выбор в этом сехме между IBGP и EBGP, к сожалению мы здесь не можем т. к. каждый раз это определяется местными условиями, предпочтениями, конфигурацией сети и возможностями сетевого оборудования. Но общий смысл сводится к тому, что в итоге обе стойки(в датацентрах А и Б) начинают пользоваться аплинками друг‑друга, они обмениваются не только внутренними маршрутами к L3-интерфейсам в серверные сегменты, но и маршрутами во вне. Такая схема, конечно, потребует наличие L3- интерфейса для терминации BGP‑сессии на коммутаторе в новой стойке в датацентре Б, но в данном случае, в виду поставленной задачи, это видится скорее нюансом, чем препятствием.
Как результат мы получим более хорошо резервированную схему, чем та, которую бы мы получили если бы сделали leaf в стойке датацентра Б, и включили ли бы в него аплинк от оператора связи. В нашей схеме отсутствие связанности по соединению между датацентрами не приведет к остановке сервиса ни в одной стоек в обоих датацентрах. Несомненно, возможно нужно будет поправить балансировку нагрузки, но это не будет полное отключение раздающих нод. Тем не менее, такое включение дает более гибкие возможности по расширению существующей инфраструктуры оператора CDN, за счет использования новых площадок географически разделенных с основным датацентром.
5. Заключение
В данной статье мы постарались изложить наш опыт и решенные проблемы реализации архитектуры Spine & Leaf на сетеовй подсистеме высоконагруженного CDN. Наш опыт является скорее рационализаторством, чем инновацией. Описанный опыт это попытка сократить издержки за счет продуманного подхода к проектированию, развитию и эксплуатации, при этом не потеряв в надежности сервиса.
В целом, из всего описанного следует вывод, что, несомненно, возможно несколько отходить от "чистой архитектуры" во имя результатов. Однако, это не должно понимать как полное непренебрежение принципами выбранной архитектурной модели и "изобретательство велосипеда". Наоборот - важен сбалансированный подход и долгосрочное планирование. В частности, это позволяет придти к более гибким решениям, которые будет возможно развивать без особых проблем. Основные проблемы на сетевой инфраструктуре узла CDN возникают с приходом реально большой нагрузки. В этой статье мы предложили читателю некоторые практические приемы, позволяющие лучше адаптировать сетевую инфраструктуру под всю гамму нагрузок в.т.ч. под ноды раздающие на скоростях более 50Gbit/s, в довольно узком коридоре технических требований, реальных условий и финансово-экономических показателей.
Мы постарались совместить и теорию и практику. Но основным вопросом все же остается метод решения этих задач в реальных условиях реального ДЦ. Сегодня именно операторы сетей доставки трафика сталкиваются с огромными объемами трафика, которые необходимо эффективно и оптимально распределить по порой скромным емкостям региональных операторов связи. Эта задача требует особого подхода, один из аспектов которого, мы попытались изложить в данной статье, совершенно не претендуя на исчерпание вопроса.
Арсений В. Великород (arseniivelikorod@gmail.com) — старший сетевой инженер CDN‑Video, Россия, Москва, 2024год
