От Slides Defined к Software Defined Networking. Часть 2
В предыдущей статье мы постарались познакомить читателей с архитектурой и ключевыми моментами SDN-решения Big Cloud Fabric от компании Big Switch Networks. В этой части представляем обзор интерфейсов взаимодействия и функциональных возможностей фабрики.
Интерфейс Big Cloud Fabric
Как было упомянуто в предыдущей части, контроллер фабрики является единой точкой управления, аналитики и интеграции с внешними системами. Несмотря на то, что для настройки, мониторинга, поиска и устранения неисправностей доступны как полнофункциональный CLI, так и чрезвычайно удобный web-интерфейс, они по сути являются клиентами для единого REST API. Многие производители предлагают REST интерфейсы для взаимодействия со своими продуктами, но так получилось, что в мире сетевых устройств они за частую менее функциональны чем CLI/WEB и не дают доступ ко всем функциям и механизмам, что значительно ограничивает возможности их применения. В свою очередь, подход, который был выбран в BCF, полностью исключает потерю функциональности — все что можно сделать в CLI или в web-интерфейсе — доступно к реализации с помощью REST API. Более того, сам процесс использования REST API сделан максимально удобным и простым: достаточно ввести в CLI команду debug rest и для каждой введенной в CLI команды будет выведен метод, путь и тело запроса, а также код и тело ответа. Таким образом, чтобы написать какой-либо скрипт для автоматизации рутинных процессов, нет больше нужды сидеть над документацией (которая тоже существует) — достаточно один раз проделать требуемые операции в CLI и на основании выводов сделать шаблон.
Отдельно хотелось упомянуть о web-интерфейсе управления. Так уж повелось в сетевом мире, что консоль CLI считается наиболее удобным инструментом конфигурирования, поиска и устранения неисправностей. Отчасти это связано с тем, что до появления общепринятых API и возможности выполнения скриптов непосредственно на оборудовании, CLI давал более широкие возможности по автоматизации рутинных операций и зачастую был гораздо информативнее, чем web-интерфейс. Однако, в контроллере BCF web-интерфейс настолько удобен, понятен и функционален, что при проведении тестирования наш инженер практически не прибегал к услугам CLI — все настройки и диагностическая информация были доступны в удобном и понятном графическом интерфейсе. В дополнение к отличной эргономике и понятной логической структуре web-интерфейс содержит множество, казалось бы, незначительных, но очень полезных деталей, которые как раз и формируют чувство удовлетворенности от работы с ним. Например, при добавлении коммутатора необходимо выбрать какую роль он будет занимать в архитектуре (Spine или Leaf). Но если в имени, которое назначается коммутатору, встретится одно из этих слов, роль будет предложена автоматически. Мелочь, а приятно.
Скриншот домашней страницы GUI (изображение кликабельно)
Функциональность Big Cloud Fabric
Когда мы начинали тестирование BCF в лаборатории, была подготовлена методика, основанная на практическом опыте. В нее были включены те функции и механизмы, которые гарантированно встречаются в ЦОД, поскольку мы не были уверены, что достаточно молодой продукт будет обладать теми же возможностями и поддерживать аналогичный набор механизмов и протоколов, что и старожилы рынка телекоммуникаций. Однако уже на первом этапе изучения документации на BCF нам пришлось значительно увеличить объем тестируемых функций, поскольку все они были действительно интересны и востребованы. Но больше всего нас впечатлило то, что все заявленные функции работали как часы — ни один тест не был провален или работал с замечаниями. Вообще, ощущения от работы с BCF можно коротко характеризовать как «быстро, просто и удобно».
Логическая структура BCF состоит из вполне понятных любому сетевому специалисту элементов, и это выгодно отличает BCF от похожих решений других производителей. Структурной единицей логической структуры BCF является tenant, который фактически представляет собой классический VRF. В tenant’ах располагаются широковещательные сегменты и их маршрутизирующие интерфейсы, а связь между ними осуществляется через системный маршрутизатор (системный tenant). В сегментах располагаются оконечные физические или виртуальные хосты (end point). Сопряжение с внешними устройствами можно организовать как посредством статической маршрутизации, так и с помощью протокола BGP. Однако, за такой простотой логической структурой развитая функциональность и гибкость.
Логическая схема Big Cloud Fabric (изображение кликабельно)
В отличие от классических коммутаторов, членами одного широковещательного сегмента могут стать серверы, передающие пакеты с разными VLAN ID, а в тоже время одинаковый VLAN ID может быть отнесен к разным сегментам. Отсутствует необходимость в использовании протоколов резервирования основного шлюза, фактически отсутствует устройство, которое реализует эту функцию, т.е. любой коммутатор фабрики может перезаписать заголовок и передать пакет в другую подсеть. Создаваемые политики доступа и сервисных цепочек (ACL, Policy-based routing) работают в рамках всей фабрики, поскольку связаны не с конкретными коммутаторами или интерфейсами, а с вышележащими логическими структурами.
Насколько мощным и в то же время простым инструментом является BCF, можно судить даже по тому, что коммутация и маршрутизация multicast-трафика в фабрике настраивается лишь переключением ползунка «Multicast Enable» в настройках tenant’а — после этого фабрика может маршрутизировать multicast-трафик между подсетями в пределах выбранного tenant’а, а каждый tenant может оперировать одинаковым набором multicast-групп без риска некорректной передачи пакетов. Сравните это с настройкой маршрутизации multicast в классической, большой сети ЦОД — PIM, IGMP, IGMP snooping — и это на каждом устройстве.
Таким образом, несмотря на отсутствие в технических характеристиках упоминания о знакомых протоколах, централизованная архитектура BCF не только позволяет реализовать любую необходимую функциональность, который необходим в сетях ЦОД, но и значительно расширить ее. Особенно это заметно, когда речь заходит о механизмах мониторинга, поиска и устранения неисправностей, а также об аналитике. Механизм Fabric SPAN позволяет зеркалировать трафик всей фабрики, отфильтрованный по параметрам L2-L4 на любой порт любого коммутатора. Например, задача зеркалирования на инструмент аналитики всего HTTP-трафика фабрики решается созданием одной-единственной политики Fabric SPAN приблизительно за 2 минуты. В классической сети ЦОД решение подобной задачи займет не только существенно больше времени, но и потребует использования дополнительного оборудования.
Другая достаточно распространенная ситуация — нет связанности между двумя серверами по определенному протоколу. В классической сети в этом случае начинается активный поиск неисправностей: ping, traceroute, telnet, анализ таблиц маршрутизации, списков доступа МСЭ и так далее — коробка за коробкой, консоль за консолью. В BCF подобная задача решается просто запуском инструмента Test Path: достаточно указать адреса, протокол и порты источника и назначения и контроллер выдаст в графической форме путь прохождения трафика, точку и описание проблемы, если она есть. При этом у инструмента есть 2 режима работы: результаты первого основаны на анализе таблиц, которые построил и загрузил на коммутаторы контроллер, а второй проверяет, как происходит обработка требуемого пакета на каждом коммутаторе и таким образом получается реальная картина движения трафика. Процесс поиска и устранения неисправностей с помощью инструмента Test Path, как правило, занимает не больше минуты и производится из единого графического интерфейса.
Скриншот инструмента Test Path (изображение кликабельно)
Отдельно хотелось бы рассказать о возможностях фабрики по сбору, обработке и предоставлению аналитической информации. Опять же благодаря архитектуре BCF c централизованным Control Plane, контроллер является единой точкой, куда стекаются «сырые» данные об состоянии аппаратной части коммутаторов, счетчиках интерфейсов, ошибках, логах и т.п. Контроллер обрабатывает полученную информацию, коррелирует события между собой, хранит историю и представляет полученный результат в удобной, настраиваемой форме. Анализу доступны как события, происходящие в физической инфраструктуре (проблемы портов, аппаратные проблемы, высокозагруженные интерфейсы и т.п.), так и события логической структуры (включение/выключение/перемещение виртуальной машины, интенсивность трафика по хостам/сегментам и т.п.). Фактически, совместно с сетевой инфраструктурой ЦОД мы получаем мощную систему аналитики, без дополнительных вложений в сервера сбора и анализа логов, а также базы данных.
Скриншот аналитической системы Big Cloud Fabric (изображение кликабельно)
