Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Протоколы маршрутизации в дата-центрах.docx
Скачиваний:
4
Добавлен:
21.07.2024
Размер:
892.9 Кб
Скачать

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ

УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М.А. БОНЧ-БРУЕВИЧА»

(СПбГУТ)

ФАКУЛЬТЕТ ИНФОКОММУНИКАЦИОННЫХ СЕТЕЙ И СИСТЕМ (ИКСС)

КАФЕДРА ПРОГРАММНОЙ ИНЖЕНЕРИИ И ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ (ПИ И ВТ)

АНАЛИТИЧЕСКИЙ ОБЗОР ПО ИССЛЕДОВАНИЯМ В ОБЛАСТИ

Протоколы маршрутизации в дата-центрах

Выполнил:

Студент 3 курса

Группы ИКПИ-92

Козлов Н.С.

Подпись____________

Принял:

Журавель Е.П.

Подпись____________

«_____»________ 2022

Оглавление

Введение 3

Маршрутизация в ЦОД 4

Трафик внутри ЦОД 17

Вывод 24

Литература 25

Введение

Мы живём во времена быстрейшего за всю историю человечества технологического прогресса, когда одна технология может тут же заменить другую. И далеко не последнюю роль в этом прогрессе играют сети связи. Причём не только с точки зрения непосредственно их развития, но и с точки зрения распространения, хранения и обработки любой информации о прогрессе в интернете – всемирной глобальной сети, представляющей из себя сложнейшею структуру, состоящую из различных протоколов передачи, адресации и маршрутизации данных. О последних упомянутых протоколах стоит рассказать отдельно, поскольку без них невозможно представить современный интернет. Применение этих протоколов позволяет избежать ручного ввода всех допустимых маршрутов, что, в свою очередь, снижает количество ошибок и обеспечивает согласованность действий всех маршрутизаторов в сети и облегчает труд сетевых администраторов. Протоколы маршрутизации применяются повсеместно, однако одной из наиболее важных областей применения остаются дата-центры, они же ЦОД.

В наше время дата-центры представляют из себя целые специализированные здания для размещения серверного и сетевого оборудования и подключения абонентов к каналам сети интернет. Дата-центр исполняет функции обработки, хранения и распространения информации, он ориентирован на решение бизнес-задач путём предоставления информационных услуг. Основным критерием оценки качества дата-центра является время доступности сервера. Помимо этого, в ряде стран имеются собственные стандарты на оборудование дата-центров позволяющие объективно оценить способность дата-центра обеспечить тот или иной уровень ЦОД. Например, в США принят американский (ANSI) стандарт TIA-942, несущий в себе рекомендации по созданию дата-центров и делящий дата-центры на типы по степени надёжности. Хотя в России пока нет такого стандарта, дата-центры оснащаются согласно требованиям для сооружений связи, а также ориентируются на требования TIA-942 и используют дополнительную документацию Uptime Institute и ГОСТы серии 34. Конечно, в условиях постоянно растущих требований, у дата-центров просто не могли не появиться собственные протоколы маршрутизации данных.

Маршрутизация в цод

В наше время ИТ сфера всё чаще сталкивается с нуждой использования различных облачных технологий, что не могло не привести к новым взглядам на разработку и внедрение различных приложений. Изменения не обошли стороной и сферу сетей связи, так же, как и приложения, они должны удовлетворять постоянно растущим требованиям современных ЦОД. Для обеспечения такой мобильности, сетям требуется новая модель, которая бы удовлетворяла следующим качествам [1]:

  1. Гибкость.

  2. Устойчивость.

  3. Производительность.

  4. Масштабируемость.

В следствии этих требований, современные сети ЦОД прошли путь от традиционных иерархических схем к более сложным архитектурам. Такие сети способны поддерживать все больший объём трафика в современных приложениях. Кроме того, остаются технологии кластеризации и методы виртуализации, для которых требуется близость ко второму уровню OSI.

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

С точки зрения рассмотрения перспектив развития к MLAG, в качестве ядра ЦОД, возникает много вопросов. Нужно четко понимать тот факт, что топология MLAG по определению не может содержать более двух коммутаторов агрегации, и, по-хорошему, требует наличия горизонтальной связи удвоенной емкости между ними. В связи с отсутствием возможности сегментирования и управления трафиком внутри и между шасси применение этой технологии в территориально распределенной среде может быть затруднительным. А определение ресурсов, необходимых для предотвращения события «Dual Master», с помощью предметного анализа сценариев отказа, может чрезвычайно перегрузить решение с точки зрения аппаратной составляющей. Несмотря на то, что коммутаторы агрегации MLAG продолжают функционировать раздельно, они чрезвычайно тесно связаны с точки зрения физической топологии.

