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

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

Архитектура 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.