Tor коммутатор что это

Top-of-rack и end-of-row коммутаторы

Когда говорят и в отношении коммутаторов, речь идет о двух видах коммутационной инфраструктуры.

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

Итак, — это модель коммутации, когда в каждой стойке стоит коммутатор, который обрабатывает трафик с серверов в этой стойке, и соединен с коммутатором ядра или с агрегирующим слоем (в зависимости от количества уровней). Хотя и устоялось название — не утверждается, что именно в верхней части стойки должен физически располагаться коммутатор. Говорят, что изначально это было так, потому что админы предпочитали сначала воткнуть все кабели в коммутатор, чтобы потом больше к нему не прикасаться. И тогда, если коммутатор вверху, кабели удобно свешиваются вниз и облегчают подключение.

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

У есть и недостатки, которые станут заметными, когда количество стоек в вашей компании будет серьезно расти. Если предположить, что у вас скажем 20 стоек, в каждой из которых стоит по 2 коммутатора, то это 40 коммутаторов, а с точки зрения обслуживания — это уже не просто. Это 40 копий софта для коммутатора для обновления, 40 конфигурационных файлов, которые надо создать и надежно архивировать, иными словами — 40 мест, где « может пойти не так».

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

Модель коммутации предполагает расположение коммутатора, условно, «в конце ряда стоек» и обслуживание им трафика с со всех серверов из нескольких стоек, расположенных в ряд. Опять же физически это не значит, что коммутатор должен быть именно в последней стойке. Такое расположение было принято для дублирующих коммутаторов, которые изначально действительно располагали в разных концах ряда стоек, чтобы например внезапная проблема типа протекшей крыши в одном месте, не вырубила из работы целый ряд стоек.

В такой схеме серверы в стойке обычно соединяются относительно короткими кабелями с коммутационной панелью в стойке, от которой идет плотный пучок кабелей, как правило через верх, над серверными стойками, к коммутатору.

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

В предыдущем примере, если мы условно возьмем по 10 стоек в ряд, то для 20 стоек понадобится всего 4 коммутатора, в отличие от 40 коммутаторов в случае с конфигурацией. То есть с точки зрения поддержки — это в 10 раз меньше потенциальных забот. Это, пожалуй, главное достоинство такой схемы.

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

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

Источник

Высокоплотный коммутатор ToR для конвергентных сетей

Коммутатор XS3900-48F от компании ZyXEL позволяет подключить до 48 серверов и систем хранения в стойке по каналам 10 Gigabit Ethernet к общей сети ЦОД.

Коммутатор XS3900-48F от компании ZyXEL позволяет подключить до 48 серверов и систем хранения в стойке по каналам 10 Gigabit Ethernet к общей сети ЦОД.

Такой привлекательный сегмент, как коммутатор 10 Gigabit Eternet, — едва ли не единственный, растущий в условиях стагнирующего рынка, — не может позволить себе игнорировать ни один из сетевых вендоров. Тайваньская компания ZyXEL представила на российском рынке свой коммутатор 10GbE для ЦОД наряду с целой линейкой коммутаторов GbE с магистральными интерфейсами 10GbE.

Сейчас, несмотря на кризис, достаточно благоприятный момент, чтобы попытаться закрепиться в этой нише — в связи с разворотом российской политики и экономики в сторону Азии, когда негласно — а иногда гласно — предпочтение отдается ИТ-продукции азиатских вендоров.

Для ZyXEL, несмотря на более чем десятилетний опыт выпуска коммутаторов Ethernet, решения для ЦОД — достаточно новое направление. Специально для этого сегмента компания предлагает весьма мощное и производительное устройство — коммутатор XS3900-48F с 48 портами, слотами SFP+ для портов 1 или 10 Гбит/с и четырьмя магистральными интерфейсами QSFP+ для 40 Гбит/с.