Эксплуатация стека в качестве ядра ЦОД сопряжено большими рисками, так как, несмотря на привлекательность и кажущуюся простоту общего Control Plane per Stack, ошибки в программном обеспечении имеют место быть, и никто не застрахованы от их появления. Хуже то, что ошибка обычно не может быть локализована в Fault Domain приемлемого размера, стек это не только один большой коммутатор, но и один большой Fault Domain. Тот факт, что возможности стека зачастую ограничены самым слабым компонентом, так как по определению многие таблицы коммутационных чипов должны быть идентичными на всех устройствах, тоже не стоит упускать из вида. К стеку, функционирующему, в распределенной среде возникают тот же набор вопросов отказоустойчивости, которые кратко описаны выше для случая применения MLAG. Кольцевая топология, которой ограничиваются некоторые производители стекируемых коммутаторов, характеризуется потенциально более перегруженными стек портами ближе к границе. В зависимости от профиля трафика это может оказаться проблемой, на которую так же нужно обратить внимание.

Рис. 1. Строение кадра

Термин VXLAN обозначает виртуальную расширяемую локальную сеть, можно найти много сходств с VLAN, однако, различие в том, что VXLAN это туннель (одностороннее виртуальное соединение между двумя коммутаторами), если говорить более точно это инкапсуляция Ethernet над UDP.

Рис. 2. Схема сети VXLAN

Привычная передача трафика второго уровня между хостами происходит на основе информации о расположении MAC адресов, таблицу которых хранят промежуточные коммутаторы. В процессе прохождения трафика, коммутаторы обновляют свои знания о сети с помощью механизма обучения. В мире VXLAN, многое меняется, так, например, для передачи трафика второго уровня промежуточные коммутаторы вовсе не обязаны работать на втором уровне в рамках одного широковещательного домена. Туннелирование Ethernet трафика позволяет транзитным коммутаторам абстрагироваться от понятия MAC адресов, и выполнять свои функции в рамках IP фабрики свободной топологии по правилам маршрутизации. Каждый коммутатор в ЦОД работает абсолютно независимо от своих соседей, это напоминает распределенную работу сети Интернет, так как регламентные работы на каждом устройстве имеют строго локальный характер. Гибкая физическая топология позволяет четко подстраиваться под профиль трафика в конкретно взятом ЦОД, а свободный выбор типов и количества соединительных портов позволяет строить сети с заданным уровнем переподписки, вплоть до полностью неблокируемых.

Когда трафик от хоста А к хосту 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. Автоматическая процедура открытия линии.

На (Рис. 3) показано применение технологий виртуализации сети доступа к системе пассивной оптической сети (PON). Согласно (Рис. 3) упрощенные функции OLT для PON обеспечиваются внешним модулем. Кроме того, к стандартному оборудованию добавляются другие необходимые сетевые функции в виде программных приложений. Эта архитектура позволяет экономично и гибко создавать соответствующие системы оптического доступа в ответ на разнообразные требования клиентов.

На (Рис. 4) показаны предлагаемые процедуры автоматического открытия линии, обеспечивающие ZTP в системах PON. Обычно ONU на территории клиента аутентифицируются посредством вмешательства оператора, при котором операторы записывают идентификаторы ONU во время доставки или напрямую подтверждают идентификаторы на территории клиента. Предлагаемые процедуры заменяют эти операторские задачи. Как показано на рис. 4, (1) клиент считывает ONU-ID с помощью смартфона, например, как встроенный в код быстрого ответа (QR), прикрепленный к ONU. (2) Затем идентификатор передается по беспроводной линии, ранее связанной с клиентом, и (3) функция открытия линии открывает линию ONU с идентификатором, полученным по связанной линии.

Рис. 5. Совместная тестовая среда.

Для оценивания был создан общий испытательный стенд для технологий виртуализации сети с использованием VPN-соединений между тремя точками. Конфигурация показана на (Рис. 5). Как показано на рисунке, система PON, состоящая из нескольких ONU и OLT, была построена в NetroSphere PIT. OLT — это коммерчески доступный Ethernet-коммутатор, оснащенный сменным OLT модульного типа. Это одно из ключевых устройств платформы виртуализации сети доступа, основанной на концепции SEBA. В этом эксперименте функция открытия линии, описанная выше, находилась в PIT NetroSphere. Другие дополнительные сетевые функции для услуг и персональных компьютеров (ПК) в качестве абонентского оборудования (CPE) были расположены на площадках TELKOM и VNPT. В этой тестовой конфигурации каждый ONU и CPE были индивидуально подключены через Интернет с помощью отдельного VPN-подключения.

Рис. 6. Последовательность операций службы IPv6.

