КРАТКОЕ ОПИСАНИЕ BIG CLOUD FABRIC

Big Cloud Fabric (BCF) — это первая в отрасли фабрика для ЦОД, созданная с использованием SDN-контроллера и стандартизированных аппаратных коммутаторов (white box).
Благодаря использованию принципов гипермасштабируемой архитектуры, решение BCF обеспечивает:

1.интеллектуальность путём упрощения сетевых операций и получения телеметрии в рамках фабрики;
2.динамичность путём автоматизации сети для быстрого развёртывания приложений и служб;
3.гибкость развёртывания благодаря масштабируемой архитектуре и стандартизированному сетевому оборудованию.

Приложениям доступны высокая производительность сетевой фабрики, безопасная, одновременная работа множества пользователей и гибкая инфраструктура для любого типа нагрузки. Клиенты получают выгоду от высокой гибкости приложений, достигнутой благодаря автоматизации, масштабному упрощению эксплуатации за счёт использования SDN и значительному снижению издержек из-за разделения программного обеспечения и аппаратной платформы.
BCF поддерживает как физическую, так и виртуальную рабочую нагрузку, а также интеграцию с различными системами управления облачными платформами и виртуализации.1 Она обеспечивает стандартные функции коммутации, маршрутизации, встраивания L4-7 сервисов, гарантируя при этом высокую пропускную способность и постоянную задержку. Big Cloud Fabric устойчива к сбоям, не имеет единой точки отказа и обеспечивает работоспособность даже в случае полного отказа контроллеров фабрики.

АРХИТЕКТУРА: ЦЕНТРАЛИЗОВАННЫЙ SDN КОНТРОЛЛЕР И ОТКРЫТАЯ АППАРАТНАЯ ПЛАТФОРМА

Архитектура Big Cloud Fabric базируется на разделении функций плоскостей передачи данных (data plane) и управления (control & management plane), а также централизации функциональности последней. На практике это означает, что большинство функций управления и контроля выносятся на централизованный SDN контроллер, в то время как на коммутаторах продолжают работать некоторые низкоуровневые control plane функции для обеспечения масштабируемости и отказоустойчивости. В итоге, Big Cloud Fabric представляет собой централизованную, с точки зрения управления и контроля, сетевую фабрику, но в тоже время полностью распределенную в контексте передачи данных.
Архитектуры на основе контроллера не только повышают гибкость благодаря возможности централизованной программируемости и автоматизации, но также упрощают дизайн сетевой инфраструктуры (например, Leaf-Spine L2/L3). В противном случае, когда управления и работа протоколов реализуется на каждом устройстве, он получается громоздким и сложным для реализации, и неустойчивым с точки зрения эксплуатации.

Рис. 1: Big Cloud Fabric

Архитектура BCF состоит из физической фабрики, базирующейся на топологии Leaf-and-Spine. Дополнительно архитектуру фабрики можно расширить за счёт коммутаторов виртуальной среды. Коммутаторы под управлением операционной системы Switch Light™ образуют узлы физической фабрики, а агент Switch Light Virtual, работающий на гипервизоре, расширяет фабрику за счёт виртуальных коммутаторов. Интеллектуальные возможности фабрики реализованы иерархически: большая часть функционирует в контроллере BCF (где осуществляется настройка, автоматизация и устранение неполадок), а некоторые низкоуровневые функции реализуются с помощью Switch Light для обеспечения отказоустойчивости и масштабируемости.

КОМПОНЕНТЫ СИСТЕМЫ BIG CLOUD FABRIC

Контроллер Big Cloud Fabric — централизованный и иерархически реализованный контроллер SDN в виде отказоустойчивой пары аппаратных или виртуализированных устройств для обеспечения бесперебойной работы.

• Стандартизированные аппаратные коммутаторы, связанные по топологии Leaf-and-Spine — коммутаторы Ethernet (white-box или брендированные), которые поставляются без встроенной сетевой ОС. Коммерческие чипы (ASIC) в этих коммутаторах аналогичны тем, которые используются большинством производителей и широко применяются в создании гипермасштабируемых сетей ЦОД. Эти коммутаторы поставляются с ONIE для автоматической и независимой от поставщика установки сторонней сетевой ОС. В списке совместимости оборудования Big Switch указано множество доступных конфигураций и производителей аппаратных коммутаторов.
• Switch Light OS — легковесная операционная система для открытых (white-box) коммутаторов, предназначенная для работы в программно-определяемых сетях.
• Switch Light VX (опционально) — высокопроизводительный программный агент для Open vSwitch (OVS) гипервизоров на базе KVM.
• Плагин OpenStack (дополнительно) — сервисный плагин Big Switch Networks и ML2 Driver Mechanism для интеграции с сетевой подсистемой OpenStack Neutron различных дистрибутивов.
• Плагин для Vmware vCenter (дополнительно) - сетевая автоматизация и видимость физической сети для систем виртуализации серверов vSphere, сети NSX, виртуализации хранилищ vSAN, а также VMware integrated OpenStack (VIO).
• Плагин для контейнерной инфраструктуры (дополнительно) — плагин BCF для различных оркестраторов контейнерной среды. Он обеспечивает автоматизацию и видимость сети на уровне контейнеров.

