[Robot_NagNews]

Материал:

В это трудно поверить несведущему человеку, но в интернете до сих пор используются протоколы, рождение которых состоялось еще в 70-е года прошлого века. Наиболее очевидный следующий технологический шаг - виртуализация. Виртуальная сеть должна работать так, словно это обычная физическая сеть, но для ее работы становится менее критичным подбор и даже месторасположение сетевого оборудования. Давайте попробуем разобраться в основах концепции SDN.

 

Полный текст

[s.lobanov]

Для тех, кому надоело поедать марктенговый булшит, который накапливается вокруг тематики SDN, рекомендую книжку http://blog.ipspace.net/2014/09/just-published-sdn-and-openflow-hype.html

 

А слушать в очередной раз "снижение capex и opex" или "снижение opex за счёт capex" это можно вечно. Сейчас практически любое новшество преподносится под этими соусами

[Nag]

Э... А где тут маркетинг вообще? Простая попытка показать "картинку" термина в примерах и ссылках, о котором и слышали-то далеко не все.

[s.lobanov]

Попытаюсь ответить развёрнуто. Во-первых, хотелось бы спросить у авторов статьи, вы лично щупали тот самый SDN? Видели ли что из себя представляет процесс поднятия SDN-сети, настройку каскадирования сервисов(одна из фишек SDN), прописывание сервисов? Понимаете ли вы сами, чем SDN отличается от классической mpls-сети и системы управления от вендора, которая может сама конфигурить железки, просто сказав ей "хочу такой-то сервис отсюда сюда"

 

Идём дальше. Например вот это

Juniper добавила поддержку OpenFlow в JunOS SDK...

 

Что это вообще даёт провайдеру или интегратору? JunOS SDK недоступен никому, кроме супер-пупер-партнёров. Собственно, много ли вы видели 3rd party приложений, работающих под JunOS? (JunOS SDK это и позволяет, но Juniper его никому(кроме очень приближённых к ним) не даёт)

 

Простое и дешевое оборудования - благодаря этому снижаются капитальные и операционные затраты (по некоторым данным, сокращение до 30%), упрощается обслуживание;

 

до 30% - ну как всегда нарисовали цифру, методики расчёта нет, исходных данных нет, проверить невозможно

 

Полная загрузка простаивающих аппаратных мощностей

 

Вот что это за булшит? Т.е. если трафика нет, чтобы на 100% загрузить "аппаратные мощности", то железки его сами начнут генерить или оно там биткойны майнит на asic-ах, добиваю утилизацию ресурсов до 100%?

 

, увеличение пропускной способности каналов за счет более рационального использования оборудования;

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

 

Я бы ещё понял фразу "более эффективная утилизация пропускной способности каналов за счёт более эффективной маршрутизации", но то что написано это какая-то ересь.

 

Ну и дальше по пунктам можно пройтись, но не буду.

 

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

 

Возьмите со склада десяток ваших SNR-S4550-24XQ-AC, запустите на них тот самый SDN, покажите что получили, чем оно лучше настройки по-старинке

[DimaM]

Если индустрия (вендоры) вложили куда-то бабки (SDN), то будьте уверены, они их отобъют.

Технологии для этого отработаны: отраслевые стандарты, армии маркетологов и "аналитиков" и т.п.

Иногда бывает, что в процессе пропихивания технологии на рынок, она при этом трансформируется,

так неудачный ATM превратился в успешный MPLS.

А иногда даже новой технологии нет, если только созданный маркетингом голем, который тем не менее со временем

начинает обрастать костями и плотью и оживать (BigData).

SDN имеет все шансы для этого, так как даже если вы его не хотите, со временем он будет в каждой железке.

Плюс он удачно дополняет тренд на виртуализацию, поэтому в Датацентрах SDN уже рулит (см. пример Google).

[zi_rus]

неудачный ATM превратился в успешный MPLS

