Comments 27
Спасибо за хороший обзор.
Хочется добавить:
Сетевым инженерам рекомендую ознакомиться с курсом Ника Фимстера.
Хочется добавить:
- SDN — не панацея от vendor-lock (впрочем, я плохо понимаю ужас зависимости от производителя),
- «SDN» — это такое же размытое понятие, как «VPN»: спросите 5 человек, что это такое/зачем нужно, получите 5 разных ответов. Например, intent-driven networking и использование OpenFlow не подразумевают наличие друг друга.
Сетевым инженерам рекомендую ознакомиться с курсом Ника Фимстера.
Так вот откуда пошла тема что 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.
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.
Так откуда оптимизм-то в статье?
Как в 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 и прочих принципиальных заменах текущей парадигме работы сетевого оборудования, то причин для оптимизма я не вижу.
Как в 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 и прочих принципиальных заменах текущей парадигме работы сетевого оборудования, то причин для оптимизма я не вижу.
Есть работающие продукты, использующие управление транспортом посредством openflow. Их можно пощупать и купить, если вы — заказчик с многомиллионным бюджетом. Спектр решений не очень велик, но представлены все области: энтерпрайз, датацентры, WAN.
Поддержка в оборудовании есть (J, A, N) (надо заметить, что в как достаточно дорогом — порядок десятков тысяч, — так и достаточно дешёвом — порядок тысяч), поддержка, как правило, дописывается к существующему hop-by-hop стеку, что 1) не даст возможность развернуть сеть только на openflow, делая сие мероприятие экономически неэффективным, но 2) позволить оценить эксплуатационные качества и выгоды использования в локальных условиях.
Я совершенно не знаком с термином «SDN over Ethernet», но упомянутое туннелирование (было бы хорошо упомянуть WXLAN) имеет больше отношения к intent-based networking.
Давайте определим, о каком значении термина идёт речь:
Поддержка в оборудовании есть (J, A, N) (надо заметить, что в как достаточно дорогом — порядок десятков тысяч, — так и достаточно дешёвом — порядок тысяч), поддержка, как правило, дописывается к существующему hop-by-hop стеку, что 1) не даст возможность развернуть сеть только на openflow, делая сие мероприятие экономически неэффективным, но 2) позволить оценить эксплуатационные качества и выгоды использования в локальных условиях.
Я совершенно не знаком с термином «SDN over Ethernet», но упомянутое туннелирование (было бы хорошо упомянуть WXLAN) имеет больше отношения к intent-based networking.
Давайте определим, о каком значении термина идёт речь:
- intent-based/zero touch networking?
- NFV?
- транспорт/control plane?
Я попытался проанализировать статью автора и указать, что вывод, пожалуй, противоречит тексту. От себя добавил только пример про 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.
Когда я упомянул «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.
Мне нравится Openflow именно новой топологией и возможностями операций на границах.
В идеальном мире, когда на границе стоит идеальный Openflow коммутатор, с большим TCAM и полной поддержкой Openflow 1.3.4 (со всеми non-required филдами). Прям на нем можно сделать распределенный ACL, трансляцию адресов, load balancing. Но жизнь жестока, в большинстве ASIC коммутаторов размер flow table не более 4к записей, поддержка протокола сделана на уровне required матчей и филдов. И приходится с этим жить.
Про NFV, я не согласен. Если есть необходимость новой топологии и смещение операций над траффиком на edge, то нужны датацентры ближе к этому edge, для запуска сложных сетевых функций.
На уровне федерального провайдера это боль прокидывать туннели до этих виртуалок на самом деле, а особенно если они еще и не в центре.
Посему, на мой вгляд, пока топология — гнать все в кору, а там разберемся — NFV buzzworld.
Проще поднимать и хендлить убервиртуалки, особенно есть гипервизор более менее вменяемый с миграцией, файловером и прочее.
При смене парадигмы — нет
В идеальном мире, когда на границе стоит идеальный Openflow коммутатор, с большим TCAM и полной поддержкой Openflow 1.3.4 (со всеми non-required филдами). Прям на нем можно сделать распределенный ACL, трансляцию адресов, load balancing. Но жизнь жестока, в большинстве ASIC коммутаторов размер flow table не более 4к записей, поддержка протокола сделана на уровне required матчей и филдов. И приходится с этим жить.
Про NFV, я не согласен. Если есть необходимость новой топологии и смещение операций над траффиком на edge, то нужны датацентры ближе к этому edge, для запуска сложных сетевых функций.
На уровне федерального провайдера это боль прокидывать туннели до этих виртуалок на самом деле, а особенно если они еще и не в центре.
Посему, на мой вгляд, пока топология — гнать все в кору, а там разберемся — NFV buzzworld.
Проще поднимать и хендлить убервиртуалки, особенно есть гипервизор более менее вменяемый с миграцией, файловером и прочее.
При смене парадигмы — нет
OpenFlow уже взлетел :) Не дошел до массового рынка, где ему, возможно, появляться рановато в силу специфики оборудования/технологий и инерции сознания.
Не совсем понял вас про новую топологию. Вы имеете в виду возможности гибкого управления потоками (включая произвольный xCMP)?
SDN это оверлей, вы зависите от физической топологии. Я бы очень рамочно сравнил с iBGP в ядре: редко у кого логическая топология повторяет физическую (например, квадрат из 4 маршутизаторов и 6 сессий). Хотите больше физически разнесенных путей — строите линки. Так и с OpenFlow: чем меньше физической централизации, тем 1) больше возможностей для оптимизации логических путей, 2) сложнее этим управлять вручную, 3) осмысленнее внедрение «центрального мозга».
Попробуйте перевести ядро сети на OpenFlow, И напишите книгу-инструкцию. Должно получиться здорово!
Не совсем понял вас про новую топологию. Вы имеете в виду возможности гибкого управления потоками (включая произвольный xCMP)?
SDN это оверлей, вы зависите от физической топологии. Я бы очень рамочно сравнил с iBGP в ядре: редко у кого логическая топология повторяет физическую (например, квадрат из 4 маршутизаторов и 6 сессий). Хотите больше физически разнесенных путей — строите линки. Так и с OpenFlow: чем меньше физической централизации, тем 1) больше возможностей для оптимизации логических путей, 2) сложнее этим управлять вручную, 3) осмысленнее внедрение «центрального мозга».
Попробуйте перевести ядро сети на OpenFlow, И напишите книгу-инструкцию. Должно получиться здорово!
А как обстоят дела у RunOS? Это всё ещё лабораторная игрушка или есть примеры использования в боевых сетях?
У RunOS есть сейчас 2 версии: коммерческая с сервисами для телекомов, которая сейчас проходит пилотирование у нескольких заказчиков, и open-source версия, у которой недавно вышел релиз 0.6.
Как мне кажется OpenFlow уже не взлетит, т.к. от былой простоты (и одновременно полной негодности из-за комбинаторного взрыва) версии 1.0 не осталось и следа. Текущая версия — монстр, поддерживающий более 50 типов заголовков, при этом далеко не факт, что в гетерогенной среде коммутаторы производителя A и B будут поддерживать необходимый общий набор типов полей.
Продукты с поддержкой OpenFlow в основном выпущены несколько лет назад, так сказать на пике ожиданий. Сейчас, как мне кажется, к-во новых продуктов с OF пойдёт на убыль. Кроме того, оказалось не так много желающих выкинуть в помойку свою архитектуру сети и произвести дорогостоящий апгрейд с целью перехода на чистую OpenFlow сеть. Говорю об этом как представитель вендора.
С другой стороны сейчас SDN стали понимать значительно более широко, чем просто стандартный API между forwarding plane коммутаторов и контроллером. В зависимости от производителя и целевой аудитории решения можно увидеть такие вещи как:
В общем происходит очень много интересного, SDN в широком смысле этого слова растёт и развивается — уж больно солидные преимущества просматриваются в средне-дальней перспективе, но ставить на OF в конце 2016 года ИМХО ошибка.
Продукты с поддержкой 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 года ИМХО ошибка.
OpenFlow вышел из научной лаборатории, все другие протоколы пришли от вендоров, поэтому, скорей всего, наиболее честный SDN со всеми его обещаниями независимости от вендоров, программируемости, централизованности — это OpenFlow. Все другие протоколы развиваются нишево, под узкие задачи управления MPLS (PCEP, segment routing, BGP-LS) и поддерживаются еще реже, чем OpenFlow и, как правило, в дорогостоящих современных устройствах.
Но, мы понимаем, у OpenFlow есть целый ряд недостатков, которые не позволяют полностью удовлетворить потребности заказчиков.
Мы видим, что этот недостаток можно решить двумя способами:
По обоим направлениям мы ведем работу.
Но, мы понимаем, у OpenFlow есть целый ряд недостатков, которые не позволяют полностью удовлетворить потребности заказчиков.
Мы видим, что этот недостаток можно решить двумя способами:
- Доработка OpenFlow для поддержки функционала, необходимого нашим заказчикам;
- А для заказчиков, сети которых построены с использованием современного оборудования, поддерживающее функционал MPLS, PCEP, нужно добавить соответствующий функционал в контроллер.
По обоим направлениям мы ведем работу.
Протокол P4 не смотрели? Он тоже из «академии». Мне понравилась простота концепции и доступность к тестированию. Не прошло и часа как я смог сделать в нём свою версию ethernet (сделал 64 битный MAC адрес) или поменять логику обработки IPv4 TTL.
Что особенно приятно API для доступа к таблицам генерируется автоматически (сравните с портянками структур из OpenFlow — прошлый век)
Что особенно приятно API для доступа к таблицам генерируется автоматически (сравните с портянками структур из OpenFlow — прошлый век)
конечно, смотрели и ведем соответствующие работы. Но P4 для настройки pipeline сетевого оборудования — кол-во таблиц, связи, поля и действия. OpenFlow все равно расматривается, как основной протокол управления. Подробнее прочитайте здесь.
API по работе с OpenFlow это свойство не протокола OpenFlow, а того контроллера или системы управления, которую вы используете при программировании. У нас в открытой версии контроллера как раз и идут разработки по этой тематике.
API по работе с OpenFlow это свойство не протокола OpenFlow, а того контроллера или системы управления, которую вы используете при программировании. У нас в открытой версии контроллера как раз и идут разработки по этой тематике.
Кстати еще несколько вопросов. Не ёрничаю, а спрашиваю, т.к. реально хотелось бы понять:
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. Вопрос: в чём конкурентное преимущество контроллера ЦПИКС, кроме того, что он сделан в РФ?
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. Вопрос: в чём конкурентное преимущество контроллера ЦПИКС, кроме того, что он сделан в РФ?
1. Главное — это простота работы с сервисами, например, а-ля l2vpn (настройка и автоматизация управления) и интеграция со сторонними система (oss/bss и другие системы). Убеждаем обычно объяснением примеров и демонстрациями.
2. В реальной жизни практически везде нужно in-band управление через канал с данными. При этом возникает много сложностей типа отказ канала, перегрузка канала. Все эти моменты надо учитывать. Первичный набор правил на коммутаторе для inband прописывается через его консоль. Дальше уже управление и всю логику работы подхватывает контроллер.
3. Мы начали разработку контроллера (его разных версий) еще даже до OpenDaylight — делали это осознанно, изучив, как недостатки и достоинства тогда существоваших. Основное преимущество это скорость работы и маленькие задержки. Наш контроллер на C++, в отличии от используемого во всех остальных контроллера языка Java.
2. В реальной жизни практически везде нужно in-band управление через канал с данными. При этом возникает много сложностей типа отказ канала, перегрузка канала. Все эти моменты надо учитывать. Первичный набор правил на коммутаторе для inband прописывается через его консоль. Дальше уже управление и всю логику работы подхватывает контроллер.
3. Мы начали разработку контроллера (его разных версий) еще даже до OpenDaylight — делали это осознанно, изучив, как недостатки и достоинства тогда существоваших. Основное преимущество это скорость работы и маленькие задержки. Наш контроллер на C++, в отличии от используемого во всех остальных контроллера языка Java.
Сорри, я не смог пройти мимо.
3.
ODL стартовал в 2013. Сейчас у него уже 7-й релиз. Вы стартовали в 2014.
Вы собираетесь выпустить хотя бы первый в обозримом будущем?
Это очень спорное преимущество, учитывая скорость прогрузки flow коммутаторами от 2К до 12к в секунду максимум. Где можно посмотреть состав стенда для прогона тестов?
Последнее что я видел — это kernel режим, 30М fps, 55 mu-sec latency, для l2 learning.
RunOS 0.6.1. версию гоняли? Будете участвовать в баттле по ONF SDN Controller Benchmark?
Какое ваше преимущество над Juniper OpenContrail?
И вопрос очень важный для меня, какое преимущество над контроллером Brain4Net, если не брать то что мы используем Java (с disruptor, affinity и продажными женщинами)? Мы ведь тоже в РФ :-)
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 и продажными женщинами)? Мы ведь тоже в РФ :-)
1. Удивительно видеть, что посторонний человек гораздо лучше в курсе о том, что у нас происходит, чем мы сами). Открытая версия контроллера развивается по своим направлениям и отлично от коммерческой — много архитектурных решений отличаются от того, что есть в открытом доступе. Версия 1 нашего открытого контроллера появится, когда мы решим ряд алгоритмических научных проблем связанных с новой абстракцией для программирования. В этом и есть ниша и суть открытой версии контроллера. И именно этим она интересна сообществу — 70% пользователей не из России. Коммерческая версия находится на тестировании у потенциальных заказчиков. Есть протоколы тестирования, есть понятные направления развития контроллера дальше, но это уже другая история.
2. По скорости и работы и задержкам мы понимаем ту величину, которая требуется контроллеру для принятия решений. Например, время для пересчета перестроения заданного количества сервисов (от 100 до 1000 сервисов) — время от детектирования критической ситуации в сети до подготовки всех правил на отправку. Мы сравнивали с существующими версиями открытых контроллеров. Разумеется, итоговое время будет зависеть и от способности физического оборудования, но и здесь есть свои успехи при более плотной работе с производителями сетевого оборудования.
3. Juniper OpenContrail заточен на управление виртуальной инфраструктурой. Мы сосредочены на управлении физическим сетевым оборудованием.
4. К сожалению, сравнить с контроллером компании Brain4Net затруднительно в связи с отсутствием материалов в открытых источниках, а также с отсутствием информации о прохождении каких-либо тестов. Нам тоже хотелось узнать, в чем особенность вашего контроллера и почему во времена существования как минимум 4-х популярных открытых контроллеров на Java (ONOS, OpenDaylight, Floodlight, Beacon), вы начали разработку своего контроллера тоже на Java? Если вы не разрабатывали свой контроллер, а просто взяли Beacon и сделали дополнительные настройки по производительности, то тогда логика понятна. Если нет, то поясните, пожалуйста.
2. По скорости и работы и задержкам мы понимаем ту величину, которая требуется контроллеру для принятия решений. Например, время для пересчета перестроения заданного количества сервисов (от 100 до 1000 сервисов) — время от детектирования критической ситуации в сети до подготовки всех правил на отправку. Мы сравнивали с существующими версиями открытых контроллеров. Разумеется, итоговое время будет зависеть и от способности физического оборудования, но и здесь есть свои успехи при более плотной работе с производителями сетевого оборудования.
3. Juniper OpenContrail заточен на управление виртуальной инфраструктурой. Мы сосредочены на управлении физическим сетевым оборудованием.
4. К сожалению, сравнить с контроллером компании Brain4Net затруднительно в связи с отсутствием материалов в открытых источниках, а также с отсутствием информации о прохождении каких-либо тестов. Нам тоже хотелось узнать, в чем особенность вашего контроллера и почему во времена существования как минимум 4-х популярных открытых контроллеров на Java (ONOS, OpenDaylight, Floodlight, Beacon), вы начали разработку своего контроллера тоже на Java? Если вы не разрабатывали свой контроллер, а просто взяли Beacon и сделали дополнительные настройки по производительности, то тогда логика понятна. Если нет, то поясните, пожалуйста.
Удивительно видеть, что посторонний человек гораздо лучше в курсе о том, что у нас происходит
Я просто посмотрел статистику 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 сервисы для контроллера, перепелили ядро, сделали кластера и оно поехало.
Я надеюсь наш маркетинг сподобится об этом написать когда-нибудь.
Я просто посмотрел статистику 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 ;)
Опрометчиво как-то считать, что initial commit на github и начало внутренних разработок это одно и тоже)
Ну кто ж знает то, пока не расскажут. По разному бывает.
Не-не, у нас то как раз нет боттлнеков, написано же выше.
Good for you.
Маркетинговые отписки в два предложения не подойдут )
Ну как так то. Первая про сравнение SDN контроллеров в мире, там все есть.
Крупнейший сайт про SDN.
Вторая официальная ссылка от сообщества, результаты отправляют по запросу.
Соревнования же были :-(
Сначала сразимся на полях Подмосковья
Вот так всегда.
Что я в Подмосковье не видел, а тут Штаты, лоси, безналоговый штат.
Всю малину испортили, как бюджет утверждать?
lhog
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-control
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-control
Спасибо, интересно, в своё время читал что-то похожее то ли в исходниках OVS, то ли в коммит логах.
А как тогда решается вопрос отказоустойчивости и неизбежных в избыточносоединенённых топологиях бесконечных циркуляций BUM трафика (штормов)? Опять Spanning Tree? Хотел бы посмотреть как это всё работает в топологии из хотя бы 50 коммутаторов, организованной в несколько колец.
А как тогда решается вопрос отказоустойчивости и неизбежных в избыточносоединенённых топологиях бесконечных циркуляций BUM трафика (штормов)? Опять Spanning Tree? Хотел бы посмотреть как это всё работает в топологии из хотя бы 50 коммутаторов, организованной в несколько колец.
А как тогда решается вопрос отказоустойчивости и неизбежных в избыточносоединенённых топологиях бесконечных циркуляций 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/
Она старовата, но работает.
Еще раз большое спасибо.
Также посетил ваш сайт: вы делаете интересные вещи. Если хотя бы половина от написанного на сайте близка к коммерческой готовности, то, я бы сказал, вы находитесь во вполне себе лидирующей группе, даже по мировым меркам.
Также посетил ваш сайт: вы делаете интересные вещи. Если хотя бы половина от написанного на сайте близка к коммерческой готовности, то, я бы сказал, вы находитесь во вполне себе лидирующей группе, даже по мировым меркам.
Спасибо за добрые слова.
Мы готовы с точки зрения product quality, но не готовы с точки зрения operations.
Выступление на SDN Congress и MEF дало понять, что для обработки большого количества лидов, нужно сделать процессы запуска PoC и продаж более динамичными.
Мы работаем над этим, как сделаем — я с легким сердцем запилю отдельный пост.
Мы готовы с точки зрения product quality, но не готовы с точки зрения operations.
Выступление на SDN Congress и MEF дало понять, что для обработки большого количества лидов, нужно сделать процессы запуска PoC и продаж более динамичными.
Мы работаем над этим, как сделаем — я с легким сердцем запилю отдельный пост.
2) почему возникает проблема курица-яйцо? shared fate для управления/данных в этом конкретном случае оправдано: фактически это выбор между консистентностью с потерей узла и потенциальной неконсистентностью. Впрочем, никто не мешает построить отдельно сбоку надежный OOB сегмент.
Для меня плюс 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, а провайдеры синтегрировались и наперегонки перепродают интерконнекты.
Как альтернативу 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, а провайдеры синтегрировались и наперегонки перепродают интерконнекты.
Sign up to leave a comment.
SDN: изменения концепции за 5 лет