Диалектика виртуальных сетей – Cisco ACI vs Vmware NSX

В нашей статье мы будем называть виртуальными (по аналогии с виртуализацией серверов) сети, соответствующие следующим требованиям:

• Общее множество ресурсов, единая точка управления. Это ключевая особенность SDN. Узел сети получает сервисы независимо от своего физического и логического размещения, а точка управления всей инфраструктурой одна и не меняется во время эксплуатации.
• Быстрое выделение ресурсов. Когда компании нужно развернуть новый сервис или приложение, выделение ресурсов под него должно происходить быстро, при этом не влияя на остальные сервисы.
• Узкая сегментация и изоляция приложений. Приложения должны быть изолированы друг от друга, даже если они работают на одном физическом CPU (на одном процессоре одного сервера). Разные компоненты приложения в соответствии с политикой безопасности должны иметь возможность взаимодействовать исключительно так, как задумано администратором.
• Гибкость в адресации и топологии сети. Новые приложения могут располагаться в любом месте ЦОДа, компонентам на разных площадках, в том числе, может потребоваться размещение в одной подсети. Сеть не должна ограничивать приложения в гибкости.

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

2 лидера – немного истории

Историю виртуализации сетей принято отсчитывать с 2006 года, когда Мартин Касадо, будучи аспирантом Стэнфордского университета, представил проект Ethane. Его основная идея: сетевые устройства должны осуществлять только передачу данных (data plane), а управление передачей данных (control plane) выполняет централизованный контроллер.

В 2007 году Мартин Касадо, Ник МакКьоун и Скотт Шенкер создали компанию Nicira и начали разработку платформы сетевой виртуализации (Network Virtualization Platform, NVP). Продукт работает на основе OVS (Open vSwitch) и стандарта OpenFlow, в настоящий момент носит название NSX MH (NSX Multi-Hypervisor).

В 2011 году была основана некоммерческая организация Open Network Foundation. Основателями проекта выступили гиганты ИТ-рынка – Google, Microsoft, Verizon, Yahoo!, Facebook, Deutsche Telecom. Цели организации – развитие программно-определяемых сетей. Фактически она развивает стандарт OpenFlow, ранние версии которого очень напоминали работы Мартина Касадо образца 2006–2007 годов, являясь по сути стандартом на основе концепций Ethane.

В 2012 году VMware приобрела Nicira за 1,26 млрд долларов. Обычно сделки такого масштаба осуществляются за счет передачи ценных бумаг/обязательств, но в данном случае VMware оплатила покупку живыми долларами. Было объявлено, что платформа сетевой виртуализации Nicira отныне будет называться VMware NSX.

Компания Cisco, наблюдая за трендами виртуализации и программируемости сетей, решила их возглавить. Сони Джандани перешла из Cisco в стартап Insieme Networks. Его основателями выступили три бывших сотрудника Cisco Марио Маццола, Прем Джейн и Лука Кафьеро, одним из основных инвесторов стала сама Cisco Systems. Cisco окончательно приобрела Insieme в ноябре 2013 года. Результатом работы стартапа стала ACI (Application Centric Infrastructure) – инфраструктура, ориентированная на приложения. Название очень точно описывает суть решения, но об этом позже. Аналогичным образом в свое время появились Fibre Channel коммутаторы MDS, серверные решения Cisco UCS, коммутаторы Cisco Nexus.

Есть еще варианты?

Стоит отметить и другие решения по виртуализации сетей.

Arista одной из первых начала продвигать SDN-решения, сейчас их продукт позволяет хорошо автоматизировать сеть, интегрируется с различными гипервизорами и оркестраторами. Автоматизацию сети функционально дополняет интеграция с VMware NSX.

HP предлагает OpenFlow SDN-контроллер. Главное узкое место OpenFlow контроллеров – крайне скудный функционал «из коробки», функции наращиваются путем установки приложений. И в HP создали магазин приложений по аналогии с Android Market и Apple App Store. Другой вопрос – малый размер таблиц под Flow записи на стандартных микросхемах коммутации – сняли с помощью подхода «SDN только до распределения». Пока приложений не так много, поэтому магазин не пользуется большой популярностью.

Juniper Networks, когда речь заходит о виртуальных сетях, предлагает аппаратные шлюзы для VMware NSX.

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

Стоит отметить Cumulus, которая предлагает операционную систему для установки на White/Brite Box коммутаторы (без поддержки/с поддержкой производителя). Она может быть интересна тем компаниям, у которых вся инфраструктура на Linux, много специалистов по этой ОС и довольно большая сеть.

Также внимания заслуживает Pluribus Networks, которая делает коммутаторы путем подключения специализированных микросхем к серверам. В итоге аппаратный коммутатор может сохранять/обрабатывать сетевой трафик приложений и имеет очень большой задел по программируемости и мониторингу приложений на сетевых устройствах.

VMware NSX

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

Со стороны сетевого оборудования виртуальная сеть выглядит как множество VXLAN-туннелей между серверами. То есть от сетевого оборудования требуется только обеспечить хорошую пропускную способность, не нужны даже большие CAM-таблицы и поддержка multicast.

Опустим описания концепции и подхода – их много в пресс-релизах вендора. Остановимся на предоставляемом функционале. NSX позволяет объединять виртуальные машины в одну виртуальную подсеть, даже если серверы, на которых эти машины расположены, находятся в разных подсетях. Это обеспечивается штатным функционалом VXLAN. В том числе можно объединить несколько площадок в единую сеть, если они находятся на небольшом расстоянии (до 50–100 км), в ином случае могут потребоваться другие технологии.

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

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

Для подключения виртуальной сети к остальной физической сети можно использовать аппаратные (от классических производителей) или виртуальные шлюзы. Штатный виртуальный шлюз, помимо подключения к внешним сетям, обеспечивает следующий функционал: NAT, DHCP, VPN, маршрутизацию с поддержкой OSPF. Также он выполняет функции межсетевого экрана, балансировщика нагрузки, обладает отказоустойчивостью.

Управляется NSX либо автоматизированно через оркестратор, либо администратором через графический интерфейс vSphere (так же, как и остальная виртуальная инфраструктура VMware). Управление NSX осуществляется из отдельного раздела, доступ к которому можно дать как сетевым, так и инфраструктурным администраторам.

Поскольку сетевые сервисы выполняются на серверах распределенно, возникает вопрос, насколько «железо» загружается от этой дополнительной задачи. VMware заявляет, что дополнительная нагрузка на гипервизор не превышает 6%.

Кратко перечислим возможности и роли NSX:

• возможность полностью менять топологию сети и сервисы, в том числе подключать новые сегменты без влияния на уже существующие из одной точки и быстро;
• распределенный маршрутизатор/коммутатор на всех серверах с виртуальными машинами;
• распределенный (меж-) сетевой экран;
• шлюз NSX с сетевыми сервисами;
• VXLAN Overlay: топология виртуальной сети не зависит от топологии сети физической.

ACI от Cisco

Сегодня, по данным мировых аналитических агентств, около 80% вычислительной нагрузки виртуализовано, в то же время 80% компаний по-прежнему имеют серверы без виртуализации (обычно в дополнение к виртуализованным). 42% компаний используют более одного гипервизора – не только VMware ESXi, но и другие. NSX же решает задачи только для фермы серверов VMware.

Cisco стремится занять свободную нишу с помощью ACI. Решение состоит из коммутаторов серии Nexus 9000 и аппаратных контроллеров на базе серверов Cisco UCS. Коммутаторы могут работать либо в стационарном режиме NX-OS так же, как и остальные коммутаторы Nexus, либо в режиме ACI – под управлением контроллера. Nexus 9000 обладают большой плотностью портов, хорошей производительностью, но в режиме NX-OS функционал у них не так обширен. В режиме фабрики (ACI) контроллер оперирует понятиями приложения. На рис. 2 изображено типичное 3-уровневое приложение.

Администратор указывает, какие серверы или виртуальные машины относятся к той или иной группе серверов, и как эти группы должны взаимодействовать. Остальное – забота контроллера, который динамически перенастраивает все оборудование. Таким образом, трафик динамически перенаправляется на межсетевые экраны и балансировщики нагрузки. Сетевые сервисы можно реализовать на оборудовании стороннего производителя, если он выпустил профайл, согласно которому APIC понимает возможности этого «железа». Многие крупные производители (например, Check Point, F5) уже выпустили такие профайлы. Контроллер перенастраивает сеть при миграции виртуальных машин, удаляя правила там, где они больше не нужны.

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

Физически всегда используется 2-уровневая архитектура (Spine-Leaf), причем Spine- и Leaf-коммутаторы отличаются на аппаратном уровне. Аппаратные особенности позволяют контроллеру получать такую информацию, как количество переданных пакетов между двумя группами серверов, задержек на передачу и потерь по каждому из путей внутри фабрики и между группами серверов в целом. Также они гарантируют решение проблем out of order delivery и пр. В том числе на основе этой информации строится система оценок в диапазоне от 0 до 100. Оценка выдается как приложению в целом, так и отдельным группам соединений, коммутаторам и т.д. Другой вопрос, насколько она полезна, если на нее в том числе влияет количество свободных портов на уровне доступа.

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

Сравнение и выводы

Если говорить о технических возможностях, NSX хорош там, где все или абсолютное большинство серверов виртуализованы с помощью VMware. ACI в принципе работает только там, где сеть в ЦОД построена на коммутаторах Nexus 9k, зато к ACI напрямую подключаются как виртуальные машины (VMware ESXi), так и физические серверы.

NSX – это виртуальная сеть до виртуальной машины. А машины должны быть обязательно виртуализованы с помощью технологий VMware. Cisco в общем случае предоставляет сеть до подключаемых серверов, но политики фабрики можно «растянуть» до виртуальных машин с помощью установки виртуального коммутатора AVS, аналога Nexus1000 для ACI. AVS официально поддерживается только под VMware ESXi (на март 2015), но ходят слухи, что существуют AVS для Hyper-V. Отметим, что AVS под VMware не поддерживается самой VMware, поэтому есть риск «застрять» между поддержками двух вендоров в случае инцидента.

NSX – «размазанная» сеть, проблема сайзинга во многом решается автоматически: вынос части виртуальных машин на новые серверы означает и вынос нагрузки на обработку трафика, поскольку внутри NSX трафик обрабатывается локально. ACI компенсирует локальную обработку на большие и «толстые» каналы, внутри фабрики множество 40Gb/s каналов , чтобы заворачивать трафик на нужные сервисы. Зато у компании-заказчика всегда есть выбор. Например, функционала встроенного в NSX балансировщика нагрузки многим будет недостаточно. Использовать сторонние решения VMware позволяет, но так же, как это происходит в классических сетях. NSX такую балансировку автоматизировать и упрощать не будет.

Что касается автоматизации за счет оркестратора, Cisco ACI «из коробки» интегрируется с Cisco UCS Director, VMware NSX – с VMware vCAC (vCloud Automation Center). Обе компании активно участвуют в проектах свободных оркестраторов и заявляют интеграцию с OpenStack.

Что касается DCI, NSX позволяет объединять в единую виртуальную сеть несколько площадок в рамках города или соседних городов, на больших расстояниях нужны специализированные технологии уменьшения задержек для приложений. Отметим, что связь удаленных площадок через NSX предпочтительнее, чем без него, даже если VXLAN не требуется. NSX имеет встроенные механизмы уменьшения BUM трафика, ARP запросов и т.д. ACI-фабрику же можно разнести на несколько помещений в рамках одного здания, между которыми будет множество 40 Гб каналов. У Cisco есть очень хорошая технология обеспечения связности удаленных площадок – OTV. Но устройства, которые поддерживают ACI, не поддерживают OTV, и наоборот. В настоящее время есть рекомендованный дизайн связи нескольких фабрик ACI с помощью OTV (он не будет частью ACI), в дальнейшем планируется управление OTV-каналом с помощью ACI контроллера APIC.

В заключение стоит сказать, что финансовые аналитики из Goldman Sachs в отчете для инвесторов провели наглядную аналогию между подходами ACI и NSX – iPhone vs Android. ACI, как и iPhone, имеет вертикальную интеграцию, собственные микросхемы, аппаратную и программную часть. Как и Apple, Cisco сохраняет полный контроль над своей экосистемой. VMware NSX, как Android, работает на разных аппаратных платформах, может использоваться разными способами, например, в качестве межсетевого экрана или для DCI. Производитель не заставляет пользователя следовать жестко заданной архитектуре. Аналитики считают, что в этом противостоянии победителя не будет – обе компании, решающие одну задачу разными способами, займут свою часть рынка.