Ок. Я посмотрю, остались ли у нас репорты, и приложу.
По поводу афинного окружения, тесты выполнялись на хосте, в котором через isolcpu было оставлено только одно ядро ОС, irqbalance выключен, VM и DPDK свитч на разных ядрах, все в рамках одной нумы, память тоже выделялась в рамках одной нумы.
Опрометчиво как-то считать, что initial commit на github и начало внутренних разработок это одно и тоже)
Ну кто ж знает то, пока не расскажут. По разному бывает.
Не-не, у нас то как раз нет боттлнеков, написано же выше.
Good for you.
Маркетинговые отписки в два предложения не подойдут )
Ну как так то. Первая про сравнение SDN контроллеров в мире, там все есть.
Крупнейший сайт про SDN.
Вторая официальная ссылка от сообщества, результаты отправляют по запросу.
Соревнования же были :-(
Сначала сразимся на полях Подмосковья
Вот так всегда.
Что я в Подмосковье не видел, а тут Штаты, лоси, безналоговый штат.
Всю малину испортили, как бюджет утверждать?
Спасибо за добрые слова.
Мы готовы с точки зрения product quality, но не готовы с точки зрения operations.
Выступление на SDN Congress и MEF дало понять, что для обработки большого количества лидов, нужно сделать процессы запуска PoC и продаж более динамичными.
Мы работаем над этим, как сделаем — я с легким сердцем запилю отдельный пост.
Удивительно видеть, что посторонний человек гораздо лучше в курсе о том, что у нас происходит
Я просто посмотрел статистику github.
Например, время для пересчета перестроения заданного количества сервисов (от 100 до 1000 сервисов) — время от детектирования критической ситуации в сети до подготовки всех правил на отправку
Не, ну если у вас есть такие bottleneck тогда ясно.
Juniper OpenContrail заточен на управление виртуальной инфраструктурой. Мы сосредочены на управлении физическим сетевым оборудованием
Ок. Какие преимущества над Juniper SD-WAN тогда?
К сожалению, сравнить с контроллером компании Brain4Net затруднительно в связи с отсутствием материалов в открытых источниках, а также с отсутствием информации о прохождении каких-либо тестов.
Если вы не разрабатывали свой контроллер, а просто взяли Beacon и сделали дополнительные настройки по производительности, то тогда логика понятна.
После такого, мне ничего не остается кроме вызова вас на битву контроллеров по версии ONF SDN Benchmarking :-)
ONF Appfest 2017.
А по факту, не, немного не так. ONOS еще не было. Floodlight только стартанул.
Мы также провели анализ существующих решений.
Только решили вести разработку на Java, а не на С++ по причинам кросс-контроллер переносимости приложений. Все таки на ODL и Floodlight уже были приложения.
По перформансу на тот момент всех лучше был Beacon.
Но по функционалу, он был как RunSDN (открытая версия).
Тупо ядро, сериализация/десериализация OpenFlow, гуя, все. Правда OFDP вместо STP.
Но поскольку Beacon и сам был научным проектом, пришлось все переписывать.
Сделали патенты на аналог segment routing в Openflow сетях, сделали MEF сервисы для контроллера, перепелили ядро, сделали кластера и оно поехало.
Я надеюсь наш маркетинг сподобится об этом написать когда-нибудь.
Как я написал в начале, я рассматривал с позиции написания DPDK приложения.
Основные бенефиты vmxnet3:
1) multiqueue
2) использование shared memory вместо VMexit-VMentry
Первое за счет RSS может скейлить обработку по ядрам,
второе за счет уменьшения количества VMexit экономит по 600 циклов за выход.
По тестам у vmxnet3 на 97% меньше частота VMexit-VMentry.
С точки зрения традиционных приложений, я за e1000.
А как тогда решается вопрос отказоустойчивости и неизбежных в избыточносоединенённых топологиях бесконечных циркуляций 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 коммутаторов, организованной в несколько колец.
На первом курсе я думал, что для программиста нужен определенный склад ума, умение анализировать и составлять алгоритмы.
На втором курсе, я пошел работать интерном и думал, что для программиста нужно много и долго читать Страуструпа
На четвертом курсе, я перешел инженером-разработчиком и понял, что главное засыпать под подкасты Java Posse, ставить окружение и гуглить.
Каждый год приносил мне новое понимание, что нужно программисту.
На данный момент, лично я считаю, что самые банальные советы — самые правильные.
Первый совет — постоянно развиваться и быть в курсе всех изменений в своей основной области.
Второй совет — смотреть, что тащишь с гугла.
lhog
2.
В двух словах.
OVS based коммутаторы настроенные в inband, честно лернят маки контроллеров и используют скрытую таблицу 254 для автогенерации правил в сторону контроллера и обратно на LOCAL (получаются через ovs-appctl). VLAN для inband выставляется на бридже. Все ip должны быть в одном L2 домене.
Не OVS based коммутаторы тоже работают схожим образом, таблицы только другие.
Мы начали разработку контроллера (его разных версий) еще даже до 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 и продажными женщинами)? Мы ведь тоже в РФ :-)
Мне нравится Openflow именно новой топологией и возможностями операций на границах.
В идеальном мире, когда на границе стоит идеальный Openflow коммутатор, с большим TCAM и полной поддержкой Openflow 1.3.4 (со всеми non-required филдами). Прям на нем можно сделать распределенный ACL, трансляцию адресов, load balancing. Но жизнь жестока, в большинстве ASIC коммутаторов размер flow table не более 4к записей, поддержка протокола сделана на уровне required матчей и филдов. И приходится с этим жить.
Про NFV, я не согласен. Если есть необходимость новой топологии и смещение операций над траффиком на edge, то нужны датацентры ближе к этому edge, для запуска сложных сетевых функций.
На уровне федерального провайдера это боль прокидывать туннели до этих виртуалок на самом деле, а особенно если они еще и не в центре.
Посему, на мой вгляд, пока топология — гнать все в кору, а там разберемся — NFV buzzworld.
Проще поднимать и хендлить убервиртуалки, особенно есть гипервизор более менее вменяемый с миграцией, файловером и прочее.
Для меня плюс 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 маршрутизаторами.
Мне вообще ситуация с SDN напоминает IP телефонию на заре ее молодости.
Никто не верил, продукты Cisco хотелось просто взять и сжечь.
Сейчас от производителей традиционных АТС осталось процентов 20, а провайдеры синтегрировались и наперегонки перепродают интерконнекты.
Я имею ввиду костыли, которые приходится писать в сетевых приложениях для контроллера.
Вот пишешь ты допустим обработку mpls. Все правила, которые генерит контроллер
OpenFlow 1.3 spec conforming.
На практике:
OVS — три метки максимум (меняется в коде), push mpls метки на пакет с vlan вызывает drop.
push трех меток в userspace отрабатывал, в kernel нет (пофиксили в upstream).
Pica — если dl_dst не указал и vlan — процессинг на CPU
(а если в разных таблицах actions, то вообще drop) и две метки, Intel FM — одна метка,
так как старый билд OVS.
Ну и подобные мелочи…
>>Тем не менее, фоллбекать процессинг на менеджмент энжин…
Будем фоллбекать, но не совсем так как Pica.
Сейчас просто делаем research на эту тему, нужно подтверждение наших
идей, ждем ответ вендора матриц.
>> Приятно видеть живого человека, имеющего компетенции в OVS и OpenFlow, да еще и пишущего на русском :)
Я кстати тоже приятно удивлен, что есть с кем поговорить :-)
>> Так вроде у них были реализованы группы
Да, у них был chaining, но они выпилили его году в 2014, объяснив
потенциальным readlock.
>> Трудновыполним именно фикс этого бага?
Скажу так, костыли есть, можно обойтись, но вот именно фикс,
гарантирующий работу group chaining в рамках архитектуры OVS — нетривиален.
В рамках координат моих знаний о его архитектуре, естественно.
Но если честно, то на мой взгляд OVS достаточно громоздок для baremetal
коммутаторов, и унификация под разные реализации datapath для x86
платформ тоже имеет свои минусы.
У него отличное сильное комьюнити, его используют множество проектов, но
конкретно нам надо решать наши сугубо прикладные задачи, и быстро :-(
Текущие реализации OVS и его портов типа Pica8 требуют костылей со стороны
контроллера, что повышает трудозатраты (разработчиков и инженеров) и
прозрачность кода.
>>А что за проблемы с meters и select algs?
meters — там есть pull реквест (годичной давности), когда проверял в феврале
— в develop ветке его не было.
select algs — там для select групп, раньше можно было делать select по dl_dst only.
Сейчас вроде еще есть 5-tuple hash, и он даже работал для tcp, udp flow,
но нет никакого механизма включить его для select группы в dpdk режиме.
Только правками в коде.
Оценив количество костылей, решили делать свой.
Потому что даже в случае выкладывания в открытый доступ ядра, мы останемся
владельцами проекта, в плане решений, что мерджить, а что нет.
Ну и изначально ориентируемся на легкий framework для baremetal с версией для x86
серверов. А не на виртуальный свитч, который портируют на baremetal.
Кстати да, а почему BGP а не RIFT, Яндекс же вроде участвовал в формировании требований к нему?
По поводу афинного окружения, тесты выполнялись на хосте, в котором через isolcpu было оставлено только одно ядро ОС, irqbalance выключен, VM и DPDK свитч на разных ядрах, все в рамках одной нумы, память тоже выделялась в рамках одной нумы.
Ну кто ж знает то, пока не расскажут. По разному бывает.
Good for you.
Ну как так то. Первая про сравнение SDN контроллеров в мире, там все есть.
Крупнейший сайт про SDN.
Вторая официальная ссылка от сообщества, результаты отправляют по запросу.
Соревнования же были :-(
Вот так всегда.
Что я в Подмосковье не видел, а тут Штаты, лоси, безналоговый штат.
Всю малину испортили, как бюджет утверждать?
Мы готовы с точки зрения product quality, но не готовы с точки зрения operations.
Выступление на SDN Congress и MEF дало понять, что для обработки большого количества лидов, нужно сделать процессы запуска PoC и продаж более динамичными.
Мы работаем над этим, как сделаем — я с легким сердцем запилю отдельный пост.
Я просто посмотрел статистику github.
Не, ну если у вас есть такие bottleneck тогда ясно.
Ок. Какие преимущества над Juniper SD-WAN тогда?
Это подойдет?
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.
А по факту, не, немного не так. ONOS еще не было. Floodlight только стартанул.
Мы также провели анализ существующих решений.
Только решили вести разработку на Java, а не на С++ по причинам кросс-контроллер переносимости приложений. Все таки на ODL и Floodlight уже были приложения.
По перформансу на тот момент всех лучше был Beacon.
Но по функционалу, он был как RunSDN (открытая версия).
Тупо ядро, сериализация/десериализация OpenFlow, гуя, все. Правда OFDP вместо STP.
Но поскольку Beacon и сам был научным проектом, пришлось все переписывать.
Сделали патенты на аналог segment routing в Openflow сетях, сделали MEF сервисы для контроллера, перепелили ядро, сделали кластера и оно поехало.
Я надеюсь наш маркетинг сподобится об этом написать когда-нибудь.
Основные бенефиты vmxnet3:
1) multiqueue
2) использование shared memory вместо VMexit-VMentry
Первое за счет RSS может скейлить обработку по ядрам,
второе за счет уменьшения количества VMexit экономит по 600 циклов за выход.
По тестам у vmxnet3 на 97% меньше частота VMexit-VMentry.
С точки зрения традиционных приложений, я за e1000.
Спасибо, поправил.
В основном решается следующим образом. Первым к контроллеру подключается 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 сетей, траффик по свитчам без причин не флудится, а если флудится правила должны строится таким образом, чтобы флуда избежать.
Можете попробовать сами поднять по инструкции:
https://techandtrains.com/2013/10/04/in-band-controller-with-mininet/
Она старовата, но работает.
На втором курсе, я пошел работать интерном и думал, что для программиста нужно много и долго читать Страуструпа
На четвертом курсе, я перешел инженером-разработчиком и понял, что главное засыпать под подкасты Java Posse, ставить окружение и гуглить.
Каждый год приносил мне новое понимание, что нужно программисту.
На данный момент, лично я считаю, что самые банальные советы — самые правильные.
Первый совет — постоянно развиваться и быть в курсе всех изменений в своей основной области.
Второй совет — смотреть, что тащишь с гугла.
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
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 и продажными женщинами)? Мы ведь тоже в РФ :-)
В идеальном мире, когда на границе стоит идеальный Openflow коммутатор, с большим TCAM и полной поддержкой Openflow 1.3.4 (со всеми non-required филдами). Прям на нем можно сделать распределенный ACL, трансляцию адресов, load balancing. Но жизнь жестока, в большинстве ASIC коммутаторов размер flow table не более 4к записей, поддержка протокола сделана на уровне required матчей и филдов. И приходится с этим жить.
Про NFV, я не согласен. Если есть необходимость новой топологии и смещение операций над траффиком на edge, то нужны датацентры ближе к этому edge, для запуска сложных сетевых функций.
На уровне федерального провайдера это боль прокидывать туннели до этих виртуалок на самом деле, а особенно если они еще и не в центре.
Посему, на мой вгляд, пока топология — гнать все в кору, а там разберемся — NFV buzzworld.
Проще поднимать и хендлить убервиртуалки, особенно есть гипервизор более менее вменяемый с миграцией, файловером и прочее.
При смене парадигмы — нет
Как альтернативу 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, а провайдеры синтегрировались и наперегонки перепродают интерконнекты.
Я имею ввиду костыли, которые приходится писать в сетевых приложениях для контроллера.
Вот пишешь ты допустим обработку mpls. Все правила, которые генерит контроллер
OpenFlow 1.3 spec conforming.
На практике:
OVS — три метки максимум (меняется в коде), push mpls метки на пакет с vlan вызывает drop.
push трех меток в userspace отрабатывал, в kernel нет (пофиксили в upstream).
Pica — если dl_dst не указал и vlan — процессинг на CPU
(а если в разных таблицах actions, то вообще drop) и две метки, Intel FM — одна метка,
так как старый билд OVS.
Ну и подобные мелочи…
>>Тем не менее, фоллбекать процессинг на менеджмент энжин…
Будем фоллбекать, но не совсем так как Pica.
Сейчас просто делаем research на эту тему, нужно подтверждение наших
идей, ждем ответ вендора матриц.
Я кстати тоже приятно удивлен, что есть с кем поговорить :-)
>> Так вроде у них были реализованы группы
Да, у них был chaining, но они выпилили его году в 2014, объяснив
потенциальным readlock.
>> Трудновыполним именно фикс этого бага?
Скажу так, костыли есть, можно обойтись, но вот именно фикс,
гарантирующий работу group chaining в рамках архитектуры OVS — нетривиален.
В рамках координат моих знаний о его архитектуре, естественно.
Но если честно, то на мой взгляд OVS достаточно громоздок для baremetal
коммутаторов, и унификация под разные реализации datapath для x86
платформ тоже имеет свои минусы.
У него отличное сильное комьюнити, его используют множество проектов, но
конкретно нам надо решать наши сугубо прикладные задачи, и быстро :-(
Текущие реализации OVS и его портов типа Pica8 требуют костылей со стороны
контроллера, что повышает трудозатраты (разработчиков и инженеров) и
прозрачность кода.
>>А что за проблемы с meters и select algs?
meters — там есть pull реквест (годичной давности), когда проверял в феврале
— в develop ветке его не было.
select algs — там для select групп, раньше можно было делать select по dl_dst only.
Сейчас вроде еще есть 5-tuple hash, и он даже работал для tcp, udp flow,
но нет никакого механизма включить его для select группы в dpdk режиме.
Только правками в коде.
Оценив количество костылей, решили делать свой.
Потому что даже в случае выкладывания в открытый доступ ядра, мы останемся
владельцами проекта, в плане решений, что мерджить, а что нет.
Ну и изначально ориентируемся на легкий framework для baremetal с версией для x86
серверов. А не на виртуальный свитч, который портируют на baremetal.