Мы живем в сетевом мире. И все больше сфер деятельности человека уходит в пространство сетей. Основой успеха является возможность компании быстро адаптировать инфраструктуру и бизнес-процессы под требования рынка. По словам председателя правления Сбербанка Германа Греф, главный вызов сейчас – скорость изменений и управления ими. Если меняешься медленнее, чем среда, то не можешь не отставать, при этом отставание очень быстро накапливается. Раньше речь шла о квартальном или полугодичном цикле, а сейчас – о ежедневном. Технологическая основа для высокой скорости адаптации – эффективная, гибкая, сетевая инфраструктура, где все большее количество сервисов и операций реализуется программно на типовом «железе», а не с помощью специализированных программно-аппаратных средств. В настоящей статье речь пойдет о концепции SDN.
В конце прошлого века стало ясно, что существующая архитектура сетей не соответствует требованиям приложений, изменениям в организации вычислений, новым телеком-технологиям, росту трафика. Конец первого десятилетия XXI в. ознаменовался появлением новой концепции в архитектуре и организации функционирования сетей – SDN.
В конечном итоге, чтобы справиться с ростом трафика на фоне увеличения количества пользователей, необходимости внедрения новых сервисов и обеспечения более высоких стандартов качества, игроки рынка предпочли разработку более мощных, интеллектуальных аппаратных устройств. Совмещение в современных компьютерных сетях функций управления и передачи данных усложняет контроль и управление. До недавнего времени действующая архитектура сетей развивалась по методу «ласточкиного гнезда», т. е. по мере выявления проблем к стеку протоколов TCP/IP добавлялся новый, который проблему решал. Но с каждым годом этот стек становился все сложнее, а, следовательно, все менее надежным, затраты на управление и эксплуатацию увеличивались.
Подходы к реализации SDN
В 2006–2007 гг. была предложена концепция сетевой архитектуры – Software defined network (SDN), позволявшая решить многие проблемы компьютерных сетей. Стоит отметить, что эта концепция в отличие, например, от АТМ, была неагрессивной. Ее применение позволяло эволюционировать из старой парадигмы в новую. В общем виде, SDN – новая сетевая архитектура, которая меняет то, как мы проектируем и управляем компьютерной сетью. Результат – сеть становится удобнее и надежнее, а ее эксплуатация – дешевле и проще.
Почти сразу было предложено несколько путей реализации концепции. Сегодня нельзя сказать, какой из способов является доминирующим.
Два подхода предполагают выделение так называемой плоскости управления (контроллера) программными средствами – виртуальными программными коммутаторами. Именно они считаются наиболее перспективным, хотя их практическое воплощение вызывает вопросы.
Первый способ предполагает реализацию SDN в виде наложенной сети (overlay) на базе виртуальных коммутаторов и туннелирования (с использованием протоколов VXLAN, NVGRE и пр.). Основная идея состоит в том, что на тех серверах, где «крутятся» виртуальные машины, настраиваются коммутация между виртуальными портами и отображение виртуальных портов на физические, а уже физические порты связываются между собой туннелями. Виртуальный коммутатор программируется с помощью специально выделенного ресурса, который называется программно-конфигурируемым контроллером. По существу, это операционная система, которая управляет, распределяет, контролирует и осуществляет мониторинг ресурсов сети.
Второй подход предполагает реализацию SDN на базе серверов агрегации трафика. На выделенный специальный сервер с помощью туннелирования заводятся каналы передачи данных. Затем данные с сервера передаются дальше под управлением SDN-контроллера с привлечением механизма туннелирования.
Следует отметить, что оба подхода – программные способы разделения управления передачей данных и собственно передачи данных, поэтому им присущи все достоинства и недостатки программной реализации. Основной недостаток – более высокие задержки при передаче данных по сравнению с аппаратной реализацией. Однако это решение самое гибкое с точки зрения функциональности коммутаторов и особенно управления инженерии трафика.
Третий подход предусматривает создание специальных аппаратных программируемых коммутаторов, программу работы которых формируют приложения контроллера и загружает контроллер. Он позволяет автоматизировать управление физической сетью с помощью приложений для контроллера плоскости управления, а также существенно упростить и сократить капитальную составляющую затрат на создание сети и операционные расходы на ее эксплуатацию. При этом унаследованная часть системы передачи данных может оставаться неизменной. Однако в пограничном слое между программно-управляемой частью сети и унаследованной требуются коммутаторы, которые, с одной стороны, программируемые, с другой – поддерживают традиционный TCP/IP стек протоколов.
Реализация SDN – на базе специальных аппаратных коммутаторов (с поддержкой протоколов Openflow, Netconf/Yang, Opflex, PCEP и пр.). Сеть SDN состоит из коммутаторов SDN, взаимодействующих с контроллерами по протоколу OpenFlow. Коммутатор SDN, реализующий только функции коммутации (forwarding) данных, представляет собой простое программируемое устройство, умеющее выполнять несколько несложных команд. Ожидается, что эти коммутаторы обойдутся значительно дешевле существующих, а маршрутизаторы «вымрут».
Концепция SDN обещала большие изменения не только в сетевых архитектурах, но и на рынке. Одними из первых интерес к SDN проявили такие компании, как Google, Facebook, американские операторы AT&T, NTT Communications, Deutsche Telecom, т. е. владельцы больших и сложных сетей. Затем «подтянулись» производители сетевого оборудования, которым концепция SDN, естественно, не нравилась, но игнорировать новые технологии было невозможно. Производители выбрали стратегию поведения «если не можешь предотвратить революцию, то возглавь ее». Однако быстро выяснилось, что из желающих возглавить революцию выстроилась очередь.
Штрихи к портрету экосистемы SDN
Прежде чем перейти к описанию стандартов, спецификаций и перечню сообществ, которые занимаются развитием концепции SDN, отметим, что в этой сфере не существует стандартов «де-юре», т. е. обязательных к исполнению всеми участниками рынка. Относительно SDN существует ряд организаций и сообществ, которые занимаются развитием спецификаций и популяризацией своей концепции развития SDN.
Исторически первая и, на наш взгляд, наиболее влиятельная международная организация, которая занимается продвижением SDN, – Open Networking Foundation (ONF), созданная в марте 2011 г. Инициаторами ее создания выступили шесть крупнейших компаний: Deutsche Telecom, Facebook, Google, Microsoft, Verizon и Yahoo. Помимо популяризации сетевой архитектуры целью организации была заявлена стандартизация SDN. Один из таких стандартов «де-факто» – протокол OpenFlow. Первое время участники рынка ошибочно ставили знак равенства между SDN и OpenFlow, забывая, что этот протокол – лишь один из способов реализации новой архитектуры. Протокол обеспечивал взаимодействие внешних, по отношению к коммутатору, программно-реализованных функций процессов управления сетью, включая маршрутизацию, балансировку нагрузки и т. д., которые не зависят от текущих прошивок оборудования и формируются на стороне специального внешнего приложения-контроллера.
К моменту создания ONF OpenFlow развивался в течение нескольких лет как совместная исследовательская разработка Стендфордского и Калифорнийского (Беркли) университетов. Один из авторов – Ник Маккеон (Nick McKeown), профессор Стэнфорда, даже вошел в состав Совета директоров организации.
Количество участников организации за первые полгода превысило 50 компаний, среди которых были почти все ведущие производители сетевого оборудования, включая Cisco, Huawei, NEC, Marvell, Intel, HP, Juniper. Статус членов совета директоров, в который вошли операционный директор Facebook, вице-президенты Google и Deutsche Telecom, подчеркивал перспективность технологии.
В настоящее время число участников ONF превысило 120. Организация декларирует, что она является управляемой ее членами и развивается исключительно с целью ускорить внедрение SDN на основе открытых стандартов. ONF запустила две программы сертификации. Первая – The OpenFlow Conformance Testing Program – дает возможность продемонстрировать соответствие решения требованиям спецификации OpenFlow. Независимые лаборатории, получившие специальный статус от ONF, проводят процедуры тестирования, разработанные в рамках ONF, и подтверждают соответствие спецификации OpenFlow для аппаратных средств (коммутаторы и маршрутизаторы), а также для сетевого программного обеспечения. Список оборудования, успешно прошедшего тестирования, открыт на сайте организации. Важно заметить, что проводится тестирование только для спецификаций не выше v1.3.4, тогда как последней версией спецификацией протокола OpenFlow является 1.5.
Вторая программа – The ONF-Certified SDN Professional Program (CSDN) – фактически подтверждает знания и квалификацию инженерного персонала в технологиях SDN.
В 2013 г. сразу несколько компаний пытались создать альтернативу ONF. Например, компания Dell предложила сформировать комитет по программно-конфигурируемым сетям (Software-Defined Networking) в Open Management Group, международном некоммерческом консорциуме, который четверть века занимается разработкой стандартов компьютерной отрасли. Свою инициативу в Dell объяснили тем, что «сетевой индустрии нужно четкое лидерство в области технологий SDN, поэтому компания делает важный шаг в направлении создания под эгидой OMG единого стандарта в рамках открытого международного процесса с участием ведущих компаний, конечных пользователей, правительственных структур и исследовательских учреждений». В Dell поясняли, что с OMG собираются работать над архитектурой стандарта, а с ONF – над его реализацией.
О создании группы было объявлено, и ее задачей провозгласили разработку единого стандарта SDN, независимого от производителя. Инициаторы группы полагали, что стандарты, разработанные в интересах всего сообщества, исключат ситуацию, когда приоритет получает один или несколько вендоров, и у клиентов будет больший выбор. Однако на сайте последняя новость о деятельности группы датирована 2013 г.
В том же 2013-м большинство ведущих ИТ-компаний, занимающихся технологиями SDN, поддержали проект OpenDaylight, в рамках которого разрабатывается платформа для SDN с открытым кодом. Среди прочих в проекте решили участвовать Cisco Systems, VMware, Juniper Networks, IBM, Hewlett-Packard, Dell, Intel и Ericsson, а организацией работы занимается Linux Foundation. Статус «платиновых» спонсоров получили Cisco, Brocade, Ericsson, Citrix, Microsoft и Big Switch Networks. Последняя компания вышла в 2014 г. из-за доминирования Cisco в проекте. Кроме финансового вклада они должны направить для работы в проекте на постоянной основе по десять сотрудников.
Директор Linux Foundation Джим Землин заявлял, что OpenDaylight должен стать для сетевой отрасли такой же общей платформой, какой стала Hadoop для обработки больших объемов данных или WebKit для веб-браузеров. Ни одна компания не будет полностью контролировать развитие OpenDaylight, победят лучшие решения. Однако сегодня все осознают, что проект контролируется компанией Cisco, что существенно ослабило интерес к нему.
В рамках проекта планировалось создание контроллера SDN с интерфейсами для сетевых приложений и сетевого оборудования, а также другие приложения и компоненты сетей SDN.
Исполнительный директор-распорядитель ONF Дэн Питт в ходе выступления на конференции Open Networking Summit в мае 2013 г. заявил, что каркас OpenDaylight, предназначенный для построения SDN, будет опираться на протокол OpenFlow, и что, по сути, организация является продолжением того, чем занимается ONF.
За три года, прошедшие с создания организации, она успела сделать многое. Обещав создание контроллера, организация разработала большую и сложную платформу, где контроллер является лишь частью. На сегодняшний момент выпущен уже четвертый релиз платформы.
В конце 2014 г. некоммерческая компания Open Networking Lab (ON.Lab), созданная исследователями из Стэнфордского университета и Калифорнийского университета и ставшая одним из разработчиков SDN и протокола OpenFlow, анонсировала операционную систему Open Network Operating System (ONOS). На ее создание сотрудников ON.Lab подтолкнула основная проблема, характерная для существующих проектов (прежде всего OpenDaylight). Суть в том, что они зависят от технологий, разработанных известными производителями, для которых SDN и NFV представляют угрозу. Представители ON.Lab утверждали, что на OpenDaylight значительное влияние оказывают Cisco Systems, IBM и другие компании. Проект ONOS заручился поддержкой таких ИТ-производителей, как Intel, Fujitsu и Huawei, и ведущих американских операторов связи AT&T и NTT Communications.
ONOS предназначена для сетей операторов регионального масштаба. По заявлению разработчиков, в дальнейшем она должна охватить провайдеров облачных сервисов и корпоративные сети. Разработчики ON.Lab обещали, что ONOS поможет объединить имеющееся у операторов оборудование с будущим SDN программируемым оборудованием. В следующих релизах производители ONOS старались решить проблему масштабируемости, поскольку это открыло бы возможность использования платформы в сетях сервис-провайдеров. Например, во второй релиз под названием Blackbird был включен набор показателей для оценки возможностей платформ управления и контроллеров SDN, пользователи получили возможность публикации в открытом доступе показателей производительности своих релизов Blackbird.
Одна из инициатив ON.Lab – разработка платформы управления облачными сервисами на основе SDN (интеграция с котроллером ONOS). Проект облака основывается на парадигме XaaS (Everything-as-a-Service). Модель XaaS сервиса сводится к централизованному управлению и оркестрированию множества экземпляров сервисов (под экземпляром обычно понимается ВМ с приложением) при помощи SDN контроллера. Для решения задачи оркестрирования предполагается разработка специализированной операционной системы – XOS (на основе Unix OS). XOS представляет собой программное окружение для облачных контроллеров, которое дает возможность гибкого и масштабированного управления «глобальным состояние» сетевой инфраструктуры облака. Подобная централизация процессов управления позволяет обеспечивать полный жизненный цикл сервисов в «облаке». XOS может служить расширением IaaS API для коммерческих облачных решений.
Как и Open Daylight, ONOS становится основой коммерческих продуктов. На сегодняшний момент пока только Ciena в конце 2015 г. выпустила коммерческий SDN-контроллер на основе ONOS. С учетом опыта основателей проекта (из лаборатории Стенфорда и Беркли вышел не только OpenFlow, но и первый SDN-стартап на миллиард – Nicira, который был приобретен VMware) можно с уверенностью утверждать, что этот продукт не последний.
CORD (Central Office Re-architected as Datacenter) – решение на базе проектов ONOS и XOS с акцентом на организации центрального офиса телеком-оператора (Enterprise, Residental-Telco, Mobile-Telco) для предоставления сервиса клиентам. Основная задача – разрешение основной функциональности оператора в облачной инфраструктуре и за счет гибкого управления доступностью, масштабированностью, безопасностью, изолированностью сервисов (реализующих функциональность telco-облако) снижение операционных расходов. На сегодняшний день проект CORD находится в состоянии POC (Proof of Concept), поддерживается компаниями AT&T, PMC Sierra и Sckipio.
В момент появления концепции SDN производители сетевого оборудования первого эшелона увидели в ней угрозу своему положению на рынке. Каждая из топ-компаний делала многомиллионные инвестиции в разработку интеллектуально сложных аппаратных средств и не могла себе позволить от них отказаться. Поэтому участие ведущих производителей в упомянутых организациях объясняется желанием быть в курсе событий и, по возможности, держать процесс появления новых открытых платформ под контролем. Второе направление – разработка этими компаниями собственных открытых платформ и формирование вокруг них сообществ и более мелких коммерческих компаний.
К примеру, в феврале 2014 г. Broadcom анонсировала программное обеспечение c открытым кодом для SDN Broadcom’s OpenFlow Data Plane Abstraction (OF-DPA). OF-DPA обеспечивает разработку и развертывание масштабируемых и высокопроизводительных SDN-приложений на основе OpenFlow на базе широко распространенных чипсетов Broadcom. OF-DPA совместим со спецификацией OpenFlow 1.3.1, утвержденной ONF.
Спецификации OF-DPA и API опубликованы и предоставляются при условии базовой реализации на ODM и OCP-совместимых коммутаторах с целью привлечения академического сообщества для развития технологии. Любые OpenFlow 1.3.1-совместимые контроллеры могут быть интегрированы с OF-DPA, чтобы была возможность разработки таких популярных вариантов использования SDN, как виртуализация сетей, инфраструктуры, цепочки сервисов (это NFV).
Компания Huawei также разработала собственный протокол Protocol Oblivious Forwarding (POF) и реализовала на его базе аппаратный и программный коммутаторы. Последний есть в открытом доступе. Причиной разработки собственного протокола, скорее всего, является то, что протокол OpenFlow развивается не так быстро, как этого требует рынок. От версии к версии добавляются дополнительные функции и возможности, прежде всего поддержка протоколов первого, второго, третьего и четвертого уровней. В текущей версии протокол OpenFlow может поддерживать 41 поле из заголовков протоколов разного уровня. Основной недостаток решения в том, что, если попадаются протоколы, которые не описаны в текущей спецификации OpenFlow, коммутаторы не смогут распознать их заголовки, а значит, информация не может быть использована при принятии решения. Любые расширения читаемых заголовков невозможны, а это означает, что остается ждать следующей версии OpenFlow и надеяться, что нужные компоненты будут включены в спецификацию. Кроме того, некоторые изменения спецификации OpenFlow могут потребовать изменения и аппаратной части, что усложняет добавление новых протоколов.
Второй недостаток, который Huawei хотела исправить, состоял в том, что уровень передачи данных в OpenFlow-коммутаторах является stateless, т. е. без сохранения состояния. Это означает, что коммутатор не следит за состоянием потока и не может влиять на него. В редких ситуациях эта функция доступна, когда, например, коммутатор без обращения к контроллеру может переключить один исходящий порт на другой в случае падения основного, но нет возможности генерации дополнительного потока, балансирования, создания новой записи и т. д.
Название протокола, разработанного Huawei, – Protocol Oblivious Forwarding (POF) – намекает на то, что нужно «забыть» (в смысле перестать волноваться) о существовании разных протоколов и стандартов и сделать универсальное решение, позволяющее администратору сети самому решать, какие протоколы и какой формат пакетов использовать. Huawei считает, что в классической архитектуре коммутаторы и маршрутизаторы – это «черные ящики», все их функции заложены производителем, и клиент не имеет возможности их изменить, поэтому вынужден покупать новые устройства, если возникает потребность в дополнительных функциях. OpenFlow они расценили как шаг в сторону программируемости, однако со значительными ограничениями, поэтому устройства на OpenFlow являются скорее «серыми ящиками». Huawei поставила цель разработки своего рода «белого ящика» – чистого листа для клиента, на котором он по желанию может написать все, что необходимо. POF покрывает возможности OpenFlow для обеспечения взаимодействия с решениями других производителей. Сторонние разработчики могут задействовать открытый исходный код POF в своих проектах.
Еще один протокол P4 (Programming Protocol-independent Packet Processors) был разработан сотрудниками Open Networking Research Center (исследовательский центр Стэнфордского университета) в сотрудничестве с Barefoot Networks, Google, Intel, Microsoft and Princeton University как высокоуровневый язык для программирования протоколонезависимой обработки пакетов. На примере P4 разработчики хотели показать, каким образом OpenFlow должен развиваться в будущем:
1) возможность реконфигурируемости полей: разработчики должны быть в состоянии изменить способ, которым коммутаторы обрабатывают пакеты;
2) независимость от протоколов: коммутаторы не должны быть привязаны к конкретным сетевым протоколам – недавние исследования показали возможность полного переконфигурирования устройства, помеченного RMT;
3) независимость от целей использования: разработчики должны иметь возможность описывать функциональные возможности обработки пакетов независимо от специфики базового оборудования.
Пожалуй, больше всего концепция SDN угрожает компании Cisco как производителю самых дорогих сетевых решений. Чтобы не потерять своих клиентов, компания разработала подход, названный Application Centric Infrastructure (ACI). ACI упрощает задачу изменения конфигурации сети при ее масштабировании и внедрении приложений. Приложение передает описания своих политик сетевому оборудованию, которое и следит за их соблюдением. Здесь не возникает центра подобного SDN контроллера, который ориентирован ан работу с простыми устройствами, способными выполнять ограниченный набор простых команд. Концепция ACI предполагает, что устройства вполне интеллектуальны: достаточно сказать, что надо сделать, а как это сделать, они знают. Это интерпретация Cisco концепции SDN. Конечно, данный подход требует применения оборудования Cisco. ACI – проприетарная технология, что может быть проблемой для корпоративных ЦОД, придерживающихся стратегии диверсифицированных закупок. В альтернативных подходах к SDN компоненты взаимозаменяемы.
В конце 2015 г. Cisco пообещала открыть ACI для компаний, которые предлагают сетевые сервисы уровней L4-L7 и не являются при этом партнерами Cisco. Видимо, тем самым Cisco планирует сделать следующую версию своей SDN платформы более гибкой за счет того, что позволит клиентам добавлять балансировщики нагрузки, файерволы и другие сервисы уровней L4-L7, предлагаемые компаниями, которые не являются партнерами Cisco.
Два российских разработчика и производителя телекоммуникационного и сетевого оборудования – Eltex и QTech – создают свои коммутаторы на базе чипов Broadcom. Обе компании интересуются SDN технологиями и предлагают для своих коммутаторов программное обеспечение с поддержкой OpenFlow на основе предложенной Broadcom абстракцией – OF-DPA. Компания Qtech также имеет в своей номенклатуре v-CPE – абонентское оборудование предназначено для подключения офисов, небольших учреждений, локальных сетей и других абонентов, где существуют повышенные требования к качеству сервисов. v-CPE поддерживает протокол Open Flow 1.3.x и может быть использовано в сетях SDN.
Оптимальным, с нашей точки зрения, при создании SDN-коммутатора стандарта OpenFlow является использование сетевых процессоров, которые, с одной стороны, позволяют в достаточно широком диапазоне менять поведение устройства путем его перепрограммирования, а с другой – обеспечивать высокую плотность портов, большую производительность при обработке трафика, занимать меньше, по сравнению с сервером, места в стойке, быстро работать с таблицами и памятью разного вида, в том числе ассоциативной.
Специалисты ЦПИКС полагают, что оптимальная аппаратная платформа для разработки OpenFlow коммутатора – решение на базе сетевого процессора. Данный подход позволит в будущем путем изменения программного обеспечения, исполняемого сетевым процессором, добиться получения нужного функционала в соответствии с изменениями, которые будут происходить при выходе новых версий протокола OpenFlow. Производством сетевых процессоров в настоящее время занимаются такие компании, как Huawei, Intel, EZchip. Израильская компания EZchip специализируется на выпуске данной продукции многие годы и предлагает для удобства разработки несколько оценочных платформ на базе семейств сетевых процессоров NP-4 и NP-5. Оценочная система может обеспечивать производительность до 240 Гб/с и 500 млн пакетов в секунду. Сетевой процессор NP-5, работающий с частотой 500Мгц, содержит множество оптимизированных для выполнения более узких задач процессоров (TOP).
***
Концепция SDN позволяет существенно реструктурировать затраты компании на развитие и эксплуатацию сетевой инфраструктуры. Наблюдается смещение в сторону затрат на разработку, адаптацию программного обеспечения, сокращаются затраты на оборудование и эксплуатацию. Поскольку основная масса сервисов теперь программно реализуема, снижается ROI на их создание и разработку. У компании-пользователя значительно больше вариантов решения своих задач, она менее зависима от поставщиков оборудования. Изменятся и требования к квалификации персонала. Сетевые инженеры должны будут овладеть дополнительными компетенциями, научиться новому, чтобы понимать и исправлять неисправности сетевых конфигураций в мире SDN. Однако в целом требования к их компетенциям и стажу работы будут существенно ниже CCIE. Это также следует предусмотреть заранее. На наш взгляд, наибольший выигрыш от технологий SDN получат организации, которые будут формировать стратегию перехода на SDN в самом начале формирования рынка таких решений. Именно те, кто предвидит изменения и сумеет к ним подготовиться, выиграет в конкурентной борьбе.
SDN – это данность и наступившее будущее. Фокус сместился с управления отдельными сетевыми устройствами к управлению целыми сетевыми сервисами. Продукты используются в больших компаниях, готовых к изменениям, компаниях, которые видят преимущества и связанные с этим трудности переходного момента.