Неблокирующая коммутирующая архитектура XS3900-48F позволяет обеспечить производительность 1,28 Тбит/с, а скорость продвижения пакетов составляет 952,4 млн пакетов в секунду. В результате на каждом порту достигается ультранизкая задержка при передаче пакетов (конкретные значения производителем не приводятся). Для достижения высокого уровня отказо устойчивости в конструкции коммутатора предусмотрено два блока питания и два блока вентиляторов, каждый из которых можно менять в горячем режиме.

Основные характеристики

Главной же особенностью коммутатора, которая в первую очередь подчеркивается производителем, является поддержка протоколов Data Center Bridging (DCB) — в частности, именно с DCB после первых вступительных слов начинается описание коммутатора в руководстве пользователя. Что же дает поддержка стандартов DCB? Если говорить кратко, она позволяет адаптировать сеть Ethernet для передачи трафика сетей хранения Fibre Channel поверх Ethernet. В результате по одному соединению Ethernet можно передавать как трафик LAN, так и трафик SAN, а также IPC (трафик межпроцессного взаимодействия).

В XS3900-48F реализованы следующие протоколы спецификации DCB: 802.1Qbb Priority-based Flow Control (PFC); 802.1Qaz Enhanced Transmission Selection (ETS); 802.1Qaz DCB Capability Exchange Protocol (DCBX). Посредством протокола DCBX коммутатор может обнаруживать другие сетевые устройства с поддержкой DCB и взаимодействовать с ними. PFC и ETS используются для контроля, приостановки и планирования различных потоков трафика во избежание заторов трафика, для предотвращения потерь пакетов и для предоставления приложениям гарантированной пропускной способности. Реализация протоколов DCB в точности соответствует стандартам.

XS3900-48F предназначен для установки внутри стойки с активным оборудованием — так называемая конфигурация Top of Rack (ToR). При такой конфигурации сокращается длина кабелей, необходимых для подключения серверов и другого активного оборудования к коммутатору. Однако при небольшом числе устройств в стойке многие порты могут остаться незадействованными, что является общим недостатком данного подхода (ToR). Чтобы улучшить соотношение задействованных и неиспользуемых портов, ZyXEL намерена в следующем году выпустить устройства с меньшей плотностью портов.

Управление коммутатором может осуществляться через Web-интерфейс и с помощью командной строки. Для конфигурации коммутатора и повседневной работы ZyXEL рекомендует использовать Web-интерфейс. Однако командную строку все же придется осваивать, особенно если планируется использовать DCB — пока конфигурирование этих протоколов через Web-интерфейс невозможно (но, ZyXEL планирует его реализовать). Впрочем, для тех, кто знаком с оборудованием Cisco, освоение командной строки не должно составить проблем, так как его синтаксис следует принятому Cisco.

За рубежом данный коммутатор доступен уже больше года, так что на российский рынок предлагается уже прошедший обкатку продукт. На XS3900-48F предоставляется трехлетняя гарантия (плюс дополнительный год при регистрации на сайте). Рекомендованная цена на российском сайте ZyXEL не указана: в Европе цены на XS3900-48F начинаются от 10 тыс. евро, в России розничные цены — от 800 тыс. рублей. В первую очередь, ZyXEL надеется на внимание к этому предложению со стороны со своих традиционных клиентов — операторов и провайдеров, у которых есть собственные ЦОД.

Дмитрий Ганьжа — главный редактор «Журнала сетевых рещений/LAN».

Поделитесь материалом с коллегами и друзьями

Источник

ЦОД: выбираем Ethernet-коммутаторы

Представление о том, каким сетевым оборудованием должен быть оснащен ЦОД, зависит от многих факторов: начиная с того, в какой отрасли и на каком уровне он решает задачи, и заканчивая тем, какие приложения в нем запущены. Что готов предложить рынок? «ИКС» спросил об этом поставщиков оборудования и системных интеграторов.

Поскольку для высокопроизводительной коммутации серверов и систем хранения сегодня используется большой спектр технологий и устройств (коммутаторы Ethernet, Fibre Channel, Infiniband, Myrinet и др.), мы решили сначала ограничиться рассмотрением узкого круга задач – организации коммуникации на уровне доступа сети ЦОДа с использованием технологии Ethernet, но при этом были вынуждены подняться несколько выше, рассмотрев архитектуру сети ЦОДа в целом.

