Проектирование ядра ЦОД на Cisco Nexus 9500 на 3 года

С чего начинается задача: рост и стабильность ядра ЦОД

Модульное ядро на Cisco Nexus 9500 - это шасси, где вы отдельно выбираете и со временем меняете модули: линейные карты с портами, управляющие модули (supervisor), фабрику, блоки питания. В отличие от фиксированных коммутаторов, вы не упираетесь в заданный набор портов и возможностей. Емкость можно наращивать по мере роста, не меняя устройство целиком.

Трехлетний горизонт важен не потому, что через три года все выбросят. Он нужен, чтобы согласовать бюджет, сроки поставок, окна работ и реальные риски. У модульного ядра много вариантов компоновки, и ошибка на старте обычно стоит дороже, чем разумный запас. Еще один фактор - обновления NX-OS и совместимость: то, что работает сегодня, должно без сюрпризов обновляться и через год, и через два.

Больше всего простоев в ядре дают не «сложные баги», а базовые вещи: питание без реального A/B, отсутствие второго supervisor в горячем резерве, неудачная схема замены фабрики или линейной карты, ошибки изменений (VLAN/VRF, ACL, BGP, MTU, опечатки в автоматизации), обновление NX-OS без плана отката.

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

• какая емкость нужна сейчас и через 36 месяцев;
• какие отказы должны проходить незаметно для сервисов;
• как вы обновляете NX-OS и как быстро откатываетесь;
• какой процесс изменений обязателен.

Если ЦОД растет за счет новых стоек и новых команд, сценарий «сегодня хватает» почти всегда превращается в постоянные ночные работы и риск ошибок. Гораздо спокойнее, когда рост и изменения заранее разложены по плану: что добавляем, когда добавляем и как проверяем, что ядро осталось стабильным.

Требования на 3 года: что собрать до проектирования

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

Сначала разберите, какие сервисы реально будут жить в ЦОД и как они растут. Важно не название системы, а профиль: постоянный трафик или пики, много мелких соединений или крупные потоки, чувствительность к задержке, сезонность. Отдельно отметьте будущие изменения: переход на новые версии, VDI, расширение Kubernetes, появление новых площадок.

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

Затем опишите типы подключений и их критичность: серверные стойки, СХД, межсегментные связи (east-west), выход во внешние каналы и офисные сети. Разделяйте «сколько портов нужно» и «какие скорости» (10/25/40/100G), плюс требования к оптике и расстояниям.

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

В конце оформите допущения на 3 года: темпы роста по портам и полосе, сроки ввода новых залов, принципы сегментации, и что считается «успешным изменением». Например: «рост серверных подключений на 30% в год, переход части хранилищ на 100G на втором году, плановые окна обновлений только по воскресеньям 02:00-06:00». Так решения принимаются быстрее, и меньше споров задним числом.

Планирование емкости: порты, скорость, запас

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

Начните со списка потребителей портов на ближайшие 12-18 месяцев и добавьте прогноз проектов на 2-3 года. Обычно это стойки с ToR, аплинки, подключение SAN или IP-storage, внешние маршрутизаторы, фаерволы, DCI и сервисные сети.

По скоростям помогает правило «скорость там, где есть массовая агрегация». Часто получается так: 10G остается для отдельных сервисов и управления, 25G - базовая скорость для серверов и ToR в новых стойках, 40G встречается как наследие, а 100G закрывает аплинки ToR, межкоммутаторные связи и выходы к DCI. Если не уверены, где нужен 100G, спросите себя: «этот линк собирает трафик от десятков хостов или только от пары устройств?»

Запас имеет смысл фиксировать не только для питания и supervisor, но и для портов и аплинков. На практике часто достаточно держать 20-30% свободных портов по каждому типу скорости и минимум один «лишний» аплинк на стойку или зону для аварийной перекоммутации. Отдельно закладывают запас по суммарной полосе на выход к DCI/интернету под рост и миграции.

Будущие проекты учитывайте отдельными строками, даже если срок плавает: новая платформа виртуализации, резервный ЦОД, GPU-кластер, новый сегмент для финсектора, переход на 25G серверные карты. Это снижает риск внезапно упереться в порты через год.

Удобный формат - таблица «год 0-1-2-3» по портам и суммарной полосе:

Пример: если в год 1 добавится еще 6 стоек виртуализации, и каждая требует по 2x100G аплинка, то только на этот проект нужно 12 портов 100G плюс запас под аварийные перестройки. Такой расчет выглядит «слишком простым», но именно он чаще всего спасает бюджет и сроки.

Слоты и модули Nexus 9500: как не ошибиться с компоновкой

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

У Nexus 9500 важно мыслить ролями. Линейные карты дают порты (10/25/40/100G и выше). Supervisor отвечает за управление и контрольную плоскость. Фабричные модули дают пропускную способность внутри шасси, и именно они часто ограничивают будущий рост, даже если порты еще есть. Блоки питания и вентиляторы - отдельная зона риска: по ним часто «не влезают» поздние апгрейды.

Если вы планируете рост на 3 года, оставляйте место не только под порты, но и под апгрейд пропускной способности шасси. Практичный ориентир - держать свободными 1-2 слота под линейные карты и заранее понимать, понадобится ли усиление фабрики и питания, когда появятся новые 100G/400G подключения.

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

Для эксплуатации почти всегда выгодно единообразие: меньше типов линейных карт, меньше вариантов оптики и кабелей, проще ЗИП и меньше сюрпризов при замене. Не обязательно один тип на все, но избегайте «зоопарка» из единичных модулей.

Перед финальной компоновкой проверьте ограничители: совместимость модулей с выбранной версией NX-OS, расчет потребления с запасом (особенно при N+1 по питанию), тепловыделение и требования к охлаждению, ограничения по oversubscription, а также план замены - можно ли менять модуль без долгого окна и что будет с трафиком.

Простой пример: если сегодня достаточно двух линейных карт 100G, но через 18 месяцев планируется удвоение uplink-ов, лучше заложить запас по питанию и фабрике сразу, а порты докупать позже. Так вы избегаете ситуации, когда «место есть, а поставить нельзя» из-за ватт и пропускной способности внутри шасси.

Резервирование: что дублировать и где обычно забывают

Резервирование в ядре ЦОД нужно не ради галочки, а чтобы пережить типовые отказы: выход из строя линейной карты, отказ supervisor, потерю блока питания, падение отдельного линка или целого коммутатора. Для модульного шасси важно заранее решить, какие события должны проходить незаметно для пользователей, а какие допустимы с короткой деградацией.

Пара шасси: актив-актив или актив-пассив

Актив-актив означает, что оба шасси одновременно несут трафик. Это дает лучшую утилизацию портов и выше живучесть при отказе одного устройства, но требует аккуратной схемы подключения и четких правил на границе ответственности (L2/L3, ECMP, vPC и т.д.).

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

В любом варианте закладывайте резервирование внутри шасси: два supervisor, N+1 по питанию и охлаждению. Это позволяет спокойно менять модуль, переживать пиковые условия и не превращать мелкую работу в аварию.

Резервируйте и связи. Вниз к стойкам и вверх к внешним сегментам планируйте два независимых пути: разные порты, разные линейные карты, разные коммутаторы на концах. В идеале добавьте разнесение трасс по разным лоткам или вводам.

Где чаще всего появляется двойная точка отказа

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

• оба шасси не должны питаться от одной PDU или одного вводного автомата;
• кабели к разным устройствам не должны идти одним маршрутом в одном лотке;
• два аплинка не должны сходиться в один и тот же промежуточный коммутатор;
• резервные блоки питания должны быть реально запитаны и учтены в расчетах;
• «временные» патч-корды не должны становиться единственными постоянными путями.

Хорошее правило: рисуйте отказ не устройства, а целого элемента среды (PDU, лоток, стойка, ToR) и смотрите, остается ли рабочий путь. Такой разбор удобно делать вместе с эксплуатацией и интегратором, чтобы на схеме не осталось скрытых общих зависимостей.

Схемы обновления NX-OS: как планировать без сюрпризов

Обновления NX-OS бывают разными по смыслу и рискам. Плановые релизы закрывают накопившиеся ошибки и добавляют функции. Срочные обновления безопасности обычно приоритетнее и могут ломать привычный график. Есть и обновления, завязанные на железо: например, когда для конкретных линейных карт или supervisor требуется определенная ветка NX-OS, или нужно обновить микрокод (EPLD) отдельным шагом.

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

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

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

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

Контроль рисков изменений: процесс, а не героизм

Больше всего простоев в ядре ЦОД случается не из-за «плохого железа», а из-за изменений, сделанных на эмоциях и без четкого плана. Для Nexus 9500 это особенно важно: модули, несколько плоскостей управления и сложные зависимости в NX-OS. Хорошее проектирование включает не только схему, но и дисциплину изменений.

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

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

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

Отдельная часть - доступы. Чем меньше людей могут «нажать кнопку», тем ниже шанс случайной ошибки. Держите принцип минимума прав, используйте отдельные учетные записи, включайте журналирование действий и заранее готовьте аварийный доступ с понятными правилами применения.

Эксплуатация и наблюдаемость: чтобы рост не стал аварией

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

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

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

Пороги и алерты лучше делать консервативными и редкими, иначе уведомления перестают читать. Например, отдельно алерт на длительную загрузку выше 70-80% (не пик на минуту), отдельно - на любые ошибки, которые растут, и отдельно - на отклонения по температуре и питанию. Хорошая практика - раз в квартал пересматривать пороги после изменений и роста трафика.

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

Отдельно ведите «паспорт» ядра: версии NX-OS, установленные модули и серийные номера, схемы питания и подключений, даты работ, замеченные риски и что с ними сделали. Когда через полтора года нужно срочно добавить линейную карту или заменить оптику, этот паспорт экономит часы.

Пример сценария: ядро для растущего ЦОД без усложнений

Исходные данные: два зала в одном ЦОД, критичные сервисы 24/7 (виртуализация, базы, VDI и несколько гос-сервисов). Серверный парк растет на 30% в год, вместе с ним растут east-west потоки и требования к предсказуемости изменений. Цель - спроектировать ядро так, чтобы через 3 года не пришлось «перекраивать» архитектуру.

План закупки на 3 года: что сразу, что опцией

Сразу закладывают два шасси Nexus 9500 (по одному в каждом зале) и считают емкость по целевой нагрузке года 3 плюс запас. На старте не пытаются занять все слоты линейными картами: оставляют место под рост и под замену модулей при переходе на более высокие скорости.

Обычно план выглядит так:

• Год 0: два шасси, резервирование supervisor, базовый набор линейных карт под текущие 10/25G и аплинки.
• Год 1: докупка линейных карт под новые стойки, расширение аплинков между залами.
• Год 2: точечный перевод части подключений на 100G (или выше) и добавление портов под новые сервисы.
• Год 3: замена 1-2 линейных карт на более плотные/скоростные без смены шасси.

Как выглядит резервирование в реальной схеме

Два шасси работают как единое ядро, а каждый критичный узел подключен «крест-накрест»: по одному линку в каждый зал. Между залами - две независимые трассы (разные кабельные пути и точки ввода). По питанию - два ввода и разнесение блоков питания по разным PDU. Это снижает риск «одной точки отказа» не только в железе, но и в инфраструктуре.

По NX-OS график часто делают простым: major-обновление раз в год в заранее согласованное окно, security-патчи - чаще (например, раз в квартал) с проверкой на тестовом контуре и четким планом отката.

Заранее фиксируют риски и меры: по поставкам держат список взаимозаменяемых модулей и запас по срокам; по окнам согласуют 2-3 варианта заранее; по человеческому фактору вводят шаблоны изменений, peer review и чеклист; по несовместимостям регулярно сверяют матрицы NX-OS, модулей и оптики; на «рост вдруг» держат буфер портов и мощности.

Короткий чеклист перед закупкой и изменениями

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

Быстрая проверка (10-15 минут)

• Емкость на ближайшие 12-18 месяцев: сходится ли прогноз портов и аплинков с реальными заявками команд, и есть ли понятный запас.
• Железо и компоновка: остаются ли свободные слоты под рост и под замену линейных карт, хватает ли блоков питания по схеме N+1, укладывается ли потребление в лимиты стойки и PDU.
• Отказоустойчивость без общих точек отказа: разведены ли питание (разные вводы, разные PDU), трассы (разные лотки/стояки), и нет ли скрытой общей точки вроде одного патч-поля.
• План обновлений и отката: согласовано ли окно, определены ли ответственные, есть ли критерии «все хорошо» и понятный шаг назад.
• Документы и факты: совпадают ли схема и реальность, актуальны ли конфиги, перечень модулей, SFP/QSFP, версии NX-OS, и есть ли список зависимостей (vPC-пары, BGP/OSPF-соседи, подключенные фабрики, L2-шлюзы).

Если кратко: ядро на Nexus 9500 чаще ломается не на выборе шасси, а на мелочах вокруг - питании, трассах, запасе слотов и дисциплине изменений.

Небольшой пример: планируется добавить 8 новых 100G аплинков «в следующем квартале». По чеклисту выясняется, что порты есть, но нет запаса по питанию: при отказе одного БП шасси выходит за допустимый режим. Это лучше исправить до закупки оптики и работ в стойке.

Следующие шаги: как превратить план в работающее ядро

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

В таблице обычно хватает 10-15 строк: типы подключений (серверы, ToR, граница, SAN), текущая скорость и количество портов, прогноз по кварталам, отдельная колонка под запас. На схеме отметьте, какие шасси и линии сейчас критичны, и где будет точка расширения (свободные слоты, место в стойке, питание, оптика).

Дальше сделайте ревизию рисков до закупок и миграций: питание (две независимые линии, реальная нагрузка, запас по PDU), трассы и оптику (разнос, длины, типы модулей), единые точки отказа (OOB-управление, NTP/DNS/AAA, сбор логов), процессы (кто утверждает изменения, кто откатывает, кто на связи ночью).

Отдельно согласуйте политику обновлений NX-OS: как часто обновляете, какие окна допустимы, что считается успехом и по какому критерию принимается решение об откате.

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

Если не хватает ресурсов на обследование площадки, проект, внедрение и поддержку, подключайте интегратора с понятным процессом изменений. В Казахстане такие задачи закрывает GSE.kz (gse.kz): от проектирования и системной интеграции до круглосуточной технической поддержки и сервисной сети.