Rambler's Top100
Блоги Алексей ШАЛАГИНОВ

SDN: истоки создания и развития

  08 августа 2016 Страница персоны
Несмотря на то, что технология программно-конфигурируемых сетей SDN (Software Defined Network), кажется, возникала относительно недавно, на самом деле она имеет довольно длительную предысторию. SDN – только завершающая фаза длительного периода усилий, направленных на то, чтобы сделать сети программируемыми.

Компьютерные сети всегда отличались сложностью структуры и управления. На них используется множество различного оборудования: коммутаторы и маршрутизаторы, а также брандмауэры (которые продолжают называть файерволами – firewall), трансляторы сетевых адресов, балансировщики нагрузки, а также устройства и системы распознавания вторжений. Обычно сетевые администраторы настраивают (конфигурируют) каждое устройство по отдельности, соблюдая сетевую топологию и правила маршрутизации. Для этого используются интерфейсы конфигурации – свои для каждого устройства и для каждого производителя, а иногда и для каждого устройства внутри линейки одного производителя. Хотя также используется т.н. «пакетный» метод конфигурации сетевых устройств, в целом, такой подход сильно затрудняет модернизацию и развитие сетей, внедрение инноваций, а также приводит к большим капитальным и операционным расходам.

Программно-конфигурируемые сети SDN (Software Defined Network) меняют подход к проектированию и администрированию сетей. Во-первых, SDN отделяет плоскость управления сетью (Control plane), которая занимается маршрутизацией трафика, от плоскости передачи данных (Data plane), которая передаёт трафик согласно правилам, полученным от плоскости управления. Во-вторых, SDN «консолидирует» плоскость управления, при этом один комплекс управляющих программ на сервере управляет многими устройствами на плоскости данных. Для этого используется стандартизированный интерфейс прикладного программирования API (Application Programming Interface). Это, например, такой интерфейс, как OpenFlow. Соответственно, для того, чтобы построить сеть SDN, на сетевых элементах, прежде всего, коммутаторах и маршрутизаторах, должна быть реализована поддержка OpenFlow. При этом на каждом из них имеется таблица, или таблицы, правил маршрутизации. Каждое правило определяет, как маршрутизировать пакеты определенной сессии или потока трафика. При этом, в зависимости от правил, установленных управляющей прикладной программой, каждый коммутатор OpenFlow может работать как коммутатор, маршрутизатор, брандмауэр, транслятор сетевых адресов, и пр.

В настоящее время большинство коммерческих коммутаторов поддерживают SDN. Появилось множество управляющих платформ. На базе этих управляющих платформ появилось множество приложений, таких как динамическое управление доступом, балансировка серверной нагрузки, виртуализация сетевых функций, энергоэффективные сети, миграция виртуальных машин и другие. Многие крупные мировые ИТ-компании: облачные провайдеры, операторы, производители оборудования, и другие, присоединились к отраслевым консорциумам SDN, таким как ONF (Open Network Foundation) и Open Daylight.

Несмотря на то, что концепция SDN стала распространённой в последние годы, сама идея достаточно ненова, и эволюционирует уже более 20 лет. Ее следы можно проследить даже в развитии ранних телефонных сетей на базе коммутации каналов, когда управление сетью (сигнализация) было отделено от сети канальной коммутации речевого трафика. И это было сделано ровно с той же целью, что и в SDN – чтобы упростить управление и ввод новых услуг. Концепция т.н. «программных коммутаторов» Softswitch для телекоммуникационных стей на базе коммутации пакетов также очень близка к SDN по функциям и реализации.

Историю SDN можно разбить на три этапа:

  1. Т.н. «активные сети» (середина 90-х – начало 2000-х), когда в сети были введена функции программирования;
  2. Разделение плоскостей управления и передачи данных (примерно с 2001 по 2007 г.), когда были разработаны открытые интерфейсы между этими плоскостями;
  3. Разработка интерфейса API OpenFlow и сетевых операционных систем (с 2007 до примерно 2010 г.), когда, собственно, концепция SDN и получила широкое распространение.

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

Активные сети

В начале 90-х произошел стремительный взлет Интернета, и появилось много новых приложений, кроме передачи файлов и электронной почты, на которые был ориентирован ранний Интернет. Это разнообразие приложений вызвало разработку новых сетевых сервисов и новых протоколов передачи данных для них. Эти новые протоколы стандартизировались в организации под названием IETF (Internet Engineering Task Force). Процесс стандартизации был сложным и долгим, что часто вызывало откровенное раздражение разработчиков.

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

