Как выбрать сетевую карту для сервера

Сетевую карту для сервера часто выбирают по остаточному принципу: смотрят на цифру в спецификации, берут «побыстрее» или, наоборот, экономят, считая NIC второстепенным компонентом. На практике именно здесь легко получить скрытое узкое место: упереться в PCIe, перегрузить CPU обработкой пакетов, потерять гибкость в виртуализации, столкнуться с несовместимостью трансиверов или переплатить за функции, которые так и не будут использоваться. Правильный выбор серверного NIC — это не поиск самой высокой скорости, а согласование сетевого интерфейса с ролью сервера, типом трафика, платформой, гипервизором и физической средой подключения.

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

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

В сервере сеть может быть реализована по-разному. Самый базовый вариант — встроенный LOM или OCP NIC, уже установленный на плате или в выделенном слоте формата OCP. Это нормально для многих типовых задач: management, обычные сервисы, умеренный east-west трафик, резервный uplink, тестовые среды. Если сервер не упирается в сеть, не работает как гипервизор, не обслуживает storage-трафик и не требует особых функций, встроенного интерфейса часто достаточно.

PCIe-адаптер нужен тогда, когда встроенных портов не хватает по скорости, количеству, типу подключения или функциональности. Это типичный случай для виртуализации, SDS, бэкап-серверов, кластеров, систем с высокой плотностью виртуальных машин, серверов с большим количеством SSD или с особыми требованиями к latency и PPS. Отдельный NIC также нужен, когда необходимо развести типы трафика, построить отказоустойчивое подключение к двум коммутаторам или использовать интерфейсы, которых у базовой платформы просто нет.

SmartNIC и DPU — уже не просто сетевые карты, а специализированные устройства, способные разгружать часть сетевой, storage- и security-логики. Они уместны там, где есть multitenancy, сложные overlay-сети, жёсткие требования к изоляции и высокая цена CPU-циклов. Для обычного корпоративного сервера это чаще всего избыточно: выше цена, сложнее эксплуатация, больше зависимостей от экосистемы. Если задача не требует именно разгрузки инфраструктурных функций, «обычный» серверный NIC остаётся более рациональным выбором.

Иногда правильный ответ — не менять карту, а пересмотреть сетевой дизайн. Если серверу хронически не хватает пропускной способности, но причина в неудачном разделении трафика, плохом ToR oversubscription, неверной NUMA-привязке или в том, что storage и production сидят на одном uplink, новая карта сама по себе проблему не решит.

Сначала — профиль нагрузки, а уже потом скорость и форм-фактор

Главная ошибка при выборе NIC — считать, что все серверные нагрузки «одинаково любят гигабиты». На практике разные сценарии предъявляют совершенно разные требования.

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

Для хостов виртуализации важнее не только bandwidth, но и многоканальность, зрелость драйверов, поддержка SR-IOV, корректная работа с vSwitch/OVS и нормальная интеграция с гипервизором. Если на одном хосте много VM и плотный east-west трафик, сеть быстро становится таким же критичным ресурсом, как CPU и RAM.

Для storage-нагрузок нужно разделять протоколы. iSCSI и NFS могут прекрасно жить без RDMA, если сеть спроектирована аккуратно и нет требований к минимальному CPU overhead. SMB Direct, HPC и часть SDS-сценариев, наоборот, могут заметно выиграть от RDMA. Для Ceph и других распределённых систем важны не только гигабиты, но и задержка, размер пакетов, предсказуемость поведения под одновременной нагрузкой на сеть, CPU и диски.

Backup, репликация и другие large sequential transfer-нагрузки обычно throughput-ориентированы. Здесь чаще важнее широкая полоса и разумная стоимость порта, чем минимально возможная задержка. Для таких задач 10GbE или 25GbE часто дают лучший баланс, чем погоня за 100GbE в одиночном порту.

