Сети центров обработки данных: устройство, Cisco ACI и современные решения

Центр обработки данных (ЦОД, или дата-центр) — это особый объект с инфраструктурой и оборудованием для обработки, хранения и распространения информации и сервисов: залы с множеством серверов, систем хранения, сетевого оборудования и т. д. Чтобы все эти серверы могли обмениваться данными друг с другом и с внешним миром, внутри ЦОДа создается специальная сеть. 

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

В статье Илья Глейкин, ведущий бизнес-консультант компании «АРБАЙТ» и ИТ-эксперт, рассмотрит устройство дата-центров, Cisco ACI и современные решения.

Основные задачи сети дата-центра можно сравнить с системой дорог в мегаполисе — она должна связать между собой все «районы» (серверы и хранилища) и обеспечить быстрое и безопасное движение «трафика» (данных). Ключевые задачи такой сети включают:

• Соединение всех узлов — сеть должна связать между собой тысячи серверов, систем хранения данных и сетевых устройств внутри ЦОДа, а также обеспечить выход к внешним сетям (интернету или корпоративным филиалам).
• Высокая пропускная способность и низкие задержки — каналы связи должны передавать данные на скоростях десятки гигабит в секунду, с минимальными задержками, чтобы приложения работали быстро.
• Отказоустойчивость — сеть должна работать 24/7 без простоев. Для этого все ключевые элементы дублируются: если один коммутатор или линия выйдет из строя, трафик пойдет по резервному пути.
• Масштабируемость — должна быть возможность легко наращивать инфраструктуру (добавлять новые серверы и сетевые устройства) без изменения архитектуры всей сети, чтобы ЦОД мог расти по требованиям бизнеса.
• Сегментация и безопасность — важно разделять потоки данных разных приложений и клиентов. Сеть должна уметь изолировать трафик (например, различными VLAN, виртуальными сетями или другими механизмами), чтобы данные одних сервисов не мешали другим и соблюдались требования безопасности.
• Удобство управления — учитывая масштаб, администрировать сеть вручную крайне сложно. Современные сети ЦОД стремятся к централизованному управлению и автоматизации: чтобы сетевые настройки можно было менять быстро и с минимумом ошибок, а также мониторить состояние всей сети из единого центра.

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

Развитие архитектуры сети ЦОД: от классики к «фабрикам»

Для соединения тысяч устройств в дата-центре применяют многоуровневую архитектуру сети. 

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

Например, на уровне доступа и агрегации используется коммутация L2 (второго уровня модели OSI), и чтобы предотвратить «петли» в сети, используется протокол spanning tree, который отключает дублирующие линии связи между коммутаторами. 

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

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

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

Решением проблемы стала топология, пришедшая из мира телефонии — Clos (топология Клоса), известная также как архитектура «spine-leaf». Первая версия такой топологии была придумана Чарльзом Клосом в 1952 году для телефонных коммутаторов того времени. 

В современном варианте этой архитектуры используются всего два уровня: коммутаторы leaf подключают непосредственно серверы и устройства в стойках, а коммутаторы spine связывают между собой все коммутаторы leaf. Каждый leaf-коммутатор соединяется с каждым spine-коммутатором, образуя многократные параллельные пути для трафика. 

По сути, архитектура spine-leaf — это основа сетевой фабрики (fabric), где сеть действует как единое целое: любое клиентское устройство (сервер) может связаться с любым другим клиентским устройством не более чем через три коммутатора (leaf1 — spine — leaf2). 

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

Как показано на схеме выше, фабрика обычно использует маршрутизацию L3 между spine и leaf, то есть все связи между коммутаторами работают на уровне IP (3 уровень), что устраняет проблему петель и необходимости блокировать дублирующие каналы. Но при этом возникает вопрос: как быть, если нужно предоставить L2-соединение (как в одной локальной сети) для узлов, которые находятся на разных leaf-коммутаторах? 

Например, если два сервера должны быть в одной VLAN или один сервер переехал на другой конец ЦОДа, а IP-адрес менять нельзя. 

Для этого используются оверлейные технологии —поверх L3-фабрики создаются виртуальные L2-сети. В современной реализации стандартом де-факто стала связка VXLAN + MP-BGP EVPN.

• VXLAN (Virtual eXtensible LAN) — технология туннелирования, которая позволяет «обернуть» Ethernet-фреймы (L2) в IP-пакеты (L3). Проще говоря, VXLAN создает поверх IP-сети виртуальную «локальную сеть», где могут находиться серверы, физически разбросанные по разным стойкам и залам. Это похоже на прокладку виртуального «кабеля» между двумя удаленными компьютерами: им кажется, что они в одном сегменте, хотя на самом деле между ними маршрутизируемая фабрика.
• MP-BGP EVPN (Multiprotocol BGP with Ethernet VPN) — протокол, который решает задачу управления этими VXLAN-туннелями. Без EVPN коммутаторам пришлось бы «угадывать» или рассылать широковещательные запросы, чтобы найти друг друга в такой виртуальной сети (так называемый flood-and-learn). EVPN же позволяет коммутаторам обмениваться служебной информацией (таблицами MAC-адресов, идентификаторами виртуальных сетей и т.п.) через расширения протокола BGP. В итоге система знает, где какой сервер подключен, и куда пересылать трафик — быстро и без лишних широковещательных рассылок. Это значительно увеличивает масштабируемость и эффективность VXLAN-оверлея.

Благодаря VXLAN/EVPN концепция сетевой «фабрики» стала стандартом построения сети ЦОД за последние годы. Она обеспечивает маршрутизируемую, высокодоступную архитектуру без блокировок, предоставляя связность и изоляцию трафика на 2 и 3 уровнях модели OSI независимо от физического расположения серверов. Так, любой сервер может обмениваться данными с любым другим, как будто они подключены к одному коммутатору, а администраторы могут логически группировать и изолировать сегменты сети для разных приложений или клиентов.

Простая аналогия: большой офис с десятками комнат. Традиционная сеть с VLAN напоминала бы ситуацию, когда для объединения компьютеров из двух разных комнат в одну сеть нужно протянуть специальный провод между этими комнатами (или соединить их через общий центральный коммутатор). VXLAN же — это как дать всем сотрудникам специальный шифратор связи: они могут общаться напрямую по общей корпоративной IP-сети, но при этом шифратор «делает вид», что они подключены к одному виртуальному коммутатору. EVPN в этой аналогии — это центральный каталог внутренних номеров: он знает, где чей телефон (MAC-адрес), и направляет звонок прямо в нужную комнату, не прозванивая вслепую все помещения.

Итак, современная сеть ЦОД часто представляет собой L3-фабрику с оверлеем для L2- или L3-трафика. Реализовать такую сеть можно разными способами: либо вручную настроить каждое сетевое устройство на работу с BGP, EVPN и VXLAN (так делают многие продвинутые инженеры или используют автоматизацию через скрипты или системы управления конфигурациями типа Ansible, которые позволяют реализовывать подход «Сеть как код»), либо воспользоваться специализированными решениями, которые упрощают и автоматизируют управление всей фабрикой. 

Одно из самых известных таких решений — фабрика Cisco ACI. Рассмотрим его подробнее.

Cisco ACI: фабрика, ориентированная на приложения

Cisco ACI (Application Centric Infrastructure) — это решение компании Cisco для построения и управления сетями дата-центров, появившееся около 2014 года. Название переводится как «инфраструктура, ориентированная на приложения», и это ключевая идея ACI. Если обычные сети настраиваются в терминах IP-адресов, VLAN-ов, маршрутов и т. д., то ACI предлагает описывать требования на языке приложений и их взаимодействий, а система сама позаботится о низкоуровневых сетевых настройках. 

Cisco ACI — это программно-определяемая сеть (SDN) для ЦОДа, где есть централизованный «мозг» (контроллер), управляющий «фабрикой» коммутаторов.

В физическом плане — это все та же spine-leaf фабрика, обычно на базе высокопроизводительных коммутаторов Cisco Nexus 9000. Отличие в том, что коммутаторы работают под управлением особых контроллеров Cisco, называемых APIC (Application Policy Infrastructure Controller). 

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

Важно подчеркнуть, что Cisco ACI — комплексное решение, включающее три составляющих:

1. Сетевая фабрика — набор коммутаторов (spine/leaf), соединенных между собой и образующих высокоскоростную «ткань» сети.
2. Подключенные к сети объекты — это могут быть физические серверы, виртуальные машины, контейнеры и другие устройства, которые пользуются сетевыми ресурсами.
3. Централизованное управление с политиками — программная платформа (контроллеры APIC) для настройки сети, где задаются политики взаимодействия приложений и правила безопасности, которые затем автоматически применяются к фабрике.

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

Например, администратор приложения говорит: «Вот приложение — оно состоит из веб-сервера и серверов базы данных; веб-сервер должен общаться с БД по порту 3306, а пользователи должны достучаться до веб-сервера по HTTP/HTTPS». Сетевой администратор добавляет требования по IP-адресам или VLAN (если нужны), а специалист по безопасности — правила взаимодействия, такие как, например, веб-сервер не может напрямую видеть сервер базы данных, кроме как через определенный TCP или UDP порт. Все эти требования объединяются контроллером в некий «профиль приложения». 

Контроллер ACI (APIC) берет этот профиль и компилирует его в конкретные настройки для коммутаторов и передает их на каждый коммутатор фабрики. На коммутаторах на основании этой информации создаются нужные VLAN/VXLAN, списки доступа (ACL) или правила безопасности на соответствующих портах, IP-адреса и т.д. Администратору не нужно вручную заходить на каждый коммутатор и настраивать десятки команд — все происходит автоматически, согласно заданной политике.

Таким образом, подход управления фабрикой Cisco ACI отходит от принципов управления классической сетевой инфраструктурой: вместо того чтобы оперировать портами и VLAN-ами, оперируют Endpoint Groups (EPG) — группами конечных устройств по смысловой принадлежности (например, «веб-серверы приложения X» — одна группа, «базы данных приложения X» — другая). 

Между группами настраиваются «контракты» — правила, какие виды трафика (протоколы/порты) разрешены между конкретными группами. Все остальное (создание VXLAN-туннелей, прописи маршрутов, применение ACL на портах) делает система. Получается «сеть, ориентированная на приложения»: администратор описывает, каким приложениям какое взаимодействие нужно, а необходимые настройки на сетевом уровне формирует и применяет автоматика.

Преимущества Cisco ACI

Централизованное управление и автоматизация

ACI позволяет видеть и настраивать всю сеть ЦОДа как единое целое. Через интерфейс APIC администратор может за несколько кликов развернуть новую сегментированную сеть для приложения, которая сразу охватит десятки коммутаторов. 

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

По сути, ACI приносит в сетевой мир подход DevOps: сетевую инфраструктуру можно программировать через API, интегрировать с системами оркестрации (например, с OpenStack, Kubernetes и др.), а шаблоны конфигураций переиспользовать.

Гибкость и скорость изменений

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

Например, развертывается новое приложение — админ определяет профили для его компонентов, и сеть автоматически настраивается под него. 

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

Сегментация и безопасность по умолчанию

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

Можно задавать тонкие правила, например, разрешить определенный порт между двумя группами, запрещая все остальное, — и эти правила будут реализованы распределено на всех необходимых коммутаторах. Это повышает безопасность внутри ЦОДа, препятствуя несанкционированным взаимодействиям даже на уровне отдельных приложений.

Интеграция с виртуализацией и контейнерами

Cisco ACI умеет интегрироваться с системами виртуализации VMware, Hyper-V, OpenStack, а также с оркестраторами контейнеров (Kubernetes). Контроллер ACI видит виртуальные машины и контейнеры и может автоматически добавлять их в нужные EPG (группы) по метаданным. 

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

Высокая производительность и масштабируемость

Поскольку в основе ACI — продуктивная аппаратная платформа (коммутаторы Nexus 9000) и проверенные протоколы (внутри ACI тоже используется VXLAN для оверлея), сеть не теряет в скорости. Пользователь получает ту же неблокируемую фабрику L3, но с надстройкой в виде центрального «мозга». 