Традиционные компьютерные сети не были «программируемыми» ни в каком смысле. Для концепции «активных сетей» было введено понятие интерфейса прикладного программирования API (Application Programming Interface). Этот интерфейс предназначен для того, чтобы «показывать» ресурсы сетевых элементов (процессоры, память, очереди пакетов) на отдельных сетевых узлах для вышестоящего уровня управления, который бы через интерфейс API управлял этими ресурсами для выполнения определённых прикладных программ. Такой подход, однако, не вызвал большого энтузиазма в Интернет-сообществе, которое отстаивала «простоту» базовой сети, упирая на то, что это – основа успеха Интернет. Подход «активной сети» стал разрабатываться в таких организациях, как GENI (Global Environment for Network Innovations), а также NSF FIND (Future Internet Design) В США и EU FIRE (Future Internet Research and Experimentation Initiative) в Европе.

В этих инновационных организациях разрабатывались две основные модели программирования сетей:

  • «Капсульная» модель, где управляющие коды были «зашиты» в пакеты c данными (in-band);
  • Модель «программируемых коммутаторов и маршрутизаторов», где использовались отдельные пакеты, которые передавали команды управления (out-of-band).

Однако, такой подход часто был очень «вендорозависим» (многие производители разрабатывали собственные версии языков сетевого программирования), требовал отдельного управления для т.н. «мидлбоксов» — брандмауэров, прокси-серверов и прочего сетевого оборудования. Уже в это время были заложены идейные основы сегодняшней технологии виртуализации сетевых функций NFV (Network Functions Virtualization), которая реализует функции различных сетевых элементов на виртуальных машинах, работающих на стандартных серверах.

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

Кроме того, оказалось, что «активная сеть» недостаточно производительна и не обеспечивает требуемый уровень безопасности. Поэтому был создан отдельный проект Secure Active Network Environment Architecture.

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

Разделение плоскостей управления и передачи данных

В начале 2000-х растущие объемы сетевого трафика и требования к стабильности и производительности сети потребовали лучших подходов к управлению сетью, например, к управлению медиа-потоками, что получило название «инжиниринг трафика» ТЕ (Traffic Engineering). Однако, существующие сетевые протоколы были для этого плохо приспособлены. Причина снова была в том, что традиционные маршрутизаторы и коммутаторы не имели разделения плоскостей управления и передачи пакетов данных. Поэтому и были предприняты первые попытки эти плоскости разделить. Это привело к двум основным инновациям:

  • Разработка открытых интерфейсов между плоскостями управления и данных, таких как ForCES (Forwarding and Control Element Separation), стандартизированного IETF, или Netlink для Linux.
  • Разработка протокола управления маршрутизацией RCP (Routing Control Platform), а также архитектуры «программируемых маршрутизаторов» (Soft-Router) и PCE (Path Computation Element).

Эти инновации были продиктованы необходимостью управлять процессом маршрутизации на сети Интернет-провайдера (ISP). Они были ориентированы уже не на конечных пользователей, а на сетевых администраторов. Они предусматривали программируемость на плоскости управления, а не на плоскости данных, визуализируемость и управляемость топологии всей сети, а не конфигурацию отдельных сетевых устройств.

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

Однако, интерфейс ForCES не был принят большинством производителей, а в RCP использовался существующий протокол плоскости управления BGP для засылки таблиц маршрутизации в стандартные маршрутизаторы. Это существенно ограничивало управляемость в масштабе всей сети.

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

Кроме того, и основным производителям также не совсем нравилась идея API типа ForCES, поскольку открытые API давали возможность проникновения на рынок множеству небольших компаний-конкурентов.

Исследователи продолжали свою работу в направлении разделения плоскостей и начали разрабатывать так называемые «clean-slate» архитектуры, по аналогии с объектно-ориентированным программированием. В проекте 4D для большей степени абстрагирования было предложено четыре плоскости:

  • плоскость данных (data plane), для обработки пакетов на основе конфигурируемых правил;
  • плоскость обнаружения (discovery plane), для сбора информации о топологии и измерении трафика;
  • плоскость распространения (dissemination plane), для установки правил обработки пакетов на сетевых узлах;
  • плоскость решений (decision plane), состоящая из логически централизованных контроллеров, которые преобразуют цели сетевого уровня в состояния обработки пакетов.

