Как рассчитать сеть для сервера: когда достаточно 10GbE, а когда нужны 25/40/100GbE

10GbE достаточно, если суммарный рабочий трафик сервера с запасом укладывается примерно в 5–7 Гбит/с и нет тяжелого трафика хранилища, массовых миграций виртуальных машин, коротких окон резервного копирования, активной репликации или конвейеров данных для AI. 25GbE стоит рассматривать как более надежную базу для плотной виртуализации, серверов с быстрыми NVMe-дисками, резервного копирования больших объемов и обмена между узлами. 40GbE чаще имеет смысл там, где такая инфраструктура уже есть. 100GbE нужно, когда сеть становится частью производительности платформы: для распределенного хранилища, AI-нагрузок, крупных кластеров, быстрой репликации и высокоплотной виртуализации.

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

Еще одна ошибка — смотреть только на среднюю загрузку. Если порт в среднем занят на 20%, это не значит, что сети хватает. Важны пики, окна передачи данных, задержка, потери пакетов и конкуренция разных потоков за один и тот же канал. Для пользователя заметна не средняя скорость за сутки, а момент, когда база начинает отвечать медленнее, виртуальная машина мигрирует слишком долго, резервное копирование не успевает завершиться или хранилище показывает задержки.

Что на практике означает 10/25/40/100GbE

10GbE, 25GbE, 40GbE и 100GbE — это номинальная скорость сетевого канала. Она не равна гарантированной скорости приложения. Часть полосы уходит на служебные заголовки протоколов, подтверждения, шифрование, повторы при потерях, работу сетевого стека, особенности коммутатора и настройки операционной системы. Поэтому в расчетах лучше использовать не идеальную скорость, а полезную: примерно 70–80% от номинала, если нужна осторожная оценка.

В хороших условиях 10GbE может дать около 1 ГБ/с полезной передачи данных. 25GbE — примерно 2,5–3 ГБ/с. 40GbE — около 4–5 ГБ/с. 100GbE — примерно 10–12 ГБ/с. Это не обещание для любой задачи, а ориентир. Один поток может не заполнить канал, особенно на 40 или 100GbE. На результат влияют размер блоков, число параллельных потоков, процессор, драйверы, сетевые карты, буферы, настройки очередей, MTU, коммутатор и само приложение.

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

Поэтому скорость порта — только один слой расчета. Для пользовательского трафика часто важна общая пропускная способность. Для хранилища важны задержка и стабильность. Для репликации — объем изменений за период. Для резервного копирования — окно передачи и скорость восстановления. Для AI — чтобы ускорители не простаивали в ожидании данных.

Базовая формула расчета сети

Для первого приближения можно использовать простую формулу:

требуемая скорость = объем данных / доступное время × коэффициент запаса

Объем данных — это не всегда размер всего содержимого сервера. Для резервного копирования важен объем передаваемой копии или изменений. Для репликации — объем изменений за расчетный период. Для миграции виртуальной машины — объем памяти ВМ и данные, которые меняются во время переноса. Для хранилища — не только гигабайты в секунду, но и число операций, задержка и профиль блоков.

Коэффициент запаса обычно берут от 1,3 до 2,0. Минимальный запас нужен даже в спокойных системах, потому что полезная скорость ниже номинальной, а нагрузка редко идет ровной линией. Для инфраструктурных потоков — хранилища, миграций, резервного копирования, репликации — лучше считать с запасом ближе к двум, особенно если эти потоки пересекаются по времени.

Пример: нужно передать 2 ТБ резервной копии за 4 часа. Это примерно 500 ГБ в час, или около 139 МБ/с без запаса. Даже с запасом такая задача обычно укладывается в 10GbE, если в это же время канал не занят хранилищем, миграциями и пользователями.

Другой пример: нужно передать 20 ТБ за 6 часов. Это уже около 925 МБ/с без запаса. С учетом служебных расходов и параллельной нагрузки задача может приблизиться к практическому пределу 10GbE. Если окно сокращается или объем растет, 25GbE становится намного спокойнее.

Миграция виртуальной машины с 512 ГБ активной памяти за 10 минут требует около 853 МБ/с без учета изменяющихся страниц памяти и накладных расходов. Если таких миграций несколько, 10GbE быстро перестает быть комфортным. Репликация 5 ТБ изменений за 2 часа требует около 694 МБ/с без запаса. Если одновременно идет резервное копирование или трафик хранилища, сеть нужно считать уже не по одному потоку, а по сумме.

Какие виды трафика есть у сервера

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

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

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

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

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

Трафик хранилища возникает при работе с iSCSI, NFS, SMB, NVMe-oF, Ceph и другими распределенными или сетевыми хранилищами. Он чувствителен не только к скорости, но и к задержке, потерям и конкуренции с другими потоками.

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

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

AI-конвейеры данных передают датасеты, признаки, логи, промежуточные результаты, модели и результаты обработки. Если GPU-сервер ждет данные от хранилища, проблема может быть не в ускорителе, а в сети или дисковой подсистеме.

Кластерный трафик включает обмен служебными сообщениями, синхронизацию состояния, кворум и heartbeat. Обычно он небольшой по объему, но важен для стабильности кластера.

Когда 10GbE действительно достаточно

10GbE остается нормальным выбором для многих серверов. Он подходит для одиночного сервера приложений, небольшой виртуализации без активного трафика хранилища, файлового сервера для офиса, веб/API-сервера с умеренной нагрузкой, административной сети, а также резервного копирования с небольшими объемами и длинным окном.

10GbE часто достаточно, если полезная загрузка канала редко превышает 50–60%, пики короткие и не мешают пользователям, а тяжелые фоновые задачи не накладываются друг на друга. Например, если сервер приложений обслуживает пользователей, но база данных находится локально или на отдельном быстром канале, а резервное копирование идет ночью и передает несколько сотен гигабайт, переход на 25GbE может не дать заметного эффекта.

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

Но важно не путать «достаточно» и «навсегда достаточно». Если планируется рост числа ВМ, переход на NVMe, появление репликации, VDI, распределенного хранилища или короткого окна резервного копирования, 10GbE может стать ограничением раньше, чем сервер устареет по CPU или RAM.

Два порта 10GbE не всегда равны одному каналу 20GbE. Агрегация каналов помогает распределить несколько потоков и дает отказоустойчивость, но один поток не ускоряется пропорционально. Поэтому для одной тяжелой передачи 25GbE может быть полезнее, чем несколько 10GbE, особенно если приложение не умеет эффективно использовать параллельные соединения.

Когда лучше сразу брать 25GbE

25GbE часто становится разумным современным минимумом для серверов, которые уже не ограничиваются обычным пользовательским трафиком. Это хороший вариант для плотной виртуализации, серверов с NVMe-дисками, хранилища по Ethernet, быстрых резервных копий, репликации между узлами, VDI, серверов баз данных с активным обменом и небольших AI-конвейеров.

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

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

Для виртуализации 25GbE дает пространство для миграций, трафика ВМ, резервного копирования и обращения к хранилищу. Для backup-серверов он помогает сокращать окна копирования и восстановления. Для баз данных — дает запас под репликацию и выгрузки. Для AI — уменьшает риск, что ускорители будут простаивать из-за медленного доступа к данным.

Когда 40GbE имеет смысл

40GbE стоит рассматривать аккуратно. Это не универсальный новый стандарт для всех проектов, а вариант, который часто встречается в уже построенных дата-центрах и унаследованных сетях. Если в инфраструктуре уже есть 40GbE-коммутаторы, трансиверы, кабели и сетевые карты, использовать их может быть вполне рационально.

40GbE может подойти для межсерверного обмена, хранилища, резервного копирования и агрегации нескольких менее быстрых потоков. Но в новых проектах его стоит сравнивать с 25GbE и 100GbE по цене портов, доступности оборудования, энергопотреблению, кабелям, трансиверам и плану роста.

