В рубрику "All-over-IP" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Будущее за программно-конфигурируемыми сетями

Разберемся с проблемами современных сетей. Все просто – они сложные. Невероятное наслоение сетевых протоколов и технологий привело к тому, что изменения в инфраструктуре (запланированные или вызванные изменениями топологии вида "экскаватор порвал кабель") могут стать настоящим кошмаром и требовать наличия высококлассных специалистов для сопровождения.

Прогресс неумолим

Изменения приходится делать постоянно:

• виртуальные машины постоянно перемещаются между ЦОД;
• подключаются новые точки доступа, камеры наблюдения;
• абонентская емкость, а значит, и требования к сетевому оборудованию серьезно расширились благодаря Интернету вещей;
• BYOD (Bring Your Own Device) требует моментального "проключения" сервиса до клиента и многое-многое другое.

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

Но мы привыкли. Это вполне логичный путь индустрии от простейших ЛВС до многоуровневых решений масштабов предприятий, городов или вообще этого нашего Интернета. Пройти этот путь при помощи одной технологии и сохранить состояние 1969 г. выпуска невозможно. По пути, конечно, пришлось обрасти дополнительными протоколами и технологиями, которые решали задачи текущего момента путем добавления очередного костыля к уже существующей горке вокруг оригинальной технологии. Далее привожу небольшой технический экскурс в форме ответов на самые распространенные вопросы про SDN.

Что предлагает SDN в первом приближении?

Формальное определение говорит о разделении Control Plane и Policy Plane.

А раньше как было?

Традиционно оба компонента (Control & Data Plane) архитектуры были "упакованы" в одну проприетарную систему, выпускаемую производителем оборудования: коробка, которую сделал вендор А, на которой стоит ПО вендора А, написанное разработчиками вендора A, на всем этом написано "вендор А". А для управления этим оборудованием, как можно догадаться, потребуется система управления от вендора А.

Что означает разделение Control & Data Plane?

С сетевого устройства исчезает его управляющий интеллект (Control Plane) и остается за пределами физической системы, оставляя на оборудовании только функционал пересылки и обработки. Этот процесс часто называют Disaggregation.

Куда исчезает Control Plane?

На устройство, которое в терминологии SDN называется SDN-контроллер. Конечно, это может быть виртуальная машина.

Кто производит SDN-контроллеры?

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

Как коммутатор обходится без Control Plane?

Удивительно, но может существовать. На коммутаторе остается достаточно интеллекта, чтобы связаться с контроллером, получить инструкции и применить их к обработчикам и пересылке. Можно сказать, что коммутатор со своим "мозгом" (который раньше просто был у него на борту) теперь связывается по IP. Естественно, такая виртуализация позволяет территориально разнести оборудование. Очевидно, что в этот момент устройство серьезно дешевеет, ведь на нем остался только стандартный чипсет от Broadcom и микрокод для общения с контроллером.

Такие коммутаторы называют Bare-Metal Switches. Оборудование от ODM-производителей (Original Design Manufacturers) без установленной операционной системы. Чистое "железо" делают малоизвестные компании, такие как Accton (Edge-Core Networks), Delta Networks (Agema Systems), Quanta Сloud Tech (iwNe-tworks). Они создают продукты по заказу других, более (а иногда – очень) известных компаний, оставляя на себе ограниченную гарантию на "железо".

Как контроллер связывается с управляемым оборудованием?

Через специальный набор команд. Официальное название – "южный" интерфейс (Southbound API). Наиболее известным примером этого интерфейса является протокол OpenFlow. Благодаря тому, что OpenFlow весь такой гибкий, открытый, адаптируемый и, что самое главное, первый, ему досталась роль фактического стандарта "южного" интерфейса контроллера. Важно, что протокол OpenFlow – открытый, и это позволяет брать от разных производителей контроллер и сами сетевые устройства. Кстати, развитие OpenFlow курирует Open Network Foundation (ONF).

Какие еще интерфейсы имеются у контроллера?

По логике, конечно, есть еще и "северный" интерфейс (Northbound API). Используется для связи с приложениями, бизнес-логикой инфраструктуры – собственно системой постановки задачи для контроллера SDN. Это может быть вышестоящая сетевая система управления, платформа виртуализации ЦОД, система балансировки нагрузки, да и вообще что угодно.

Задача контроллера – управлять?

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

Интересно, что первые SDN-архитектуры построили такие игроки, как Facebook, Amazon, Google, "Яндекс" (их называют Web-Scale или Hyperscale). Это им, владельцам самых больших ЦОД, потребовались новые открытые масштабируемые сетевые архитектуры. Которые еще и довольно комфортно расширять с финансовой точки зрения за счет покупки коммутаторов "без мозгов".

В чем основные преимущества программно-определяемых сетей?

Тезисно соберем их вместе:

• Оборудование передачи данных серьезно дешевеет.
• Снижаются эксплуатационные расходы. И стоимость запуска новой функции или сервиса. И затраты на обучение персонала.
• Конфигурация сети централизована и упрощена. Вся сеть настраивается из одного места.
• Более равномерная загрузка мощностей. С устройства передачи данных уходят неспецифичные задачи.
• Принцип "потока" данных пришел на смену традиционной маршрутизации, которая выполнялась последовательно на всех промежуточных устройствах.
• Возможность простой замены оборудования.

Есть ли "подводные камни"?

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

Есть место и для конструктивной критики, которая подсвечивает тонкие места и указывает пути совершенствования.

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

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

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

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

Опубликовано: Журнал "Системы безопасности" #6, 2016
Посещений: 4486

Автор Сергей Трюхан Менеджер по развитию бизнеса компании Avaya Всего статей:  2

В рубрику "All-over-IP" | К списку рубрик  |  К списку авторов  |  К списку публикаций