Надо отметить, что присутствие в обзоре производителей, известных своими продуктами для рынков небольших локальных и операторских сетей доступа, может вызвать вопросы. Но в связи с тем, что классификация того или иного оборудования как предназначенного специально для ЦОДа и является предметом обсуждения данной статьи, мы считаем, что, ознакомившись с ней, читатель сам сможет сделать вывод, какая модель Ethernet-коммутатора годится для его конкретного проекта ЦОДа, а какая нет.

Сеть ЦОДа: классическая архитектура и ее воплощения

Коммуникационная среда ЦОДа в силу повышенных требований к ее надежности и безопасности часто создается как отдельная сеть. Исторически масштабирование Ethernet-сетей производилось благодаря многоуровневой иерархической структуре. В классической современной архитектуре корпоративной ЛВС выделяют три уровня: доступа, агрегирования и ядра сети. Аналогичным образом строится и сеть ЦОДа (см., например, рисунок), т.е. в общем случае в ней также можно выделить уровень доступа (access tier, или у некоторых производителей – edge tier), просто в качестве терминальных узлов здесь выступают не настольные ПК или иные абонентские устройства, а серверы. В такой сети своя специфика имеется и у уровня агрегирования (иногда еще называемого distribution), и у уровня ядра. Скажем, на уровне агрегирования часто помимо средств безопасности и мониторинга располагаются еще и средства балансировки нагрузки.

Некоторые из опрошенных нами поставщиков считают, что для сети ЦОДа трехуровневая архитектура слишком сложна и избыточна. Это объяснимо, поскольку в России, которая находится на начальном этапе «цодостроительства», под ЦОДом часто подразумевают серверную комнату с парой стоек оборудования, и в таком случае действительно можно обойтись если не единственным модульным коммутатором, то уж точно сетью с двухуровневой архитектурой.

Другое дело, когда заходит речь о сетевых решениях, обеспечивающих работу сотен стоек с тысячами серверов: там дополнительный уровень, распределяющий серверный трафик и поддерживающий сетевые сервисы, просто необходим.

От ядра – к серверам

Уровень ядра сети ЦОДа обеспечивает коммутацию трафика от уровня агрегирования и связь ЦОДа с остальной корпоративной сетью. С организационной точки зрения именно за уровнем ядра сети ЦОДа в крупных организациях заканчивается зона ответственности структурного подразделения эксплуатации ЦОДа. Уровень агрегирования, комплектуемый обычно коммутаторами с большим числом портов 10 Gigabit Ethernet (10GE), в крупных сетях служит демпфером между ядром и уровнем доступа; коммутаторы в нем, как правило, устанавливаются парами, так, что коммутаторы уровня доступа подключаются сразу к двум коммутаторам уровня агрегирования.

Как уже отмечалось, в сети ЦОДа в качестве терминальных узлов уровня доступа выступают серверы. Современные серверы имеют как минимум два интерфейса Gigabit Ethernet. Кроме того, они могут оснащаться портами для связи с системой хранения данных (а часто еще и дополнительными интерфейсами для обеспечения доступа к системе резервного копирования) и портом управления по дополнительному каналу (out-of-band). Такое количество интерфейсов существенно усложняет коммутационную инфраструктуру нижнего уровня сети ЦОДа. Задача поставщиков активного сетевого оборудования – упростить ее, предоставив как можно более унифицированную коммуникационную среду.

На уровне доступа используются два метода размещения коммутаторов, в соответствии с которыми поставщики иногда классифицируют свои продукты. Это подключение серверов одного ряда стоек к од-ному коммутатору с большим числом гигабитных интерфейсов, устанавливаемому в конце этого ряда (End-of-row – EoR), и подключение серверов в каждой стойке к стоечному коммутатору высотой 1U–2U, устанавливаемому вверху стойки (Top-of-rack –ToR). Отдельная тема для разговора – обеспечение коммуникационной среды для блейд-серверов.

