Какой компонент архитектуры aci преобразует политики приложений в сетевой программный код

Обновлено: 06.01.2025

Последние несколько лет Cisco активно продвигает новую архитектуру построения сети передачи данных в ЦОД — Application Centric Infrastructure (или ACI). Некоторые с ней уже знакомы. А кто-то даже успел внедрить её на своих предприятиях, в том числе и в России. Однако для большинства ИТ-специалистов и ИТ-руководителей ACI пока является либо непонятной аббревиатурой, либо всего лишь рассуждением о будущем.

В этой статье мы постараемся это будущее приблизить. Для этого мы расскажем об основных архитектурных компонентах ACI, а также проиллюстрируем способ её применения на практике. Кроме того, в ближайшее время мы организуем наглядную демонстрацию работы ACI, на которую может записаться каждый заинтересованный ИТ-специалист.

Узнать больше про новую архитектуру построения сети можно будет в Санкт-Петербурге в мае 2019 года. Все подробности – по ссылке. Записывайтесь!

Предыстория

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

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

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

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

Корнем проблемы являются даже не сами сроки или сложность требований. Дело в том, что эти требования необходимо «переводить» с языка бизнес-приложений на язык сетевой инфраструктуры. Как известно, любой перевод — это всегда частичная потеря смысла. Когда владелец приложения говорит о логике работы своего приложения, сетевой администратор понимает набор VLAN-ов, Access list—ов на десятках устройств, которые нужно поддерживать, актуализировать и документировать.

Накопленный опыт и постоянное общение с заказчиками позволило Cisco спроектировать и внедрить новые принципы построения сети передачи данных центра обработки данных, которые отвечают современным тенденциям и основываются, в первую очередь, на логике бизнес-приложений. Отсюда и название — Application Centric Infrastructure.

Архитектура ACI

Архитектуру ACI наиболее правильно рассматривать не с физической стороны, а с логической. Она основана на модели автоматизированных политик, объекты которых на верхнем уровне можно разделить на следующие компоненты:

Сеть на базе коммутаторов Nexus.
Кластер контроллеров APIC;
Профили приложений;

Рассмотрим каждый уровень более подробно – при этом мы будем переходить от простого к сложному.

Сеть на базе коммутаторов Nexus

Сеть в ACI-фабрике похожа на традиционную иерархическую модель, но строится значительно проще. Для организации сети используется модель Leaf-Spine, которая стала общепринятым подходом для реализации сетей нового поколения. Данная модель состоит из двух уровней: Spine и Leaf, соответственно.

Уровень Spine отвечает только за производительность. Суммарная производительность Spine-коммутаторов равна производительности всей фабрики, поэтому на этом уровне следует использовать коммутаторы с портами 40G или выше.

Spine-коммутаторы соединяются со всеми коммутаторами следующего уровня: Leaf-коммутаторами, к которым подключаются конечные хосты. Основная роль Leaf-коммутаторов – портовая емкость.

Таким образом, легко решаются вопросы масштабирования: если нам требуется увеличить пропускную способность фабрики, мы добавляем Spine-коммутаторы, а если нам требуется увеличить портовую ёмкость – Leaf.

Для обоих уровней используются коммутаторы серии Cisco Nexus 9000, которые для Cisco являются основным инструментом для построения сетей ЦОД независимо от их архитектуры. Для уровня Spine используются коммутаторы Nexus 9300 или Nexus 9500, а для Leaf только Nexus 9300.

Модельный ряд коммутаторов Nexus, которые используются в ACI фабрике, приведён на рисунке ниже.

Кластер контроллеров APIC (Application Policy Infrastructure Controller)

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

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

Теперь перейдем к одному из главных компонентов ACI – профилям приложений.
Профиль приложения (Application Network Profile) – это логическая основа ACI. Именно профили приложений определяют политики взаимодействия между всеми сетевыми сегментами и описывают непосредственно сами сетевые сегменты. ANP позволяет абстрагироваться от физического уровня и, по сути, представить, как нужно организовать взаимодействие между различными сегментами сети с точки зрения приложения.

Профиль приложения состоит из групп подключений (End-point groups – EPG). Группа подключений – это логическая группа хостов (виртуальных машин, физических серверов, контейнеров и т.п.), которые находятся в одном сегменте безопасности (не сети, а именно безопасности). Конечные хосты, которые относятся к той или иной EPG, могут определяться большим количеством критериев. Обычно используются следующие:

