telecom №26. Виртуализация и SDN, часть третья
0
12586
3
26 выпуск подкаста посвящен SDN\OpenFlow- контроллерам. Какие существуют на данный момент контроллеры, что они вообще из себя представляют, какие функции выполняют. Поговорим о безопасности, отказоустойчивости, внутреннем устройстве. Обсудим примеры внедрения в различных ситуациях, от энтерпрайза до ЦОДов и провайдеров.
В этот раз к нашей убер-SDN-команде в составе Александра Фатина и Виталия Антоненко примкнет коллега Виталия, ведущий программист-исследователь ARCCN, кандидат физико-математических наук Александр Шалимов. Кроме того, у нас будет еще один гость, Михаил Соколов, руководитель группы разработки компании Robonect, который в данный момент занимается разработкой программно-аппаратного комплекса с применением технологий SDN\NFW.
Дмитрий Булыгин в рамках исторической странички поведает о возникновении АТС.
Скачать файл подкаста.
Добавить RSS в подкаст-плеер.
Скачать все выпуски подкаста вы можете с помощью BT Sync (код: BYENRHD5UNKD5ZDIYFSB63WG2PEY2GIUN) или с яндекс-диска.
Новости выпуска:
Сделанное в России телеком- оборудование проверят на специальной площадке
Минкомсвязи разработало законопроект по обеспечению доступа операторов связи в многоквартирные жилые дома
Прокладка волоконно- оптического кабеля в руслах рек как дешевый способ обеспечения интернетом северных районов России
«Билайн» протестировал функционал LTE Advanced с объединением трех несущих частот из разных диапазонов.
Nokia возвращается на рынок мобильных телефонов
Google запустил виртуального мобильного оператора
Хронометраж:
0:00:00 — 0:23:50: Вступление и новости.
0:23:50 — 0:52:30: Рубрика «История связи» от Дмитрия Булыгина. АТС.
0:52:30 — 2:44:36: SDN\OpenFlow контроллеры.
Презентация к рассказу Александра
0
12586
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
Спасибо за подкаст и особенно за выпуски про SDN. С удовольствием слушаю, очень интересно. Сейчас в SDN явно больше проблем, чем пользы, но есть ощущение верной дороги. Жду продолжения!
Хочу оставить свои замечания к выпуску и мнение по поводу 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.