Cisco Nexus в ядрі корпоративної мережі



Комутатори Cisco Nexus з'явилися на ринку досить давно. Дане сімейство комутаторів позиціонується в першу чергу для установки в ЦОДах. Однак останнім часом сам вендор став активно пропонувати комутатори Nexus для установки в корпоративну мережу в якості ядра мережі. І тут відразу виникає питання, а чи підійде для такої задачі 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 Ship – 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 – як комутаторів Цод. До таких функцій належать забезпечення конвергентного доступу (підтримка протоколу Fco), і віртуалізація комутатора (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.1 Qbb і 802.1 Qaz). Проте в цілому налаштування політик схожа з налаштуваннями для комутаторів 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 іноді приємно дивує, що і змушує нас замислюватися про поставленому на початку питанні.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.