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

Интеграция 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 значительно упрощают поиск неисправностей и процессы коммуникаций между командами;

Широкие возможности по аналитике. В контроллер фабрики встроена мощная система по сбору, корреляции и отображению всех данных по физической и логической структуре фабрики. Благодаря этому значительно упрощаются процессы поиска и устранения неисправностей, а также отсутствует необходимость в развертывании дополнительных систем;

Значительная масштабируемость. Один POD BCF поддерживает до 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 мы получили исключительно приятные впечатления и уверены, что за счет удобства, простоты и широкой функциональности оно будет востребовано на рынке сетевых решений ЦОД даже в условиях жесткой конкуренции со стороны других крупных систем.

От Slides Defined к Software Defined Networking. Часть 3