Jump to content
Калькуляторы

Неоднозначность SDN

Материал:

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

 

Полный текст

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Попытаюсь ответить развёрнуто. Во-первых, хотелось бы спросить у авторов статьи, вы лично щупали тот самый 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, покажите что получили, чем оно лучше настройки по-старинке

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

 

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this