Во многих сценариях 25GbE оказывается более удобным шагом после 10GbE, а 100GbE — более понятной целью для магистральных и высоконагруженных соединений. Поэтому 40GbE не стоит выбирать только потому, что число выглядит «между 25 и 100». Нужно смотреть, насколько этот вариант вписывается в существующую сеть и будет ли он удобен через несколько лет.

Когда нужны 100GbE

100GbE нужен не каждому серверу. Обычно он оправдан там, где сеть становится частью производительности вычислений или хранилища, а не просто каналом для пользователей. Это высокоплотная виртуализация, распределенные хранилища, NVMe-oF, storage-кластеры, крупные backup-репозитории, быстрая репликация, AI-конвейеры данных, аналитика больших объемов и узлы, которые могут генерировать десятки гигабит трафика.

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

При 100GbE особенно важно считать всю цепочку. Сетевой адаптер не поможет, если коммутатор не справляется с буферами, uplink перегружен, кабели выбраны неправильно, CPU тратит слишком много ресурсов на обработку пакетов, слот PCIe ограничивает карту или хранилище не отдает данные с нужной скоростью. Один поток также может не заполнить 100GbE без правильной настройки приложения, протоколов и параллельности.

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

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

Резервное копирование часто недооценивают, потому что оно считается фоновой задачей. Но именно backup может первым показать, что сети не хватает. Важно считать не только объем данных, но и окно копирования, параллельность задач, сжатие, дедупликацию, шифрование и скорость восстановления.

Если нужно передать 5 ТБ за 8 часов, средняя скорость без запаса составит около 174 МБ/с. Для 10GbE это не проблема, если канал не занят другими тяжелыми потоками. Если нужно передать 15 ТБ за 6 часов, получится около 694 МБ/с без запаса. Это уже заметная нагрузка на 10GbE, особенно если параллельно идут пользовательские задачи, репликация или хранилище.

Если объем составляет 30 ТБ, а окно всего 4 часа, нужна скорость около 2,1 ГБ/с без запаса. В таком сценарии 10GbE уже мало, а 25GbE становится разумным минимумом. Если нужно не только копировать, но и быстро восстанавливать десятки виртуальных машин, сеть нужно считать по сценарию восстановления тоже.

Документация Veeam по backup proxy отдельно подчеркивает важность расположения proxy ближе к источнику данных и достаточного канала между proxy и репозиторием. Там же предусмотрены механизмы ограничения сетевого трафика, потому что резервное копирование может забирать значительную часть пропускной способности.

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

Расчеты для миграции виртуальных машин

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

Если виртуальная машина имеет 128 ГБ памяти и ее нужно перенести за 10 минут, понадобится около 213 МБ/с без запаса. Для 10GbE это обычно посильно. Если ВМ имеет 512 ГБ памяти и ее нужно перенести за те же 10 минут, понадобится уже около 853 МБ/с без учета изменяющихся страниц. Это близко к практическому пределу 10GbE при реальной инфраструктурной нагрузке.

Если одновременно переносятся четыре ВМ по 512 ГБ за 15 минут, суммарная скорость составит около 2,3 ГБ/с без запаса. Здесь 10GbE уже не подходит, а 25GbE становится более реалистичным вариантом. Если при этом идут резервные копии, репликация или активный трафик хранилища, нужен еще больший запас или разделение сетей.

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

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

Расчеты для трафика хранилища

Трафик хранилища отличается от обычной передачи файлов. Здесь важны не только гигабайты в секунду, но и задержка, стабильность, потери пакетов и поведение при перегрузке. Для iSCSI, NFS, SMB, NVMe-oF и распределенных хранилищ сеть фактически становится частью дисковой подсистемы.

10GbE может подойти для умеренного iSCSI или NFS, если нагрузка не слишком плотная, а задержки стабильны. Но сервер с быстрыми NVMe-дисками способен генерировать поток выше 10GbE. Если несколько виртуальных хостов обращаются к сетевому хранилищу, запускают ВМ, пишут логи и одновременно попадают в окно резервного копирования, 10GbE может стать узким местом.

25GbE лучше подходит для плотной виртуализации, NVMe-серверов и хранилищ, где важен запас. 100GbE нужен для высокопроизводительных storage-кластеров, NVMe-oF, крупных Ceph-кластеров и систем, где один узел может отдавать или принимать десятки гигабит трафика.

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

Расчеты для репликации

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

Считать нужно не общий размер базы или хранилища, а объем изменений за расчетный период. Если база занимает 20 ТБ, но за час меняется 200 ГБ, расчет строится вокруг этих 200 ГБ и требуемого времени доставки изменений. Если в пиковые часы изменений становится 2 ТБ, считать по среднему дневному значению опасно.

500 ГБ изменений за 1 час — это около 139 МБ/с без запаса. 3 ТБ за 2 часа — около 417 МБ/с. 10 ТБ за 2 часа — около 1,4 ГБ/с без запаса. Последний сценарий уже выходит за комфортный уровень 10GbE, особенно если канал используется не только для репликации.

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

Расчеты для пользователей и приложений

Пользователи сами по себе не всегда требуют 25 или 100GbE. Для обычного офисного приложения, веб-сервиса или учетной системы пользовательский трафик часто меньше, чем внутренние инфраструктурные потоки. 100 пользователей по 5 Мбит/с среднего трафика — это 500 Мбит/с. Даже с запасом 10GbE здесь более чем достаточно.

Но среднее значение может обмануть. Если 50 пользователей одновременно открывают файлы по 200 МБ, возникает кратковременный пик около 10 ГБ данных. Если это происходит постоянно, файловый сервер и сеть нужно считать уже по пиковому поведению. Для медиапроизводства, CAD-файлов, видео, больших выгрузок, удаленной работы с графикой и VDI трафик может быть намного тяжелее, чем в обычном офисе.

VDI требует отдельного внимания. Важны не только пользовательские сессии, но и пики входа, загрузка профилей, обновления, антивирусные проверки, обращение к хранилищу и одновременный запуск рабочих столов. В такой среде 10GbE может хватать днем, но проседать утром или во время обновлений.

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

Расчеты для AI-конвейеров данных

AI-нагрузки и конвейеры данных часто требуют передачи датасетов, логов, признаков, промежуточных результатов, моделей и ответов между хранилищем, CPU-серверами и GPU-серверами. Если ускорители простаивают в ожидании данных, покупка более мощного GPU не решит проблему. Узким местом может быть сеть, хранилище или обработка данных до передачи в модель.

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

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

NVIDIA публикует материалы по сетевому планированию для AI- и storage-нагрузок, где высокоскоростная сеть рассматривается как часть общей платформы, а не как второстепенный канал передачи файлов. NVIDIA

Для таких сценариев полезно считать не только объем датасета, но и частоту его чтения, число параллельных задач, размер батчей, скорость хранилища, загрузку GPU, очереди и время простоя ускорителей. Если GPU стоит дорого, сеть, которая не дает ему простаивать, может быть экономически оправданной.

Рост нагрузки и запас

Сеть нельзя считать впритык. Даже если сегодня 10GbE хватает, через год могут появиться новые виртуальные машины, репликация, NVMe-хранилище, другой режим backup, больше пользователей или AI-сервис. Данные часто растут быстрее, чем число сотрудников, а окна резервного копирования со временем не расширяются, а сокращаются.

Для обычных серверов стоит оставлять минимум 30–50% свободной полосы. Для инфраструктурных задач лучше считать запас до двух раз. Это не избыточная осторожность, а защита от пересечения пиков. Резервное копирование, миграция ВМ, репликация и обслуживание баз могут совпасть по времени, даже если каждую задачу отдельно рассчитывали как приемлемую.

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

Когда достаточно 10GbE, а когда нужны 25/40/100GbE

