Cisco ACI: основа сетевой архитектуры современного ЦОД

Когда сеть в дата-центре строится вокруг коммутаторов, к которым инженер подключается по SSH, каждый новый клиент, каждое изменение безопасности или миграция сервиса превращаются в рутину из десятков команд. VLAN нужно создать на каждом устройстве, STP — проверить, согласовать агрегированные каналы. Чем больше арендаторов и сложнее инфраструктура, тем больше ручной работы ложится на сетевую команду, и тем выше риск ошибки при очередном изменении.

Cisco ACI предлагает другой подход. Вместо россыпи индивидуальных конфигураций — централизованное управление через контроллер APIC. Вместо привязки политик к IP-адресам — логические группы приложений EPG и понятные контракты между ними. Сеть перестает быть пассивным транспортным слоем и становится платформой, готовой к быстрым изменениям. Для облачного провайдера, где сотни арендаторов требуют изоляции, производительности и быстрого выделения ресурсов, такая архитектура становится отраслевым стандартом.

Архитектура Cisco ACI: ключевые компоненты

Cisco ACI — это программно-определяемая архитектура, которая переосмысливает управление сетью в современном дата-центре. Чтобы понять, как ACI меняет подход к организации сети в дата-центре, стоит начать с основы — физической топологии. Вместо классической иерархии «ядро — агрегация — доступ» с ее сложными протоколами loop prevention и непредсказуемыми путями трафика, ACI использует архитектуру Spine-Leaf. Это два уровня:

• Leaf — коммутаторы, к которым подключается клиентское оборудование: серверы, устройства хранения данных, физические маршрутизаторы, а также гипервизоры и апплайенсы;
• Spine — коммутаторы, выполняющие роль высокоскоростной коммутационной матрицы. Каждый leaf соединяется с каждым spine, формируя полносвязную топологию.

Каждое соединение работает по принципу ECMP — трафик распределяется равномерно по всем доступным путям. В результате:

• исчезает необходимость в STP и его ограничениях;
• задержки становятся предсказуемыми и одинаковыми между любыми парами устройств;
• добавление новых spine или leaf-коммутаторов расширяет фабрику горизонтально без простоев и переконфигурации.

Центральным элементом управления выступает контроллер APIC — Application Policy Infrastructure Controller. В типовой инсталляции их три, и работают они в кластере. APIC не участвует в передаче данных, не обрабатывает каждый пакет, а занимается исключительно управлением. Задачи APIC:

• создание и хранение политик;
• конфигурация тенантов и их изоляция;
• задание правил безопасности и сервисных граф;
• мониторинг состояния и сбор телеметрии.

Инженер взаимодействует с APIC через веб-интерфейс, REST API или инструменты автоматизации вроде Terraform и Ansible, а контроллер уже сам проталкивает нужные настройки на все коммутаторы фабрики. Это ключевое отличие от классической модели, где каждое устройство настраивается отдельно.

Логическая модель ACI строится вокруг нескольких базовых абстракций, которые заменяют привычные VLAN, VRF и ACL:

• Тенант — контейнер полной изоляции, аналог VRF в традиционной сети. Включает в себя не только маршрутизацию, но и политики безопасности, сервисные графы, интеграцию с внешними контроллерами виртуализации. Для облачного провайдера тенант — это естественная граница между клиентами.
• Bridge Domain (BD) — по смыслу близка к VLAN, но с важным отличием. ACI подавляет широковещательный трафик ARP на уровне всей инфраструктуры. Это существенно разгружает сеть в крупных инсталляциях, где тысячи виртуальных машин постоянно отправляют ARP-запросы.
• VRF (Private Network) — контекст маршрутизации внутри тенанта. Обеспечивает изоляцию трафика между разными сетями одного клиента.

Главная же инновация скрывается в понятии Endpoint Group — EPG. Вместо того чтобы думать о сети в терминах IP-адресов и портов коммутаторов, администратор описывает группы приложений. Пример EPG в типичном трехзвенном приложении:

• EPG «веб-серверы»;
• EPG «прикладные серверы»;
• EPG «базы данных»;
• EPG «внешний мир» (выход в интернет или в корпоративную сеть).

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

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

Микросегментация и Политики

Когда сеть строится вокруг физических портов и IP-адресов, политики безопасности превращаются в длинные списки ACL, разбросанные по десяткам коммутаторов. Добавил новый сервер — нужно обновить правила на всех устройствах, где этот сервер должен быть виден. Переехала виртуальная машина на другой хост — правила перестали работать, пока инженер вручную не перенесет их. В динамичной среде, где приложения живут неделями, а инфраструктура пересобирается из кода, такой подход становится главным источником ошибок и задержек.

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

Контрактный подход

