Когда переход на 10/25/100GbE оправдан в серверной

Что значит, что сеть стала узким местом

Сеть становится узким местом, когда серверам и хранилищу уже хватает CPU, RAM и дисков, но приложения все равно тормозят, потому что данные не успевают проходить между узлами. Чаще это видно не как постоянные 100% на порту, а как короткие пики трафика, очереди на коммутаторе и рост задержки.

Обычно в сеть упираются задачи, где много обмена между серверами: миграции и хранилище для виртуализации, базы данных с активными запросами, VDI (особенно в часы входа пользователей), а также трафик резервного копирования и репликации. На 1GbE такие нагрузки могут выглядеть приемлемо до определенного масштаба, а потом любой рост (плюс 10-20 ВМ, еще один узел, больше пользователей) резко ухудшает ситуацию.

Важно смотреть не только на среднюю загрузку канала. Средняя может быть 30-40%, но при микровсплесках (microbursts) пакеты встают в очередь, появляются потери и ретрансляции. Приложения ощущают это как задержки и подвисания.

Чаще всего узкие места появляются в нескольких точках:

• ToR-коммутатор в стойке, когда много серверов делят один или два аплинка
• uplink в агрегацию или ядро, особенно при одновременных бэкапах
• сеть хранения (iSCSI/NFS/CEPH) или ее отсутствие, когда все смешано в одном канале
• межузловой трафик кластера виртуализации (vMotion/Live Migration)

Если вы обсуждаете переход на 10/25/100GbE, начните с простого вопроса: где именно растет задержка и где появляются очереди. Это дает точку для расчета и помогает не купить просто более быстрые порты, оставив прежнее бутылочное горлышко, например в аплинке или storage-сети.

Признаки, что пора повышать скорость линков

Самый частый сигнал - сеть вроде работает, но все важное начинает занимать заметно больше времени: копирование файлов, открытие тяжелых документов, ночные бэкапы, вход в VDI. Если при этом CPU и диски на серверах не забиты, логично проверять сеть.

Начните с графиков на коммутаторах и на серверах. Опасны не только 90-100% утилизации, но и очереди на портах, дропы и ошибки. Часто средняя загрузка за сутки выглядит скромно, но в пиках на 10-15 минут линк упирается в потолок и на эти минуты подвешивает сервисы. Поэтому привязывайте пики к событиям: когда идут резервные копии, репликации, обновления, миграции виртуальных машин.

В виртуализации узкое место часто видно по косвенным симптомам. Миграции VM (vMotion/Live Migration) тянутся дольше обычного, а один шумный сосед в группе хостов начинает заметно ухудшать работу других VM. Обычно это означает, что east-west трафик между хостами и хранилищем упирается в скорость линков или в аплинк стойки.

Со стороны хранилища типичный признак - растет latency, хотя диски и контроллеры не в экстремальной загрузке. Например, днем пользователи жалуются на лаги VDI, а мониторинг показывает всплески задержек на iSCSI/NFS именно в моменты параллельных задач.

Метрики, которые должны насторожить:

• регулярные пики утилизации порта близко к 100% в рабочие окна
• рост очереди на порту и дропы (даже без явных аварий)
• CRC/ошибки на интерфейсе (часто маскируют проблему кабеля или оптики)
• растянутые окна бэкапа и репликации при прежних объемах
• замедление миграций VM и нестабильность VDI в часы пик

Если таких сигналов несколько, переход на 10/25/100GbE обычно оправдан не ради скорости как таковой, а чтобы убрать пики, из-за которых пользователи и сервисы ощущают сеть как тормоз.

Какие данные собрать перед расчетом

Перед тем как считать пропускную способность, соберите факты о текущей нагрузке. Иначе переход на 10/25/100GbE легко превращается в закупку на глаз, где потом внезапно упирается не линк, а бэкап-окно, дисковая подсистема или несовместимая оптика.

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

Минимальный набор исходных данных

Соберите цифры, которые можно проверить и повторить через месяц:

• Инвентаризация: сколько физических хостов, сколько VM, где стоят хранилища, сколько сетевых портов и какой скорости на узлах.
• Пиковая и средняя нагрузка: входящий и исходящий трафик по времени суток, отдельно для prod, storage, backup, репликации и управления.
• Резервное копирование: объем данных за ночь, требуемая скорость, длительность окна обслуживания, сколько потоков параллельно и куда пишется бэкап.
• Репликация и миграции: как часто и сколько данных гоняется (например, vMotion/Live Migration), есть ли всплески в рабочее время.
• Ограничения: бюджет, сколько свободных юнитов в стойке, доступность модулей SFP28/QSFP28, тип кабеля (медь/оптика) и реальные расстояния между узлами и коммутаторами.

Дальше добавьте прогноз роста на 12-24 месяца. Это не гадание, а план: сколько новых VM ожидается, как растут базы и файлы, появятся ли новые сервисы (например, VDI, видеонаблюдение, аналитика). Часто именно рост делает текущие 10GbE вчерашним днем.

Отдельно зафиксируйте, что критично по времени. Например, RPO 15 минут и RTO 2 часа диктуют требования к репликации и восстановлению, а не только к скорости портов. Если ночью нужно снять 20 ТБ за 6 часов, важна не дневная средняя загрузка, а стабильная скорость ночью с учетом накладных расходов и параллельных задач.

Пошаговый расчет пропускной способности под виртуализацию

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

5 шагов, которые дают понятную цифру

1. Оцените east-west трафик: кто с кем общается внутри кластера (VM с базой данных, VM с хранилищем, сервисы мониторинга). Смотрите пики, а не среднее за день.

2. Оцените north-south трафик: выход к пользователям, интернету, филиалам и внешним системам. Часто он меньше внутреннего, но именно он влияет на ощущение, что тормозит сайт или 1С.

3. Добавьте трафик миграций и обслуживания: Live Migration/vMotion, ребилды, обновления хостов. Важно, как часто это происходит и сколько VM обычно переезжает одновременно.

4. Заложите накладные расходы: заголовки протоколов, инкапсуляция (например, VXLAN), шифрование, зеркалирование, служебные потоки. Практично добавлять запас 15-30% поверх измеренных пиков.

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

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

Пример: если в ToR подключено 8 хостов по 10GbE, суммарно это 80GbE. При oversubscription 4:1 аплинк нужен около 20GbE (на практике это подталкивает к 25GbE), а при 2:1 - уже 40-50GbE. Так переход на 10/25/100GbE становится следствием цифр, а не моды.

Расчет сети для резервного копирования и репликации

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

Базовая оценка простая: объем данных, который нужно передать за окно, делим на длительность окна. Формула в лоб выглядит так: ГБ за окно / секунды окна = ГБ/с. Чтобы перевести в Гбит/с, умножьте ГБ/с на 8.

Например, за ночь надо отправить 4 000 ГБ инкрементов за 6 часов. 6 часов = 21 600 секунд. 4 000 / 21 600 = 0,185 ГБ/с, то есть около 1,48 Гбит/с чистой скорости. Но это без накладных расходов, без пиков и без одновременных задач.

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

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

Чтобы не получить ситуацию, когда переход на 10/25/100GbE ускорил бэкап, но начал мешать пользователям, предусмотрите простые меры: разнесите бэкап и репликацию по отдельным VLAN или интерфейсам, ограничьте скорость на задания, не запускайте все джобы в одну минуту. Это особенно важно на плотных узлах виртуализации и хранилища.

Как выбрать между 10, 25 и 100GbE

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

10GbE часто становится первым взрослым шагом для ToR-коммутатора, хостов виртуализации и отдельного бэкап-сегмента. Его хватает, если у каждого сервера умеренный I/O, а пики редкие и короткие.

25GbE стоит рассматривать не как немного быстрее 10, а как более удобную ступень роста: на одном порту больше запаса, и часто это выгоднее по цене за 1 Гбит/с, особенно когда важна плотность портов и вы не хотите возвращаться к апгрейду через год.

100GbE обычно выбирают не на каждый сервер, а для аплинков и межстоечных связей: агрегация, spine/leaf, подключения тяжелых кластеров. В таких местах суммарный поток от стойки легко упирается в 2x10 или 4x10.

Ориентиры, которые помогают не ошибиться:

• Оставайтесь на 10GbE, если узел редко упирается в сеть и стойка не забивает аплинки даже в пики.
• Берите 25GbE на хосты, если на них много говорящих ВМ, активные миграции, или бэкап и рабочий трафик пересекаются по времени.
• Планируйте 100GbE на аплинки, если суммарно с 10-20 серверов стойки трафик часто упирается в 2-4 аплинка, даже если каждый сервер по отдельности не перегружен.
• Проверяйте не только скорость порта, но и суммарную пропускную способность вверх: часто проблема не в серверах, а в узком аплинке.

Практичный сценарий постепенного перехода: оставить часть серверов на 10GbE, новые узлы подключать на 25GbE, а аплинки ToR сделать 100GbE. Так вы заранее усиливаете верх стойки, не меняя все сетевые карты и оптику одновременно.

Оптика и кабели: что проверить до закупки