СЦЕНАРИИ РАЗВЁРТЫВАНИЯ

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

• виртуализация VMware SDDC (vSphere, NSX, Virtual SAN и VIO);
• OpenStack, включая NFV;
• контейнерная инфраструктура;
• частные облака;
• инфраструктура виртуальных рабочих столов (VDI);
• Big Data/высокопроизводительные вычисления (HPC);
• программно-определяемые хранилища (SDS).

Рис. 2: Пример сценариев развёртывания BCF

BCF может поддерживать вышеупомянутые сценарии развёртывания с различными конфигурациями открытых Ethernet коммутаторов. Некоторые примеры приведены в таблице на рис. 2.

ПРЕИМУЩЕСТВА BIG CLOUD FABRIC

Использование централизованного контроллера позволяет сократить количество консолей управления более чем в 60 раз.

Так как настройка, автоматизация и большая часть процессов по поиску и устранению неполадок выполняется с помощью контроллера BCF, это позволяет резко сократить количество консолей управления, участвующих в настройке новых сетевых объектов. Например, в POD из 32 стоек с резервными ToR коммутаторами и четырьмя коммутаторами Spine, традиционный подход box-by-box потребовал бы 68 консолей управления. Big Cloud Fabric имеет только одну — консоль контроллера (CLI, GUI или REST API) — и она выполняет те же функции. В результате это значительно экономит время, снижает частоту ошибок и упрощает автоматизацию

Простая конфигурация и управление – путь к инновациям

В BCF настройка в интерфейсе CLI, GUI или REST API основана на концепции логических клиентов (tenant). Каждый клиент контролирует собственный L2/L3 домены и политики взаимодействия. Контроллер Big Cloud Fabric транслирует логическую структуру (L2/L3/политики) в оптимизированные записи в таблицах коммутации Spine, Leaf и vLeaf.

Стандартизированное аппаратное обеспечение снижает капитальные расходы более чем на 50 %

Если подсчитать расходы на оборудование, программное обеспечение, техническое обслуживание и оптику/кабели, то при использовании стандартизированного оборудования разница очевидна.

Встроенная интеграция с оркестраторами упрощает эксплуатацию ЦОД

Контроллер BCF поддерживает ”из коробки” интеграцию с различными платформами управления облаком (CMP) — VMware (vSphere, NSX Manager, vSAN и VIO), OpenStack и контейнерами через единый программный интерфейс. Это более простой и масштабируемый вариант по сравнению с box-by-box, который требует гораздо большего числа программных взаимодействий с CMP. Администраторам ЦОД будут доступны преимущества налаженных процессов развёртывания приложений, расширенной аналитики и упрощённого процесса устранения неполадок в физических и виртуальных средах.

                                          Рис. 3: BCF поддерживает интеграцию с CMP

Фабрика SDN обеспечивает глубокую видимость и отказоустойчивость в сетях OpenStack

L2/L3 плагин BCF для OpenStack Neutron обеспечивает отказоустойчивость, необходимую для развёртывания OpenStack в условиях промышленной эксплуатации, включая поддержку распределённой маршрутизации, NAT и Floating IP. Контроллер BCF выполняет роль единой системы для развертывания, устранения неполадок, видимости и аналитики всей физической и виртуальной сетевой среды. Это позволяет операторам ЦОД быстро разворачивать приложения, упрощает эксплуатацию и обеспечивает немедленный анализ причин сбоев при возникновении проблем с производительностью приложений.

Интеграция компонентов сети, безопасности и аудита

Контроллер BCF использует ряд REST API для интеграции шаблонов приложений с системами аудита, например в OpenStack. Благодаря интеграции сетевых функций с помощью шаблонов OpenStack HEAT в Horizon GUI, время развёртывания новых приложений резко сокращается, так как оценка безопасности выполняется один раз (по шаблону), а не каждый раз для нового приложения. Функции подключения, редактирования и аудита доступны из системы самообслуживания и позволяют быстро создавать отчёты, адаптированные для аудита, обеспечивая эффективную оценку сложных приложений, выходящих за рамки базовых шаблонов.

