Комментарии 13
Во всём openflow, особенно в той части, где предлагают умные коммутаторы заменить на тупые с коннектором к контроллеру, есть одна драма:
вот этот тоненький secure channel, который становится единой точкой отказа для всей сети. Вместо естественным образом распределённой логики управления в режиме share-nothing/share-something, мы получаем монстра с названием share-everything. На резервирование и обеспечение надёжности которого придётся потратить колоссальные ресурсы.
Когда я щупал openflow-контроллер три года назад, он только и делал, что сегфолтился.
А это означает ещё большую драму: если у нас на кластерах работает одинаковый код, то при приходе одинаковых данных он поведёт себя одинаковым образом. Например, свернётся в корку.
Таким образом, мы, даже если обеспечим резервирование железа, получаем всё равно единую точку отказа — это код.
Просто представить себе ping of death, сносящий не забытые непатченные винды, а весь кластер контроллеров openflow в «новом модном молодёжном» дата-центре…
Я думаю, большинство спецов по сетям интуитивно это чувствуют и крайне неодобрительно относятся к идеям засунуть «всё самое важное» от коммутаторов в софтинку.
вот этот тоненький secure channel, который становится единой точкой отказа для всей сети. Вместо естественным образом распределённой логики управления в режиме share-nothing/share-something, мы получаем монстра с названием share-everything. На резервирование и обеспечение надёжности которого придётся потратить колоссальные ресурсы.
Когда я щупал openflow-контроллер три года назад, он только и делал, что сегфолтился.
А это означает ещё большую драму: если у нас на кластерах работает одинаковый код, то при приходе одинаковых данных он поведёт себя одинаковым образом. Например, свернётся в корку.
Таким образом, мы, даже если обеспечим резервирование железа, получаем всё равно единую точку отказа — это код.
Просто представить себе ping of death, сносящий не забытые непатченные винды, а весь кластер контроллеров openflow в «новом модном молодёжном» дата-центре…
Я думаю, большинство спецов по сетям интуитивно это чувствуют и крайне неодобрительно относятся к идеям засунуть «всё самое важное» от коммутаторов в софтинку.
Я думаю, большинство спецов по сетям интуитивно это чувствуют и крайне неодобрительно относятся к идеям засунуть «всё самое важное» от коммутаторов в софтинку.
Так ведь сценарий «единый control plane, сгружающий по EOBC весь FIB на несколько независимых форвардилок, каждая из которых сам принимает решения, но в случае чего пунтит пакет в RP» уже реализован в тех самых упоминавшихся в статье «Hi-End корпоративных маршрутизаторах и коммутаторах». Обычно там два RP, непрерывно синхронизирующие между собой всё что возможно. Один выдернуть — ничего страшного, через десятки миллисекунд другой подхватит работу. Теоретически.
Поднимите руки те, у кого ни разу не было полного падения шасси с резервированными супами по связанной с самими супами причине (от программного бага до аппаратной проблемы). Моя рука опущена ниже некуда — я всякое повидал. И это только сценарий полного падения. Много чего другого может пойти не так. Поэтому не принято ставить зуб на надежность работы одного шасси, даже с полным дублированием всех компонентов.
Мне кажется, слово «корпоративный»/enterprise пора забывать, т.к. масштабы и сложность сетей внутри компаний уже не дотягивает до масштабов и сложности сетей в ДЦ, чисто интернет-компаниях класса фб и т.д. То есть «энтерпрайз» давно звучит как «переусложнённое г-но, которое на реальных задачах сдувается».
Насчёт проблемы. Разваливающиеся шасси — проблема, конечно. Но SDN предлагает её раздуть до масштабов всей сети с соответствующими последствиями.
Лично мне несколько igp'шных маршрутизаторов, возможно, даже, имеющих независимые стыки до разных провайдеров, нравятся больше, чем один гигантский виртуальный шасси на несколько тысяч портов.
А SDN, фактически, хочет это шасси раздуть до размеров сетевого периметра. Так сказать, ужаснитесь.
Насчёт проблемы. Разваливающиеся шасси — проблема, конечно. Но SDN предлагает её раздуть до масштабов всей сети с соответствующими последствиями.
Лично мне несколько igp'шных маршрутизаторов, возможно, даже, имеющих независимые стыки до разных провайдеров, нравятся больше, чем один гигантский виртуальный шасси на несколько тысяч портов.
А SDN, фактически, хочет это шасси раздуть до размеров сетевого периметра. Так сказать, ужаснитесь.
То есть «энтерпрайз» давно звучит как «переусложнённое г-но, которое на реальных задачах сдувается».
Не сказал бы. Это г-но вполне успешно решает реальные задачи компании.
Но SDN предлагает её раздуть до масштабов всей сети с соответствующими последствиями.
Я о том и говорю. И страшновато, и профита не видно кроме как на бумаге (да и на бумаге тоже не все просто).
Лично мне несколько igp'шных маршрутизаторов, возможно, даже, имеющих независимые стыки до разных провайдеров, нравятся больше, чем один гигантский виртуальный шасси на несколько тысяч портов.
А помните факап cloudflare? Там всего-то был централизованный management plane, с кучей независимых роутеров по разным площадкам. И даже тут удалось благодаря багу на час положить весь сетевой периметр и полностью пропасть из интернета.
Задачи «компаний» давно уже в подмётки не годятся крупным инсталляциям в ДЦ. Просто потому, что нормальной «компании» просто не нужно прокачивать пару терабит, да ещё и за копейки.
То есть я вокруг multi-tenant бизнеса уже лет 5 кручусь, и каждый раз, когда нам показывают очередное облачное чудо, оно обычно оказывается «под нужды компаний», совершенно не готовый к суровым интернетам, где любая слабость — это повод кому-то повеселиться.
То есть я вокруг multi-tenant бизнеса уже лет 5 кручусь, и каждый раз, когда нам показывают очередное облачное чудо, оно обычно оказывается «под нужды компаний», совершенно не готовый к суровым интернетам, где любая слабость — это повод кому-то повеселиться.
Задачи «компаний» давно уже в подмётки не годятся крупным инсталляциям в ДЦ.
У «компаний» тоже есть ДЦ, иногда собственные…
А терабиты у единиц встречаются, это скорее исключение, на которое не надо ориентироваться. «Компаниям» как раз нужны вундервафли, возможно — дорогостоящие (и запросто позволяющие при правильном дизайне получить те терабиты), способные реализовать хотелки любой степени костыльности. Потому я полностью поддерживаю классическое разделение задач и железа на «ентерпрайз» и «SP», а вносить третью категорию «мегаDC» не хочу. Объемы трафика все-таки чаще всего несущественны, важен функционал, от него и отталкиваются.
Во, во, я про это и хочу сказать. Для компании важным является её маленький трафик, который обвешан фичами по самое не хочу. И она готова (в пересчёте на полосу) платить много за всякие неожиданные хотелки.
Хотелки даются не просто так — низкая производительность (в сравнении с молотящими фабриками), адская сложность конфигурирования и сопровождения.
В то же время классический SP, который «в одном месте взял, в другом отдал» ничего, кроме полосы (ну и всякого фэнсервиса в стиле mpls) не хочет.
А есть третий класс — который хочет иметь какие-то фичи (желательно поближе к индустриальным стандартам), со скоростью среды, и, главное, дешёво. Потому что этот трафик — не «святая святых внутри бизнеса», а бросовый трафик дешёвых клиентов или ввобще бесплатных посетителей, и тратить туда слишком много не хочется.
Вот у меня есть ощущение, что в этом районе некоторая дыра, которую частично джуники закрывают, но совсем не полностью.
Хотелки даются не просто так — низкая производительность (в сравнении с молотящими фабриками), адская сложность конфигурирования и сопровождения.
В то же время классический SP, который «в одном месте взял, в другом отдал» ничего, кроме полосы (ну и всякого фэнсервиса в стиле mpls) не хочет.
А есть третий класс — который хочет иметь какие-то фичи (желательно поближе к индустриальным стандартам), со скоростью среды, и, главное, дешёво. Потому что этот трафик — не «святая святых внутри бизнеса», а бросовый трафик дешёвых клиентов или ввобще бесплатных посетителей, и тратить туда слишком много не хочется.
Вот у меня есть ощущение, что в этом районе некоторая дыра, которую частично джуники закрывают, но совсем не полностью.
Хотелки даются не просто так — низкая производительность (в сравнении с молотящими фабриками)
Ну не знаю… Если отталкиваться не от попугаев, а от более-менее реальных задач, то N7K или даже cat6500 какую производительность дают, большую или маленькую? Вон у нексуса 550гб/с на слот. И фич полно. Ориентирован на крупные ЦОДы, multitenancy такой, что можно каждому клиенту выдать по собственному маленькому свитчику, в который будет включена маленькая группа портов крупного шасси.
этот трафик — не «святая святых внутри бизнеса», а бросовый трафик дешёвых клиентов или ввобще бесплатных посетителей, и тратить туда слишком много не хочется.
Но в том-то и дело, что он не менее критичен, чем в «ентерпрайзе». И, в отличие от «ентерпрайза» (я сейчас оперирую терминологией в вашем понимании), 5-минутный простой такого трафика попадет в новости и затронет огромное количество людей (а клиенты в очередной раз будут ругать глючный селектел и выбирать, куда бы сбежать). Так что требования по надежности остаются и даже увеличиваются. По функционалу — гугл производит собственное железо и пишет под него собственный софт, чтобы потом можно было хвастаться 90% утилизацией линков при низкой стоимости порта. Но гуглов мало, а «облачных» ЦОДов чуть больше, и у них, как и у гугла, не катит подход «просто вбросить побольше линковой скорости», нужна определенная гибкость в управлении трафиком. Так появляются фичи, а потом пойдут и костыли…
я уже пол-года не имею отношения к Селектелу.
Так вот, я ж снова говорю: пожелания по аптайму — есть. По какому-то скромному набору фич — есть. Но главное — гигабиты и дёшево.
Тот же шеститонник как агрегирующий — ещё ничего, а вот access до хостов — уже дорого.
Пример «каждому клиенту выдать по маленькому свитчику» — это как раз энтерпрайз подход.
Ожидаемый новый — «на каждом порту по паре тысяч тенантов с сильной изоляцией и self serving».
Так вот, я ж снова говорю: пожелания по аптайму — есть. По какому-то скромному набору фич — есть. Но главное — гигабиты и дёшево.
Тот же шеститонник как агрегирующий — ещё ничего, а вот access до хостов — уже дорого.
Пример «каждому клиенту выдать по маленькому свитчику» — это как раз энтерпрайз подход.
Ожидаемый новый — «на каждом порту по паре тысяч тенантов с сильной изоляцией и self serving».
я уже пол-года не имею отношения к Селектелу.
Знаю, это был просто пример :)
Пример «каждому клиенту выдать по маленькому свитчику» — это как раз энтерпрайз подход.
Почему? Амазон нечто подобное делает. А ентерпрайз как правило консолидирует все управление инфраструктурой в рамках одного подразделения, там не нужно такое деление.
Ожидаемый новый — «на каждом порту по паре тысяч тенантов с сильной изоляцией и self serving».
Ну это, опять же, про аплинки речь. А я скорее про аксессные порты — чтобы клиент, имеющий N серверов, мог творить с ними что пожелает, раскидывать по любым VLANам (плевать, пересекаются они с чужими или нет), вешать любые ограничения.
О, давненько я не встречал на хабре маркетингнового буллшита про SDN, целых несколько месяцев наверное :)
Ё-мое…
1) Давно автоматизировано чем угодно вплоть до MPLS TE.
2) Чушь. Есть средства автоматизации, включая оркестраторы, а L2 свитчи вообще могут иметь конфиги под копирку (под более сложные сценарии есть куча вариантов zero-touch provisioning). Даже скрипты никто не отменял. Вон я недавно смотрел один вебинар, там товарищ описал решение задачи установки где-то около тысячи свитчей на крупное мероприятие, с бардаком, с несколькими вариантами management сетей, с разными VLANами на портах. В итоге на все поголовно свитчи был залит один и тот же конфиг. После загрузки свитч с помощью EEM апплетов обзванивал окружающую сеть, выяснял, куда его воткнули, и применял соответствующую конфигурацию, и это без всякой централизации.
3) Не понял.
4) SDN ведет к эталонной проприетарности и эталонному vendor lock-in, какие сейчас недостижимы.
Это скорее не «современный» (так как этого почти ни у кого нет), а «возможно, будущий». Лет через *цать.
Про какие расходы и нагрузки вы говорите, когда на всех платформах, носящих название «свитч», включая самые маленькие и стоящие у людей дома, control plane физически отделен от data plane? Вы писали «впервые разделение появилось на high-end железе», но это не так, любой без исключения свитч имеет подобное разделение.
А вторая сеть как стоится? И она, случаем, не потребует отдельных затрат на свое сопровождение?
Так давно уже, и без SDN.
Опять же, вариантов масса. Циска вон проталкивает Trustsec&SGT, весьма эффективно покрывающий пункты 1, 4 и 5 (2 и 3 не так явно, но тоже есть варианты на нем же).
То есть ничего не изменится?
(вы ведь про «управление как management plane», верно?)
Бред.
Интересно, а чем занимаются все современные «децентрализованные» протоколы, если не этим?
STP не занимается обменом информацией о топологии сети…
Ну ладно, дело отказа от блокируемых STP линков благое. Есть бумажный TRILL и несколько боевых имплементаций похожих на него алгоритмов. Есть разные варианты MLAG. Где тут преимущество SDN?
С DV протоколами контроллер не будет видеть полную картину сети…
Так зачем SDN, если это и так уже есть?
Более-менее соглашусь. Только у нас уже полно сетевых индустриальных стандартов. Я вот так и не понял, чем еще один мне поможет…
Итого. Есть лишние точки отказа. Есть повышенная латентность в определенных ситуациях (возможно — на целые миллисекунды). Есть необходимость поддерживать аж две сети вместо одной. Есть копирование имевшегося ранее функционала. Но сможете ли вы объяснить, какой от всего этого будет профит?
Хорошо хоть что вы не стали говорить «сеть на базе Openflow дешевле» — кажется, вендоры начали понимать, что любой, хоть немного следящий за этой темой, от таких слов начнет брызгать слюной на монитор и обзывать озвучившего эту глупость всякими нехорошими словами, синонимичными слову «лжец»…
Но в сетевом окружении, как раньше, так и сейчас существуют разные трудности:
1) Статическое или ручное выделение и перераспределение сетевых ресурсов;
2) Отдельная настройка каждого сетевого устройства при большом их количестве;
3) Сложность и ресурсоемкость при внедрении и изменении сетевых политик, конфигураций, новых сервисов;
4) Многовендорность и проприетарность некоторых функций;
Ё-мое…
1) Давно автоматизировано чем угодно вплоть до MPLS TE.
2) Чушь. Есть средства автоматизации, включая оркестраторы, а L2 свитчи вообще могут иметь конфиги под копирку (под более сложные сценарии есть куча вариантов zero-touch provisioning). Даже скрипты никто не отменял. Вон я недавно смотрел один вебинар, там товарищ описал решение задачи установки где-то около тысячи свитчей на крупное мероприятие, с бардаком, с несколькими вариантами management сетей, с разными VLANами на портах. В итоге на все поголовно свитчи был залит один и тот же конфиг. После загрузки свитч с помощью EEM апплетов обзванивал окружающую сеть, выяснял, куда его воткнули, и применял соответствующую конфигурацию, и это без всякой централизации.
3) Не понял.
4) SDN ведет к эталонной проприетарности и эталонному vendor lock-in, какие сейчас недостижимы.
то современный подход в индустрии заключается в распространении такого разделения и на сети дата-центров любого размера, где фабрика становится отвечающей за связи между плоскостями передачи данных и обработки трафика.
Это скорее не «современный» (так как этого почти ни у кого нет), а «возможно, будущий». Лет через *цать.
это может привести к их неоптимальной производительности из-за возникновения накладных расходов (дополнительных нагрузок), которые могут повлиять на трафик данных.
Про какие расходы и нагрузки вы говорите, когда на всех платформах, носящих название «свитч», включая самые маленькие и стоящие у людей дома, control plane физически отделен от data plane? Вы писали «впервые разделение появилось на high-end железе», но это не так, любой без исключения свитч имеет подобное разделение.
При таком подходе имеем существование двух параллельных сетей
А вторая сеть как стоится? И она, случаем, не потребует отдельных затрат на свое сопровождение?
Операции по сетевому распределению ресурсов как для физических, так и для виртуализированных сетей Дата-Центра становятся автоматизированными.
Так давно уже, и без SDN.
Существенно снижается сложность сетевых конфигураций, например, при приведении в действие политик безопасности, качества обслуживания, маршрутизации, фильтрации или аутентификации;
Опять же, вариантов масса. Циска вон проталкивает Trustsec&SGT, весьма эффективно покрывающий пункты 1, 4 и 5 (2 и 3 не так явно, но тоже есть варианты на нем же).
Управление становится централизованным;
То есть ничего не изменится?
(вы ведь про «управление как management plane», верно?)
Существенно снижаются простои в сетевом окружении;
Бред.
Можно избежать неоптимальных путей трафика за счет вышеописанного подхода, т.к. централизованная плоскость обработки трафика может принимать решение о выборе пути, основываясь на производительности, доступности и других дополнительных параметрах на сети;
Интересно, а чем занимаются все современные «децентрализованные» протоколы, если не этим?
Отсутствует необходимость использования Spanning-Tree протокола для обмена информацией о топологии сети среди сетевых устройств;
STP не занимается обменом информацией о топологии сети…
Ну ладно, дело отказа от блокируемых STP линков благое. Есть бумажный TRILL и несколько боевых имплементаций похожих на него алгоритмов. Есть разные варианты MLAG. Где тут преимущество SDN?
С единой плоскостью обработки трафика использование алгоритмов состояния каналов связи (таких как IS-IS, основанных на алгоритме Дейкстры, как OSPF) и дистанционно-векторных алгоритмов становится лучшим выбором, т.к. обязательно, чтобы централизованный контроллер мог видеть полную картину сети, а не частичную.
С DV протоколами контроллер не будет видеть полную картину сети…
Так зачем SDN, если это и так уже есть?
Вышеописанный подход становится индустриальным стандартом и делает возможным взаимодействие в мультивендорном мире.
Более-менее соглашусь. Только у нас уже полно сетевых индустриальных стандартов. Я вот так и не понял, чем еще один мне поможет…
Итого. Есть лишние точки отказа. Есть повышенная латентность в определенных ситуациях (возможно — на целые миллисекунды). Есть необходимость поддерживать аж две сети вместо одной. Есть копирование имевшегося ранее функционала. Но сможете ли вы объяснить, какой от всего этого будет профит?
Хорошо хоть что вы не стали говорить «сеть на базе Openflow дешевле» — кажется, вендоры начали понимать, что любой, хоть немного следящий за этой темой, от таких слов начнет брызгать слюной на монитор и обзывать озвучившего эту глупость всякими нехорошими словами, синонимичными слову «лжец»…
вот этот тоненький secure channel, который становится единой точкой отказа для всей сети. Вместо естественным образом распределённой логики управления в режиме share-nothing/share-something, мы получаем монстра с названием share-everything. На резервирование и обеспечение надёжности которого придётся потратить колоссальные ресурсы.
Лучшие практики высокой доступности контроллера:
— резервирование secure channels;
— резервирование контроллера:
— кластеризация;
— резервирование NIC;
— резервирование жестких дисков, RAID;
— резервирование источников питания;
Когда я щупал openflow-контроллер три года назад, он только и делал, что сегфолтился
Три года назад работоспособные контроллеры были только у Гугла, т.к. именно с Гугла начался интерес к SDN … Но Гугл ни с кем своими наработками не делится. У других они только начинали появляться и были в зачаточном состоянии, т.е. не совершенны.
А это означает ещё большую драму: если у нас на кластерах работает одинаковый код, то при приходе одинаковых данных он поведёт себя одинаковым образом. Например, свернётся в корку.
Таким образом, мы, даже если обеспечим резервирование железа, получаем всё равно единую точку отказа — это код.
Первые релизы софта были не совершенны, но сейчас это уже рабочий продукт, который работает у многих операторов и сервис провайдеров. Открытые референсы есть.
Я думаю, большинство спецов по сетям интуитивно это чувствуют и крайне неодобрительно относятся к идеям засунуть «всё самое важное» от коммутаторов в софтинку.
В мире еще одним решением прибыло: есть выбор, или остаться на текущих технологиях и решениях или попробовать новое. Никто не говорит, что новое – это самое лучшее, попробуйте, и если вам понравится,- пользуйтесь.
Поднимите руки те, у кого ни разу не было полного падения шасси с резервированными супами по связанной с самими супами причине (от программного бага до аппаратной проблемы). Моя рука опущена ниже некуда — я всякое повидал. И это только сценарий полного падения. Много чего другого может пойти не так. Поэтому не принято ставить зуб на надежность работы одного шасси, даже с полным дублированием всех компонентов.
В случае падения SDN контроллера – все существующие связи сохраняются, а возможность добавления новых настроек будет ожидать восстановления контроллера.
Разваливающиеся шасси — проблема, конечно. Но SDN предлагает её раздуть до масштабов всей сети с соответствующими последствиями.
В случае падения SDN контроллера – все существующие связи сохраняются, а возможность добавления новых настроек будет ожидать восстановления контроллера.
А SDN, фактически, хочет это шасси раздуть до размеров сетевого периметра. Так сказать, ужаснитесь.
В этом нет ничего плохого, появляется один единый роутер, один балансировщик, один файрвол и др.сервисные аплайансы, вместо десятков девайсов в классической архитектуре, в слоеном расположении друг относительно друга.
То есть я вокруг multi-tenant бизнеса уже лет 5 кручусь, и каждый раз, когда нам показывают очередное облачное чудо, оно обычно оказывается «под нужды компаний», совершенно не готовый к суровым интернетам, где любая слабость — это повод кому-то повеселиться.
5 лет — совсем немного. Новые решения никто не навязывает, а только предлагает попробовать, хотя бы для тестировочных целей. Решение SDN – рабочее, прошедшее обкатку и успешную эксплуатацию во мгогих крупных компаниях: Deutsche Telecom, Virizon, Facebook, Yahoo, Microsoft, NTT, и др. Пробуйте, что для вас подходит, если понравится – Wellcome!
О, давненько я не встречал на хабре маркетингнового буллшита про SDN, целых несколько месяцев наверное :)
Данная статья, короткая, специально бизнес ориентированая, дающая обзор по технологии. За глубокими техническими знаниями прошу на вендорские семинары, мы их проводим, кстати регулярно.
Статическое или ручное выделение и перераспределение сетевых ресурсов;
Давно автоматизировано чем угодно вплоть до MPLS TE.
Интересно, чем вы автоматизируете развертывание виртуальных сетей под развертывание нескольких сотен виртуальных машин для Cloud приложений. А потом, когда вы или ваш клиент через месяц захотят эти VM свернуть, кто вспомнит про выделенные под это сети?
Отдельная настройка каждого сетевого устройства при большом их количестве;
Чушь. Есть средства автоматизации, включая оркестраторы, а L2 свитчи вообще могут иметь конфиги под копирку (под более сложные сценарии есть куча вариантов zero-touch provisioning). Даже скрипты никто не отменял. Вон я недавно смотрел один вебинар, там товарищ описал решение задачи установки где-то около тысячи свитчей на крупное мероприятие, с бардаком, с несколькими вариантами management сетей, с разными VLANами на портах. В итоге на все поголовно свитчи был залит один и тот же конфиг. После загрузки свитч с помощью EEM апплетов обзванивал окружающую сеть, выяснял, куда его воткнули, и применял соответствующую конфигурацию, и это без всякой централизации.
Все эти скритпы и вспомогательные программы все равно заходят на каждое устройство и прописывают новые настройки, как если бы мы руками это делали. В нашем случае подход другой.
SDN ведет к эталонной проприетарности и эталонному vendor lock-in, какие сейчас недостижимы.
Как раз наоборот, SDN ведет к объединению разрозненных кусков в единое целое.
Про какие расходы и нагрузки вы говорите, когда на всех платформах, носящих название «свитч», включая самые маленькие и стоящие у людей дома, control plane физически отделен от data plane? Вы писали «впервые разделение появилось на high-end железе», но это не так, любой без исключения свитч имеет подобное разделение.
Многие типовые сетевые устройства имеют универсальный процессор, который не может справится с большим объемом специализированных операций.
STP не занимается обменом информацией о топологии сети…
Это неверно. Учите мат.часть.
дело отказа от блокируемых STP линков благое. Есть бумажный TRILL и несколько боевых имплементаций похожих на него алгоритмов. Есть разные варианты MLAG. Где тут преимущество SDN?
Преимущество SDN – в дополнение к вышесказанному, в т.ч. в замене традиционных роутинговых протоколов (OSPF, BGP, RIP и др.) на сети.
Есть лишние точки отказа. Есть повышенная латентность в определенных ситуациях (возможно — на целые миллисекунды). Есть необходимость поддерживать аж две сети вместо одной. Есть копирование имевшегося ранее функционала. Но сможете ли вы объяснить, какой от всего этого будет профит?
Механизмы отказоустойчивости и резервирования были приведены выше. В плане латентности, времени отклика, задержек – тесты и эксплуатация показывает, что все лучше, чем на привычных сетях.
Хорошо хоть что вы не стали говорить «сеть на базе Openflow дешевле» — кажется, вендоры начали понимать, что любой, хоть немного следящий за этой темой, от таких слов начнет брызгать слюной на монитор и обзывать озвучившего эту глупость всякими нехорошими словами, синонимичными слову «лжец»…
Решения OpenFlow есть двух типов: для физических сетевых устройств, и для виртуальных.
Виртуальные решения SDN – дешевы, ориентировочно от 100 до нескольких сот USD за сокет. Лицензируются по сокетно.
Для физических устройств решения дороже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция в сетях Дата-Центров. Программно-определяемые сети SDN