атм был удачный, но дорогой, поэтому проиграл дешевому ethernet, а сейчас фичи из АТМ перетаскивают и натягивают на новый глобус

 

в Датацентрах SDN уже рулит

там ему и жить, там не ездят бульдозера

 

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

[Nag]

Во-первых, хотелось бы спросить у авторов статьи, вы лично щупали тот самый SDN? Видели ли что из себя представляет процесс поднятия SDN-сети, настройку каскадирования сервисов(одна из фишек SDN), прописывание сервисов?

Нет конечно. :-) У меня вообще есть подозрения, что полномасштабно его никто в России не тестировал.

По крайней мере с ЦПИКС общались, но конкретики не получили, только пару восторженных фраз. Что на самом деле там происходит - не знаю.

С другой стороны, в гугле оно работает как-то.

Отсюда и обзорный формат - ознакомительный кусок + отсылки к теоретикам + отсылки к практикам. Буллшита (кроме, разумеется, отсылочного) и восторгов по прежнему не вижу. ;-)

Если в комментах выплывут реальные пользователи - буду только рад - и постараюсь запытать на предмет написания чего-нибудь по этому поводу.

 

Что это вообще даёт провайдеру или интегратору? JunOS SDK недоступен никому, кроме супер-пупер-партнёров.

Это претензия к Джунам. :-) Хотя добавить этот момент в текст надо обязательно.

 

Если у канала пропускная способность 10G, то она не может быть 30G какой бы магией SDN не обладал.

Эту формулировку надо подправить.

 

И пожалуй, самое главное, статья не даёт понимание тем кто не в теме, зачем оно вообще нужно, что не так с классическими сетями, в каких масштабах приходит понимание того, что надо что-то менять

Ну... А вы это можете сформулировать лучше? Попробуйте - интересно.

[Navu]

Вот что это за булшит? Т.е. если трафика нет, чтобы на 100% загрузить "аппаратные мощности", то железки его сами начнут генерить или оно там биткойны майнит на asic-ах, добиваю утилизацию ресурсов до 100%?

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

[Nag]

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

Наверно это тоже надо переформулировать чуток. ;-)

[stas_k]

А иногда даже новой технологии нет, если только созданный маркетингом голем, который тем не менее со временем начинает обрастать костями и плотью и оживать (BigData).

Кости и плоть BigData существуют уже лет 50, только называлось оно по другому и до обывателя не доводилось.

Исследования ДНК, ядерная физика, синхрофазатроны, малые и большой коллайдеры генерируют BigData ежесекундно.

[DimaM]

Кости и плоть BigData существуют уже лет 50, только называлось оно по другому

 

Именно: сами задачи успешно решались много лет, а потом было придумано СЛОВО (бренд), под которое

сначала затаскивали уже существующие технологии и продавали их под новым соусом.

Т.е. поначалу ничего нового не было, а было просто СЛОВО (BigData).

Зато под это СЛОВО полились деньги, возникло множество стартапов и специализированных проектов,

пошли исследования, и в результате под этим брендом порождаются новые подходы и технологии.

И теперь спор про BigData - это будет спор про курицу и яйцо.

[s.lobanov]

Ну... А вы это можете сформулировать лучше? Попробуйте - интересно.

 

У меня тоже есть вендорские презентации по мотивам которых(частично) и написана эта статья. Перепечатывать их ещё раз? Зачем? Вы уже это сделали. Я бы мог написать про openflow, но это была бы жуткая статья с кучей строчек вида "... add-flow f1 in_port=10,dl_type=0x800,nw_src=1.1.1.1,nw_dst=2.2.2.2,actions=..."

 

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

[s.lobanov]

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

 

Juniper Logical System давно уже существует и к SDN не имеет отношения(ну и другие вендоры подтягиваются в этом плане). И я знаю реальные примеры использования этой штуки без всяких SDN и openflow.

[s.lobanov]