Физический порт
Логический порт (порт-группа на виртуальном коммутаторе)
VLAN ID или VXLAN
IP-адрес или IP-подсеть
Атрибуты сервера (имя, расположение, версия ОС и т.п.)

На рисунке ниже описан пример настройки связи различных EPG через контракты в рамках одного ANP.

Профилей приложений в рамках ACI-фабрики может быть любое количество. Кроме того, контракты не привязаны к конкретному профилю приложения, их можно (и нужно) использовать для соединения EPG в разных ANP.

По сути, каждое приложение, для которого в том или ином виде нужна сеть, описывается собственным профилем. К примеру, на схеме выше приведена стандартная архитектура трёхзвенного приложения, состоящего из N-ного количества серверов внешнего доступа (Web), серверов приложений (App) и серверов СУБД (DB), а также описаны правила взаимодействия между ними. В традиционной сетевой инфраструктуре это был бы набор правил, прописанных на различных устройствах в инфраструктуре. В архитектуре ACI мы описываем эти правила в рамках одного профиля приложения. ACI с помощью профиля приложения позволяет значительно упростить создание большого количества настроек на различных устройствах, сгруппировав их все в единый профиль.

На рисунке ниже показан более жизненный пример. Профиль приложения Microsoft Exchange, выполненный из нескольких EPG и контрактов.

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

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

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

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

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

Таким образом, компания Cisco на практике реализует концепцию сети центра обработки данных нового поколения. Хотите убедиться в этом сами? Приходите на демонстрацию Application Centric Infrastructure в Санкт-Петербурге и поработайте с сетью ЦОД-а будущего уже сейчас.
Записаться на мероприятие можно по ссылке.

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

Концепция и отличительные особенности Cisco ACI

Много лет подряд дата-центры (ЦОД) остаются одним из главных направлений деятельности Cisco. Международная компания не переставала уделять особенное внимание инфраструктуре дата-центров, представляя общественности новые разработки, которые учитывали мировые тенденции к росту требований и изменению подхода. Ярким примером является нацеленная на программы технология Cisco ACI. Представили технологию во второй половине 2013 года. Главной концепцией является поддержка сквозной виртуализации и возможность управления и автоматизации, при этом в основе логики работы приложений лежат настраиваемые политики. Cisco ACI дает возможность полной автоматизации программ в пределах ЦОД, а сочетание software и hardware дает выгоду, которую трудно извлечь иным способом.

Базовые компоненты Cisco ACI

Application Policy Infrastructure Controller (APIC)

Базовый элемент. Играет роль единой точки автоматизации и управления матричной структуры, настройки политик, а также мониторинга работоспособности всей системы.

Сетевые профили

Логическое представление архитектуры совокупности элементов приложения и их взаимодействия.

Коммутаторы Cisco ACI

Cisco Nexus серии 9000 обладают всеми необходимыми возможностями, чтобы удовлетворить быстро меняющиеся потребности сетей ЦОД, и используются как основа транспортной системы.

Более того, Cisco ACI предоставляет программам возможность изменять сеть для своих нужд. Для этого профиль и создается. Туда заводятся параметры, после чего профиль попадает в Cisco APIC контроллер. В то же время, контроллер настраивает коммутаторы Cisco.

Схема функционирования ACI

Как уже было упомянуто, Cisco ACI включает в себя контроллеры и коммутаторы «девятитысячной» серии, семейства Cisco Nexus. Последние имеют два режима работы: под управлением ACI контроллера или стационарный.

В режиме ACI устройство работает с понятиями программы. Указав принадлежность виртуальных/физических серверов к той или иной группе, а также порядок их взаимодействия, администратор избавляет себя от лишних обязанностей и оставляет часть задач контроллеру. В то же время, контроллер динамически перенаправляет трафик на брандмауэры и уравнивает нагрузки.

Этот день настал: растягивание ACI-фабрики

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

