`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

SDN: теория и практика

+55
голосов

Почти любая новая технология, прежде чем завоевать рынок, проходит некий инкубационный период, во время которого происходит ее созревание. Он характеризуется настороженным отношением к ней потенциальных пользователей, что оправдывается рядом причин, как объективных, так и субъективных. Хорошим тому примером служат облачные вычисления. Та же картина наблюдается и в отношении программно-определяемых сетей — SDN.

Прежде всего отметим, что данная публикации является результатом обсуждения программно-определяемых сетей с двумя ИТ-специалистами. Один из них, менеджер категории сетевых продуктов в странах Восточной Европы Вячеслав Самойленко из киевского офиса НР, а второй — архитектор сетевых решений Михаил Пикульский из компании-системного интегратора ЛанТек.

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

Нужно упомянуть о том, что эта технология разрабатывалась не с целью активизировать продажи сетевого оборудования, а для решения противоречий, которые возникли между традиционной статической архитектурой сетей и динамическими требованиями бизнеса. Решению проблем традиционными методами препятствует ряд ограничений, присущих имеющейся архитектуре. К примеру, чтобы добавить или убрать какое-нибудь устройство, сетевые администраторы должны провести корректировки в многочисленных коммутаторах, маршрутизаторах, брандмауэрах, порталах веб-аутентификации и т.п., адаптировать списки доступа (ACL), VLAN, QoS и другие базирующиеся на протоколах механизмы, используя для этого инструменты управления на уровне устройств. Во внимание также должны быть приняты топология сети, производители и модели коммутаторов, версии ПО. Такая сложность приводит к относительной статичности сетей, поскольку администраторы стремятся минимизировать риски, привносимые сервисом. Сегодня приложения распределены по множеству виртуальных машин (ВМ), которые обмениваются данными друг с другом. ВМ мигрируют для оптимизации и балансировки нагрузки серверов, создавая потоки данных между конечными физическими точками. Миграция ВМ вызывает ряд проблем в традиционных сетях, от схем адресации и пространства имен и до основных представлений о сегментации и дизайна, основанного на маршрутизации. Эти и ряд других несоответствий между запросами рынка и возможностями существующих сетей привели индустрию к переломному моменту — была разработана концепция программно-управляемых сетей.

Она основана на том, что традиционные сетевые устройства содержат в проприетарном встроенном ПО набор правил и логику для управления потоком и модификацией данных, которые разделяется на две части, известные как плоскость (слой) данных (data plane) и плоскость управления (control plane). Концепция предусматривает разделение управления сетью (плоскости управления) и механизма продвижения данных (плоскости данных). Перенос управления в доступные вычислительные устройства, называемые SDN-контроллерами, позволяет приложениям и сервисам абстрагироваться от базовой инфраструктуры и трактовать сеть как логическую или виртуальную сущность.

Логическая структура архитектуры SDN (рис. 1) состоит из трех основных уровней (снизу вверх): инфраструктуры, управления и приложений.

SDN: теория и практика

Рис. 1. Логическая структура архитектуры SDN

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

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

Таким образом, посредством открытых API между уровнями управления и прикладным бизнес-приложения могут оперировать с абстракцией сети, используя сетевые сервисы и возможности, не вдаваясь в детали их реализации. В результате вычислительные и сетевые ресурсы могут быть оптимизированы. Рассмотрим на примере MS Lync более подробно, как происходит взаимодействие между бизнес-приложением, SDN-приложением, в данном случае НР Network Optimizer, и SDN-контроллером (рис. 2).

SDN: теория и практика

Рис. 2. Схема взаимодействия бизнес-приложения и SDN-контроллера

Что сделала Microsoft (совместно с НР), так это разработала Lync SDN API. Идея заключается в том, что в среде Lync имеется API, с помощью которого приложение прямо направляет Network Optimizer необходимые требования к конфигурации коммутаторов, а тот, в свою очередь, передает ее SDN-контроллеру. Последний транслирует требования от уровня SDN-приложения к коммутаторам.

Предположим, что имеются два пользователя, Джеймс (слева внизу) и Линда (справа внизу). Джеймс хочет связаться с Линдой посредством Lync. Когда Джеймс делает вызов (зеленая пунктирная линия), Lync через SDN API обращается к Network Optimizer (красная пунктирная линия) и указывает, какой сервис хочет получить. Последний передаст SDN-контроллеру необходимые требования к конфигурации сети, а тот с помощью протокола OpenFlow (серая пунктирная линия) реконфигурирует коммутаторы. Такое не может быть сделано в традиционных сетях. В качестве примера назовем еще одно SDN-приложение — HP Network Protection. Оно предназначено для кампусных сетей и обеспечивает безопасность их границ.

Естественно, что такие SDN-приложения могут быть разработаны для любого бизнес-приложения, причем не только компанией-производителем, но и любым подготовленным программистом. Для этого НР разместила в открытом доступе соответствующий SDK. Компания также создала интернет-магазин для SDN-приложений, своеобразный App Store, правда, не для конечных пользователей, а для корпораций. В нем представлены SDN-приложения, разработанные не только НР, но и ее партнерами. Так, BlueCat DNS Director совместно с архитектурой HP SDN позволяет упростить сквозную безопасность сети и увеличить ее гибкость и надежность; Fortinet FortiGate обеспечивает защиту конечных пользовательских устройств, блокируя атаку на ближайшем коммутаторе и не позволяя ей распространяться по сети; функции SDN-приложения KEMP Enhanced Load Balancing видны из его названия. Заказчик может прибрести в НР App Store необходимые продукты и установить их прямо на SDN-контроллер.

Интересно, что, по прогнозам IDC, объем рынка SDN к 2016 г. достигнет 3,7 млрд долл., а рынок приложений для SDN — 670 млн долл. Так что в ближайшие несколько лет на этом рынке будет наблюдаться значительный рост.

Ну, хорошо, скажет заказчик. Все это выглядит заманчиво. А что делать с имеющейся сетевой инфраструктурой? Выбросить? Я на такой шаг не пойду, по крайней мере, еще лет пять. Однако ситуация не столь драматична, как кажется. Вот как ее прокомментировал Вячеслав Самойленко.

Безусловно, нет необходимости заменять всю существующую сетевую инфраструктуру. НР уже в течение многих лет поставляет коммутаторы с поддержкой протокола OpenFlow. Так что очень вероятно, что сеть наших заказчиков уже готова для внедрения технологии SDN. Если даже это не так, то можно реализовать гибридную модель, другими словами, внедрить SDN только в какой-нибудь подсети или фрагменте, а остальная часть может базироваться на традиционных технологиях. Таким образом, может быть некий переходной период. Это намного упрощает процесс внедрение этой инновационной технологии.

Остается вопрос, как быть с ЦОД’ами? С точки зрения реконструкции сетевой инфраструктуры, это традиционно наиболее консервативные участники ИТ-рынка.

Развернуть SDN в ЦОД поможет решение HP—VMware, объединяющее SDN и сетевую виртуализацию для публичных, частных и гибридных облачных ЦОД, в которых работают как виртуализованные, так и традиционные приложения.

Гибридный ЦОД строится на базе платформы сетевой виртуализации VMware NSX, которая устанавливает динамичную оверлейную (наложенную) виртуальную сетевую инфраструктуру поверх основной сетевой инфраструктуры НР.

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

При сетевой виртуализации функциональный эквивалент «сетевого гипервизора» воспроизводит полный набор сетевых сервисов уровней L2—L7, то есть коммутацию пакетов, маршрутизацию, управление доступом, брандмауэр, QoS и балансировку нагрузки, программными средствами. В результате они могут программно объединяться в произвольных комбинациях, образуя уникальные виртуальные сети, по сути, за секунды (рис. 3).

SDN: теория и практика

Рис. 3. Виртуальная оверлейная сеть

На рис. 3 NSX представляет ВМ виртуализованные версии всех традиционных сетевых функций. Эти виртуальные функции распределены по различным хостам в ЦОД. Так, трафик между VM1 и VM2 с логической точки зрения выглядит как трафик через некоторые коммутаторы, брандмауэры и балансировщики нагрузки. Однако реальный трафик проходит по пути, представленному на рис. 4.

SDN: теория и практика

Рис. 4. Виртуальный (зеленый) и реальный (коричневый) трафики

Трафик от VM1 фактически подается на локальные экземпляры коммутаторов, брандмауэров и балансировщиков, реализованных NSX на хостах. Эти локальные экземпляры определяют, что адресатом трафика является удаленный хост, на котором находится VM2. Они инкапсулируют трафик и направляют его к удаленному хосту, где после разборки он представляется целевой VM2, как если бы он прошел через физические экземпляры этих устройств. Туннели, представленные коричневым цветом на рис. 4, с точки зрения сетевой инфраструктуры видны как плоский IP-трафик и не требуют дополнительной функциональности от физических устройств.

Решение HP—VMware SDN объединяет на федеративных принципах VMware NSX и HP VAN SDN-контроллер. В этом SDN-решении коммутаторы HP FlexFabric серии 5930 функционируют как аппаратные шлюзы L2, которые пересылают трафик между ВМ на гипервизоре и компонентами физической инфраструктуры, такими как серверы, брандмауэры, маршрутизаторы. Это достигается за счет передачи посредством моста пакетов с метками VXLAN (Virtual Extensible LAN) из оверлейной (виртуальной) сети к соответствующим VLAN’ам физической сети. Таблица отображения для создания моста, или туннелей, сбрасывается L2-шлюзам, поддерживающим OpenFlow, HP VAN SDN-контроллером по соответствующим протоколам.

В целом, сетевое решение HP—VMware объединяет в федерацию HP VAN SDN Controller и платформу виртуализации VMware NSX, предоставляя заказчикам интегрированный подход к автоматизации физической и виртуальной сетевой инфраструктуры, управлению и видимости.

Еще одно преимущество SDN-решений заключается в том, что они позволяют улучшить масштабируемость и гибкость всей распределенной инфраструктуры. В октябре 2014 г. НР объявила о совместном с Alcatel-Lucent решении Distributed Cloud Networking (DCN), расширяющем ее портфель продуктов виртуализации сетей.

DCN состоит из трех компонентов. Виртуализованный контроллер сервисов (Virtualized Service Controller, VSC) обеспечивает плоскость управления LAN внутри ЦОД и по WAN. Виртуализованная директория сервисов (Virtualized Service Directory, VSD) является каркасом для политик и оркестровки. Виртуальный маршрутизатор/коммутатор (Virtualized Routing and Switching, VRS) является элементом плоскости данных и базируется на Open vSwitch. Оверлей использует VXLAN-инкапсуляцию для туннелей оверлейного трафика внутри ЦОД и маршрутизацию MPLS поверх протокола Generic Routing Encapsulation для передачи данных между ЦОД. Тегирование MPLS позволяет наложить сетевые сегменты поверх WAN таким образом, что они будут вести себя с точки зрения приложений подобно продолженным LAN.

DCN позволяет сервис-провайдерам и большим организациям автоматически разворачивать облачные сети по распределенной инфраструктуре за считаные минуты. Посредством SDN и сетевой виртуализации DCN позволяет сетевым администраторам управлять распределенным сетевым окружением из одного центра независимо от того, имеет ли организация частный, публичный или гибридный облачный ЦОД.

Такова теория. А что сегодня происходит на практике? Каковы сдерживающие факторы (кроме финансовых, конечно), препятствующие внедрению SDN в организациях? Ситуацию прокомментировал Михаил Пикульский.

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

Подобные опасения всегда возникают при переходе на новую технологию. Такова природа человеческой натуры — незнание вызывает страх. Остается только одно, изучить архитектуру и технологию SDN достаточно глубоко, выбрать грамотных и надежных интеграторов, которые помогут «преодолеть пропасть» (jump over a chasm) между старой статической сетью и новой, на основе SDN.

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

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

Препятствует внедрению SDN также мнение о том, что протокол OpenFlow еще далек от зрелости, и его ждет множество изменений.

Это правда, однако таков путь любой новой технологии. Все протоколы когда-то были молодыми, даже те, которые сегодня уже старые. Это неотъемлемая часть любой новой технологии. Тем не менее, протоколы OpenFlow уже работают у многих заказчиков. Например, у South Washington, Bama, Deltion College и др.

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

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

Протокол OpenFlow разрабатывается организацией Open Network Foundation (ONF). Давайте посмотрим на состав ее участников.

Трудно поверить, что организация, среди участников которой есть такие компании, как HP, Cisco, Intel, Brocade, Citrix, Huawei, H3C, Juniper, NEC, Oracle и т. д., может разрабатывать «неправильный» протокол. Остальное все маркетинг и борьба между производителями. Ну и наконец, очень мало реализованных проектов на рынке (все боятся неизведанного).

Что ж, у новых технологий всегда мало реализаций. Как только реализаций становится много, технология становится зрелой. Технология SDN находится на пороге перехода к «зрелости».

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

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

Варианты, когда все устройства в сети умеют работать с OpenFlow или когда все устройства не умеют работать с OpenFlow, предельно ясны. Для случая, когда только часть устройств поддерживает протокол OpenFlow, план по внедрению SDN может быть следующим.

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

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

Следующий шаг — интеграция устройств, умеющих работать с OpenFlow и с контролером SDN. А для того чтобы контроллер мог работать с остальными устройствами в сети, на сервер с iMC устанавливаем «HP iMC Virtual Application Networking SDN Management Software». Этот модуль позволяет SDN-контроллеру работать с остальными устройствами в сети.

Описанное пошаговое внедрение SDN для предприятий разной зрелости было реализовано на базе демоцентра компании ЛанТек.

Таким образом, приступить к внедрению технологий будущего можно уже сейчас. По прогнозам, 45% средних и крупных компаний планируют запуск SDN у себя в ЦОД уже в 2015 г., а в 2016 г. таких компаний ожидается до 87%.

+55
голосов

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT