Коммутаторы Cisco Nexus появились на рынке достаточно давно. Данное семейство коммутаторов позиционируется в первую очередь для установки в ЦОДах. Однако последнее время сам вендор стал активно предлагать коммутаторы Nexus для установки в корпоративную сеть в качестве ядра сети. И тут сразу возникает вопрос, а подойдёт ли для такой задачи Nexus? Понятно, раз предлагают, значит подойдёт. Но давайте на этом чуточку заострим наше внимание.
Не́ксус (лат. nexus — «связь, сцепление») — имеет множество значений в разных областях, но в общем случае обозначает центральную часть какой-либо сущности, центр сцепления каких-нибудь связей.
Анонс одного из первых коммутаторов данного семейства Cisco Nexus 7000 произошёл в 2008 году. Однако долгое время они позиционировались и на бумаге, и в умах в первую очередь для построения сети ЦОДа. Время шло, и из статуса диковинного устройства данные коммутаторы потихоньку стали превращаться в более обыденные. Семейство коммутаторов за это время сильно расширилось. Более того, оно стало даже чуточку избыточным. Не всегда на 100% стало понятно, какой именно Nexus стоит использовать. На сегодняшний день представлены коммутаторы с фиксированной конфигурацией (Nexus 3000, 5000, 6001, 9300) и модульные (Nexus 6004, 7000, 9500), коммутаторы для установки в блейд-корзину (Nexus 4000, B22). Также есть специализированные коммутаторы – расширители фабрики (Fabric Extenders), это Nexus 2000 и B22. Даже есть виртуальный коммутатор Nexus 1000V (хотя слово «даже» не очень уместно, так как облака – это наше всё). Продолжать классификацию можно ещё долго, однако наша задача не в этом.
Давайте посмотрим, чем же именно семейство коммутаторов Nexus отличаются от самых обычных коммутаторов семейства Catalyst. Так как вопрос достаточно объёмный, рассмотрим его укрупнёнными мазками. Коммутаторы Nexus в первую очередь рассчитаны на работу в ЦОДах, где необходимо обеспечивать непрерывную «прокачку» большого количества трафика зачастую с минимальными задержками. Отсюда вытекают архитектурные особенности коммутаторов Nexus.
«Прокачка» большого количества трафика обеспечивается наличием разнообразных портов в том числе на скорости до 100 Гбит/с, а также производительностью внутренней фабрики. Стоит отметить, что нет единой архитектуры коммутаторов. Различные модели Nexus строятся на основе различных архитектур. Есть варианты построения на базе только Crossbar-фабрики (такая фабрика предполагает наличие большого количества путей между элементами коммутатора – ASIC’ами). Есть варианты реализации архитектуры Switch on Chip – SoC (когда вся логика заключена внутри чипа ASIC, а передача пакета между портами идёт через общую память внутри чипа). Также есть комбинированные варианты — Crossbar-фабрика вместе с SoC. Во всех случаях производительность коммутаторов Nexus достаточна для передачи больших объёмов сетевого трафика.
Минимизация задержек в коммутаторах Nexus обеспечивается за счёт архитектурных особенностей. В частности, большинство коммутаторов Nexus обеспечивают режим коммутации пакетов Cut-through. Как мы помним, коммутаторы семейства Catalyst работают в режиме Store-and-forward. В режиме Store-and-forward коммутатор начинает передачу пакета только после того, как он его весь получил. В режиме Cut-through передача пакета происходит после получения первых 64 байт. А значит, в режиме Cut-through задержка пакета в коммутаторе всегда постоянная и не зависит от его длины. Также в борьбе с минимизацией задержек при передаче пакетов внутри коммутатора участвуют различные схемы работы внутренней фабрики (superframing, очереди на входе и пр.). Например, Superframing обеспечивает склеивание пакетов друг с другом при их передаче через внутреннюю фабрику, что позволяет эффективно расходовать пропускную способность данной фабрики. Для примера, задержки в коммутаторах Catalyst 3850 достигают 50 мкс (зависит от размера пакета). При этом задержка в коммутаторе Nexus 3548 в специальном режиме составляет всего 190 нс. Для остальных коммутаторов Nexus – 1-2 мкс.
За непрерывность «прокачки» трафика отвечают разнообразные архитектурные особенности как железа, так и программного обеспечения. С точки зрения железа – это дублирование различных блоков в устройстве (избыточные вентиляторы, несколько блоков питания, фабрик и пр.). Также присутствуют различные схемы контроля и мониторинга компонент коммутатора (Connectivity Management Processor и пр.), которые позволяют заметить проблемы на самом раннем этапе. С точки зрения программного обеспечения имеем специализированную операционную систему NX-OS и букет различных функций. NX-OS в отличии от привычного IOS является модульной программной архитектурой. Каждая функция выполняется как отдельный процесс. А значит, если у нас проблема, например, с OSPF, мы можем перегрузить только процесс OSPF. Трогать всю систему не придётся. На коммутаторах Nexus поддерживаются различные функции, которые позволяют нам получить высокий уровень отказоустойчивости. Например, поддержка протоколов обеспечения резервирования шлюза по умолчанию (First Hop Redundancy Protocols), динамической маршрутизации вместе с Nonstop Forwarding, протоколы STP и прочее. Так же есть присущая только Nexus функциональность, например, создание виртуальных агрегированных каналов Virtual Port Channel (vPC).
В дополнение к указанным выше особенностям коммутаторов Nexus стоит добавить, что они поддерживают достаточно широкий спектр функций, специфичных именно для этого семейства. По большому счёту все эти функции продиктованы областью применения Nexus – в качестве коммутаторов ЦОДа. К таким функциям относятся и обеспечение конвергентного доступа (поддержка протокола FCoE), и виртуализация коммутатора (Virtual device contexts – VDC: физический коммутатор мы можем разделить на несколько виртуальных), и поддержка оверлейных технологий (например, FabricPath), а также программно-определяемых сетей (Application Centric Infrastructure – ACI) и т.д.
Думаю, уже стало понятно, почему коммутаторы Nexus устанавливаются в ЦОДах. Давайте попробуем сфокусироваться всё-таки на изначальном вопросе, а именно: можно ли поставить Nexus вместо Catalyst в ядро обычной корпоративной сети? На текущий момент мы не выявили никаких противопоказаний. Наоборот, отметили, что коммутаторы Nexus обладают различными положительными характеристиками, хотя и необходимыми в первую очередь в ЦОДах. Посмотрим теперь на те аспекты, которые необходимы нам от устройства при работе в корпоративной сети.
Первый вопрос, который волнует: а что там с командной строкой? Не придётся переучиваться? В целом, ответ: нет, не придётся. Командные строки достаточно похожи. Есть особенности, но они не фатальные. Например, при настройке различных функций их необходимо изначально активировать с помощью команды «feature». Порты независимо от типа называются Ethernet. Синтаксис большинства стандартных команд практически идентичен.
Второй вопрос, какие порты я могу получить? Тут широкая линейка Nexus’ов нас ничем не ограничивает. Доступны варианты с портами 1, 10, 40 и 100 Гбит/с. Много вариантов устройств с различным количеством портов. Отдельно стоит упомянуть, что коммутаторы Nexus поддерживают подключение к себе расширителей (Fabric Extender). Это как линейная карта в модульном коммутаторе, только выполненная в виде отдельного устройства. Сам по себе Fabric Extender не реализует никакой логики. Весь трафик всегда передаётся на родительское устройство (полноценный коммутатор Nexus). Благодаря Fabric Extender’ам можно получить большой логический коммутатор с различными портами. А так как Fabric Extender – это отдельное устройство, установить его мы можем как можно ближе к подключаемому к нему оборудованию, что обеспечивает определённые удобства при построении сети. Кстати, аналогичное решение в мире Catalyst – Instant Access. Правда в мире Nexus вендор пошёл дальше, предоставив возможность «дотянуть» порт коммутатора непосредственно в виртуальную машину. Т.е. создаётся иллюзия, что каждая виртуальная машина подключена напрямую в железный коммутатор Nexus.
А что со стандартным функционалом на коммутаторах Nexus?
Если мы посмотрим на L2-функции, то найдём всё, что нам необходимо: виртуальные сети (VLAN, Private VLAN), поддержку протоколов предотвращения петель STP, а также различные «гарды» (Root Guard, BPDU Guard и пр.), агрегацию портов Port Channel и т.д.
Что касается L3-функций, ситуация аналогичная: поддержка статической и динамической маршрутизации (EIGRP, OSPF, BGP, ISIS), маршрутизации на основе политик (PBR), поддержка протоколов резервирования шлюза по умолчанию (HSRP, VRRP, GLBP), GRE-туннелей и т.д. Поддерживаются протоколы для работы с multicast-трафиков: IGMP и PIM.
С точки зрения функций безопасности также имеем стандартный набор: списки доступа ACL (IP, MAC, VLAN), ограничение доступа на уровне порта (Port Security), различные функции борьбы с подменами адресов (DHCP snooping, Dynamic ARP inspection, IP source guard). Присутствуют механизмы борьбы с широковещательными штормами (Storm Control) и защиты уровня управления (Control Plane Policing).
Для обеспечения мониторинга и управления всё необходимое присутствует: SNMP, NTP, Netflow, различные реализации SPAN, Embedded Event Manager и другое. Более того в отличие от коммутаторов Catalyst на Nexus поддерживается возможность управления через протокол сетевого управления NETCONF, а также запуска скриптов на базе Python.
Помимо всего перечисленного коммутаторы Nexus, как я уже отметил ранее, поддерживают достаточно большой спектр и других различных технологий, правда, менее востребованных в корпоративных сетях: MPLS, LISP, VXLAN, OTV и пр.
Вроде как, отметил основные моменты. Хотя нет, упустил часть, касающуюся качества обслуживания QoS. Функциональность QoS зависит от платформы и типа линейных карт. Безусловно, коммутаторы Nexus имеют свои особенности: очереди на входе, поддержка различных протоколов управления потоками, согласования параметров обслуживания трафика и динамического управления полосой (802.1Qbb и 802.1Qaz). Однако в целом настройка политик схожа с настройками для коммутаторов Catalyst. Используется привычная схема Modular QoS CLI. Основные отличия: QoS включён по умолчанию и все порты доверяют значениям QoS в пакетах (CoS, DSCP). Ещё один момент: в большинстве коммутаторов Nexus приоритетная очередь (priority queuing) ничем не ограничена, а значит может утилизировать всю полосу пропускания (для остальных очередей возможна ситуация «голодания» — starvation).
Думаю, стоит упомянуть, чего нет в коммутаторах Nexus. На них не поддерживается стекирование в любом виде. Хотя это совсем и не проблема. Для обеспечения подключения устройств в отказоустойчивом варианте к двум разным коммутаторам Nexus используется технология Virtual Port Channel (vPC). Она позволяет агрегировать несколько физических интерфейсов в один логический. При этом коммутаторы Nexus, куда приходит агрегированный канал, продолжают работать независимо друг от друга. Между собой они лишь синхронизируют параметры и состояние агрегированного канала vPC.
В модульные коммутаторы Nexus нет возможности ставить сервисные модули, как это можно делать в коммутаторах Catalyst 6500/6800 (например, модуль межсетевого экранирования ASA-SM, модуль анализатора трафика NAM, контроллер беспроводной сети WiSM и пр.). Также на коммутаторах Nexus нет функции передачи питания по Ethernet (Power over Ethernet), собственно это и логично.
Давайте подведём итог. С точки зрения управления, проблем возникнуть не должно. Консоль NX-OS очень похожа на консоль IOS. С выбором устройства также трудностей не будет. Семейство коммутаторов очень многообразно. Поддерживается необходимый стандартный функционал для работы коммутатора в корпоративной сети в качестве её ядра. А значит, можем подключать к коммутатору Nexus более привычные коммутаторы Catalyst (или коммутаторы других производителей). Таким образом смело отвечаем на поставленный в начале статьи вопрос: в большинстве случаев коммутатор Nexus можно без проблем установить в корпоративную сеть в качестве ядра сети. Его функциональности для большинства задач хватит.
Заметим, коммутаторы Nexus всё-таки в первую очередь позиционируются для ЦОДов. И они, конечно же, не являются полноценной заменой коммутаторов Catalyst. В большинстве случаев мы их можем использовать в корпоративной сети. Но не всегда. Следует тщательно смотреть на требования к сети.
В заключение коснёмся ценового аспекта. Он остался за кадром. Понятное дело, цена очень важный фактор, на который зачастую смотрят в первую очередь. Конечно же, при сравнении коммутаторов Nexus с другими семействами можно сразу отметить, что близость стоимости решений достигается только для коммутаторов с портами 10 Гбит/с. Не стоит думать, что коммутаторы Nexus будут конкуренты с обычными коммутаторами с портами 1 Гбит/с. Для семейства коммутаторов Nexus стандартными портами являются именно порты 10 Гбит/с. Обязательно нужно считать полную стоимость коммутатора: стоимость железа и лицензий, так как зачастую лицензии дают очень приличное увеличение цены. Но при всём при этом, ценовая политика вендора в разрезе коммутаторов Nexus иногда приятно удивляет, что и заставляет нас задумываться о поставленном в начале вопросе.
Автор: CBS
