ETegro Technologies
Компания
25,11
рейтинг
14 февраля 2014 в 16:49

Разное → Software Defined Network (SDN) на основе открытой платформы Intel ONS

В данной статье мы хотим напомнить о такой концепции, как SDN и рассказать, как сейчас выглядит ее реализация в виде платформы Intel ONS.

Сперва лайфхак для тех, кому лень читать много текста и смотреть картинки: в самом конце статьи приведены условия получения 10G коммутатора. «Без-воз-мез-дно, то есть даром», — как говорила Сова во всем известном мультфильме.

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



Преимущества такого подхода:
  • Прямое программирование сети: разделение уровней управления позволяет создавать архитектуру напрямую.
  • Гибкость: Администратор может изменять правила работы сети «на лету» для адаптации к изменившимся требованиям.
  • Централизация управления: Все управление сетью сосредоточено (логически) в одном месте, в контроллере SDN. Для приложений сеть выглядит единым логическим коммутатором.
  • Программное конфигурирование: SND позволяет конфигурировать, управлять, задавать правила безопасности, оптимизировать сетевые ресурсы в сжатые сроки с помощью автоматизированных средств, в том числе собственной разработки.


Концепт вызывает немало споров, но мы считаем направление перспективным.

В прошлом году Intel представила ряд решений для коммутаторов, на основе приобретенной
Fulcrum Microsystems, Intel Ethernet FM6000.

идея матрицы

Матрицы позиционируются как гибридные коммутаторы с возможностью простого перехода от традиционной коммутации к SDN. Главной особенностью считается возможность направлять потоки обработчику OpenFlow или обработчику традиционных пакетов. Обработчик в Intel FM6000 крайне гибок, он позволяет работать с любыми стандартами, даже если администратору захочется создать свой собственный протокол — не беда, это можно сделать. Основа такой гибкости — структура обработчика.

Структура TCAM/RAM/MUX в обработчике

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

эталонный дизайн


Модели в серии

Для работы с такими замечательными матрицами Intel представил решение от Wind River — Open Network Software.

Структура ONS

Особенности:
  • Модульная, открытая и расширяемая архитектура с доступам к низкоуровневым функциям.
  • Системные интерфейсы с открытым API и вызовами RPC.
  • Программный интерфейс управления на основе XML-RPC.
  • Объектно-ориентированный дизайн с использованием XML и схем баз данных.
  • Application Development Kit для встраивания новых приложений на коммутатор.
  • Встроенная поддержка ряда протоколов и расширение через модули.

Поддерживаются основные протоколы L2 и L3, функционал для ЦОД.

Layer 2:
  • Port-based VLAN
  • 802.1Q VLAN
  • IGMP snooping
  • LACP
  • Storm Control
  • STP/RSTP/MSTP
  • Q-in-Q
  • QoS/DiffServ
  • L2/L3/L4 ACL
  • LLDP (802.1ab)

Layer 3:
  • Static route
  • VLAN routing
  • OSPF v2
  • ECMP
  • ARP
  • IGMP*
  • PIM-SM*
  • VRRP*
  • OSPF v3*
  • PIM-SM6*
  • DHCPv6 relay
  • BGP

Управление:
  • CLI/WEB/SNMP
  • IPv6 management
  • Auto-Installation

Data Center Application:
  • 802.1Qaz (ETS)
  • 802.1Qbb (PFC)
  • DCBX
  • VM Tracer
  • EVB/802.1Qbg
  • OpenFlow v1.0
  • VXLAN
  • NVGRE*

Отмеченное "*" будет поддерживаться в следующих версиях.

Так выглядит идеальный коммутатор будущего (по мнению Intel):


Что будет, если взять старшую модель матрицы Intel FM6764 и сетевой стек ONS? Отличный коммутатор!


48 портов 10G SFP+, 4 порта 40G QSFP, USB порт, порты консоли и управления.


Два блока питания, вентиляция с горячей заменой.


Intel Core i3, 2GB оперативной памяти, 30 гигабайт SSD накопитель.

В нашей лаборатории коммутатор успешно запущен и работает.

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

