Компания
306,14
рейтинг
21 июня 2014 в 17:02

Разное → SDN: революция или эволюция? Семинар в Яндексе

Привет, меня зовут Даниил Гинсбург, я работаю в Яндексе сетевым архитектором.

В своем докладе я попытался дать свое определение понятия Software-defined Network, которое сегодня понимается в индустрии как чрезмерно широко, так и чрезмерно узко. Мой рассказ также затронул исторические корни SDN, его будущее и вопросы практического развертывания.



Видеозапись доклада



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



Сложность


Что же сейчас не так в сетевом мире? Первое, что нас убивает – это сложность. Наши сетевые решения, наши сети сложны. Сложность нам мешает масштабироваться, управлять сетями, делает их хрупкими. Сложность – наш враг. Передача полезного трафика (data-plane устроена сложно. Data-plane наших железок умеет кучу всего: форвардить миллионы инкапсуляций, делать миллион разных тоннелей (причем, мы продолжаем изобретать новые). Есть люди, которые строят из этого абсолютно ужасные конструкции.

Например, гоняют multicast через IRB, который торчит в VPLS, под которым лежат link aggregation groups. Такую штуку невозможно масштабировать, невозможно отлаживать. И стоит это дорого, дорого и в плане железа, и в плане рабочего времени.

Всем этим богатством возможностей data-plane нужно как-то управлять. А раз все это хозяйство такое сложное, то и управлять им сложно.

Мы строим дикие бутерброды из протоколов, и наши протоколы управления развиваются сиюминутно.

Мой любимый (хоть и не самый вопиющий) пример сиюминутности – это Multiprotocol BGP. Для того чтобы анонсировать маршрут по нему, next hop в этом анонсе должен иметь ту же самую address family (v4, v6 или что-то еще). Когда мы хотим v4-маршрут c v6 next hop, мы начинаем придумывать новые RFC. Соответственно, у нас есть n NLRI, то потенциально появляется n2 RFC. Это ужасная, ущербная и невыразительная абстракция.

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

Все это обходится очень дорого. Сетевой элемент, который имеет огромную сложность в data-plane и control-plane, в конкретном случае использует, скажем, 5% возможностей, а оплачивается на все 100. И оплачивается не только ценой железки, но и сложностью ПО, которое на ней используется, багами в нем, хрупкостью сети.

Feature velocity


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

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

Что с этим делать


Очевидно, что нужно с этим всем что-то делать. Например, переделать вообще все и назвать это SDN.

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

Так что же такое SDN? Это нечто, которое даст нам удобные абстракции. Они будут простыми, понятными естественными, выразительными и полными. Это позволит реализовывать необходимые функции сети самостоятельно, а не ждать, когда вендор сделает это. Естественно, упростится и автоматизация.

Во-первых, разделить прохождение трафика (data-plane) и сигнализацию/управление (control plane). Во-вторых, сделать элементы data-plane максимально простыми и, в-третьих, централизовать control-plane. Это все позволит быстро и просто реализовывать удобные абстракции в control-plane независимо от data-plane.

Теперь разберем все эти идеи по порядку.

Разделение data-plane и control-plane


Первый вопрос, который возникает в связи с разделением data-plane и control-plane – насколько их нужно разделить?

Это далеко не новая идея, это делали или пытались делать уже много раз. Так, например, устроен любой современный маршрутизатор. Есть элементы data-plane: форвардинговые движки, которые принимают пакеты и решают, куда их форвардить, есть соединяющая их матрица коммутации. Модуль управления существует отдельно. Пользовательский трафик течет насквозь, трафик управления поступает в control engine, который программирует forwarding engine.



Такой подход позволяет масштабировать отдельный сетевой элемент. С другой стороны такой подход крайне усложняет модель отказов. Такая составная конструкция ломается по частям. Более того, даже data-plane может сломаться частично. Например, если у вас сломалась матрица коммутации, а control engine этого не заметил, весь пользовательский трафик будет просто дропаться. Управленческий трафик будет продолжать ходить, и все будут думать, что наш сетевой элемент жив.

На схеме этого нет, но синий трафик идет через отдельную внутреннюю cеть out-of-band-управления. И эта сеть также может отказать. Если мы возьмем и разделим data-plane и control-plane не в рамках одного сетевого элемента, а в рамках всей сети, то cеть out-of-band-управления станет столь же сложной, что и наш data-plane. Соответственно, ломаться она станет так же часто и плохо, как и основная сеть.

Возникает также вопрос, а как же управлять управляющей сетью, если она столь же сложна, что и сеть, передающая полезный трафик?

Упрощение элементов сети


Перейдем к идее упрощения элементов data-plane. Мы должны придумать достаточно простую и общую абстракцию для управления сетевым элементом. Простую, понятную, достаточно гибкую и выразительную.

Насколько простой должна быть эта абстракция? Если не вдаваться глубоко в детали, data-plane выглядит следующим образом: к нам приходит пакет, мы берем поля из заголовка делаем lookup в таблице форвардинга, модифицируем заголовки пакета и отправляем в следующий интерфейс.

Реальность несколько сложнее. Вот так выглядит сильно упрощенная схема того, что происходит в одном чипе сетевого элемента:



Какую абстракцию элементов data-plane нам предлагает OpenFlow? У нас есть поля, есть таблица лукапов, мы делаем поиск, определяем, что нужно сделать и воплощаем это. Все предельно просто.

Одна из проблем с абстракцией в OpenFlow 1.0 – это комбинаторный взрыв. Для примера возьмем простую искуственную задачу. Нам нужно пропускать трафик на N хостов на одни и те же M TCP-портов, а остальной трафик сбрасывать. В OpenFlow 1.0 для этого нам потребуется NxM записей, придется перечислить все комбинации хост-порт. Масштабировать это не получится.

В OpenFlow 1.1 и всех последующих версиях появляется идея множественных таблиц. Это избавляет от комбинаторного взрыва. Идея сравнительно элегантная, но у нее есть проблема, она плохо отражается на железе. Дело в том, что железо, которое стоит разумных денег, не умеет делать лукапы в произвольном порядке.

В современном железе есть возможность делать многостадийную обработку. Находим в таблице соответствующую запись, а дальше проводим несколько стадий обработки: добавляем метку, перезаписываем заголовок, потом еще что-нибудь и т.д. Называется это indirect next hops: один next hop в этом случае ссылается на другой по индексу таблицы. Т.е. находить следующий просто. Однако, в конструкции с множественными таблицами у нас нет непосредственных ссылок, и мы вынужденны будем делать multifield lookup несколько раз, а это достаточно затратно. Однако от комбинаторного взрыва мы избавляемся и та же задача с N хостов и M портов решается гораздо проще: у на будет две таблицы: N записей в одной и M записей в другой.

В рамках организации Open Networking Foundation, которая разрабатывает и стандартизирует OpenFlow, работает Forwarding Abstractions working group (FAWG). Разрабатываемая этой группой идея заключается в том, чтобы опрашивать сетевые элементы о том, какую последовательность лукапов они могут сделать. Т.е. когда контроллер делает запрос, сетевой элемент предоставляет ему информацию обо всем том чудовищном пайплайне, который представлен на предыдущей картинке.

Но куда же делась абстракция?

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

Централизация и децентрализация


Попробуем определить, насколько централизованным должен быть control-plane. Тут есть пространство для маневра. Централизация и децентрализация – процесс колебательный.

Те, кто достаточно давно работают в индустрии, скорее всего, со мной согласятся. Один из примеров, d котором мы уже прошли несколько циклов. Мы покупаем BRAS и ставим его в середине. Понимаем, что у нас ничего не масштабируется, растащим его по краям. Теперь теряется управление, снова возвращаемся к централизации, покупаем BRAS побольше и ставим его в середину. И так далее.

Это естественный процесс, от которого никуда не деться. Он диктуется не только модой и маркетингом, но и вполне объективными факторами, техническим прогрессом. С централизацией и децентрализацией в control-plane все будет происходить точно так же.

Что нам в этом плане предлагают радикалы от OpenFlow-подхода? Предполагается, что сам сетевой элемент крайне туп и неспособен ни как каким самостоятельным действиям, что ему контроллер говорит, то он и делает.

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

Так что же делать на самом деле?


Главное – это умерить революционный пыл и подойти к SDN с эволюционной точки зрения.

Все то, что нам обещает SDN, все то, о чем мы говорили в начале – действительно хорошо. Это то, к чему нам нужно стремиться. Мы должны приложить все усилия, чтобы эти обещания сбылись.

Так что же нам для этого нужно сделать?

Во-первых, стандартизировать один механизм data-plane. Для управления всем разнообразием протоколов, конструкций и механизмов, которые есть в сегодняшнем data-plane, нет никакого разумного способа.

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

Оба стиля управления – централизованный и децентрализованный – важны. Есть естественно централизованные функции, например, высокоуровневые политики.

И в то же время существуют децентрализованные по своей природе функции, например, перемаршрутизация при сбоях. Кроме того, есть функции, которые можно реализовывать так, как это выгодно здесь и сейчас. К таким функциям можно отнести вычисление пути. Например, внутри дата-центра у меня нет никакой потребности делать traffic-engineering, там просто нет необходимости экономить полосу. А вот в WAN уже может потребоваться traffic-engineering, и его можно и иногда нужно делать централизованно.

Сеть может иметь доменную структуру: например, DC и WAN, access и core, RAN и blcackhaul. Разные части сети выполняют различные функции, они устроены по-разному, и подходят им разные типы управления. Соответственно, чтобы сеть была единой, разные части сети нужно «сшивать» и «накладывать» друг на друга. Поверх доменов мы можем сделать транспорты, а поверх этих транспортов – «сервисы».

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

Эта абстракция должна позволять комбинировать разные стили управления. Если какая-то функция реализована классическим способом в виде распределенного сигналинга, а другая – в виде централизованного управления, они должны уметь друг с другом взаимодействовать.

Один из многообещающих подходов – это i2rs от IETF. Это несколько более высокоуровневая модель, чем предлагаемый OpenFlow. Например, i2rs оперирует не записями в таблице форвардинга, а понятием маршрута.

Где мы сейчас


Что технический прогресс позволяет нам сделать сегодня и в самое ближайшее время?

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

В качестве транспорта у нас есть IP/MPLS. Мы умеем делать простую MPLS-сеть, делать транспорт.

95% сложности MPLS control-plane сосредоточена в организации сервисов. Именно здесь должны быть сосредоточены усилия.

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

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

При этом, каковы бы ни были наши политики, мы не трогаем транспорт. В нем ничего не меняется, он не знает ни про наши политики, ни про наложенную сеть.

Заключение


Подводя итоги, хочется повторить идею о том, что SDN, что бы под ним ни подразумевалось, действительно обещает нам хорошие вещи, их нужно претворять в жизнь. Однако, это нужно делать правильными инструментами, а не приравнивать SDN и OpenFlow.
Автор: @yadbg
Яндекс
рейтинг 306,14

Комментарии (82)

  • +1
    Спасибо.
  • 0
    А зачем v4 маршрут и v6 next-hop?
    • 0
      rfc5549, раздел 6.
    • 0
      А зачем выделять линковую IPv4 сеть, если по факту next hop нужен лишь чтобы получить mac?
  • +3
    Первая адекватная статья про SDN на хабре! Не забыт даже тот факт, что концепции разделения control plane и data plane сто лет в обед! Все-таки приятно, когда о таких вещах пишет инженер, а не маркетолог.

    А про последний пункт можно поподробнее? Я правильно понимаю, что у вас LSP сигнализируются сразу с хоста? И нечто подобное когда-то давно было модно…
    • +1
      Метки от хоста. При некоторой ухищренности их можно сделать заранее известными, и тем самым избавиться от сигнализации к хосту.

      Вот тут лежит наша с Димой Афанасьевым презентация с одной конференции, где про это есть немного:


      Но вообще, это отдельная большая тема, где может быть несколько разных подходов со своими достоинствами и недостатками. Может быть, когда-нибудь потом, если мы соберемся, то расскажем отдельно. Наверное.
      • 0
        Слайды 1-24 читаются так, как будто Яндекс только открыл для себя MPLS VPN и TE, и очень тащится от этого новомодного функционала :)

        Слайду 32 аплодирую. Каждому пункту. Это прелесть, когда архитектура приложений такое позволяет.

        Только на слайде 34, кажется, понял, зачем вам MPLS до хостов. Это теория, или это у вас реально работает? Насколько быстра и надежна реакция на падение одного из линков от свитча до хоста (когда надо перевести трафик либо на другой линк этого свитча, либо на другой свитч), и как это реализовано в условиях, когда до доставки до других хостов информации о необходимости перемаршрутизации трафика связь с ними будет лишь односторонней? Или вас совсем не волнует смерть хоста, просто выберется другой хост? Каким механизмом хосты обмениваются подобной информацией между собой — перепиленный BGP или нечто свое? Кто пишет control plane софт для LSR'ов, и как они распределяют между собой свои «хостовые» метки? Label swap на каждом хопе производится на почти-рандомную выданную соседом метку (LDP-way), или на ту же самую (segment routing-way)? Path protection внутри площадки используете?

        Вообще, мне кажется, при разработке этой архитектуры кто-то вдохновился segment routing'ом. Чертовски похоже. Разве что в нем первые N меток (N>=2) могли бы определять путь до последнего хопа и его порта (а не просто идентифицировать его), а дальше можно засунуть соответствующую виртуалке метку. При остром желании, следующая — интерфейс виртуалки.
        Может быть, когда-нибудь потом, если мы соберемся, то расскажем отдельно.

        Жду статью «кратко об архитектуре сети Яндекса». В принципе, я уже заинтригован этими слайдами. Гугл и Амазон не раскалываются — может, хоть вы что-нибудь расскажете…
        • +1
          Вообще, мне кажется, при разработке этой архитектуры кто-то вдохновился segment routing'ом.


          Есть немного. :) И есть далеко идущие планы активно скрещивать нашу конструкцию с SR для решения самых разных задач. И мы плотно работаем с Кларенсом Филсфилсом над этим — вот одно из последнего: tools.ietf.org/html/draft-filsfils-spring-segment-routing-central-epe-00. Будет еще. Stay tuned.

          Слайды 1-24 читаются так, как будто Яндекс только открыл для себя MPLS VPN и TE, и очень тащится от этого новомодного функционала


          Иногда приходится объяснять очевидные вещи, которые почему-то оказываются очевидными далеко не всем.
          • 0
            Так все-таки, сказанное — теория, или практика на вашей боевой сети?

            От чтения RFC (особенно — обзорв ных) меня всегда клонит в сон, так что жду статью с человеческим описанием подхода, в том числе при указанных мной выше сценариях :)
            • 0
              Нет, это еще не production, сейчас пока стадия отладки в лаборатории.
              • 0
                Ну тогда не интересно… Слайды написаны так, будто описывают нечто уже работающее. Т.е. сейчас у вас нечто «a bit outdated» в продакшне, а также L2 и прочее?
                • 0
                  Нельзя просто так взять и заставить вендоров сделать то, что тебе нужно. Особенно, когда вендор думает, что он знает лучше. Это занимает некоторое время. Но в итоге удается, рано или поздно :)
                  • 0
                    Гугл сам себе вендор. Не подумываете? Вроде мозги имеются.
                    • 0
                      Не на этом этапе.
                  • 0
                    Опять же про MPLS. А есть какая-то информация, что вендоры развивают это направление в чипах ориентированных на применение в ДЦ?
                    Тут как раз кстати строчка из вашей презентации, что мы заложники вендоров. Не получится ли так, что все ваши наработки уйдут коту под хвост только из-за того, что вендор не сделает соответствующую поддержку?
                    • 0
                      Есть не просто информация. Есть живые чипы, и есть оборудование, построенное на этих чипах. Например, Trident 2 от Broadcom.
                      • 0
                        Ну а в качестве оборудования можно привести пример Nexus 9500, который на этом чипсете базируется. Коммутатор как раз ориентрован на DC.
                        • 0
                          Но, помнится, в N9K Trident соседствует с собственными цискиными ASICами, и на трайденте разве что базовый L3, остальным другие чипы занимаются.
                          • 0
                            А при чем здесь вообще L3? Не уловил. Самое главное в данном контексте это парсинг пакета, дальше L2/L3 lookup, и то и другое делается на trident. Custom ASIC из того что запомнилось занимается VoQ, буферизацией и общением с фабрикой. L3 лишь малая часть забот trident-2.
                            • 0
                              У меня отложилось в памяти, что там работой с пакетами с метками там занимается custom asic, как и тем самым QoS, наворотами ACI и так далее. Trident — только L3 форвардинг. Ну видимо был не прав. Сейчас найти подтверждение не удалось.
                              • 0
                                BRKDCT-3640 там на слайдах много чего перечислено было.
                                • 0
                                  Его и смотрел. Там говорится, что Trident — это вдобавок ко всему сказанному vxlan bridging (не routing) и самые общие интерфейсные счетчики. Про MPLS там нет. Но, опять же, «fast re-route» под «custom asic»… Что под этим понимать-то? Может, оно и есть в том числе.
                                  • 0
                                    Мне казалось что для 9000 функционал этот еще не открывали общественности, может поэтому про mpls мало информации. Но всегда можно посмотреть даташит на StrataXGS Trident II
                      • 0
                        Да, есть, но также важно как оно там сделано. Процитирую Ivan Pepelnjak:
                        Due to lack of customer requests, MPLS is not the primary focus of merchant silicon vendors. Even though FM 6000 supports MPLS, it needs TCAM to match MPLS labels wasting precious hardware resources – the more MPLS labels a switch supports, the fewer ACL or PBR entries it could have.
                        • 0
                          О да, конечно, важно. И таки сделано оно там далеко не идеально (хотя и достаточно, чтобы быть полезным уже сегодня). Там есть некоторые неприятные подробности, которые на сегодня ограничивают масштабирование, впрочем, эти подробности касаются не только и не столько реализации MPLS — эти же ограничения касаются и обычной IP-fabric. В следующих поколениях бродкомовских чипсетов будет лучше.
  • 0
    Статья хорошая, но побольше бы вашего мнения о SDN, а не только по OpenFlow. И про практический опыт было бы здорово узнать, наверняка Яндекс делает эксперименты.
    Помнится мне на YACе выступал кто-то из Cumulus Networks. Пробовали ли вы их продукт? Какое мнение относительно концепции Pluribus Networks?

    Если я правильно вас понял, то вы за MPLS везде и всюду, в том числе, ДЦ. Тогда ответьте на простой вопрос — почему никто из больших игроков (FB, Google, Amazon) не использует MPLS в своих ДЦ?

    Вообще у меня складывается ощущение, что многие вендоры ориентируются все таких на чистый Ethernet/IP. Плюс всякого рода оверлеи. MPLS в западной блогосфере в темах про SDN не упоминается.
    • 0
      MPLS в западной блогосфере в темах про SDN не упоминается

      Упоминается приблизительно везде, если автор живет в реальном мире, а не в мире фантазий. В мире фантазий как раз можно разместить один контроллер на сеть и обойтись безмозглыми форвардерами. В реальном мире такое по понятным причинам работать не может.

      Все смотрят на гибридные подходы, когда у сетевого оборудования все-таки есть мозги, а механизмы SDN используется скорее для внедрения отдельных правил в FIB по мере надобности.

      А у Google как минимум до недавнего времени (скорее всего, сейчас тоже) использовалось нечто свое, но очень смахивающее на MPLS.

      • 0
        Не исключаю, что не попадались на глаза толковые статьи про MPLS. Буду благодарен на ссылочки, особенно интересно было бы почитать, что сейчас вендоры делают по MPLS в разрезе железа.

        Я про централизацию в один контроллер ничего и не говорил, но вообще поддерживаю гибридные решения. Идея с один (несколькими) контроллерами меня не воодушевляет особо. В связи с этим про Pluribus и заговорил. Очень понравился их подход. Надеюсь Яндекс пригласит их на YaC в следующем году, или какой-ть другое мероприятие по этому вопросу устроит.
        • +1
          интересно было бы почитать, что сейчас вендоры делают по MPLS в разрезе железа.

          Например. Еще. Еще. Еще. Еще. Еще. Хотя именно в разрезе железа с MPLS не так много чего происходит, все-таки штука очень простая. Из более-менее важного — научить железку заглянуть сквозь 16 меток на IP заголовок для ECMP :) Хотя всякие GMPLS, MPLS-TP…

          Про блогосферу я имел в виду, что обычно рядом с «SDN вон что может» упоминают «вообще-то MPLS мог такое издавна» :)
          • 0
            Спасибо, ознакомлюсь.
            Однако на циске мир клином не сошелся.

            Согласен, что у MPLS большой потенциал, но почему-то его не раскрыли или раскрыли, но не донесли до масс, или еще что-то. Относительно недавно читал информацию о возможных причинах почему MPLS так и не полетел, если правильно помню, то там говорилось про плохое визабилити работы MPLS сети (могу ошибаться). Не могу сейчас вспомнить источник, чуть позже поищу и отпишусь.
            • 0
              на циске мир клином не сошелся.

              А там много многовендорного. По первой ссылке «The session begins with an overview of the activities in the most relevant IETF working groups». Например, как выше выяснилось, циска совместно с яндексом продвигает segment routing… Еще презенташка про то, над чем думает IETF. На примере циски можно много чего рассматривать, потому что это наиболее открытый вендор.
              Относительно недавно читал информацию о возможных причинах почему MPLS так и не полетел

              Уже на этой фразе можно назвать ту информацию бредом. MPLS взлетел. Еще как взлетел. Он везде — и у операторов (где его изначально и предполагалось использовать), и в ентерпрайзе. Лично я без него жизни не представляю.

              Все-таки не переборщите с блогосферой. Блоги разные бывают. Какие-то (вроде etherealmind) могут вести люди, которые вроде грамотные, но могут зациклиться на чем-то одном как это произошло с Greg Ferro и SDN (он уже выздоровел и не считает это панацеей от всех болезней). Раньше перегибал палку.
              там говорилось про плохое визабилити работы MPLS сети

              Всё дорабатывается. Со всякими OAM он не отстает от любых конкурентов.
              • 0
                Он везде

                Тут каждый смотрит со своей колокольни. Я бы так не сказал. Согласен, что для операторов на транспорте это их все.
                Но давайте возьмем, например, домовые сети, их огромное множество, почему же там нет MPLS и даже если есть, то как капля в море?
                • 0
                  Потому что домовые сети бывают аж в виде единого L2 на целый район. Там правят L2 технологии, QinQ например. Общая цель — как можно сильнее снизить стоимость оборудования, а L2 свитч априори дешевле умеющего MPLS L3 свитча (или openflow форвардера, раз уж мы говорим от SDN). А еще человеку, который хорошо умеет работать с технологиями на базе MPLS, придется платить больше.

                  Я как-то помогал в изменении дизайна одной городской сети. Там было L2 кольцо по всему городу. С STP. С дефолтными таймерами. И радиорелейками на паре участков. Этот недо-провайдер был безальтернативным ОПМ для одного важного канала, и меня откровенно бесили пропадания связи на 40-50 секунд несколько раз в день, пока STP пересоберется.

                  Но то, что такая сеть существует в природе, не значит, что она хоть чем-то (кроме стоимости оборудования) хороша.
                  • 0
                    Так а почему цена на MPLS железо высокая — потому, что массовости нет. L2 мыльницы с кучей функционала стоят копейки исключительно из-за массовости.

                    Мне вот интересно, почему же MPLS не взял верх над всем этим зоопарком L2 фич, которые используются на доступе? Насколько я понимаю, с MPLS все можно было бы сделать очень элегантно. Мне действительно это интересно. Буду очень благодарен за мысли или теории.
                    • 0
                      L2 мыльницы с кучей функционала стоят копейки исключительно из-за массовости.

                      Неверно. Способные лишь на L2 (вариант — с самым базовым L3 функционалом) чипы устроены намного проще своих полноценных L3шных собратьев. Можно обойтись минимумом дорогущей памяти для форвардеров (CAM на десятки тысяч записей и, возможно, ACL TCAM для продвинутых вариантов).

                      Посмотрите на схему одного из супов моего любимого свитча. В левой части то, что непосредственно передает пакеты (PFC3). Понятно, что выкидыванием L3 engine и всего связанного с ней можно сильно снизить стоимость? Простой коммутируемый в пределах VLANа транзитный пакет туда все равно не попадет.

                      Далее — софт под них куда проще писать, так как фич почти нет, это тоже означает удешевление.

                      Когда говорите «MPLS свитч», всегда подразумевайте «это L3 свитч, но не простой L3 свитч, а еще и умеющий передавать трафик с метками»,
              • 0
                Или вот еще, почему в IX не используют MPLS?

                Если в MPLS все давно уже, почему просто не дотянут его до конечного пользователя? Почему вендоры не делают на доступ свитчи с MPLS?

                P.S. Еще раз замечу, что ничего лично против MPLS не имею, но считаю, что дальше операторов MPLS полноценно так и не распространился.
                • 0
                  почему в IX не используют MPLS?

                  Там, где собственно происходит обмен трафиком? Обычно там ставят большие свитчи, к ним подключаются участники пиринга, через RR или напрямую обмениваются маршрутами. А где именно вы хотите воткнуть там MPLS, если простого L2 достаточно?
                  почему просто не дотянут его до конечного пользователя?

                  В каком виде? В виде LDP? BGP? RSVP? До сотен тысяч клиентов? А главное — с какой целью? Source routing как предлагает яндекс в случае гипервизорных свитчей? Но это не нужно конечному пользователю, оператору лучше знать, как пустить трафик клиента.

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

                  Я не знаю ни одной относительно крупной компании (не оператора), где хоть на каком-то участке не использовался бы MPLS в виде VPN, вариант — VPLS/EoMPLS, где-то даже TE. С другой стороны, известные мне крупные компании обычно небедные, у них есть и мозги, и весьма дорогие железки.
                  • 0
                    А главное — с какой целью?

                    Иметь единый контрол-плейн. Не ради ли этого весь SDN затевается? А то получает тут одно, а тут другое. Вот инженеры знают L2, а вот инженеры MPLS. Упрощение и универсальность — разве не к этому все стремятся?

                    А где именно вы хотите воткнуть там MPLS, если простого L2
                    достаточно?

                    Мммм, тут наверно да, перегнул.

                    хоть на каком-то участке не использовался бы MPLS

                    Вот тут опять же, почему только местами? Почему не покрывается MPLSсом большая часть сети?

                    Получается MPLS так всем хорош, но не везде применяется. Странно как-то.
                    • 0
                      Иметь единый контрол-плейн.

                      1) Эта идея воистину ужасна. Вы хотите, чтобы вся инфраструктура зависела от здоровья этого единого контрол-плейна? Ну что же, относительно недавно Cisco анонсировали фексы для cat6500 (Instant Access). Это когда есть центральная VSS пара 6500 (см. «стек»), есть множество фексов (выглядят как свитчи, но это только так кажется, на самом деле это совершенно безмозглые линейные карты, подключаемые оптикой к центральным 6500-м свитчам и управляемые оттуда же как родные порты). Итого: если у вас есть кампус на несколько зданий и тысячи портов по десяткам кроссовых, то вы можете обойтись в прямом смысле одним control plane. Зайдете на management адрес центрального свитча и увидите все до единого порты. Весь трафик даже между соседними портами фекса всегда проходит через центральные свитчи. Итак: при наличии бюджета вы бы стали внедрять такую архитектуру? Лично я — нет. Тогда я бы начал бояться даже дышать в сторону этого дела, не то что трогать его. Малейший чих — и ложится ВСЁ. И я даже вживую видел на одной презентации, как ложилось, да так, что консоль не помогала, надо было по питанию центральные свитчи дернуть.
                      2) MPLS не обязательно подразумевает централизацию :)
                      3) Те фичи MPLS, которые можно централизовать… Вы всерьез предлагаете оператору связи в режиме реального времени управлять сетевым стеком пользовательского компьютера?
                      Почему не покрывается MPLSсом большая часть сети?

                      В моей сети покрывается (кроме кампусной, где он опять же не нужен). Во многих других тоже. А у кого-то (Амазон например) вообще архитектура приложений такова, что ничего кроме простого L3 транспорта не требуется.
                      Получается MPLS так всем хорош, но не везде применяется. Странно как-то.

                      Офигенный аргумент.
                      Есть некоторая технология, которая прекрасно решает определенный список задач. Есть области, где этих задач не возникает, потому технология там просто не нужна, либо. На основании того, что задача не везде возникает, вы начинаете упрекать решение? Мне это даже как-то нечем крыть.
                      • 0
                        Ну что же, относительно недавно Cisco анонсировали фексы для cat6500 (Instant Access). Это когда есть центральная VSS пара 6500 (см. «стек»), есть множество фексов (выглядят как свитчи, но это только так кажется, на самом деле это совершенно безмозглые линейные карты, подключаемые оптикой к центральным 6500-м свитчам и управляемые оттуда же как родные порты).


                        Это имеет смысл при экономии денег. Точнее, такая схема используется операторами сотовой связи вместе с asr 9000. В результате за относительно низкую стоимость можно иметь огромное количество L3 портов на одном ASR.
                        • 0
                          Я бы понял, если бы фекс стоил как 2960, на базе которого он и сделан. Но он стоит примерно как полноценная линейная карта чуть ли не с DFC. Маркетинг…

                          Операторы связи, кстати, часто не заботятся о резервировании, полагаясь на то, что огромная железка никогда не умрет, линейная карта на ней никогда не отвалится и т.д. Сколько уже было случаев, когда связь с крупным провайдером пропадает на срок от 5 минут до нескольких часов из-за «сбоя маршрутизатора». Что самое огорчающее — разом на нескольких площадках, так как оказывается, что все каналы собраны на одном узле. Но такой подход имеет смысл — обычно клиент не требует компенсации за сбой, а если в договоре она прописана, то она соответствует доле абонентской платы. Итого: подход «сломается — починим» оказывается выгоднее подхода «зарезервируем, чтобы клиент не заметил поломки».
                          • 0
                            Попробуйте уговорить начальство на то, чтобы раздуть бюджет закупки магистрального оборудования потому что «если ляжет магистральное оборудование, у Вас будут недоступен сегмент до суток.» У меня не получилось, максимум что было — резервный маршутизатор на складе и/или смартнет. А так да, надежность низкая. Честно говоря вот для фексов 6500 я не вижу ниши на рынке. Лучше бы Tactical вернули бы.
                            • 0
                              Честно говоря вот для фексов 6500 я не вижу ниши на рынке.

                              Не, на слайдах это выглядит красиво, не поспоришь. Единая точка администрирования, плюс весь функционал cat6500 на любом из портов фексов, хоть даже xconnect пробросить прямо от пользовательского порта. Но зная, как работает VSS (и вообще — любая новая технология у циски), становится страшно.
                              • 0
                                Так-то да, и еще может быть офигенная плотность портов (в обмен на скорость), плюс возможность поместить фексы по всему кампусу ровным слоем. Еще если не подводит память, для феков пара свичей с парой супов в каждом — рекомендуемая конфигурация, заработает и на одном свиче.

                                Но честно в боевую схему запихнуть их не рискну, нет уверенности в стабильности джиттера а главное — работе при высокой нагрузке (80% нагрузки — и начинают валиться рандомные интерфейсы и то сами фексы — привет длинку!).
                                • 0
                                  для феков пара свичей с парой супов в каждом — рекомендуемая конфигурация,

                                  Режим VSS обязателен.
                                  Наличие двух шасси категорически рекомендовано, но технически не требуется.
                                  Наличие четырех супов, из которых три — hot standby, ни разу не гарантирует, что весь кластер не встанет колом из-за какого-нибудь глюка.
                                  нет уверенности в стабильности джиттера

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

                                  Да и видели ли вы когда-нибудь хотя бы 10% утилизацию 10G аплинка в кампусе? Я — нет, даже если это аплинк свитча с сотнями портов, а не то что маленький фекс или стек из фексов.
                                  • 0
                                    Те кто задумывается о покупке фексов 10G обычно не используют.
                                  • 0
                                    Режим VSS обязателен.

                                    VSS не обязателен! Но сильно желателен.

                                    • 0
                                      Из всей документации и из личного общения с Hodgdon'ом я вынес, что режим VSS обязателен, так как задействуется определенная его программная инфраструктура для добавления фексов (т.е. надо сделать switch convert mode virtual, без этого никуда). Вот наличие двух шасси уже не требуется, но желательно.
                                      • 0
                                        Да, так будет наиболее точно. Но с одним шасси отсутсвует VSL. Поэтому по большому счету все работает так же как и в standalone.
                            • 0
                              Tactical вернули, кстати.
                              www.aviziatech.com/product_tactical.html
                              Уже можно попробовать заказать.
                                • 0
                                  Ну я не имел в виду, что вернули старый. Сейчас уже доступна новая модель Tactical на основе SX20.
                                  • 0
                                    Это строго говоря не tactical. Cisco свернула эту линейку и я не слышал о ее возобновлении. Avizia tactical — это разработка сторонней фирмы. Но вообще можно уточнить у ystas, он точно располагает всей информацией)
                                    • 0
                                      Avizia отпочковалась от Циски год-два назад как раз для продолжения разработки линеек tactical/clinical assistant, и сейчас продвигается в сотрудничестве с Циской. Так что не совсем сторонняя фирма все же.
                                      • 0
                                        Это так, но формально это другая фирма, с которой требуется устанавливать свои партнерские отношения и та далее. Ну и насколько знаю в России дистрибьютором avizia является только OCS, а дистрибьюторов cisco куда больше.
                                        • 0
                                          Насколько я знаю, для покупки этих штук никаких партнерских отношений не требуется.
                                          • 0
                                            Для покупки — нет, а для скидок — да.
                    • 0
                      Во, вспомнил.

                      Electricity over IP.
                      This document is motivated by such work as SONET/SDH over IP/MPLS

                      Шедевр, как раз на тему «почему бы нам не впихнуть MPLS везде где только можно?». Наглядно показывает, что в принципе KISS есть своя прелесть, и не надо усложнять на ровном месте.
                • 0
                  Или вот еще, почему в IX не используют MPLS?

                  Причина та же самая почему Inter-AS VPN крайне редко бывает Option B/C.
                • 0
                  Или вот еще, почему в IX не используют MPLS?


                  Дейтвительно, ну почему же?

                  Я просто оставлю это здесь:
                  ams-ix.net/technical/ams-ix-infrastructure/the-ams-ix-mplsvpls-infrastructure
                  www.linx.net/publicity/2011releases/pr2011-01.html
                  • 0
                    Я так понял, что имелось ввиду MPLS между всеми операторами на IX Понятно что в инфраструктуре может быть все что угодно.
  • +1
    Эксперименты Яндекс делает, это верно. Возможно, мы что-нибудь расскажем о них в будущем.

    Продукты конкретных вендоров я не очень хочу комментировать по понятным причинам. С Cumulus мы дружим не только на YaC, но вне него. В скором времени с кумулюсовскими людьми мы выкатим пару драфтов в ietf.

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

    А что до упоминаний в блогосфере, то это не самый надежный индикатор — в самом деле, блогосфера переполнена опенфлоем и vxlan'ом, и, если смотреть только на блоги, можно подумать, что ничего другого не только нет, но и быть не может.
    • 0
      А как можно будет узнать о выпуске драфтов. Интересно почитать.

      Блоосфера может быть и не надежный, но все таки, какой-то показатель. С MPLS мне было бы все таки интересно подетальнее узнать реальные внедрения в сетях уровня ДЦ, а таких материалов не встречал. Да и вы говорите, что пока только в лабе.
  • 0
    Спасибо за пост, очень понравилось!

    З.Ы. на моменте когда упомянули NP 4 от EZchip и все засмеялись я почувствовал себя дураком ибо первый раз о нем слышу :)
  • 0
    Интереса ради — не планируете скрещивать OF c netchannel (в имплементации Якобсона)?
  • 0
    Очень хорошее меропритие было, правда больше полугода прошло…

    1) Дискуссию не добавите? Да, было несколько неконструктивно, но местами забавно.
    2) Тема будет еще публично развиваться?
    • +1
      Я не думаю, что есть смысл пихать в пост, но вот на всякий случай ссылка на видео: tech.yandex.ru/events/science-seminars/SDN-21nov/talks/1428/

      Вообще, планируется. Даже как-то раз уже почти собрались сделать еще один семинар. Но тупо времени не хватило — эту фигню надо еще и допиливать, а не только про нее рассказывать. :) Теперь, может в августе уже (или в сентябре даже), после июльского IETF.
      • 0
        Спасибо, теперь стало понятно что такое NP 4 :)
      • 0
        Наверное, тяжело было аккуратно выбирать слова, общаясь с теоретиком, витающем в облаках? :)
  • 0
    У меня вопрос к Даниилу, но возможно другие хабрапользователи тоже смогут ответить.

    Насколько я понял из вашего выступления вы знакомы с тем как SDN реализован в google, они на одной из презентаций www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf страница 8-17 показали что SDN/централизованное управление улучшает востановление сети после сбоя, но это как-то не согласовывается с идеей MPLS FRR где возможность принятия решения локально и есть главным приемуществом в плане скорости.

    Прокоментируйте пожалуйста, может я что-то не так понял. Спасибо :)
    • 0
      Там идет сравнение с чем-то похожим на TE без FRR. Да и есть у FRR одна нерешаемая проблемка: на период, пока новый LSP не был по-человечески просигнализирован, наверняка будет выбран неоптимальный путь. Гугл хвастался, что утилизация линков у них в среднем 90% — соответственно, если упадет один линк, то будет плохой идеей переводить весь трафик с него на один другой линк, в этом случае плохо станет уже двум линкам…

      Конечно же ничто не может побить в скорости переключения на резерв схему, когда резервный путь заранее программируется в FIB роутера перед аварийным линком. Другой вопрос, что гуглу может хватить, скажем, 200-300мс времени восстановления (роутер сообщает контроллеру, тот размышляет над резервным путем, шлет информацию отправителям, кому-то перепосылает, те программируют путь себе) вместо 50мс. Я вот никогда не понимал, зачем стремиться к 50мс.
      • 0
        Я вот никогда не понимал, зачем стремиться к 50мс

        Для IPTV? Чтобы картинка не разваливалась слишком.
        • 0
          Ну если у вас линк каждую минуту падает… Иначе, если такое происходит раз в неделю/месяц/год, да и пусть эта картинка развалится в течение нескольких кадров, ничего страшного.

          Там, где надо, чтобы ни один пакет мультикастового потока не потерялся, делают live-live. Это когда два одинаковых потока идут разными трассами, оба приходят клиенту, и тот отбрасывает дубль. Если потерялся пакет одного потока — ничего страшного, есть другой.
          • 0
            Видимо 50мс появились из известных технологий резервирования TDM каналов. Просто старались сделать не хуже.
            • 0
              Само собой. Но с решениями, добивающимися тех 50мс, обычно больше геморроя, чем выгоды (есть даже любители делать TE именно ради этого, и я им сочувствую). Хотя не всегда. Допустим, per-prefix LFA приятен — в теории, у него нет недостатков, задействуется он одной командой и работает самостоятельно. Только вот уж больно он чувствителен к топологии, т.е. недостаток все-таки есть — «не всегда применим».
              • 0
                Мне приходилось TE делать на оборудовании, которое не может заглянуть в IP заголовки внутри EoMPLS, чтобы сделать hash на основе src-dst ip и распределить трафик между равнозначными линками. А раз TE появился, несмотря на то, что был ненужен — с ним появились и прочие его прелести, чтобы зря не пропадал.
                • 0
                  Ну так основное назначение TE — source routing с относительно человеческим лицом, это было еще как нужно. Есть, условно, X сетевых потоков с ограничением сверху по пропускной способности. Есть Y (Y<X) каналов связи, расположенных совершенно хаотично и потому без возможности сделать ECMP по ним (по-научному — partial mesh), и неплохо бы равномерно загрузить их трафиком, так как канал — дорогостоящий ресурс, и при этом желательно никого не зажать. TE очень даже прилично решает эту задачу — без централизации control plane, с возможностью централизации management plane, ну и да, с колоссальным management overhead, за что его и не любят. А дальше уже накрутили path protection и прочее.
                  • 0
                    ну и да, с колоссальным management overhead

                    О да, трудно не согласится.
                    На этому тему тоже есть специальное ПО, которое этот головняк практически снимает. Но, к несчастью, с очень внушительной ценой.
  • 0
    Тема с SDN похоже больше волнует облачных операторов. В традиционных операторах связи мысль о централизации CP на мой взгляд вызывает «тихий ужас». Чем больше оператор связи, тем сильнее в нем идея — «не складывать все яйца в одну корзину». Если централизованный CP в какой то момент поведет себя неправильно — потеряем всю сеть.
    Другое дело централизованная конфигурация услуг, с высоким уровнем абстракции. Это действительно привлекательная идея. Есть и соответствующее ПО для этого, например Tail-F NCS.
  • 0
    Даня, большое спасибо за статью!
    Обязательно пиши еще, иначе все зарастет этим опенгноем.
  • 0
    opencontrail.org/opencontrail-architecture-documentation/
    Пока самое полное и адекватное (продуманное, аргументированное) описане SDN из тех, что я видел. Конечно, там больше упор на управление виртуальными сетями, но концепции вполне зрелые.
  • 0
    Статья не особо описывает принцип работы SDN и дает понятие о этой технологии в целом. Ну есть один коммутатор в каком-нибудь Ростелекоме и Транстелекоме у которых сеть на столько большая, что можно сутки заходить на все железки без перерыва.Как тогда планируется таким количеством железа управлять с одного устройства? Небольшая тишина.
    Хорошо отделение data и форвардинга, схема нарисованная вами напоминает схему устройства джуниперовских роутеров. У них отделен фовардин от дата плейна хотя иногда дата плейн и учавствует в некоторых важных процессах
    Идем дальше упростить lookup, чтобы посмотреть метку и дальше пульнуть у нас есть mpls для этого.Как можно это усовершенствовать? Для свичей и в целом для уровня доступа есть технология q-and-q. Ничего нового я снова не вижу в идеи sdn.только красивое слово sdn и openflow.
    Что же такое openflow это софт который можно бесплатно ставить на железки он не предназначен для конкретного вендора, он бесплатный и синтаксис на любом оборудовании одинаков и получается из этого польза сетевику который может не заучивать команды разных вендоров? Возможно будут проще некоторые моменты такие как настройка вланов по протоколу vty, только циска поддерживает, а тут бах и такой протокол поддерживают все свичи в сети. Тогда я разом настроил свои 1 тысячу и один свитч и все радость.

    В целом складывается такое ощущение эти слова sdn,openflow используются вендорами для того, чтобы все решили пора менять сеть. У меня все не верно и много миллиардные контракты на покупки нового оборудования.
    А простыми сетевиками используются SDN и Openflow как некое а страктное которое должно наконец упростить эту сложную работу сетевым специалистом. Главное, чтобы зарплату сетевика не решили упростить с покупкой нового оборудования для построения сети Sdbn, вроде как sdn должно упростить технологии может и бюджет кампании сэкономит?

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

    P S много сетевиков работает в яндексе и какого вендора у вас используется оборудование?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное