CC BY
13
УДК 004.75
Ю.А. Ушаков, доцент кафедры геометрии и компьютерных наук, кандидат технических наук, доцент, ФГБОУ ВО «Оренбургский государственный университет»
А.Л. Коннов, доцент кафедры управления и информатики в технических системах, кандидат технических наук, доцент, ФГБОУ ВО «Оренбургский государственный университет»
П.Н. Полежаев, преподаватель кафедры компьютерной безопасности и математического обеспечения информационных систем, ФГБОУ ВО «Оренбургский государственный университет» e-mail: andrey_konnov@mail.ru
CБОР И ОБОБЩЕНИЕ ИНФОРМАЦИИ C СЕТЕВЫХ УСТРОЙСТВ И ВИРТУАЛЬНЫХ СЕТЕВЫХ МОДУЛЕЙ В РАМКАХ СЕГМЕНТА СЕТИ NFV
Предмет. Сбор и анализ информации о работе сетевых устройств.
Цели. Формирование подхода при создании сети распределенных виртуализированных модулей сбора информации.
Актуальность. Сетевая инфраструктура многие годы была довольно статической с точки зрения технологий. Новые стандарты и протоколы внедряются крайне медленно. Поэтому задача формирования подхода при создании сети распределенных виртуализированных модулей сбора информации является актуальной.
Методология. Подход состоит в создании сети распределенных виртуализированных модулей сбора информации, которые поставляют все сведения в единый центр управления сетью на основе OpenFlow контроллера и соответствующих модулей.
В результате исследований подхода по выносу первой линии мониторинга в виртуальные среды было проведено исследование применимости и целесообразности, получены результаты по масштабируемости системы и нагрузке в различных режимах работы.
Выводы. Полученные результаты свидетельствуют о пропускной способности системы до нескольких десятков устройств на один виртуальный модуль мониторинга. При этом отсутствует дефрагментация трафика и нет нарушений в работе очередей.
Ключевые слова: виртуальные сети, программно-конфигурируемые сети, nfv-сети, мониторинг сети.
Введение
Сетевая инфраструктура многие годы была довольно статической с точки зрения технологий. Новые стандарты и протоколы внедряются крайне медленно и неохотно, особенно это видно на примере провайдеров и стека IPv6. До сих пор большая часть провайдеров России не поддерживает выдачу клиентам IPv6 адресов, несмотря на то, что технология в корпоративном секторе существует довольно давно и успешно. Особенно трудно внедряются новые подходы к самой инфраструктуре, как, например, концепция программно-конфигурируемых сетей (SDN, software-definednetworks) [9]. Но некоторые новые подходы подхватили инфраструктурные провайдеры и довольно успешно и быстро внедряют. Это облачные технологии.
Основной проблемой провайдеров на сегодняшний день является все убыстряющееся снижение доходов при повышении трафика в сети. Большей частью это происходит из-за того, что клиентам требуются услуги и сервисы, а не просто передача данных. Провайдеры, которые не начнут внедрять новые типы сервисов, которые позволят занять долю рынка контента, превратятся в поставщиков услуг передачи информации и специализированные строительно-монтажные организации [1].
Основой новых сетей предоставления сервисов является концепция виртуализации сетевых функций (NFV, Networkfunctionvirtualization) в рамках виртуализованной инфраструктуры NFVI (NFVInfrastructure). Данная концепция подразумевает вынос всех сетевых и смежных сервисов в единую платформу на основе виртуальных машин, запускаемых по запросу [2]. NAT, DHCP, DNS, межсетевой экран, DPI, VPN и прочие сервисы уже давно доступны в виде виртуальных машин. При использовании облачных платформ, таких как OpenStack, VmwareVSphere/NSX, Opennebula и подобных, возможен запуск и преднастройка таких сервисов по запросу в любых доступных масштабах и месторасположениях. Использование универсальной коммутации OpenFlow, VXLAN или VPLS позволяет пропускать трафик через эти модули, предоставляя только те услуги конкретному клиенту, которые он заказал. Это, с одной стороны, позволяет снизить затраты на обеспечение инфраструктуры, с другой стороны, снизить цену на услуги и занять более привлекательные рынки.
Постановка проблемы
При использовании подхода NFV к предоставлению услуг коммуникационных сетей встает проблема быстрого мониторинга и получение ин-
формации из таких сетей. Рассмотрим типичную схему платформы предоставления услуг по запросу на основе типовых схем реализации стоек с оборудованием ведущих производителей [5] (рисунок 1).
Как видно из схемы, коммутатор TopofRack
(TOR) является распределительным для целой серии виртуальных коммутаторов, которые также могут быть вышестоящими для коммутаторов виртуальных подсетей. Эта схема существенно усложняет снятие информации с таких устройств и ее интерпретацию [10].
Рисунок 1. Схема типовой стойки для облачных услуг
В качестве виртуальных коммутаторов чаще всего используются или продукты, входящие в состав систем виртуализации (vSwitch, Openvswitch, Hyper-Vswitch), или специально разработанные решения для виртуальных сред (CiscoNexus-V, DPDKOVS, HPE-v, IBMDVS). Также в Blade системах присутствует Blade-коммутатор со своими особенностями и настройками. В результате проследить где, например, изменилось значение поля DSCP для обеспечения QoS или отследить реальный путь пакета в MSTP деревьях очень сложно. Но, как показано в [10], такой подход выгоден с точки зрения цены коммутации - одно ядро процессора может обеспечить трафик до 1Гбит/с, а режиме DPDK - до 9 [7].
Методы решения
Предлагаемый подход универсализирует получение информации о топологии и связях виртуальных и реальных коммутаторов, а также позволяет получать от них информацию для мониторинга, статистики, анализа сбоев и поиска мест возникновения ошибок. Подход состоит в создании сети распределенных виртуализированных модулей сбора информации, которые поставляют все сведения в единый центр управления сетью на основе OpenFlow контроллера и соответствующих модулей. Использование OpenFlow протокола оправдано в случае интеграции сети с платформой виртуализации, такой как OpenStack и подобных, поскольку такие платформы уже имеют модули взаимодействия с OpenFlow контроллером для
управления сетевой связностью запускаемых виртуальных машин.
Виртуальные коммутаторы Openvswitch, CiscoNexus-V, Hyper-VVirtualSwitch и другие уже поддерживают OpenFlow для управления и мониторинга, коммутаторы TOR от Cisco, HP, Juniper, ExtreamNetworks и прочие также могут использовать OpenFlow протокол для управления. Благодаря единой точке получения информации и протоколам, подобным LLDP, контроллер OpenFlow может видеть не только полную топологию связей, но и карту трафика в каждой точке. Это открывает новые возможности для поиска проблем и для управления коммутацией. Однако все это затрудняет получение статистической/журнальной информации для использования тем же контроллером.
Все аппаратные коммутаторы имеют те или иные ограничения на реализацию протокола OpenFlow и связанные с ним технологии. Мониторинг состояния каналов, объемов трафика, длин очередей, загрузки процессоров и памяти, количества ошибок на физическом уровне - все это реализовано зачастую не полностью или вообще недоступно для Openflow. Виртуальные коммутаторы более приблизились к полноценной поддержке OpenFlow. Но если требуется получать статистику по сетевым протоколам, портам TCP или, например, конкретным IP, то эффективность Openflow становится очень низкой. Лучшими решениями в таких
областях до сих пор остаются специализированные протоколы типа NetFlow, sFlow, а для статистики SNMP. Но эти протоколы требуют прямого доступа к коммутатору и в случае с анализом пакетов широкого канала связи. На рисунке 2 показана схема трафика различных источников информации.
Предлагаемый подход позволит, во-первых, приблизить анализатор к источнику трафика и, во-вторых, преобразовать информацию в единый формат хранения и анализа SIEM системы.
На рисунке 3 показана схема централизованного сбора информации.
Рисунок 2. Схема потоков при использовании разных протоколов мониторинга
TOR Switch
SNMP
OpenFlow
Syslog
sFlow M-
SNMP
OpenFlow
Syslog
sFlow M-te
L3 Switch
'xlanm
4аццЫе
SNMP OpenFlow Syslog sFlow
SIEM/ Nagios
Рисунок 3. Система сбора информации
SIEM система выбрана в качестве входной точки агрегации по причине совей универсальности и всеядности в области анализа и хранения информации. Использование различных каналов входа позволяет не привязываться только к одному формату данных и в будущем позволит расширить область мониторинга.
Трафик SNMP рассчитывается по следующей формуле:
i<jy i<Pr>rts, kKStatSj
£ Sizeof(OIDt),
¡=1 j=1 k=1
где csnmp - общая требуемая пропускная способность;
N - количество оборудования;
Portsi - количество интерфейсов коммутатора i;
Statsj - количество типов статистики, снимаемых с коммутатора i ;
OIDk - полное содержание статистики k;
Sizeof(OIDk) - определение размера OIDk.
При этом количество требуемых пакетов зависит от версий протокола SNMP, используемых механизмов аутентификации и IPSEC (с авторизацией или без, с проверкой подлинности или без и т.д.). При максимальном использовании всех возможностей протокола, на 1 запрос будет уходить:
а) При установке/разрыве соединения на TLS Handshake - 11 пакетов, из них 5 от клиента, 6 от сервера [6].
б) На запрос SNMP по UDP - 2-4 пакета (в зависимости от размера ответа и типа запроса).
в) На запрос SNMP по TCP - в дополнении
к 2-4 пакетам еще 5-7 пакетов на работу протокола TCP (в зависимости от размера ответа и типа запроса).
Итого в самом большом обмене может участвовать до 22 пакетов на 1 запрос. Расчет требуемой полосы пропускания для служебного трафика мониторинга нужен для минимизации влияния этого трафика на общие показатели сети. Поэтому нужно использовать механизмы оптимизации трафика - SNMPPoling[4], сжатие gzip, агрегация потоков sFlow/NetFlowи подобные. В [7] показано, что при включении шифрования трафика мониторинга и периодическом обращении за информацией по интерфейсам при 100 портах задержка получения информации может достигать 4 секунд, при этом служебная часть трафика составляет до 25 %, количество передаваемой информации - от 100 до 568 байт на 1 запрос на 1 порт. Общий трафик SNMPнебольшой - около 5-6 КБ на одну серию запросов к 100 портам, но большое количество маленьких пакетов и частота запросов могут существенно дефрагментироватьтрафик и нарушить работу QoSочередей.
Эксперимент
Для эксперимента была построена небольшая NFV сеть на платформе OpenNebula, в качестве виртуальных коммутаторов выступил Openvswitch, TOR коммутаторами были HP2924 и Aruba2930.
На платформе виртуализации были запуще-
ны модули сетевого тестирования на основе iPerf и nmap, которые создавали трафик и были приемниками для других подобных модулей. Целью эксперимента было:
1. Показать работоспособность и целесообразность идеи с выносом приемников мониторинга ближе к оборудованию.
2. Измерить накладные расходы, связанные с дополнительными анализаторами.
3. Измерить производительность системы мониторинга.
В качестве систем сбора и анализа были выбраны LogAnalyze для получения текстовой информации (включая SNMPTrap, IDS и журналы оборудования). Для анализа пакетов был использован Nagios с модулями NetFlow и sFlow, а также NetFlowAnalyzer для анализа сырых пакетов и генерации статистики независимо от систем мониторинга. Общая схема стенда показана на рисунке 4.
Коммутаторами управлял контроллер RYU с модулями L3_switch и OFCTL_rest [3]. Для снятия данных мониторинга был создан маркер пакетов, маркер привязан к виртуальным машинам мониторинга таким образом, чтобы не влиять на общий трафик [8].
Мониторинг по SNMP включал в себя получение загрузки всех интерфейсов в обе стороны, размеров очередей, памяти и процессора коммутатора (не применимо к OVS).
Рисунок 4. Схема стенда
Мониторинг пакетов проводился по протоколу sFlow. Сервер управления (Managementserver) давал задание на начало и конец генерации трафика, а также обнулял маршруты и статистику.
Эксперимент проводился с количеством виртуальных коммутаторов 4 и количество модулей 8. Для проверки масштабирования были достигнуты
показатели в 128 OVS коммутаторов и 256 виртуальных КУМ модулей. На рисунке 5 показан график зависимости нагрузки на модули мониторинга, а также их процентный вклад в потребление ресурсов на серверах.
На рисунке 6 показаны графики трафика мониторинга. Как видно из графика, потребление памяти
Рисунок 5. Масштабирование системы мониторинга
Рисунок 6. Трафик при мониторинга
растет нелинейно, а доля потребления процессора одинакова для разных значений нагрузки.
В результате можно сделать вывод о целесообразности применения данного подхода в больших сложных гетерогенных средах с высоким проникновением виртуализации.
Выводы
В результате исследований подхода по выносу первой линии мониторинга в виртуальные сре-
ды было проведено исследование применимости и целесообразности, получены результаты по масштабируемости системы и нагрузке в различных режимах работы. Полученные результаты свидетельствуют о пропускной способности системы до нескольких десятков устройств на один виртуальный модуль мониторинга. При этом отсутствует дефрагментация трафика и нет нарушений в работе очередей.
Литература
1. Герасимов, А.В. Перспективы создания сетей программно-определяемых дата-центров в России [Электронный ресурс] /А.В. Герасимов // Конференция ЦОД. - Москва, 2015. - Режим доступа: http:// dcforum.ru/sites/default/files/14.10-14.30_prezentaciya_gerasimov.pdf - (дата обращения: 22.06.2017).
2. Герасимов, А.В. Методика стратегического управления развитием SDN&NFV-сети оператора связи и услугами на ее основе / А.В. Герасимов, Е.В. Лашманов // Материалы собрания консорциума SDN. -МГТУ МИРЭА, 2017.
3. Built-in Ryu applications. ryu.app.ofctl_rest [Электронный ресурс] / Nippon Telegraph and Telephone Corporation. - Режим доступа: http://ryu.read-thedocs.io/en/latest/app/ofctl_rest.html - (дата обращения: 22.06.2017).
4. Cheikhrouhou, M. An Efficient Polling Layer for SNMP [Электронный ресурс] / M. Cheikhrouhou, J. Labetoulle. - Режим доступа: http://www.eurecom.fr/en/publication/361/download/ce-cheimo-000414.pdf -(дата обращения: 22.06.2017).
5. Data Center Top-of-Rack Architecture Design [Электронный ресурс] - Режим доступа: http://www.dsco.
com/c/en/us/products/collateral/switches/ nexus-5000-series-switches/white_paper_c11-522337.html - (дата обращения: 22.06.2017).
6. Du, X. Implementation and Performance Analysisof SNMP on a TLS/TCP Base [Электронный ресурс] / X. Du., M. Shayman, M. Rozenblit. - Режим доступа: http://www.ece.umd.edu/~shayman/papers.d/snmp.pdf -(дата обращения: 22.06.2017).
7. Jan Scheurich. OvS-DPDK performance optimizations to meet Telco needs [Электронный ресурс] / Jan Scheurich, Mark Gray. - Режим доступа: http://open-vswitch.org/support/ovscon2016/8/1400-gray.pdf - (дата обращения: 22.06.2017).
8. Large flow marking using hybrid OpenFlow [Электронный ресурс] - Режим доступа: http://blog.sflow. com/2014/01/large-flow-marking-using-hybrid-openflow.html - (дата обращения: 22.06.2017).
9. Obraczka, Katia. SDN, NFVand their role in 5G.IEEE SIGCOMM 2016 [Электронный ресурс] / KatiaObraczka, Christian Rothenberg, Ahmad Rostami. - Режим доступа: http://www.dca.fee.unicamp. br/~chesteve/ppt/SIGCOMM16 -Tutorial-5G-SDN-NFV-part1.pdf - (дата обращения: 22.06.2017).
10. Paul Emmerich. Performance Characteristics of Virtual Switching [Электронный ресурс] / Paul Emmerich, Daniel Raumer, Florian Wohlfart //IEEE 3rd International Conference on Cloud Networking (CloudNet). -2014. - Режим доступа:https://www.net.in.tum.de/publications/papers/Open-vSwitch-CloudNet-14.pdf - (дата обращения: 22.06.2017).
Исследование проведено при поддержке Российского фонда фундаментальных исследований, грант №16-29-09639 и №15-07-06071.
