Программно-конфигурируемые сети — как это работает?

Программно-конфигурируемые сети — как это работает?

— Мы принесли вам подключение к современному миру. — Через месяц мы возвратимся с антидепресантами.Пост «какое количество стоит SDN» собрал собственную долю внимания Хабра — по приглашению sergeykalenik я сейчас буду вести собственный блог на хабре и в меру сил говорить об отечественных удачах в области SDN-разработок.
Смотрите кроме этого: Как ощутить себя в чужом теле

В Японии разрабатывается программно-аппаратный комплекс, имитирующий такие эмоции, как зрение, слух, осязание и обоняние, и вестибулярные ощущения. В лаборатории Ikei Магистратуры системного дизайна при Токийском столичном университете (Япония) разрабатывается программно-аппаратный комплекс, разрешающий практически ощутить себя вторым человеком.Экспериментальный комплекс (фото DigInfo TV).

История с 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 млн, каждую 60 секунд на 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, будем рады сотрудничеству.

Случайная статья:

Почему важно не работать


Похожие статьи:

Комментирование и размещение ссылок запрещено.

Обсуждение закрыто.