Cisco ACI поддерживает многоподдоменную и многодоменную архитектуры — то есть можно объединять несколько географически разделенных площадок в единую управляемую сеть. Это важно для больших компаний: несколько ЦОДов могут работать под управлением одного кластера контроллеров (или связанных между собой контроллеров) с общей политикой.

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

Недостатки и ограничения ACI

Однако у Cisco ACI есть и свои минусы (как технические, так и организационно-финансовые):

• Сложность освоения и внедрения. Парадоксально, но, чтобы упростить жизнь, сперва надо существенно повысить квалификацию команды или привлечь экспертов. В Cisco ACI применяется достаточно сложная концепция, требующая понимания как сетевых технологий, так и умения мыслить на уровне приложений. При внедрении часто приходится перестраивать процессы: сетевые инженеры учатся работать с API и политиками, взаимодействовать теснее с администраторами приложений и безопасности. В небольших организациях, где один-два инженера совмещают несколько специализаций, Cisco ACI может оказаться избыточно сложным в управлении, но когда в управлении находится несколько крупных ЦОДов, использование будет весьма эффективным.
• Привязка к оборудованию одного вендора (vendor lock-in). Фабрика ACI — проприетарное решение Cisco. Оно требует использования совместимых коммутаторов Cisco (серии Nexus ACI-Mode) и контроллеров APIC. Это снижает гибкость в выборе аппаратуры и может вести к высокой стоимости.
• Стоимость владения. Помимо затрат на оборудование Cisco Nexus, ACI — это платные программные лицензии и сервисная поддержка Cisco. Для многих компаний начальные инвестиции в ACI довольно велики по сравнению с традиционными сетями. Конечно, оправдано это или нет — зависит от масштаба: на больших сетях окупается экономией трудозатрат, но на маленьких площадках выгоднее может быть классический подход.
• Зависимость от производителя и техподдержки. Используя ACI, пользователь полагается на Cisco в вопросах обновлений, исправления багов, расширения функционала. Например, если возникает нестандартная проблема глубоко внутри контроллера, без участия разработчиков Cisco ее решить сложно. Эта зависимость стала особым риском в условиях текущей геополитической обстановки. 

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

• Ограниченная открытость. Хотя Cisco заявляет поддержку открытых API и интеграций, сам экосистемный подход ACI может несколько «закрывать» сетевую инфраструктуру внутри себя. Сетевые устройства Cisco Nexus 9000 в режиме ACI управляются не напрямую, а только через APIC-контроллер — то есть теряется привычный доступ к конфигурации каждого свитча. Некоторые инженеры сетуют, что ACI «скрывает» от них детали работы сети, затрудняя низкоуровневый траблшутинг (хотя инструменты для диагностики в ACI есть, но они специфичны).

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

Далее рассмотрим, как ACI соотносится с другими подходами — и какие решения доступны на российском рынке.

Cisco ACI vs EVPN-VXLAN vs традиционные решения: сравнение подходов

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

1. Традиционная сеть L2/L3 без оверлеев (классический подход).
2. Модернизированная сеть на основе EVPN-VXLAN (без ACI, «открытая фабрика»).
3. Cisco ACI (SDN-фабрика с централизованным контроллером).

Рассмотрим их особенности.

Традиционная сеть дата-центра (классический L2/L3)

В традиционных решениях сеть строилась либо как большая L2-домена с VLAN по всему ЦОД (с помощью технологий вроде STP, MLAG, FabricPath/TRILL), либо как иерархия L3-маршрутизации с фиксированными границами подсетей. Оба варианта имели ограничения:

• Большие L2-домены с VLAN. Этот вариант удобен тем, что любой сервер можно переместить в любую точку, сохранив его VLAN/IP — сеть прозрачно доставит трафик (что важно для миграции виртуальных машин, кластеров и т. п.). Но L2 по всему ЦОД плохо масштабируется: протокол spanning tree отключает дублирующие связи, что мешает полностью использовать топологию; число VLAN ограничено (4096); широковещательный трафик (broadcast) от одного «болезненного» сервера может разрастись на весь ЦОД и вызвать проблемы. Администрирование безопасности на L2 уровне тоже сложнее — изоляция трафика основывается только на VLAN, и при разрастании инфраструктуры легко ошибиться с тегами.
• Жесткое разделение на L3 сегменты. Другой подход — разбить ЦОД на множество небольших L2-сегментов (например, каждый ряд стоек — своя подсеть), а связь между сегментами пустить через маршрутизацию (L3). Это устранит проблемы петель и широковещания глобально, но взамен пожертвуем гибкостью: если сервер переносится в другой сегмент, придется менять его IP-адрес или настраивать сложные схемы вроде L2TP/GRE туннелей, чтобы «протянуть» VLAN. В эпоху физически закрепленных серверов это было терпимо, но с появлением виртуализации, когда ВМ может перебежать на другой хост в другом сегменте, такой подход стал неудобен.