Компоновка стоек: ToR против EoR

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

В ToR-конфигурации используются коммутаторы с относительно небольшим числом портов. Для этого типа компоновки могут быть применены продукты большинства опрошенных нами производителей (см. табл. 1). Такой подход позволяет упростить кабельную систему (к стойке уровня агрегации достаточно протянуть кабели обычного или агрегированного uplink-канала). Недостатком, соответственно, является необходимость управлять большим числом коммутаторов. Однако специальные инженерные решения позволяют справиться с этой трудностью.

ToR-компоновка: «виртуальное шасси», или Общая шина на уровне доступа

Ряд поставщиков предлагает решения, которые совмещают преимущества EoR- и ToR-компоновок путем объединения коммутаторов, монтируемых вверху стойки, в некий виртуальный модульный коммутатор с помощью мощной стекирующей шины. С точки зрения системы управления такой стек действительно представляется единым коммутатором, что упрощает администрирование множества отдельных устройств.

Например, у компании Juniper такое решение получило название «виртуальное шасси» (Virtual Chassis, VC). Оно работает только на коммутаторах серии EX4200. Несколько этих коммутаторов (до 10) объединяются стекирующей шиной с кольцевой топологией через два 64-гигабитных VC-порта с результирующей пропускной способностью 128 Гбит/с (допускается также подключение коммутаторов в VC-стек с помощью агрегируемых Ethernet-каналов с пропускной способностью до 40 Гбит/с). Управление виртуальным шасси производится с резервированием по принципу выделения master/backup-коммутаторов.

Метод стекирования для консолидации коммутаторов на уровне доступа при помощи специальной мощной шины используют и другие производители, например компания Nortel в технологии Switch Cluster, позволяющей объединять в кольцо до 8 устройств ERS5600 60-гигабитной шиной (максимальная пропускная в способность в кольце – 120 Гбит/с).

Несмотря на то что у Cisco есть своя технология StackWise для стекирования стоечных коммутаторов, сегодня в нише ToR-размещения компания делает ставку на коммутаторы серии Nexus с технологией так называемых выносных модулей (fabric extenders) с применением топологии «звезда». Идея этого подхода заключается в том, что виртуальный модульный коммутатор образуется за счет подключения к центральному коммутатору (также резервируемому) Nexus 5000 нескольких выносных модулей Nexus 2000, фактически Ethernet-коммутаторов высотой 1U, по обычному или агрегированному соединению из четырех 10GE-каналов. По данным компании, такой «почти неблокируемый виртуальный коммутатор» с 12 выносными модулями может иметь до 576 интерфейсов Gigabit Ethernet.

Справедливости ради надо сказать, что и остальные компании, представившие свои стоечные коммутаторы для компоновки ToR, позволяют строить из них стеки (преимущественно с помощью 10GE-каналов, часто агрегируемых). Но при этом неблокируемая коммутируемая емкость таких стеков значительно ниже, чем у перечисленных выше виртуальных модульных коммутаторов.

В самом деле для ЦОДа?

Опираясь на опрос поставщиков, мы можем выделить несколько общих требований, которым должно отвечать Ethernet-оборудование для ЦОДов:

Повышенная надежность и отказоустойчивость. Надежность коммутирующих устройств в ЦОДе обеспечивается высоким качеством разработки схемотехнических решений и резервированием всех основных модулей: управления, коммутационных матриц, питания и вентиляции. Это правило справедливо даже для младших моделей коммутаторов (см. табл. 1), используемых на уровне доступа, в большинстве которых дублируются модули питания и вентиляторные блоки.

