вот этот тоненький 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 за сокет. Лицензируются по сокетно.
Для физических устройств решения дороже.
Лучшие практики высокой доступности контроллера:
— резервирование secure channels;
— резервирование контроллера:
— кластеризация;
— резервирование NIC;
— резервирование жестких дисков, RAID;
— резервирование источников питания;
Три года назад работоспособные контроллеры были только у Гугла, т.к. именно с Гугла начался интерес к SDN … Но Гугл ни с кем своими наработками не делится. У других они только начинали появляться и были в зачаточном состоянии, т.е. не совершенны.
Первые релизы софта были не совершенны, но сейчас это уже рабочий продукт, который работает у многих операторов и сервис провайдеров. Открытые референсы есть.
В мире еще одним решением прибыло: есть выбор, или остаться на текущих технологиях и решениях или попробовать новое. Никто не говорит, что новое – это самое лучшее, попробуйте, и если вам понравится,- пользуйтесь.
В случае падения SDN контроллера – все существующие связи сохраняются, а возможность добавления новых настроек будет ожидать восстановления контроллера.
В случае падения SDN контроллера – все существующие связи сохраняются, а возможность добавления новых настроек будет ожидать восстановления контроллера.
В этом нет ничего плохого, появляется один единый роутер, один балансировщик, один файрвол и др.сервисные аплайансы, вместо десятков девайсов в классической архитектуре, в слоеном расположении друг относительно друга.
5 лет — совсем немного. Новые решения никто не навязывает, а только предлагает попробовать, хотя бы для тестировочных целей. Решение SDN – рабочее, прошедшее обкатку и успешную эксплуатацию во мгогих крупных компаниях: Deutsche Telecom, Virizon, Facebook, Yahoo, Microsoft, NTT, и др. Пробуйте, что для вас подходит, если понравится – Wellcome!
Данная статья, короткая, специально бизнес ориентированая, дающая обзор по технологии. За глубокими техническими знаниями прошу на вендорские семинары, мы их проводим, кстати регулярно.
Интересно, чем вы автоматизируете развертывание виртуальных сетей под развертывание нескольких сотен виртуальных машин для Cloud приложений. А потом, когда вы или ваш клиент через месяц захотят эти VM свернуть, кто вспомнит про выделенные под это сети?
Все эти скритпы и вспомогательные программы все равно заходят на каждое устройство и прописывают новые настройки, как если бы мы руками это делали. В нашем случае подход другой.
Как раз наоборот, SDN ведет к объединению разрозненных кусков в единое целое.
Многие типовые сетевые устройства имеют универсальный процессор, который не может справится с большим объемом специализированных операций.
Это неверно. Учите мат.часть.
Преимущество SDN – в дополнение к вышесказанному, в т.ч. в замене традиционных роутинговых протоколов (OSPF, BGP, RIP и др.) на сети.
Механизмы отказоустойчивости и резервирования были приведены выше. В плане латентности, времени отклика, задержек – тесты и эксплуатация показывает, что все лучше, чем на привычных сетях.
Решения OpenFlow есть двух типов: для физических сетевых устройств, и для виртуальных.
Виртуальные решения SDN – дешевы, ориентировочно от 100 до нескольких сот USD за сокет. Лицензируются по сокетно.
Для физических устройств решения дороже.