HPC, AI-кластеры и низколатентные межузловые взаимодействия — уже другой класс. Здесь на выбор NIC влияют задержка, tail latency, качество драйвера, поддержка RDMA, NUMA-локальность и иногда даже топология PCIe относительно GPU. В packet-processing сценариях — firewall, IDS/IPS, edge-router, телеком — часто важнее не гигабиты как таковые, а количество пакетов в секунду, очереди, steering и поддержка нужного datapath.

Именно поэтому перед выбором карты надо ответить на три базовых вопроса: сервер упирается в пропускную способность, в задержку или в packet rate? От этого меняется вся логика подбора.

Скорость порта: почему больше — не всегда лучше

На бумаге всё просто: 1, 10, 25, 40, 50, 100, 200GbE. На практике эти цифры — только верхняя граница линии, а не гарантированная полезная производительность приложений. Реальная отдача всегда ниже из-за накладных расходов протоколов, особенностей размера пакетов, характера нагрузки, работы очередей, прерываний и самого программного стека.

25GbE в последние годы стал особенно важным серверным классом. Это не просто «чуть быстрее 10G», а более рациональный шаг для новых серверных развёртываний: лучшее соотношение между плотностью, масштабируемостью и современным сетевым дизайном, чем у 10GbE, особенно там, где сервер уже работает с SSD/NVMe, виртуализацией и активным east-west трафиком. Ethernet Alliance прямо показывает 25GbE как один из ключевых и устойчивых серверных скоростных классов, а более высокие скорости развиваются уже поверх той же логики плотности и масштабирования.

40GbE сегодня чаще встречается как наследуемый или переходный вариант. Для новых построений он нередко уступает по практичности 25GbE и 100GbE: либо слишком «старый» по экосистеме, либо не даёт того баланса, который проще получить через 2×25GbE или через 100GbE там, где это действительно нужно.

100GbE оправдан там, где у сервера реально есть чем насытить канал: несколько быстрых NVMe, плотная виртуализация, storage-node, высокопроизводительный бэкап, AI/HPC или значительный агрегированный east-west трафик. Если же реальная нагрузка умеренная, uplink коммутатора всё равно ограничен, а PCIe-ресурсы сервера скромные, 100GbE легко превращается в дорогую галочку без практической отдачи.

Наконец, есть важный нюанс: для многих задач 2×25GbE практичнее, чем 1×100GbE. Два порта позволяют развести трафик, построить отказоустойчивость, работать с двумя коммутаторами и получить более гибкую схему масштабирования. Один очень быстрый порт хорош там, где действительно нужен единый широкий поток. Во всех остальных случаях полезнее смотреть на архитектуру, а не на максимальную цифру.

Какой класс скорости обычно подходит под разные сценарии

Если нужно быстрое правило: 10GbE — всё ещё нормальный минимум для множества корпоративных серверных задач; 25GbE — наиболее рациональный современный выбор для новых универсальных серверов; 100GbE — инструмент для действительно тяжёлых, плотных и требовательных нагрузок, а не универсальный ответ «на вырост».

Сколько портов нужно: один, два или четыре

Количество портов — это не вопрос удобства, а вопрос дизайна. Один порт уместен там, где сервер не критичен, сеть не является узким местом, а отказоустойчивость обеспечивается другими слоями. Это может быть тестовый узел, отдельный сервис, management-хост или сервер с внешне простой ролью.

Два порта — самый практичный серверный компромисс. Такая схема позволяет сделать active-backup, LACP, dual-switch uplink, развести production и storage либо management и рабочий трафик. Для большинства серьёзных инсталляций именно два порта дают лучший баланс между надёжностью, гибкостью и стоимостью.

Четыре порта нужны тогда, когда это действительно оправдано архитектурой: несколько независимых сетей, legacy-среда, большое число изолированных плоскостей, специфические требования к разделению трафика. Но многопортовый адаптер — не всегда благо. Чем выше портовая плотность, тем выше требования к PCIe, охлаждению и планированию кабельной схемы. Иногда разумнее взять два более быстрых порта и использовать VLAN-ы, чем четыре медленных, особенно если сервер уже ограничен по слотам и тепловому бюджету.

RJ45, SFP, DAC, AOC, оптика: где чаще всего допускают ошибки

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

SFP+ и SFP28 чаще оказываются более серверным выбором. Они лучше подходят для 10/25GbE, дают больше гибкости по среде подключения и обычно лучше вписываются в современные стойки. DAC логичен на коротких дистанциях внутри стойки или между соседними стойками: дёшево, просто, низкая задержка. AOC и оптика нужны там, где расстояния больше, требования к помехоустойчивости выше или кабельная архитектура уже оптическая.

Для 100G и выше обычно начинаются QSFP-классы. Здесь ошибки особенно дороги: можно купить правильную по скорости карту, но потерять деньги на неподходящих модулях, столкнуться с ограничениями по совместимости с коммутатором или упереться в vendor-lock по оптике и прошивкам. Поэтому NIC никогда не стоит выбирать в отрыве от всей физической схемы: карта, трансивер, кабель, порт коммутатора и политика совместимости должны рассматриваться как единый комплект.

PCIe: узкое место, которое ломает красивые спецификации

Даже идеальная сеть не поможет, если адаптер не может отдать свою производительность через PCI Express. Для серверного NIC это критично: важны поколение PCIe, число линий, реальная разводка слота и то, с чем этот слот делит ресурсы на платформе. PCI-SIG прямо указывает, что спецификации PCIe определяют совместимость и параметры взаимодействия периферийных устройств с платформой, а значит для сетевых адаптеров пропускная способность и возможности конкретного слота — это не формальность, а часть итоговой производительности.

Именно поэтому 100GbE-карта может «не раскрыться» в неправильном слоте. Формально она установится и будет работать, но фактически упирается в доступную полосу, в слотовую разводку, в деление линий с NVMe, GPU или HBA. Чем плотнее сервер по ускорителям и накопителям, тем чаще сеть конкурирует за те же PCIe-ресурсы.

Отдельная тема — NUMA. Если NIC подключён к сокету, на котором не выполняется основной сетевой стек, не размещены соответствующие VM, контейнеры или приложения, вы получаете лишние межсокетные переходы. Это увеличивает задержку, добавляет CPU overhead и ухудшает предсказуемость под нагрузкой. В реальной серверной эксплуатации это часто влияет сильнее, чем разница между близкими классами скоростей.

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

Аппаратные функции: какие offload действительно важны

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

Базовые функции вроде checksum offload давно воспринимаются как норма. Дальше начинаются более важные для серверов вещи: TSO, GRO, GSO, multiqueue, interrupt moderation, steering. Один из самых полезных механизмов — RSS: он распределяет входящий трафик по нескольким аппаратным очередям и позволяет обрабатывать его на нескольких CPU, а не упираться в одно ядро. Red Hat прямо описывает RSS как способ разгрузить bottleneck на receive path и снизить сетевую задержку при перегрузке одного CPU.

Но offload не надо воспринимать как абсолютное благо. В части latency-чувствительных сценариев некоторые механизмы могут ухудшать предсказуемость поведения или затруднять диагностику. Иногда ради контроля tail latency, прозрачной отладки или узкоспециализированного datapath часть функций осознанно отключают. Поэтому вопрос должен звучать не «поддерживает ли карта максимум offload’ов», а «какие из них реально полезны моему стеку и профилю нагрузки».

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

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

SR-IOV часто подают как обязательную функцию для «правильного» серверного NIC, но это не так. Microsoft описывает SR-IOV как механизм, при котором часть сетевого трафика может обходить программный switch-слой Hyper-V, снижая I/O overhead и приближая производительность к невиртуализованной. Это действительно полезно там, где нужен прямой и быстрый путь к виртуальным функциям. Но у SR-IOV есть цена: меньше гибкости, ограничения в некоторых сценариях миграции и эксплуатации, более жёсткие требования к BIOS, IOMMU, гипервизору и общей архитектуре.

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

