OpenFlow в операторских сетях: маркетинговый бред или?

[Macil]

Недавно бегло тестировал SRN-CPE

К сожалению, пример неудачный. Железо старое и больше ориентированное на fastpath между PPPoE с натом и Wi-Fi, т.е. блобы, блобы и блобы, и древние как говно мамонта ядра.

 

Как я понимаю, планируется выпуск девайса на MT7621, а это уже совсем другие характеристики, хотя и не bleeding-edge.

 

Самая главная проблема в том что большинство функционала типа того же IGMP снупинга практически не тестируется. Могут быть недоработки и в линуксе, может получиться так что нужный функционал вообще не управляется софтом.

 

Это я все к тому, что настоящий головняк в ISP начинается за "последней милей", когда какое то абонентское барахло не справляется с нагрузкой, а виноват провайдер. И как решать это все пока не очень понятно.

Очень даже понятно. Заканчивать извращения типа NDA. Поощрять опен-сорс разработку, и через это налаживать связи с *непосредственными* клиентами (а не с теми кто покупает железяки). В линуксе, например, есть такая штука как DSA (https://www.kernel.org/doc/Documentation/networking/dsa/). Существует, кстати, давно. Потихоньку налаживается взаимодействие между DSA (т.е. реальными свитчами) и switchdev (экспериментальной инфраструктурой для девайсов с поддержкой аппаратного бриджинга, https://www.kernel.org/doc/Documentation/networking/switchdev.txt). Но это все буквально вот-вот. И реального оборудования фактически нет.

 

Другой проблемой, является позиция Linux Foundation по поводу аппаратного оффлоадинга NAT, PPPoE и прочих "fastpath": «Этого дерьма в ядре не будет». С этой позицией нельзя не согласиться. Более того, в ядро не принимают кривой код. Поэтому, производителям приходится поддерживать свои поделки самостоятельно. Отсюда и весьма и весьма протухшие ядра.

 

Сейчас есть две позитивных тенденции. Во-первых, взят курс на white-box. Пусть пока только в области свитчей для ЦОД. Это приведёт к образованию определённой экосистемы в ядре, которой могут воспользоваться и производители SOHO решений. Во-вторых, MIPS (который, к слову, жутко тормозил прогресс в последнее время) заменятеся на n-ядерный ARM. А учитывая последние достижения интела на поприще встраиваемых решений, чем чёрт не шутит, может быть будут ставить и интелы. Рост производительности сделает бессмысленным аппаратный оффлоадинг NAT (как бывало уже не раз).

 

И в завершение, в очередной раз поднимаю вопрос технического ценза в телекоме. Как я понимаю, чтобы даже сделать 100 мегабит приходится сталкиваться с определёнными трудностями?

[nuclearcat]

Другой проблемой, является позиция Linux Foundation по поводу аппаратного оффлоадинга NAT, PPPoE и прочих "fastpath": «Этого дерьма в ядре не будет». С этой позицией нельзя не согласиться. Более того, в ядро не принимают кривой код. Поэтому, производителям приходится поддерживать свои поделки самостоятельно. Отсюда и весьма и весьма протухшие ядра.

Вообще-то fastpath и аппаратный оффлоадинг - совершенно разные вещи. Насколько я помню, аппаратный NAT в роутерах - небольшой TCAM. И он очень быстрый в железе, и крайне тормознутый в ядре.

 

Сейчас есть две позитивных тенденции. Во-первых, взят курс на white-box. Пусть пока только в области свитчей для ЦОД. Это приведёт к образованию определённой экосистемы в ядре, которой могут воспользоваться и производители SOHO решений. Во-вторых, MIPS (который, к слову, жутко тормозил прогресс в последнее время) заменятеся на n-ядерный ARM. А учитывая последние достижения интела на поприще встраиваемых решений, чем чёрт не шутит, может быть будут ставить и интелы. Рост производительности сделает бессмысленным аппаратный оффлоадинг NAT (как бывало уже не раз).

На самых современных интелях еще кое-как приемлимой цены (2к за каждый проц) - судя по всему в лимит упрется около 20гиг. А железки могут больше.

[Умник]

nuclearcat, все значительно лучше - http://www.6wind.com/products/6wind-turbo-router/

[nuclearcat]

Это тот же fastpath, к тому же не бесплатный.

[Умник]

nuclearcat, это софтовый fastpath, реализованный на x86_64. Да, не бесплатный.

[nuclearcat]

nuclearcat, это софтовый fastpath, реализованный на x86_64. Да, не бесплатный.

И не факт, что там нет бинарных блобов.

Ну, можно сочинить на DPDK NAT, но это уже не совсем Линукс.

[Умник]

Это тенденция. Если что-то нужно делать очень быстро - делают kernel bypass и решают все проблемы в userspace. Если смущает проприетарщина, то посмотрите в сторону openfastpath: реализация стека IP под opendataplane, который есть и для Intel DPDK (odp-dpdk). Пока до production quality очень далеко, но горизонт виден.

[nuclearcat]

Спасибо за инфу, да, похоже по другому никак. Надо будет поэкспериментировать, а то я перевалил за 10гиг, и непонятно, что делать дальше.

[Macil]

Это тенденция. Если что-то нужно делать очень быстро - делают kernel bypass и решают все проблемы в userspace.

... и с щенячьей радостью напарываются на всю массу проблем, которые пришлось решать за последние 25 лет.

 

Если смущает проприетарщина, то посмотрите в сторону openfastpath: реализация стека IP под opendataplane

 

Судя по диаграммам, упоротые инженеры очень сильно пытались доказать своим упоротым продакт менеджерам «у нас не линукс, у нас не линукс», хотя и те и другие страдают терминальной стадией линуксофилии. Глупо. Архитектура ничем не отличается от выставления девайса с набором ioctl в юзерспейс, другого способа взаимодействия разработчики, видимо, не знают. А то что в таком случае вся тяжесть реализации ложится на юзерспейс... Дык! Мы сделаем УниверасальныйАПИ пыщ-пыщь 2.0e special edition! И больше не будем жрать кактус в одиночку. Ведь раньше что? Почему я злой был? Просто у меня SDN не было... А теперь, мои волосы станут мягкими и шелковистыми.

 

Вот если бы инженерам хватило крепости яиц (ну и квалификации) сделать это под гипервизором, хотя бы под XeN, вот это было бы *действительно* круто. А если бы сделали бы под OKL4 было бы *нереально* круто.

 

Про попытки «реализации» отдельного IP-стека я скромно промолчу, чтобы не засорять тему чёрной матершиной.

 

Короче говоря, очередная проприетарная поделка (лицензия на исходники тут никакой роли не играет), которая через некоторое время загнётся. В ядро она включена не будет никогда, просто потому что никто и никогда не сможет доказать необходимость ещё одной подсистемы. Тем более, в ядре уже есть Open vSwitch, shwitchdev и DSA.

 

Если корпорации и дальше хотят тешить своё эго (читай транжирить деньги инвесторов), то пусть обращают свой взор на OpenBSD или разработки NICTA.

[Ivan_83]

Речь про эту модель? :) Он и тогда был дороже, а потом подорожал еще чуток, а потом рубль рухнул. :(

Да, про него.

 

К сожалению, пример неудачный. Железо старое и больше ориентированное на fastpath между PPPoE с натом и Wi-Fi, т.е. блобы, блобы и блобы, и древние как говно мамонта ядра.

Там сфстудио всё перепилил практически, и hw_nat пашет с практически всеми оффлоадингами.

[SpheriX]

Если кому интересно, 375-я армада 192kpps без NAT, фрейм 64 байта. Чисто на софте.

[Macil]

Если кому интересно, 375-я армада 192kpps без NAT, фрейм 64 байта. Чисто на софте.

Угу, и марвелловские свитчи поддерживаются из коробки.

[Macil]

Ещё к вопросу о железе: http://semiaccurate.com/2016/01/14/amd-launches-the-opteron-a1100-series-of-64-bit-arm-cpus-for-servers/

 

8 армов, 2 10G езернета... 150 баксов.

[Macil]

P.S. И вот ещё в дополнение к A1100 http://www.nextplatform.com/2016/01/15/clever-ethernet-switching-rises-from-calxeda-arm-ashes/

[SpheriX]

8 армов, 2 10G езернета... 150 баксов.

Бгг. Марвеловский кирквуд тк71 47kpps, хотя 2 дырки под гигабитную сеть.

[Macil]

Бгг. Марвеловский кирквуд тк71 47kpps

Извини, не очень понял причём тут Kirkwood.

[SpheriX]

Бгг. Марвеловский кирквуд тк71 47kpps

Извини, не очень понял причём тут Kirkwood.

Тк71 - семейство кирквудов.

[wanderer_from]

Хороший бложек-стандалоун про SDN на русском.Так и называется - https://sdnblog.ru

 

Рекомендую.

 

Например, короткая и понятная статья "4 причины низкой стоимости White-box коммутаторов"

[xcme]

Сторонники White-box коммутаторов могут сказать, что традиционная модель разработки коммутаторов (со специализированными ASIC и интегрированным набором сетевого функционала) изжила себя и вскоре будет заменена на новую с использованием White-box коммутаторов, более низкую по стоимости.

 

Да, стоимость White-box коммутатора значительно ниже эквивалентного по производительности и портовой емкости брендированного коммутатора. Однако, наиболее важным потенциальным преимуществом White-box коммутаторов является снижение операционных затрат на его эксплуатацию. Эту концепцию можно сформулировать так:

 

Сетевое устройство должно быть схоже по сложности эксплуатации с обычным сервером. Таким, чтобы инженер ИТ-департамента без глубоких знаний в области сетевых технологий мог установить, настроить оборудование и в дальнейшем поддерживать сетевую инфраструктуру.

Все это очень напоминает подход Saab95 - сущности поверх сущностей поверх еще других сущностей и т.д., а ASIC - это "устаревшая технология" ©.

[wanderer_from]

сущности поверх сущностей поверх еще других сущностей

такова окружающая реальность, увы. Мироустройство очень сложно и продолжает усложняться :)

 

