Comments 98
И как же движутся разработки ПКС у нас?
Я честно позвал Верижникову отвечать, обещал что ее здесь заплюсуют и она сама сможет посты на хабр писать — сейчас подтянеться напишет все из первых рук. На сколько я знаю, они в своем центре занимаются разработкой OpenFlow стандартов и продвинулись довольно далеко — кроме гранта сколково у них есть и такие специалисты как Dr. Carolyn Turbyfill — бывший деректор сетевых сервисов в Sun и PGP.
Но вот до какой стадии они продвинулись в парктическом плане мне самому интересно — я даже надеюсь как-нибудь их навестить и сделать репортаж, а то странно что у нас под боком один из мировых центров разработки будущих стандартов интернета, а о нем информации с гулькин нос.
Но вот до какой стадии они продвинулись в парктическом плане мне самому интересно — я даже надеюсь как-нибудь их навестить и сделать репортаж, а то странно что у нас под боком один из мировых центров разработки будущих стандартов интернета, а о нем информации с гулькин нос.
Раньше исследованиями ПКС занимались на факультете Вычислительной математики и кибернетики МГУ под руководством проф. Р.Л. Смелянского. Сейчас есть отдельный Центр прикладных исследований компьютерных сетей, который будет вести разработки в области ПКС-сетей, кстати, в очень плотном сотрудничестве со Стэнфордом и Беркли и частности с Ником и Скоттом.
К сожалению, вынужден отметить, что совершенно неинформативный ответ, за исключением громких названий и имен.
Центр прикладных исследований фактически начал работать с конца мая этого года, поэтому о больших результатах говорить как минимум рано. Инициатор проекта – венчурный инвестор Александр Галицкий, Almaz Venture Partner.
Направления исследований Центра:
— Разработка ПКС-моделей, методов, технологий и решений-прототипов для использования в корпоративных сетях, ЦОДах (включая SAN) а также беспроводных сетях.
— Экспериментальное подтверждение заявленных характеристик Open Flow – решений, разработанных в университетах Стэнфорда и Беркли;
— Создание математических моделей и обоснование методов, используемых для разработки приложений в ПКС-сетях;
— Создание инструментальных средств для разработки и отладки приложений для работы в ПКС сетях;
— Разработка прототипа сетевой операционной системы с открытым кодом для управления ПКС сетями, в том числе — прототип ОС, поддерживающей Open Flow транзакции;
— Создание программных средств для виртуализации и слайсинга ПКС-сетей, для измерения и балансировки нагрузки в Центре Обработки Данных (ЦОД), включая SAN;
— Разработка методов и средств стыковки ПКС-сетей с сетями традиционной архитектуры;
— Разработка прототипа Open Flow коммутатора с оптимизированной архитектурой;
— Разработка методов и средств обеспечения безопасности ПКС-сетей.
С сентября у нас будет и железо, на котором можно будет проводить эксперименты. Сейчас мы находимся в стадии формирования штата разработчиков и исследователей (нам очень нужны люди).
Есть запланированные результаты исследований, если кому интересно, могу отдельно рассказать, но, думаю, рассуждать о них пока преждевременно. Совершенно точно мы будет делать сегменты ПКС-сетей в вузах-партнерах (сейчас это МГУ и ИТМО).
Извините, если очень официально написала
Направления исследований Центра:
— Разработка ПКС-моделей, методов, технологий и решений-прототипов для использования в корпоративных сетях, ЦОДах (включая SAN) а также беспроводных сетях.
— Экспериментальное подтверждение заявленных характеристик Open Flow – решений, разработанных в университетах Стэнфорда и Беркли;
— Создание математических моделей и обоснование методов, используемых для разработки приложений в ПКС-сетях;
— Создание инструментальных средств для разработки и отладки приложений для работы в ПКС сетях;
— Разработка прототипа сетевой операционной системы с открытым кодом для управления ПКС сетями, в том числе — прототип ОС, поддерживающей Open Flow транзакции;
— Создание программных средств для виртуализации и слайсинга ПКС-сетей, для измерения и балансировки нагрузки в Центре Обработки Данных (ЦОД), включая SAN;
— Разработка методов и средств стыковки ПКС-сетей с сетями традиционной архитектуры;
— Разработка прототипа Open Flow коммутатора с оптимизированной архитектурой;
— Разработка методов и средств обеспечения безопасности ПКС-сетей.
С сентября у нас будет и железо, на котором можно будет проводить эксперименты. Сейчас мы находимся в стадии формирования штата разработчиков и исследователей (нам очень нужны люди).
Есть запланированные результаты исследований, если кому интересно, могу отдельно рассказать, но, думаю, рассуждать о них пока преждевременно. Совершенно точно мы будет делать сегменты ПКС-сетей в вузах-партнерах (сейчас это МГУ и ИТМО).
Извините, если очень официально написала
Я честно позвал Верижникову отвечать, обещал что ее здесь заплюсуют и она сама сможет посты на хабр писать — сейчас подтянеться напишет все из первых рук
ну тогда передайте что на один + у нее стало больше и мы ждем ее ответов ;)
Читал и не понял, чё порты в свичах отменяют? Или ios на свичах уже не софт или же я на своём тупом hp 2650 смогу получить конфетку ака cisco 3750?
скорее речь идет о передаче трафика в облачных инфраструктурах.
Скорее, происходит привычный процесс разделения железа и софта, который уже прошёл у модемов и многих других девайсов. В перспективе, как я понял — да, это должно дать возможность на «тупом» оборудовании получить плюшки «умных» девайсов.
для HP 2650 нету (пока?) поддержки OpenFlow вроде бы
Порты не отменят, зато ими можно будет управлять с внешнего контроллера и для всей сети в целом. У той же Cisco ios закрытая и управлять ей можно только при помощи инструментов Cisco.
Из hp 2650 конфетку не сделаешь, свич должен поддерживать режим OpenFlow. У hp такие свичи начинаются от 35ХХ
Из hp 2650 конфетку не сделаешь, свич должен поддерживать режим OpenFlow. У hp такие свичи начинаются от 35ХХ
Видимо, будет внедерна технология VXLAN, более подробно с понятными роликами смотреть тут
В Cisco nexus вроде уже полгода есть. Что делает компания за милиард из описания совсем не понятно.
VXLAN уже есть в Nexus 1000V.
А делают они то, что сетями управлять можно программно и быстро. Представьте, что Вы создаёте и удаляете сети примерно с той же лёгкостью что и ВМ. Вот примерно в этом суть.
А делают они то, что сетями управлять можно программно и быстро. Представьте, что Вы создаёте и удаляете сети примерно с той же лёгкостью что и ВМ. Вот примерно в этом суть.
Представьте, что Вы создаёте и удаляете сети примерно с той же лёгкостью что и ВМ.
На эту тему есть множество решений, подразумевающих центральный оркестратор. Да, давно есть варианты вида «если виртуалка мигрируется с хоста А на хост Б, на хосте А не остается никого в ее VLANе, а на хосте Б этого VLANа нет, то убираем VLAN с транков в сторону А и добавляем его на транках в сторону Б». Для этого не нужен SDN. Создавать VLANы? Умоляю — любой скрипт на баше сможет с этим справиться.
а точно миллиард наличными? Можете дать ссылку, где про наличные говорится?
На официальном сайте VMware в релизе есть фраза «VMware will acquire Nicira for approximately $1.05 billion in cash» ссылка: www.vmware.com/company/news/releases/vmw-nicira-07-23-12.html
Также интересно отметить, что сегодня Oracle объявила о покупке Xsigo — конкуренте и аналоге Nicira.
Вроде несколько компаний думают о покупке BigSwitch — тоже конкурент Nicira, только он появился позднее
BigSwitch находится в «теневом» режиме. Пока они публично ничего не представили, поэтому и разговоров особых нету.
Ben Horowitz в этом интервью объяснил почему они выбрали Nicira, а не BigSwitch www.businessinsider.com/ben-horowitz-explains-why-tiny-startup-nicira-was-worth-126-billion-to-vmware-2012-7#ixzz21cxpTBlk И тоже нет поводов сомневаться в его аргументах
У IBM (BNT) вроде тоже есть разработки в этом направлении.
Ситуация следующая: есть вполне приличные коммутаторы (программные и аппаратные), поддерживающие openflow. С контроллерами по большому счёту полный швах. Я слышал, кто-то начал пилить контроллер на эрланге — надеюсь, у них получится.
Однако, за пределами openflow существует масса сложных моментов (например, кто будет коммутировать сеть между коммутаторами и контроллерами?), да и рискнуть доверить сервису, слушающему на https работу всей сети дата-центра рисковать не хочется…
Однако, за пределами openflow существует масса сложных моментов (например, кто будет коммутировать сеть между коммутаторами и контроллерами?), да и рискнуть доверить сервису, слушающему на https работу всей сети дата-центра рисковать не хочется…
Пока еще рано говорить о серьезных индустриальных решениях в области ПКС, самой разработке всего 5 лет. Можно сказать, что она только выходит из лабораторий, поэтому «белых пятен» много.Фактически ПКС в промышленных масштабах еще никто не пробовал.
Но то, что практически все крупных вендоры так или иначе начали делать оборудование и ПО под ПКС-сети (кроме Cisco свичи с поддержкой режима OpenFlow делает HP, Brocade, Juniper, Extreme Networks …, у Marvel, NEC и Pronto есть OpenFlow-only коммутаторы), плюс в эту тему влез еще и Google c Yahoo и ряд крупных провайдеров AT&T, NTT говорит о том, что индустрия на будущее считает ПКС очень перспективной и «денежной» технологий. Думаю, что в ближайшие 2-3 года все станет понятно
Но то, что практически все крупных вендоры так или иначе начали делать оборудование и ПО под ПКС-сети (кроме Cisco свичи с поддержкой режима OpenFlow делает HP, Brocade, Juniper, Extreme Networks …, у Marvel, NEC и Pronto есть OpenFlow-only коммутаторы), плюс в эту тему влез еще и Google c Yahoo и ряд крупных провайдеров AT&T, NTT говорит о том, что индустрия на будущее считает ПКС очень перспективной и «денежной» технологий. Думаю, что в ближайшие 2-3 года все станет понятно
Я ж и говорю — сделать коммутатор ума особого не надо (я имею в виду, прикрутить во внутрь openflow).
А вот написать robust контроллер — это и есть самая большая драма. Потому что тут критическими являются одновременно и надёжность (чуть ниже подробнее про это), и latency ответа, и готовность к дурацкому взбрыку флуда на порте (каждый новый flow на испекцию, читай, готовый dos через какой-нибудь 10G коммутатор).
Относительно надёжности. openflow подразумевает, что если от контроллера пришёл таймаут, то флоу либо дропаются, либо обрабатываются default-правилом.
Вроде ок, если вы с помощью openflow бродкасты режете. А если делается приватный вилан для очень важного сервера? default — это неуправляемый коммутатор. Схватил контроллер OOM, или там сегфолт (который, кстати, даже эрлангеры могут иногда наблюдать, ибо там снизу всё равно голая сишечка), и что? Вилан наружу? Запрашивай кто хочешь что хочешь?
А если класть по неответу контроллера, так это прямой путь к single point. Который надо кластеризовывать, потом ещё крутить сверху, потом ещё и ещё…
Так что всё не так уж просто, как кажется. И доверять вот так вот с бухты-барахты связность всей сети какому-то тупому бинарнику я бы не рискнул. Даже если бинарник кластеризован, код-то один. от того, что все узлы кластера синхронно поделят на ноль (или уйдут в дедлок) легче никому не станет.
А вот написать robust контроллер — это и есть самая большая драма. Потому что тут критическими являются одновременно и надёжность (чуть ниже подробнее про это), и latency ответа, и готовность к дурацкому взбрыку флуда на порте (каждый новый flow на испекцию, читай, готовый dos через какой-нибудь 10G коммутатор).
Относительно надёжности. openflow подразумевает, что если от контроллера пришёл таймаут, то флоу либо дропаются, либо обрабатываются default-правилом.
Вроде ок, если вы с помощью openflow бродкасты режете. А если делается приватный вилан для очень важного сервера? default — это неуправляемый коммутатор. Схватил контроллер OOM, или там сегфолт (который, кстати, даже эрлангеры могут иногда наблюдать, ибо там снизу всё равно голая сишечка), и что? Вилан наружу? Запрашивай кто хочешь что хочешь?
А если класть по неответу контроллера, так это прямой путь к single point. Который надо кластеризовывать, потом ещё крутить сверху, потом ещё и ещё…
Так что всё не так уж просто, как кажется. И доверять вот так вот с бухты-барахты связность всей сети какому-то тупому бинарнику я бы не рискнул. Даже если бинарник кластеризован, код-то один. от того, что все узлы кластера синхронно поделят на ноль (или уйдут в дедлок) легче никому не станет.
По сути это просто удобная для ДЦ система управления сетью, которая работает со свитчами/роутерами через openflow. Я правильно понял?
Да, все верно
Не совсем так. Не «работает со свичами», а выносит их логику с коммутатора на сервер. То есть чтобы коммутатор делал вилан, STP и прочие клёвые штуки, теперь нужен будет сервер. Лёг сервер — нет сети.
Из всего описания я понял, что эта технология пока годна только для грамотного распила бабла. Для галочки в условиях тендера.
Я на текущий момент слобо себе представляю логику stp вне свича. Неужели на каждый flow эта технология лезет на контроллер?
Я на текущий момент слобо себе представляю логику stp вне свича. Неужели на каждый flow эта технология лезет на контроллер?
Это зависит от того, как flow будет определён контроллером. Если там будут сплошные звёзды — то нет, один флоу покроет все виды трафика.
Нужно это в первую очередь для построения виртуальных сетей, заходящих вовнутрь виртуалки. Мы, например, до сих пор используем олдскульные acl'ы для антиспуфинга в первую очередь потому, что нет приличного контроллера. Так бы уже давно всё было на openflow.
Нужно это в первую очередь для построения виртуальных сетей, заходящих вовнутрь виртуалки. Мы, например, до сих пор используем олдскульные acl'ы для антиспуфинга в первую очередь потому, что нет приличного контроллера. Так бы уже давно всё было на openflow.
Я на текущий момент слобо себе представляю логику stp вне свича
В пределах облака SDN STP не требуется, контроллер сам обеспечит безкольцевую сеть между безмозглыми свитчами. А вот на стыке с традицонной сетью — очень даже. И тут вроде как полная печалька…
вобщем технология для тех кто знает зачем >1024 влана?
На самом деле, SDN запросто может отменить понятия «VLAN». Создать правило «если в порт 1 пришел пакет от адреса из 10.0.1.0/24 до адреса из 10.0.1.0/24, то выплюнуть его в тот порт, где видится получатель, или на следующий свитч в сторону получателя». 802.1q тут абсолютно не нужен.
Ну а по поводу ">1024 влана" — у меня есть серьезнейшие сомнения в том, что SDN в текущем виде сможет масштабироваться до требуемых значений…
Ну а по поводу ">1024 влана" — у меня есть серьезнейшие сомнения в том, что SDN в текущем виде сможет масштабироваться до требуемых значений…
Да это похоже модно стало: control plane выносить на отдельную железку.
На большом уровне абстракции, он прав. Если постараться коротко описать что такое OpenFlow получится именно так
А для полноты понимания можно хоть один примерчик flow на пальцах?
Амазоновский VPC?
Амазоновский VPC?
Выше есть ролик про vxlan. Посмотрите, это сродние вещи.
Вот здесь Ник очень понятно все рассказывает www.youtube.com/watch?v=c9-K5O_qYgA&list=UUHo2uqQqpmE_Cg5b4qiUpUg&index=102&feature=plcp
всё красиво
Хочу увидеть 4 работающих продукта(сервер, свич, рутер, контроллер) с поддержкой всего этого на столе для лабы
Хочу увидеть 4 работающих продукта(сервер, свич, рутер, контроллер) с поддержкой всего этого на столе для лабы
Контроллер пока не могу обещать, но остальные три сможете попробовать осенью. Как приедет оборудование и стенды, я напишу
Собственно, я уже больше года занимаюсь этим направлением (даже статью на хабр когда-то писал про это) и наша компания к этому учебному году предложит для университетов готовый продукт для лабораторных работ, все в одном флаконе, и сервер, и свич, и мануалы, и исходники. Так что пощупать живьем — сколько угодно!
>Так выглядит миллиард наличными
Так выглядит туалетная бумага
Так выглядит туалетная бумага
Маркетоидный булщит. Пару профессоров наконец то предложили API(ну или некую прослойку управления с потугой на универсальность) для коммутаторов, производители поддержали, ну или вид сделали. Все.
Т.е. вот все-все производители одновременно притворились, что им это интересно?
Да, только не притворились, реально заинтересованы. Только cisco тут реальный конкурент, опять же — это технология для бооольших ЦОД, но не так интересна для СМБ. Второе — это повсеместные облака. А облако типа IaaS это автоматизация всего чего можно.
Я тоже думаю, что вендоры не будут вкладывать в нечто просто для отвода глаз, тем более в таких объемах
Это модно. На этом можно стрясти лишних денег. Особо мощных объемов нет, есть лишь кучки исследователей и фактически существующая лишь в powerpoint технология с массой непоняток.
По мне, полностью вынимать мозги из шасси коммутатора — безумие. Должно быть какое-то гибридное решение. В общем и целом, существующие технологии работают хорошо, действительно хорошо. Они за десятилетия вылизаны до блеска. Возможно, им не хватает некоей гибкости, но это не повод полностью отбрасывать «старье».
Под «старые технологии» понимается L2 от STP до TRILL, L3 от OSPF до BGP, нечто между ними под названием MPLS с разными вкусными плюшками вроде VPN и TE, и еще по мелочи. Это ведь действительно классные протоколы (ну кроме STP).
По мне, полностью вынимать мозги из шасси коммутатора — безумие. Должно быть какое-то гибридное решение. В общем и целом, существующие технологии работают хорошо, действительно хорошо. Они за десятилетия вылизаны до блеска. Возможно, им не хватает некоей гибкости, но это не повод полностью отбрасывать «старье».
Под «старые технологии» понимается L2 от STP до TRILL, L3 от OSPF до BGP, нечто между ними под названием MPLS с разными вкусными плюшками вроде VPN и TE, и еще по мелочи. Это ведь действительно классные протоколы (ну кроме STP).
Булщит да, но только потому что ни Вы ни я не видели живой продукт. Я вот помню как на гипервизоры криво и косо смотрели, а сейчас ничего, привыкли все :)
они предложили разделить уровень управления и передачи данных. В современных сетях эти функции совмещены
Да ни фига подобного, если мы говорим об L3 коммутаторах. Там ведь все то же самое. «Мозги» программируют логику, которая и передает пакеты. SDN лишь еще дальше разносит одно от другого, с соответствующими недостатками.
В теории SDN — это круто (можно вкратце описать его как правило вида «если в порт 1 прилетел пакет с .1q тегом 10 и адресом получателя из 10.0.1.0/24, то заменить тег .1q на 20 и выплюнуть из порта 2» или что-то около того). Теоретически — абсолютная гибкость в управлении трафиком, теоретически — легкая балансировка трафика без задействования отдельной железки и так далее. На практике, у SDN есть две колоссальные беды.
1) Транспорт от контроллера до коммутаторов. Что, строить out-of-band management сеть? Некрасиво как-то.
2) Стыковка с традицонной сетью. Ребята, а у вас хотя бы более-менее приличные реализации BGP/OSPF/STP есть? Правильно, нет. Делать статические маршруты? Идите в известном направлении.
Итого, на данный момент SDN — штука сугубо лабораторная и к боевой инфре неготовая.
Если я где ошибаюсь — поправьте.
p.s. и нет, Cisco тоже занялась этим направлением, см. One. Только вот у них архитектура — «каждая железка имеет свой control plane, как раньше, но при этом можно манипулировать отдельными потоками с контроллера».
Я выше уже писала, что ключевыми направлениями исследований почти у всех (и у нас в том числе) — проверка на масштабируемость ПКС-сетей и разработка методов стыковки с сетями традиционной архитектуры. Про лабораторную штуку отчасти правда, хотя появляются и решения для индустрии. Знаю, что в многие компании покупают оборудование OpenFlow пока в основном для тестов.
ключевыми направлениями исследований почти у всех (и у нас в том числе) — проверка на масштабируемость ПКС-сетей
Не томите — расскажите, как предполагается доставлять трафик от контроллера до свитчей и обратно — этот момент мне наименее понятен :)
Ну и сколько потоков в секунду выдерживает контроллер на данный момент, и на каком железе? Вроде Bigswitch проводили презентацию, но этот вопрос они тщательно обошли стороной…
Знаю, что в многие компании покупают оборудование OpenFlow пока в основном для тестов.
Ну я, скажем, знаю, что гугл уже в процессе внедрения чего-то подобного. Но:
1) У них потрясающие человеческие ресурсы, позволяющие с нуля создать свой собственный превосходный контроллер, наверняка никоим образом не совместимый с openflow, хотя использующий чем-то похожие концепции. И уж конечно они не станут открывать подобные разработки.
2) Они закупают кастомное сетевое железо, созданное строго в соответствии с их требованиями, и, опять же, пишут под него свой софт.
Но это — гугл. Циска вон тоже что-то свое начинает предлагать, как всегда наплевав на открытые стандарты и справедливо полагая, что стандарты по привычке подстроятся под нее. Вопрос лишь в том, через сколько лет openflow дорастет до того уровня, когда им на самом деле можно пользоваться.
Из того, что я вижу — ближайшие лет 5 openflow позволит слегка сэкономить на железе и добавить немного (действительно немного, иначе такой зоопарк начнется...) гибкости, но все это в ущерб операционным расходам. Сопровождать такое решение будет безумно дорого, если только вы не Гугл. И, опять же, с надежностью вопрос открыт.
И кстати — какую версию openflow поддерживают приезжающие в сентябре железки, и придется ли их менять при появлении новой версии?
Уже приехавшие NEС 5420 поддерживают спецификацию OpenFlow 1.0.0
Менять железки понадобится необязательно, так как вендоры выпускают прошивки с обновлениями, например, так же уже приехавшие HP 3500yl поддерживают OpenFlow (не помню версию) только в специальной версии прошивки. Надеюсь, что и NEC выпустит со временем прошивку с обновлением
версии протокола.
Что касается остальных заданных вопросов — то вы несколько забегаете вперед. Как раз на решение этих вопросов и направлены исследования.
Результаты которых, уже интересны, например, таким компаниям, как Ростелеком, который уже устанавливает тестовую зону для проверки оборудования/ПО OpenFlow.
Так же будут проводиться сравнительные исследования применения традиционного подхода и OpenFlow.
Менять железки понадобится необязательно, так как вендоры выпускают прошивки с обновлениями, например, так же уже приехавшие HP 3500yl поддерживают OpenFlow (не помню версию) только в специальной версии прошивки. Надеюсь, что и NEC выпустит со временем прошивку с обновлением
версии протокола.
Что касается остальных заданных вопросов — то вы несколько забегаете вперед. Как раз на решение этих вопросов и направлены исследования.
Результаты которых, уже интересны, например, таким компаниям, как Ростелеком, который уже устанавливает тестовую зону для проверки оборудования/ПО OpenFlow.
Так же будут проводиться сравнительные исследования применения традиционного подхода и OpenFlow.
Результаты которых, уже интересны, например, таким компаниям, как Ростелеком, который уже устанавливает тестовую зону для проверки оборудования/ПО OpenFlow.
Делаем ставки: они выяснят, что openflow категорически не годится для построения территориально распределенной транспортной сети, и лучше остаться со старым добрым MPLS TE.
Посчитал, на картинке и правда миллиард :)
Купюра в 100 долларов = (до 1996 года) 156.4 мм *66.6 мм (Д/Ш); (после 1996 года) 156мм*67мм (Д/Ш); толщина 0,1075 мм
10000$ ( пачка ) = 156мм*67мм (Д/Ш; берем по максимуму); толщина 10.75 мм
Получается на одном поддоне 16 слоев по 5 рядов, по 105 пачек примерно (размеры евро-поддона как раз 1200х800мм).
Вес миллиарда, кстати 22 тонны.
Купюра в 100 долларов = (до 1996 года) 156.4 мм *66.6 мм (Д/Ш); (после 1996 года) 156мм*67мм (Д/Ш); толщина 0,1075 мм
10000$ ( пачка ) = 156мм*67мм (Д/Ш; берем по максимуму); толщина 10.75 мм
Получается на одном поддоне 16 слоев по 5 рядов, по 105 пачек примерно (размеры евро-поддона как раз 1200х800мм).
Вес миллиарда, кстати 22 тонны.
То есть 1 миллион долларов — 22 килограмма…
Интересно, как миллион долларов в фильмах носили в аккуратном портфельчике :)
Интересно, как миллион долларов в фильмах носили в аккуратном портфельчике :)
как вы получили 22 тонны? ru.wikipedia.org/wiki/%D0%94%D0%BE%D0%BB%D0%BB%D0%B0%D1%80
всего 10 тонн )
где-то читал, что в межбанке использовались купюры по $1к, но вики опровергает )
всего 10 тонн )
где-то читал, что в межбанке использовались купюры по $1к, но вики опровергает )
UFO just landed and posted this here
Чуть позже я напишу пост что такое ПКС и как оно работает. В комментариях всех подробностей не объяснишь
Это как бы вопрос со стороны обычного сисадмина небольшой компании до 100человек.
А забейте. При наличии такой инфраструктуры смысла переходить на SDN нет и вряд ли когда-либо появится. Вам просто не нужна та гибкость, которую в перспективе может дать openflow.
Но если интересно, можете погуглить «software defined networking».
Что то попахивает… от этой идеи, я конечно не первая инстанция но все же.
У меня только вопросы, а ответов нету. Коллеги поднимали вполне приличные темы (routing, STP, etc...) У нас небольшой ЦОД, ну как не большой 140 блейдов, с 10 коммутаторов, понятно что guest системы сидят в vlan (иногда в pvlan) но дальше это стекается к vrf и уходит на роутинг. Я отдаю себе отчет что SDN это автоматизация только L2 трансмиссии и не более. Тут приводили примеры, как SDN должен обрабатывать трафик:
— входящий порт, s_IP, d_IP
Этож какая тактовая частота должна быть у ASIC который обрабатывает эти запросы? При таком подходе 1g wirespeed не реален, иначе железо будет стоит как титановый мост через темзу (в качестве примера можете взять цену 1g порта на asr1000, который обеспечивает wirespeed).
Очень веселый вопрос остается с CP, если CP будет выделен на управляющую систему, рождаются вопросы:
— Отдельная OOBM сеть для этого
— Наличие своего CP на коммутаторе для обработки данных от контроллера для програмирования FIB
— Как защищать этот CP
— Как конвергировать сеть, в случае отказа?
Одним словом это все хорошо, но до поры до времени. Мне кажется идею надо развивать в несколько другом направлении. Выдумывать протокол 1,5+ его вытаскивать на контроллер, и дальше возиться с ним.
У меня только вопросы, а ответов нету. Коллеги поднимали вполне приличные темы (routing, STP, etc...) У нас небольшой ЦОД, ну как не большой 140 блейдов, с 10 коммутаторов, понятно что guest системы сидят в vlan (иногда в pvlan) но дальше это стекается к vrf и уходит на роутинг. Я отдаю себе отчет что SDN это автоматизация только L2 трансмиссии и не более. Тут приводили примеры, как SDN должен обрабатывать трафик:
— входящий порт, s_IP, d_IP
Этож какая тактовая частота должна быть у ASIC который обрабатывает эти запросы? При таком подходе 1g wirespeed не реален, иначе железо будет стоит как титановый мост через темзу (в качестве примера можете взять цену 1g порта на asr1000, который обеспечивает wirespeed).
Очень веселый вопрос остается с CP, если CP будет выделен на управляющую систему, рождаются вопросы:
— Отдельная OOBM сеть для этого
— Наличие своего CP на коммутаторе для обработки данных от контроллера для програмирования FIB
— Как защищать этот CP
— Как конвергировать сеть, в случае отказа?
Одним словом это все хорошо, но до поры до времени. Мне кажется идею надо развивать в несколько другом направлении. Выдумывать протокол 1,5+ его вытаскивать на контроллер, и дальше возиться с ним.
Этож какая тактовая частота должна быть у ASIC который обрабатывает эти запросы?
А в чем проблема? Современные L3 коммутаторы способны дать line-rate PBR и L4 ACL на сотнях/тысячах/десятках тысяч гигабит в секунду.
(в качестве примера можете взять цену 1g порта на asr1000, который обеспечивает wirespeed).
Зачем его? Берите старенький Cat6500. 48 медных гигабитных портов стоят $15k. Не так уж и дорого.
Навороченная M1 плата под N7k на 32 10G порта (все плюшки вплоть до line-rate шифрования) стоит $70k. Менее навороченная F2 на 48 10G портов — $44k.
Выдумывать протокол 1,5+ его вытаскивать на контроллер
Как LWAPP? Но это же безумие. Сервер в таком случае должен выглядеть как огромный модульный L3 свитч многотерабитной емкости. Тогда зачем вообще городить огород?
Один Мартин Кассадо заменяет собой целую стойку серверов — мне одному это показалось интересным?
Sign up to leave a comment.
Сколько стоит SDN?