Высокая производительность и плотность портов. Коммутаторы на уровне доступа должны иметь как минимум гигабитные интерфейсы для связи с серверами и 10GE-интерфейсы для uplink-соединений. В силу упомянутого выше большого числа интерфейсов в современных серверах к коммутаторам для ЦОДов предъявляются требования высокой плотности портов. Но физический максимум конструктивной плотности портов фактически уже достигнут – это порядка 48–52 портов на стандартное стоечное устройство высотой 1U (см. фотографии). Поэтому, говоря о плотности, производители часто подразумевают некую удельную пропускную способность на один порт, а она тем выше, чем больше у коммутатора 10GE-интерфейсов. Сегодня компоновку с большим числом таких портов обеспечивают в основном модульные коммутаторы, но некоторые производители предоставляют уже и 1U–2U- стоечные модели 10-гигабитных коммутаторов, например, Cisco – коммутатор Nexus 5000 (до 52 10GE-портов), Juniper – 1U-коммутатор EX2500 (24 10GE-порта), HP – 1U-коммутатор ProCurve 6600-24XG (24 10GE-порта). Такие устройства могут быть использованы при ToR-размещении коммутаторов в стойках с высокопроизводительными серверами, оснащенными 10GE-интерфейсами.

Однако строгий читатель может заметить, что все это справедливо и для любых современных ЛВС. В то же время к сетям ЦОДов сегодня предъявляются определенные специфические требования, связанные, в частности, с применением технологии виртуализации серверов, что сильно отличает такие сети от обычных ЛВС. Эти требования тезисно сформулировал системный инженер-консультант Cisco Александр Скороходов:

Эффективная поддержка больших доменов коммутации 2-го уровня (коммутации Ethernet). Широкое использование миграции виртуальных машин усугубляет данное требование.

Все более высокая производительность и массовый переход на технологию 10-Gigabit Ethernet, поскольку консолидация вычислений приводит к росту нагрузки на сетевые интерфейсы серверов.

Консолидация ввода-вывода (переход на технологии объединенной сети). Использование виртуализации приводит к росту доли серверов, подключенных к сетям хранения данных, что делает особенно актуальной задачу консолидации ввода-вывода, т.е. отказа от отдельного подключения серверов к сетям Ethernet и Fibre Channel, а в перспективе, возможно, и от отдельных сетей передачи данных и хранения данных.

В результате своего небольшого исследования мы выяснили, что, если не считать некоторых концепций и сетевых архитектур (например, Data Center Infrastructure Solutions фирмы Juniper или аналогичных концепций HP и Nortel) и «точечных» моделей ком-мутаторов, поставщики в основном позиционируют свое Ethernet-оборудование как универсальное, которое может использоваться как в корпоративных и операторских транспортных сетях, так и в сетях ЦОДов.

Взяв на себя определенный риск, компания Cisco выпустила целую линию продуктов, позиционируемую как специализированное оборудование для ЦОДа. В нее входят коммутаторы серий Nexus 7000, 5000, 2000 и 1000V. Последний представляет собой виртуальный программный коммутатор, обслуживающий виртуальные же серверы в среде гипервизора VMware. (Можно сказать, что на наших глазах начинается этап перетаскивания очередного слоя оборудования в «зазеркалье» виртуализации.) Линия продуктов Nexus – не последняя инициатива Cisco в рамках ее концепции Data Center 3.0. Весной этого года компания вышла на рынок с новой линией продуктов Unified Computing System, поставляемой в формате блейд-шасси, и серверов для них, которые включают в себя полную сетевую инфраструктуру с конвергированной Ethernet-средой и использованием как минимум 10GE-интерфейсов. Тем самым рынку Ethernet-оборудования брошен вызов, и уже в ближайшее время можно ожидать, что на нем разгорится борьба в сфере специализированных комплексных сетевых решений для ЦОДов.

Источник

Содержание

Пусть наш Сервис-Провайдер LAN_DC будет, например, хостить обучающие видео о выживании в застрявших лифтах.
В мегаполисах это пользуется бешенной популярностью, поэтому физических машин надо много.
Сначала я опишу сеть приблизительно такой, какой бы её хотелось видеть. А потом упрощу для лабы.

Физическая топология

Локации

У LAN_DC будет 6 ДЦ:

Внутри ДЦ (Intra-DC)

