То, что именно SDN оказался в центре дискуссии по поводу будущего компьютерных сетей, по нашему мнению, оказали влияние три события:
— покупка VMware компании Nicira — первого стартапа в сфере SDN – за рекордные для отрасли $1,26 млрд.
— создание в 2011 году Open Networking Foundation – некоммерческой организации, чьей основной задачей провозглашалось популяризация нового подхода к управлению компьютерными сетями — SDN. Инициаторами выступили 6 компания – владельцы крупнейших в мире сетей — Deutsche Telekom, Facebook, Google, Microsoft, Verizon, и Yahoo. Очень быстро к консорциуму присоединились все основные производители сетевых решений, включая Cisco, Brocade, NEC, HP и тд.
— доклад Urs Holzle, старшего вице-президента Google по технической инфраструктуре, на Open Networking Summit 2012 о том, что компания использует технологии SDN.
В том же 2012 году стали пачками выходить многообещающие маркетинговые исследования о том, что рынок SDN-решений за пять лет достигнет огромных размеров, причем 2016 год почти все называли годом «массового внедрения».
Собственно, тот самый 2016 год, который должен был стать «годом внедрения», уже почти закончился и есть возможность оценить насколько сбылись прогнозы и что вообще поменялось за это время.
- Если в 2011-2012 про SDN многие вендоры и интеграторы (в России особенно) относились с огромным скепсисом и как к университетской игрушке, то к 2016 году их мнение кардинально поменялось. В 2011-2012 годах они заявляли, что все современное оборудование итак все умеет и отлично работает, то сейчас все игроки в индустрии смирились с SDN и воспринимают этот подход как наше настоящее. Тем же сервис-провайдерам нравится, что они могут управлять своим оборудованием из логического центра, нравится, что могут сами создавать сервисы и программы по управлению оборудованием и признают, что за таким подходом будущее.
- Если в 2012 году SDN позиционировали преимущественно как технологию для ЦОДов и часто даже ставили знак равенства между SDN и OpenFlow (в результате чего, кстати, появилось множество статей на тему того, что сравнивать, а тем более ставить между ними знак равенства нельзя, например, эта или эта), то сейчас сферы применения SDN значительно расширились. Во-первых, к ним добавились сети операторов связи. Главным образом, про SDN в телекоме стали серьезно думать в 2015 году, когда оператор связи AT&T изменил парадигму и фактически объявил себя софтверной компанией. К 2020 году AT&T поставил цель виртуализировать и с помощью технологий SDN контролировать более чем 75 % сети. Причем как ПО, так и железо компания планирует разрабатывать самостоятельно. Уже сейчас про SDN и NFV в сетях сервис-провайдеров говорят и пишут значительно больше, чем в своё время писали про SDN и ЦОД.
Кроме того, появились решения и кейсы SDN для корпоративных сетей — Enterprise SDN, где SDN используется в частных облаках, в сетях обработки данных, для интернет-безопасности и многого другого. В корпоративных сетях новые технологии внедряются медленнее, но некоторые приложения, такие как, например, SD-WAN (Software-Defined WAN) уже получают распространение на крупных предприятиях, а количество вариантов таких решений все время растет. Технология SDN продолжает развиваться, инженеры относятся к ней уже не так скептично, и можно с уверенностью сказать, что количество внедрений увеличится в ближайшие несколько лет.
- За прошедшие 5 лет на рынке произошло огромное количество слияний/поглощений и многообещающих инвестиций. Та самая обещанная вендоронезависимость давала надежду на появление стартапов в одной из самых сложных сфер в ИТ – сетевые технологии. Еще 15-20 лет назад диктат ИТ-гигантов Cisco, Brocade, Juniper и тд казался незыблемым. SDN обещали значительный передел рынка. Наши коллеги из NFware подсчитали, что только в 2015 году сфера SDN и NFV привлекла свыше $600 млн инвестиций.
- Все большие вендоры так или иначе завели у себя собственные линии (или платформы), которые позволят в той или иной степени программировать сеть.
Что не сбылось:
- совершенно точно 2016 год не станет годом массового внедрения. Прогнозы по развитию остались все такими же перспективными, но теперь говорят про 2020-2022 года;
- многие обещали смерть OpenFlow. По факту протокол не умер и пока является наиболее готовым к использованию в реальных сетях и есть даже список вендоров, у которых можно купить оборудование с поддержкой OpenFlow версии 1.3.4. Но плюсом к нему появились еще несколько вроде Protocol Oblivious Forwarding (POF) от Huawei или P4 (Programming Protocol-independent Packet Processors) от Open Networking Research Center (Стэнфорд). По сути OpenFlow – это пока единственная реализация SDN, которая обещает честную независимость от производителя. Да, все крупные вендоры предлагают свои решения SDN и в той или иной степени расширили возможность управления устройства в сети, но решения разных вендоров между собой все также практически не совместимы.
Что сейчас имеем:
- никто уже не спорит, что SDN необходим, а все споры сместились в сторону реализации;
- по факту сейчас уже все поняли, чего можно ожидать от SDN и в плане реализации SDN/OpenFlow на практике, и в плане появления нового оборудования, и в плане появления новых сервисов. Совершенно точно области применения SDN уже меняться не будут. Например, можно утверждать, что как за это время не появилось OpenFlow коммутаторов, так их скорей всего и не появится, поскольку пока большие вендоры не изменят производство своего оборудования, то никакого прогресса в этой сфере не произойдет. Вероятнее всего протокол OpenFlow будет медленно эволюционировать в сторону, устраивающую и вендров, и их клиентов.
- у всех вендоров абсолютно разное понимание SDN. Совершенно разные протоколы, разных подходы к реализации, то так или иначе появилось централизованное управление, есть возможность самостоятельно создавать сервисы и т.д., но нет открытости и переносимости между устройствами. Но с 2015 года все основные вендоры SDN начали активно налаживать горизонтальные связи для создания комплексных продуктов, которые хотят конечные клиенты.
По факту вместо стадии массового внедрения, мы сейчас наблюдаем стадию массового пилотирования технологии. Все большие операторы связи пристреливаются к технологии, подбирают команды, которые смогут работать с новыми технологиями, планируют перестройку бизнес-процессов. Думаем, что в ближайшие 2-3 года можно будет уже говорить о начале стадии внедрения.
Комментарии (25)
ayurtaykin
17.11.2016 23:17Так вот откуда пошла тема что SDN = openflow :)
Wiki как-то по другому на все это смотрит:
SDN was commonly associated with the OpenFlow protocol (for remote communication with network plane elements for the purpose of determining the path of network packets across network switches) since the latter's emergence in 2011. Since 2012,[1][2] however, many companies have moved away from OpenFlow, and have embraced different techniques. These include Cisco Systems' Open Network Environment and Nicira's network virtualization platform.
VitalKoshalew
18.11.2016 08:32Так откуда оптимизм-то в статье?
Как в 2012 практически ничего реально не было, только buzzword, так и в 2016 мало что появилось. Всё те же прогнозы «на следующую пятилетку».
Вы же пишете "… как за это время не появилось OpenFlow коммутаторов, так их скорей всего и не появится, поскольку пока большие вендоры не изменят производство своего оборудования, то никакого прогресса в этой сфере не произойдет." Собственно, это конец идеологии SDN на уровне аппаратуры. Если даже представить, что вендоры создадут-таки свои устройства на своём проприетарном протоколе, это будет худшее, что случилось с компьютерными сетями за десятилетия. Мы столько лет шли к стандартизации протоколов, чтобы в одночасье всё это перечеркнуть?
Была надежда на массовый SDN в средах виртуализации. Microsoft в Hyper-V 2012 и SCVMM 2012 SP1 действительно сделала поддержку SDN-over-Ethernet с инкапсуляцией пактов между серверами в NVGRE, причём без дополнительной оплаты. Затем подтянулась VMware с NSX, но уже с заградительной ценой «от $5k за процессор». Microsoft посмотрела на это, и тоже подняла цену на SDN, потребовав Windows Datacenter лицензию на всех узлах, включая шлюзы. Если до этого казалось, что вот оно — счастье SDN, то теперь во многих случаях экономический смысл просто теряется.
Вы написали про операторов, привели пример AT&T. Поправьте меня, если я не так понял, но за маркетинговой шелухой у AT&T в документах написано (в частности, вот тут хоть что-то сказано по существу):
1. Перевести-наконец (в 2015 году!) сети с ATM на Ethernet.
2. В центрах обработки данных перевести-таки (в 2015-2020 годах!) все (точнее, 75%) вычисления с выделенных серверов в частное облако. Речь идёт, я так понимаю, о процессинге, биллинге, контроллерах сотовых сетей и прикладных внутренних IT-приложениях. Для сотового и кабельного оператора это, видимо, инновация, но если сравнить с корпоративными системами, то они же на годы отстали с переходом в частное облако! Главное, это не SDN! Это просто private cloud для их серверной инфраструктуры, в том числе для централизованного контроля сети, но он в сотовых сетях и так был, в некотором роде, software-defined всегда.
3. Заменить, по возможности, железные маршрутизаторы на виртуальные машины, потому что так дешевле. Это SDN? Такой SDN (только не на виртуальных машинах, а на PC/серверах с несколькими сетевыми адаптерами) повсюду был до начала, а то и до середины 2000-х.
4. Старый добрый self-service portal для клиентов, с возможностью раз в сутки менять скорость порта. Судя по ограничению на частоту смены, поначалу техники будут принимать заявку и прописывать на оборудовании новые настройки. Потом, видимо, сделают скрипты, которые на это оборудование будут сами заходить, и настройки менять. Это SDN? По-моему, это просто централизованная система менеджмента настроек сетевого оборудования.
Если мы говорим о SDN over Ethernet/IP и о network function virtualization (NFV), то такие «SDN» были десятки лет назад, есть и будут, тем более, что теперь все сервера виртуализованы, а любой гипервизор включает в себя виртуальный коммутатор. Если же говорить о OpenFlow и прочих принципиальных заменах текущей парадигме работы сетевого оборудования, то причин для оптимизма я не вижу.
xcore78
18.11.2016 15:03+1Есть работающие продукты, использующие управление транспортом посредством openflow. Их можно пощупать и купить, если вы — заказчик с многомиллионным бюджетом. Спектр решений не очень велик, но представлены все области: энтерпрайз, датацентры, WAN.
Поддержка в оборудовании есть (J, A, N) (надо заметить, что в как достаточно дорогом — порядок десятков тысяч, — так и достаточно дешёвом — порядок тысяч), поддержка, как правило, дописывается к существующему hop-by-hop стеку, что 1) не даст возможность развернуть сеть только на openflow, делая сие мероприятие экономически неэффективным, но 2) позволить оценить эксплуатационные качества и выгоды использования в локальных условиях.
Я совершенно не знаком с термином «SDN over Ethernet», но упомянутое туннелирование (было бы хорошо упомянуть WXLAN) имеет больше отношения к intent-based networking.
Давайте определим, о каком значении термина идёт речь:
- intent-based/zero touch networking?
- NFV?
- транспорт/control plane?
VitalKoshalew
18.11.2016 20:30Я попытался проанализировать статью автора и указать, что вывод, пожалуй, противоречит тексту. От себя добавил только пример про SDN в системах виртуализации. Если ваш прогноз — OpenFlow взлетит, то тут вам нужно полемизировать с автором статьи, который считает, что не взлетит. Я не берусь делать прогнозы о его будущем.
Когда я упомянул «SDN over Ethernet» я говорил о типе нижнего уровня SDN: infrastructure (в парадигме infrastructure-control-application). Какой тип north-bound interface будет между control и application — декларативный или intent-based — в данном случае неважно, речь о нижнем уровне. С OpenFlow был шанс получить принципиально новые сети с новой топологией — то, для чего изначально создавалось понятие SDN. В случае туннелирования поверх IP (NVGRE, VXLAN) мы теряем контроль над топологией и получаем обычную Ethernet-овскую звезду с терабитами и петабитами в секунду в центре — то, от чего изначально предполагалось спасаться динамическим контролем трафика в SDN.
NFV — вообще, на мой взгляд, чистой воды buzzword. Какая разница, где мы запустим ОС для маршрутизации/контроля доступа — на железе или в виртуальной машине? Это вообще не проблема сетевиков, которые этот buzzword придумали: переводится вся серверная нагрузка в виртуальные машины, и эта нагрузка — не исключение, тут сисадмины сами разберутся. А больше ничего нового в этом buzzword нет — возвращаемся к истокам, кое-где вообще никогда не переходили на «железные» маршрутизаторы и брандмауэры.
Виртуальные коммутаторы приплетать к SDN/NFV можно только формально — они появились на десяток лет раньше, чем термин SDN, и, без изменения топологии физической сети, они так и будут просто эмулировать узел Ethernet-звезды.
Потому я и говорю, что если убрать buzzword-ы и маркетинговую шелуху, то реально нового в SDN со стороны сетевиков была перспектива OpenFlow. Если её похоронить — останется только туннелирование/VPN (с сомнительной экономической эффективностью при текущих ценах), виртуализация серверных нагрузок и эмуляция Ethernet в виртуальных коммутаторах — по существу, давно известные технологии, а хотелось бы действительно SDN.
drwatson32
22.11.2016 09:46Мне нравится Openflow именно новой топологией и возможностями операций на границах.
В идеальном мире, когда на границе стоит идеальный Openflow коммутатор, с большим TCAM и полной поддержкой Openflow 1.3.4 (со всеми non-required филдами). Прям на нем можно сделать распределенный ACL, трансляцию адресов, load balancing. Но жизнь жестока, в большинстве ASIC коммутаторов размер flow table не более 4к записей, поддержка протокола сделана на уровне required матчей и филдов. И приходится с этим жить.
Про NFV, я не согласен. Если есть необходимость новой топологии и смещение операций над траффиком на edge, то нужны датацентры ближе к этому edge, для запуска сложных сетевых функций.
На уровне федерального провайдера это боль прокидывать туннели до этих виртуалок на самом деле, а особенно если они еще и не в центре.
Посему, на мой вгляд, пока топология — гнать все в кору, а там разберемся — NFV buzzworld.
Проще поднимать и хендлить убервиртуалки, особенно есть гипервизор более менее вменяемый с миграцией, файловером и прочее.
При смене парадигмы — нет
Loxmatiymamont
18.11.2016 13:47А как обстоят дела у RunOS? Это всё ещё лабораторная игрушка или есть примеры использования в боевых сетях?
arccn
21.11.2016 14:26У RunOS есть сейчас 2 версии: коммерческая с сервисами для телекомов, которая сейчас проходит пилотирование у нескольких заказчиков, и open-source версия, у которой недавно вышел релиз 0.6.
lhog
21.11.2016 11:27+1Как мне кажется OpenFlow уже не взлетит, т.к. от былой простоты (и одновременно полной негодности из-за комбинаторного взрыва) версии 1.0 не осталось и следа. Текущая версия — монстр, поддерживающий более 50 типов заголовков, при этом далеко не факт, что в гетерогенной среде коммутаторы производителя A и B будут поддерживать необходимый общий набор типов полей.
Продукты с поддержкой OpenFlow в основном выпущены несколько лет назад, так сказать на пике ожиданий. Сейчас, как мне кажется, к-во новых продуктов с OF пойдёт на убыль. Кроме того, оказалось не так много желающих выкинуть в помойку свою архитектуру сети и произвести дорогостоящий апгрейд с целью перехода на чистую OpenFlow сеть. Говорю об этом как представитель вендора.
С другой стороны сейчас SDN стали понимать значительно более широко, чем просто стандартный API между forwarding plane коммутаторов и контроллером. В зависимости от производителя и целевой аудитории решения можно увидеть такие вещи как:
- Открытая операционная система на «голом металле» (см. Cumulus, Open Network Linux)
- Open Source API для взаимодействия с ASIC-ами или попытки написать универсальную обёртку над несколькими типами ASIC-ов (SAI, OpenNSL)
- Открытые и стандартизированные API для доступа к возможностям устройства (a-la RESTCONF, NETCONF)
- Универсальные языки описания конфигураций, транслируемые в конфигурации конкретных вендоров (например NAPALM)
- Использование существующих протоколов (с небольшими расширениями) для построения маршрутов из центральной точки управления. Segment Routing, BGP-LS и прочее
- Попытки использования статистики и аналитики для управления сетью как единой системой
В общем происходит очень много интересного, SDN в широком смысле этого слова растёт и развивается — уж больно солидные преимущества просматриваются в средне-дальней перспективе, но ставить на OF в конце 2016 года ИМХО ошибка.arccn
21.11.2016 15:03OpenFlow вышел из научной лаборатории, все другие протоколы пришли от вендоров, поэтому, скорей всего, наиболее честный SDN со всеми его обещаниями независимости от вендоров, программируемости, централизованности — это OpenFlow. Все другие протоколы развиваются нишево, под узкие задачи управления MPLS (PCEP, segment routing, BGP-LS) и поддерживаются еще реже, чем OpenFlow и, как правило, в дорогостоящих современных устройствах.
Но, мы понимаем, у OpenFlow есть целый ряд недостатков, которые не позволяют полностью удовлетворить потребности заказчиков.
Мы видим, что этот недостаток можно решить двумя способами:
- Доработка OpenFlow для поддержки функционала, необходимого нашим заказчикам;
- А для заказчиков, сети которых построены с использованием современного оборудования, поддерживающее функционал MPLS, PCEP, нужно добавить соответствующий функционал в контроллер.
По обоим направлениям мы ведем работу.lhog
21.11.2016 17:14Протокол P4 не смотрели? Он тоже из «академии». Мне понравилась простота концепции и доступность к тестированию. Не прошло и часа как я смог сделать в нём свою версию ethernet (сделал 64 битный MAC адрес) или поменять логику обработки IPv4 TTL.
Что особенно приятно API для доступа к таблицам генерируется автоматически (сравните с портянками структур из OpenFlow — прошлый век)arccn
22.11.2016 07:09конечно, смотрели и ведем соответствующие работы. Но P4 для настройки pipeline сетевого оборудования — кол-во таблиц, связи, поля и действия. OpenFlow все равно расматривается, как основной протокол управления. Подробнее прочитайте здесь.
API по работе с OpenFlow это свойство не протокола OpenFlow, а того контроллера или системы управления, которую вы используете при программировании. У нас в открытой версии контроллера как раз и идут разработки по этой тематике.
lhog
21.11.2016 23:56Кстати еще несколько вопросов. Не ёрничаю, а спрашиваю, т.к. реально хотелось бы понять:
1) Вы пишите про потребности заказчика и OF как средство их удовлетворения. Не могли бы вы привести обезличенный пример о каких потребностях идёт речь? Как вы убеждаете своих клиентов строиться на OF, а не на «стандартных» протоколах?
2) Как решается проблема управления (management) коммутаторами OpenFlow? Out of band сеть управления или как-то хитрее? Помнится, что когда я пристально изучал OpenFlow, то спецификации хранили на этот счёт гордое молчание. Проблема in-band коммуникации для канала управления ведь серьёзная, из серии «что первично: курица или яйцо». Если не совсем понятно о чём речь, то спрошу так: кто/что прописывает flow для доступа между OF-element и OF-controller при первом(первоначальном) включении коммутатора?
3) Я так понимаю ЦПИКС делает контроллер и приложения для него? В мире как известно помимо чистых OpenFlow контроллеров, которых не меньше 5, есть еще и универсальные гиганты OpenDayLight и ONOS. Почти все контроллеры (по крайней мере ядро и большинство модулей) freeware/open-source. Вопрос: в чём конкурентное преимущество контроллера ЦПИКС, кроме того, что он сделан в РФ?arccn
22.11.2016 12:45-11. Главное — это простота работы с сервисами, например, а-ля l2vpn (настройка и автоматизация управления) и интеграция со сторонними система (oss/bss и другие системы). Убеждаем обычно объяснением примеров и демонстрациями.
2. В реальной жизни практически везде нужно in-band управление через канал с данными. При этом возникает много сложностей типа отказ канала, перегрузка канала. Все эти моменты надо учитывать. Первичный набор правил на коммутаторе для inband прописывается через его консоль. Дальше уже управление и всю логику работы подхватывает контроллер.
3. Мы начали разработку контроллера (его разных версий) еще даже до OpenDaylight — делали это осознанно, изучив, как недостатки и достоинства тогда существоваших. Основное преимущество это скорость работы и маленькие задержки. Наш контроллер на C++, в отличии от используемого во всех остальных контроллера языка Java.drwatson32
22.11.2016 21:32Сорри, я не смог пройти мимо.
3.
Мы начали разработку контроллера (его разных версий) еще даже до OpenDaylight
ODL стартовал в 2013. Сейчас у него уже 7-й релиз. Вы стартовали в 2014.
Вы собираетесь выпустить хотя бы первый в обозримом будущем?
Основное преимущество это скорость работы и маленькие задержки.
.
Это очень спорное преимущество, учитывая скорость прогрузки flow коммутаторами от 2К до 12к в секунду максимум. Где можно посмотреть состав стенда для прогона тестов?
Последнее что я видел — это kernel режим, 30М fps, 55 mu-sec latency, для l2 learning.
RunOS 0.6.1. версию гоняли? Будете участвовать в баттле по ONF SDN Controller Benchmark?
Наш контроллер на C++, в отличии от используемого во всех остальных контроллера языка Java.
Какое ваше преимущество над Juniper OpenContrail?
И вопрос очень важный для меня, какое преимущество над контроллером Brain4Net, если не брать то что мы используем Java (с disruptor, affinity и продажными женщинами)? Мы ведь тоже в РФ :-)arccn
23.11.2016 14:56-11. Удивительно видеть, что посторонний человек гораздо лучше в курсе о том, что у нас происходит, чем мы сами). Открытая версия контроллера развивается по своим направлениям и отлично от коммерческой — много архитектурных решений отличаются от того, что есть в открытом доступе. Версия 1 нашего открытого контроллера появится, когда мы решим ряд алгоритмических научных проблем связанных с новой абстракцией для программирования. В этом и есть ниша и суть открытой версии контроллера. И именно этим она интересна сообществу — 70% пользователей не из России. Коммерческая версия находится на тестировании у потенциальных заказчиков. Есть протоколы тестирования, есть понятные направления развития контроллера дальше, но это уже другая история.
2. По скорости и работы и задержкам мы понимаем ту величину, которая требуется контроллеру для принятия решений. Например, время для пересчета перестроения заданного количества сервисов (от 100 до 1000 сервисов) — время от детектирования критической ситуации в сети до подготовки всех правил на отправку. Мы сравнивали с существующими версиями открытых контроллеров. Разумеется, итоговое время будет зависеть и от способности физического оборудования, но и здесь есть свои успехи при более плотной работе с производителями сетевого оборудования.
3. Juniper OpenContrail заточен на управление виртуальной инфраструктурой. Мы сосредочены на управлении физическим сетевым оборудованием.
4. К сожалению, сравнить с контроллером компании Brain4Net затруднительно в связи с отсутствием материалов в открытых источниках, а также с отсутствием информации о прохождении каких-либо тестов. Нам тоже хотелось узнать, в чем особенность вашего контроллера и почему во времена существования как минимум 4-х популярных открытых контроллеров на Java (ONOS, OpenDaylight, Floodlight, Beacon), вы начали разработку своего контроллера тоже на Java? Если вы не разрабатывали свой контроллер, а просто взяли Beacon и сделали дополнительные настройки по производительности, то тогда логика понятна. Если нет, то поясните, пожалуйста.drwatson32
23.11.2016 16:19Удивительно видеть, что посторонний человек гораздо лучше в курсе о том, что у нас происходит
Я просто посмотрел статистику github.
Например, время для пересчета перестроения заданного количества сервисов (от 100 до 1000 сервисов) — время от детектирования критической ситуации в сети до подготовки всех правил на отправку
Не, ну если у вас есть такие bottleneck тогда ясно.
Juniper OpenContrail заточен на управление виртуальной инфраструктурой. Мы сосредочены на управлении физическим сетевым оборудованием
Ок. Какие преимущества над Juniper SD-WAN тогда?
К сожалению, сравнить с контроллером компании Brain4Net затруднительно в связи с отсутствием материалов в открытых источниках, а также с отсутствием информации о прохождении каких-либо тестов.
Это подойдет?
https://www.sdxcentral.com/sdn/definitions/sdn-controllers/sdn-controllers-comprehensive-list/
Или это?
https://www.opennetworking.org/?p=2199&option=com_wordpress&Itemid=316
Если вы не разрабатывали свой контроллер, а просто взяли Beacon и сделали дополнительные настройки по производительности, то тогда логика понятна.
После такого, мне ничего не остается кроме вызова вас на битву контроллеров по версии ONF SDN Benchmarking :-)
ONF Appfest 2017.
А по факту, не, немного не так. ONOS еще не было. Floodlight только стартанул.
Мы также провели анализ существующих решений.
Только решили вести разработку на Java, а не на С++ по причинам кросс-контроллер переносимости приложений. Все таки на ODL и Floodlight уже были приложения.
По перформансу на тот момент всех лучше был Beacon.
Но по функционалу, он был как RunSDN (открытая версия).
Тупо ядро, сериализация/десериализация OpenFlow, гуя, все. Правда OFDP вместо STP.
Но поскольку Beacon и сам был научным проектом, пришлось все переписывать.
Сделали патенты на аналог segment routing в Openflow сетях, сделали MEF сервисы для контроллера, перепелили ядро, сделали кластера и оно поехало.
Я надеюсь наш маркетинг сподобится об этом написать когда-нибудь.
alex_lizard
23.11.2016 19:50Я просто посмотрел статистику github.
Опрометчиво как-то считать, что initial commit на github и начало внутренних разработок это одно и тоже) DPDK же появился раньше, чем 7 марта 2013 года — дата первых коммитов «init DPDK repository» и «first public releasev1.2.3r0» :-D
Не, ну если у вас есть такие bottleneck тогда ясно.
Не-не, у нас то как раз нет боттлнеков, написано же выше. Они есть в Java-based контроллерах, которые мы тестировали.
Это подойдет?
https://www.sdxcentral.com/sdn/definitions/sdn-controllers/sdn-controllers-comprehensive-list/
Или это?
https://www.opennetworking.org/?p=2199&option=com_wordpress&Itemid=316
Маркетинговые отписки в два предложения не подойдут )
После такого, мне ничего не остается кроме вызова вас на битву контроллеров по версии ONF SDN Benchmarking :-)
ONF Appfest 2017.
Сначала сразимся на полях Подмосковья — if you know what i mean ;)drwatson32
24.11.2016 00:11Опрометчиво как-то считать, что initial commit на github и начало внутренних разработок это одно и тоже)
Ну кто ж знает то, пока не расскажут. По разному бывает.
Не-не, у нас то как раз нет боттлнеков, написано же выше.
Good for you.
Маркетинговые отписки в два предложения не подойдут )
Ну как так то. Первая про сравнение SDN контроллеров в мире, там все есть.
Крупнейший сайт про SDN.
Вторая официальная ссылка от сообщества, результаты отправляют по запросу.
Соревнования же были :-(
Сначала сразимся на полях Подмосковья
Вот так всегда.
Что я в Подмосковье не видел, а тут Штаты, лоси, безналоговый штат.
Всю малину испортили, как бюджет утверждать?
drwatson32
22.11.2016 21:35lhog
2.
В двух словах.
OVS based коммутаторы настроенные в inband, честно лернят маки контроллеров и используют скрытую таблицу 254 для автогенерации правил в сторону контроллера и обратно на LOCAL (получаются через ovs-appctl). VLAN для inband выставляется на бридже. Все ip должны быть в одном L2 домене.
Не OVS based коммутаторы тоже работают схожим образом, таблицы только другие.
https://github.com/openvswitch/ovs/blob/master/DESIGN.rst#user-content-in-band-controllhog
23.11.2016 11:21Спасибо, интересно, в своё время читал что-то похожее то ли в исходниках OVS, то ли в коммит логах.
А как тогда решается вопрос отказоустойчивости и неизбежных в избыточносоединенённых топологиях бесконечных циркуляций BUM трафика (штормов)? Опять Spanning Tree? Хотел бы посмотреть как это всё работает в топологии из хотя бы 50 коммутаторов, организованной в несколько колец.drwatson32
23.11.2016 11:46А как тогда решается вопрос отказоустойчивости и неизбежных в избыточносоединенённых топологиях бесконечных циркуляций BUM трафика (штормов)?
В основном решается следующим образом. Первым к контроллеру подключается direct коммутатор, контроллер должен модифицировать его таблицы, чтобы он арпы от indirect коммутаторов отправлял на контроллер.
Контроллер соответственно трекает direct и indirect коммутаторы, линки между ними и т.п.
Ну то есть в отличии от out-of-band, подключение идет в 3 фазы, вместо 1.
В out-of-band — установка соединения и потом topology discover
В in-band — арп ответы и лерн, установка соединения с контроллером с direct коммутаторов, прогрузка правил, старт topology discover, ну и дальше пока подключаются indirect коммутаторы идет постоянный апдейт правил отсылки на контроллер и обратно, чтобы не допускать лупов.
Всех легче это достигается ff группами.
STP (несмотря на то, что его использует RunOS) — в Openflow сетях избыточен и вреден.
Обычно используют OFDP и OF_PORT_STATUS + ECHO_TIMEOUT.
Так как STP был придуман для работы в традиционных сетях без центрального управляющего элемента, в случае Openflow сетей, траффик по свитчам без причин не флудится, а если флудится правила должны строится таким образом, чтобы флуда избежать.
Хотел бы посмотреть как это всё работает в топологии из хотя бы 50 коммутаторов, организованной в несколько колец.
Можете попробовать сами поднять по инструкции:
https://techandtrains.com/2013/10/04/in-band-controller-with-mininet/
Она старовата, но работает.lhog
23.11.2016 16:06Еще раз большое спасибо.
Также посетил ваш сайт: вы делаете интересные вещи. Если хотя бы половина от написанного на сайте близка к коммерческой готовности, то, я бы сказал, вы находитесь во вполне себе лидирующей группе, даже по мировым меркам.drwatson32
23.11.2016 17:00Спасибо за добрые слова.
Мы готовы с точки зрения product quality, но не готовы с точки зрения operations.
Выступление на SDN Congress и MEF дало понять, что для обработки большого количества лидов, нужно сделать процессы запуска PoC и продаж более динамичными.
Мы работаем над этим, как сделаем — я с легким сердцем запилю отдельный пост.
drwatson32
22.11.2016 09:27Для меня плюс Openflow в том, что он обеспечивает реактивность изменения data plane с центрального элемента управления по анализу пакета. Остальные SDN протоколы в основном используют или P2P коммуникации, или прогрузку удаленного конфига определенного формата (для локального control plane), плюс еще ручную конфигурацию традиционного оборудования в домене, если есть.
Как альтернативу Openflow, лично я рассматриваю PCEP, Segment Routing, BGP-LS.
Но рынок Openflow устройств есть (может быть в Россию большинство не поставляется, но есть).
Выбор устройств в США уже достаточно велик, около 10 вендоров, у каждого по 3-5 моделей.
Что хочется отметить, то что провайдеры всегда хотели контролировать свое оборудование из ПО,
люди писали скрипты которые лезли на свитчи и разными костылями прописывали конфиги,
другими костылями цепляли это к биллингу. В последние 2 года стала наблюдаться тенденция к попыткам синхронизации видения сервис провайдеров, в том числе для продаж ресурсов друг друга. И мне это нравится.
На мой взгляд основная проблема в том, что софтовые коммутаторы (по типу OVS) достаточно дороги из расчета цена порта и энергопотребления, а хардварные все на asic от Броадкома или Марвелла (P4/OpenNSL/OFDPA — ты все равно лимитирован их SDK, а иногда и возможностями asic). Есть варинт еще NPU свитчей, но там вполне сравнимая цена с традиционными MPLS маршрутизаторами.
Поэтому нужно не только реализовывать контроллеры, коммутаторы, но сильно вкладываться в интеграцию с традиционными устройствами и реализацию функционала уже существующих сетей. Чтобы не просто взять и поменять всю сеть на Openflow, а менять именно участками. И эти участки должны быть дешевле при покупке, обслуживании и обеспечить какие-нибудь бизнес бенефиты. В общем должны сделать мир лучше © Silicon Valley.
Мне вообще ситуация с SDN напоминает IP телефонию на заре ее молодости.
Никто не верил, продукты Cisco хотелось просто взять и сжечь.
Сейчас от производителей традиционных АТС осталось процентов 20, а провайдеры синтегрировались и наперегонки перепродают интерконнекты.
xcore78
Спасибо за хороший обзор.
Хочется добавить:
Сетевым инженерам рекомендую ознакомиться с курсом Ника Фимстера.