RDMA, RoCEv2 и SMB Direct: когда нужен другой класс требований

RDMA имеет смысл только тогда, когда вы понимаете, зачем он нужен. Это не универсальная «ускорялка сети», а специализированный механизм, снижающий участие CPU и уменьшающий накладные расходы на передачу данных в определённых типах workloads. Он реально полезен для HPC, AI, SMB Direct, отдельных storage-сценариев и там, где межузловой обмен критичен по задержке и эффективности.

RoCEv2 особенно важен тем, что работает в L3/IP-среде: NVIDIA описывает его как расширение RoCE с IP- и UDP-инкапсуляцией, позволяющее трафику проходить через маршрутизируемые IP-сети. Это делает его практичнее в ряде реальных Ethernet-инфраструктур, чем ранние более ограниченные варианты.

Но RDMA нельзя выбирать «про запас». Если сеть не подготовлена, QoS и приоритезация не продуманы, стек и приложения не умеют это использовать, а эксплуатационная команда не планирует поддерживать такую среду, включение RDMA приносит не выгоду, а сложность. Для многих обычных серверов iSCSI, NFS или виртуализации без специальных low-latency требований хороший классический Ethernet NIC оказывается более рациональным, чем дорогой адаптер с RDMA-функциями, которые никогда не будут задействованы.

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

Задержка и CPU overhead: то, что часто важнее «скорости на коробке»

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

Задержка зависит не только от самой линии, но и от драйвера, очередей, interrupt coalescing, NUMA, размера пакетов, выбранных offload’ов и общей PCIe-топологии. Для web, file-сервисов и бэкапов это не всегда ключевой фактор. Но для trading, распределённых БД, RPC, replication, real-time analytics и части storage-сценариев уже важна не только средняя задержка, но и хвосты — p99 и p99.9. Именно там «вроде бы одинаковые» карты начинают различаться по-настоящему.

Если задача чувствительна к latency, смотрят не на пиковый throughput, а на предсказуемость: как адаптер ведёт себя при росте PPS, как работает распределение очередей, как он привязан к сокету, насколько стабилен драйвер в реальной ОС и не создаёт ли выбранная конфигурация скрытых межсокетных переходов.

PTP и аппаратная timestamping: нишевая функция, которую нельзя добавлять задним числом

Для большинства серверов PTP и аппаратные временные метки не являются обязательными. Но если речь идёт о телеком-сценариях, промышленной автоматике, высокоточной синхронизации, финансовых системах или high-precision logging, это уже не «дополнительная опция», а часть базовых требований.

Аппаратная timestamping и PTP-поддержка завязаны на возможности самого сетевого устройства и его драйвера, а наличие аппаратного PTP clock — отдельная важная характеристика для точной синхронизации. Иными словами, если такая функция нужна, её нужно проверять на этапе выбора карты и стека, а не надеяться, что потом «как-нибудь включится».

DPDK, XDP и AF_XDP: когда важны не гигабиты, а пакеты в секунду

Сервер, который работает как virtual router, firewall, IDS/IPS, edge-шлюз или телеком-узел, оценивает NIC иначе. Здесь главный вопрос — сколько пакетов в секунду можно обработать без развала по CPU и latency, а не какую максимальную скорость указывает спецификация.

В таких задачах критичны очереди, steering, качество драйвера, поддержка нужного datapath и нормальная интеграция с DPDK, XDP или AF_XDP. Карта с красивой маркетинговой скоростью, но слабой экосистемой или плохой предсказуемостью под мелкопакетной нагрузкой, может уступить более «скромному» по цифрам адаптеру, который лучше подходит под ваш стек. Поэтому packet processing — это всегда выбор по софту и архитектуре, а не только по Ethernet-классу.

Совместимость важнее красивой спецификации

Один из самых дорогих промахов — купить технически «подходящую» карту, которая плохо живёт в вашей реальной среде. Для сервера важно не только то, что NIC вообще определяется системой. Важно, есть ли зрелый драйвер под нужную версию Linux или Windows Server, нормально ли адаптер поддерживается в Hyper-V, VMware, KVM, Proxmox, как часто выходят прошивки, есть ли нормальные утилиты диагностики и насколько предсказуемо устройство ведёт себя после обновлений.

«Работает» и «работает стабильно под реальной многомесячной нагрузкой» — не одно и то же. Именно зрелость экосистемы часто отличает хороший серверный NIC от просто совместимого железа. Поэтому до покупки надо проверить поддерживаемые версии ОС, доступность драйверов, known issues, рекомендации вендора платформы и наличие нормального lifecycle у прошивки.

Отказоустойчивость: её создаёт схема, а не сама карта

Наличие двух портов ещё не означает высокой доступности. Отказоустойчивость появляется только тогда, когда продумана вся схема: active-backup или LACP настроены корректно, uplink’и разведены по разным коммутаторам, роли трафика логично разделены, а отказ одного компонента не оставляет сервер без доступа.

Очень частая ошибка — считать, что двухпортовый NIC автоматически решает вопрос HA. Если оба порта идут в один коммутатор, в один модуль или через одну критичную точку, это не отказоустойчивость, а иллюзия резерва. Для production, storage и management лучше заранее понимать, какая именно цель у нескольких портов: резерв, агрегация или изоляция потоков. От этого зависит и класс карты, и тип кабельной среды, и общая логика выбора.

Другая частая ошибка - это взять два адаптера 10GbE для iSCSI, собрать их в LACP и считать что производительность будет 20GbE, а это не так. Для увеличения скорости работы iSCSI лучше использовать MPIO, поэтому при проектировании также нужно учесть не только сетевой уровень, но и прикладной.

Энергопотребление, нагрев и плотность: особенно важно в 1U и плотных шасси

Чем быстрее NIC, тем чаще он становится ещё и заметным источником тепла. Это касается не только самой карты, но и трансиверов, особенно оптики и отдельных вариантов Base-T. В плотных 1U/2U серверах даже лишние 10–20 Вт на карту и модули могут быть разницей между «конфигурация проходит в прод» и «шасси работает на неприятно высоких оборотах, с ухудшением акустики и thermal margin, сваливаясь в троттлинг по дискам и CPU».

Поэтому при апгрейде сети проверяют не только наличие слота, но и тепловой бюджет шасси, airflow именно в зоне этого слота, ограничения по длине/типу карт и поведение платформы с полной нагрузкой по CPU, накопителям и сети одновременно. Иногда с инженерной точки зрения лучше более энергоэффективный 25GbE-класс с правильной кабельной схемой, чем попытка «впихнуть» более быстрый адаптер в сервер, который для этого не рассчитан.

SmartNIC и DPU: где это действительно оправдано

SmartNIC и DPU оправданы там, где есть реальная потребность разгружать overlay-сети, фильтрацию, storage-пути, multi-tenant изоляцию или инфраструктурные функции облачного класса. В такой среде цена CPU-циклов высока, сетевой стек сложен, а плотность нагрузки делает вынос части логики на отдельное устройство рациональным.

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

Как выбирать NIC по типовым сценариям

Если нужен универсальный сервер приложений, web или внутренний сервис без экстремального трафика, обычно достаточно 1/10GbE, а в новой инфраструктуре часто разумно сразу закладывать 10GbE с запасом по нормальной многолетней эксплуатации. Здесь важнее совместимость, драйвер, стабильность и отсутствие лишних сюрпризов.

Для хоста виртуализации среднего масштаба чаще всего оптимален двухпортовый 10/25GbE-адаптер. Если среда типовая, без жёстких низколатентных требований, важнее зрелая экосистема и корректная работа с гипервизором, чем максимум «ускоряющих» функций. На SR-IOV стоит смотреть только там, где вы действительно понимаете, зачем он нужен и какие ограничения готовы принять.

Для storage node логика зависит от профиля I/O. Если много параллельных потоков, быстрые SSD/NVMe и активный сетевой обмен, 25GbE уже выглядит базовым серьёзным уровнем, а 100GbE оправдан там, где сервер действительно способен его нагрузить. RDMA имеет смысл только при подходящем протоколе и готовой сети.

Для backup server приоритет — throughput и разумная стоимость полосы. Здесь часто лучше широкий, но прагматичный канал без избыточных «спецфункций». Переплата за latency-ориентированные возможности обычно не даёт выгоды.

Для AI/HPC node картой управляет уже не только сеть, но и вся архитектура узла: GPU, PCIe, NUMA, межузловой протокол, требование к RDMA. Здесь ошибка в выборе NIC особенно болезненна, потому что она влияет не только на сеть, но и на эффективность всей вычислительной системы.

Для firewall, packet processing и IDS/IPS нужна карта с хорошими очередями, предсказуемым драйвером, корректной поддержкой нужного datapath и нормальным поведением на мелких пакетах. В таком сервере легко переплатить за «большие гигабиты», но всё равно упереться в PPS.

Для небольшого edge-сервера и branch-инфраструктуры выбор часто ограничивают не сеть, а power/thermal, простота эксплуатации и стоимость. Здесь медные 1GbE или 10GbE нередко оказывается правильнее, чем погоня за серверной «модой».

Для high-availability инфраструктурного узла почти всегда важнее не скорость сама по себе, а грамотно построенная схема резервирования, минимум два логически независимых uplink’а и аккуратное разделение ролей трафика.

Типичные ошибки при выборе серверного NIC

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

Не проверяют PCIe-слот, число линий и привязку к сокету, а потом получают карту, которая формально установлена, но работает в ограниченном режиме. Покупают RJ45 по привычке, хотя в конкретной стойке логичнее SFP28 и DAC-«гидры». Берут RDMA «на будущее», хотя сеть, приложения и команда к нему не готовы. Игнорируют совместимость трансиверов и внезапно переплачивают не за NIC, а за неудачную оптическую схему.

Ещё одна типичная ошибка — считать, что любые offload-функции автоматически полезны. В реальной эксплуатации важна не галочка в спецификации, а эффект в вашем стеке. И наконец, очень дорогой промах — брать самый дешёвый адаптер без нормального driver lifecycle, особенно если сервер живёт в виртуализации, storage или production-нагрузке.

Что проверять перед покупкой

Чек-лист перед покупкой

Перед тем как заказывать карту, стоит пройти по короткому списку:

• Какой у сервера профиль трафика: пропускная способность, задержка или PPS?
• Какая реальная, а не теоретическая, требуемая скорость нужна этому узлу?
• Сколько портов действительно нужно и зачем каждый из них нужен?
• Какой тип физического подключения будет использоваться: RJ45, DAC, AOC, оптика?
• Совместима ли карта с существующим коммутатором и трансиверами?
• Хватает ли PCIe-линий, и подходит ли конкретный слот по поколению и ширине?
• К какому сокету привязан слот, если для вас важны latency и NUMA?
• Нужны ли вам на практике SR-IOV, RDMA, PTP или это лишние функции?
• Есть ли полноценная поддержка в вашей ОС и гипервизоре?
• Есть ли у адаптера зрелые драйверы, прошивки и инструменты диагностики?
• Укладывается ли карта вместе с модулями в thermal/power budget сервера?
• Не платите ли вы за функции, которыми среда не будет пользоваться?

Вывод

Выбор серверной сетевой карты — это всегда баланс между задачей, типом трафика, возможностями платформы, совместимостью, физической средой подключения и требованиями к задержке, виртуализации и storage. Хороший NIC не обязан быть самым быстрым, самым дорогим или самым «навороченным». Он должен быть согласован со всей системой.

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