Эта таблица не заменяет расчет. Она помогает быстро понять направление. 10GbE может быть достаточно для сервера приложений и недостаточно для хоста виртуализации с активным хранилищем. 25GbE может быть оптимальным для одного узла и слабым для магистрального соединения. 100GbE может быть избыточным для пользователей и необходимым для обмена между серверами.

Отдельные сети или общий канал

Разделение трафика — не только вопрос безопасности, но и вопрос предсказуемости. Управление, пользователи, хранилище, миграции, резервное копирование и репликация имеют разный профиль. Пользовательский трафик чувствителен к задержкам в рабочее время. Backup может занимать канал долго и агрессивно. Хранилище не любит потери и всплески задержки. Миграции виртуальных машин дают короткие, но тяжелые пики.

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

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

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

Коммутатор, кабели, оптика и PCIe тоже считаются

Сетевая карта сервера не решает задачу сама по себе. Если сервер получил 100GbE, но подключен к коммутатору с перегруженным uplink, реальной пользы может быть мало. Если ToR-коммутатор имеет высокий oversubscription, несколько серверов могут одновременно упереться в общий выход. Если буферы коммутатора малы, при пиках появятся потери пакетов и повторы.

Кабели и оптика тоже важны. Для 25/40/100GbE нужно заранее проверить типы трансиверов, совместимость с коммутатором, длину линий, энергопотребление и тепловыделение. DAC-кабели удобны на коротких расстояниях внутри стойки, оптика нужна для больших расстояний, но стоит дороже и требует аккуратного подбора.

PCIe может стать скрытым ограничением. Для 100GbE нужна подходящая пропускная способность слота, правильное поколение PCIe и достаточное число линий. Если в сервере уже стоят GPU, NVMe-контроллеры и другие платы, сетевой адаптер может оказаться не в оптимальном слоте или делить ресурсы с другими устройствами.

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

Матрица расчета по типам трафика

Как понять, что текущей сети уже не хватает

1. Порт часто загружен выше 70–80% в рабочие или инфраструктурные пики. Но смотреть нужно не только среднее значение. Важны p95 и p99, то есть верхние процентили, которые показывают поведение в тяжелые моменты. Если средняя загрузка низкая, а в короткие окна канал забивается полностью, пользователи все равно будут видеть задержки.
2. Резервное копирование не помещается в окно. Если backup должен завершаться до начала рабочего дня, но регулярно заходит в рабочее время, сеть может быть одной из причин. То же самое относится к восстановлению: копии могут создаваться нормально, но восстановление больших ВМ или файловых массивов занимает слишком много времени.
3. Миграции виртуальных машин идут дольше ожидаемого или заметно влияют на другие сервисы. Если во время миграции падает скорость работы приложений, значит трафик конкурирует за канал или хранилище.
4. Хранилище показывает задержки, хотя диски и контроллеры не выглядят перегруженными. В этом случае нужно смотреть сеть: потери, повторы, очереди, буферы коммутатора, загрузку интерфейсов и uplink.
5. PU тратит заметную долю ресурсов на сетевой стек, а приложение при этом не достигает ожидаемой скорости. Это особенно важно на 25/100GbE, где неправильные драйверы, прошивки и настройки могут ограничить реальную передачу.

Для AI и аналитики важный сигнал — простой ускорителей или вычислительных задач в ожидании данных. Если GPU загружен неравномерно, а очередь данных идет из сетевого хранилища, проверять нужно не только модель, но и сеть, storage и подготовку данных.

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