При переходе на 10/25/100GbE чаще всего стреляют не сами скорости, а детали вокруг оптики: форм-фактор, тип кабеля, расстояние, чистота коннекторов и бюджет мощности. Ошибка на этом этапе легко превращается в нестабильные линки и лишние закупки.

Сначала проверьте совместимость форм-факторов и скоростей. SFP+ обычно про 10GbE, SFP28 про 25GbE, QSFP28 про 100GbE. Важно не только то, что модуль физически подходит, но и поддерживает ли конкретная модель коммутатора нужный режим, кодировку и, если нужно, разветвление 100G в несколько 25G (breakout).

Дальше решите вопрос дистанции и типа волокна. Для коротких линий внутри стойки и между соседними стойками часто хватает многомода (OM3/OM4). Для длинных трасс по серверной, между этажами или корпусами обычно выбирают одномод (OS2). Это влияет на цену модулей, тип коннекторов и допустимые потери.

Перед заказом полезно свести физику в одну простую таблицу (порт - модуль - тип среды - длина) и проверить три вещи: укладываются ли потери в допуск Tx/Rx, совместимы ли модули с вашим вендором и прошивкой, и понятно ли, где можно использовать DAC/AOC, а где нужна оптика.

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

Перед вводом в эксплуатацию сделайте короткий план тестов: проверьте уровни сигнала и температуру модулей (DOM/DDM), прогоните нагрузку 1-2 часа и посмотрите CRC/FEC/дропы, понаблюдайте за флапами линка на реальной нагрузке (виртуалки, бэкапы). Если есть подозрения, переподключите патч-корды и убедитесь, что проблема не переезжает вместе с кабелем.

Коммутаторы: на что смотреть, кроме скорости портов

Скорость порта на коробке не гарантирует, что коммутатор переварит реальный трафик. Узкое место часто появляется не на 10/25/100GbE линке, а внутри устройства: не хватает буферов при всплесках, падает производительность на мелких пакетах (PPS), а аплинки перегружаются из-за oversubscription.

Если у вас виртуализация, почти всегда есть микс трафика: east-west между ВМ, хранилище, управление, резервное копирование. В такой смеси важны не только гигабиты, но и то, как коммутатор держит очереди и приоритеты, и как быстро показывает проблему в мониторинге.

Что проверить по начинке и функциям

Из того, что действительно пригодится в серверной:

• Буферы и PPS: чтобы переживать короткие пики (например, старт ночных бэкапов или массовый ребут ВМ).
• VLAN и LACP: для разделения трафика и агрегирования линков к хостам.
• Stack или MLAG: чтобы два ToR выглядели как один и хосты не зависели от одного коммутатора.
• QoS и базовая телеметрия: чтобы не топить все бэкапом и быстрее находить перегрузки.
• Oversubscription: оцените, сколько 25G портов сходится в один 100G аплинк и какой запас вам нужен.

Железо, которое забывают посчитать

Заложите питание и охлаждение: два БП, горячая замена, запас по мощности под оптику, приемлемый уровень шума (особенно в небольших серверных). Отдельно проверьте план портов: сколько 10/25G пойдет на хосты сейчас и через год, и сколько 100G нужно на аплинки к ядру или в spine-leaf.

На практике при переходе на 10/25/100GbE лучше начинать не с максимума скорости, а с понятной ToR-архитектуры с резервированием и прогнозом роста. Если вы делаете это вместе с интегратором, заранее зафиксируйте требования по oversubscription, отказоустойчивости и мониторингу, чтобы закупка не превратилась в набор несовместимых быстрых портов.

Типовые ошибки при переходе на более быстрый Ethernet

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

Вторая ловушка - ускорить серверы, но оставить бутылочное горлышко выше по цепочке. Например, вы поставили на хосты 25GbE, а аплинк с коммутатора стойки в ядро остался 10GbE. В такой схеме новые карты почти не дают эффекта: весь трафик все равно упирается в старый аплинк.

С оптикой и кабелями тоже легко промахнуться. Часто покупают модули на глаз, не сверив дистанции, тип портов и среду. Результат - несовместимость, ошибки линка, или внезапно оказывается, что нужен другой тип трансиверов (SFP28/QSFP28) и другая разводка.

Проверьте себя по короткому списку:

• Планируете пиковые нагрузки (бэкапы, репликация, VM-migration), а не только среднее за сутки.
• Сверяете скорость на всем пути: сервер - ToR - аплинк - агрегация - ядро - хранилище.
• Подбираете оптику и кабели под реальные расстояния и типы портов заранее.
• Закладываете запас по портам и ресурсам коммутатора, чтобы не доплачивать за срочные доработки.
• Настраиваете мониторинг до апгрейда, чтобы было чем подтвердить проблему и проверить результат.

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

Быстрый чеклист перед апгрейдом

