LACP и прочие технологии агрегации каналов

Есть ещё один протокол или группа технологий, о которые систёмные администраторы часто ломают копья.

Но для начала краткая предыстория. Ну или вводная.

Когда вы начинаете строить проводную сеть, рано или поздно, у вас возникает необходимость увеличить пропускную способность одного из каналов. Хорошим решением такой задачи будет объединение нескольких шнурков (скажем по 1ГБ) в группу, так что бы их скорость суммировалась.

Если просто взять и соединить несколько свичей проводами, то, как я писал раньше, протокол STP не позволит вам использовать их вместе, так как с точки зрения Ethernet'а у вас, батенька, петля. Блокируем её.

Чтобы такое соединение заработало, были придуманы технологии - bonding, portchannel, etherchannel и похожие; и протоколы - у циски свой PaGP (Port Aggregation Protocol) и открытый LACP (Link Aggregation Control Protocol).

Одиним из таких протоколов настраивается связь на двух устройствах смотрящих друг на друга несколькими проводами и вуаля - получаем объединение полосы. Вроде бы.

Но всё это не так просто, иначе бы я об этом не писал. Есть несколько неочевидных нюансов:

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

2. Настройка балансировки происходит с каждой стороны независимо, и настраивается так же с каждой стороны отдельно. Принимающая сторона просто получает данные как они пришли и передаёт их дальше, она не влияет на то из какого шнурка на её что валится. Что это значит? Это значит, что неправильная настройка потока трафика в какую либо сторону - может свести к минимуму все усилия по объединению каналов.

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

Итак. Балансировка трафика настраивается с каждой стороны и работает примерно так. Устройство получает кадр с данными, смотрит внутрь него, читает какую либо информацию и решает: вот этот кадр поедет по первому проводу, вот этот по второму, снова по первому, снова по второму. Какие же критерии могут быть?

* Мак адрес отправителя или получателя

* IP адрес отправители или получателя (и, редко и дорого, порты отправителя и получателя)

Т.е. самая дешёвая и слабая железка, ничего кроме мак адреса не видит, и работать балансировка в такой ситуации будет, когда у вас с одной стороны есть много-много устройств, а с другой сервер (или несколько серверов). И в ситуации когда много-много компьютеров смотрят на много-много компьютеров. (устройства средней ценовой категории могут читать IP, что немногим лучше)

А вот в ситуации когда у вас один сервер смотрит на другой сервер - балансировка работать уже не будет. Это самый негативный сценарий для таких технологий, так как и мак адрес и IP отправителя и получателя всё время одинаковые, они не меняются от пакета к пакету. В этой ситуации помогла бы информация о используемых для соединения портах, но для её извлечения нужно очень много CPU и много памяти, ооочень мало железок такое делают на лету и с достаточной пропускной способностью.

Такими умениями обладают устройства из серии Дата центровый свичинг и стоят они как крыло Боинга (отчасти именно из-за такой фичи).

Единственным бюджетным решением, которое позволит вам решить такую задачу будет использовать несколько IP сетей, для каждой сетевой карты сервера (для каждого сервера) и организация линий L3 уровня, если вы понимаете о чём я. Но в этой ситуации встаёт проблема маршрутизации, и желательно динамической. Об этом позже ;)

Stay connected and use LACP smart.

P.S. Нет, во фразе "систёмные администраторы" я не опечатался. В других местах да, а тут нет

https://t.me/cooladmin