Сначала немного теории. Чтобы понять концепцию растянутой ACI-фабрики, важно представлять её в виде единой структуры, ведь по факту так всё и организовано. Главным её плюсом является возможность переноса рабочих задач и мобильность виртуальных серверов, при этом растянутая фабрика в обслуживании ведет себя точно так же, как и стандартная, и в полной мере обеспечивает переносимость виртуальных станций. Например, все площадки растянутой фабрики могут использовать одну платформу VMware vCenter, а хосты ESXi двух площадок находиться под контролем общего приложения vCenter и сервера DVS, которые «растянуты» между двумя местоположениями.

Отправная точка в рамках предложенного сценария: 2 центра обработки данных (ЦОД), растянутая фабрика ACI, 8 «листьев» на каждый ЦОД. ACI-фабрика использует связанные «листья». В первом центре организации данных расположены два виртуальных сервера. Они, в то же время, находятся на общем ESX-хосте.

Чтобы иметь представление о топологии, озвученной выше, сделаем обращение к консоли Cisco APIC и выберем пункт «Топология».

Для проведения живой миграции обратимся к клиенту vSphere Web. Как можно увидеть на рисунке ниже, два виртуальных сервера L-Web-Server1-T4 и L-Web-Server2-T4 находятся непосредственно на одном хосте.

Перед тем, как мигрировать, проведем маленький тест: удостоверимся, что каждая из машин «видит» другую и обе корректно отвечают на запросы. Будет логично предположить, что даже маленькая проблема в сетевой конфигурации повлияет на выполнение такого действия. Подключимся к одному из виртуальных серверов, к примеру, L-Web-Server1-T4, и попробуем «пропинговать» второй виртуальный сервер. На картинке можно увидеть ответ узла на запросы, вторая машина действует по тому же принципу.

549 Осталось только запустить «живую миграцию». Заходим в свойства виртуального сервера L-Web-Server2-T4 консоли клиента vSphere Web и выбираем «Мигрировать».

Обратим особое внимание на второй пункт контекстного меню — выбор целевого ресурса, куда укажем хост во втором центре обработки данных.

Закончив «живую миграцию», виртуальный сервер L-Web-Server2-T4 переносится во второй ЦОД на хосте 1.2.9.21, как можно наблюдать ниже на картинке.

Данные ping-теста демонстрируют, что обрывов связи не было, несмотря на расположение виртуальных серверов на физических машинах отдельных ЦОД.

Заключение

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

В концепции Cisco Application Centric Infrastructure (ACI) предлагается принципиально новый подход к построению сетевой инфраструктуры центров обработки данных. Чем же эта архитектура отличается от других, как традиционных, так и недавно появившихся?

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

МОДЕЛЬ ПОЛИТИК

Название Application Centric Infrastructure можно перевести как «инфраструктура, ориентированная на приложения». Тем самым подчеркивается, что во главу угла поставлена не сетевая, а прикладная иерархия центра обработки данных — будь то ЦОД традиционного корпоративного заказчика или оператора облачных услуг.

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

Примером может служить конфигурация межсетевого экрана, типичная для большинства крупных организаций: она содержит тысячи или даже десятки тысяч строк, и зачастую о назначении многих из них уже никто не помнит. В противоположность этому ACI описывает политику для приложений в терминах самих приложений и их компонентов (см. Рисунок 1). В качестве ключевых элементов для описания политики в инфраструктуре ACI используются сетевые профили приложений (Application Network Profile), в которых задаются правила взаимодействия между приложениями или уровнями приложения. Последние представляются в виде групп элементов (End-Point Group, EPG), входящих в состав приложения.

Сетевая инфраструктура ЦОД с акцентом на приложениях

Рисунок 1. Сетевой профиль приложения.

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

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

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

В ACI сервисные элементы включаются в путь трафика автоматически, средствами самой сетевой инфраструктуры, причем это могут быть элементы разработки как Cisco, так и сторонних компаний, как виртуальные, так и реализованные в виде отдельных устройств. Более того, инструментарий для описания сервисных элементов в формате, «понятном» ACI, достаточно прост и может быть использован сторонними разработчиками и даже ИТ-специалистами компании заказчика.

СЕТЕВАЯ ФАБРИКА

С точки зрения собственно сетевого решения ACI представляет собой коммутирующую матрицу, построенную в соответствии с двухуровневой сетевой топологией Клоза, состоящей из «листьев» (leaf) — устройств доступа, к которым подключаются серверы, сервисные элементы и каналы, соединяющие с внешним миром, — и «хребта» (spine), задачей которого является коммутация между «листьями», а также выполнение служебных функций по реализации наложенной сети (см. Рисунок 2).

