Comments 8
В момент запуска нашего сервиса в публичное использование мы применяли именно nwfilter [1], но были вынуждены перейти на OpenFlow 1.0
Обалдеть. Такое в продакшн… Да вы — экстремалы, и это вовсе не похвала. Openflow и сейчас-то не готов к продакшну, а вы еще тогда развернули.
1) Сколько у вас виртуальных машин?
2) Про какие цифры pps, cps и одновременных соединений мы говорим (на конкретной вашей сети, а не где-то в презентациях)?
3) Чем конкретно не устраивал ECMP в симметричной CLOS фабрике как на картинке выше? Не окажется ли, что вам на самом деле с огромным запасом хватает аплинков, и никакой реальной потребности в балансировке по нагрузке не было? Это ведь ЦОД, здесь обычно проще, надежнее и дешевле добавить емкости, чем выгадывать какие-то проценты с помощью относительно интеллектуальных механизмов, которые вы все равно наверняка не используете (если все таблицы проактивно загружены на свитчи).
4) Сколько было аварий по вине чего-либо связанного с openflow за последний месяц? Только честно.
5) Итого. Какой конкретно задействуется функционал openflow из того, что нельзя реализовать традиционными средствами? Например, тот самый «анализ необычных пакетов» влегкую решается виртуальными файрволами и IPS на гипервизоре вместо отправки пакета куда-то далеко. Подход «ставим один большой файрвол, пускаем всё через него» уже несколько устарел.
1. в стойке — около 1к
2. pps — сотни тысяч на тестах (упираемся в производительность vhost-net на мелких пакетах), в реальности 20k/нода перемалываются с пренебрежимо малой нагрузкой процессора, cps в этом случае те же — трафик идентичен трафику счетчиков.
3. неудобством сопряжения интеллектуального куска на нодах и всего, что будет находиться выше — выходит сложнее в плане логики
4. 0 :) у нас за все время из-за опенфлоу была ровно одна авария, связанная с некорректной логикой контроллера, как раз в начале внедрения, занявшая 20 минут времени
5. в целом, если выбросить оверлеи, никакой — на порядки сокращается время тестирования и упрощается выявление аномалий, OF это не волшебная палочка, а просто очередной шаг вперед — касательно того же анализа пакетов — OF, в общем случае, не может выступать в роли файрвола в силу своей природы (нет отслеживания состояния соединения), но зато может выступать дешевым классификатором. Сопрягать оркестровку еще и со сторонней IDS — увольте, до момента, когда она будет предоставлять действительно уникальные фичи, это просто расход ресурсов в никуда и инвестиции в производителя этой IDS.
Мы утверждаем, что Openflow к продакшну при грамотном подходе полностью готов — об этом свидетельствует годичный опыт :)
2. pps — сотни тысяч на тестах (упираемся в производительность vhost-net на мелких пакетах), в реальности 20k/нода перемалываются с пренебрежимо малой нагрузкой процессора, cps в этом случае те же — трафик идентичен трафику счетчиков.
3. неудобством сопряжения интеллектуального куска на нодах и всего, что будет находиться выше — выходит сложнее в плане логики
4. 0 :) у нас за все время из-за опенфлоу была ровно одна авария, связанная с некорректной логикой контроллера, как раз в начале внедрения, занявшая 20 минут времени
5. в целом, если выбросить оверлеи, никакой — на порядки сокращается время тестирования и упрощается выявление аномалий, OF это не волшебная палочка, а просто очередной шаг вперед — касательно того же анализа пакетов — OF, в общем случае, не может выступать в роли файрвола в силу своей природы (нет отслеживания состояния соединения), но зато может выступать дешевым классификатором. Сопрягать оркестровку еще и со сторонней IDS — увольте, до момента, когда она будет предоставлять действительно уникальные фичи, это просто расход ресурсов в никуда и инвестиции в производителя этой IDS.
Мы утверждаем, что Openflow к продакшну при грамотном подходе полностью готов — об этом свидетельствует годичный опыт :)
cps в этом случае те же
Так какой cps, сколько одновременных соединений и сколько стоек на контроллер?
неудобством сопряжения интеллектуального куска на нодах и всего, что будет находиться выше — выходит сложнее в плане логики
Не вижу связи. Так у вас есть задача выравнивать нагрузку на аплинках, или нет? И кстати, железные свитчи все-таки являются OF форвардерами, или только держат оверлеи? Я как-то не понял.
на порядки сокращается время тестирования и упрощается выявление аномалий,
Тестирование чего?
Какого рода аномалии?
OF, в общем случае, не может выступать в роли файрвола в силу своей природы (нет отслеживания состояния соединения), но зато может выступать дешевым классификатором.
Шаг назад по сравнению с пропусканием трафика через файрвол в гипервизоре. Вы даже не сможете по-человечески детектировать L7 аномалиями, а всё что ниже легко отсекается любым свитчем. И любой приличный оркестратор сам позаботится о настройке портов на физическом или виртуальном свитче. Итого: можно либо добиться того же, что у вас есть сейчас, но без хранения flow информации в любом виде (проблемы с масштабированием), либо куда большего — с хранением.
Так какой cps, сколько одновременных соединений и сколько стоек на контроллер?
20k/20k (из примера в продакшене), около 0.05 :)
Не вижу связи. Так у вас есть задача выравнивать нагрузку на аплинках, или нет? И кстати, железные свитчи все-таки являются OF форвардерами, или только держат оверлеи? Я как-то не понял.
Пока что нет, мы не сделали полноценный BGP redistribution, задача сводится к оптимизации трафика датацентра. Свичи выполняют, как бы это сказать, совмещенную роль — режим OF работает как оверлейный механизм.
Тестирование чего?
Какого рода аномалии?
Сейчас — очень простые, вида «машина ведет себя не как обычно» — профиль трафика и, при обнаружении каких либо отклонений в «дешевых» анализаторах — переключение на более «дорогие», то есть реактивные правила или заворачивание на тот же IDS. Очень помогает в борьбе со всякого рода зловредами, обожающими пролезать через дырявые движки.
Вы даже не сможете по-человечески детектировать L7 аномалиями
В этом пока что нет нужды, мы не предоставляем такую услугу. Анализ L7 — задача, востребованная энтерпрайзом (предотвращение атак и тому подобное), для самих себя это в лучшем случае помощь от упомянутых зловредов на еще более ранних стадиях, то есть предотвращение заражения.
20k/20k
20k cps, 20k pps и 20k одновременных соединений? Какие-то странные цифры.
задача сводится к оптимизации трафика датацентра
Так если сеть построена симметрично и потоков много — что там оптимизировать?
при обнаружении каких либо отклонений в «дешевых» анализаторах — переключение на более «дорогие», то есть реактивные правила или заворачивание на тот же IDS. Очень помогает в борьбе со всякого рода зловредами, обожающими пролезать через дырявые движки.
То есть все-таки занимаетесь L7, раз заботитесь о зловредах… Ну так хоть даже netflow можно смотреть на предмет таких же аномалий, а вариантов переключения трафика на анализаторы тоже полно.
Так зачем вам Openflow? Я не понял. Вроде всё усложнили, профита не вижу.
20k cps, 20k pps и 20k одновременных соединений? Какие-то странные цифры.
Это пример с одной из VM, обслуживающих другой наш проект — на нее идут отстуки в несколько сотен байт, так что числа почти одинаковые.
Так если сеть построена симметрично и потоков много — что там оптимизировать?
Распределение трафика в ней, ведь пользовательский трафик может быть очень сильно перекошен относительно топологии. Безусловно, чем меньше масштаб, тем меньше и перекосы, потому это не очень очевидно.
Ну так хоть даже netflow можно смотреть на предмет таких же аномалий,
Зачем? Лишний механизм, необходимость прогона всего трафика в хосте… В будущем мы внедрим одно из offload-решений(netmap/dpdk) в vswitch, такие механизмы просто лишатся возможности работать, хост перестанет «видеть» трафик.
Так зачем вам Openflow? Я не понял. Вроде всё усложнили, профита не вижу.
Наоборот, мы отвязались от *всех* протоколов маршрутизации внутри своей сети и существенно упростили управление ей. Со стороны сетевиков, работавших с классическими протоколами большую часть карьеры, это кажется изобретением велосипеда(чем, частично, и является, иначе полной замены не выйдет), а на деле это огромное упрощение, сведение всех сетевых сущностей к единому участку кода в оркестровке. Можете считать это закладкой на будущее — мы можем линейно масштабироваться без каких-либо усилий, вводить дополнительные реактивные (в смысле логики поведения) правила обработки трафика, создавать оверлеи на сколь угодно большом масштабе — плюсы перечислять можно долго. Как было упомянуто в посте, мы стремимся к выстраиванию своей собственной экосистемы во всех стеках — поверьте, это приносит положительные плоды.
Да, чуть не забыл — из утверждения про проактивность большей части правил никак не следует отсутствие преимущества централизованного их пересчета, сравнительно с IGP. Проактивность всего лишь шаг к редукции числа правил, а не аналог статической FIB.
Как уже писал в другой теме — откройте flow контроллер, не жмитесь, сделаете и себе хорошо и Сообществу :)
Sign up to leave a comment.
В поисках идеальной сети: OpenFlow и все-все-все