Во всех ДЦ идентичные сети внутренней связности, основанные на топологии Клоза.
Что за сети Клоза и почему именно они — в отдельной статье.
В каждом ДЦ по 10 стоек с машинами, они будут нумероваться как A, B, C итд.
В каждой стойке по 30 машин. Они нас интересовать не будут.
Также в каждой стойке стоит коммутатор, к которому подключены все машины — это Top of the Rack switch — ToR или иначе в терминах фабрики Клоза будем называть его Leaf.
Общая схема фабрики.
Именовать их будем XXX-leafY, где XXX — трёхбуквенное сокращение ДЦ, а Y — порядковый номер. Например, kzn-leaf11.

Каждый ToR-коммутатор в свою очередь соединён с четырьмя вышестоящими агрегирующими коммутаторами — Spine. Под Spine’ы выделено по одной стойке в ДЦ. Именовать будем аналогично: XXX-spineY.
В этой же стойке будет стоять сетевое оборудование для связности между ДЦ — 2 маршрутизатора с MPLS на борту. Но по большому счёту — это те же самые ToR’ы. То есть с точки зрения Spine-коммутаторов не имеет никакого значения обычный там ToR с подключенными машинами или маршрутизатор для DCI — один чёрт форвардить.
Такие специальные ToR’ы называются Edge-leaf. Мы их будем именовать XXX-edgeY.
Выглядеть это будет так.
На схеме выше edge и leaf я действительно разместил на одном уровне. Классические трёхуровневые сети приучили нас рассматривать, аплинк (собственно отсюда и термин), как линки вверх. А тут получается «аплинк» DCI идёт обратно вниз, что некоторым немного ломает привычную логику. В случае крупных сетей, когда датацентры делятся ещё на более мелкие единицы — POD‘ы (Point Of Delivery), выделяют отдельные Edge-POD‘ы для DCI и выхода во внешние сети.
Для удобства восприятия в дальнейшем я буду всё же рисовать Edge над Spine, при этом мы будем держать в уме, что никакого интеллекта на Spine и отличий при работе с обычными Leaf и с Edge-leaf нет (хотя тут могут быть нюансы, но в целом это так).
Схема фабрики с Edge-leaf’ами.
Троица Leaf, Spine и Edge образуют Underlay-сеть или фабрику.
Задача сетевой фабрики (читай Underlay), как мы уже определились в прошлом выпуске, очень и очень простая — обеспечить IP-связность между машинами как в пределах одного ДЦ, так и между.
Оттого-то сеть и называется фабрикой, так же, например, как фабрика коммутации внутри модульных сетевых коробок, о чём подробнее можно почитать в СДСМ14.

А вообще такая топология называется фабрикой, потому что fabric в переводе — это ткань. И сложно не согласиться:

Фабрика полностью L3. Никаких VLAN, никаких Broadcast — вот такие у нас в LAN_DC замечательные программисты, умеют писать приложения, живущие в парадигме L3, а виртуальные машины не требуют Live Migration c сохранением IP-адреса. И ещё раз: ответ на вопрос почему фабрика и почему L3 — в отдельной статье.

DCI — Data Center Interconnect (Inter-DC)

DCI будет организован с помощью Edge-Leaf, то есть они — наша точка выхода в магистраль.
Для простоты предположим, что ДЦ связаны между собой прямыми линками.
Исключим из рассмотрения внешнюю связность.

Я отдаю себе отчёт в том, что каждый раз, как я убираю какой-либо компонент, я значительно упрощаю сеть. И при автоматизации нашей абстрактной сети всё будет хорошо, а на реальной возникнут костыли.
Это так. И всё же задача этой серии — подумать и поработать над подходами, а не героически решать выдуманные проблемы.

На Edge-Leaf’ах underlay помещается в VPN и передаётся через MPLS-магистраль (тот самый прямой линк).
Вот такая верхнеуровневая схема получается.

Маршрутизация

