Cisco Nexus 9300 для ЦОД: выбор карт, оптики и проверок

С чего начать выбор: требования ЦОД простыми словами

Выбор Cisco Nexus 9300 для ЦОД лучше начинать не с каталога модулей, а с понимания реального трафика. В большинстве ЦОД основные «пожиратели» полосы - хранилища (особенно на пиках), виртуализация и резервное копирование. Сразу определите, где для вас критична минимальная задержка, а где важнее предсказуемость без потерь. Под разные профили трафика по-разному проявляются вопросы FEC, CRC и буферов.

Дальше посчитайте порты простыми блоками: сколько серверных подключений нужно на 25GbE и сколько аплинков требуется на 100GbE. Не пытайтесь угадать «на 5 лет вперед», но заложите понятный запас под рост стоек и миграции. Частая ошибка на старте - взять много 25GbE, а на аплинках сэкономить и потом упереться в перегрузки именно «вверх» по фабрике.

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

Отдельно выпишите бизнес-требования, которые действительно важны: допустимые потери, максимальная задержка для ключевых сервисов и нужный уровень отказоустойчивости (двойные аплинки, резервные пути, быстрые перезапуски). Не все приложения одинаково чувствительны - и это нормально.

До закупки полезно решить «на бумаге» базовые вещи: портовую емкость (сколько 25GbE на стойку и сколько 100GbE между уровнями), дистанции и среду (медь/оптика, тип волокна и реальные длины трасс), SLO по качеству (что недопустимо: потери, рост задержки, простои) и сценарии роста на ближайшие 12-18 месяцев. А тонкие настройки (какой FEC включать, где появятся CRC, хватит ли буферов на микровсплесках) лучше подтверждать пилотом на ваших потоках, а не по чужим схемам.

Если нет времени собирать методику тестов с нуля, системный интегратор может помочь формализовать требования и провести пилот так, чтобы выводы потом легли в закупку и масштабирование. В Казахстане такие работы часто берут на себя команды уровня GSE.kz - как раз в части проектирования, пилота и дальнейшей поддержки инфраструктуры.

Линейные карты и порты: как выбрать конфигурацию под 25/100GbE

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

Планируя 25GbE, считайте не только количество серверов, но и то, какие 100GbE аплинки вы хотите на leaf (ToR). Типовая логика такая: серверы садятся на 25G, uplink к spine делают 100G. Дальше включается математика: сколько 25G портов реально останется, если часть портов нужна под аплинки, под MLAG или под отдельные сервисные подключения. Часто команда видит красивую цифру «48 портов 25G», а потом выясняется, что после аплинков и резервирования остается заметно меньше.

В характеристиках смотрите не только «скорости портов», а и то, что влияет на поведение под нагрузкой и на удобство масштабирования: соотношение downlink/uplink, поддержку breakout и то, как ваш портовый план сочетается с топологией.

Oversubscription и реальные аплинки

Oversubscription - это соотношение суммарной скорости вниз (к серверам) к суммарной скорости вверх (к spine). Если вы подключили много 25G серверов, но дали мало 100G аплинков, полосы может не хватать на пиках. Это не всегда плохо: для VDI или офисных нагрузок допустимо большее уплотнение, а для хранилища или интенсивной east-west нагрузки лучше держать запас.

Breakout и смешанные скорости

Breakout полезен, когда один 100G порт можно разложить на несколько более медленных линий (например, чтобы временно подключить устройства на меньшей скорости или аккуратно нарастить порты). Но он влияет на план портов, кабели и на то, какие скорости поддерживаются одновременно. Заранее решите, будет ли у вас чистый профиль «25G к серверам и 100G вверх», или нужна смесь скоростей.

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

Чтобы заложить рост и не переплатить, удобно зафиксировать минимум, который нужен «в день запуска», и разумный запас на 12-18 месяцев. Для этого обычно достаточно ответить на несколько вопросов: сколько 25G портов нужно под серверы сейчас и после ближайшего расширения; сколько 100G аплинков нужно на каждый leaf с учетом допустимого oversubscription; нужен ли breakout и какие скорости должны поддерживаться без замены кабельной части; сколько портов уйдет на резервирование, межкоммутаторные связи и отдельные сети (например, management); совпадают ли выбранные роли портов с вашей топологией и планом миграции.

Если вы внедряете ЦОД под требования госорганизаций или крупного бизнеса, портовый план лучше согласовать заранее с теми, кто будет отвечать за схему и пилот. В проектах, которые ведет GSE.kz, старт обычно как раз с этой «портовой математики», а уже потом подбирают оптику, режимы FEC и сценарии проверок на стенде.

Оптика и кабели: что обычно берут для 25GbE и 100GbE

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

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

Внутри одного зала, когда расстояние уже больше и есть патч-панели, типичный выбор - SR на многомоде. Для 25GbE это чаще SFP28 SR, для 100GbE - QSFP28 SR4. Заранее проверьте тип коннектора (LC или MPO) и реальную схему кросса, чтобы не оказалось, что оптика есть, а шнуров нужного типа нет.

Если линия длиннее (другой зал, другой этаж, магистраль по зданию), обычно берут LR на одномоде. Тут важно уточнить две вещи: запас по бюджету мощности (чтобы не жить «на грани») и требования к трассе (качество сварок, количество соединений). На пилоте полезно фиксировать фактические уровни Rx/Tx, а не только факт «линк поднялся».

Отдельная тема - breakout 100G в 4x25G. Он часто упрощает схему, когда нужно подключить несколько 25GbE устройств к одному 100G порту на агрегации. Но риски растут, если в проекте смешиваются разные типы breakout (DAC, AOC, оптика), нет единого стандарта по длинам и маркировке, часть портов планируют потом перевести обратно в 100G, а в шкафу тесно и легко перепутать «ветки» 4x25G.

Чтобы пилот не превратился в угадайку, помогает простая дисциплина учета. Достаточно договориться о минимальном наборе полей и придерживаться его: тип (DAC/AOC/SR/LR), скорость (25G/100G) и форм-фактор (SFP28/QSFP28); длина и место установки (стойка, юнит, порт); серийный номер модуля или кабеля; тип волокна и коннектор (MM/SM, LC/MPO); статус «проверено на пилоте» с датой.

Если интегратор ведет поставку и внедрение, попросите сразу оформить это в виде таблицы для пилота. Потом она сильно экономит время при поиске несовместимости и замене модулей.

Совместимость оптики: как избежать сюрпризов

Даже если на коробке написано 25GbE или 100GbE, это не значит, что модуль будет одинаково хорошо работать в любом порту. У модулей бывает разная оптическая мощность, чувствительность, требования к FEC, плюс банальные отличия в прошивках и кодах совместимости. Поэтому для Cisco Nexus 9300 для ЦОД важно заранее договориться, что именно вы считаете совместимой оптикой: не просто «линк поднялся», а «линк стабилен под нагрузкой».

Самый частый сценарий сюрпризов выглядит так: линк поднимается, трафик идет, но при росте нагрузки начинают расти CRC, интерфейс периодически флапает, а на 100G неожиданно появляются большие FEC-коррекции. В итоге приложение видит задержки и ретраи, а команда сети ищет причину между коммутатором, модулем, патчкордом и панелью.

Матрица совместимости

Полезно завести простую матрицу совместимости и вести ее как документ пилота. Она нужна не для бюрократии, а чтобы повторить удачную комбинацию в закупке и не смешать разные партии.

Обычно достаточно зафиксировать модель коммутатора и тип порта (25G, 100G, breakout, скорость, автосогласование), точный артикул и ревизию модуля (включая vendor part number и версию), тип линии и длину (SR/LR/CR, OM3/OM4, SMF, DAC/AOC, метры), схему кросса (патчкорд, панель, количество соединений) и требования к настройкам (FEC on/off, speed, lane configuration).

Отдельно обсудите тестовые партии: лучше взять небольшое количество модулей и кабелей разных типов (например, SR и DAC для коротких линий, LR для межрядовых) и прогнать их на ваших реальных трассах. С интегратором это проще: он может собрать «набор для пилота» и помочь не смешать несовместимые варианты в одной поставке.

Как оценивать результат

Результат лучше описывать не словами «вроде работает», а понятными порогами. Проверяйте не только ошибки, но и температуру, и поведение на длительном прогоне.

Здоровая картина обычно выглядит так: линк не флапает в течение длительного теста (часы, лучше сутки) под реальной нагрузкой; счетчики CRC и input errors не растут (или растут только при намеренных тестах отказа); FEC не показывает аномально высокий уровень коррекций по сравнению с эталонной линией; температура модуля держится в норме для вашей стойки и не «ползет» вверх со временем; после перетыка и перезагрузки поведение повторяемо, без «магии» и разовых успехов.

Если хоть один пункт вызывает вопросы, не спешите списывать это на «особенности линии». Часто дешевле заменить конкретный тип модуля или кабеля в пилоте, чем потом ловить редкие CRC в продуктиве.

FEC для 25/100GbE: когда включать и как не ошибиться

FEC (Forward Error Correction) - это «подстраховка» на линии: к данным добавляется служебная информация, чтобы приемник мог исправлять часть ошибок без повторной передачи. На 25/100GbE это особенно важно: скорость выше, сигнал чувствительнее к шумам, качеству кабеля и оптики.

Практическое правило простое: FEC должен совпадать на обоих концах. Если на коммутаторе включен один режим, а на другом конце (второй коммутатор, серверная NIC, DWDM-оборудование) другой, линк может не подняться или будет «подниматься, но с ошибками».

Типовые режимы и почему «Auto» не всегда спасает

Чаще всего встречаются варианты: FEC выключен, FC-FEC и RS-FEC. У разных платформ и модулей допустимый набор режимов отличается.

В практике удобно опираться на такие ориентиры:

• Если используете новые 100G модули на PAM4 (когда 100G идет по одной-двум парам), FEC обычно обязателен.
• Для классических 100G на QSFP28 (NRZ) по SR4/LR4 FEC нередко не требуется, но на «шумных» участках может быть рекомендован.
• Для 25G по DAC или короткой оптике FEC часто можно оставить выключенным или в Auto, но на грани по качеству линии он помогает удержать CRC в нуле.

Заранее решите, где вы доверяете Auto, а где фиксируете режим руками (особенно в ядре/spine, где важна предсказуемость).

Где чаще всего ошибаются: межвендорные стыки и breakout

Ошибки обычно всплывают в двух сценариях. Первый - межвендорный стык: Nexus 9300 соединяют с оборудованием другого производителя или с транспортом. У обоих «Auto» может означать разное, и вы получаете CRC/дропы при внешне поднятом линке.

Второй - breakout (100G -> 4x25G). На стороне QSFP28 порт может ожидать один режим FEC, а на стороне SFP28 и NIC - другой. Симптомы: линк нестабилен, растут FCS/CRC, появляются периодические ошибки без явной причины.

Связка с оптикой и длиной простая: чем «сложнее» физика (дольше линия, больше соединений, хуже качество кабеля, более чувствительный модуль), тем выше шанс, что FEC нужен и его лучше зафиксировать. Перед закупкой сверяйте требования FEC в даташитах модулей и в матрице совместимости портов, а на пилоте подтверждайте это реальными счетчиками ошибок.

Пилот: пошаговый план проверки FEC и CRC

Пилот нужен не для того, чтобы «просто пингануть». Его цель - поймать ошибки линии до масштабирования: несовместимую оптику, неверный режим FEC, грязные патч-корды, проблемы автосогласования и редкие flaps, которые потом превращаются в нестабильность сервисов.

Начните со стенда, который повторяет реальную линию. Минимум - два коммутатора, либо коммутатор и сервер с нужной NIC. Сразу составьте список проверяемых линков: 25GbE (SFP28), 100GbE (QSFP28), DAC/AOC, разные длины и разные партии модулей. Если пилот делается под Cisco Nexus 9300 для ЦОД, включите хотя бы один линк «как в проде»: тот же тип оптики, тот же кросс, тот же путь через панель.

Перед измерениями зафиксируйте базовую точку: версии ПО, модель/ревизию железа, текущие настройки портов и режимы FEC. Иначе потом сложно понять, что именно изменилось.

План прогонов

Для каждого типа линка действуйте одинаково: подняли порт, прогрели трафиком, сняли счетчики, повторили в другом режиме.

Сценарий может быть простым: фиксируете скорость и режим согласования (ожидаемая скорость, duplex, состояние линка), гоняете трафик в обе стороны (лучше близко к линии) и держите 15-30 минут, снимаете счетчики ошибок (CRC и связанные L2/L1 ошибки, а также FEC corrected и FEC uncorrected), проверяете стабильность (не было ли link flaps, переобучения, пересогласования скорости). Затем повторяете с альтернативой: другой модуль, другая длина, другой патч-корд, а потом - на реальной нагрузке, не только на синтетике.

После каждого прогона делайте короткую запись в таблицу. Это экономит часы, когда нужно сравнить «до/после».

На что смотреть в результатах

CRC-ошибки чаще всего сигналят о проблемах физики: оптика, кабель, загрязнение, перегиб, плохой контакт. FEC corrected может расти и при рабочем линке, но важно, чтобы не появлялись FEC uncorrected и не росли потери. Если при включении FEC uncorrected уходят, а corrected становится умеренным и стабильным, это часто признак, что линия «на грани» и без FEC будет срываться.

Пример из практики: на 25GbE линии длиной 10 км линк поднимается, но раз в час фиксируются редкие CRC и один flap. Меняете патч-корд, чистите коннекторы, повторяете тест. Если CRC исчезли и счетчики FEC не скачут, проблема была в тракте, а не в порту. Если CRC сохраняются только с конкретной партией модулей, это повод заменить модуль или пересмотреть совместимость.

Буферы и перегрузки: как понять, хватит ли коммутатору памяти

Буферы коммутатора - это небольшая «подушка» памяти, куда складываются пакеты, когда они приходят быстрее, чем могут уйти дальше. В ЦОД это часто проявляется из-за микровсплесков (microbursts) - очень коротких пиков трафика в микросекундах-миллисекундах, которые легко пропустить обычными графиками «средняя загрузка за минуту». Даже если линк в среднем загружен на 30-40%, микровсплеск может мгновенно заполнить очередь.

Симптомы нехватки буферов редко выглядят как «все упало». Чаще это мелочи, которые сложно сразу связать с сетью: tail drop (тихие потери в хвосте очереди), рост задержки, рывки в скорости репликации, таймауты приложений, повторные передачи в TCP. На уровне эксплуатации это ощущается как «то быстро, то медленно», особенно во время бэкапов или массовых обновлений.

Риск перегрузок сильно зависит от соотношения аплинков и даунлинков (oversubscription). Простой пример: стойка с серверами на 25GbE и аплинками на 100GbE. Если несколько серверов одновременно начнут лить данные в один аплинк (репликация, бэкап, миграция ВМ), очередь на выходе может переполниться, даже если коммутатор выглядит «с запасом» по характеристикам.

На пилоте важно проверять не только «скорость на iperf», а сценарии перегрузки: короткие пики трафика (burst), смешанный профиль (мелкие пакеты плюс крупные потоки), одновременные репликации и бэкапы в один аплинк, конкуренцию разных сервисов за один порт (east-west и north-south), и главное - что происходит при заполнении очередей: потери или рост задержки.

Когда видите признаки очередей, ищите решение не только в «железе». Часто помогает комбинация: настройки очередей и QoS (что важнее, что можно прижать), ECN (чтобы не доводить до потерь и заранее «притормаживать» TCP), а также аккуратные лимиты на «шумные» классы трафика. Смысл пилота - доказать на ваших паттернах ЦОД, что при пиках сеть либо держит задержку, либо предсказуемо деградирует без сюрпризов.

Что измерять на пилоте: метрики, логи и простая отчетность

Задача пилота - подтвердить, что выбранная схема (портовый план, оптика, режим FEC) работает стабильно и без скрытых ошибок. Для Cisco Nexus 9300 для ЦОД лучше заранее договориться, какие цифры вы снимаете регулярно и в каком виде показываете итог.

Метрики, которые стоит снимать регулярно

Нужен набор, который помогает быстро отличить проблему кабеля/оптики от очередей и перегрузок: ошибки на интерфейсах (CRC, input/output errors, symbol errors, link flaps), FEC-счетчики corrected/uncorrected (важно фиксировать рост по времени), дропы и discards по портам и по очередям (если доступны), загрузку (средняя и пиковая утилизация, плюс короткие всплески), а также задержку и джиттер на тестовом трафике хотя бы в формате «до/после» в одинаковых условиях.

Чтобы цифры были сравнимыми, снимайте их одинаково: например, утром и вечером, плюс сразу после изменений.

Журнал изменений и простые пороги тревоги

Без журнала пилот превращается в спор «кажется стало лучше». Ведите таблицу: дата/время, что поменяли (тип оптики, длина, FEC on/off, замена патчкорда, перенос порта), где (стойка, порт) и что увидели в счетчиках через 15 минут, 2 часа и сутки.

На время пилота удобно ввести простые пороги, чтобы не пропустить деградацию: любой рост uncorrected FEC или стабильный рост CRC - повод сразу разбирать линию; повторяющиеся link flap - остановить тест и проверить физику; дропы в «спокойном» профиле трафика - проверить очереди и oversubscription; резкий рост задержки или джиттера при тех же нагрузках - искать микровсплески и поведение буферов.

Как сравнивать варианты и оформить результат

Сравнивайте только один параметр за раз. Например: одна и та же линейная карта и нагрузка, но разные модули 25GbE; затем тот же набор, но FEC включен. В отчете показывайте не «лучше/хуже», а цифры: ошибки, дропы, стабильность линка, задержка.

Формат, который обычно устраивает и эксплуатацию, и закупки: одна страница выводов (что выбрали и почему), затем 2-3 таблицы «вариант A/B» и короткое приложение с логами или выгрузками счетчиков. Пример формулировки по делу: «Вариант A: 0 CRC за 72 часа, corrected FEC растет медленно, uncorrected 0, дропов нет. Вариант B: CRC появляются после прогрева, есть 3 link flap». Так разговор быстро переходит из мнений в факты.

Частые ошибки при выборе карт и оптики

Самая дорогая ошибка в проекте на Cisco Nexus 9300 для ЦОД часто выглядит как мелочь: «порты есть, значит поедет». На практике детали в трансиверах, кабелях и настройках иногда решают больше, чем модель коммутатора.

Ошибка 1: берут 100G, а потом «внезапно» нужен breakout

100GbE порт не всегда означает, что вы без проблем раздадите его на четыре 25GbE. Нередко порт есть, но дальше выясняется, что для схемы 4x25 нужен конкретный тип breakout-кабеля и соответствующая оптика (и что она отличается от той, что уже закупили). Итог предсказуемый: сроки сдвигаются, потому что меняется корзина закупки и план монтажа.

Хорошая привычка - заранее описать, какие линк-сценарии будут в стойке: 100G-100G, 100G-4x25, 25G-25G, и на каких расстояниях.

Ошибка 2: «кабель же один и тот же»

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

Чтобы не гадать, держите один стандарт на линию и фиксируйте его в спецификации: тип волокна, тип коннекторов, длины, маркировка на концах.

Ошибка 3: разные режимы FEC на концах

Когда на одном конце FEC включен в одном режиме, а на другом - в другом (или выключен), вы можете увидеть CRC, ретраи, нестабильность или даже падения линка. Это особенно болезненно на 25/100GbE, где запас по качеству сигнала меньше, чем многие ожидают.

Ошибка 4: тестируют «в простое»

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

Ошибка 5: не фиксируют версии и настройки

Если вы не записали версии ПО, профили портов и параметры FEC, вы не сможете повторить результат и понять, почему «вчера было нормально». Минимум, который стоит фиксировать на пилоте: версии NX-OS и модельные номера карт, типы трансиверов и кабелей, длины и место установки, режимы FEC на каждом интерфейсе, счетчики ошибок (CRC) до и после теста, сценарий нагрузки и время проведения.

В проектах, где интегратор ведет пилот и документацию, такие записи экономят дни споров и повторных выездов.

Короткий чеклист и следующие шаги после пилота

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

Чеклист по технике (что должно сойтись)

Проверьте, что совпали базовые вещи: портовый план (25/100GbE на нужных стыках, хватает ли портов под текущие подключения и рост, учтен ли breakout), физика линий (реальные длины, типы волокна SM/MM, запас по бюджету мощности, корректные типы модулей и кабелей), единая политика FEC (одинаковый режим на обоих концах каждого линка, особенно на 25/100GbE и на breakout), пороги по ошибкам (целевые значения по CRC/FEC под нагрузкой и план действий при отклонениях), а также поведение при микровсплесках (нет неожиданного роста drops, или понятно, почему он есть и как его убрать - очереди, oversubscription, QoS/ECN).

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

Как принять решение (pass/fail) и что делать дальше

Критерии pass/fail лучше записать до финального прогона и не менять по ходу. Пример: все линки поднимаются стабильно, режимы FEC совпадают на всех стыках, CRC не растет под нагрузкой, drops не выходят за согласованный предел, а задержка не «скачет» в типовых сценариях.

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

Если пилот делается «под ключ», имеет смысл подключать интегратора и сервисную команду сразу, чтобы закрыть и железо, и настройку, и поддержку. При необходимости можно опереться на GSE.kz (gse.kz): у них есть опыт системной интеграции и поддержки ЦОД 24/7, и это помогает быстрее перевести пилот по Cisco Nexus 9300 в рабочее внедрение без сюрпризов.