Рисунок 2. Сетевая фабрика ACI.

На данный момент для построения фабрики ACI необходимо использовать коммутаторы семейства Cisco Nexus 9300/9500, специально разработанные для реализации функций ACI. Они обеспечивают, в частности, применение политики на основе EPG, создание наложенной сети, нормализацию инкапсуляции, динамическую балансировку трафика в фабрике, сбор детальной телеметрической информации и многое другое. Трафик внутри фабрики передается по высокопроизводительным соединениям 40 Gigabit Ethernet, причем для ACI были разработаны двунаправленные трансиверы 40GbE, позволяющие передавать 40GbE по обычной паре многомодовых волокон, то есть перейти с 10G на 40G без внесения каких-либо изменений в кабельную систему (эта разработка доступна теперь и в других продуктах Cisco). Для подключения серверов фабрика ACI предоставляет интерфейсы 1G, 10G и 40G, причем система построена так, чтобы переход с привычных соединений 1G на 10G происходил без заметного увеличения цены.

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

Чтобы не задействовать для этого такие ненадежные и плохо масштабируемые подходы, как «растягивание» VLAN, в современных сетевых фабриках обычно создают наложенные сети — логические сети, построенные путем инкапсуляции (туннелирования) сетевого трафика через нижележащую транспортную сеть. Для этого используются FabricPath, VXLAN, NVGRE и ряд других протоколов.

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

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

ACI использует интегрированную в сетевую фабрику технологию наложенных сетей, что позволяет строить динамически формируемые сегменты с коммутацией второго и третьего уровня поверх маршрутизируемой транспортной сети. При этом серверы могут использовать всевозможные типы подключений — обычные VLAN, инкапсуляцию VXLAN или NVGRE. На границе фабрики выполняется «нормализация» инкапсуляции в единый для фабрики формат eVXLAN, построенный на базе VXLAN с передачей в заголовках дополнительной информации. В результате появляется возможность объединить в одном логическом сегменте виртуальные машины, расположенные на хосте под управлением VMware vSphere, где применяется инкапсуляция VXLAN, и на хосте под управлением Microsoft Hyper-V с инкапсуляцией NVGRE.

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

КОНТРОЛЛЕР APIC

Централизованное управление инфраструктурой ACI осуществляет контроллер Application Policy Infrastructure Controller (APIC). В действительности он представляет собой кластер контроллеров, поскольку для целей масштабирования и обеспечения непрерывности работы APIC поддерживает кластеризацию. Несмотря на определенную аналогию с контроллером программно определяемых сетей (SDN), APIC реализует совершенно другую модель управления.

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

В архитектуре ACI функции администрирования (management plane), то есть настройка описанной выше сетевой политики приложений, а также функций мониторинга и диагностики, выполняются централизованно. При взаимодействии с элементами сети роль APIC состоит в том, чтобы довести до них правила, а не детали настройки. В этом смысле можно говорить о том, что ACI использует декларативную модель управления, когда сети и ее компонентам сообщается, какое их состояние является желаемым, а они самостоятельно, без привлечения ресурсов контроллера, достигают его и поддерживают в случае каких-либо изменений в серверах и соединениях, при миграции виртуальных машин и т. д.

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

В отрасли существует насущная потребность в использовании общего языка декларативного описания политик инфраструктуры. Совместно с другими компаниями Cisco опубликовала в IETF протокол OpFlex, где описывается «южный» интерфейс между контроллером как точкой описания правил и реализующими эти правила элементами инфраструктуры. Кроме того, Cisco планирует опубликовать референсную реализацию с открытым исходным кодом агента OpFlex для виртуального коммутатора, что позволит облегчить и ускорить внедрение данного подхода в составе систем сторонних разработчиков.

В будущем реализация OpFlex на стороне контроллера планируется не только в составе ACI, то есть под управлением контроллера APIC, но и в рамках имеющего широкую отраслевую поддержку проекта контроллера с открытым исходным кодом OpenDaylight, активным участником которого является компания Cisco. Таким образом, в перспективе можно будет говорить о возможности использования OpFlex как единого инструмента для распространения политики в информационных инфраструктурах.