Для маршрутизации внутри ДЦ будем использовать BGP.
На MPLS-магистрали OSPF+LDP.
Для DCI, то есть организации связности в андерлее — BGP L3VPN over MPLS.
Общая схема маршрутизации
На фабрике никаких OSPF и ISIS (запрещённый в Российской Федерации протокол маршрутизации).
А это значит, что не будет Auto-discovery и вычисления кратчайших путей — только ручная (на самом деле автоматическая — мы же здесь про автоматизацию) настройка протокола, соседства и политик.
Схема маршрутизации BGP внутри ДЦ
Почему BGP?
На эту тему есть целый RFC имени Facebook’a и Arista, где рассказывается, как строить очень крупные сети датацентров, используя BGP. Читается почти как художественный, очень рекомендую для томного вечера.
А ещё целый раздел в моей статье посвящён этому. Куда я вас и отсылаю.
Но всё же если коротко, то никакие IGP не подходят для сетей крупных датацентров, где счёт сетевым устройствами идёт на тысячи.
Кроме того использование BGP везде позволит не распыляться на поддержку нескольких разных протоколов и синхронизацию между ними.

Положа руку на сердце, на нашей фабрике, которая с большой долей вероятности не будет стремительно расти, за глаза хватило бы и OSPF. Это на самом деле проблемы мегаскейлеров и клауд-титанов. Но пофантазируем всего лишь на несколько выпусков, что нам это нужно, и будем использовать BGP, как завещал Пётр Лапухов.

Политики маршрутизации

На Leaf-коммутаторах мы импортируем в BGP префиксы с Underlay’ных интерфейсов с сетями.
У нас будет BGP-сессия между каждой парой Leaf-Spine, в которой эти Underlay’ные префиксы будут анонсироваться по сети тудыть-сюдыть.
Внутри одного датацентра мы будем распространять специфики, которые импортировали на ТоРе. На Edge-Leaf’ах будем их агрегировать и анонсировать в удалённые ДЦ и спускать до ТоРов. То есть каждый ТоР будет знать точно, как добраться до другого ТоРа в этом же ДЦ и где точка входа, чтобы добраться до ТоРа в другом ДЦ.
В DCI маршруты будут передаваться, как VPNv4. Для этого на Edge-Leaf интерфейс в сторону фабрики будет помещаться в VRF, назовём его UNDERLAY, и соседство со Spine на Edge-Leaf будет подниматься внутри VRF, а между Edge-Leaf’ами в VPNv4-family.
А ещё мы запретим реанонсировать маршруты полученные от спайнов, обратно на них же.
На Leaf и Spine мы не будем импортировать Loopback’и. Они нам понадобятся только для того, чтобы определить Router ID.
А вот на Edge-Leaf’ах импортируем его в Global BGP. Между Loopback-адресами Edge-Leaf’ы будут устанавливать BGP-сессию в IPv4 VPN-family друг с другом.
Между EDGE-устройствами у нас будет растянута магистраль на OSPF+LDP. Всё в одной зоне. Предельно простая конфигурация.
Вот такая картина с маршрутизацией.

BGP ASN

Edge-Leaf ASN

На Edge-Leaf’ах будет один ASN во всех ДЦ. Это важно, чтобы между Edge-Leaf’ами был iBGP, и мы не накололись на нюансы eBGP. Пусть это будет 65535. В реальности это мог бы быть номер публичной AS.

Spine ASN

На Spine у нас будет один ASN на ДЦ. Начнём здесь с самого первого номера из диапазона приватных AS — 64512, 64513 итд.
Почему ASN на ДЦ?
Декомпозируем этот вопрос на два:

Почему одинаковые ASN на всех спайнах одного ДЦ
Вот как будет выглядеть AS-Path Андерлейного маршрута на Edge-Leaf:

При попытке заанонсировать его обратно на Спайн, тот его отбросит потому что его AS (Spine_AS) уже есть в списке.
Однако в пределах ДЦ нас совершенно устраивает, что маршруты Underlay, поднявшиеся до Edge не смогут спуститься вниз. Вся коммуникация между хостами внутри ДЦ должна происходить в пределах уровня спайнов.
При этом агрегированные маршруты других ДЦ в любом случае беспрепятственно будут доходить до ТоРов — в их AS-Path будет только ASN 65535 — номер AS Edge-Leaf’ов, потому что именно на них они были созданы.
Почему разные в разных ДЦ
Теоретически нам может потребоваться протащить Loopback’и каких-нибудь сервисных виртуальных машин между ДЦ.
Например, на хосте у нас запустится Route Reflector или тот самый VNGW (Virtual Network Gateway), который по BGP запирится с ТоРом и проанонсирует свой лупбэк, который должен быть доступен из всех ДЦ.
Так вот как будет выглядеть его AS-Path:

И здесь нигде не должно быть повторяющихся ASN.
То есть Spine_DC1 и Spine_DC2 должны быть разными, ровно как и leafX_DC1 и leafY_DC2, к чему мы как раз и подходим.

Как вы, наверно, знаете, существуют хаки, позволяющие принимать маршруты с повторяющимися ASN вопреки механизму предотвращения петель (allowas-in на Cisco). И у этого есть даже вполне законные применения. Но это потенциальная брешь в устойчивости сети. И я лично в неё пару раз проваливался.
И если у нас есть возможность не использовать опасные вещи, мы ей воспользуемся.

Leaf ASN

У нас будет индивидуальный ASN на каждом Leaf-коммутаторе в пределах всей сети.
Делаем мы так из соображений, приведённых выше: AS-Path без петель, конфигурация BGP без закладок.
Чтобы маршруты между Leaf’ами беспрепятственно проходили, AS-Path должен выглядеть так:

где leafX_ASN и leafY_ASN хорошо бы, чтобы отличались.
Требуется это и для ситуации с анонсом лупбэка VNF между ДЦ:

Будем использовать 4-байтовый ASN и генерировать его на основе ASN Spine’а и номера Leaf-коммутатора, а именно, вот так: Spine_ASN.0000X.

Вот такая картина с ASN.

IP-план

Принципиально, нам нужно выделить адреса для следующих подключений:

Если в ДЦ нам не будет хватать выделенных диапазонов (а их не будут — мы же претендуем на гиперскейлероство), просто выделяем следующий блок.
Вот такая картина с IP-адресацией.
Loopback’и:

Два вендора. Одна сеть. АДСМ.
Juniper + Arista. Ubuntu. Старая добрая Ева.
Количество ресурсов на нашей виртуалочке в Миране всё же ограничено, поэтому для практики мы будем использовать вот такую упрощённую до предела сеть.
Два датацентра: Казань и Барселона.

Полная конфигурация всех сетевых устройств, которую мы будем пробовать воспроизвести с помощью автоматики.

Заключение

Так же принято? Под каждой статьёй делать короткий вывод?
Итак мы выбрали трёхуровневую сеть Клоза внутри ДЦ, поскольку ожидаем много East-West трафика и хотим ECMP.
Разделили сеть на физическую (андерлей) и виртуальную (оверлей). При этом оверлей начинается с хоста — тем самым упростили требования к андерлею.
Выбрали BGP в качестве протокола маршрутизации анедрелейных сетей за его масштабируемость и гибкость политик.
У нас будут отдельные узлы для организации DCI — Edge-leaf.
На магистрали будет OSPF+LDP.
DCI будет реализован на основе MPLS L3VPN.
Для P2P-линков IP-адреса мы будем вычислять алгоритмически на основе имён устройств.
Лупбэки будем назначать по роли устройств и их расположению последовательно.
Андерлейные префиксы — только на Leaf-коммутаторы последовательно на основе их расположения.
Предположим, что прямо сейчас у нас ещё не установлено оборудование.
Поэтому наши следующие шаги будут — завести их в системах (IPAM, инвентарная), организовать доступ, сгенерировать конфигурацию и задеплоить её.
В следующей статье разберёмся с Netbox — системой инвентаризации и управления IP-пространством в ДЦ.

Спасибы

Оставайтесь на связи

Особо благодарных просим задержаться и пройти на Патреон.

Источник