Александр Шилкин. «От Slides Defined к Software Defined Networking: обзор коробочного SDN-решения»

Каждый из нас слышал о концепции программно-определяемых сетей (Software Defined Networking, SDN). Однако, несмотря на непрерывное развитие и ряд значительных изменений, эта концепция долгое время не имела воплощения в виде коммерчески состоявшихся продуктов, по сути, оставаясь на уровне slides defined, т. е. в виде умозрительных конструкций в презентациях вендоров и интеграторов. В свете этого неудивительно, что чрезмерно активное обсуждение темы SDN в последние годы вкупе с отсутствием полностью рабочих решений на рынке привело если не к отторжению, то точно к критическому отношению к этой технологии со стороны части ИТ-сообщества.

Александр Шилкин, системный инженер компании INLINE Technologies, пытается развеять этот скепсис и рассказывает о сетевой фабрике, которая соответствует классическим критериям SDN и в то же время является полностью законченным, «коробочным» решением. Автор сознательно избегает глубокого погружения в технику и акцентирует внимание на возможностях, которые может принести данное решение.

Вступление

В отличие от устоявшихся технологий построения распределенных корпоративных и кампусных сетей подходы к организации сети ЦОД непрерывно развиваются. Отчасти это связано со значительным ростом требований со стороны приложений и смежных систем. Так, для работы приложений необходима все большая пропускная способность, ужесточаются требования к предсказуемости задержки, а также различным параметрам передачи трафика, что приводит к пересмотру применяемых механизмов и топологий. Смежные системы (в частности, системы виртуализации и оркестрации), в свою очередь, требуют более широких возможностей по интеграции и автоматизации, позволяющих влиять на процессы, происходящие в сети.

Концепция Software Defined Networking призвана решить большинство проблем с интеграцией и автоматизацией за счет использования единой точки управления и контроля сети. Эти же принципы должны помочь значительно снизить зависимость пользователя от вендора – до сих пор в сетевом мире производитель, как правило, является единственным поставщиком ПО к своему оборудованию, несмотря на то, что оборудование создается на базе типовых элементов, производимых сторонними компаниями.

В свою очередь, развитие рынка специальных микросхем (ASIC) и сетевого оборудования привело к появлению на рынке коммутаторов без установленной операционной системы (Bare-metal Switch, BM-коммутаторы), для которых обеспечивающая основную функциональность операционная система разрабатывается другими компаниями, а также устройств с предустановленной ОС, но с возможностью ее замены (White Box). Стоимость и тех, и других коммутаторов значительно ниже, чем их брендированных аналогов, и у клиента появляется возможность выбора операционной системы. Кроме того, ускорилось развитие сетевых операционных систем, поддерживающих различные аппаратные платформы (Cumulus Linux, Pica8, SwitchLight OS). Это стало возможным благодаря предоставлению производителем ASIC API для взаимодействия, а также появлению стандартизированного загрузчика ONIE. Однако, к сожалению, подавляющее большинство таких SDN-продуктов представляет из себя некий конструктор, предлагающий самостоятельно собрать решение из доступных частей (коммутаторов, контроллеров, ПО). Возможно, использование подобных наборов является приемлемым для компаний, обладающих значительным штатом технических специалистов, но для большинства организаций такой подход неудобен.

Между тем недавно нашей компании удалось протестировать решение по построению сети ЦОД Big Cloud Fabric (BCF) от компании Big Switch Networks, которое отличается куда большей дружественностью по отношению к пользователю. Big Cloud Fabric является классическим SDN-решением: в нем используются BM-коммутаторы в качестве аппаратной инфраструктуры сетевой фабрики и централизованный набор функций сетевого оборудования (Control Plane), обеспечивающий взаимодействие по сетевым протоколам, расчет топологии сети и другие операции и вынесенный на отдельный контроллер. На контроллер также возлагаются функции обработки маршрутной информации, изучения подключенных хостов, а также конфигурирования и управления всеми функциями системы. Результаты работы контроллера синхронизируются между коммутаторами и напрямую заносятся в аппаратные таблицы ASIC. И при этом BCF является полностью законченным, «коробочным» решением, которое не требует от пользователя долгой и трудной интеграции компонентов между собой.

Давайте подробнее рассмотрим, как работает решение на основе столь нетипичного подхода и какие возможности оно может предложить пользователям.

Архитектура Big Cloud Fabric

Что из себя представляет Big Cloud Fabric? Если попробовать коротко сформулировать определение, то наиболее подходящим будет следующее: BСF – это сеть передачи данных ЦОД с возможностью использования BM-коммутаторов, находящихся под единым контролем, и обладающая единым интерфейсом взаимодействия для управления, аналитики и интеграции.

В основе BCF лежит сеть Ethernet-коммутаторов, построенная по топологии Spine and Leaf. Эта топология в настоящее время является наиболее востребованной для построения сетей ЦОД, поскольку оптимизирована для передачи трафика типа «east-west», обеспечивает низкий уровень переподписки и предсказуемую, постоянную задержку. Так, например, в классической двухуровневой топологии, где к двум EoR-коммутаторам подключается некоторое количество ToR-коммутаторов, при выходе из строя одного из EoR переподписка сразу же увеличивается в 2 раза, а выход из строя второго полностью выводит сеть из строя. В случае же топологии Spine and Leaf, например с 4 spine-коммутаторами, выход из строя одного из них увеличивает переподписку лишь на 33 %, при этом количество промежуточных узлов для любых 2 хостов сети всегда одинаково. Использование топологии Spine and Leaf в BCF, в частности, позволяет любые два leaf-коммутатора объединять в MC-LAG-пару (Leaf Group, в терминологии BCF).

В отличие от других решений в BCF можно использовать коммутаторы разных производителей, поддерживающие установку сетевых операционных систем. С технической точки зрения, эти коммутаторы ничем не отличаются от привычных брендированных моделей. Они используют те же самые аппаратные компоненты – центральный процессор, память и коммерчески доступный ASIC. Однако вместо операционной системы производители BM-коммутаторов устанавливают загрузчик ONIE – небольшую системную утилиту, которая обеспечивает загрузку и установку любой совместимой сетевой операционной системы. Подобный подход дает значительную гибкость при построении сети, поскольку обеспечивает возможность выбора аппаратной платформы независимо от используемого программного обеспечения.

В фабрике могут поддерживаться любые коммутаторы, построенные на ASIC Broadcom Trident II/II+ и Tomahawk, что составляет большинство производимых на данный момент коммутаторов ЦОД (как классических, так и Bare-metal/White Box). В официальный список поддерживаемых моделей входят различные коммутаторы Dell Networks и Accton/Edge-Core. Это связано с тем, что Big Cloud Fabric – это не набор коммутаторов, независимо работающих друг с другом, а единая фабрика, имеющая централизованное управление и контроль. Именно поэтому протестированная совместимость всех компонентов чрезвычайно важна для безотказной работы всей сети. Вместе с тем компания Big Switch Networks регулярно пополняет список поддерживаемых коммутаторов.

Коммутаторы сами по себе бесполезны без операционной системы, которая могла бы ими управлять. В случае BCF все элементы управления, контроля и интеграции со сторонними системами вынесены на специальное устройство – контроллер фабрики. В его задачи входят все функции управления и контроля – предоставление интерфейса доступа к фабрике, сбор информации о подключенных хостах, расчет топологии, синхронизация информации для программирования аппаратных таблиц между коммутаторами, а также многое другое. На коммутаторы устанавливается легковесная операционная система Switch Light OS, которая предназначена для получения инструкций от контроллера и непосредственного программирования их в ASIC коммутатора, а также сбора «сырых» данных статистики и отправки их на контроллер для анализа. При этом сетевому администратору не нужно вручную устанавливать ОС на коммутатор – BCF поддерживает механизм Zero Touch Provisioning, благодаря которому коммутатор после подключения к сети управления автоматически определяется контроллером и на него устанавливается ОС и шаблоны конфигурации. Информация между коммутаторами и контроллером передается посредством сильно видоизмененного протокола OpenFlow.

Легковесная операционная система Switch Light OS, используемая в BCF, основана на известном проекте Open Network Linux (ONL, часть Open Compute Project). ONL представляет собой оптимизированный дистрибутив Debian с большим количеством драйверов для периферийных устройств (SFP, FAN, GPIO, ASIC), а также минимальным набором утилит. Как самостоятельный продукт ONL применяется редко, но используется как база для развития и построения более мощных проектов. По сути, Switch Light OS – это собственный OpenFlow-агент Big Switch Networks, запущенный в Open Network Linux.

Если проводить напрашивающуюся аналогию с модульным коммутатором, то коммутаторы – это линейные карты (leaf) и коммутационные модули (spine), а контроллер – это супервизор большого территориально распределенного коммутатора. Для обеспечения отказоустойчивости фабрикой управляет кластер из минимум 2 узлов, а сеть взаимодействия между контроллером и коммутаторами реализуется в виде отдельной (out of band) инфраструктуры.

