Сетевые технологии SDN – Software Defined Networking

    В современном мире, бизнес в сфере информационных технологий предъявляет все большие требования к гибкости и масштабируемости компьютерных сетей. Так, старожилу IT рынка компании AOL для привлечения одного миллиона клиентов понадобилось 9 лет, Facebook понадобилось 9 месяцев, а онлайн сервису DrawSomething понадобилось всего 9 дней.

    При всем этом, можно наблюдать, что основными трендами развития корпоративных сетей и сетей центров обработки данных являются:
    • стремительный рост объемов трафика и изменение его структуры в сторону передачи видео и унифицированных коммуникаций (UC-C);
    • необходимость поддержки мобильных пользователей (BYOD) и социальных сетей;
    • высокопроизводительные кластеры для обработки Больших Данных (BIG DATA);
    • виртуализация для предоставления облачных сервисов (Cloud Bursting).

    При этом сеть в классическом ее виде (управление через командную строку и конфигурационные файлы) становиться ограничивающим фактором развития вычислительной инфраструктуры. Классические подходы к решению проблем, к примеру, на основе виртуализации сетей (VLAN, VRF), не соответствует уровню развития виртуализации серверов и систем хранения данных. Традиционные сети прежде всего статичны и не соответствуют быстрой динамике развития современного IT бизнеса. Возможности масштабирования традиционных сетей не соответствуют требованиям крупного бизнеса и сервис провайдеров (Deutsche Telekom, Facebook, Google, Microsoft, Verizon и Yahoo), а распределенное управление устройствами традиционных сетей слишком сложное и не эффективное. Привязка же к выбранному сетевому производителю не гарантирует поддержку будущих приложений и сервисов, так, по слухам, очередной апгрейд сетевого оборудования компании Amazon имел ценник с девятью нулями. Как результат наблюдается картина, что традиционные архитектуры/дизайны сетей становятся неэффективны в динамических средах.

    Необходима новая технология или подход к построению информационных сетей позволяющая решить перечисленные выше проблемы. Такая технология есть и носит название — Software Defined Networking или сокращенно SDN.

    Что такое SDN?


    По определению от Wikipedia:
    Программно-конфигурируемая сеть (SDN от англ. Software-defined Networking, также программно-определяемая сеть) — сеть передачи данных, в которой уровень управления сетью отделён от устройств передачи данных и реализуется программно, одна из форм виртуализации вычислительных ресурсов.

    Давайте расшифруем это определение. Если рассмотреть современное сетевое устройство (роутер или коммутатор, не принципиально), то оно, как пирог, логически состоит из трех компонентов.
    1. Уровень управления – это CLI, встроенный веб-сервер или API и протоколы управления. Задача этого уровня обеспечить управляемость устройством.
    2. Уровень управления трафиком – это различные алгоритмы и функционал задачей которого является автоматическая реакция на изменения трафика т. е. интеллект устройства.
    3. Передача трафика – функционал обеспечивающий физическую передачу данных, уровень микросхем и сетевых пакетов.


    Рисунок 1 Типичное сетевое устройство

    Что если:
    • централизовать управление трафиком, отделив управление от устройств?
    • централизовать управление устройствами?

    В результате «новый» роутер или коммутатор обслуживает только поток данных (уровень передачи трафика DATAPLANE), становиться более простым соответственно более дешевым. Конечно же лишить полностью интеллекта сетевое устройство не получиться, но его достаточно заменить простой таблицей переадресации (forwarding table).

    Весь интеллект (MANAGEMENT PLANE и CONTROL PLANE) переносится в отдельное центральное устройство называемое контроллером SDN.


    Рисунок 2 Логическая модель сетевых устройств SDN

    Итак, мы получаем:
    • Разделение функций передачи трафика от функций управления (включая контроль как самого трафика, так и осуществляющих его передачу устройств)
    • Единый, стандартный, открытый интерфейс между устройствами управления и передачи (получивший название OpenFlow)

    • Централизованное управление сетью (Контроллер SDN)
    • Виртуализация физических ресурсов сети
    • Возможности программирования как оборудования (OpenFlow), так и приложений (API — Контроллер SDN)
    • Быстрее реагировать на изменения в сети
    • Оптимизировать передачу трафика (L2/3) через большее количество резервных путей
    • Легче и быстрее настраивать сети
    • Существенно сократить время развертывания приложений
    • Упростить управление сетевыми устройствами
    • Сократить затраты на управление сетями
    • Централизованное применение политик, увеличение производительности, уменьшение задержек приводит к более эффективному взаимодействию пользователей и приложений как в корпоративных сетях, так и в сетях датацентров
    • Простота управления. Управление целыми сетями, а не сетевыми устройствами
    • Открытые, основанные на стандартах протоколы позволят взаимодействовать различным производителям сетевого оборудования между собой, одновременно увеличивая выбор заказчику и конкуренцию между вендорами при снижении затрат, ускоряя инновации как в области программного обеспечения, так и аппаратных средств.
    • Контроллер SDN поддерживает открытый интерфейс программирования (API), который позволяет программировать его извне, создавая среду для автоматизации и контроля, а также масштабировать функционал для будущих приложений.
    • Приложение может запрашивать напрямую определенные требования к сети
    • Видимость всего трафика сети контроллером


    Рисунок 3 Общая архитектура SDN

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

    Каждое SDN приложение, по сути, являет собой интерфейс оптимизации сети под конкретное бизнес приложение (к примеру Microsoft Lynk) и его основная роль — изменение сети в реальном времени под текщие нужды обслуживаемой программы. В случае Microsoft Lynk это может быть, к примеру, изменение QoS сети между двумя телефонными абонентами для предачи HD видеозвонка в реальном времени без задержек или создание VPN тоннеля между двумя абонентами.


    Рисунок 4 SDN приложение для MS Lynk

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


    Рисунок 5 Структура и компоненты SDN

    Первый поток получил название «северный мост», а второй «южный мост». В качестве «северного моста» выступает протокол на основе RESТ API, а в качестве «южного моста» прижился протокол OpenFlow.


    Рисунок 6 Управляющие информационные потоки контроллера SDN

    Что же такое OpenFlow?



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

    Соответственно коммутатор OpenFlow состоит, как минимум, из двух компонент:
    • таблицы потоков (flow table);
    • безопасного канала (secure channel)


    Рисунок 7 Пример таблицы потоков OpenFlow

    Коммутаторы с поддержкой OpenFlow уже доступны на рынке, так в портфолио лидера в разработки концепции SDN – компании Hewlett-Packard, уже более 40 моделей коммутаторов поддерживают OpenFlow версии 1.3, соответственно готовы выступать «кирпичиками» построения реальной сети SDN.

    Кроме коммутаторов Hewlett-Packard предлагает несколько моделей готовых контроллеров SDN и бесплатно предоставляет несколько готовых приложений SDN для конкретных бизнес программ, к примеру, Microsoft Lync. Компания HP также поддерживает активное сообщество разработчиков SDN (sdndevcenter.hp.com), где пользователи могут делиться своими идеями, а также онлайн-магазин приложений SDN App Store, откуда пользователи могут скачивать различные приложения на контроллер HP VAN SDN всего в несколько кликов.

    Такой интерес Hewlett-Packard к технологии SDN не случаен. Считается, что SDN изменит сети так же, как это сделала в свое время виртуализация на рынке корпоративных серверных систем. Соответственно SDN для компании Hewlett-Packard это стратегическое направление, ведь успех в этом направлении может предоставить лидерство на рынке, пример тому, успех таких крупных игроков на рынке сетевых сервисов как Amazon и Google активно использующих SDN в своей работе.

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



    Киев, 23-24 марта состоится курс НР — Cloud Computing Foundation (EXIN)
    Дистрибуция решений HP в Украине, Грузии и Таджикистане
    Каталог всех решений и сервисов дистрибьютора МУК

    МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание
    • +12
    • 55.8k
    • 8
    МУК
    64.75
    Company
    Share post

    Comments 8

      0
      ну, SDN не ограничивается только управлением свитчами/роутерами с помощью внешней софтины.
      Есть еще сеть внутри платформ виртуализации — Neutron, OpenSwitch, Cisco CRS1Kv, Cisco Nexus 1Kv — вот это все. И вот эта часть сейчас гораздо более востребована чем толком никому не нужный openFlow. И как я понимаю, HP в этом как раз не то чтобы не силен, а вообще полный 0.
        –1
        Я вот не пойму, объясните мне, кто понимает… зачем свичем управлять?
        Как мне кажется каждый свитч во время приема ethernet пакета тут же из заголовка пакета сразу знает destination MAC. И свитч знает к какому порту какое устройство у него подключено и какие у них MAC. Сразу из заголовка пакета понятно на какой порт отправлять пакет дальше.
        Я не понимаю чего тут можно поуправлять?
          –1
          VLAN и QoS придумали глупые люди?
            0
            спасибо за ответ, из него мне сразу все стало понятно!
              0
              Сорри. По факту — современные свитчи представляют массу возможностей. Это та же организация VLAN-ов (можно сделать набор виртуальных локалок, например, на нескольких портах разных свитчей, соединённых одним шнурком, так, чтобы трафика из одной локалки не было видно в другой), QoS (управление приоритетами пропуска трафика), транкинг портов (когда между двумя свитчами протянуты несколько кабелей, можно их включить в разные порты этих свитчей и обеспечить более скоростное соединение, чем по одному шнурку), привязка MAC-адресов к портам, включение/отключение PoE (питание через Ethernet) на портах и многое другое. Естественно, эти возможности требуют настройки, которую при большом количестве оных трудновато обеспечить джамперами, переключателями (так, например, можно было настраивать VLAN-ы на некоторых старых свитчах CNet) или иными способами непосредственно на свитчах. Да и мониторить состояние свитча нередко полезно. Для всего этого и придумали управление.
            –1
            Можно посмотреть вот эту публикацию
            habrahabr.ru/post/252127/
            а потом оценить, что ВСЕ про что там рассказывается о ISIS, OSPF и т.д. можно заменить умным SDN контроллером, управляющим пустыми (с точки зрения конфигов) свичами
              0
              А потом контроллер умрет и кто-то пойдет искать новую работу. Шутка :)
            0
            Для управления коммутаторами вендоры уже давно предлагают свои централизованные управлялки (Cisco Works/Prime, HP IMC), SDN эти задачи не решает. SDN стал развиваться во многом из-за логичного стремления упростить сеть, использовать дешевое и эффективное сетевое оборудование, при этом вынести логику на уровень централизованных контроллеров. Это похоже на серверную виртуализацию (по крайней мере, выгоды похожие), но в итоге получилось что-то вроде автоматизированного управления серверами, если проводить параллели.
            Гораздо интереснее полноценная сетевая виртуализация на основе overlay-сетей.

            Only users with full accounts can post comments. Log in, please.