Помимо доведения политики до элементов фабрики, контроллер APIC реализует и мощные возможности по получению из фабрики диагностической и телеметрической информации. Причем и в этом случае используется подход, ориентированный на приложения, — администратор может увидеть детальную информацию не только о задержках, потерях и т. д. по каждому сетевому элементу, но и о «состоянии здоровья» инфраструктуры с точки зрения конкретного приложения, что позволяет упростить диагностику и устранение проблем, а также планирование и оптимизацию производи тельности.

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

Александр Скороходов — консультант в области центров обработки данных в компа нии Cisco.

Я нарисовал относительно типичной сети ACI, и я просто сказать несколько важных компонентов:

1,1 Cisco Стратегия Application Infrastructure Controller (APIC):

APIC является единой точкой автоматизации и управления матрицами своп Cisco ACI, реализации политики и мониторинга состояния здоровья. Основные ответственные задачи включают в себя активацию подкачки матрицы, переключатель обслуживание прошивки, настройки сетевой политики и создание экземпляры. Реализация этих функций опирается на юго-направленного протокола Opflex (этот протокол Cisco подавшего IETF, но в настоящее время нет других производителей, готовых следовать, так что это соглашение может в принципе видеть частное соглашение о Cisco). Кроме того, APIC предназначен для программирования и централизованного управления. Cisco APIC предоставляет Северный API через XML и JSON, а также предоставляет интерфейс командной строки (CLI) и графический интерфейс с помощью этого API для управления обменом матрицами. Эта система также обеспечивает с открытым исходным кодом на юг путь API, позволяющий сторонним поставщикам услуг сети осуществлять контроль стратегии через Cisco APIC.

Матрица подкачки 1.2 VXLAN

Давайте поговорим о подкладочного сети, сеть Подложка является основной IP-сети между Позвоночник и листьев. Поскольку сеть Overlay НКД в принимает VXLAN технологии (я не говорю о технологии VXLAN, там также упоминается в предыдущей статье), так что сеть Подложка является относительно фиксированной, только IP может быть предоставлена. Поэтому, когда линии между физикой сетевых устройств подключены друг к другу, то контроллер автоматически выталкивает конфигурацию каждого сетевого узла для завершения сети Underlay. Этот процесс почти автоматически реализуется. Когда новый переключатель находится в сети, вы можете заполнить все конфигурации сети до тех пор, как вы подключите текущие ТКАНИ. Стоит отметить, что конфигурация сети Подложка полностью черный ящик, и совершенно непонятно, чтобы войти в коммутаторе. По словам инженера Cisco, в настоящее время нет открытой сети Устранение неполадок. После моего исследования, я чувствую, как ISIS и BGP состав. трехслойная сеть, балансировка нагрузки с помощью ECMP, поскольку сеть Подложки является сетью трехслойной, так что горизонтальное расширение очень легко, подходит для супер крупных центров обработки данных. Физический выключатель сети ACI в основном подключи и работай, делая расширение сети более гибкой.

Затем, наложенная сеть, хост доступ LEAF коммутатор в сети ACI является VTEP, поэтому логика доступа к сети завершаются наложенной сетью, поэтому сеть Overlay фактически развязана с устройством физической сети, сеть Overlay может полностью игнорировать физическая сеть, и является гибким в соответствии с приложением.

Специальный говоря , что ACI является типичным аппаратным решением Overlay, Cisco является поставщиком оборудования, поэтому он несет ответственность за VTEP упакованного пакетом VXLAN на физическом коммутаторе (LEAF узел), так что он поддерживает любые виртуализации в решении ACI. Технологии , но напротив аппаратные коммутаторы также связаны с коммутаторами Cisco ACI. Это просто противоречит решению программного обеспечения Overlay. В программной схеме Overlay, аппаратный переключатель может быть выбран как только три слоя совместим, а программный коммутатор должен использовать виртуализированные производитель, такие как VMware NSX.

1.3 Применение в центре сети

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

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

Сетевой сервисный профиль приложения в GUI контроллера

Сетевые администраторы и владельцы приложений могут использовать GUI APIC для определения связности компонентов приложения, а также создавать «контракты» для коммуникаций между ними: кому позволено передавать данные, по каким портам, какое качество обслуживания требуется, какие сетевые службы необходимы.

