SDN&NFV: SDN/OpenFlow контроллеры и приложения

SDN&NFV: SDN/OpenFlow контроллеры и приложения Доп. главы Компьютерных сетей и телекоммуникации к.ф.-м.н., м.н.с., Шалимов А.В. ashalimov@lvk.cs.msu.su @alex_shali @arccnnews Часть 0: SDN/OpenFlow Доп.главы Компьютерных сетей Шалимов А.В. 2 Что такое SDN/OpenFlow? Внедрения SDN = Software Defined Networking Основные принципы • • • Физическое разделение уровня передачи данных от уровня управления сетевых устройств. Логически централизованное управление. Программируемость. • Открытый единый интерфейс управления. Преимущества ... • Упрощение управления сетью (OPEX) • Удешевление оборудования (CAPEX) • Разработка ранее недоступных сервисов “SDN means thinking differently about networking” Доп.главы Компьютерных сетей Шалимов А.В. 3 Маршрутизация с SDN/OpenFlow A B A -> B A B • Неизвестный пакет отправляется на контроллер (OF_PACKET_IN). • Контроллер вычисляет лучший маршрут через всю сеть (с наименьшей стоимостью и удовлетворяющий политикам маршрутизации). • Соответствующие правила OpenFlow устанавливаются на коммутаторы + сразу и обратный маршрут (OF_PACKET_OUT/FLOW_MOD). Доп.главы Компьютерных сетей Шалимов А.В. 4 Маршрутизация с SDN/OpenFlow A B A B • Неизвестный пакет отправляется на контроллер (OF_PACKET_IN). • Контроллер вычисляет лучший маршрут через всю сеть (с наименьшей стоимостью и удовлетворяющий политикам маршрутизации). • Соответствующие правила OpenFlow устанавливаются на коммутаторы + сразу и обратный маршрут (OF_PACKET_OUT/FLOW_MOD). • Динамическая переконфигурация в случае ошибки сети. Доп.главы Компьютерных сетей Шалимов А.В. 5 Часть I: OpenFlow контроллеры Доп.главы Компьютерных сетей Шалимов А.В. 6 OpenFlow контроллер • Программа, TCP/IP сервер, ожидающий подключения коммутаторов • Отвечает за обеспечение взаимодействие приложения-коммутатор. • Предоставляет важные сервисы (например, построение топологии, мониторинг хостов) • API сетевой ОС или контроллер предоставляет возможность создавать приложения на основе централизованной модели программирования. Доп.главы Компьютерных сетей Шалимов А.В. 7 Список OpenFlow контроллеров • Их действительно много – Nox, Pox, MUL, Ruy, Beacon, OpenDaylight, Floodlight, Maestro, McNettle, Flower, Runos – Разные языки программирования от Python до Haskell, Erlang • Для образования - Pox. • Два больших комьюнити – ONOS (Stanford) – OpenDayLight (Cisco) • В России – наш Runos – arccn.github.io/runos Доп.главы Компьютерных сетей Шалимов А.В. 8 Архитектура OpenFlow контроллера Маршрутизация, виртуалилазция, мониторинг, балансровка, фильтрация, аутентифкация, NAT, ARP, DNS, DHCP, BGP Алгоритмы на графах, распределенные системы и базы данных, web Многопоточные алгоритмы Быстрая обработка пакетов Требования к контроллеру ПКС • Производительность – Пропускная способность • events per second – Задержка • ЦОД требует обработку >10M событий в секунду • Реактивные контроллеры более “чувствительные” • us • Надежность и безопасность – 24/7 • Программируемость – Функциональность: приложения и сервисы – Интерфейс программирования Полный список контроллеров (2013) • • • • • • • • • NOX-Classic NOX Beacon Floodlight SNAC Ryu POX Maestro Trema • • • • • • • • • Helios FlowER MUL McNettle NodeFlow Onix SOX Kandoo Jaxon • Cisco ONE controller • Nicira NVP Controller • Big Network Controller • IBM Programmable Network Controller • HP SDN Controller • NEC Programmable Flow 11 Экспериментальное исследование • Производительность – максимальное количество запросов на обработку – время обработки запроса при заданной нагрузке • Масштабируемость – изменение показателей производительности при увеличении числа соединений с коммутаторами и при увеличении числа ядер процессора • Надежность – количество отказов за время тестирования при заданном профиле нагрузок • Безопасность – устойчивость к некорректно сформированным сообщениям протокола OpenFlow 12 Стенд 5/30/2013 13 Результаты сравнения (2013) • Максимальная производительность 7 000 000 потоков в секунду. • Минимальное время задержки от 50 до 75 мкс. • Недостатки: – Надежность контроллеров вызывала вопросы – Производительность была не достаточна (DC >10M fps) Часть II: Производительность и программируемость OpenFlow контроллеров Доп.главы Компьютерных сетей Шалимов А.В. 15 Повышение производительности Самые ресурсоемкие задачи: • Взаимодействие с OpenFlow коммутаторами: – использование многопоточности; – учет загрузки нитей и перебалансировка. • Получение OpenFlow пакетов из канала: – чтение пакетов из памяти сетевой карты, минуя сетевой стек OS Linux; – переключение контекста; – виртуальные адреса. Пример: In-kernel контроллер Контроллер был реализован в ядре ОС Linux [2] • Супер производительный – нет переключений контекста при сетевом взаимодействии – меньше времени на работу с виртуальной памятью • Но очень сложно разрабатывать свои приложения – Низкоуровневый язык программирования – Ограниченное число библиотек и средств отладки – Высокий риск “положить” всю систему [2] P. Ivashchenko, A. Shalimov, R. Smeliansky "High performance in-kernel SDN/OpenFlow controller", Proceedings of the 2014 Open Networking Summit Research Track, USENIX, March 3-5, 2014 Santa Clara, USA Производительность (kernel) • Производительность равна 30M fps • Задержка 45us RUNOS – это линейка OpenFlow контроллеров +: большая фунци-ть -: низкая произв-ть Приложения NOX, Pox, Floodlight, OpenDaylight, MUL, etc Сервисы OpenFlow User space Kernel space Что может быть по середине? Приложения Сервисы Приложения Inkernel OpenFlow Архитектура: • Прилож-я в userspace • Часто используемые сервисы +: большая фунци-ть в ядре (топология) +: высокая произв-ть • Интерфейс взаимодействия Сервисы OpenFlow +: высокая произв-ть -: мало функций Варианты исполнения RUNOS Easy RUNOS Приложения Сервисы User space Kernel space Функциональность Производительность OpenFlow NOX, POX, Floodlight, OpenDaylight, OpenMUL Fusion RUNOS Приложения In-kernel RUNOS Сервисы Приложения OpenFlow Сервисы OpenFlow Easy Fusion In-kernel + + - Низкая Высокая Высокая Программируемость • На языке контроллера [быстро] • На любом языке через REST интерфейс [медленно] • Специальные языки программирования с другой абстракцией (например, Pyretic, Maple) Пример REST запроса Доп.главы Компьютерных сетей Шалимов А.В. 22 Проблематика NorthBound API • NorthBound API – интерфейс между контроллером и приложениями • Программирование с OpenFlow не простая задача! – Сложно выполнять независимый задачи (routing, access control) – Низкоуровневая абстракция – Нужно помнить о правилах на коммутаторах – Порядок установки правил на коммутаторах неизвестен • Переносимость приложений между контроллерами Доп.главы Компьютерных сетей Шалимов А.В. 23 Низкоровневые детали OpenFlow Доп.главы Компьютерных сетей Шалимов А.В. 24 Possible problems in OpenFlow controllers Example of the problem with running several apps independently: • Forwarding and Span apps. First app sends a flow over port 1, while second ones sends the same flow over port 5. Rules intersect with each other. • Final rules order in the flow table is unknown. • Packets will go using only the first rule. Thus, only one app will work. Conflict! • We may to resolve such conflicts and some others. Just ip_src:10.0.0.1 -> output:1,5! Forwarding SPAN OpenFlow Rule 1: ip_src:10.0.0.1 -> output:1 Rule 2: ip_src:10.0.0.1 -> output:5 Flow table Rule 1 Rule 2 New packet ip_dst:10.0.0.1 never used Композииция приложений • Два типа композиции (на примере, Pyretic) – Параллельная – выполняет оба действия одновременно (forwarding и couting) – Последовательная композиция – выполняет одно действие за другим (firewall, затем switch) Доп.главы Компьютерных сетей Шалимов А.В. 26 • Pyretic – (match(dstip=2.2.2.8) >> fwd(1)) + (match(dstip=2.2.2.9) >> fwd(2)) Доп.главы Компьютерных сетей Шалимов А.В. 27 Pyretic пример LB • http://frenetic-lang.org/publications/pyretic-login13.pdf Доп.главы Компьютерных сетей Шалимов А.В. 28 Часть III: Runos контроллер Доп.главы Компьютерных сетей Шалимов А.В. 29 Сетевая операционная система RUNOS RUNOS = RUssian Network Operating System • Цель проекта – “Could an OpenFlow controller be both easy to develop applications for and also high performance?” – Разработать систему, которая будет удобна для разработки новых сетевых приложений – При этом помнить о быстроте Коммутатор Версия OpenFlow Arista 7050T-52 OF1.0 NEC PF5240F OF1.0, OF1.3 Extreme X460-24p OF1.0, OF1.3 OpenvSwitch 1.6 и выше OF1.0, OF1.3 Brocade OF 1.3 Huawei OF 1.3 RUNOS: особенности • Проблема запуска нескольких приложений, интеграция с приложениями других разработчиков Приложения Сервисы User – требуется статическая подстройка приложений под OpenFlow space себя, порядок и способ передачи информации между ними. Kernel space – нет механизма контроля и разрешения конфликтов Features: между приложениями (генерация пересекающихся - Algorithmic policies (rule generation) правил). • В RUNOS стоит задача решить указанные выше проблемы: – часть настройки происходит автоматически по мета информации, связывание происходит динамически – разработана система разрешения конфликтов – Широкий набор сервисов для упрощения разработки новых приложений - - Client-friendly API using EDSL grammar (low level details are hidden inside the runtime – overloading, templates) Modules composition (parallel and sequential composition) Параметры запуска Config (json): “controller”: { “threads”: 4 }, “loader”: { “threads”: 3 }, “link discovery”: { “poll-interval” : 10, “pin-to-thread” : 2 }, “learning switch”: { } … • Задается количество нитей контроллера – для взаимодействия со свитчами – для работы приложений • Список приложений – их параметры (poll-interval) – зафиксировать нить выполнения или выделить в монопольное пользование (pin-to-thread, ownthread) Реализация Ключевые слова: C++11, QT, Boost (asio, proto, graph Основные сторонние компоненты: • libfluid project (_base, _msg) – для взаимодействия со свитчами и разбор OpenFlow 1.3 сообщений • libtins – разбор пакетов внутри OpenFlow сообщений • glog (google log) – логирование, многопоточное • tcmalloc (google performance tools) – альтернативная более быстрая реализация malloc/free • json11 – разбор конфигурационного файла • boost graph – Хранение топологии, поиск маршрута Пример графического интерфейса EasyWay • Графический интерфейс: система управления корпоративной сетью Описания релизов Сейчас версия 0.5 • ядро контроллера • построение топологии • построение маршрута через всю сеть • первая версия системы генерации правил • Rest API (совместимый с Floodlight) • WebUI (мониторинг загрузки, просмотр таблиц, удаление и добавление правил) • Проактивная загрузка правил • Холодное резервирование • ARP кеширование Описания релизов Версия 0.6 - следующий большой релиз (конец сентября) • Полное обновление структуры ядра контроллера. Нет привязка к конкретной версии протокола OpenFlow. Своя модель, расширяемая под любые новые поля, в том числе и специфические для оборудования. • Пакетная грамматика для сетевых приложений. Упрощает разработку новых приложений. • Обновление системы генерации правил — повышена скорость работы и улучшена генерация правил (по количетсву правил и числу приоритетов). • Возможность статического связывания модулей. • Система тестов. Проект с открытым исходным кодом • Исходный код http://arccn.github.io/runos/ – Apache, version 2.0 • Tutorial (Readme.md) – Как установить, запустить, написать свое первое приложение • Виртуальная машина – Уже собранный контроллер – Средства для работы с OpenFlow • Список рассылки – Google group runos-ofc Программируемость • Algorithmic policies (rule generation) – Arrangement of priorities of rules, combining of rules – LOAD, MATCH, READ abstractions – MAPLE based • Client-friendly API using EDSL grammar (low level details are hidden inside the runtime – overloading, templates) – – – – – “pkt[eth src] == eth addr” “if (ethsrc == A || ethdst == B) doA else doB” “test((eth_src & “ff0…..0”) == “….”)” “modify(ip_dst >> “10.0.0.1”)” decision are “unicast()”, “broadcast()”, “drop()” • Application composition (parallel and sequential composition) – dpi + (lb >> forwarding) Производительность • Производительность : 10 млн. потоков в секунду • Задержка: 55 мкс Open Source • Два типа OpenSource проектов: – ради Идеи: “Free as in Freedom” – продаем свои компетенции, а не продукт • доработка под нужды заказчика, • продавать advanced версии и плагины (eg, приложения для Runos) • community вокруг (семинары, обучение) • Важна лицензия (*): Apache, BSD или GPL, Eclipse, проприетарные лицензии, перелицензирование за деньги • Угрозы: – Скопируют и будут продавать под другим названием (eg, runos-ng) – Будут дорабатывать своими силами (для компаний с большим R&D) * http://www.slideshare.net/gerasiov/license-44646637 Часть IV: Разработка приложений для Runos контроллер Доп.главы Компьютерных сетей Шалимов А.В. 41 First application – L2 learning A 1 2 3 B B | A | ... A | B | ... L2 learning table 4 Host • What is L2 learning? Switch:port A 1:1 B 3:2 – L2 table – where particularly host resides (host <->sw:port) • A->B. What should we do on sw1? – Learn and broadcast • B->A. What should we do on sw3? – Learn and unicast • Advanced question: will it work for ping utilities? Ping 10.0.0.2 (assuming B has this IP) – Yes, arp (broadcast), ip (icmp) Host Databases .insert(…) L2 forwarding application Пример работы с Runos • Инструментарий – Runos – Mininet • Перейти на виртуальную машину Доп.главы Компьютерных сетей Шалимов А.В. 45 Часть V: Распределенный уровень управления Доп.главы Компьютерных сетей Шалимов А.В. 46 Высокая доступность (High Availability, HA) • Сеть работает в режиме 365/24/7. • Платформа управления ПКС должна работать непрерывно. • Цель обеспечения высокой готовности – поддержание непрерывной работоспособности платформы управления, сетевых приложений. • Причины простоя: обслуживание, программные и аппаратные ошибки, отказы оборудования, атаки, отключение электроэнергии, аварии. Коэффициент готовности, % Время простоя за год 99,999 5 минут 99,99 52 минуты 99,9 8,7 часов 99 3,7 дней Угрозы Потеря соединения коммутатора с контроллером Отказ контроллера Перегрузка контроллера Стратегии резервирования /1 Active/Standby (Passive) стратегии: • Холодное [без синхронизации] • Теплое [периодическая синхронизация] • Горячее [постоянная синхронизация] Восстановление после отказа контроллера для случая горячего резервирования RUNOS Особенности решения: • OpenFlow ≥ 1.0 • Корпоративные сети. • Не масштабируется • Не полная утилизация вычислительных ресурсов + - Одиночный отказ контроллера Потеря соединения коммутатора с контроллером Перегрузка контроллера Стратегии резервирования /2 • Стратегии резервирования Active/Active – Ассиметричная – Симметричная • Высокая сложность [Требуется координация контроллеров, поддержка глобального состояния] • Высокая доступность [минимальное время простоя] • Высокая утилизация вычислительных ресурсов Возможности протокола OpenFlow • Протокол OpenFlow 1.2: – Множество контроллеров – Механизм ролей – Роли: Master, Slave, Equal – По умолчанию: контроллер находится в роли Equal для коммутаторов. – Смена роли: OFPT_ROLE_REQUEST – Распределение ролей: возложено на контроллеры. OpenFlow 1.0, 1.1 OpenFlow 1.2 – 1.5 Модель платформы управления Задачи: 1. Как синхронизовать контроллеры? 2. Как определить начальное распределение коммутаторов по контроллерам? 3. Как перераспределить управление коммутаторами при одиночном отказе контроллера? 4. Как восстановить управление коммутатором при потере соединения с контроллером? 5. Как предотвратить перегрузку контроллера в платформе управления? Предположения модели Предположения: • Все контроллеры имеют одинаковую производительность. • Контроллер устанавливает правила только на те коммутаторы, для которых он является Master контроллером. • Инфраструктура доступа обеспечивает связь коммутаторов с каждым контроллером. Условие корректности решения: • В каждый момент времени для каждого коммутатора в сети должен быть определен только один Master контроллер. Задача 1: Синхронизация контроллеров In-memory хранилище Состояние Network View 1 Контроллер [MASTER] ДКА Журнал событий ... Состояние Network View 1 Контроллер [SLAVE] ДКА Журнал событий Add Flow Add Node Сервис синхронизации Proposer In-memory хранилище Acceptor ... Add Flow Add Node In-memory хранилище Состояние Network View 1 Контроллер [SLAVE] ДКА Журнал событий ... Add Flow Add Node Сервис синхронизации Сервис синхронизации Acceptor Acceptor Событие Сегмент Network 1 • • • Сегмент Network 2 Сегмент Network 3 На основе Multi-Paxos Обеспечивает одновременное одинаковое выполнение команд контроллеров Команды: изменение Network View, установление новых потоков (чтение NV), изменение ролей контроллеров. Задача 2: Начальное распределение коммутаторов по контроллерам • Критерий определения Master-контроллера: – Задержка от коммутатора до контроллера, как мера близости. • Ограничение: на количество коммутаторов в сегменте контроллера. • Решение: Жадный алгоритм по значению задержки от коммутатора до контроллеров. Задача 3: Выработка и представление сценариев восстановления • Проактивная разработка сценариев восстановления • Критерий выбора нового распределения: задержка от коммутатора до контроллера • Алгоритм Балаша. • Результат: перечень сценариев для каждого контроллера платформы управления. Задача 3: Использование сценария для восстановления ПУ после отказа контроллера 1. 2. 3. 4. Оставшимися контроллерами фиксируется факт отказа контроллера и CID. Каждый контроллер выбирает сценарий восстановления, соответствующий отказу контроллера CID. В соответствии со сценарием каждый контроллер изменяет свою роль на коммутаторах. Каждый контроллера информирует остальные контроллеры о завершении выполнения сценария восстановления. Задача 4: Восстановление при потере соединения коммутатора с контроллером ? Отказ коммутатора или потеря соединения? ? 1. 2. 3. 4. 5. Фиксируется отключение коммутатора Masterконтроллером. Инициируется проверка присутствия коммутатора в сети. Осуществляется измерении задержки контроллерами, поддерживающими связь с коммутатором. Master-контроллером становится контроллер с минимальной задержкой до коммутатора. Новый Master-контроллер устанавливает свою роль на коммутаторе. Задача 5: Предотвращение перегрузки контроллера платформы управления Для обнаружения перегрузки: • Устанавливаются пороговые значения параметров загрузки контроллеров. • Осуществляется постоянный мониторинг загрузки контроллеров [количество коммутаторов, количество packetin запросов в секунду, CPU, память] • Факт перегрузки фиксируется при обнаружении превышения порогового значения. Задача перераспределения коммутаторов по контроллерам: Необходимо перераспределить коммутаторы так, чтобы: 1. Нагрузка на каждый из контроллеров не превышала его производительности 2. Использовалось минимальное количество контроллеров. 3. При перестроении управления сетью было проведено минимальное количество передач управления коммутаторами. Задача 5: Передача управления коммутатором • Свойство живучести: В любой момент времени для коммутатора существует контроллер, работающий в режиме Master. Для любой асинхронной команды, контроллер, который ее отправил, остается активным до тех пор, пока коммутатор не закончит ее обработку. • Свойство безопасности: Ровно один контроллер обрабатывает каждое асинхронное сообщение от коммутатора. Задача 5: Распределение коммутаторов по группам • Входные данные: – Топология сети – Количество новых потоков с каждого коммутатора – Максимально допустимая нагрузка на контроллер P • Алгоритм разбиения графа на компоненты связности, чтобы суммарная нагрузка компоненты связности не превышала P. • Выходные данные: – Матрица, определяющая Master-контроллеры для коммутаторов и сегменты управления для каждого контроллера. Задача 5: Распределение групп коммутаторов по контроллерам • Входные данные: – Текущая матрица распределения управления коммутаторами по контроллерам. – Желаемая матрица распределения управления коммутаторами. • Алгоритм: жадный алгоритм, минимизирующий количество передач управления коммутаторами между контроллерами платформы управления. • Выходные данные: – Список операций по передаче управления отдельными коммутаторами. Quiz 2 • На другом слайде Доп.главы Компьютерных сетей Шалимов А.В. 64 Заключение • OpenFlow Tutorial – гуглится • Runos проект предназначен для упрощения разработки новых приложений – В открытом доступе arccn.github.io/runos http://arccn.ru/ ashalimov@lvk.cs.msu.su Доп.главы Компьютерных сетей Шалимов А.В. @alex_shali @arccnnews 65