Это были такие проекты, как например, SANE и последующий за ним Ethane. В Ethane маршрутизаторы занимаются только обработкой таблиц потоков трафика, которые раздаются с контроллеров на уровне решений. Этот проект был реализован в научном департаменте Стэнфордского университета и заложил основы для разработки протокола OpenFlow.

OpenFlow и сетевые ОС. В середине 2000-х группа исследователей Стэнфордского университета основала программу Clean Slate Program (программа «с чистого листа») и сосредоточилась на исследованиях исключительно кампусных сетей.

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

Коммутатор OpenFlow содержал таблицу правил маршрутизации, где каждое правило содержало образец (Pattern), который соответствовал определённым битам в заголовке пакета; список действий (Actions, например «отбросить» (drop), «создать рассылку» (flood), передать на определённый интерфейс, модифицировать заголовок пакета, или передать пакет на контроллер); набор счетчиков (counters), для подсчета байтов и пакетов; и приоритет (priority) для устранения возможных неоднозначностей между правилами и накладываемыми на них образцами. После получения очередного пакета, коммутатор OpenFlow идентифицировал правило соответствия с наивысшим приоритетом, выполнял предписанные действия и инкрементировал счетчики.

OpenFlow был первым, широко воспринятым в отрасли, протоколом по разделению плоскостей управления и данных. Он вызвал настоящий ажиотаж среди производителей оборудования, проектировщиков чипсетов, сетевых операторов и исследователей-сетевиков. Перед появлением OpenFlow, некоторые производители чипсетов, такие как Broadcom, уже пытались создавать открытые интерфейсы API, чтобы дать возможность программистам управлять определёнными режимами передачи пакетов. Решение открыть чипсет дало возможность управления сетевыми устройствами, давно ожидаемому в отрасли. Это также дало возможность более широкому числу компаний-производителей создавать коммутаторы без необходимости больших вложений в проектирование и производство их собственного оборудования для плоскости данных.

Во второй половине 2000-х исследовательская группа в Стэнфорде, воодушевленная успехом SDN в их кампусной сети, стала широко пропагандировать эту концепцию и для других кампусных сетей, причем и для сетей большого масштаба, объединяющих несколько кампусных сетей, где и были реализованы первые проекты SDN.

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

К недостаткам OpenFlow следует отнести отсутствие поддержки глубокого анализа пакетов (DPI) на плоскости передачи данных, поэтому OpenFlow сам по себе не мог эффективно задействовать функциональность «мидлбоксов» — вспомогательного сетевого оборудования, например, брандмауэров.

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

  • плоскость данных (data plane) с открытым интерфейсом;
  • уровень управления состояниями (state management layer), который отвечает за постоянное отслеживание состояния сети;
  • уровень управляющей логики (control logic), производящий различные операции в зависимости от состояния сети.

Мифы и предубеждения относительно SDN. Один из распространённых мифов об SDN – первый пакет трафика должен идти на контроллер для обработки. Некоторые ранние системы, например, Ethane, именно так и работали, поскольку они были предназначены для поддержки подробных политик поддержки в небольших сетях. На самом деле, в SDN в общем, и в OpenFlow в частности, этого не требуется, поскольку в них контроллер не обрабатывает непосредственно трафик данных.

Другой миф – в SDN, якобы, контроллер должен быть физически централизован. Такие  проекты, как Onix и ONOS, наглядно демонстрируют, что SDN-контроллер может, и даже должен, быть распределённым. А такие масштабные проекты SDN, как частная магистральная сеть Google, вообще демонстрируют множество контроллеров, распределённых по всей сети между Америкой и Европой.

Наконец, самое общее предубеждение состоит в том, что OpenFlow и SDN эквивалентны друг другу. На самом деле, OpenFlow – лишь один, хотя и очень популярный, пример реализации SDN, и принципы SDN могут быть реализованы и при помощи других API, например, Cisco ONE и JunOS SDK.

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

В частности, SDN уже доказала свою пользу в решении проблем виртуализации сети.

Виртуализация сети

