— Мы принесли вам подключение к современному миру.
— Через месяц мы вернемся с антидепресантами.
Пост «Сколько стоит SDN» собрал свою долю внимания Хабра — по приглашению sergeykalenik я теперь буду вести свой блог на хабре и в меру сил рассказывать об отечественных успехах в области SDN-технологий.
История с Nicira, о том, как меньше чем за 5 лет трое университетских преподавателя и частных инвестора смогли построить стартап стоимостью в $1,26 млрд., который, по мнению экспертов, способен сильно изменить расстановку сил на рынке сетевого оборудования и, возможно, даже стать «убийцей» Cisco (верится с трудом, но, тем не менее, такое мнение есть.)
В комментариях к посту было много обсуждений о том, что собственно из себя представляют программно-конфигурируемые сети (ПКС) и насколько все это применимо в реальности. Коротко комментарии можно разделить на следующие группы:
- ПКС не нужны, ибо и так все хорошо работает
- интересно, но непонятно что и зачем
- маркетинговый буллшит
- подход строго лабораторный, для тестов в университетах, а в практической жизни скорей всего неприменим
В общем-то, последняя точка зрения отчасти правда. Саму концепцию новой сетевой архитектуры предложили только в 2007 году в рамках диссертации одного профессора Стэнфордского университета. С тех пор, ПКС развивались преимущественно в научной лаборатории Стэнфорда и Беркли и в промышленно значимых масштабах ее еще никто не пробовал. Поэтому как «идеализировать», так «хоронить» ПКС как минимум преждевременно.
Почему в Стэнфорде и Беркли вообще взялись за попытку поменять сетевую архитектуру? Как объясняют сами авторы похода: Мартин Касадо (Martin Casado) и Ника МакКьоуна (Nick McKeown), они хотели изменить или повлиять на следующие моменты:
- сети традиционной архитектуры проприетарны, закрыты для исследований и практически любых изменений извне Оборудование разных вендоров часто между собой плохо «стыкуется»
- рост трафика в геометрической прогрессии и тезис о том, что сети нынешней архитектуры просто не смогут его «переварить» на необходимом уровнем качества
- количество протоколов и их стеков в сети
Основные сетевые протоколы в архитектуре TCP/IP были разработаны в 70-е годы на заре Интернета, когда никто не мог предсказать современные скорости и объемы передаваемых данных. В 2010 г. Эрик Шмидт говорил на конференции Techonomy: «Пять экзабайт информации создано человечеством с момента зарождения цивилизации до 2003 года, столько же сейчас создаётся каждые два дня, и скорость увеличивается…».
По прогнозам компании Cisco в ближайшие 5 лет объем трафика увеличится в 4 раза, причем мобильный трафик будет удваиваться ежегодно. К 2015 г. количество устройств в сети, будет в два раза выше, чем население планеты. Количество сетевых адресов в новом протоколе IPv6 такое, что на 1 м2 поверхности Земли приходится 6,7*1023 адресов (фактически, это количество устройств, которое потенциально могут быть подключены к сетям). Сегодня одновременно в Skype работает свыше 35 млн. пользователей, в Facebook — свыше 200 млн, каждую минуту на YouTube загружают 72 часа видео. Видео-трафик составляет более 50 % потребительского трафика и его доля будет дальше только расти. К 2015 г. трафик от беспроводных устройств превысит объем трафика от фиксированных. Наверняка, если бы сегодня существовала возможность разработать сетевые протоколы с чистого листа и с учетом всего накопленного опыта, они оказались бы абсолютно иными.
Для иллюстрации представьте что все веб-сервера были разработаны в 70-ых и остались без изменений. Это как если бы сейчас не было ни Nginx ни даже Apache, а только ISS образца 1995 года. К сожалению в области протоколов все обстоит именно так.
До недавнего времени действующая архитектура сетей развивалась по методу «ласточкиного гнезда», т.е. по мере выявления проблем к стеку протоколов TCP/IP добавлялся новый, который эту проблему решал. Например, когда появились цифровая сеть с интеграцией служб, объединяющая передачу речи, данных и изображений (ISDN) возникла проблема передачи видеотрафика. Суть проблемы можно свести к следующему: при передаче видео по сетям возникают жесткие требования к управлению качеством сервиса, поскольку необходимо динамично «пропихивать» очень высокоскоростной трафик, не допускающий задержек.
Протокол RSVP как раз решил проблему резервирования необходимых ресурсов под такой трафик и, соответственно, позволил обеспечить необходимый уровень качества услуг. Однако, как потом выяснилось, этот протокол тоже не безгрешен и имеет ряд ограничений, связанных, например, с масштабируемостью сетей.
Другой пример – протокол DHCP (dynamic host configuration protocol) поселившийся в любом домашнем роутере — протокол динамической конфигурации узла, был разработан для сетей IPv4. Протокол позволяет выделять IP-адрес на ограниченный период времени («время аренды») или до отказа клиента от адреса — в зависимости от того, что произойдет раньше. Это в какой-то мере решило проблему ограниченности IP адресов в сетях IPv4, но в результате появилась проблема другая проблема – назначение одинаковых IP адресов разному оборудованию в рамках одной сетевой инфраструктуры. На сегодня число фактически (активно) используемых протоколов более 600. И цифра далеко не конечная.
С чего начали исследователи из Стэнфорда и Беркли – они предположили, что в компьютерных сетях возможно разделить функции управления и передачи данных.
Рисунок 1. Обработка и передача данных в коммутаторе Ethernet
При передаче данных коммутатор Ethernet подает запрос к таблице коммутации (рис 1). Затем на основании полученной информации коммутационная матрица осуществляет дальнейшую обработку и передачу данных на целевой исходный порт.
В обычном коммутаторе Ethernet одновременно реализуются и управление и передача данных. Уровень управления представлен встроенным контроллером, уровень передачи данных – таблицей коммутации и коммутационной матрицей. Контроллер обладает некоторыми интеллектуальными функциями, позволяющим ему самому принимать решения о передаче данных на основе информации о структуре сети. Но непосредственно управлять принятием решения нельзя – можно лишь конфигурировать контроллер, задавая определенные наборы правил и приоритетов. Это значительно ограничивает функциональность коммутатора и всей сети. Например, организацию связей «каждый с каждым» в такой сети нельзя построить без сетевого устройства третьего уровня – маршрутизатора.
Проблему разделения уровня управления и передачей данных исследователи Стэнфорда и Беркли предложили решить в рамках подхода, получившего название программно-конфигурируемые сети (ПКС).
До OpenFlow сетевую архитектуру можно представить как телефонную связь в самом начале 20 века, когда коммутация осуществлялась вручную (Барышня, Смольный!). В принципе, сейчас администратор также вручную настраивает оборудование по заданным параметрам, и любые дальнейшие изменения осуществляются преимущественно на аппаратном уровне.
OpenFlow позволяет уйти от такого «ручного» управления сетью, что положительно сказывается на ее масштабируемости, например.
В коммутаторе OpenFlow реализован только уровень передачи данных. Вместо контроллера используется гораздо более просто устройство, задача которого состоит в принятии поступающих данных, извлечение их адресов и, если адресат есть в таблице коммутации, немедленной передачи данных коммутационной матрице. Иначе коммутатор по защищенному каналу отправляет запрос на Центральный контроллер сети OpenFlow, и на основании полученной от него информации вносит необходимый изменения в таблицу коммутации, после чего осуществляется обработка полученных данных (больше оборудование не перенастраивается руками, а перенастраивается с помочью ПО).
Центральный контроллер имеет точную информацию о структуре и топологии сети. Это позволяет оптимизировать продвижение пакетов данных, и, в частности, прокладывать связи «каждый с каждым» на уровне L2, не прибегая к IP-маршрутизации (рис. 2). Также становится возможным «коммутировать» каналы передачи данных на всем пути от источника до пункта назначения. В результате по сети передаются потоки данных, а не отдельные пакеты.
Поэтому в терминологии ПКС такая таблица коммутации получила название FlowTable (таблица потоков). У каждого контроллера своя уникальная FlowTable, эту таблицу он заполняет только на основании информации, полученной от центрального контроллера.
В сетях новой архитектуры ПКС все маршрутизаторы и коммутаторы объединяются под управлением Сетевой Операционной Системы (СОС), которая обеспечивает приложениям доступ к управлению сетью и которая постоянно отслеживает конфигурацию средств сети.
В отличие от традиционного толкования термина СОС как операционной системы интегрированной со стеком сетевых протоколов, в данном случае под СОС понимается программная система, обеспечивающая мониторинг, доступ, управление, ресурсами всей сети, а не конкретного узла. СОС формирует данные о состоянии всех ресурсов сети и обеспечивает доступ к ним для приложений управления сетью. Эти приложения управляют разными аспектами функционирования сети, типа построения топологии, принятия маршрутизирующих решений, балансировки нагрузки и т.п.
Протокол OpenFlow решает также проблему зависимости от сетевого оборудования какого-либо конкретного поставщика, поскольку ПКС(SDN) использует общие абстракции для пересылки пакетов, которые сетевая операционная система использует для управления сетевыми коммутаторами.
Можно сказать, что OpenFlow – это протокол нижнего уровня для программирования коммутаторов. ПО для сетей SDN/ПКС находится в самом начале своего развития, его в большинстве случаев предстоит только разработать. В ближайшее время разработчикам только предстоит убедиться в правильности подхода, в возможности масштабируемости сетей нового поколения, поскольку технология только-только вышла из стен лабораторий.
Но уже сейчас интерес со стороны производителей огромный. Например, Cisco добавили OpenFlow к своим коммутаторам Nexus и Catalyst 37XX, Jupiper также добавил опцию OpenFlow в JunOS SDK, а в июне этого года объявил о реализации этой технологии в линейке коммутаторов EX and MX Series. Более того, ряд производителей сетевого оборудования уже предлагают коммутаторы, которые реализуют только протокол OpenFlow, а традиционные протоколы не поддерживают: NEC, Pronto, Marvell.
В России проверкой всех заявленный характеристик Open Flow на начальном этапе будет заниматься Центр прикладных исследований компьютерных сетей. Если среди вас есть желающие тоже попробовать все своими руками, пишите на everizhnikova@arccn.ru, будем рады сотрудничеству.
Автор: everizhnikova