Вместо списков правил «разрешить IP 10.1.1.5 к IP 10.2.2.10 на порт 3306» инженер работает с контрактами между группами. Контракт — это документированное и версионируемое описание того, как сервисы общаются друг с другом:

• Subject — что именно разрешено (например, HTTP, HTTPS, MySQL);
• Filters — детализация до протоколов и портов;
• Direction — обмен данными: только от источника к получателю или в обе стороны.

Контракт заключается между двумя EPG. Например, EPG «веб-серверы» получает контракт на доступ к EPG «базы данных» по порту 3306. Обратный трафик разрешается автоматически, и инженеру не нужно прописывать симметричные правила.

Преимущества такого подхода:

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

Микросегментация

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

В традиционной сети реализовать микросегментацию сложно:

• для каждой зоны нужен отдельный VLAN или VRF;
• межсетевые экраны становятся узким местом, через которое пропускается весь трафик;
• добавление новой зоны требует изменений на всех уровнях сети.

В ACI микросегментация заложена в архитектуру:

• каждая EPG по умолчанию изолирована — без явного контракта трафик между EPG не проходит;
• изоляция реализуется на Leaf-коммутаторах, а не на централизованном файрволе, что исключает узкие места;
• количество EPG ограничено только мощностью контроллеров и может достигать тысяч.

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

Сервисные графы

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

В ACI эта задача решается через Service Graph — сервисные графы. Это визуальное описание цепочки сервисов, через которые должен проходить трафик между EPG.

• Граф — последовательность устройств (виртуальных или физических), через которые направляется трафик.
• Узлы графа — конкретные экземпляры файрвола, балансировщика нагрузки или других устройств.
• Функции — конфигурация, которая применяется на этих устройствах (например, политики файрвола).

Service Graph автоматически:

• определяет, какой трафик нужно перенаправить;
• настраивает PBR на Leaf-коммутаторах;
• обеспечивает симметричное прохождение трафика в обоих направлениях;
• при необходимости инжектирует маршруты для возвратного трафика.

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

Изоляция клиентских сред

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

Как это реализуется в ACI:

• На уровне тенантов — полная изоляция между клиентами. Один тенант не видит трафик другого, и контракты между ними невозможны по определению;
• Внутри тенанта клиента — микросегментация через EPG. Клиент может создавать EPG для каждого своего приложения: CRM, биллинг, мониторинг, базы данных;
• Между EPG — контракты, которые клиент описывает через портал самообслуживания (интегрированный с APIC через API);
• На границе — Service Graph с общим файрволом, через который проходит трафик между EPG клиента и внешним миром.

В результате:

• клиенты получают полную изоляцию друг от друга без дополнительных устройств;
• внутри своей среды клиент самостоятельно управляет правилами доступа между приложениями;
• провайдер не участвует в ручной настройке ACL при каждом изменении в клиентской среде;
• при атаке на одно приложение злоумышленник не получает доступа к соседним сервисам того же клиента.

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

Интеграция с облаком

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

VMware vCenter: автоматизация на уровне портгрупп

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

С ACI эта цепочка упрощается до одного действия — настройки VMM Domain (Virtual Machine Manager Domain):

• VMM Domain связывает APIC с vCenter, передавая информацию о кластерах хостов, датасторах и сетевых настройках;
• APIC автоматически создает портгруппы на распределенных коммутаторах vCenter для каждой EPG, которая привязана к этому VMM Domain;
• Когда администратор разворачивает виртуальную машину и подключает ее к определенной портгруппе, APIC автоматически применяет к трафику этой VM все политики, заданные для соответствующей EPG.

Что происходит автоматически:

• создание и удаление портгрупп при добавлении или удалении EPG;
• применение политик безопасности к трафику виртуальной машины независимо от того, на каком хосте она запущена;
• поддержка vMotion без участия сетевого инженера — политика переезжает вместе с VM;
• распределение VLAN на физические коммутаторы по мере необходимости, без ручного конфигурирования.

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

OpenStack: сеть, которой не нужно управлять

OpenStack изначально проектировался как платформа с программно-определяемой сетью через модуль Neutron. Однако стандартные реализации Neutron на базе Open vSwitch или Linux bridge имеют ограничения по производительности и масштабируемости, особенно когда речь идет о десятках тысяч портов и сложных политиках безопасности.

Интеграция ACI с OpenStack работает через механизм ML2 (Modular Layer 2) драйвера:

• Neutron управляет сетями, подсетями и портами через стандартный API OpenStack;
• ACI ML2 драйвер транслирует вызовы Neutron в конфигурацию APIC;
• Вся сетевая логика — VLAN, VXLAN, security groups, маршрутизация — реализуется на уровне инфраструктуры, а не на вычислительных хостах.

Преимущества для облачного провайдера, строящего OpenStack-облако:

• Производительность — трафик между виртуальными машинами коммутируется на Leaf-коммутаторах, минуя программный стек на гипервизорах;
• Безопасность — security groups OpenStack транслируются в контракты ACI и реализуются на уровне инфраструктуры, без нагрузки на хосты;
• Масштабирование — добавление новых вычислительных узлов не требует настройки сетевых агентов на каждом сервере;
• Единая политика — сети OpenStack, созданные через Horizon или CLI, автоматически получают все возможности ACI: микросегментацию, сервисные графы, маршрутизацию между тенантами.

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

Kubernetes: контейнеры в единой сетевой политике

Контейнерная оркестрация добавляет новый уровень динамики. Поды в Kubernetes могут появляться и исчезать в течение нескольких минут, и каждый под должен получить IP-адрес и сетевые политики, соответствующие его роли в приложении. Стандартные CNI-плагины (Calico, Flannel, Cilium) решают эту задачу по-разному, но часто изолируют контейнерную сеть от остальной инфраструктуры, создавая отдельные сетевые домены.

ACI CNI (Container Network Interface) встраивает контейнеры в ту же сетевую модель, которая используется для виртуальных и физических серверов:

• Установка — ACI CNI разворачивается в кластере Kubernetes как набор подов (opflex-agent, контроллеры) и интегрируется с APIC;
• Привязка к EPG — каждое пространство имен (namespace) или набор меток (labels) может быть привязан к определенной EPG. Поды, запущенные в этом namespace, автоматически получают политики, заданные для EPG;
• Сетевая модель — контейнеры получают IP-адреса из того же пула, что и виртуальные машины, и могут обмениваться трафиком без NAT и дополнительных шлюзов.

Что это дает на практике:

• Единая политика безопасности — контракт между EPG «веб-серверы» (виртуальные машины) и EPG «базы данных» (контейнеры) работает так же, как между двумя EPG виртуальных машин;
• Микросегментация контейнеров — поды в одном кластере могут быть изолированы друг от друга на уровне EPG, даже если они работают на одном узле;
• Наблюдаемость — APIC видит все эндпоинты (виртуальные машины, физические серверы, контейнеры) в единой картине, что упрощает траблшутинг;
• Service Graph для контейнеров — трафик между подами может проходить через те же балансировщики нагрузки и межсетевые экраны, что и трафик между виртуальными машинами.

Для разработчика, который деплоит приложение в Kubernetes, работа с сетью не усложняется. Он продолжает использовать стандартные объекты NetworkPolicy, а ACI CNI реализует их через контракты. Но для команды эксплуатации это означает, что контейнеры перестают быть «черной дырой» с точки зрения сетевой безопасности и наблюдаемости.

Одна политика на все дата-центры

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

Cisco ACI предлагает два уровня агрегации:

• Multi-Pod — объединяет несколько инсталляций (фабрик) ACI в одном географическом регионе (например, несколько залов одного ЦОД). Поды работают как единая среда с общим APIC кластером, и политики автоматически синхронизируются между ними.
• Multi-Site — объединяет независимые инсталляции ACI в разных географических регионах. Через Nexus Dashboard Orchestrator администратор управляет политиками на всех площадках из единого интерфейса.

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

Автоматизация сети

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

Подход API-first

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

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

Инфраструктура как код

Для команд, которые уже строят свою инфраструктуру по принципу Infrastructure as Code, Terraform стал естественным языком описания ресурсов. Cisco ACI позволяет описывать сетевую конфигурацию в тех же декларативных файлах, что и виртуальные машины, объекты хранения или контейнерные кластеры.

Через Terraform можно управлять всеми ключевыми объектами ACI:

• тенанты и настройки их изоляции;
• VRF, Bridge Domain, подсети;
• EPG и контракты между ними;
• интеграции с vCenter и другими VMM доменами;
• Service Graph с встраиванием L4-L7 устройств.

Для облачного провайдера это открывает несколько важных сценариев. Новая клиентская среда разворачивается выполнением одного terraform apply без череды ручных действий в интерфейсе. Конфигурация сети хранится в Git вместе с конфигурацией вычислительных ресурсов, что дает полную историю изменений и упрощает аудит. А когда клиент завершает работу, terraform destroy удаляет все связанные объекты без риска оставить забытые настройки, которые потом будут мешать или создавать угрозы безопасности.

Автоматизация типовых задач

Если Terraform отвечает за декларативное описание желаемого состояния, то Ansible лучше подходит для выполнения последовательных операций и встраивания сетевых задач в существующие процессы. Коллекция cisco.aci содержит модули для управления практически любым объектом APIC, и с их помощью можно автоматизировать повседневные действия, которые раньше требовали ручного труда.

Вот несколько типовых сценариев, которые закрываются Ansible:

• создание нового тенанта по шаблону — плейбук принимает название клиента и автоматически настраивает VRF, Bridge Domain и базовые EPG;
• подключение нового арендатора — настройка изоляции, экспорт маршрутов в пограничные маршрутизаторы, создание VPN-туннелей для удаленного доступа;
• массовые операции — добавление сотни EPG в существующий тенант или обновление контрактов для всех приложений клиента;
• аудит и сверка — сбор текущей конфигурации из APIC и сравнение с эталоном, хранящимся в репозитории.

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

Кастомные интеграции

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

ACI Toolkit (также известный как cobra SDK) — это Python библиотека для взаимодействия с APIC. Она предоставляет объектную модель, которая полностью повторяет структуру управляемых объектов APIC, и позволяет:

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

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

Заключение

Подведем итог всему сказанному и выделим главные составляющие CIsco ACI. Архитектура ACI строится на трех китах: физическая топология Spine-Leaf, централизованный контроллер APIC и гибкая логическая модель из тенантов, EPG и контрактов. На этой основе реализуется микросегментация приложений, встраивание L4-L7 сервисов через Service Graph и бесшовная интеграция с VMware, OpenStack и Kubernetes. Таким образом ACI дает облачному провайдеру предсказуемую и отказоустойчивую основу, на которой можно строить сервисы любого уровня сложности.

Если перед вами стоит задача построить надежную и современную инфраструктуру для своих приложений, обратите внимание на решения ИТ-ГРАД. Наши специалисты с огромным опытом работы с облачными решениями помогут развернуть такую архитектуру, которая будет соответствовать вашим задачам, обеспечит высокую производительность, изоляцию и быструю автоматизацию.

Частые вопросы

1. Чем Cisco ACI принципиально отличается от классической сети с коммутаторами, настроенными вручную?

В классической сети каждый коммутатор настраивается отдельно через CLI или систему управления конфигурациями. При добавлении нового сервера или изменении политики безопасности изменения нужно вносить на всех коммутаторах, через которые проходит трафик. ACI работает иначе: вся конфигурация задается централизованно через контроллер APIC, а коммутаторы (Leaf и Spine) только исполняют политики, которые им отправляет контроллер. Это снижает риск ошибок, ускоряет изменения и позволяет управлять сетью как единым целым, а не россыпью отдельных устройств.

2. Как ACI интегрируется с существующей виртуализацией — VMware vSphere, Microsoft Hyper-V или KVM?

ACI имеет встроенные механизмы интеграции с основными платформами виртуализации через так называемые VMM Domain (Virtual Machine Manager Domain). Для VMware vCenter это означает, что APIC автоматически создает портгруппы на распределенных коммутаторах, соответствующие EPG. Когда виртуальная машина подключается к такой портгруппе, ACI применяет к ее трафику все политики безопасности, заданные для этой EPG. При миграции VM между хостами политики «переезжают» вместе с ней без участия сетевого инженера. Для OpenStack используется ML2 драйвер, который транслирует вызовы Neutron в конфигурацию APIC. Для KVM без OpenStack доступны агенты, которые работают по тому же принципу. В итоге администраторы виртуализации продолжают работать в привычных интерфейсах, а сетевые политики применяются автоматически.

3. Какие преимущества в безопасности дает ACI по сравнению с традиционными VLAN и ACL?

Главное преимущество — микросегментация на уровне отдельных приложений. В классической сети сегментация обычно строится вокруг VLAN: все серверы в одном VLAN доверяют друг другу по умолчанию. ACI позволяет создавать EPG для каждого компонента приложения (веб-серверы, прикладные серверы, базы данных) и по умолчанию запрещает трафик между разными EPG. Доступ разрешается только через контракты, где явно указывается, какой протокол и порт открыт. Кроме того, ACI реализует политики безопасности на Leaf-коммутаторах, а не на централизованном межсетевом экране, что исключает появление единой точки узкой производительности. При атаке на один компонент злоумышленник не получает автоматического доступа к соседним сервисам — горизонтальное перемещение блокируется архитектурно.

4. Насколько сложно автоматизировать ACI и какие инструменты для этого нужны?

ACI спроектирован с принципом API-first, то есть все действия, доступные в графическом интерфейсе APIC, также доступны через REST API с поддержкой JSON и XML. Для автоматизации можно использовать стандартные DevOps-инструменты. Terraform позволяет управлять инфраструктурой как кодом, Ansible с коллекцией cisco.aci подходит для выполнения типовых задач. Для кастомных сценариев (интеграция с биллингом, клиентский портал, тикетная система) используется Python с библиотекой ACI Toolkit (cobra SDK). Порог входа выше, чем у ручного CLI, но после настройки автоматизации сетевая команда тратит в разы меньше времени на рутинные операции.