Гибкая масштабируемая фабрика

Гибкая, масштабируемая архитектура BCF даёт пользователям возможность начинать с определённого варианта фабрики, который удовлетворяет их текущим потребностям, и масштабировать его в будущем без изменений в архитектуре. Благодаря возможности выбора аппаратной платформы и модели pay-as-you-grow, компания может начинать с малого и постепенно расширять фабрику, вместо того чтобы ограничиваться полностью интегрированным проприетарным решением. Это открывает путь к современным сетям ЦОД. После добавления новых коммутаторов (физических или виртуальных) контроллер автоматически включает их в фабрику и расширяет текущую конфигурацию, тем самым снижая вероятность любых ошибок. Клиент получает фабрику, которую нужно настроить только один раз.

Отказоустойчивость уровня ЦОД

BCF обеспечивает отказоустойчивость, которая позволяет фабрике полноценно работать в случае отказов линий или коммутаторов, а также в тех редких ситуациях, когда кластер контроллера полностью недоступен. Замена коммутатора полностью аналогична замене линейной карты в модульном шасси. Контроллер BCF координирует и организует обновление всей фабрики, обеспечивая минимальное время простоя. Эти функциональные возможности ещё более повышают отказоустойчивость фабрики и упрощают эксплуатацию.

ИСПОЛЬЗОВАНИЕ BCF: ПРИМЕР С ТРЁХУРОВНЕВЫМ ПРИЛОЖЕНИЕМ

BCF поддерживает модель множественной аренды, которую легко можно настроить под конкретные требования различных организаций и приложений. Эта модель увеличивает скорость развертывания приложений, упрощает настройку и помогает с аналитикой и устранением неполадок. Некоторые важные термины, используемые для описания функциональности:

• Клиент (tenant) — логический контейнер для L2 и L3 сетевых объектов и сервисов.
• Логический сегмент (segment) — L2 сеть, включающая в себя порты и подключенные устройства. Фактически, он представляет собой стандартный широковещательный домен.
• Логический маршрутизатор (logical-router) — распределенный маршрутизатор, предоставляющий маршрутизация внутри и между подсетями различных клиентов.
• Внешний маршрутизатор — физический маршрутизатор, обеспечивающий связь между модулями в рамках ЦОД и внешними сетями.
• Сервисы клиента — предоставляемые клиентом сервисы, развёрнутые как выделенные или совместно используемые службы (отдельно или как часть сервисной цепочки).

Рабочий процесс клиента

В наиболее распространённом сценарии конечные потребители инфраструктуры ЦОД получают логическую топологию сети, которая определяет политики связанности для приложений. В качестве примера на рисунке 5 показано каноническое трёхуровневое приложение с различными узлами клиента BLUE. Как правило, клиент разворачивает эти узлы с помощью систем управления виртуализацией, например, OpenStack, VMware vSphere или непосредственно GUI/CLI BCF. В рамках этого рабочего процесса контроллер BCF автоматически создает эту логическую топологию для физических и виртуальных коммутаторов.

Сопоставление логического дизайна в физическую сеть

Клиент BLUE имеет три логических сегмента сети. Каждый из трёх сегментов представляет собой широковещательный домен для каждого из 3 уровней приложения: Web, App и DB. Допустим, в этом примере Web и App — виртуальные машины, а DB представлен физическими серверами. Согласно правилам, которые установил администратор ЦОД, система управления распределяет создаваемые ВМ на разных физических узлах в рамках ЦОД. В качестве примера логическая топология, показанная на рисунке 5, может быть преобразована в сеть POD. Контроллер BCF выполняет задачу по обеспечению связанности между разворачиваемыми элементами, распределёнными по POD, обеспечивая при этом изолирование клиентов и безопасность.

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

Примерный набор записей в различных таблицах переадресации выделяет некоторые характерные особенности BCF, описанные в предыдущих разделах.

• Маршрутизация между подсетями одного или различных tenant выполняется на ближайшем leaf или vLeaf коммутаторе. Таким образом отсутствует неоптимальные пути маршрутизации трафика;
• Передача трафика внутри L2 доменов (логических сегментов) происходит без дополнительной инкапсуляции внутри фабрики;
• Полноценная балансировка нагрузки между коммутаторами фабрики (как на уровне Leaf, так и на уровне Spine);
• Избыточные линии связи между уровнями leaf и spine для отказоустойчивости.