Перед тем как планировать переход на 10/25/100GbE, полезно за 1-2 рабочих дня собрать признаки, что сеть реально упирается в скорость, а не в настройку или диски.

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

Чеклист, который обычно дает ясный ответ:

• Есть ли порты, которые держатся выше 70-80% загрузки в пиковые часы (регулярно), и при этом растет задержка.
• Есть ли на портах коммутаторов дропы, ошибки, переполнения очередей или рост discards, особенно во время бэкапов или миграций.
• Укладывается ли резервное копирование в окно без заметного влияния на prod: нет ли жалоб на тормозит утром и конкуренции бэкапа с основным трафиком.
• Стали ли миграции VM, ребалансировка хранилища, обслуживание кластера и восстановление после сбоев ощутимо дольше, чем раньше.
• Есть ли понятная карта скоростей: где достаточно 10GbE, где выгоднее 25GbE, где нужен 100GbE, и какие аплинки и агрегация портов для этого потребуются.

Отдельно проверьте физику до закупки. Убедитесь, что выбранные модули и кабели совместимы с вашими серверами и коммутаторами, и что реальная дальность подходит (медь, DAC, оптика, тип волокна). Типовая ошибка - купить SFP28/QSFP28 как в спецификации, а потом упереться в несовместимость или неправильный тип кабеля между стойками.

Пример сценария: виртуализация + ночные бэкапы в одной стойке

Представим стойку с 6 хостами виртуализации. На каждом по 20-30 ВМ, общее хранилище подключено через ToR-коммутатор, а ночью запускаются полные бэкапы на отдельный сервер или репозиторий в той же стойке.

Первые проблемы обычно появляются не днем, а ночью. На 1/10GbE все держится, пока не совпадут три вещи: бэкап, фоновая репликация и обычные задачи ВМ (обновления, отчеты, антивирусные проверки). В этот момент аплинк ToR забивается, растут очереди на портах, и задержка для ВМ заметно увеличивается. Днем это превращается в странные жалобы: "в 9:30 все тормозило", хотя CPU и диски вроде не в красной зоне.

Типичная картина до апгрейда:

• Бэкап не укладывается в окно и затягивается до рабочего времени.
• На портах ToR высокий процент утилизации и микропики до 100%.
• Растет latency для хранения или vMotion, появляются краткие подвисания ВМ.
• При аварийном восстановлении скорость ниже ожидаемой.

Простой план улучшения: поднять скорость на хостах до 25GbE, а аплинки стойки сделать 2x100GbE (или больше, если есть несколько стоек). Отдельно выделить сегмент под бэкап: отдельные VLAN/VRF, отдельные порты или даже отдельный коммутатор, чтобы ночной трафик меньше влиял на живую виртуализацию.

Проверяйте результат не на глаз, а по метрикам до и после: утилизация портов, drop/CRC, очереди, p95 задержки до хранилища, фактическая скорость бэкапа и время закрытия окна. Тестируйте в пиковое время, когда бэкап реально идет, а не в тишине.

Чтобы заложить рост, выбирайте ToR с запасом по портам 25GbE и возможностью добавить еще 100GbE аплинки без полной замены. Тогда расширение (плюс 2 хоста или новый бэкап-репозиторий) будет апгрейдом внутри стойки, а не перестройкой всей схемы.

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

После того как вы нашли узкие места и прикинули нужную полосу, не начинайте с закупки. Сначала соберите точную карту: где стоят серверы и СХД, какие скорости у линков, где аплинки в ядро, где отдельные сети (управление, storage, VM, резервное копирование), где межстоечные соединения. Такая схема быстро показывает, что иногда достаточно усилить один участок (например, uplink стойки), а не менять все подряд.

Дальше помогает план, который снижает риск и дает цифры на реальной нагрузке:

• Соберите схему портов и скоростей по стойкам: хосты, storage, uplink, interconnect, текущие типы SFP/QSFP и длины линий.
• Сделайте пилот на одной стойке (или одном кластере): включите новую скорость, прогоните обычные ночные бэкапы и типовые задачи виртуализации, снимите метрики (загрузка портов, задержки, потери, время окна бэкапа).
• Подготовьте спецификацию: коммутаторы, модули и кабели, плюс 1-2 запасные позиции на критичные элементы (трансиверы, DAC/оптика).
• Продумайте поддержку: кто отвечает за инциденты, как быстро возможна замена, где лежат запасные части, какой порядок отката, и что требуется для режима 24/7.
• Запланируйте внедрение волнами: стойка за стойкой, с контрольными точками и понятными критериями успеха (например, окно бэкапа сократилось до X часов, средняя загрузка uplink не выше Y%).

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