Виртуализация сети – абстрактное представление для верхнего уровня сети, которая отделена от нижележащего физического оборудования. При этом возможно создание множества независимых виртуальных сетей, которые совместно используют единую сетевую инфраструктуру, причем каждая из виртуальных сетей имеет гораздо более простую топологию, чем нижележащая физическая сеть. Например технология виртуальной локальной сети VLAN (Virtual Local Area Network) создает иллюзию отдельной LAN, которая простирается через множество физических подсетей, где несколько сетей VLAN может работать на одном наборе коммутаторов и маршрутизаторов. Хотя виртуализация сети концептуально не зависит от SDN, соотношения между двумя этими технологиями в последние годы стали более тесными.

Механизмы совместного использования инфраструктуры были использованы и в программируемых сетях ранее (например, для множества арендаторов в одном дата-центре, административных группах в кампусных сетях, и пр.). Поэтому сам термин «виртуализация сети» многие эксперты рассматривают как несколько расплывчатый, в частности, ведутся дискуссии о том, можно ли называть технологию «нарезки ресурсов сетей» (network slicing) видом виртуализации сети.

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

Поэтому, строго говоря, виртуализация сети не обязательно требует SDN, а SDN (как логическое разделение плоскостей правления и передачи данных) не обязательно означает виртуализацию сети. SDN и виртуализация сети соотносятся друг с другом в трех основных ипостясях:

  • SDN, как средство виртуализации сети. Виртуализация сети срочно понадобилась в облачных вычислениях, т.к. облачным провайдерам был нужен способ логического разделения заказчиком (или «арендаторов») на единой сетевой инфраструктуре. Платформа виртуализации проекта Nicira NVP (Nicira’s Network Virtualization Platform) предлагала такое абстрагирование без поддержки со стороны нижележащей сети. Такое решение предоставляет каждому арендатору абстракцию коммутатора для всех его виртуальных машин в дата-центре (Open vSwitch). Логически централизованный контроллер устанавливает правила инкапсуляции пакетов и модифицирует их при перемещении виртуальных машин по серверам в дата-центре.
  • Виртуализация сети, как средство оценки и тестирования SDN. Возможность отделять управляющие приложения SDN от нижележащего уровня передачи данных дает возможность те6стировать и оценивать управляющие приложения SDN на виртуальном окружении перед тем как приложение будет развернуто на действующей сети. Решение Mininet использует виртуализацию процессов для запуска нескольких виртуальных коммутаторов OpenFlow, оконечных узлов и SDN-контроллеров на одной физической (или виртуальной) машине. Это позволяет Mininet эмулировать сеть с сотнями узлов и коммутаторов на одной машине. В такой среде исследователь или оператор может разрабатывать управляющую логику и легко тестировать ее на полномасштабной эмуляции плоскости передачи данных. После тестирования, отладки и оценки, плоскость управления может быть развернута на реальной продуктивной сети.
  • Виртуализация («нарезка») SDN. В обычной сети виртуализация маршрутизаторов и коммутаторов – довольно сложное дело, поскольку каждый виртуальный компонент должен иметь собственный экземпляр управляющей программы. Напротив, виртуализировать «тупой» SDN-коммутатор гораздо проще. Система FlowVisor дает возможность создать в кампусной сети среду тестирования поверх физического оборудования, которое несет рабочий трафик. Основная идея состоит в том, чтобы разделить пространство сети на «нарезки» — слайсы (slices) (концепция введенная группой PlanetLab), где каждый слайс имеет свою долю сетевых ресурсов и управляется своим SDN-контроллером. Такая концепция сейчас используется для сетей доступа, чтобы дать возможность другим провайдерам (например, локальным провайдерам интернет-доступа) предоставить услуги локализованному кругу пользователей без развертывания собственной сетевой инфраструктуры, причём с собственной сетевой топологией и адресным пространством.

Хотя ранние применения SDN относились к университетским кампусным сетям (Стэнфорд), дата-центрам (Google), и магистральным сетям больших предприятий, в настоящее время исследуется и тестируется применение SDN для более широкого круга применений. Это «домашние сети», сети предприятий, точки обмена интернет-трафиком, опорные сети операторов связи, сети мобильного и WiFi доступа.

Заключение

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

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

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

Источник: блог Алесея Шалагинова "Телеком и ИТ"

Оставить свой комментарий:

Для комментирования необходимо авторизоваться!

Комментарии по материалу

Данный материал еще не комментировался.