Отсюда и обзорный формат - ознакомительный кусок + отсылки к теоретикам + отсылки к практикам. Буллшита (кроме, разумеется, отсылочного) и восторгов по прежнему не вижу. ;-)

 

Ну т.е. сокращение расходов до 30% по капексу и опексу это тоже "коровая не моя"отсыл к булшитам?

[Nag]

Ну т.е. сокращение расходов до 30% по капексу и опексу это тоже "коровая не моя"отсыл к булшитам?

А разве это не очевидно в данном случае? Там даже точная цитата: (по некоторым данным, сокращение до 30%) :-)

[Navu]

Juniper Logical System давно уже существует и к SDN не имеет отношения(ну и другие вендоры подтягиваются в этом плане). И я знаю реальные примеры использования этой штуки без всяких SDN и openflow.

Наличие подобной возможности в Juniper автоматически превращает все аналогичные разработки в буллшит?

[stas_k]

Именно: сами задачи успешно решались много лет, а потом было придумано СЛОВО (бренд), под которое сначала затаскивали уже существующие технологии и продавали их под новым соусом.

Т.е. поначалу ничего нового не было, а было просто СЛОВО (BigData).

 

Там и сейчас из технологий НИЧЕГО НОВОГО НЕТ.

 

ключевые патенты в этих областях имеют возраст свыше 25 лет. более новые патенты в реферате содержат "берем штуку из старого патента красим в синий и включаем в розетку" или "берем штуку из старого патента красим в красный и включаем в розетку".

 

наверное в этом всё и дело, что через 20 лет формула патента становится свободной, и её можно использовать без лицензионных и авторских отчислений.

[wanderer_from]

Мои пять копеек, и я даже не дам ссылку на предыдущую статью.

 

В общем и целом, речь идет о некоторой смене парадигмы, причем, SDN это только часть, которая называется SDI - Software Defined Infrastructure, куда входит в том числе и SDN. Но там есть еще и Storage, и Server, и даже целиком Data Center. SDI (и SDN) впервую очередь присядет именно в ЦОДах, где есть реальный смысл в сложных и постоянно перестраиваемых маршрутах. И действительно это дает весьма нехилый профит на капексах и опексах. На сети операторов этот зверь придет с полной проработкой еще одного зверя - NDN. Я уже про него пытаюсь написать, но, если честно - тыковки уже реально не хватает. Это просто сеть следующего поколения, когда от коммутации каналов и коммутации пакетов будет переход к коммутации данных.

 

То есть к контенто-центричной сети...

 

Парни, кто по умнее а запулите в меня хорошей ссылкой про NDN :)

[NN----NN]

http://named-data.net/publications/techreports/

[wanderer_from]

не, это ясен-красен. Мне б понять... :)

[s.lobanov]

Это просто сеть следующего поколения, когда от коммутации каналов и коммутации пакетов будет переход к коммутации данных.

 

Очередной маркетинговый бред, вы вообще сами-то понимаете что пишите? Или только способны повторять красивые строчки из презентаций? В плане dataplane это такая же коммутация пакетов как и в обычных СПД, что сейчас всё работает по принципу "match X -> action Y". SDN это другой способ управления сетью с коммутацией пакетов, при этом никакой революции по части dataplane нет, ни в СПД, ни в СХД

[wanderer_from]

вы вообще сами-то понимаете что пишите?

сам-то понял за что споришь? Я писал про NDN. И да - там пока все очень хлывко и экспериментально. Прежде чем бросаться на амбразуру, оглянись.

[s.lobanov]

wanderer_from

ок. если про NDN, то значит мой комментарий неуместен

[sirmax]

Кто-то ОпенВСвитч в эту сторону смотрел?

Оно вроде даж как-тоработает =)

[pers123]

На самом деле, когда речь идет об SDN и openflow, то имеет смысл говорить о переходе от управления сетевым оборудованием к управлению

потоками данных в сети.

Правда задача контроля состояния оборудования никуда не исчезла и в частности это отягощает реализацию идей так красиво описанных

концептуально.