Кроме того, традиционные сети очень зависели от ручного управления. Настройки VLAN, маршрутов, списков доступа выполнялись инженерами на каждом коммутаторе/маршрутизаторе отдельно (или через простейшие шаблоны). Внести изменение сразу в десятки устройств без ошибок — сложная задача. 

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

Итог: традиционные L2/L3 сети подходят для небольших и средних ЦОДов или статичных конфигураций, но плохо справляются с динамикой облаков и большого количества сегментов. По мере роста нагрузок и требований к гибкости такие сети или усложнялись «костылями», или трансформировались в более современные фабрики.

EVPN-VXLAN фабрики (открытый стандарт)

Связка EVPN-VXLAN — это, по сути, ответ индустрии на потребности современных дата-центров. Она позволяет построить ту самую фабрику «spine-leaf» с L3-ядром, но при этом сохранить возможность предоставлять L2-сервисы поверх нее. Главное — это не продукт одного вендора, а набор протоколов, стандартизированных IETF, которые внедрили в свою продукцию почти все крупные производители сетевого оборудования. EVPN-VXLAN поддерживается коммутаторами Cisco (в классическом режиме NX-OS), Juniper, Arista, Huawei, Extreme и др.

Особенности EVPN-VXLAN подхода:

• Мультивендорность и открытость. Поскольку это общие стандарты, можно строить сеть из оборудования разных производителей, и они будут обмениваться данными о сетевых сегментах через BGP EVPN. Например, коммутаторы Juniper в роли Spine и коммутаторы Cisco в роли Leaf могут сосуществовать в одном fabric, обмениваясь маршрутами VXLAN — нужно лишь правильно настроить BGP-сессию между ними. Это дает гибкость в выборе железа и отсутствие жесткой привязки к одному вендору, но может повысить операционные расходы на персонал и дополнительное программное обеспечение.
• Отсутствие централизованного контроллера (по умолчанию). В EVPN-фабрике каждое сетевое устройство само играет роль «интеллекта» — они обмениваются информацией напрямую. Есть так называемый control-plane (BGP), который позволяет автоматически узнавать о новых устройствах, MAC-адресах, VLAN-ах и т. п. Это уже большое упрощение по сравнению с классическим L2 (где приходилось полагаться на flood-and-learn). Однако единого внешнего «мозга» нет — администратор все равно задает конфигурацию на каждом коммутаторе: например, какие VLAN (VNI) объявлять в EVPN, какие соседи BGP, какие политики фильтрации. То есть, по сути, EVPN-VXLAN — более «умная» ткань, но ее оркестрация все еще лежит на инженерах или на дополнительных системах автоматизации.
• Гибкость сети и масштабируемость. EVPN-VXLAN решает основные проблемы традиционных сетей: можно иметь до 16 млн виртуальных сетей (VNI) вместо 4096 VLAN, широковещание не выходит за пределы нужного сегмента (EVPN распространяет информацию более адресно), фабрика легко расширяется — добавили новый leaf-коммутатор, настроили несколько параметров BGP — и он вписался в общую систему, узнав от соседей все, что нужно. Легко объединять несколько ЦОДов через IP, создавая единое адресное пространство (решения Multi-Site). Все это доступно без проприетарных технологий, используя общедоступные протоколы.

Чтобы проиллюстрировать: EVPN-VXLAN можно воспринимать как «конструктор», из которого инженер может построить сеть под свои задачи. Возможности почти такие же, как у ACI (VXLAN-оверлей, сегментация, мультидатацентровость), но интеграция и управление — задача и ответственность сетевых инженеров. 