Состав фабрики ACI

Сама ACI-фабрика построена на коммутаторах Nexus 9000, которые интерпретируют сетевые абстракции приложений в политики, применяемые к подключаемым виртуальным и/или физическим серверам (расширяются Nexus 2000). Все коммутаторы доступа (leaf) связаны по каналам 40 Гбит со всеми коммутаторами агрегации (spin).

Сетевые абстракции разрабатываются в Контроллере Политик Инфраструктуры Application Policy Controller (APIC). Контроллер представляет собой отказоустойчивый кластер из трех серверов, который поддерживает базу данных информации о конфигурациях, и транслирует эту информацию в сетевые политики и программирует в коммутаторах. Контроллер собирает и визуализирует «здоровье» сети: задержки и потери пакетов для каждого приложения, для группы приложений, для ландшафтов (теннант), состояние сети в общем.

ACI Фабрика и кластер APIC

Для подключения виртуальной инфраструктуры используется новая версия виртуального коммутатора Nexus 1000V – Cisco Application Virtual Switch (AVS), который также управляется контроллером APIC (возможно использование и стандартных виртуальных коммутаторов). APIC кроме того работает с рядом сторонних продуктов, в том числе с балансировщиками нагрузки от Citrix и F5, и с межсетевыми экранами ASA, коммутаторами Catalyst, маршрутизаторами ISR и ASR.

ACI цепочка сетевых сервисов

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

Не только инструмент для настройки

APIC — это не просто утилита автоматизации, которая создает файлы конфигураций. Физические (и виртуальные) коммутаторы ACI используют VXLAN(Virtual Extensible LAN)-технологию, для передачи L2 поверх L3-инфраструктуры, при этом пользователю нет необходимости настраивать VXLAN (при добавлении коммутатора в фабрику ACI ему присваивается служебный IP-адрес и формируется связность с другими).

В VXLAN Ethernet фреймы инкапсулируются в UDP-пакеты, которые могут воспользоваться преимуществами L3: IP-мультикаст, маршрутизация, балансировка по множеству аплинков и так далее. Благодаря этому размер фабрики легко масштабируется от 2 до тысяч коммутаторов, до 1 млн IPv4 / IPv6 хостов без увеличения сложности администрирования. Контроллер является инструментом настройки и управления.

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

ACI строит ЦОД-фабрику поверх VXLAN — это способ получить «растянутый» L2 домен, без «классических» ограничений, присущих L2. Например, нет широковещательных рассылок (если только не включена опция бродкаста), т.к. на каждом коммутаторе агрегации (Spin) находится общая база знаний обо всех MAC/IP-адресах по всей фабрике. Подключение хостов возможно как с помощью VLAN, так и VXLAN, NVGRE — каждый коммутатор доступа (Leaf) проводит нормализацию в VXLAN.

VXLAN в Nexus 9000— это аппаратный оверлей, и, в отличии от программного (на уровне гипервизора), ACI владеет информацией о текущем состоянии коммутаторов и аплинков фабрики, сервисных профилей приложений, может эффективно балансировать нагрузку, приоритезировать и, при необходимости, перенаправлять на инспекцию или зеркалировать трафик. Виртуальный Application Virtual Switch также управляется контроллером, понимает профили приложений и может быть софтовым оверлеем (VXLAN отрабатывается CPU сервера) или же отправлять трафик на аппаратный оверлей (т.е. коммутатор, к которому подключен гипервизор). В контроллере APIC имеются встроенные утилиты по нахождению и устранению неисправностей.

Cisco ACI рассматривает сеть ЦОД как единое целое, а не совокупность коммутаторов. Решение использует центральный APIC-контроллер, чтобы автоматизировать такие задачи, как первоначальный запуск ACI-фабрики, применение обновлений и индивидуальных конфигураций коммутаторов. ACI позволяет администраторам приложений применять политики в сети, просто описывая как компоненты приложений связаны друг с другом.

ACI предоставляет новый способ взглянуть на сети ЦОД, и сетевые администраторы могут тратить намного меньше времени на настройку, устранение неисправностей и отладку конфигураций ЦОД.

Конечная цель заключается в значительном сокращении операционных расходов и скорости внедрения новых бизнес-услуг и сервисов.

Читайте также: