У большинства физических серверов есть не один сетевой разъём, а два, четыре или даже больше. На первый взгляд кажется, что причина проста: дополнительные порты нужны ради скорости. Если один интерфейс работает на 1 Гбит/с, два якобы должны дать 2 Гбит/с, четыре — 4 Гбит/с. В реальной инфраструктуре всё немного сложнее. Второй сетевой порт часто устанавливают не для того, чтобы один файл скачивался в два раза быстрее, а ради резервирования, разделения сетей или объединения нескольких физических соединений в одну логическую группу.
Для обычного сайта один исправный гигабитный интерфейс способен годами оставаться полностью достаточным. Но физический сервер часто арендуют именно тогда, когда требования к инфраструктуре становятся серьёзнее. На машине может работать интернет-магазин, база данных, несколько виртуальных серверов, внутренняя сеть или сервис, простой которого приносит бизнесу реальные потери. В такой ситуации зависеть от единственного сетевого интерфейса и единственного кабеля уже не всегда разумно.
Именно здесь появляются bonding, LACP, резервные сетевые интерфейсы и подключение сервера к нескольким коммутаторам. Эти технологии решают разные задачи, и наличие двух разъёмов на корпусе само по себе ещё не означает, что сервер защищён от сетевого сбоя.
Самый простой вариант использования двух портов — держать один из них в резерве. Сервер работает через первый интерфейс, а второй готов принять трафик, если основное подключение перестанет работать. Такая схема особенно полезна там, где отказ одного сетевого адаптера, кабеля или порта коммутатора не должен автоматически делать сайт недоступным.
На Linux несколько физических интерфейсов можно объединить в логический интерфейс с помощью bonding. Операционная система видит условный bond0, а внутри него находятся, например, eno1 и eno2. Приложению, веб-серверу или базе данных обычно не нужно знать, какой именно физический порт в данный момент передаёт трафик.
Bonding поддерживает несколько режимов работы. В одном режиме активен только один интерфейс, а второй находится в резерве. Если система обнаруживает проблему основного подключения, трафик переключается на запасной. Такой вариант часто называют active-backup.
Для сайта эта схема привлекательна своей простотой. Не нужно пытаться распределять каждое соединение между несколькими портами. Основная задача заключается именно в том, чтобы пережить отказ одного физического сетевого пути.
Но здесь важно понимать слово путь. Если оба кабеля от сервера подключены к одному и тому же коммутатору, схема защищает от поломки сетевого порта сервера, кабеля или конкретного порта коммутатора, но не от отказа всего коммутатора.
Представим сервер с двумя сетевыми картами. Первый кабель подключён в порт 10 коммутатора, второй — в порт 11 того же устройства. При повреждении первого кабеля резервирование сработает. При выходе из строя коммутатора оба соединения исчезнут одновременно.
Поэтому серьёзное сетевое резервирование строится так, чтобы физические пути были действительно независимыми. Один интерфейс подключается к одному коммутатору, второй — к другому. Дальше уже сама сеть дата-центра должна иметь соответствующую архитектуру, позволяющую пережить отказ одного устройства.
Bonding не всегда нужен ради скорости
Один из самых распространённых мифов заключается в том, что два гигабитных порта автоматически превращаются в один канал 2 Гбит/с. Теоретически агрегированная группа действительно может получить большую суммарную пропускную способность. Но это не означает, что одно отдельное соединение начнёт передавать данные в два раза быстрее.
Представим физический сервер с двумя портами по 1 Гбит/с. Они объединены в группу, которая способна одновременно использовать оба соединения. На сервер приходит сто независимых пользователей. Часть их соединений может идти через первый интерфейс, часть через второй. В результате суммарный сетевой поток способен превысить возможности одного гигабитного порта.
Но если один пользователь скачивает один большой файл через одно TCP-соединение, оно обычно будет привязано к одному физическому каналу. Его скорость останется ограниченной примерно возможностями одного порта.
Это делается не случайно. Если пакеты одного соединения бесконтрольно отправлять через несколько путей с разными задержками, они могут приходить в другом порядке, что создаёт дополнительные проблемы. Поэтому алгоритмы балансировки часто привязывают поток к определённому интерфейсу на основе MAC-адресов, IP или портов соединения.
Получается, что два порта особенно полезны для сервера, который обслуживает много независимых клиентов или сервисов одновременно. Общая пропускная способность растёт, хотя конкретный одиночный поток не обязательно ускоряется.
Для обычного сайта это часто не имеет практического значения. Если текущая сеть использует в пиковый момент 100-150 Мбит/с, объединять два гигабитных интерфейса ради пропускной способности бессмысленно. Огромная часть доступной полосы и так остаётся свободной.
В такой ситуации второй порт намного полезнее использовать для резервирования или отдельной внутренней сети.
Разделение сетей вообще является одним из самых интересных применений нескольких интерфейсов. Например, первый порт обслуживает публичный интернет, а второй подключён только к приватной сети дата-центра.
Через публичный интерфейс посетители открывают сайт. Через приватный сервер общается с базой данных, системой резервного копирования или другим физическим узлом.
Так внутренний трафик не приходится отправлять через публичную сеть. Кроме того, база данных может вообще не иметь доступного из интернета интерфейса.
Для инфраструктуры из нескольких машин это существенно упрощает безопасность. Веб-сервер доступен пользователям, а PostgreSQL принимает подключения только из закрытой сети между серверами.
Отдельный физический интерфейс также можно использовать для управления. У сервера появляется сеть для обычного пользовательского трафика и отдельная management-сеть для администрирования. В крупных инфраструктурах разделение рабочих и административных соединений является вполне обычным подходом.
Количество портов само по себе поэтому ничего не говорит о скорости сайта. Четыре сетевых интерфейса могут выполнять четыре совершенно разные роли и вообще никогда не объединяться в один канал.
Что такое LACP и зачем он нужен
LACP расшифровывается как Link Aggregation Control Protocol. Это стандартный протокол, который помогает нескольким физическим Ethernet-соединениям работать как одна логическая группа.
В Linux подобная схема может быть настроена через bonding в режиме 802.3ad. На стороне сервера создаётся агрегированный интерфейс, а на стороне сетевого оборудования соответствующие порты объединяются в LAG.
Сервер и коммутатор обмениваются служебной информацией и понимают, какие физические соединения входят в группу и находятся в рабочем состоянии.
Преимущество LACP заключается в том, что можно одновременно получить резервирование и увеличение суммарной пропускной способности. Если один кабель перестаёт работать, оставшиеся продолжают обслуживать группу. Если все соединения исправны, независимые потоки могут распределяться между ними.
Но здесь уже требуется поддержка со стороны сетевой инфраструктуры провайдера. Нельзя просто соединить два кабеля, включить LACP в Linux и рассчитывать, что всё заработает. Порты коммутатора тоже должны быть объединены соответствующим образом.
Поэтому на арендованном физическом сервере подобную схему нужно согласовывать с дата-центром или хостинг-провайдером.
Есть ещё один нюанс. Подключение двух LACP-портов к двум независимым коммутаторам возможно только в том случае, если сетевое оборудование умеет работать в соответствующей распределённой архитектуре. У разных производителей используются технологии вроде MLAG, vPC и другие варианты объединения нескольких физических устройств в единую логическую систему.
Если просто взять два полностью независимых коммутатора и подключить к каждому один кабель обычной LACP-группы без поддержки подобной схемы, нормальной работы не получится.
Поэтому истинное резервирование сети зависит не только от конфигурации сервера. Огромное значение имеет архитектура самого дата-центра.
Когда второе сетевое подключение действительно нужно сайту
Для одного обычного сайта с умеренной посещаемостью второй интерфейс редко является обязательным. Если сервер подключён к качественной сети дата-центра, а простой в несколько минут после редкой аппаратной проблемы допустим, один сетевой порт вполне способен быть рациональным выбором.
Дополнительное подключение начинает приносить реальную пользу тогда, когда доступность проекта важна настолько, что отказ одного элемента не должен останавливать сервис.
Например, крупный интернет-магазин работает круглосуточно, а каждая минута недоступности означает потерянные заказы. Сервер уже имеет RAID, резервные блоки питания и полноценное аппаратное управление. Оставлять единственный сетевой кабель становится странно: вся серьёзная аппаратная избыточность упирается в один физический Ethernet-интерфейс.
В такой ситуации два независимых подключения выглядят гораздо логичнее.
Но нужно уточнить, что именно предоставляет провайдер. Фраза два сетевых порта ещё не означает полноценную отказоустойчивость. Важно узнать, подключены ли они к разным коммутаторам и что произойдёт при отказе одного из сетевых устройств.
Хороший вопрос провайдеру звучит не есть ли второй Ethernet, а останется ли сервер доступен при отказе коммутатора, к которому подключён основной интерфейс.
Если ответ положительный, дальше уже можно разбираться, каким способом реализовано переключение.
Второй интерфейс особенно полезен в инфраструктуре с отдельной базой данных. Представим две физические машины. На первой работает приложение, на второй PostgreSQL. Публичный сетевой порт первой машины обслуживает пользователей, а второй соединён с внутренней сетью дата-центра. Сервер базы вообще может не иметь публичного доступа к своему рабочему интерфейсу.
Запросы между приложением и базой идут по приватной сети. Это уменьшает зависимость внутреннего трафика от публичной маршрутизации и позволяет проще ограничивать доступ.
Для резервного копирования тоже может использоваться отдельная сеть. Если каждую ночь сервер передаёт сотни гигабайт на другую машину, этот поток не обязательно должен конкурировать с обычным пользовательским трафиком на одном интерфейсе.
Правда, в большинстве обычных проектов гигабитный порт имеет такой запас, что разделять трафик физически ради нескольких гигабайт резервной копии нет смысла. Но для больших объёмов данных отдельное подключение становится полезнее.
Другой интересный сценарий — виртуализация. Один физический сервер может обслуживать несколько виртуальных машин. Часть сетевых интерфейсов выделяется под внешние подключения виртуальных серверов, другая используется для управления гипервизором, а отдельный канал может работать для хранилища или миграции виртуальных машин.
В такой системе несколько Ethernet-портов становятся уже не резервом на случай аварии, а необходимой частью архитектуры.
Количество и скорость интерфейсов особенно важны для серверов хранения данных. Если несколько вычислительных узлов постоянно читают большие объёмы информации с одной машины, сеть способна стать ограничением раньше процессора или дисков.
Например, массив NVMe внутри сервера способен отдавать данные со скоростью значительно выше одного гигабита. Если сетевой порт ограничен 1 Гбит/с, большая часть производительности накопителей для удалённых клиентов просто остаётся недоступной.
Тогда используют 10, 25, 40 или 100 Гбит/с подключения, а иногда несколько высокоскоростных интерфейсов одновременно.
Для обычного WordPress такой масштаб выглядит избыточным. Но сам принцип остаётся тем же: сетевую конфигурацию нужно выбирать по реальному потоку данных.
Стоит учитывать и отказ самого сетевого адаптера. В серверных материнских платах часто установлено несколько встроенных портов, а при необходимости можно добавить отдельную PCI Express сетевую карту.
Если два порта принадлежат одному физическому контроллеру, отказ самого контроллера теоретически способен затронуть оба интерфейса. Для действительно критичной инфраструктуры поэтому используют независимые сетевые адаптеры и разные пути до коммутаторов.
Обычному владельцу сайта заходить настолько глубоко в резервирование чаще всего не требуется. Но полезно понимать, что два кабеля не всегда означают два полностью независимых пути.
Надёжность определяется всей цепочкой: сетевой контроллер сервера, кабель, порт коммутатора, сам коммутатор, вышестоящее сетевое оборудование и внешние каналы дата-центра.
Если где-то в этой цепочке существует единственная общая точка отказа, два интерфейса сервера не убирают её автоматически.
Иногда несколько сетевых подключений используют ради миграции и обслуживания. Например, сервер подключают к новой сети через второй интерфейс, проверяют работу, а затем постепенно отключают старое соединение. Это позволяет менять сетевую инфраструктуру с меньшим риском полной потери доступа.
Похожий подход полезен при смене IP-схемы, переходе между VLAN или реорганизации внутренней сети.
Второй физический интерфейс также даёт страховку при ошибке администратора. Если сетевые пути настроены независимо, неудачное изменение конфигурации одного интерфейса не обязательно полностью отрезает машину. Но рассчитывать на это как на основной способ восстановления всё равно не стоит: для аварийного доступа гораздо надёжнее IPMI или IP-KVM.
При выборе сервера стоит посмотреть и на тип сетевых портов. Самая привычная конфигурация — обычный Ethernet на медных кабелях с разъёмами RJ45. На скоростях 10 Гбит/с и выше часто используются SFP+, SFP28 и другие интерфейсы с оптическими или медными модулями.
Для клиента арендованной машины эта физика обычно скрыта. Провайдер просто указывает скорость подключения. Но если требуется специфическая сеть или colocation собственного оборудования, совместимость интерфейсов уже становится важной.
Необходимо учитывать и стоимость дополнительного порта. У некоторых хостеров второй Ethernet входит в конфигурацию сервера физически, но его подключение к сети оплачивается отдельно. Может отдельно тарифицироваться и дополнительная пропускная способность.
Поэтому четыре разъёма на задней панели не означают, что клиент автоматически получает четыре активных гигабитных подключения.
Перед заказом полезно уточнить, сколько портов включено в тариф, к каким сетям они подключаются, можно ли настроить bonding или LACP и будет ли дополнительный интерфейс тарифицироваться отдельно.
Для резервирования также важно узнать, подключаются ли порты к разным коммутаторам. Если нет, второй интерфейс всё равно может защитить от отказа кабеля или порта, но не от проблем всего сетевого устройства.
Если проект критичен к простою, нужно смотреть ещё дальше и оценивать резервирование внешних операторов самого дата-центра. Два сетевых интерфейса одного сервера мало помогают, если вся площадка выходит в интернет через единственный внешний канал.
Профессиональные дата-центры обычно используют несколько операторов и собственную маршрутизацию, поэтому отказ одного внешнего соединения не отключает всю инфраструктуру.
Для обычного сайта эта часть чаще всего значительно важнее второго Ethernet-порта внутри конкретной машины.
Поэтому не стоит механически требовать два или четыре подключения для каждого физического сервера. Сначала нужно определить задачу.
Если сервер размещает один сайт, использует меньше 10 процентов гигабитного канала и допускает короткое техническое окно при редкой сетевой неисправности, одного подключения вполне достаточно.
Если нужна защита от отказа кабеля или интерфейса, имеет смысл active-backup bonding.
Если важна высокая суммарная пропускная способность для множества независимых соединений, можно рассматривать LACP.
Если сервер работает одновременно в публичной и внутренней сети, отдельные физические интерфейсы позволяют хорошо разделить эти потоки.
Если инфраструктура критична к простою, нужно строить независимые сетевые пути до разных коммутаторов, а не просто покупать второй кабель.
Именно поэтому число сетевых портов нельзя оценивать как ещё одну характеристику мощности рядом с ядрами CPU и гигабайтами RAM. Это инструмент построения сети.
Один порт может быть полностью достаточным для очень мощного сервера. Четыре порта могут оказаться необходимыми машине, которая по вычислительной мощности намного скромнее, но выполняет несколько сетевых ролей.
Хорошая конфигурация появляется тогда, когда каждый интерфейс имеет понятную задачу. Один обслуживает публичный трафик, второй резервирует его или подключён к приватной сети, дополнительные интерфейсы используются для хранилища, виртуализации или управления.
Если такой задачи нет, свободный Ethernet-разъём может спокойно оставаться свободным. Для сайта это намного лучше, чем сложная сетевая схема, которую никто в команде потом не сможет нормально диагностировать.