Во-первых, чтобы подтвердить работоспособность самой системы с предлагаемой функцией открытия линии, предполагая одновременную работу до 32 ONU, мы измерили зависимость времени открытия от количества ONU. Здесь время измеряется для последовательностей (2)–(4) на (Рис. 6).

Рис. 7. Зависимость времени открытия линии от количества ONU.

Время увеличивается по мере увеличения количества ONU. Результаты измерений представлены на (Рис. 7). Как показано на рисунке, время, необходимое для открытия линий всех 32 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. Отправляемые и принимаемые последовательности пакетов по схеме связи «один к одному» и «два к одному».

Когда PTCP использует приоритетную очередь, следующие проблемы имеют решающее значение для отправителя PTCP. Как вставить пакет с высоким приоритетом? Как настроить окно перегрузки при получении ACK высокоприоритетного пакета? Когда происходит повторная передача возможного потерянного пакета? Что касается PTCP-коммутатора, он должен поддерживать приоритетную очередь и включать планирование Strict Priority (SP), которые доступны для стандартного коммутатора. Для приемника PTCP он обрабатывает пакет данных так же, как TCP. При получении пакета с высоким приоритетом он генерирует соответствующий ACK с высоким приоритетом и устанавливает порядковый номер ACK таким же, как номер последнего полученного пакета данных (Рис. 8).

Подобно TCP, PTCP содержит стадию медленного запуска, стадию предотвращения перегрузки и стадию быстрой повторной передачи. Однако на этих этапах PTCP будет вставлять дополнительный высокоприоритетный пакет размером с заголовок пакета после пакетов данных. Подробности следующие. На этапе медленного старта окно перегрузки мультипликативно увеличивается в каждом RTT. На этапе предотвращения перегрузки окно перегрузки изменяется в аддитивном порядке. На любом этапе вставленный пакет с высоким приоритетом отправляется после окна пакетов данных. Когда PTCP входит в стадию быстрой повторной передачи так же, как и TCP, пакет с высоким приоритетом отправляется после каждого повторно переданного пакета данных, если получено подтверждение предыдущего пакета с высоким приоритетом. Наконец, чтобы предотвратить тайм-аут, вызванный потерей хвоста, если данных недостаточно для заполнения окна перегрузки, также отправляется пакет с высоким приоритетом.

Рис. 9. Отправка и получение последовательности пакетов при перегрузке.

Обычно мы используем только один пакет с высоким приоритетом в каждом раунде PTCP. Причина в том, что пакет с высоким приоритетом потребляет дополнительную пропускную способность, поэтому использование двух или более высокоприоритетных пакетов вместе с окном пакетов данных увеличивает нагрузку на полосу пропускания. Использование более высокоприоритетных пакетов в каждом раунде вводит для них более сложные механизмы контроля. Например, для каждого пакета с высоким приоритетом мы должны учитывать полученные последовательности каждого пакета с высоким приоритетом и соответствующие ему пакеты данных, чтобы сделать вывод о перегрузке (Рис. 9). Хотя использование двух или более пакетов с высоким приоритетом может быть более точным для анализа последовательностей пакетов данных, поступающих к получателю.

Если ACK пакета с высоким приоритетом получен до ACK пакетов данных в соответствующем окне, окно уменьшается в соответствии с предполагаемой степенью перегрузки. Здесь предполагается, что размер окна перегрузки составляет Ns в пакетах. После отправки Ns пакетов данных вставляется пакет с высоким приоритетом. Источник вычисляет степень перегрузки при получении ACK пакета с высоким приоритетом. Предполагая, что количество подтвержденных пакетов данных на данный момент равно Nr, как показано на рис. 9.

Таким образом: TCP страдает от нескольких проблем с производительностью из-за тайм-аута, который легко срабатывает в DCN. Чтобы решить проблемы, авторы статьи разрабатываем PTCP с использованием дополнительного пакета с высоким приоритетом, который отличается от современных протоколов. Протокол авторов статьи доставляет пакеты с высоким приоритетом при отправке пакетов данных. Схема основана на выводе о том, перегружена ли сеть, исходя из чего можно сделать вывод, сравнивая последовательности полученных ACK двух типов пакетов с последовательностями их отправки. Следовательно, с пакетом с высоким приоритетом PTCP может хорошо контролировать длину очереди для снижения вероятности тайм-аута. Более того, PTCP удерживает пакет с высоким приоритетом в пути, чтобы можно было быстро восстановить возможные потерянные пакеты. В результате тайм-аут еще больше сокращается. Поскольку протокол PTCP совместим с серийным коммутатором, его легко развернуть в DCN. Обширные эксперименты по моделированию показывают, что PTCP имеет нулевое время ожидания и лучшую производительность с точки зрения решения проблем TCP по сравнению с несколькими современными протоколами.