В поисках идеальной сети: OpenFlow и все-все-все

    Здравствуйте, уважаемые читатели,

    в этом посте мы расскажем о своем поиске идеального сетевого решения для облачной инфраструктуры и о том, почему мы решили остановиться на OpenFlow.

    image



    Введение


    Понятие облака неразрывно связано с двумя абстракциями — гарантированное качество ресурсов и их взаимная изоляция. Рассмотрим, как эти понятия применяются к устройству сети в облачном решении. Изолированность ресурсов подразумевает следующее:
    • антиспуфинг,
    • выделение приватного сегмента сети,
    • фильтрация публичного сегмента для минимизации воздействий извне.

    Гарантированное качество ресурсов — это QoS в общем понимании, то есть обеспечение требуемой полосы и требуемого отклика внутри сети облака. Далее — подробный разбор реализации упомянутых концепций в облачных инфраструктурах.

    Изоляция трафика


    • Антиспуфинг с помощью iptables/ebtables или статических правил в OpenVSwitch: максимально дешевое решение, но на практике неудобно — если для linux bridge правила создаются с помощью механизма nwfilter в libvirt и автоматически подтягиваются при запуске виртуальной машины, для ovs оркестровке придется отслеживать момент старта и проверять или обновлять соответствующие правила в свиче. Добавление или удаление адреса или миграция виртуальной машины превращаются в обоих случаях в нетривиальную задачу, перекладываемую на логику оркестровки. В момент запуска нашего сервиса в публичное использование мы применяли именно nwfilter [1], но были вынуждены перейти на OpenFlow 1.0 из-за недостаточной гибкости решения в целом. Также стоит упомянуть довольно экзотический метод фильтрации исходящего трафика с помощью netlink для технологий, работающих в обход сетевого стека хоста (macvtap/vf), который в свое время не был принят в ядро, несмотря на высокую коммерческую востребованность.
    • Антиспуфинг с помощью правил в свиче уровня стойки (ToR switch) при переносе в него портов виртуальных машин с помощью одного из механизмов туннелирования трафика непосредственно от интерфейсов виртуальных машин (см. картинку ниже). В качестве плюсов такого решения можно отметить сосредоточение логики на свиче == отсутствие необходимости ее «размазывания» по программным свичам вычислительных нод. Маршрут трафика между машинами одной вычислительной ноды всегда будет проходить через свич, что может быть не всегда удобно.
      image
      ToR filtering © networkheresy

    • Антиспуфинг при проверке полей в OpenFlow сети — когда все свичи, физические и виртуальные, подключены к группе контроллеров, обеспечивающих, помимо перенаправления и трансформации полей трафика повсюду, его очистку на уровне программного свича вычислительной (compute) ноды. Это самый сложный и самый гибкий из возможных вариантов, поскольку абсолютно вся логика, начиная от пересылки датаграмм внутри обычного свича, будет вынесена в контроллер. Неполные или неконсистентные правила могут привести либо к нарушению связности, либо к нарушению изоляции, поэтому системы с большим процентом реактивных (задающихся динамически по запросу от свича) правил следует тестировать с помощью, фреймворков наподобие NICE [2].
    • Выделение сегмента сети — решение, практикуемых в крупных гомогенных структурах, при этом за группой виртуальных машин закрепляется либо привязка к физическим машинам (и портам физического свича), либо к тегу инкапсуляции любого типа (vlan/vxlan/gre). Граница фильтрации находится на стыке L2 сегмента, иначе говоря, сегменту выделяется подсеть или набор подсетей и невозможность их подмены обуславливается роутингом в вышестоящей инфраструктуре, пример — OpenStack Neutron без гибридного драйвера Nova [3]. Глубокого теоретического интереса этот подход не представляет, но имеет широкую практическую распространенность, унаследованную от до-виртуализационной эпохи.


    Управление трафиком


    Оптимизация маршрутов таким образом, чтобы использовать возможности сетевых линков по-максимуму (иначе говоря, нахождение максимума cуммы min-cut [4] для всех пар взаимодействующих конечных точек с учетом их весов, то есть приоритетов QoS), считается наиболее сложной задачей в распределенных сетях. IGP, призванные решать эту проблему, в общем случае являются недостаточно гибкими — трафик может быть отсортирован только на основании заранее выделенных меток QoS и о динамическом анализе и перераспределении трафика приходится не думать. Для OpenFlow, поскольку средства анализа отдельных элементов трафика являются неотъемлемой частью протокола, решить эту задачу достаточно несложно — достаточно построить корректно работающий классификатор отдельных потоков [5, 6]. Еще один несомненный плюс OpenFlow в этом случае — в централизованном подсчете стратегии форвардинга возможно учесть множество дополнительных параметров, которые просто не включены ни в один из стандартов IGP.

    Проектирование сети даже небольшого датацентра с гетерогенным наполнением (содержание одновременно множества розничных пользоватей без физической привязки группы машин к стойке), приводит к задаче построения распределенных L2-over-L3 сетей (overlay networks) [7] с помощью одного из существующих механизмов, из-за невозможности технически поместить десятки тысяч виртуальных хостов в один широковещательный сегмент обычными способами. Указанные технологии позволяют «разгрузить» логику форвардинга, поскольку оборудование теперь оперирует метками, соответствующим группам хостов вместо отдельных адресов в приватных (и, возможно, публичных) сегментах пользовательских сетей. За дешевизной и сравнительной простотой внедрения кроется привязка как минимум к производителю сетевого оборудования и конечная недетерминированность — если отвлечься от детализации, все оверлейные протоколы предоставляют обучаемый свич внутри отдельной метки, что может вызвать затруднения при оптимизации трафика внутри оверлейного сегмента, из-за «развязанности» протоколов маршрутизации третьего уровня и механизмов самого оверлея. Выбирая OpenFlow, мы сводим все управление трафиком к одному уровню принятия решений — сетевому контроллеру. Оверлеи или замещающий их собственный механизм, безусловно, могут выполнять ту же роль по уменьшению объема правил в свичах-аггрегаторах (spine на картинке ниже), а оптимизация направления трафика на ToR свичах (leaf) будет происходить, базируясь на произвольном наборе метрик, в отличие от простой балансировки (как, к примеру, в ECMP).

    image
    Двухуровневый spine-leaf


    OpenFlow


    Стандарт OpenFlow в первом промышленно доступном варианте, 1.0, стал доступен в составе железных свичей более года назад, но эта версия имела несколько архитектурных ограничений, препятствовавших массовому внедрению, и наиболее проблемное из них — отсутствие множественных последовательных таблиц для обработки, то есть одно правило соответствовало ровно одной паре взаимодействовавших конечных точек, без учета дополнительных совпадений [8]. Использование OpenFlow 1.0 проактивным образом (то есть с созданием всех необходимых правил заранее) вело бы к квадратичному росту числа правил от числа взаимодействующих хостов, как представлено на на картинке ниже.
    image
    Сравнение OF 1.0 и 1.3 © Broadcom Corp

    Частичным выходом из ситуации является использование механизма learning switch — то есть реактивной работы OpenFlow свича, когда правила запрашиваются каждый раз, когда они не совпадают ни с одним, уже помещенным в таблицу форвардинга свича, а через определенный TTL — удаляются из свича. Стратегия удаления может быть как «жесткой» — удаление через заданный промежуток времени после установки правила, так и «мягкой» — удаление происходит только в отсутствие активности за заданный промежуток времени «внутри» конкретного потока. На момент начала использования нами OF ни один из открытых программных контроллеров не поддерживал новые версии, упомянутая выше погоня за гибкостью подхода управления остановилась именно на стандарте 1.0. Модель learning switch оправдывает себя на значительном количестве нагрузок, непредолимым препятствием для нее становятся лишь приложения наподобие счетчиков, генерирующие сотни и тысячи уникальных запросов в секунду на уровне свича, также она подвержена атаке быстрого спуфинга — клиент, генерирующий пакеты с уникальными IP/MAC идентификаторами, как минимум, способен привести в нерабочее состояние свич уровня вычислительной ноды, а если заранее не позаботиться об ограничении PACKET_IN (сообщений на обработку потока для контроллера), то и целый сегмент сети.

    После того, как все элементы нашей сети (базирующейся на OpenVSwitch), получили обновление, достаточное для использования стандарта 1.3, мы незамедлительно перешли на него, разгрузив контроллеры и обеспечив прирост производительности форвардинга (на пересчет по усредненному pps) на полтора-два порядка, за счет перехода на проактивные флоу для подавляющего объема трафика. Необходимость распределенного анализа трафика (без прокачивания всего объема через выделенные ноды-классификаторы с классическим фаерволом) оставляет место для реактивных флоу — ими мы анализируем необычный трафик.

    О настоящем


    Поддержка современных стандартов OpenFlow производителями доступного сетевого оборудования ToR в формате whitebox [9] на сегодняшний день ограничивается решениями на базе Windriver (Intel), Cumulus (Dell) и Debian в свичах Pica8, все прочие вендоры либо предоставляют свичи более высокой ценовой категории, либо злоупотребляют собственными несовместимыми расширениями/механизмами. По историческим обстоятельствам нами используется Pica8 в качестве ToR свичей, но политика производителя, переведшего GPL-дистрибутив на платную подписку, весьма ограничивает область потенциального взаимодействия. Сегодня открытые платформы Intel ONS или Dell (базирующийся на Trident II), при весьма скромной цене (<10K$ за 4*40G+48*10G), позволяют управлять трафиком нескольких десятков тысяч виртуальных машин в масштабе одной промышленной стойки с 1-6 Тб памяти, используя OpenFlow (1.3+).

    Оглядываясь назад, отмечу дополнительные плюсы подобной разработки — погружение в проблематику программно-определяемых подсетей и расширение собственной экосистемы. Использование OpenFlow для управления трафиком и программного хранилища Ceph для обеспечения высокой доступности данных, позволяет заявить о себе, как о реализации software-defined datacenter, хотя впереди еще много работы на пути к идеалу.

    Спасибо за внимание!

    Ссылки


    [1]. libvirt — nwfilter
    [2]. NICE
    [3]. OpenStack Neutron
    [4]. Max-flow/Min-cut
    [5]. B4 — WAN сеть гугля на OpenFlow
    [6]. Подробный разбор одного из алгоритмов QoS-ориентированного TE
    [7]. Хорошая статья про overlay networks
    [8]. OF: 1.0 vs 1.3 table match
    [9]. Why whitebox switches are good for you
    • +5
    • 12,4k
    • 8
    Перформикс
    35,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 8

      0
      В момент запуска нашего сервиса в публичное использование мы применяли именно nwfilter [1], но были вынуждены перейти на OpenFlow 1.0

      Обалдеть. Такое в продакшн… Да вы — экстремалы, и это вовсе не похвала. Openflow и сейчас-то не готов к продакшну, а вы еще тогда развернули.

      1) Сколько у вас виртуальных машин?
      2) Про какие цифры pps, cps и одновременных соединений мы говорим (на конкретной вашей сети, а не где-то в презентациях)?
      3) Чем конкретно не устраивал ECMP в симметричной CLOS фабрике как на картинке выше? Не окажется ли, что вам на самом деле с огромным запасом хватает аплинков, и никакой реальной потребности в балансировке по нагрузке не было? Это ведь ЦОД, здесь обычно проще, надежнее и дешевле добавить емкости, чем выгадывать какие-то проценты с помощью относительно интеллектуальных механизмов, которые вы все равно наверняка не используете (если все таблицы проактивно загружены на свитчи).
      4) Сколько было аварий по вине чего-либо связанного с openflow за последний месяц? Только честно.
      5) Итого. Какой конкретно задействуется функционал openflow из того, что нельзя реализовать традиционными средствами? Например, тот самый «анализ необычных пакетов» влегкую решается виртуальными файрволами и IPS на гипервизоре вместо отправки пакета куда-то далеко. Подход «ставим один большой файрвол, пускаем всё через него» уже несколько устарел.
        0
        1. в стойке — около 1к
        2. pps — сотни тысяч на тестах (упираемся в производительность vhost-net на мелких пакетах), в реальности 20k/нода перемалываются с пренебрежимо малой нагрузкой процессора, cps в этом случае те же — трафик идентичен трафику счетчиков.
        3. неудобством сопряжения интеллектуального куска на нодах и всего, что будет находиться выше — выходит сложнее в плане логики
        4. 0 :) у нас за все время из-за опенфлоу была ровно одна авария, связанная с некорректной логикой контроллера, как раз в начале внедрения, занявшая 20 минут времени
        5. в целом, если выбросить оверлеи, никакой — на порядки сокращается время тестирования и упрощается выявление аномалий, OF это не волшебная палочка, а просто очередной шаг вперед — касательно того же анализа пакетов — OF, в общем случае, не может выступать в роли файрвола в силу своей природы (нет отслеживания состояния соединения), но зато может выступать дешевым классификатором. Сопрягать оркестровку еще и со сторонней IDS — увольте, до момента, когда она будет предоставлять действительно уникальные фичи, это просто расход ресурсов в никуда и инвестиции в производителя этой IDS.

        Мы утверждаем, что Openflow к продакшну при грамотном подходе полностью готов — об этом свидетельствует годичный опыт :)
          0
          cps в этом случае те же

          Так какой cps, сколько одновременных соединений и сколько стоек на контроллер?
          неудобством сопряжения интеллектуального куска на нодах и всего, что будет находиться выше — выходит сложнее в плане логики

          Не вижу связи. Так у вас есть задача выравнивать нагрузку на аплинках, или нет? И кстати, железные свитчи все-таки являются OF форвардерами, или только держат оверлеи? Я как-то не понял.
          на порядки сокращается время тестирования и упрощается выявление аномалий,

          Тестирование чего?
          Какого рода аномалии?
          OF, в общем случае, не может выступать в роли файрвола в силу своей природы (нет отслеживания состояния соединения), но зато может выступать дешевым классификатором.

          Шаг назад по сравнению с пропусканием трафика через файрвол в гипервизоре. Вы даже не сможете по-человечески детектировать L7 аномалиями, а всё что ниже легко отсекается любым свитчем. И любой приличный оркестратор сам позаботится о настройке портов на физическом или виртуальном свитче. Итого: можно либо добиться того же, что у вас есть сейчас, но без хранения flow информации в любом виде (проблемы с масштабированием), либо куда большего — с хранением.
            0
            Так какой cps, сколько одновременных соединений и сколько стоек на контроллер?

            20k/20k (из примера в продакшене), около 0.05 :)

            Не вижу связи. Так у вас есть задача выравнивать нагрузку на аплинках, или нет? И кстати, железные свитчи все-таки являются OF форвардерами, или только держат оверлеи? Я как-то не понял.

            Пока что нет, мы не сделали полноценный BGP redistribution, задача сводится к оптимизации трафика датацентра. Свичи выполняют, как бы это сказать, совмещенную роль — режим OF работает как оверлейный механизм.
            Тестирование чего?
            Какого рода аномалии?

            Сейчас — очень простые, вида «машина ведет себя не как обычно» — профиль трафика и, при обнаружении каких либо отклонений в «дешевых» анализаторах — переключение на более «дорогие», то есть реактивные правила или заворачивание на тот же IDS. Очень помогает в борьбе со всякого рода зловредами, обожающими пролезать через дырявые движки.

            Вы даже не сможете по-человечески детектировать L7 аномалиями

            В этом пока что нет нужды, мы не предоставляем такую услугу. Анализ L7 — задача, востребованная энтерпрайзом (предотвращение атак и тому подобное), для самих себя это в лучшем случае помощь от упомянутых зловредов на еще более ранних стадиях, то есть предотвращение заражения.
              0
              20k/20k

              20k cps, 20k pps и 20k одновременных соединений? Какие-то странные цифры.
              задача сводится к оптимизации трафика датацентра

              Так если сеть построена симметрично и потоков много — что там оптимизировать?
              при обнаружении каких либо отклонений в «дешевых» анализаторах — переключение на более «дорогие», то есть реактивные правила или заворачивание на тот же IDS. Очень помогает в борьбе со всякого рода зловредами, обожающими пролезать через дырявые движки.

              То есть все-таки занимаетесь L7, раз заботитесь о зловредах… Ну так хоть даже netflow можно смотреть на предмет таких же аномалий, а вариантов переключения трафика на анализаторы тоже полно.

              Так зачем вам Openflow? Я не понял. Вроде всё усложнили, профита не вижу.
                0
                20k cps, 20k pps и 20k одновременных соединений? Какие-то странные цифры.

                Это пример с одной из VM, обслуживающих другой наш проект — на нее идут отстуки в несколько сотен байт, так что числа почти одинаковые.

                Так если сеть построена симметрично и потоков много — что там оптимизировать?


                Распределение трафика в ней, ведь пользовательский трафик может быть очень сильно перекошен относительно топологии. Безусловно, чем меньше масштаб, тем меньше и перекосы, потому это не очень очевидно.

                Ну так хоть даже netflow можно смотреть на предмет таких же аномалий,


                Зачем? Лишний механизм, необходимость прогона всего трафика в хосте… В будущем мы внедрим одно из offload-решений(netmap/dpdk) в vswitch, такие механизмы просто лишатся возможности работать, хост перестанет «видеть» трафик.

                Так зачем вам Openflow? Я не понял. Вроде всё усложнили, профита не вижу.

                Наоборот, мы отвязались от *всех* протоколов маршрутизации внутри своей сети и существенно упростили управление ей. Со стороны сетевиков, работавших с классическими протоколами большую часть карьеры, это кажется изобретением велосипеда(чем, частично, и является, иначе полной замены не выйдет), а на деле это огромное упрощение, сведение всех сетевых сущностей к единому участку кода в оркестровке. Можете считать это закладкой на будущее — мы можем линейно масштабироваться без каких-либо усилий, вводить дополнительные реактивные (в смысле логики поведения) правила обработки трафика, создавать оверлеи на сколь угодно большом масштабе — плюсы перечислять можно долго. Как было упомянуто в посте, мы стремимся к выстраиванию своей собственной экосистемы во всех стеках — поверьте, это приносит положительные плоды.
          0
          Да, чуть не забыл — из утверждения про проактивность большей части правил никак не следует отсутствие преимущества централизованного их пересчета, сравнительно с IGP. Проактивность всего лишь шаг к редукции числа правил, а не аналог статической FIB.
          0
          Как уже писал в другой теме — откройте flow контроллер, не жмитесь, сделаете и себе хорошо и Сообществу :)

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое