Если вы когда-нибудь собирали сеть в ЦОД, то знаете это чувство: в спецификации всё красиво, портов хватает, цена устраивает — а через полгода выясняется, что оборудование не тянет нагрузку, апгрейд стоит как половина стойки, а вендор отвечает на тикеты через неделю. Знакомо? Тогда давайте разберёмся, на что смотреть при выборе коммутатора и маршрутизатора, чтобы не наступить на эти грабли. Кстати, если вы только присматриваетесь к инфраструктуре и думаете про размещение серверов в ЦОД, выбор сети — один из первых вопросов, которые придётся решить.
Разбираем 7 критериев выбора: от пропускной способности и задержки до масштабируемости и поддержки вендора
Начнём с базы, но без воды. Критериев на самом деле много, но есть семь, которые реально влияют на деньги и на сон вашего сетевого инженера.
- Пропускная способность и oversubscription. Смотрите не на красивые цифры «до 100 Гбит/с на порт», а на коэффициент переподписки. Если у вас 48 портов по 25G и всего 4 аплинка по 100G — это oversubscription 3:1. Для одних задач норм, для других — приговор. Считайте под свой трафик, а не под маркетинговые обещания.
- Задержка (latency). В ЦОД каждая микросекунда на счету, особенно если речь про финансовые приложения, базы данных или ИИ-нагрузки. Смотрите на latency в спецификации, но обязательно уточняйте, при каких условиях она измерена — при полной загрузке цифры будут другими.
- Портфель портов и скорость. 10G, 25G, 40G, 100G, 400G — что вам нужно сегодня и что понадобится через два года? Хороший коммутатор для ЦОД — тот, у которого есть запас по скорости и возможность апгрейда без замены шасси.
- Архитектура фабрики и масштабируемость. Если вы планируете расти, смотрите на поддержку leaf-spine, EVPN-VXLAN и возможность добавлять коммутаторы без перестройки всей сети. Иначе через год придётся перекладывать кабели и объяснять руководству, почему бюджет снова ушёл.
- Функциональность маршрутизации. Для маршрутизаторов в ЦОД критичны таблицы маршрутизации, поддержка BGP, MPLS, сегментация и политики QoS. Дешёвый L3-коммутатор может не тянуть полный BGP-таблицу — проверяйте лимиты, а не только наличие функции в даташите.
- Управление и автоматизация. CLI — это хорошо, но в 2026 году нужны API, Ansible-модули, телеметрия и интеграция с системами мониторинга. Чем меньше ручной работы, тем меньше человеческих ошибок — а они в ЦОД стоят дороже всего.
- Поддержка вендора и жизненный цикл. Сколько лет вендор обещает поддержку? Есть ли локальный сервис? Как быстро приезжает замена? Дешёвое железо с поддержкой «по email из другой страны» — это не экономия, а отложенный простой.
Почему дешёвый коммутатор в ЦОД может стоить дороже: скрытые издержки, которые не видно в спецификации
Вот тут начинается самое интересное. Цена в прайс-листе — это верхушка айсберга. Под водой прячутся:
- Стоимость простоя. Если коммутатор падает и сеть лежит, вы теряете не стоимость железа, а деньги бизнеса. Считали когда-нибудь, сколько стоит час даунтайма для вашего ЦОД?
- Стоимость интеграции. Дешёвое оборудование часто требует ручной настройки, кастомных скриптов и времени инженеров. А время инженеров — это деньги.
- Стоимость апгрейда. Коммутатор без запаса по портам и скорости придётся менять целиком через год-два. Это не экономия, а рассрочка наоборот.
- Стоимость поддержки. Если вендор не отвечает или отвечает медленно, вы платите за простой и за нервы команды.
- Стоимость ошибки выбора. Неправильно подобранный маршрутизатор может не тянуть BGP-таблицу или не поддерживать нужную сегментацию — и всё придётся переделывать.
Так что когда видите «дешёвый коммутатор для ЦОД», задайте вопрос: а что именно вы экономите и чем за это платите?
Сравниваем подходы к выбору сети в ЦОД: портфель портов, архитектура фабрики и запас на рост
Есть три подхода, и каждый хорош по-своему.
Подход «по портфелю портов». Вы берёте коммутатор под текущее количество портов и скорость. Плюс — быстро и дёшево. Минус — через год может не хватить портов или скорости, и придётся докупать и перестраивать сеть. Хорошо для небольших ЦОД с предсказуемой нагрузкой.
Подход «по архитектуре фабрики». Вы сразу строите leaf-spine с запасом на рост, выбираете оборудование с поддержкой EVPN-VXLAN и масштабируемой фабрикой. Плюс — сеть готова к росту и новым нагрузкам. Минус — выше стартовые вложения. Хорошо для ЦОД, которые планируют расти и запускать новые сервисы.
Подход «по запасу на рост». Вы выбираете оборудование с запасом по портам, скорости и функциональности — на 2–3 года вперёд. Плюс — не придётся переделывать сеть при каждом росте. Минус — можно переплатить за то, что не понадобится. Хорошо для компаний, которые не хотят частых апгрейдов и готовы платить за спокойствие.
Какой выбрать? Зависит от ваших планов, бюджета и того, насколько критичен простой. Но в любом случае лучше считать TCO на 3–5 лет, а не смотреть только на цену в прайсе.
Типичные ошибки при выборе сети в ЦОД (и как их избежать)
Теория теорией, но давайте честно: большинство проблем с сетью в ЦОД начинается не с плохого оборудования, а с решений, принятых на этапе выбора. Вот самые частые грабли, на которые наступают даже опытные команды.
Ошибка 1. Покупать «под текущую нагрузку» без запаса. Классика: собрали сеть ровно под сегодняшние 20 серверов, а через год их стало 60. И ладно бы только портов не хватало — скорость и архитектура тоже не тянут. Как избежать: считайте не только сегодняшний трафик, но и план роста на 2–3 года. Хотя бы прикиньте, сколько серверов и каких нагрузок ждёте.
Ошибка 2. Экономить на аплинках. 48 портов по 25G и четыре аплинка по 100G выглядят красиво в спецификации, но на практике это узкое горлышко. Как избежать: считайте oversubscription под реальный профиль трафика, а не «чтобы влезло в бюджет». Лучше меньше портов, но с нормальными аплинками, чем наоборот.
Ошибка 3. Верить даташиту без проверки лимитов. «Поддерживает BGP» — не значит «тянет полную BGP-таблицу». «Поддерживает VXLAN» — не значит «делает это на скорости». Как избежать: просите у вендора конкретные цифры и, если есть возможность, тестируйте на пилотном стенде. Пять минут с инженером вендора сэкономят месяцы боли.
Ошибка 4. Игнорировать автоматизацию. Если оборудование управляется только через CLI и не умеет в API и телеметрию, вы обречены на ручную работу. А ручная работа в ЦОД — это человеческие ошибки, которые стоят дороже всего. Как избежать: проверяйте наличие API, поддержку Ansible/Terraform и интеграцию с мониторингом ещё на этапе выбора.
Ошибка 5. Покупать «на вырост» без расчёта. Обратная крайность: берут оборудование с запасом на пять лет вперёд, переплачивают за функции, которые так и не понадобятся, а через два года выясняется, что нужна другая архитектура. Как избежать: считайте TCO и сценарии роста, а не покупайте «самое топовое, чтобы точно хватило».
Ошибка 6. Не проверять поддержку и жизненный цикл. Дешёвое железо с поддержкой «по email из другой страны» кажется выгодным ровно до первого простоя. Как избежать: уточняйте срок поддержки, наличие локального сервиса и скорость замены. Это не менее важно, чем порты и скорость.
Ошибка 7. Выбирать сеть в отрыве от остальной инфраструктуры. Коммутаторы и маршрутизаторы живут не сами по себе — они связаны с серверами и СХД. Если вы планируете размещение серверов в ЦОД или уже развернули СХД, сеть должна под них подстраиваться, а не наоборот. Как избежать: проектируйте сеть вместе с серверной и storage-частью, а не по остаточному принципу.
Вывод простой: большинство этих ошибок — не про технологии, а про дисциплину выбора. Чек-лист и расчёт на 3–5 лет вперёд закрывают 80% проблем.
Коммутатор vs маршрутизатор: где проходит граница в современном ЦОД
Этот вопрос задают на каждом втором собеседовании, и ответ «коммутатор работает на L2, а маршрутизатор на L3» уже давно устарел. Давайте разберёмся, как оно на самом деле.
Классическое деление. Исторически коммутатор — это про локальную сеть: MAC-адреса, VLAN, быстрое переключение внутри одного сегмента. Маршрутизатор — про соединение разных сетей: IP-адреса, BGP, NAT, фильтрация трафика между сегментами. Всё просто, пока не начинаешь строить современный ЦОД.
Что изменилось. Сегодня L3-коммутаторы умеют маршрутизировать на скорости портов, держать огромные таблицы маршрутизации и поддерживать BGP с EVPN. А маршрутизаторы научились делать функции, которые раньше были только у коммутаторов. Граница размылась, и это нормально.
Как выбирать на практике. Смотрите не на название устройства, а на задачу. Если нужно быстро переключать трафик внутри ЦОД между серверами и СХД — вам нужен коммутатор, даже если он L3. Если нужно соединить ЦОД с внешними сетями, филиалами или провайдерами, работать с BGP и политиками — вам нужен маршрутизатор. В современном ЦОД часто используют оба: коммутаторы строят фабрику внутри, маршрутизаторы отвечают за выход наружу.
Типичная ловушка. Купить L3-коммутатор и пытаться повесить на него функции маршрутизатора — или наоборот. В итоге получаете либо нехватку таблиц и функций, либо переплату за ненужную производительность. Как избежать: определите, где проходит граница вашей сети — внутри ЦОД или на стыке с внешним миром, — и подбирайте оборудование под эту границу.
Короткий вывод. Коммутатор и маршрутизатор сегодня — не столько разные устройства, сколько разные роли в сети. И хорошая архитектура ЦОД — та, где каждая роль закрыта подходящим оборудованием, а не универсальным «на всё сразу».