Big Cloud Fabric доступна в двух вариантах: полностью физической фабрики (P Fabric) и гибридной (P+V Fabric). Последний вариант предполагает возможность установки программного агента Switch Light VX (по сути, той же Switch Light OS) для программных коммутаторов Open vSwitch в виртуальной среде KVM. Switch Light VX работает в пользовательском окружении и не оказывает никакого влияния на ядро гипервизора. В его задачи входит синхронизация политик пересылки трафика с контроллером фабрики и реализация их в Open vSwitch. Фактически в BM-коммутаторах Swith Light OS опирается на «мускулы» ASIC, а в виртуальной среде – на ЦП и Open vSwitch. Таким образом, благодаря наличию агента в виртуальной среде не только оптимизируется пересылка трафика (коммутация и маршрутизация между виртуальными машинами выполняется на физическом хосте без передачи на внешнее устройство), но и появляется возможность применения политик и сбора аналитики в виртуальной среде.

На данный момент реализация P+V Fabric возможна только в архитектуре OpenStack/KVM, поскольку последняя является открытой. Для других гипервизоров доступна P Fabric. Однако возможности по интеграции с VMware vCenter/vSphere (о которых чуть ниже) полностью компенсируют данные неудобства.

Необходимо еще раз отметить, что в отличие от похожих продуктов других производителей контроллер является элементом, который полностью управляет коммутаторами фабрики, производит расчеты топологии, отношений соседства протоколов маршрутизации с внешними устройствами и синхронизирует состояния аппаратных таблиц. Это не система управления, которая лишь собирает конфигурационные данные и на их основании настраивает коммутаторы. Это не система мониторинга, периодически (или по запросу) опрашивающая устройства и собирающая лишь ту информацию, которую они могут предоставить по стандартным протоколам. Это настоящий Control Plane фабрики — контроллер имеет полную картину сети, поскольку он сам ее создает. Через ОС на коммутаторах он имеет доступ напрямую к ASIC, и именно поэтому скорость реакции у BCF выше, а аналитика на порядок подробнее, чем у конкурирующих продуктов.

