Эволюция SDN: путь в прекрасное программируемое будущее
По прогнозам аналитиков, к 2018 году мировые расходы на программно-конфигурируемые сети, имеющие первостепенную важность для облачных ЦОД, возрастут до 35 миллиардов долларов:
Аналитики Cloud4Y провели цикл форсайтов и сессий долгосрочного стратегического планирования, и сегодня мы хотим поделится с вами образом того будущего, которое у нас получилось. В этой статье речь пойдёт об эволюции программно-определяемых сетей в течение ближайшего столетия, а также об их роли для корпоративных коммуникаций, интернета и беспроводных подключений.
Общий тренд
Первая волна облачных вычислений началась с централизации и виртуализации серверов — в результате смены подхода к хранению данных и использованию программного обеспечения. Зарождающаяся вторая волна затрагивает развитие программно-определяемых сетей (SDN), централизацию и виртуализацию управления сетью в облаке.
После становления SDN в центрах обработки данных, развёртывание SDN разрослось в NaaS (сети как услуга) — модель, предлагаемую предприятиям и частным клиентам.
What for? Нафига козе баян?
SDN снижает потребность в технических специалистах (прости, Хабр!) — и, как результат, сокращает капитальные (CapEx) и эксплуатационные (OpEx) расходы. Также SDN обеспечивает быстрое взаимодействие сервисов, поскольку данные программируются сервисами удаленного контроля (контроллерами) и приложениями. В глобальном плане SDN трансформирует сеть в вычислительный домен и перенимает все больше практик стандартизации, применимых к компьютерам и программному обеспечению.
Таким образом, мы можем определить программно-определяемые сети (SDN) как один из наиболее значительных сдвигов парадигмы, зарегистрированных в сетевой индустрии в последние годы.
Предыстория
Возникновение SDN и OpenFlow (протокол управления обработки данных в SDN) было вызвано необходимостью идти в ногу с новыми сетевыми требованиями, возникающими в связи с популяризацией облачных вычислений, необходимости в мобильности и объемных информационных приложениях.
Цели SDN включают способность быстро внедрять сетевые инновации быстрее и радикально упростить и автоматизировать процесс управления крупными сетями. Тем не менее, многие принципы SDN не являются абсолютно новыми — например, возможность программирования сети тестировалась в Active Networking в 90-е годы, а выделение уровня контроля было представлено в 2000-х рабочей группой IETF ForCES Working Group. К сожалению, многие результаты таких исследований не получили широкого распространения.
Наша цель сегодня — рассмотреть перспективы развития SDN и OpenFlow, впервые исследованного в ONF (Открытом фонде сетевых технологий), в который в настоящий момент входят все крупные производители сетевого оборудования: Alcatel-Lucent, Cisco, Dell, Ericsson, Extreme Networks, HP, Huawei, IBM, Intel, Juniper Networks.
Примеры использования SDN
Использование SDN — движущая сила в эволюции OpenFlow. Число примеров использования SDN, основанных на применении OpenFlow, за последние годы масштабно возросло. Мы рассмотрим два наиболее значительных для эволюции OpenFlow кейса, которые достаточно обширно иллюстрируют разнообразие круга вопросов, касающихся SDN: облачные ЦОД и унифицированные коммуникации на предприятиях.
ЦОД уходит в облако
Вычислительные ресурсы в облачных ЦОД создаются автоматически в считанные минуты. Типичное же сетевое управление вручную с помощью человека затрагивает работу интерфейса командной строки для каждого сетевого элемента, и, таким образом, осуществляется намного медленнее. Сбои в работе сети могут иметь широкое воздействие, а влияние изменений сети достаточно сложно спрогнозировать. Один подход к этой новой динамической парадигме заключается в отделении сети от вычислительной неустойчивости и предоставлении только плоских статических сервисов связи.
Тем не менее, облачные дата-центры создают новые требования к базовой сети. Например, трафик от разных арендаторов должен быть сегрегирован как для повышения безопасности, так и для улучшения производительности.
Различные сетевые функции, такие как Firewall, системы распознавания Интернет-трафика (DPI) и балансировки нагрузки должны быть добавлены по требованию клиента и в соответствии с его трафиком. Таким образом, сетевые функции должны быть как никогда тесно связаны с вычислительным функционалом, так как сетевая политика должна соответствовать вычислительной политике, и обычных статических настроек сети становится недостаточно.
Распространенным решением сегодня является развертывание SDN для динамического конфигурирования статической сети. VSwitch, программный коммутатор с открытым кодом, динамически маршрутизирует для каждого сервера пакеты от виртуальных машин (VМ) по различным статическим путям, действующим в сети.
Менеджер ЦОД управляет API (интерфейсом прикладного программирования) для применения новых требований к подключению к сетевому контроллеру при внесении изменений в вычислительные данные. Сетевой контроллер может затем использовать интерфейс API, например, OpenFlow, чтобы применить требования по обеспечению сетевого доступа и политики к программному коммутатору VSwitch.
Примером эволюции OpenFlow может являться добавление многоканальной поддержки, обусловленное стремлением использовать OpenFlow в облачных ЦОД. На современных версиях OpenFlow включена возможность инкапсуляции метаданных — базовый примитив в создании логической сети поверх существующей.
Облачные корпоративные коммуникации
Интерактивные медиа-приложения, такие как видео-конференция или удаленное рабочее место, которые требуют Качества обслуживания (QoS) в сети, гарантирующего производительность приложений — либо развертываются на дорогостоящих выделенных сетях, либо страдают от плохого качества невыделенных сетей.
QoS для этих приложений критично и оно должно поддерживаться в сквозном режиме на основе глобальной сетевой политики, что делает процесс развертывания и конфигурирования сложным. Следовательно, существующие реализации QoS в первую очередь ограничены спецификацией QoS, базирующейся на статичных решениях и частично на сетевом аспекте.
Для сегодняшних сетей не существует эффективного способа идентифицировать процессы, требующие QoS, и политик, применимых к каждому из них. К тому же, система контроля доступа требует вычислительного подхода и конфигурирования подходящего QoS над QoS входящего потока.
Выделение ресурсов QoS также должно быть динамически адаптировано для удовлетворения различных потребностей трафика и чувствительных к QoS рабочих процессов. Эволюция SDN может помочь автоматизировать QoS-конфигурации всей сети для Унифицированных коммуникаций, как было продемонстрировано на презентации OpenFlow Lync от HP и Microsoft.
MS Lync — это продукт для корпоративных коммуникаций и обмена сообщениями, включая аудио- и видео-конференции, удаленный доступ к рабочему столу с помощью конечного клиента на ПК и центрального сервера Lync для управления сеансами связи и политиками.
Продукт VAN controller — это SDN-контроллер, который может конфигурировать сетевые контроллеры с использованием протокола OpenFlow. Сервер Lync и VAN controller взаимодействуют через северный интерфейс прикладного программирования SDN (northbound API — программный интерфейс, с помощью которого приложение представляет низкоуровневые детали вышестоящему в архитектуре системы приложению).
Модуль QoS на SDN-контроллере необходим для мониторинга использования ресурсов сети и может применять конкретные QoS-меры к потокам в сети, базируясь на политиках QoS. Модуль QoS может легко сопоставить глобальные политики QoS и сеть.
При запуске новой сессии сервер Lync может обращаться к требованиям сессии, таким как необходимая пропускная способность и сквозная задержка, чтобы проверить с помощью SDN-контроллера, имеются ли доступные ресурсы. Контроллерный модуль QoS может определять применимую к конкретному соединению политику, базируясь на глобальных политиках QoS, характеристиках, переданных сервером Lync, состоянием других существующих в сети QoS-соединений и при необходимости на основе идентификации пользователя (полученной с помощью службы каталогов, например, LDAP). Затем модуль QoS программирует эту политику на различные коммутаторы с использованием OpenFlow.
Целью здесь является не только предоставление требуемого QoS, но и масштабирование используемых ресурсов. Если качество сессии неприемлемо, состояние сети может быть проанализировано в режиме реального времени и могут быть предприняты меры (например, перенаправление вызова).Корпоративные сети с автономным управлением поддаются подобному глобальному QoS контролю.
Будущее наступает
Два рассмотренных нами случая использования SDN предназначены для удовлетворения нужд, которые плохо решаются с помощью действующих сетей. В следующих статьях мы рассмотрим более детально основные элементы SDN, а также поговорим об эволюции в маршрутизации и беспроводных подключениях.
Все современные компании, предлагающие облачные сервисы, признают: перспективы развития SDN глобальны, и требуется определенное количество усилий для выведения SDN на новый уровень использования. Тем не менее, потребности в SDN также колоссальны, а количество организаций и фондов, занимающихся его девелопментом, насчитывает десятки.
Анализируя состояние рынка или даже клиентский трафик самого Cloud4Y, можно отметить, что потребности в облачных услугах неуклонно растут, и важность развития SDN в этом смысле неоспорима. Именно поэтому можно безо всяких сомнений утверждать, что программируемое будущее — не за горами.
