
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М.А. БОНЧ-БРУЕВИЧА»
(СПбГУТ)
ФАКУЛЬТЕТ ИНФОКОММУНИКАЦИОННЫХ СЕТЕЙ И СИСТЕМ (ИКСС)
КАФЕДРА ПРОГРАММНОЙ ИНЖЕНЕРИИ И ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ (ПИ И ВТ)
АНАЛИТИЧЕСКИЙ ОБЗОР ПО ИССЛЕДОВАНИЯМ В ОБЛАСТИ
Протоколы маршрутизации в дата-центрах
Выполнил:
Студент 3 курса
Группы ИКПИ-92
Козлов Н.С.
Подпись____________
Принял:
Журавель Е.П.
Подпись____________
«_____»________ 2022
Оглавление
Введение 3
Маршрутизация в ЦОД 4
Трафик внутри ЦОД 17
Вывод 24
Литература 25
Введение
Мы живём во времена быстрейшего за всю историю человечества технологического прогресса, когда одна технология может тут же заменить другую. И далеко не последнюю роль в этом прогрессе играют сети связи. Причём не только с точки зрения непосредственно их развития, но и с точки зрения распространения, хранения и обработки любой информации о прогрессе в интернете – всемирной глобальной сети, представляющей из себя сложнейшею структуру, состоящую из различных протоколов передачи, адресации и маршрутизации данных. О последних упомянутых протоколах стоит рассказать отдельно, поскольку без них невозможно представить современный интернет. Применение этих протоколов позволяет избежать ручного ввода всех допустимых маршрутов, что, в свою очередь, снижает количество ошибок и обеспечивает согласованность действий всех маршрутизаторов в сети и облегчает труд сетевых администраторов. Протоколы маршрутизации применяются повсеместно, однако одной из наиболее важных областей применения остаются дата-центры, они же ЦОД.
В наше время дата-центры представляют из себя целые специализированные здания для размещения серверного и сетевого оборудования и подключения абонентов к каналам сети интернет. Дата-центр исполняет функции обработки, хранения и распространения информации, он ориентирован на решение бизнес-задач путём предоставления информационных услуг. Основным критерием оценки качества дата-центра является время доступности сервера. Помимо этого, в ряде стран имеются собственные стандарты на оборудование дата-центров позволяющие объективно оценить способность дата-центра обеспечить тот или иной уровень ЦОД. Например, в США принят американский (ANSI) стандарт TIA-942, несущий в себе рекомендации по созданию дата-центров и делящий дата-центры на типы по степени надёжности. Хотя в России пока нет такого стандарта, дата-центры оснащаются согласно требованиям для сооружений связи, а также ориентируются на требования TIA-942 и используют дополнительную документацию Uptime Institute и ГОСТы серии 34. Конечно, в условиях постоянно растущих требований, у дата-центров просто не могли не появиться собственные протоколы маршрутизации данных.
Маршрутизация в цод
В наше время ИТ сфера всё чаще сталкивается с нуждой использования различных облачных технологий, что не могло не привести к новым взглядам на разработку и внедрение различных приложений. Изменения не обошли стороной и сферу сетей связи, так же, как и приложения, они должны удовлетворять постоянно растущим требованиям современных ЦОД. Для обеспечения такой мобильности, сетям требуется новая модель, которая бы удовлетворяла следующим качествам [1]:
Гибкость.
Устойчивость.
Производительность.
Масштабируемость.
В следствии этих требований, современные сети ЦОД прошли путь от традиционных иерархических схем к более сложным архитектурам. Такие сети способны поддерживать все больший объём трафика в современных приложениях. Кроме того, остаются технологии кластеризации и методы виртуализации, для которых требуется близость ко второму уровню OSI.
В традиционной сети второго уровня OSI с множественными путями между коммутаторами мы обязаны использовать STP, MLAG или стекирование [2]. STP сокращает эффективную пропускную способность, просто отключая порты. К этой технологии также есть большие претензии с точки зрения времени сходимости.
С точки зрения рассмотрения перспектив развития к MLAG, в качестве ядра ЦОД, возникает много вопросов. Нужно четко понимать тот факт, что топология MLAG по определению не может содержать более двух коммутаторов агрегации, и, по-хорошему, требует наличия горизонтальной связи удвоенной емкости между ними. В связи с отсутствием возможности сегментирования и управления трафиком внутри и между шасси применение этой технологии в территориально распределенной среде может быть затруднительным. А определение ресурсов, необходимых для предотвращения события «Dual Master», с помощью предметного анализа сценариев отказа, может чрезвычайно перегрузить решение с точки зрения аппаратной составляющей. Несмотря на то, что коммутаторы агрегации MLAG продолжают функционировать раздельно, они чрезвычайно тесно связаны с точки зрения физической топологии.
Эксплуатация стека в качестве ядра ЦОД сопряжено большими рисками, так как, несмотря на привлекательность и кажущуюся простоту общего Control Plane per Stack, ошибки в программном обеспечении имеют место быть, и никто не застрахованы от их появления. Хуже то, что ошибка обычно не может быть локализована в Fault Domain приемлемого размера, стек это не только один большой коммутатор, но и один большой Fault Domain. Тот факт, что возможности стека зачастую ограничены самым слабым компонентом, так как по определению многие таблицы коммутационных чипов должны быть идентичными на всех устройствах, тоже не стоит упускать из вида. К стеку, функционирующему, в распределенной среде возникают тот же набор вопросов отказоустойчивости, которые кратко описаны выше для случая применения MLAG. Кольцевая топология, которой ограничиваются некоторые производители стекируемых коммутаторов, характеризуется потенциально более перегруженными стек портами ближе к границе. В зависимости от профиля трафика это может оказаться проблемой, на которую так же нужно обратить внимание.
Рис.
1. Строение кадра
Рис.
2. Схема сети VXLAN
Когда трафик от хоста А к хосту B попадает на пограничный коммутатор в виде кадра второго уровня (Рис. 2), этот кадр упаковывается внутрь IP пакета (Рис. 1) и отправляется по IP сети к пограничному коммутатору другой стороны чтобы там произошла процедура распаковки. Началом эпохи разделение компонентов сети на транспортную и сервисную составляющие принято считать внедрение BGP Free Core на базе технологий MPLS в сетях операторов связи. Применительно к ЦОД эта тенденция появилась относительно недавно в качестве метода решения задач масштабируемости и упрощения эксплуатации, компоненты такой архитектуры обычно называют Underlay — транспортная сеть, и Overlay – сервисная или виртуальная.
Разделение функций сетевой подсистемы ЦОД, позволяет конфигурировать сервис отдельно от конфигурации транспортной составляющей. Больше не требуется определять Vlan на каждом транзитном коммутаторе в цепочке, вместо этого описывается Overlay сети путем настройки только там, где он фактически предоставляется, при этом обмен трафиком Overlay сетей осуществляется через туннели на базе Underlay сети. С другой стороны, вполне ожидаемым является тот факт, что проведение таких активностей на Underlay сети как изменение физической топологии, добавление/удаление коммутаторов или каналов связи, будет иметь нулевое влияние на конфигурацию сервисной составляющей. Ядро или транспортная составляющая сети ЦОД при этом свободны от обработки и хранения состояний, табличное пространство коммутационных чипов коммутаторов ядра используется исключительно в рамках задачи построения связности, передачи трафика и обеспечения быстрой сходимости, а информация о состояниях сервисной составляющей присутствует только на границе сети ЦОД.
Подводя итоги: Если говорить просто — VXLAN это инкапсуляция над data-plane, EVPN — это набор правил, руководствуясь которыми коммутаторы передают трафик второго уровня поверх IP сети, т. е. control-plane. Имея в своем распоряжении только VLAN теги, можно оперировать количеством сегментов, ограниченным сверху 12-ти битным числом, т. е. 4096. В VXLAN для идентификации сегментов отводится уже 24 бита, т. е. предельное количество экземпляров VNI (это аналог VLAN тега) равно 16-ти миллионам. В сети ЦОД оценка величины требуемых сегментов вполне может приблизиться к верхнему пределу количества VLAN.
EVPN/VXLAN поддерживает передачу трафика второго уровня по множественным путям (ECMP передача). Если вспомнить что VXLAN - туннель, станет понятно, что это свойство наследуется совершенно естественным образом. Достаточно указать точку назначения туннеля в IP заголовке внешнего пакета, и у транзитных коммутаторов появляется возможность утилизировать потоками трафика все возможные пути. Инкапсуляция VXLAN специально разработана таким образом, чтобы передача потока с соблюдением последовательности пакетов не требовала серьезной инспекция транзитного пакета. Для этой цели используется заголовок транспортного уровня, полем повышения энтропии трафика и идентификатором потока служит номер UDP порта. Заполнение этого поля выполняется на пограничных коммутаторах, так чтобы транзитным коммутаторам не приходилось глубоко заглядывать в содержимое пакета, что снижает требования к их коммутационным чипам. Это означает что высокопроизводительные IP фабрики можно строить, используя коммутаторы общего назначения.
Вместе с тем, ссылаясь на статью [3], ожидается, что с распространением услуг мобильной связи 5G и IoT возникнут новы требования клиентов, связанные с сервисной вариативностью. Для удовлетворения таких требований необходимы системы оптического доступа, гибко и оперативно предоставляющие различные услуги. Одним из решений является применение технологий виртуализации сети к системам оптического доступа. Спецификации и реализации виртуализации сети доступа технологии активно обсуждались и часто предлагались многими телекоммуникационными операторами и поставщиками в организациях по стандартизации, таких как Open Networking Foundation (ONF) и Broadband Forum.
Рис.
3. Применение виртуализации сети доступа
к системе PON.
включает
коммерчески доступные серверы и
коммутаторы.
Рис.
4. Автоматическая процедура открытия
линии.
На (Рис. 4) показаны предлагаемые процедуры автоматического открытия линии, обеспечивающие ZTP в системах PON. Обычно ONU на территории клиента аутентифицируются посредством вмешательства оператора, при котором операторы записывают идентификаторы ONU во время доставки или напрямую подтверждают идентификаторы на территории клиента. Предлагаемые процедуры заменяют эти операторские задачи. Как показано на рис. 4, (1) клиент считывает ONU-ID с помощью смартфона, например, как встроенный в код быстрого ответа (QR), прикрепленный к ONU. (2) Затем идентификатор передается по беспроводной линии, ранее связанной с клиентом, и (3) функция открытия линии открывает линию ONU с идентификатором, полученным по связанной линии.
Рис.
5. Совместная тестовая среда.
Рис.
6. Последовательность операций службы
IPv6.
Рис.
7. Зависимость времени открытия линии
от количества ONU.
Таким образом: Авторы оригинальной статьи проверили выполнимость процедур автоматического открытия линии и мультисервисной активации на основе ZTP для технологий виртуализации сети доступа с использованием сменного OLT модульного типа. Для трех операторов связи Азиатско-Тихоокеанского региона (TELKOM, VNPT и NTT) была создана общая тестовая среда для технологий виртуализации сетей доступа. Используя испытательный стенд, авторы провели оценку производительности для двух вариантов использования: функция DHCPv6 для службы IPv6 и автоматическая инициализация нескольких служб на CiaB, а время активации услуги составляет несколько десятков секунд. Исходя из этого, можно прийти к выводу, что предлагаемые процедуры технически осуществимы, и их достоверность доказана экспериментально в реальной среде Интернета.
В это же время, исследователи в статье [4] пришли к тому, что в настоящее время крупные центры обработки данных строятся как базовая инфраструктура для предоставления облачных сервисов, таких как веб-поиск, социальные сети и рекомендательные системы. В этих центрах обработки данных десятки тысяч серверов соединены сетями обработки данных (DCN). В отличие от Интернета, DCN имеют более короткий RTT (около 100 мкс) и более высокую пропускную способность (не менее 1 Гбит/с). Кроме того, облачные сервисы, такие как MapReduce и Spark, обычно имеют специальный шаблон связи, такой как «многие к одному», а в DCN предпочтительнее использовать товарный коммутатор с неглубоким буфером. Эти отличительные характеристики DCN приводят к тому, что используемый по умолчанию транспортный протокол TCP страдает от таких проблем, как TCP Incast, TCP Outcast и длительное время выполнения запроса, что может значительно снизить производительность TCP при передаче данных. По сути, причиной проблем TCP является тайм-аут. Поскольку минимальное время ожидания повторной передачи (RTOmin) по умолчанию для TCP составляет около 200 мс, что на несколько порядков больше, чем RTT в DCN, возникновение тайм-аута приведет к проблемам TCP. В частности, проблема TCP Incast возникает, когда несколько потоков TCP одновременно передают данные в один пункт назначения. Например, около 80 параллельных потоков сосуществуют в узле, расположенном в кластере с 1500 серверами. Следовательно, если какой-либо поток испытывает тайм-ауты, узкое место может быть значительно недоиспользовано, что приводит к резкому снижению полезной производительности. Проблема TCP Outcast возникает, когда два набора потоков, поступающих на два разных входных порта, перенаправляются на один и тот же выходной порт коммутатора. Пакеты в наборе потоков с меньшим RTT могут страдать от отключения портов и последовательно отбрасываться. Если потери пакетов значительны, происходит тайм-аут, в результате чего набор потоков с меньшим RTT имеет меньшую пропускную способность. Проблема длительного времени выполнения запроса также связана с тайм-аутом. Поток запросов обычно имеет небольшой размер и может выполняться за десятки микросекунд. Как только происходит тайм-аут, время выполнения потока запросов становится намного больше, чем теоретическое время. Чтобы смягчить тайм-ауты, транспортный протокол должен поддерживать небольшую очередь коммутатора, чтобы избежать потери пакетов и быстро восстанавливать потерянные пакеты, когда происходит потеря пакета.
Для таких целей и был придуман PTCP. PTCP направлен на уменьшение времени ожидания с помощью пакетов с высоким приоритетом на стандартном коммутаторе. В частности, PTCP пытается обнаружить перегрузку и контролировать длину очереди на коммутаторе с узким местом, вставляя дополнительные пакеты с высоким приоритетом, и повторно передает потерянные пакеты как можно скорее с помощью дополнительного механизма быстрого восстановления.
Рис.
8. Отправляемые и принимаемые
последовательности пакетов по схеме
связи «один к одному» и «два к одному».
Подобно TCP, PTCP содержит стадию медленного запуска, стадию предотвращения перегрузки и стадию быстрой повторной передачи. Однако на этих этапах PTCP будет вставлять дополнительный высокоприоритетный пакет размером с заголовок пакета после пакетов данных. Подробности следующие. На этапе медленного старта окно перегрузки мультипликативно увеличивается в каждом RTT. На этапе предотвращения перегрузки окно перегрузки изменяется в аддитивном порядке. На любом этапе вставленный пакет с высоким приоритетом отправляется после окна пакетов данных. Когда PTCP входит в стадию быстрой повторной передачи так же, как и TCP, пакет с высоким приоритетом отправляется после каждого повторно переданного пакета данных, если получено подтверждение предыдущего пакета с высоким приоритетом. Наконец, чтобы предотвратить тайм-аут, вызванный потерей хвоста, если данных недостаточно для заполнения окна перегрузки, также отправляется пакет с высоким приоритетом.
Рис.
9. Отправка и получение последовательности
пакетов при перегрузке.
Если ACK пакета с высоким приоритетом получен до ACK пакетов данных в соответствующем окне, окно уменьшается в соответствии с предполагаемой степенью перегрузки. Здесь предполагается, что размер окна перегрузки составляет Ns в пакетах. После отправки Ns пакетов данных вставляется пакет с высоким приоритетом. Источник вычисляет степень перегрузки при получении ACK пакета с высоким приоритетом. Предполагая, что количество подтвержденных пакетов данных на данный момент равно Nr, как показано на рис. 9.
Таким образом: TCP страдает от нескольких проблем с производительностью из-за тайм-аута, который легко срабатывает в DCN. Чтобы решить проблемы, авторы статьи разрабатываем PTCP с использованием дополнительного пакета с высоким приоритетом, который отличается от современных протоколов. Протокол авторов статьи доставляет пакеты с высоким приоритетом при отправке пакетов данных. Схема основана на выводе о том, перегружена ли сеть, исходя из чего можно сделать вывод, сравнивая последовательности полученных ACK двух типов пакетов с последовательностями их отправки. Следовательно, с пакетом с высоким приоритетом PTCP может хорошо контролировать длину очереди для снижения вероятности тайм-аута. Более того, PTCP удерживает пакет с высоким приоритетом в пути, чтобы можно было быстро восстановить возможные потерянные пакеты. В результате тайм-аут еще больше сокращается. Поскольку протокол PTCP совместим с серийным коммутатором, его легко развернуть в DCN. Обширные эксперименты по моделированию показывают, что PTCP имеет нулевое время ожидания и лучшую производительность с точки зрения решения проблем TCP по сравнению с несколькими современными протоколами.