В связи с такой значимой ролью контроллера в инфраструктуре фабрики возникает резонный вопрос: что будет, если все элементы кластера выйдут из строя и фабрика останется без Control Plane? Как оказывается, ничего страшного не произойдет. Оставшись без контроллера (headless mode), фабрика продолжит работать в обычном режиме и будет корректно обрабатывать трафик уже изученных хостов и даже некоторые виды отказов (например, отказ линка в пределах одной стойки (MC-LAG-пары). Конечно, данный режим накладывает ограничения на новые настройки, изучение вновь подключаемых хостов и изменения топологии фабрики в том смысле, что они обработаны не будут. Кому-то это может показаться недостатком, однако давайте представим, что произойдет в случае отказа всех супервизоров в модульном коммутаторе. Вероятнее всего, он просто остановится.

Интерфейс Big Cloud Fabric

Как мы отметили ранее, контроллер фабрики является единой точкой управления, аналитики и интеграции с внешними системами. Несмотря на то, что для настройки, мониторинга, поиска и устранения неисправностей доступны как полнофункциональный CLI, так и чрезвычайно удобный веб-интерфейс, они, по сути, являются клиентами для единого REST API. Многие производители предлагают REST-интерфейсы для взаимодействия со своими продуктами, но так получилось, что в мире сетевых устройств они зачастую менее функциональны, чем CLI/WEB, и не дают доступ ко всем функциям и механизмам, что значительно ограничивает возможности их применения. В свою очередь, подход, который был выбран в BCF, полностью исключает потерю функциональности – все, что можно сделать в CLI или в веб-интерфейсе, доступно к реализации с помощью REST API. Более того, сам процесс использования REST API сделан максимально удобным и простым: достаточно ввести в CLI команду «debug rest», и для каждой введенной в дальнейшем команды в CLI будет выведен метод, путь и тело запроса, а также код и тело ответа. Таким образом, чтобы написать какой-либо скрипт для автоматизации рутинных процессов, нет больше нужды сидеть над документацией (которая тоже существует) – достаточно один раз проделать требуемые операции в CLI и на основании выводов сделать шаблон.

Отдельно хотелось упомянуть о веб-интерфейсе управления. Так уж повелось в сетевом мире, что консоль CLI считается наиболее удобным инструментом конфигурирования, поиска и устранения неисправностей. Отчасти это связано с тем, что до появления общепринятых API и возможности выполнения скриптов непосредственно на оборудовании CLI давал более широкие возможности по автоматизации рутинных операций и зачастую был гораздо информативнее, чем веб-интерфейс. Однако в контроллере BCF веб-интерфейс настолько удобен, понятен и функционален, что при проведении тестирования наш инженер практически не прибегал к услугам CLI – все настройки и диагностическая информация были доступны в удобном и понятном графическом интерфейсе. В дополнение к отличной эргономике и понятной логической структуре веб-интерфейс содержит множество, казалось бы, незначительных, но очень полезных деталей, которые как раз и формируют чувство удовлетворенности от работы с ним. Например, при добавлении коммутатора необходимо выбрать, какую роль он будет занимать в архитектуре (spine или leaf). Но если в имени, которое назначается коммутатору, встретится одно из этих слов, роль будет предложена автоматически. Мелочь, а приятно.

Функциональность Big Cloud Fabric

Когда мы начинали тестирование BCF в лаборатории, была подготовлена методика, основанная на практическом опыте. В нее были включены те функции и механизмы, которые гарантированно встречаются в ЦОД, поскольку мы не были уверены, что достаточно молодой продукт будет обладать теми же возможностями и поддерживать аналогичный набор механизмов и протоколов, что и старожилы рынка телекоммуникаций. Однако уже на первом этапе изучения документации на BCF нам пришлось значительно увеличить объем тестируемых функций, поскольку все они были действительно интересны и востребованы. Но больше всего нас впечатлило то, что все заявленные функции работали как часы – ни один тест не был провален или работал с замечаниями. Вообще, ощущения от работы с BCF можно коротко характеризовать как «быстро, просто и удобно».

Логическая структура BCF состоит из вполне понятных любому сетевому специалисту элементов, и это выгодно отличает BCF от похожих решений других производителей. Структурной единицей логической структуры BCF является т. н. tenant, который фактически выступает аналогом классической выделенной таблицы маршрутизации (VRF). В tenant’ах располагаются широковещательные сегменты и их маршрутизирующие интерфейсы, а связь между ними осуществляется через системный маршрутизатор. В сегментах располагаются оконечные физические или виртуальные хосты (end point). Сопряжение с внешними устройствами можно организовать как посредством статической маршрутизации, так и с помощью протокола BGP. Однако за такой простотой логической структуры скрывается развитая функциональность и гибкость.

В отличие от классических коммутаторов членами одного широковещательного сегмента могут стать серверы, передающие пакеты с разными VLAN ID, и в то же время одинаковый VLAN ID может быть отнесен к разным сегментам. Отсутствует необходимость в использовании протоколов резервирования основного шлюза, фактически отсутствует устройство, которое реализует эту функцию, т. е. любой коммутатор фабрики может перезаписать заголовок и передать пакет в другую подсеть. Создаваемые политики доступа и сервисных цепочек (ACL, Policy-based Routing) работают в рамках всей фабрики, поскольку связаны не с конкретными коммутаторами или интерфейсами, а с вышележащими логическими структурами.

Насколько мощным и в то же время простым инструментом является BCF, можно судить даже по тому, что коммутация и маршрутизация multicast-трафика в фабрике настраивается лишь переключением ползунка «Multicast Enable» в настройках tenant’а – после этого фабрика может маршрутизировать multicast-трафик между подсетями в пределах выбранного tenant’а, а каждый tenant может оперировать одинаковым набором 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

Современная сеть ЦОД не может существовать отдельно от остальных систем – слишком тесно переплетены физический и виртуальный миры и слишком размыты границы между ними. Интеграция с системами виртуализации и оркестрации – это одно из важнейших преимуществ BCF. Несмотря на то, что аналогичные возможности заявлены в решениях множества производителей, централизованная архитектура BCF позволяет их реализовать быстро, просто и удобно.

На данный момент реализована совместная работа BCF с VMware vSphere, Docker/Kubernetes, а также плотная интеграция с OpenStack. В случае с последним возможности интеграции считаются одними из лучших в индустрии. На вычислительные узлы KVM устанавливается агент для программного коммутатора Open vSwitch, который полностью синхронизирован с фабрикой и обеспечивает не только коммутацию, но и маршрутизацию между виртуальными машинами на вычислительном узле. Создание и управление проектами в интерфейсе Horizon полностью синхронизировано с контроллером BCF – фактически внутри OpenStack Project (BCF Tenant) любые действия по управлению сетевой инфраструктурой фабрики могут быть выполнены из Horizon.

Интеграция с vSphere происходит через vCenter, при этом фабрика может быть связана с несколькими копиями vCenter, каждый из которых управляет собственным tenant'ом в BCF. Более того, ресурсы фабрики могут быть разделены между несколькими копиями vCenter и OpenStack. Интеграция с vCenter дает следующие возможности:

• автоматическое изучение подключенных ESXi-хостов и организация LAG-групп;
• автоматическое изучение адресов виртуальных машин (MAC-адрес, опционально IPv4), развернутых на подключенных ESXi;
• автоматическое создание сегментов в фабрике и правил членства в них при создании port group;
автоматическое добавление необходимых VLAN в LAG c ESXi-хостом;
• при осуществлении vMotion, если на текущем ESXi не остается виртуальных машин в конкретном сегменте, interface-group (через который подключен ESXi) будет удален из сегмента.

Таким образом, большинство рутинных операций автоматизированы и не требуют вмешательства сетевого специалиста. Однако на этом возможности интеграции BCF и vSphere не ограничиваются. В Big Switch Networks разработали плагин для vCenter, который еще больше расширяет возможности членов команды виртуализации и дает им дополнительные инструменты конфигурации и анализа неисправностей. С помощью него администратор vCenter может создавать L3-интерфейсы для подсетей и сегментов, в которых расположены виртуальные машины, просматривать информацию о VLAN, оконечных хостах и серверах, а также политиках (ACL, PBR). Но самое главное, в плагине доступен тот же инструмент Test Path, что и в интерфейсе контроллера BCF.

Администратору виртуальной среды больше не нужно беспокоить сетевого инженера на большинстве этапов процесса поиска и устранения неисправностей, достаточно выбрать виртуальную машину источника и машину (или внешний хост) назначения и провести полный тест на прохождение трафика через фабрику.

Может сложиться впечатление, что интеграция с vSphere и плагин для vCenter дают слишком большие возможности администраторам виртуальной инфраструктуры, к которым они могут быть не готовы. Однако это не так. Вышеописанные инструменты лишь призваны облегчить и ускорить процессы настройки и поиска неисправностей – командам незачем без необходимости отвлекать друг друга и ждать реакции на выполнение простейших запросов и рутинных операций. Администратор виртуальной среды не может ничего «сломать» в фабрике – его возможности заканчиваются tenant’ом, с которым синхронизирован vCenter, но в то же время у него достаточно инструментов для решения ежедневных задач. Общее управление фабрикой по-прежнему осуществляет сетевой инженер, но его участие требуется только в решении серьезных инцидентов или при глобальных изменениях в системе.

Заключение

Концепция Software Defined Networks является, вероятно, самой обсуждаемой темой сетевого мира. Ни один маркетинговый материал не обходит ее, каждый производитель стремится в том или ином виде заявить о ее поддержке в своих решениях. Однако, несмотря на непрерывное развитие и ряд значительных изменений, эта концепция долгое время не имела воплощения в виде коммерчески законченных продуктов. Возможно, причина в том, что одним из краеугольных камней отказоустойчивости телекоммуникационных сетей является децентрализация, в то время как реализация SDN-концепции практически невозможна без единой точки управления и контроля (Control & Management Plane).

Однако те преимущества, которые несет за собой SDN, интерес заказчиков и постоянно наступающие на пятки производители программного обеспечения заставляют гигантов сетевого рынка пересматривать свою точку зрения. В результате рынок наводняют продвинутые системы управления, пусть и под разными названиями, но объединенные одной целью – эмулировать SDN-функции в классической сети. К сожалению, такой подход не может принести всех тех преимуществ, что предлагает SDN, а самое главное, не решает давней проблемы сетевого мира – разделения приложений, операционной системы и аппаратного обеспечения. Развитие коммерческих ASIC и появление на рынке разработчиков сетевых операционных систем отчасти решило проблему дезагрегации, но собранные из них продукты либо по-прежнему остаются сетью независимых устройств без какого-либо намека на интеграцию со сторонними системами, либо конструктором, который предлагается собирать самостоятельно.

Сети ЦОД не обладают широким территориальным распределением и редко выходят за рамки одного машинного зала, а следовательно, надежность линий связи в них значительно выше, чем у распределенных и кампусных сетей. Таким образом, проблема централизации и отказоустойчивости в ЦОД не стоит остро. Более того, всем нравятся модульные коммутаторы! Если бы не кабели с их неизменной способностью заполнять все доступное пространство, сеть ЦОД наверняка состояла бы из двух очень больших коммутаторов. Рекомендованные дизайны ведущих производителей с использованием выносов фабрики или больших стеков 1RU-коммутаторов тому наглядный пример. Видимо, справедливо основываясь на подобных размышлениях, компания Big Switch Networks смогла совершить прорыв и превратить концепцию в реально работающий коммерческий продукт.

В заключение хотелось бы сделать сухую выжимку обзора и еще раз перечислить основные моменты, которыми обладает Big Cloud Fabric:

• отсутствие аппаратной привязки к производителю сетевого оборудования (hardware vendor lock-in). В качестве коммутатора фабрики могут быть использованы коммутаторы различных производителей, основанные на ASIC Broadcom Trident 2/2+ и Tomahawk. Это означает, что больше не нужно подстраиваться под политику производителя и поставщика коммутаторов – теперь есть выбор. Это не только снижает затраты, но и ускоряет процессы закупки оборудования: можно выбрать любой из доступных сейчас коммутаторов вместо того, чтобы месяцами ждать поставки определенной модели;
• отказоустойчивость. Несмотря на централизованный Control & Management Plane, BCF чрезвычайно надежна. Контроллеры фабрики реализуются в виде отказоустойчивого кластера, leaf-коммутаторы можно объединять в MC-LAG-пару, а в случае выхода из строя всех контроллеров фабрика будет продолжать работать со всеми изученными серверами. Как одно из доказательств отказоустойчивости фабрики Big Switch Networks приводит результаты т. н. Chaos Monkey Testing – на фабрике из 16 spine-/32 leaf-коммутаторов под нагрузкой из 42 000 оконечных хостов/ВМ было организовано более 640 отказов в течение 30 минут, но это никак не повлияло на производительность приложений;
• единая точка контроля, управления и интеграции. По сути, перед нами действительно большой распределенный модульный коммутатор. Нет нужды настраивать каждый коммутатор по отдельности и беспокоиться о протоколах, петлях, отказоустойчивости внутри сети – BCF представляет собой единую фабрику с единым интерфейсом. Интеграция с системами виртуализации и оркестрации позволяет автоматизировать большинство процессов, а такие инструменты, как Test Path и плагин для VMware vCenter, значительно упрощают поиск неисправностей и процессы коммуникаций между командами;
• широкие возможности по аналитике. В контроллер фабрики встроена мощная система по сбору, корреляции и отображению всех данных по физической и логической структуре фабрики. Благодаря этому значительно упрощаются процессы поиска и устранения неисправностей, а также отсутствует необходимость в развертывании дополнительных систем;
• значительная масштабируемость. В BCF одна структурная единица модульной архитектуры ЦОД (POD) поддерживает до 32 leaf-/6 spine-коммутаторов и 46 000 подключенных оконечных хостов. Таким образом, мы получаем сетевую фабрику с предсказуемым, постоянным временем задержки и переподпиской 2:1. Следует отметить, что для добавления коммутатора в фабрику не требуется ничего, кроме коммутации: функция Zero Touch Provisioning устраняет необходимость в какой-либо настройке подключаемого оборудования. Таким образом, для увеличения портовой емкости фабрики с 96 до более чем 1500 портов необходимо время только на монтаж и коммутацию плюс 10 минут на настройку.

В дополнение ко всему компания Big Switch Networks предоставляет очень гибкие возможности по знакомству с продуктом. Во-первых, это специальная бесплатная версия BCF-контроллера в виде виртуальной машины, Community Edition. Она обладает всей функциональностью коммерческой версии, кроме ограничений на количество и тип коммутаторов (только 2 физических коммутатора), а также поддержку (best effort, только по электронной почте). Для знакомства с возможностями BCF даже без наличия оборудования можно воспользоваться удаленной лабораторией. В ней представлены несколько учебных модулей, разбитых по наиболее интересным темам, в рамках которых можно отработать часто используемые функции и сценарии или просто познакомиться с интерфейсом контроллера.

В целом от тестирования и работы с фабрикой Big Cloud Fabric мы получили исключительно приятные впечатления и уверены, что за счет удобства, простоты и широкой функциональности она будет востребована на рынке сетевых решений ЦОД даже в условиях жесткой конкуренции со стороны других крупных систем.