что такое агрегирование каналов связи
Агрегация каналов и балансировка трафика по IP для СХД
В большинстве современных серверов на борту как правило присутствует минимум два 1Gb интерфейса под данные и один 100Mb для менеджмента.
Схема подключения FlexPod Express.
Теоретическая часть
Как правило, 2-4 сервера не нагружают 1Gb линки по пропускной способности, использование всех линков одновременно положительно сказывается на скорости взаимодействия узлов сети и на пропускной способности в пиковых нагрузках.
Описание
Настройка
Отказоустойчивость для NFS
К VMware ESXi подключены следующие датасторы
Итак видно, что по интерфейсу e0a (столбец Pkts Out) трафик практически не отправляется.
Свитч
Идём на сторону свитча (свитч усредняет данные за период в несколько минут, потому утилизация лишь 80%, а не почти 100%) и видим, что порт Ethernet 1/11 практически не принимает фреймы.
Пример для Cisco IOS Release 12.2(33)SXI and later releases
Обратите внимание, если flowcontrol, в конфигурации, нигде не фигурирует, значит он в состоянии «flowcontrol auto«, и если на портах хранилища, которые подключены к коммутатору, flowcontol выключен, то на свиче на соответствующих портах, он будет в состоянии «off». Установка параметра flowcontrol может варьироваться, и зависит от нескольких параметров: скорости порта и типа коммутатора. Если хранилище «не отправляет и не принимает» команды (flowcontrol off) контроля потока, то «с другой стороны» свич тоже должен «не принимать и не отправлять» их. Побробнее про flowcontrol.
И не забываем про рекомендации по настройке Spanning-Tree, где желательно включить RSTP и установить порты свитча подключённых к конечным узлам в состояние spanning-tree portfast.
Видна нагрузка на приём (Rx) для контроллера в столбце «Rx Util» и загрузка на передачу (Tx) для сервера в столбце «Tx Util». При этом видно, что 2 датастора делят один линк контроллера.
Подбор IP
Почему это происходит? Да потому что хеш суммы двух IP пар совпадают, заставляя алгоритм выбирать один и тот же линк. Другими словами нужно просто подобрать другие IP.
Можно просто перебирать варианты IP. В написании программы подбора IP адресов большая трудность заключается в том, что алгоритм использует побитовые сдвиги над знаковым 32битным целым и операции сложения над ними же (переполнения отбрасываются). Поскольку скриптовые языки нынче слабо ориентированы на фиксированную битность чисел, то добиться нормального расчета на python не удалось. Поэтому была написана на C маленькая программа расчета по всему диапазону, а потом использовать результаты в переборе.
Алгоритм SuperFastHash
Начиная с версии Data ONTAP 7.3.2 для выбора пути используется не просто операция XOR над двумя IP адресами источника и получателя ((source_address XOR destination_address) % number_of_links). А более сложный алгоритм с побитовыми сдвигами под названием SuperFastHash представляющий более динамический, более сбалансированный способ распределения нагрузки и обеспечивает лучшую балансировку для большого количества клиентов. Результат получается почти тот же, но каждая TCP сессия ассоциируется только с одним интерфейсом.
Кстати говоря для быстрого получения результата очень удобно воспользоваться онлайн компилятором.
Как пользоваться табличкой
Видно, что для каждого сервера трафик с разными алиасами на одном контроллере будет идти по разным интерфейсам. Аналогично трафик с разных серверов на один IP СХД пойдет по разным интерфейсам.
При написании использовались материалы Александра Гордиенко, Агрегация каналов и балансировка трафика по IP со стороны NetApp.
Основы компьютерных сетей. Тема №8. Протокол агрегирования каналов: Etherchannel
P.S. Возможно, со временем список дополнится.
Итак, начнем с простого.
Etherchannel — это технология, позволяющая объединять (агрегировать) несколько физических проводов (каналов, портов) в единый логический интерфейс. Как правило, это используется для повышения отказоустойчивости и увеличения пропускной способности канала. Обычно, для соединения критически важных узлов (коммутатор-коммутатор, коммутатор-сервер и др.). Само слово Etherchannel введено компанией Cisco и все, что связано с агрегированием, она включает в него. Другие вендоры агрегирование называют по-разному. Huawei называет это Link Aggregation, D-Link называет LAG и так далее. Но суть от этого не меняется.
Разберем работу агрегирования подробнее.
Есть 2 коммутатора, соединенных между собой одним проводом. К обоим коммутаторам подключаются сети отделов, групп (не важен размер). Главное, что за коммутаторами сидят некоторое количество пользователей. Эти пользователи активно работают и обмениваются данными между собой. Соответственно им ни в коем случае нельзя оставаться без связи. Встает 2 вопроса:
Теперь об их отличии. Первые 2 позволяют динамически согласоваться и в случае отказа какого-то из линков уведомить об этом.
Ручное агрегирование делается на страх и риск администратора. Коммутаторы не будут ничего согласовывать и будут полагаться на то, что администратор все предусмотрел. Несмотря на это, многие вендоры рекомендуют использовать именно ручное агрегирование, так как в любом случае для правильной работы должны быть соблюдены правила, описанные выше, а коммутаторам не придется генерировать служебные сообщения для согласования LACP или PAgP.
Начну с протокола LACP. Чтобы он заработал, его нужно перевести в режим active или passive. Отличие режимов в том, что режим active сразу включает протокол LACP, а режим passive включит LACP, если обнаружит LACP-сообщение от соседа. Соответственно, чтобы заработало агрегирование с LACP, нужно чтобы оба были в режиме active, либо один в active, а другой в passive. Составлю табличку.
Теперь перейдем к лабораторке и закрепим в практической части.
Есть 2 коммутатора, соединенные 2 проводами. Как видим, один линк активный (горит зеленым), а второй резервный (горит оранжевым) из-за срабатывания протокола STP. Это хорошо, протокол отрабатывает. Но мы хотим оба линка объединить воедино. Тогда протокол STP будет считать, что это один провод и перестанет блокировать.
Заходим на коммутаторы и агрегируем порты.
На этом настройка на первом коммутаторе закончена. Для достоверности можно набрать команду show etherchannel port-channel:
Видим, что есть такой port-channel и в нем присутствуют оба интерфейса.
Переходим ко второму устройству.
После этого канал согласуется. Посмотреть на это можно командой show etherchannel summary:
Здесь видно группу port-channel, используемый протокол, интерфейсы и их состояние. В данном случае параметр SU говорит о том, что выполнено агрегирование второго уровня и то, что этот интерфейс используется. А параметр P указывает, что интерфейсы в состоянии port-channel.
Все линки зеленые и активные. STP на них не срабатывает.
Сразу предупрежу, что в packet tracer есть глюк. Суть в том, что интерфейсы после настройки могут уйти в stand-alone (параметр I) и никак не захотят из него выходить. На момент написания статьи у меня случился этот глюк и решилось пересозданием лабы.
Теперь немного углубимся в работу LACP. Включаем режим симуляции и выбираем только фильтр LACP, чтобы остальные не отвлекали.
Видим, что SW1 отправляет соседу LACP-сообщение. Смотрим на поле Ethernet. В Source он записывает свой MAC-адрес, а в Destination мультикастовый адрес 0180.C200.0002. Этот адрес слушает протокол LACP. Ну и выше идет «длинная портянка» от LACP. Я не буду останавливаться на каждом поле, а только отмечу те, которые, на мой взгляд, важны. Но перед этим пару слов. Вот это сообщение используется устройствами для многих целей. Это синхронизация, сбор, агрегация, проверка активности и так далее. То есть у него несколько функций. И вот перед тем, как это все начинает работать, они выбирают себе виртуальный MAC-адрес. Обычно это наименьший из имеющихся.
И вот эти адреса они будут записывать в поля LACP.
С ходу это может не сразу лезет в голову. С картинками думаю полегче ляжет. В CPT немного кривовато показан формат LACP, поэтому приведу скрин реального дампа.
Выделенная строчка показывает для какой именно цели было послано данное сообщение. Вот суть его работы. Теперь это единый логический интерфейс port-channel. Можно зайти на него и убедиться:
И все действия, производимые на данном интерфейсе автоматически будут приводить к изменениям на физических портах. Вот пример:
Стоило перевести port-channel в режим trunk и он автоматически потянул за собой физические интерфейсы. Набираем show running-config:
И действительно это так.
Теперь расскажу про такую технологию, которая заслуживает отдельного внимания, как Load-Balance или на русском «балансировка». При создании агрегированного канала надо не забывать, что внутри него физические интерфейсы и пропускают трафик именно они. Бывают случаи, что вроде канал агрегирован, все работает, но наблюдается ситуация, что весь трафик идет по одному интерфейсу, а остальные простаивают. Как это происходит объясню на обычном примере. Посмотрим, как работает Load-Balance в текущей лабораторной работе.
На данный момент он выполняет балансировку исходя из значения MAC-адреса. По умолчанию балансировка так и выполняется. То есть 1-ый MAC-адрес она пропустит через первый линк, 2-ой MAC-адрес через второй линк, 3-ий MAC-адрес снова через первый линк и так будет чередоваться. Но такой подход не всегда верен. Объясняю почему.
Вот есть некая условная сеть. К SW1 подключены 2 компьютера. Далее этот коммутатор соединяется с SW2 агрегированным каналом. А к SW2 поключается маршрутизатор. По умолчанию Load-Balance настроен на src-mac. И вот что будет происходить. Кадры с MAC-адресом 111 будут передаваться по первому линку, а с MAC-адресом 222 по второму линку. Здесь верно. Переходим к SW2. К нему подключен всего один маршрутизатор с MAC-адресом 333. И все кадры от маршрутизатора будут отправляться на SW1 по первому линку. Соответственно второй будет всегда простаивать. Поэтому логичнее здесь настроить балансировку не по Source MAC-адресу, а по Destination MAC-адресу. Тогда, к примеру, все, что отправляется 1-ому компьютеру, будет отправляться по первому линку, а второму по второму линку.
Это очень простой пример, но он отражает суть этой технологии. Меняется он следующим образом:
Здесь думаю понятно. Замечу, что это пример балансировки не только для LACP, но и для остальных методов.
Заканчиваю разговор про LACP. Напоследок скажу только, что данный протокол применяется чаще всего, в силу его открытости и может быть использован на большинстве вендоров.
Тем, кому этого показалось мало, могут добить LACP здесь, здесь и здесь. И вдобавок ссылка на данную лабораторку.
Теперь про коллегу PAgP. Как говорилось выше — это чисто «цисковский» протокол. Его применяют реже (так как сетей, построенных исключительно на оборудовании Cisco меньше, чем гетерогенных). Работает и настраивается он аналогично LACP, но Cisco требует его знать и переходим к рассмотрению.
У PAgP тоже 2 режима:
Теперь переходим к настройке SW2 (не забываем, что на SW1 интерфейсы выключены и следует после к ним вернуться):
Возвращаемся к SW1 и включаем интерфейсы:
Теперь переходим в симуляцию и настраиваемся на фильтр PAgP. Видим, вылетевшее сообщение от SW2. Смотрим.
То есть видим в Source MAC-адрес SW2. В Destination мультикастовый адрес для PAgP. Повыше протоколы LLC и SNAP. Они нас в данном случае не интересуют и переходим к PAgP. В одном из полей он пишет виртуальный MAC-адрес SW1 (выбирается он по тому же принципу, что и в LACP), а ниже записывает свое имя и порт, с которого это сообщение вышло.
В принципе отличий от LACP практически никаких, кроме самой структуры. Кто хочет ознакомиться подробнее, ссылка на лабораторную. А вот так он выглядит реально:
Последнее, что осталось — это ручное агрегирование. У него с агрегированием все просто:
При остальных настройках канал не заработает.
Как говорилось выше, здесь не используется дополнительный протокол согласования, проверки. Поэтому перед агрегированием нужно проверить идентичность настроек интерфейсов. Или сбросить настройки интерфейсов командой:
В созданной лабораторке все изначально по умолчанию. Поэтому я перехожу сразу к настройкам.
И аналогично на SW2:
Настройка закончена. Проверим командой show etherchannel summary:
Порты с нужными параметрами, а в поле протокол «-«. То есть дополнительно ничего не используется.
Как видно все методы настройки агрегирования не вызывают каких-либо сложностей и отличаются только парой команд.
Под завершение статьи приведу небольшой Best Practice по правильному агрегированию. Во всех лабораторках для агрегирования использовались 2 кабеля. На самом деле можно использовать и 3, и 4 (вплоть до 8 интерфейсов в один port-channel). Но лучше использовать 2, 4 или 8 интерфейсов. А все из-за алгоритма хеширования, который придумала Cisco. Алгоритм высчитывает значения хэша от 0 до 7.
4 | 2 | 1 | Десятичное значение |
---|---|---|---|
0 | 0 | 0 | 0 |
0 | 0 | 1 | 1 |
0 | 1 | 1 | 3 |
1 | 0 | 0 | 4 |
0 | 0 | 1 | 1 |
1 | 0 | 1 | 5 |
1 | 1 | 0 | 6 |
1 | 1 | 1 | 7 |
Данная таблица отображает 8 значений в двоичном и десятичном виде.
На основании этой величины выбирается порт Etherchannel и присваивается значение. После этого порт получает некую «маску», которая отображает величины, за которые тот порт отвечает. Вот пример. У нас есть 2 физических интерфейса, которые мы объединяем в один port-channel.
Значения раскидаются следующим образом:
1) 0x0 — fa0/1
2) 0x1 — fa0/2
3) 0x2 — fa0/1
4) 0x3 — fa0/2
5) 0x4 — fa0/1
6) 0x5 — fa0/2
7) 0x6 — fa0/1
8) 0x7 — fa0/2
В результате получим, что половину значений или паттернов возьмет на себя fa0/1, а вторую половину fa0/2. То есть получаем 4:4. В таком случае балансировка будет работать правильно (50/50).
Теперь двинемся дальше и объясню, почему не рекомендуется использовать, к примеру 3 интерфейса. Составляем аналогичное сопоставление:
1) 0x0 — fa0/1
2) 0x1 — fa0/2
3) 0x2 — fa0/3
4) 0x3 — fa0/1
5) 0x4 — fa0/2
6) 0x5 — fa0/3
7) 0x6 — fa0/1
8) 0x7 — fa0/2
Здесь получаем, что fa0/1 возьмет на себя 3 паттерна, fa0/2 тоже 3 паттерна, а fa0/3 2 паттерна. Соответственно нагрузка будет распределена не равномерно. Получим 3:3:2. То есть первые два линка будут всегда загруженнее, чем третий.
Все остальные варианты я считать не буду, так как статья растянется на еще больше символов. Можно только прикинуть, что если у нас 8 значений и 8 линков, то каждый линк возьмет себе по паттерну и получится 1:1:1:1:1:1:1:1. Это говорит о том, что все интерфейсы будут загружены одинаково. Еще есть некоторое утверждение, что агрегировать нужно только четное количество проводов, чтобы добиться правильной балансировки. Но это не совсем верно. Например, если объединить 6 проводов, то балансировка будет не равномерной. Попробуйте посчитать сами. Надеюсь алгоритм понятен.
У Cisco на сайте по этому делу есть хорошая статья с табличкой. Можно почитать по данной ссылке. Если все равно останутся вопросы, пишите!
Раз уж так углубились, то расскажу про по увеличение пропускной способности. Я специально затронул эту тему именно в конце. Бывают случаи, что срочно нужно увеличить пропускную способность канала. Денег на оборудование нет, но зато есть свободные порты, которые можно собрать и пустить в один «толстый» поток. Во многих источниках (книги, форумы, сайты) утверждается, что соединяя восемь 100-мегабитных портов, мы получим поток в 800 Мбит/с или восемь гигабитных портов дадут 8 Гбит/с. Вот кусок текста из «цисковской» статьи.
Теоретически это возможно, но на практике почти недостижимо. Я по крайней мере не встречал. Если есть люди, которые смогли этого добиться, я буду рад услышать. То есть, чтобы это получить, нужно учесть кучу формальностей. И вот те, которые я описывал, только часть. Это не значит, что увеличения вообще не будет. Оно, конечно будет, но не настолько максимально.
На этом статья подошла к концу. В рамках данной статьи мы научились агрегировать каналы вручную, а также, при помощи протоколов LACP и PAgP. Узнали, что такое балансировка, как ею можно управлять и как правильно собирать Etherchannel для получения максимального распределения нагрузки. До встречи в следующей статье!
Удваиваем скорость домашней сети: практические испытания технологии агрегирования каналов
Уже много лет LAN-кабель не пересекает гигабитную границу. Мы покажем, как достичь двойной скорости и что необходимо для получения десятикратной скорости передачи данных.
Раньше люди особо не задумывались о скорости кабельных подключений в домашней сети. Они всегда обеспечивали достаточную скорость и надежность, что в любом случае доказано их использованием миллионы раз. Однако в наши дни технология подошла к своему пределу: во все большее число компьютеров устанавливаются твердотельные накопители, скорость которых как минимум впятеро превышает 1 Гбит/с. А новые стандарты беспроводной сети 802.11 «ac» и «ad» значительно превышают гигабитную скорость Ethernet.
Разумеется, существуют кабельные технологии, обеспечивающие скорость до 10 Гбит/с, однако они предназначены для профессиональных вычислительных центров и являются довольно дорогими. Но есть и другая возможность обеспечения более высокой скорости. Она состоит в объединении нескольких гигабитных сетей. В подобной схеме, т.н. «агрегации каналов», соединяются два обычных гигабитных LAN-кабеля и тем самым обеспечивается отличная интеграция в существующую сеть. Однако для реализации простого принципа «2×1 Гбит = 2 Гбит» на практике существуют некоторые препятствия, которые мы обнаружили в ходе наших тестов.
Агрегация каналов: сетевые коммутаторы от 2500 руб
Основным элементом для агрегации каналов является сетевой коммутатор, который должен поддерживать эту функцию. В большинстве домашних сетей существует лишь коммутатор, встроенный в маршрутизатор — это его порты LAN. Зачастую они не могут соединяться друг с другом.
Эту возможность обеспечивают только современные маршрутизаторы топ-класса, такие, как ASUS RT-AC5300 или Netgear Nighthawk X10 (цена каждого — от 20 000 рублей). Однако всего за 2500 рублей доступны LAN-коммутаторы с 8 портами и возможностью агрегации каналов (например, TP-Link TL-SG108E или Netgear Gs108E), которые можно переключать между маршрутизатором и объединяемыми в сеть устройствами (см. схему справа).
Принципиальная особенность: коммутатор должен быть управляемым (т. е. требуется веб-интерфейс для его настройки, а установленная в нем прошивка должна обеспечивать возможность соединения портов). Указанием на это является один из терминов «Link Aggregation», «Port Trunking», «LACP» или «802.3ad» в техническом описании.
Компьютеры или устройства, которые должны подключаться со скоростью в несколько Гбит/с, должны иметь соответствующее число LAN-портов, а также возможность настройки на программном уровне. Мы протестировали два сценария, используя коммутатор Netgear GS110TP. В первом сетевой накопитель NAS соединен с коммутатором через два LAN-порта, таким образом каждый из двух ПК может загружать данные из NAS-хранилища с полной гигабитной скоростью.
Этот вариант представляет собой целевое применение агрегации каналов и работает относительно беспроблемно. При втором варианте мы сконфигурировали ПК с двумя LAN-портами так, что данные можно было загружать из NAS со скоростью 2 Гбит/с. Этот довольно сложный способ предполагает совершенно определенные виды передачи данных и часто (но не всегда) обеспечивает удвоенную скорость.
Структура и конфигурирование коммутатора
В любом случае сначала необходимо запустить коммутатор: к электрической сети он подключается через собственный блок питания; один из его портов соединяется с маршрутизатором (мы использовали последний порт № 8). Примерно через минуту он загрузится, его LAN-порты заработают, а веб-интерфейс станет доступен для всех компьютеров, подключенных к коммутатору (или маршрутизатору) по кабельной или беспроводной сети.
IP-адрес коммутатора можно узнать в настройках вашего маршрутизатора, предварительно установленный пароль указан в руководстве пользователя. В первую очередь необходимо произвести поиск обновлений на сайте производителя; у нашего коммутатора Netgear нам было необходимо загрузить новую прошивку в меню «Maintenance | Download | HTTP File Download».
В веб-интерфейсе коммутатора Netgear производится конфигурирование групп агрегации каналов, а также подключаемых портов
Конфигурирование агрегации каналов может производиться до подключения соответствующих устройств. В веб-интерфейсе коммутатора Netgear в поле «Switching | LAG» нажмите на пункт «LAG1» (группа агрегации каналов) и установите галочку в пункте «PORT» у номеров портов, которые вы хотите задействовать. Каждая группа служит для подключения одного устройства: на схеме сверху справа LAG1 — это NAS-хранилище, подключенное к портам 1 и 2, LAG2 — это ПК на портах 5 и 6. В разделе «LAG Configuration» мы оставили настройки по умолчанию, лишь изменили параметр «LAG Type» на «LACP».
Скорость портов, не относящихся ни к одной группе, остается на обычном уровне 1 Гбит (на схеме — это 3, 4 и 8). Подключите устройства в соответствии с LAG-идентификацией. Сначала активно только простое кабельное соединение с физическим первым интерфейсом конечного устройства; агрегацию каналов также необходимо активировать на конечных устройствах. Как это сделать, читайте далее.
Конфигурирование NAS для двухканального режима
Для наших тестов мы использовали QNAP TS-231P, оснащенный двумя LAN-портами и обеспечивающий высокую пропускную способность. Мы измерили скорости передачи данных по FTP, причем и в NAS-накопителе, и в целевом ПК были установлены быстрые SSD-накопители SATA. Настройки сети в веб-интерфейсе QNAP находятся в разделе «Панель управления | Системные настройки | Сеть».
Здесь в разделе «Интерфейсы» показаны оба Ethernet-порта. Щелкните раздел «Группирование портов | Добавить» и установите флажок для каждого интерфейса. Единственный режим, который надежно работал с коммутатором Netgear в ходе тестирования и привел к требуемым результатам, был «Balance-rr», при котором для передачи данных используются оба кабеля поочередно.
После щелчка на кнопке «Применить» NAS-накопитель на короткое время переходит в режим оффлайн для применения новых параметров. Если установлен режим, который не поддерживается, NAS будет недоступен; в этом случае необходимо нажать и удерживать в течение 3 секунд кнопку на задней стороне устройства. Это приведет к сбросу пароля и возврату параметров сети к значениям по умолчанию.
В теории базовый режим агрегации каналов с помощью двух компьютеров, подключенных к простым портам коммутатора Netgear, должен позволять одновременно скачать с NAS-диска два файла со скоростью 1 Гбит/с каждый. Но загрузка и закачка с двух ПК немного выбивает систему из ритма: при загрузке на сетевой накопитель скорость примерно на 25% ниже максимальной теоретически возможной.
Так как подобная конфигурация является относительно доступной и легко реализуемой, она, безусловно, подходит для домашних сетей, в которых доступ к NAS-накопителю осуществляется с нескольких компьютеров. Однако стоит обратить внимание на следующее: в то время, как параллельная передача данных помогает исчерпать возможности обеих сетевых линий, она же предъявляет повышенные требования к накопителям, установленным в NAS-устройстве. Желательно использоваться SSD-диски.
Удвоенная скорость передачи данных от NAS-сервера к ПК также возможна, однако на практике этот вариант довольно сложен, как мы выяснили далее.
Настройка агрегации каналов на ПК
То, что выполняется на NAS-накопителе с помощью пары кликов, должно быть так же просто реализовать на ПК. Во всяком случае, так считают. С точки зрения аппаратных средств существуют многочисленные материнские платы с двумя LAN-портами, или платы с возможностью установки второй сетевой карты со скоростью 1 Гбит/с за небольшие деньги. С точки зрения программного обеспечения это становится сложнее: изначально эта функция поддерживалась в Windows 10. Но после обновления осенью 2015 года, утилиты для этого хотя и существуют, однако больше не работают. Это также относится к сетевым драйверам Intel, с помощью которых агрегация каналов может быть настроена альтернативным способом.
Поэтому мы установили на игровом ПК с процессором Skylake и двумя сетевыми разъемами ОС Ubuntu, в которой может быть настроена агрегация, в мире Linux называемая «Port Trunking». Для этого мы сначала деактивировали менеджер сетей Ubuntu, а потом настроили агрегацию портов с помощью файла конфигурации Linux («/etc/network/interfaces»). По правде говоря, мы испытывали разные варианты из Интернета, до тех пор, пока технология не заработала на нашем тестовом ПК, поскольку документация по теме довольно скудна и зачастую противоречива.
Наша успешная комбинация состоит из четырех определений интерфейсов, каждый из которых начинается с «auto…»: сначала указывается важное для системы устройство закольцовывания, в котором нельзя ничего изменить. В этом случае определяются, но не активируются, оба физических LAN-порта. Это происходит только в определении «bond0» указанного интерфейса агрегации каналов. Большинство записей предназначены для конфигурирования IP-настроек в ручном режиме, режим подключения указывается с помощью строки «bond-mode». Режим 4 предназначен для соединения по стандарту «802.3ad» и обеспечивает максимальную скорость до 1628 Мбит/с.
Альтернативным образом работает режим 0 («Balance-rr», то есть тот же самый режим, что и в NAS-накопителе), однако только со скоростью 1202 Мбит/с. Для сравнения: скорость передачи данных по отдельной гигабитной линии составляет 912 Мбит/с. Отказоустойчивость является положительным сопутствующим эффектом: во время передачи данных можно отключить один из двух разъемов — связь не обрывается, лишь вдвое падает скорость.
Однако есть как минимум одна загвоздка: обе линии используются только в том случае, если по FTP одновременно передаются два файла (в меню настроек Filezilla: «Передачи | Максимум одновременных передач: 2»). При повышении этого значения скорость очень быстро уменьшается. Кроме того, необходимо обращать внимание на то, чтобы между ПК и NAS-сервером отсутствовала любая другая связь (например, открытый веб-интерфейс NAS, SSH-соединение), так как даже минимальная загрузка линии приводит к тому, что обе передачи данных осуществляются только по одной линии вместо двух.
Дополнительное разочарование: скорость в ходе экспериментов с SMB-протоколом, который использует Windows для удаленного доступа к файлам, была значительно медленнее, чем по одной гигабитной линии. Все это демонстрирует малую вероятность того, что режим агрегации каналов в Windows мог бы функционировать быстро и без проблем, так как система Microsoft сохраняет контрольные и иные соединения.
Наш вывод в отношении агрегации каналов: процесс хорошо подходит для эффективного соединения NAS-сервера с несколькими гигабитными клиентами. В качестве быстрого соединения NAS с клиентом он является трудоемким и имеет много подводных камней. Для этого потребовалась бы принципиально более быстрая сетевая технология.
SFP+ как новый 10-гигабитный стандарт
Маршрутизатор Netgear Nighthawk X10 оснащен интерфейсом SFP+, таким образом, к нему можно подключить устройство со скоростью передачи данных 10 Гбит/с. Два его гигабитных LAN-порта объединяются посредством агрегации каналов.
Ethernet 10 Гбит и SFP+
В профессиональной области 10-гигабитный стандарт уже более десяти лет образует основу инфраструктуры в вычислительных центрах. Вариант с медными кабелями под названием «10GBase-T» делает ставку на те же самые разъемы RJ-45, как и гигабитная локальная сеть LAN, однако для него требуются экранированные (как минимум Cat. 6) кабели и дорогое оборудование: сетевая карта, например, Intel X540-T1 стоит около 22 000 руб., самый дешевый коммутатор с двумя портами 10GBase-T (ASUS XG-U2008) примерно столько же. NAS-накопители с поддержкой данного стандарта стоят от 50 000 руб.
Профессиональная карта
Благодаря сетевой карте HP NC523SFP компьютер дополнительно оснащается двумя интерфейсами SFP+
Более доступным является стандарт «SFP+». Он описывает компактное модульное приемо-передающее устройство, используемое в кабельных сетях и рассчитан как на медные, так и гораздо более дорогие оптоволоконные кабели. Оба варианта обеспечивают передачу данных со скоростью 10 Гбит/с: медные кабели на расстояние 50-100 метров, оптоволокно — до нескольких километров. Маршрутизатор Netgear Nighthawk X10 оснащен одним портом SFP+. С помощью модуля SFP+ Direct Attach Copper Cable (около 2500 руб.) к нему можно подключить NAS-накопитель.
Самой дешевой моделью SFP+ является QNAP TS-531X-2G (от 48 000 руб.). Сетевые карты PCIe, поддерживающие SFP+, доступны по цене от 15 000 руб. (Внимание! Большинство из них работают только с драйверами серверной версии Windows!) Впрочем, как показывает маршрутизатор Netgear, складывается ситуация, что SFP+ может проникнуть на массовый рынок и «взорвать» гигабитную границу.