• Самая частая ошибка — считать только пользовательский трафик. Внутренние задачи сервера часто тяжелее: резервное копирование, восстановление, миграции, репликация, хранилище и обмен между узлами.
• Считать по среднему, а не по пикам. Сеть может быть свободной 20 часов в сутки и перегруженной в те 30 минут, когда бизнесу особенно важна скорость.
• Думать, что 2×10GbE всегда равно 20GbE. Для нескольких потоков это может быть близко к правде, но один поток часто не ускоряется так, как ожидают.
• Смешивать хранилище и резервное копирование в одном канале без запаса. Backup может забрать полосу именно тогда, когда виртуальные машины активно обращаются к дискам.
• Игнорировать uplink коммутатора. Серверы могут иметь быстрые порты, но если несколько узлов сходятся в слабый uplink, узкое место просто перемещается выше.
• Покупать 100GbE-карту без проверки коммутатора, кабелей, оптики, PCIe, драйверов и охлаждения. На таких скоростях вся цепочка должна соответствовать задаче.
• Забывать про задержку и потери. Для хранилища и синхронной репликации широкий канал с нестабильной задержкой может быть хуже более предсказуемой сети.
• Не учитывать рост данных. Сегодня 10GbE хватает, потому что backup занимает 3 часа. Через год объем вырастает вдвое, окно остается тем же, и сеть становится ограничением.
• Считать репликацию по полному объему базы, а не по объему изменений. Или наоборот — считать по среднему объему изменений, игнорируя пиковые часы.
• Не проверять реальную скорость приложения. Синтетический тест канала полезен, но он не всегда показывает, как поведут себя база, хранилище, ВМ или AI-конвейер.

Как выбрать скорость сети

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

Затем нужно посчитать объемы и окна передачи. Сколько данных нужно скопировать? За сколько часов? Сколько виртуальных машин может мигрировать одновременно? Какой объем изменений реплицируется за час? Сколько данных читает AI-конвейер? Какой поток идет к хранилищу в рабочее время?

После этого нужно сложить одновременные задачи. Если резервное копирование, репликация и миграция не пересекаются, их можно считать отдельно. Если они могут идти одновременно, сеть рассчитывается по сумме. К полученному значению нужно добавить запас: минимум 30–50%, а для инфраструктурных потоков часто ближе к двум.

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

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

Затем проверяются коммутаторы, uplink, кабели, оптика, сетевые карты, PCIe, драйверы и прошивки. Нет смысла ставить быстрый адаптер в сервер, если остальная инфраструктура не готова.

После этого выбирается скорость. 10GbE подходит для умеренных серверов и задач без тяжелого внутреннего трафика. 25GbE — хороший выбор для современных узлов виртуализации, backup, репликации, NVMe и плотных серверов. 40GbE оправдан, если инфраструктура уже построена вокруг него. 100GbE нужен для storage-кластеров, AI-конвейеров, высокоплотной виртуализации, магистралей и узлов, которые реально способны генерировать десятки гигабит трафика.

Финальную оценку лучше проверять тестами. Нужно смотреть не только скорость копирования большого файла, но и задержку, потери, повторы, загрузку CPU, поведение приложения, длительность backup/restore, миграции ВМ и работу хранилища под нагрузкой.

Что выбрать в итоге

10GbE остается нормальным вариантом для многих серверов, если нет тяжелого внутреннего трафика, коротких окон резервного копирования, активного хранилища по сети, массовых миграций и AI-конвейеров. Это рабочий минимум для одиночных серверов, умеренной виртуализации, обычных приложений и файловых сервисов без постоянной передачи больших объемов.

25GbE часто оказывается самым рациональным современным выбором для серверов, которые должны жить несколько лет и выдерживать рост. Он дает запас для виртуализации, NVMe, репликации, backup и более плотной нагрузки, но не требует сразу переходить на сложность 100GbE.

40GbE имеет смысл, если такая инфраструктура уже есть и хорошо вписывается в текущую сеть. Для новых проектов его нужно сравнивать с 25 и 100GbE, а не выбирать автоматически.

100GbE нужно там, где сеть напрямую влияет на производительность платформы: в распределенном хранилище, AI/data pipelines, крупных кластерах, быстрой репликации, магистральных соединениях и высокоплотной виртуализации. Но такой порт требует готовности всей цепочки — от сетевой карты и PCIe до коммутатора, кабелей, uplink, драйверов и настроек ОС.

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