Кроме лингвистических придирок, есть еще аргументы?

[Macil]

Например, короткая и понятная статья "4 причины низкой стоимости White-box коммутаторов"

Низкая стоимость коммутаторов обусловлена прежде всего тем, что компании-вендоры работают с более низкой маржой.

 

Это кстати, один из самых больших рисков SDN: глобальная остановка инноваций на годы вперёд. Высокая маржа вендоров-мироедов уходит ведь не только на элитных бл@й и особняки руководства, а и на весьма нетривиальные НИОКР.

 

HP и Dell спят и видят как погнать Циску из дата-центров, и сполна расплатиться за десятилетия унижений. Поэтому, могут себе позволить поработать в «ноль» или даже в лёгкий убыток.

 

Важной вехой будет выход white-box из категории ЦОД в свитчи уровня предприятия, а там и до телекома уже рукой подать.

[micho]

Сетевое устройство должно быть схоже по сложности эксплуатации с обычным сервером. Таким, чтобы инженер ИТ-департамента без глубоких знаний в области сетевых технологий мог установить, настроить оборудование и в дальнейшем поддерживать сетевую инфраструктуру.

а что, обычные серверы в эксплуатации намного проще свичей/роутеров? Ню-ню.

[ChargeSet]

Не, это просто еще один микротик. Таким образом вендор как бы исключает техподдержку из своих обязанностей

