![](https://habrastorage.org/files/84d/70d/d4e/84d70dd4e3654d0d8bd1835e8c34b050.jpg)
В предыдущей статье мы постарались познакомить читателей с архитектурой и ключевыми моментами 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. Однако, за такой простотой логической структуры стоит развитая функциональность и гибкость.
![](https://habrastorage.org/files/ede/915/7bf/ede9157bf96848cf95c45632c59c74f2.jpg)
Логическая схема Big Cloud Fabric (изображение кликабельно)
В отличие от классических коммутаторов, членами одного широковещательного сегмента могут стать серверы, передающие пакеты с разными VLAN ID, а в тоже время одинаковый VLAN ID может быть отнесен к разным сегментам. Отсутствует необходимость в использовании протоколов резервирования основного шлюза, фактически отсутствует устройство, которое реализует эту функцию, т.е. любой коммутатор фабрики может перезаписать заголовок и передать пакет в другую подсеть. Создаваемые политики доступа и сервисных цепочек (ACL, Policy-based routing) работают в рамках всей фабрики, поскольку связаны не с конкретными коммутаторами или интерфейсами, а с вышележащими логическими структурами.
![](https://habrastorage.org/files/544/2bf/9d1/5442bf9d1ba64a2ca6db75a32a3f72b3.png)
Таким образом, несмотря на отсутствие в технических характеристиках упоминания о знакомых протоколах, централизованная архитектура BCF не только позволяет реализовать любую необходимую функциональность, который необходим в сетях ЦОД, но и значительно расширить ее. Особенно это заметно, когда речь заходит о механизмах мониторинга, поиска и устранения неисправностей, а также об аналитике. Механизм Fabric SPAN позволяет зеркалировать трафик всей фабрики, отфильтрованный по параметрам L2-L4 на любой порт любого коммутатора. Например, задача зеркалирования на инструмент аналитики всего HTTP-трафика фабрики решается созданием одной-единственной политики Fabric SPAN приблизительно за 2 минуты. В классической сети ЦОД решение подобной задачи займет не только существенно больше времени, но и потребует использования дополнительного оборудования.
Другая достаточно распространенная ситуация – нет связанности между двумя серверами по определенному протоколу. В классической сети в этом случае начинается активный поиск неисправностей: ping, traceroute, telnet, анализ таблиц маршрутизации, списков доступа МСЭ и так далее — коробка за коробкой, консоль за консолью. В BCF подобная задача решается просто запуском инструмента Test Path: достаточно указать адреса, протокол и порты источника и назначения и контроллер выдаст в графической форме путь прохождения трафика, точку и описание проблемы, если она есть. При этом у инструмента есть 2 режима работы: результаты первого основаны на анализе таблиц, которые построил и загрузил на коммутаторы контроллер, а второй проверяет, как происходит обработка требуемого пакета на каждом коммутаторе и таким образом получается реальная картина движения трафика. Процесс поиска и устранения неисправностей с помощью инструмента Test Path, как правило, занимает не больше минуты и производится из единого графического интерфейса.
![](https://habrastorage.org/files/343/e31/a6d/343e31a6dad04c38b65ef6788b522a5d.png)
Скриншот инструмента Test Path (изображение кликабельно)
Отдельно хотелось бы рассказать о возможностях фабрики по сбору, обработке и предоставлению аналитической информации. Опять же благодаря архитектуре BCF c централизованным Control Plane, контроллер является единой точкой, куда стекаются «сырые» данные об состоянии аппаратной части коммутаторов, счетчиках интерфейсов, ошибках, логах и т.п. Контроллер обрабатывает полученную информацию, коррелирует события между собой, хранит историю и представляет полученный результат в удобной, настраиваемой форме. Анализу доступны как события, происходящие в физической инфраструктуре (проблемы портов, аппаратные проблемы, высокозагруженные интерфейсы и т.п.), так и события логической структуры (включение/выключение/перемещение виртуальной машины, интенсивность трафика по хостам/сегментам и т.п.). Фактически, совместно с сетевой инфраструктурой ЦОД мы получаем мощную систему аналитики, без дополнительных вложений в сервера сбора и анализа логов, а также базы данных.
![](https://habrastorage.org/files/ec1/7d3/c7c/ec17d3c7c28d4827ad0fb544d4edfb5f.png)
Скриншот аналитической системы Big Cloud Fabric (изображение кликабельно)
Поделиться с друзьями
dsaks
Удобное решение, особенно в части обьединения ЦОД на layer2. Но вот в версии 3.6.1 содержит косяк с autonegotiation, благо откат на предыдущую версию занял всего 15 минут. Но, как только такой косяк проявился, ни о каком «безостановочном» апдейте, как это заявлено производителем, речи нет :( обидно, однако.
aleks_shi
Хм, интересная проблема. Мне казалось, что согласование работает ниже уровнем, где то в драйверах самого white box'а. Правильно я понимаю, что речь идет о медных SFP?
dsaks
Ну, то что уровнем ниже, то возможно. Речь, как ни странно, про fiber 1g (Finsar FTLF1318P2BCL). Но вот ранее (в версии 3.5.2) это решалось из интерфейса одним кликом — а теперь (в 3.6.1) не решается никак со стороны BCF. Accton AS6700 в качестве spine, Accton AS5710 в качестве leaf. Поскольку структура сложная, и сразу все оборудование не заменить, встречаются линки со старинными Nortel 5520. Вот на таких линках проблема и вылезла. Решения пока не нашли (оббегать все нортел-ы и менять вручную с консоли negotiation — не предлагать, умрем бегаючи, да и время на апдейт очень ограничено).
aleks_shi
Да уж, странно. Но, на мой взгляд, так как автосогласование на оптическом 1GE интерфейсе, не несет никакой практической пользы (разве что согласование для 802.3x), может попробовать отключить его на Nortel, а потом уже обновиться в выделенное окно.
А в целом — каковы впечатления от эксплуатации? Нам удалось пока только протестировать, в эксплуатации больше интересных моментов всплывает.
dsaks
Ну вот еще одно интересное впечатление — 100M Copper не поддерживается. От слова вообще. И куда теперь подключить всякие MGMT интерфейсы и прочие древние и не очень девайсы ( как то мониторинг состояние racks, power modules и прочее) — не очень понятно.
В плане интеграции с виртуальными средами — мы пока до этого не дошли, нам бы с физикой справиться.
aleks_shi
Ну это, на мой взгляд, ограничение как раз bare-metal коммутатора и его ASIC, а не операционной системы. Хотя с таким буфером как у Trident 2 трудно передать без потерь информацию размером больше 300 кБ с 10GE на FE интерфейс:)