На пути повышения надёжности и скорости: Linux bonding

Павел Закляков

– Bond?....James Bond?

– No, Linux Bonding.

В данной статье описывается частный случай объединения двух каналов Ethernet в один c помощью Linux bonding (на базе Red Hat v.7.3) как с целью повышения пропускной способности, так и надёжности сетевого соединения.

Года два назад, просматривая одну электронную доску объявлений в разделе б/у сетевого оборудования, я наткнулся на заметку о продаже 16-портового коммутатора «Switch Surecom EP-716X c поддержкой виртуальной сети и транка на базе портов» плюс прочие документированные возможности. Цена была низкой, а желание повозиться с настройками велико. Поэтому я поспешил приобрести его.

Рисунок 1. Фотография коммутатора Surecom EP-716X

Ситуация на рынке год от года не меняется, скорости передачи данных неизменно растут, выходят новые версии и т. д. Несмотря на рост скоростей в сетях с выделенным сервером, узким местом все равно остаётся точка соединения сервера с локальной сетью. Если взять наиболее часто используемый вариант, то используется сеть Fast Ethernet и сетевые адаптеры с пропускной способностью 100 Мбит/с. В результате если к серверу обращается одновременно 20 компьютеров, то пропускная способность падает до 5 Мбит/c, а за вычетом служебной информации реальная пропускная способность оказывается ещё меньше. Выход из данной ситуации может быть только один – увеличивать пропускную способность со стороны сервера. Если на сервере в качестве делимого взять не 100, а 1000 Мбит/c, то в теории средняя скорость передачи на один компьютер должна увеличиться в 10 раз. Характеристики повсеместно продаваемого сетевого оборудования указывают на тот факт, что развитие идёт именно в этом направлении. Однако на данном пути есть несколько препятствий, не позволяющих делать переход массовым и незаметным.

Первый недостаток – необходимость покупки дорогих коммутаторов с поддержкой нескольких или одного порта по стандарту IEEE 802.3ab (1000Base-T). При этом старый коммутатор оказывается не у дел.

Второй недостаток – необходимость замены кабельной инфраструктуры. Кабели повсеместно используемых на сегодня категорий 5 и 5e не подойдут по полосе пропускания, соответственно их придётся также менять.

Третий недостаток – сочетание сетевых карт стандарта IEEE 802.3ab (1000Base-T) и шины PCI. С некоторой натяжкой можно считать, что цена данных устройств относительно невелика. А вот пропускная способность шины PCI 2.0 может оказаться для нас недостаточной: 33 МГц * 32 бита = 1056 Мбит/c [1]. Хотя, 1056 > 1000 следует понимать, что различные накладные расходы, особенно для карт стоимостью менее $25, приведут к тому, что реальная пропускная способность окажется ниже 1000 Мбит/c. При большой загрузке сети это приведёт к тому, что буфер не будет успевать обрабатываться, возникнут потери пакетов. Как следствие – повторная передача и ещё большее снижение пропускной способности. Также не следует упускать из виду, что многие серверы часто имеют не одну сетевую карту, а несколько.

Если согласно спецификации PCI 2.1 (и выше) вместо тактовой частоты шины в 33 МГц использовать 66 МГц, то подобных эффектов удастся избежать, однако в этом случае возможны проблемы c другим оборудованием, не поддерживающим частоту шины 66 МГц. Использование PCI-X или 64-разрядной шины PCI (даже при тактовой частоте 32 МГц) решает проблему технически, но часто делает её финансово непосильной. Материнские платы с поддержкой 64-разрядной шины PCI уже относятся к серверному классу и стоят соответствующе. «Склепать дешёвый сервер на коленке» не получится.

Единственный недорогой выход для данной ситуации – это использование нескольких обычных сетевых карт. Затраты при этом минимальны: $5 + один вечер и результат усилий (удвоение пропускной способности) налицо. По этому пути я и пошёл.