[Ivan_83]

Важной вехой будет выход white-box из категории ЦОД в свитчи уровня предприятия, а там и до телекома уже рукой подать.

Многим предприятиям хватает и тупарей за 500 руб/шт собранных гирляндой, а возится с управляемым некому и незачем.

Так, для примера: одна небольшая IT контора, в сети видно 50-60 хостов (меньше половины - рабочие места, остальное железки), с огромным трудом удалось убедить взять управляемый свич. Один. На два отдела сразу. Остальное так и будет на мыльницах.

Это ИТ контора, и не вебмастера какие то, а полный набор хардкора.

[Macil]

Многим предприятиям хватает.

У многих предприятий вообще нет штатного администратора. Даже на аутсорсе. Они прекрасно научились побираться на поприще ИТ-сервиса... И по-своему счастливы в своей неадекватности. Не помогают даже щелчки по носу типа «затроянили машину и увели со счёта деньги». Это ни о чём не говорит.

 

Как только предприятие начинает участвовать в госзакупках, то градус неадеквата сразу же падает: немедленно находятся деньги и на администрирование, и на сетевую инфраструктуру, и на ИБ/ОИБ, и даже на СБ. Но тенденция уже прошла: остались только самые неадекватные неадекваты, либо существующие в неком «заповеднике», либо никому нафиг не нужные. И те и другие в ближайшее время сдохнут.