Стратегия Cisco SDN для центров обработки данных

Блог Крейга Хёйтема (Craig Huitema), директора по маркетингу решений Cisco для ЦОД

У компании Cisco множество заказчиков на разных рынках в разных регионах. У каждого из них свои требования, операционные модели и проекты, и поэтому создать универсальную, пригодную для всех стратегию внедрения SDN не представляется возможным. Наша SDN-стратегия предоставляет заказчикам больше возможностей выбора и большую гибкость, что и было продемонстрировано в ходе конференции Cisco Live в Сан-Диего.

Стратегия Cisco SDN для центров обработки данных (ЦОД) стоит на трех китах в виде:

• ориентированной на приложения инфраструктуры (Application Centric Infrastructure, ACI);

• программируемой фабрики;

• программируемой сети.

Такой подход, распространяющий преимущества программируемости и автоматизации на всю линейку коммутаторов Cisco Nexus, дает нашим заказчикам возможность выбрать тот вариант реализации, который более всего соответствует их ИТ- и бизнес-целям. Рассмотрим каждую из упомянутых выше опор стратегии Cisco SDN для ЦОД.

ACI

ACI — флагманское предложение Cisco в области SDN и самое полнофункциональное SDN-решение в отрасли. Используя модель политик, ориентированную на приложения, ACI обеспечивает автоматизированное, интегрированное конфигурирование базовых и наложенных сетей, конфигурирование сервисов уровней L4- L7 в обширной партнерской экосистеме, а также дистанционное измерение различных параметров для текущего контроля работоспособности на уровне приложений. Открытое, гибкое и безопасное решение с такими комплексными возможностями обеспечивает заказчикам преимущества, которые не способно предоставить ни одно другое SDN-решение. Доказательством может служить отчет компании IDC о том, какие выгоды в результате получают заказчики. Подробнее же ознакомиться с инфраструктурой ACI можно на нашем сайте.

Программируемая фабрика

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

Виртуальные сети VXLAN приобрели немалую популярность в отрасли по многим причинам, в том числе, в силу их преимуществ перед такими традиционными технологиями, как VLAN и Spanning Tree. Здесь и более эффективное использование полосы пропускания благодаря протоколу Equal Cost Multi Pathing (ECMP), и большая теоретическая масштабируемость (16 млн сегментов), и большая гибкость, достигаемая благодаря применению оверлейной модели, которая допускает построение многопользовательских (multi tenant) облачных сетей. С ростом популярности сетей VXLAN растет и потребность в решении двух ключевых проблем: реализации стандартизованного подхода к масштабированию сетей VXLAN и упрощению их конфигурирования и управления ими.

Для стандартизованного масштабирования сетей VXLAN Cisco реализовала на коммутаторах Nexus поддержку управляющей плоскости Multipoint BGP EVPN. Почему это так важно? Дело в том, что первоначальная спецификация VXLAN (RFC 7348) опиралась на многоадресный механизм лавинной рассылки и изучения (flood-and-learn) без управляющей плоскости для ряда ключевых функций (обнаружение узлов VTEP и определение доступности оконечных хост-компьютеров). Это не самый эффективный подход. Для преодоления его ограничений комитет IETF в качестве стандартизованной управляющей плоскости для оверлеев VXLAN разработал технологию MP BGP EVPN Control Plane. Тем самым удалось уменьшить объем трафика рассылки в наложенной сети и добиться большей масштабируемости и эффективности.

Для решения второй проблемы (т.е. для упрощения конфигурирования и управления) Cisco представила систему Virtual Topology System (VTS) — новое решение, которое автоматизирует конфигурирование наложенных сетей, упрощая развертывание облачных сервисов. Благодаря автоматизации и тесной интеграции с такими средствами гармонизации от сторонних производителей, как OpenStack и VMWare VCenter, VTS упрощает конфигурирование и управление как для физических, так и для виртуальных задач, устраняя необходимость в интенсивной ручной настройке сети. Для интересующихся этой темой мы приготовили две электронные лекции с общим обзором и более подробным рассказом о данной технологии.

Программируемая сеть

Программируемость инфраструктуры имеет огромное значение, ибо она способствует автоматизации, которая, в свою очередь, содействует увеличению скорости, что является необходимостью практически для любого бизнеса, имеющего дело с цифровой революцией. С развитием программируемости Cisco реализует все больше и больше возможностей в линейке Nexus. Срели них такие функции, как открытые программируемые интерфейсы API (Programmable Open APIs), интеграция со средствами DevOps и средствами автоматизации сторонних производителей, средства разработки пользовательских приложений и команды Bash. Ввод набора этих функций в состав NX-OS облегчил реализацию программируемых сетей. Давайте посмотрим, как этим может воспользоваться заказчик.

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

Большинство (хотя и не все) склонились к третьему варианту, и тут открытием стала автоматизация: средства автоматизации развертывания серверов и управления ими помогли системным администраторам и их работодателям масштабировать бизнес. Они начали обращать внимание на такой показатель, как число серверов, управляемых одним администратором. Это соотношение стало резко увеличиваться (в некоторых случаях на несколько порядков).

С внедрением автоматизации и наступлением других перемен, касающихся культуры производства, процессов и т.д., в некоторых компаниях заметили, что администраторы управляют уже не десятками и сотнями, а тысячами серверов. Тогда начались эксперименты с применением DevOps . По мере конвергенции упомянутых элементов постепенно усиливалось сотрудничество разных подразделений, и в результате начался обмен «секретами мастерства». Так, например, одни системные администраторы увидели эффект применения таких инструментов, как Puppet и Chef для автоматизации серверных задач, и у них возникло желание использовать те же средства в сети. В других случаях знатоки Linux и любители интерпретатора команд Bash стали использовать эти команды для конфигурирования и диагностики и сетей, и серверов. Третьим потребовались интерфейсы API, которые позволяли извлекать подробнейшую информацию для ее последующей обработки и использования скриптами и другими инструментами.

Иными словами, возникла потребность в увеличении числа доступных для программирования сетевых компонентов. Хотя эти процессы происходили лишь в некоторых компаниях, многие компоненты вызвали интерес у довольно обширного круга заказчиков. Когда это произошло, Cisco стала наращивать функционал программирования в коммутаторах Nexus. Подробную информацию о различных вариантах применения и возможностях коммутаторов Nexus можно найти здесь.

Итак, три кита: инфраструктура ACI, программируемая фабрика и программируемая сеть, — обеспечивают широкий спектр возможностей, которые помогают нашим заказчикам решать самые разнообразные проблемы, с которыми им приходится столкнуться.