return

telecom №26. Виртуализация и SDN, часть третья

25 апреля 2015, 21:01
like 0 views 12544 message 3

3 коментария

  • Живьем, если кто успеет, презентация от Ivan Pepelnjak с RIPE meeting по SDN ripe70.ripe.net/live/main/
    и слайды ripe70.ripe.net/wp-content/uploads/presentations/7-SDN-4-Years-Later.pdf

    11 мая 2015, 18:26
  • Спасибо за подкаст и особенно за выпуски про SDN. С удовольствием слушаю, очень интересно. Сейчас в SDN явно больше проблем, чем пользы, но есть ощущение верной дороги. Жду продолжения!

    5 мая 2015, 19:04
  • Хочу оставить свои замечания к выпуску и мнение по поводу SDN.
    Дослушал подкаст до конца, спасибо большое Александру. Самый подробный рассказ из всех выпусков — сразу видно, что человек близко работает с этим, а не просто вбрасывает модные слова и термины, относящиеся к SDN, как сейчас многие делают.
    Была упомянута альтернатива TCAM — бинарное дерево в RAM. Это будет медленнее, чем TCAM, потому что время поиска лучшего совпадения в TCAM — константное O(1), а в бинарном дереве — O(log n).
    Теперь непосредственно про SDN. Я вижу такую проблему — для связи контроллера со свитчами нам нужна отдельная Out of Band сеть, мало того, эта сеть должна быть очень быстрая с минимальными задержками, т.е. скорее всего 10 Гигабитные линки, то есть нам ещё надо потратить дополнительные деньги за n..2n (если у нас есть резервный контроллер) 10 гигабитных портов.
    Следующая проблема, для простоты, допустим, что у нас мелкая сеть, где 2 свитча соединены между собой. Сеть за одним коммутатором будет отрезана от сети за другим коммутатором в случае, если с линком что-то случится. Теперь добавим SDN — OOB сеть с контроллером, где контроллер активно управляет свитчами, постоянно изменяя таблицы потоков. Теперь 2 сети не смогут общаться между собой в случае, если что-то случится с линком между коммутатором или с любым из линков к контроллеру. То есть проблемы в OOB сети влияют на нашу основную сеть!
    Упомянули, что SDN контроллер не может мгновенно узнать, например, об обрыве линка. Это неподустимо, в современных сетях давно используется уже упомянутый BFD, который позволяет узнавать о таких проблемах за 150мс, и уже через столько времени, роутер может пересчитать SPF (или что там у вас используется). Я практически уверен, что в SDN таких цифр просто нет. И быть не может, пока нам надо тратить время на таймеры и на взаимодействие с контроллером.
    Дальше, ещё одна проблема, которую уже озвучили, и я считаю, что она очень важная. Сетевые инженеры МАКСИМУМ выучат Python, но не Java или C++. Хорошие Java или C++ программисты не пойдут учить сети, потому что это большой и сложный пласт знаний — нужно изучить большинство основных протоколов, какие проблемы эти протоколы решают и как. Несомненно, специалисты в обоих областях будут, но их будет слишком мало для покрытия спроса. Зачем переходить на другую сетевую архитектуру, если потом специалиста не найти? Это, примерно, как писать софт на Scala. Прикольно, да, только поддерживать некому. На это всё мне можно ответить, что есть же REST или GUI. Оба варианта в готовых решениях на сегодняшний день ужасны. Чтобы аргументировать свою точку зрения, я приведу пример из своего опыта. У меня года полтора назад была мысль, что SDN — это будущее сетей, и мне, как молодому сетевому инженеру, стоит начать изучать это направление, чтобы не пришлось запрыгивать в последний вагон уходящего поезда. Так получилось, что я решил делать проект в университете по SDN, в частности OpenDayLight. Изучил тему, некоторую документацию, попробовал REST API, написал небольшой модуль на Java, и понял — SDN ещё не здесь, и придёт он ещё нескоро. Описание логики сети с помощью REST или web-gui OpenDayLight похоже на примитивный Policy Based Routing, если вы понимаете о чём я.
    Допустим, что всё же появится развесистый и удобный GUI, в котором будет реализована самая необходимая функциональность и красивые графики для мониторинга. Компания перешла на SDN, уволила нафиг штат сетевых инженеров, наняла пару студентов, которые по GUI тыкают и графики смотрят, а софт для контроллера или покупается отдельно, или отдаётся на разработку в аутсорс. Всё хорошо и отлично ровно до того момента, когда что-то ломается или просто необходимо что-то изменить или добавить, а нужной кнопочки в GUI нет. Мы запросим фичу или модификацию у тех, кто пишет нам софт, потом будем ждать, пока её напишут, оттестируют и задеплоят. Вероятно, через недели (если давать пинков нужным людям) мы получим бета-версию фичи. Только у конкурентов, у которых legacy сеть и куда ушла часть команды уволенных сетевых инженеров, изменение в работе сети обычно занимает 1 maintenance window. Зато у нас SDN! Сеть обычна нужна здесь и сейчас, чтобы решать бизнес-задачи. Индустрия разработки софта так быстро просто не работает.
    Проект я сделал, презентовал и расстроился, и без дальнейших сомнений на тему SDN vs Legacy сети взялся за книжки CCIE.
    Я вижу достоинства SDN в ЦОДах, Openstack это несомненно успех, а NFV в теории звучит тоже заманчиво. В других случаях я не вижу особых преимуществ перехода на SDN. Legacy сети с привычными всем BGP/OSPF/MPLS будут работать ещё очень долго. Посмотрю на SDN года через 3, а пока что воспринимаю SDN лишь как buzz word.

    1 мая 2015, 00:25
Ещё выпуски
telecom №45. Data Center Interconnection (DCI)
В продолжение 12-й части СДСМ Александр Клиппер, гость 23-го выпуска рассказывает про Data Center Interconnection (DCI): TRILLVXLANOTVEVPN/VPLS Скачать файл подкаста
like 1 14427 17
По'уехавшие №10. Польша. Владимир Зберовский
Одной Польши нам было мало. Возьмём её ещё раз. О чём не говорили в прошлый раз и поговорили в этот: Как знать всю ...
like 0 6668 1
Play
telecom №103. Домашний Интернет
Если долго смотреть в бездну, то бездна начнёт смотреть на тебя... Мы так тщательно избегали этой темы, что поговорили примерно обо всём, что ...
like 1 3953 4
telecom №32. ОАО Полигон, оборудование, программный маршрутизатор
В 32-м выпуске у нас рекордное количество гостей. В эфире делегация из ОАО НПП Полигон. Денис Абсалямов — специалист по маркетингу Альфред Исламов ...
like 0 13917 9
00:00 00:00