Кто-то использует скрипты и Ansible/Terraform для автоматизации настройки EVPN на сотнях коммутаторов, кто-то покупает у вендоров специальные системы управления (например, у Cisco есть Nexus Dashboard Fabric Controller для VXLAN-фабрик, у Juniper — Apstra, у Arista — CloudVision). Но принципиально можно обойтись и без контроллера, особенно на небольшом масштабе — коммутаторы сами «договариваются» друг с другом о необходимом.

ACI vs EVPN-VXLAN: Cisco ACI внутри себя тоже использует VXLAN,  но скрывает это от пользователя за слоями автоматизации.  Фактически ACI — частный случай EVPN-фабрики: там также есть маршрутизируемое ядро, VXLAN-инкапсуляция, а роль протокола распространения сведений выполняет внутренний механизм (в ранних версиях ACI это был протокол COOP + интеграция с MP-BGP для Multi-Site). 

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

Сравнение на практике

Чтобы понять, когда что лучше, можно привести аналогию и сравнение:

• Управление и автоматизация: Cisco ACI предоставляет «автопилот» — сеть сама настроится под заданные параметры. EVPN-VXLAN — это «ручное управление с круиз-контролем»: основные вещи (типа поддержания связности) делаются автоматически, но куда ехать и когда поворачивать — решает оператор. А традиционная сеть — это вообще «ручная коробка передач»: каждое действие требует участия человека. Поэтому, если у вас очень большая инфраструктура с частыми изменениями, ACI или хорошо продуманная автоматизация EVPN дадут выигрыш. Если инфраструктура небольшая и изменений мало, традиционный подход тоже работоспособен и может быть экономически выгоднее.
• Мультивендор vs единая экосистема. EVPN-VXLAN позволяет миксовать оборудование, например, использовать коммутаторы разных производителей для разных слоев. Это снижает зависимость от одного вендора и потенциально экономит бюджет (можно выбирать по лучшему соотношению цена/качество для каждой роли). ACI же — единая экосистема Cisco: плюс в том, что все гарантированно совместимо и протестировано вместе, но минус — привязка к решениям Cisco. В условиях, когда Cisco полностью поддерживает регион, это может быть приемлемо, но если возникают санкционные риски, EVPN-вариант с «дружественными» или отечественными вендорами гибче.
• Функциональность и интеграции. ACI имеет из коробки много интеграций (с гипервизорами, контейнерами, средствами мониторинга Cisco, фаерволами Cisco и т. п.). В открытом подходе вам, например, придется отдельно настраивать интеграцию сети с VMware (через функции типа EVPN VXLAN Gateway, NSX или аналогичные). То есть ACI — решение «all-in-one» для ЦОДа, а EVPN — «сделай сам», где при необходимости добавляются сторонние компоненты. Традиционная сеть, конечно, еще менее приспособлена к таким интеграциям — там зачастую вообще виртуализация сети решается на уровне гипервизора (vSwitch в каждом сервере), а физическая сеть просто прозрачно переносит VLANы.
• Отладка и прозрачность. В ACI администратор оперирует высокоуровневыми объектами, и иногда трудно сразу понять, где произошел сбой (например, почему два сервера не пингуются — из-за контракта безопасности или проблемы в физическом соединении?). Приходится разбираться через интерфейс ACI, смотреть логи контроллера. В EVPN/VXLAN инженер чаще сам знает схему и может зайти на конкретный коммутатор и увидеть, что, скажем, не пришел маршрут в таблицу BGP. В традиционной сети ситуация понятнее, но там и возможностей меньше (чаще всего это либо проблема физики, либо неправильно настроенный VLAN/ACL вручную). 

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

Обобщая, Cisco ACI можно рассматривать как следующий этап развития инфраструктуры ЦОД после EVPN/VXLAN фабрики — шаг в сторону удобства и централизации, сделанный одним вендором. 

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

Различия — в способе управления и экосистеме. Традиционные L2/L3 сети сегодня скорее уступают им, когда речь про крупные и динамичные ЦОДы, но могут сосуществовать в маленьких дата-центрах или изолированных зонах, где требования проще.