Авторам самого интересного проекта, включая высоконагруженные решения на традиционной коммутации, один коммутатор будет подарен :)
Подведение итогов — 31 марта.
Автор: @ETegro_Technologies
ETegro Technologies
рейтинг 25,11
Компания прекратила активность на сайте

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

  • +1
    Сколько миллионов flow эта штука способна обработать в час?
    • 0
      Как контроллер — больше 100К flows/sec.

      Как коммутатор — практически wire-speed.
      • 0
        То есть если какой-то засранец сгенерирует, например, миллион flow в секунду,… ладно, 150к flow в секунду, что станет с контроллером?
        • 0
          Используйте внешний! :)
          Если у вас есть план, как положить коммутатор нагрузкой — поделитесь, реализуем на практике и поделимся результатом с общественностью.
          • 0
            Начните с hping3 --flood --rand-source -p ++1 -S some_host
            • 0
              Как верно заметили ниже — флуд будет обрезан контроллером.

              Я просил несколько другое — план решения, с нагрузкой от которого коммутатор не справится.
              48 серверов, которые делают что-то полезное для общественности.
              • 0
                входящий флуд будет обрезание контроллером? При том, что контроллер 100к флоу, а хпинг делает больше 300? Если -p ++1 кажется заманчивым, замените на -p 80.
                • 0
                  Все таки мы о разных вещах сейчас говорим.
                  Размещать контроллер SDN на коммутаторе можно, но не очень нужно, в нем стоит двухъядерный процессор.
                  Для того Control Plane и отвязывали от железки.

                  На коммутатор лучше разместить фаерволл, IPS и прочие задачи такого рода.
                  • 0
                    я говорю про контроллер на несколько коммутаторов внутри периметра. Если его надо прикрывать файволами/ids, то получившееся может и выживет, но надо ли такое?
                    • 0
                      Вы рассматриваете сценарий, когда контроллер отслеживает каждый flow?
                      Зачем?
                      Такой вариант не масштабируется, будет медленным, да и пользы от отслеживания каждого flow не видно.
                      Составьте таблицу маршрутизации, дальше коммутатор съест любой поток.
                      • 0
                        Нет, я хочу, чтобы вы мне попытались описать такую конструкцию (условного интернет-сайта) с использованием SDN, в котором бы не было сценария, при котором школьник может с помощью hping/ab заставить каждый новый запрос обрабатываться как новая flow с отправкой на инспекцию. В принципе, я понимаю что ab — это уже другой уровень. Так что давайте начнём с hping'а. Как будет выглядеть инсталляция SDN, которая будет обрабатывать трафик из интернета с участием контроллера (то есть не «у нас всюду маршрутизация/коммутация, а контроллер для красоты»), и при этом сможет избежать проблемы с инспекцией каждого specially-crafted пакета?

                        У меня, конечно, есть нехорошая интонация «да фигня это всё», но разобраться я хочу серьёзно, потому что flow-flood сейчас моё самое главное и основное возражение против SDN IRL.
                        • 0
                          Сферический школьник в вакууме отправляет запросы на фронт-енд сайта, его не волнует то, как его запрос обрабатывается дальше. Внутреннюю сеть школьник не видит.

                          Под таблицей маршрутизации я как раз понимал таблицу flows в коммутаторах, а контроллер для изначальной задачи таблицы/обновления по мере необходимости (появления новых destination).
                          Удобство от централизации остается, проблемы масштабирования и флуда снимаются.

                          Зачем каждый пакет инспектировать контроллером?
                          Вот тут примерно такое же мнение описано.
                          • +1
                            Перед тем, как будем разбирать пример, вы хотите сказать, что SDN не подходит для периметра сети, то бишь фронт-энда? (который принимает нефильтрованный трафик из интернетов)

                            Я, собственно, эту мысль и пытаюсь всё время донести: SDN — уютная игрушка для уютных задних сетей, а к реальной нагрузке оно не готово.

                            Проблема «flows в коммутаторе» сводится к тому, что мы либо из всех flow оставляем только dst_ip, который потом уже разбираем глубже внутри, либо мы должны мириться с невероятного размера флудом на контроллер.

                            Если мы весь SDN сводим к «dst-based policy», то это и есть обычная маршрутизация (с минусами внешнего контроллера), если пытаемся сделать что-то более умное — огребаем амплифицирующий само-DoS.
        • 0
          Возможно не совсем правильно понял, что подразумевается под flow в данном вопросе. Но, что касается самой идеологии SDN, то всё зависит от реализации контроллера сети. Если вопрос стоит в том, чтобы обязательно обработать всё, что приходит, то заткнуть можно всё что угодно. Если же говорить об устойчивости, то в SDN заложены богатые возможности по обнаружению «засранцев» и минимизации ущерба для нормальных пользователей. Вплоть до блокировки адресов и даже физических портов и перераспределения трафика между оставшимися. То есть при правильном контроллере почти все 150k (или даже 1000k) от «засранца» будут отброшены, а с контроллером ничго не случится.
          • 0
            каким образом это поможет при внешнем флуде?
            • 0
              В упрощённом виде: все коммутаторы запускаются с одним правилом — все неизвестные пакеты (или их заголовки) отправлять контроллеру. Получив их, он добавляет необходимые правила для обработки, в идеале со временем действия. Кроме того, предусмотрены счётчики для измерения потоков (по портам, по правилам и т.п.) и оповещение контроллера о превышениях заданных порогов. При правильном наборе правил, простите за тафтологию, источник флуда будет временно отключён, с необходимыми корректировками остальных маршрутов, и не повредит сети в целом. Но отдельные порты или диапазоны адресов конечно можно блокировать такими атаками.
              • +1
                /facepalm.

                Какой источник флуда? Интернет?

                Если не поняли, повторяю: школьник на vds'ке запускает hping --flood --rand-source с целью на один из серверов внутри SDN. Кого куда что будет банить?
                • 0
                  Если у вашей сети один порт для интернета и если у школьника проплаченный канал шире, чем у вашей сети, то да, будет временно забанен интернет. Хотя может быть отключён и только доступ извне к атакуемому серверу, с сохранением его для остальных машин сети. Всё зависит от баланса фантазии автора программы контроллера сети и вашего «школьника».
                  • 0
                    Не-не, ну что вы передергиваете. Допустим, у школьника 50 мегабит. Входящий канал в сеть с контроллером — 10 гигабит.

                    И, допустим, школьник достаточно умный, чтобы не только --rand-source сделать, но и долбануть не по одному IP, а по всем адресам АС.

                    Я и хочу понять, как в этих условиях sdn жить будет, когда 300к flow ежесекундно новых.

                    Это моя претензия к технологии sdn.
                    • 0
                      Странный получается диалог… Ну, например, контроллер может сортировать записи по степени активности и при заполнении таблиц удалять самые «пассивные». То есть ваш флуд будет забивать сам себя. Если вы надеетесь забить управляющий канал и будете настаивать что можете, то это приведёт к задержкам при установлении новых соединений.

                      И при чём здесь sdn? Что остальные варианты построения сети устойчивы к такому виду атак?
                      • 0
                        Так давайте начнём с более простого: контроллер просто не сможет обслуживать 300к запросов на новые флоу, то есть простой школьник с 20-50Мбит/с каналом сможет положить сеть почти любого размера.

                        Я ж это всё пишу не просто так. Старые версии openvswitch страдали ровно той же проблемой — флуд клал контроллер (который vswitchd) на колени при 15 мегабитах флуда. Это при том, что ядерный модуль был способен 7-10 гигабит перемолоть. В новой поправили, но так vswitchd — не полноценный openflow-контроллер, а всего лишь прослойка между нормальным контроллером или ручными правилами.

                        Я утверждаю, что из простенького 10G маршрутизатора и коммутатора могу изготовить решение, которое на 50Мбит пакетного флуда даже глазом не поведёт. И даже фильтровать не будет, а прямо до сервера донесёт (который тоже проигнорирует флуд).

                        Другими словами, SDN решение получается много более уязвимое, чем существующие технологии, и проблема тут не в реализации (конкретного вендора или софта), а в принципиальной идее «централизации обработки всех flow с отправкой образцов на инспекцию».
  • 0
    >Мы приглашаем разработчиков сетевых приложений и компании, которые собираются тестировать/внедрять SDN решения для апробации >коммутатора в реальных задачах.
    Куда и когда приглашаете? А может мы вас пригласим обсудить наш проект?

    Мы сейчас на стадии разработки решения для наших ЦОД на базе OpenStack и у нас (taximaxim.ru) есть идеи, как использовать подобный продукт для своих нужд.
    • +1
      Написал личное сообщение.
      • 0
        Я так понимаю, мне со своим трёхслойным проектом опенсорс/опенхардварь умного дома (который гарантированно не «засрёт» полосу) даже соваться бессмысленно? :)
        • 0
          а зачем умному дому SDN?
          • 0
            сеть большая (точнее, в моём проекте — там три сети). Вряд ли, конечно, оно в пределах одного дома засрёт весь контроллер, даже если гонять видео/аудио от системы безопасности да ещё и мультирум через него же пустить, но «обычные домашние» решения тут уже не подойдут.
    • +1
      Ребят, я понимаю, что тут не совсем место, но не могли бы вы попросить там своих маркетологов не использовать SMS-спам для завлечения клиентов?
      А то у меня спам от вас пришёл спустя 10 часов после покупки новой сим-карты с новым номером. Я уже начал подозревать оператора в сговоре со спамерами :-/
      • 0
        а на #asterisk@rusnet стеснялся написать?
        у нас маркетологи на аутсорсе и они регулярно за это «получают»
        • 0
          Да что-то как-то не подумал, что ты там и тут — один и тот же человек :)

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

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