Тестирование технологии Nic Teaming (Bonding)
Тестовая среда:
В качестве тестовой площадки выступало следущее оборудование:
2 компьютера с идентичной конфигурацией (CPU 3.0Ghz, RAM 6Gb, HDD 160Gb, 1 LAN OnBoard, 1PCI-E External LAN 4 port)
Сетевое оборудование CISCO Catalyst 2960S и CISCO Catalyst 3560G
Продолжительность тестирования:
Продолжительность тестирования составило 18 рабочих дней.
Тестирование
Тестирование проводилось в 3 этапа: Linux – Linux, Linux – Windows, openSolaris – Windows.
Режимы работы NicTeaming (Bonding):
0 — balance-rr При передачи данных меняет интерфейсы поочередно(Round-robin).
1 — active-backup Один из интерфейсов активен. Если активный интерфейс выходит из строя, другой интерфейс присваивает MAC-адрес и становится активным. Данный режим предоставляет только отказоустойчивость и не требует специальной поддержки со стороны коммутатора.
2 — balance-xor Передачи распределяются между интерфейсами на основе формулы ((MAC-адрес источника) XOR (MAC-адрес получателя)) % число интерфейсов. Один и тот же интерфейс работает с определённым получателем. Режим даёт балансировку нагрузки и отказоустойчивость.
3 — broadcast Передаёт все пакеты на все интерфейсы объединения, обеспечивая повышения отказоустойчивости.
4 — 802.3ad Это классический IEEE 802.3ad, динамическое объединение каналов. Требует поддержки 802.3ad от коммутатора и восстановления скорости и дуплекса от драйвера каждого из интерфейсов.
5 — balance-tlb Адаптивная балансировка нагрузки передачи. Входящий трафик получается только активным интерфейсом, исходящий же распределяется в зависимости от текущей загрузки каждого интерфейса. Не требует специальной поддержки коммутатора.
6 — balance-alb Адаптивная балансировка нагрузки — обеспечивает балансировку нагрузки как передачи (TLB, transmit load balancing), так и приёма для IPv4 через ARP. Не требует специальной поддержки коммутатором, но требует возможности изменять MAC-адрес устройства.
Результаты тестирования Linux – Linux.
В качестве Операционной Системы для тестирования (ОС – сокращение в дальнейшем) был выбран дистрибутив Debian Linux Lenny stable x64.
Для установки драйверов понадобилось дополнительно установить ряд пакетов: net-tools, ethtool, ifenslave-2.6, build-essential, make.
Затем создаем bonding (он же NicTeaming), для этого создаем сетевой интерфейс bond0 который будет объединять в себе 4 интерфейса, eth1, eth2, eth3, eth4. Для этого правим файл /etc/network/interfaces
Таким же способом на 2 компьютере создан интерфейс с IP: 10.10.250.3.
Сделали сервером компьютер с IP 10.10.250.2. Здесь и в дальнейшем условимся, что сервер – это ПК с IP адресом 10.10.250.2, а клиент – это ПК с IP адресом 10.10.250.3.
Так как мы решили тестировать по протоколу iSCSI и не ограничивать себя в скорости работы с жетскими дисками, мы будем использовать RAMDrive.
Для этого создадим на сервере RAMDrive в котором развернем iSCSI ресурс.
затем устанавливаем iSCSI-Target
После этого настраиваем iSCSI путем редактирования его конфигурационного файла /etc/iet/iet.conf
И создаем само iSCSI хранилище размером 2.1Гб в RAMDriv’e емкостью 3Гб.
После чего перезапускаем службу iSCSI и службу сетевых интерфейсов
После чего проверяем NicTeaming(bonding) выполнив команду:
На клиенте был установлен пакет open-iscsi и перезапущены сервисы сетевых интерфейсов и iSCSI-Initiator, после чего выполнили команду
Затем мы подключили iSCSI хранилище и RAMDrive выполнив
Наиболее оптимльном режимом работы оказался balance-rr, вот его результаты:
Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 185-310MB/Sec
RAMDrive -> iSCSI 135-185MB/Sec
Перезапись файла:
iSCSi -> RAMDrive 180-320MB/Sec
RAMDrive -> iSCSI 150-175MB/Sec
Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.
PING
# ping -s 65000 10.10.250.2
PING 10.10.250.2 (10.10.250.2) 65000(65028) bytes of data.
65008 bytes from 10.10.250.2: icmp_seq=503 ttl=128 time=1.34 ms
65008 bytes from 10.10.250.2: icmp_seq=504 ttl=128 time=1.31 ms
65008 bytes from 10.10.250.2: icmp_seq=505 ttl=128 time=1.32 ms
65008 bytes from 10.10.250.2: icmp_seq=506 ttl=128 time=1.34 ms
^C
— 10.10.250.2 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 507016ms
Ресурсы обоих систем Debian Linux были вполне свободны:
SWAP – 4Gb использовался 1-3%
RAM – 6Gb, из них 3Gb отведено под виртуальный диск, свободно всегда оставалось 600-800Mb.
Загрузка процессора составляла 7-30%
Загрузка сети 18-27%
Как видно из результатов, скорость передачи данных не синхронна и очень мала для заявленого 500-650М/сек по описанию технологии с применением NicTeaming’а на 4-х портах сетевого адаптера. В режиме наибольшей прорускной способности (802.3ad) оборудование CISCO зависло 2 раза.
Попытка использовать протокол NFS дала прирост в скорости чтения на 10-15%, но на столько же снизило скорость записи.
Результаты тестирования Linux – Windows
В качестве ОC сервера остался Debian Linux Lenny stable, в качестве клиентской ОС был установлен MS Windows 2003 Server Standard R2.
На клиенте был установлен RAMDrive и Microsoft iSCSI Initiator, а так же создан NicTeaming (Bonding) в режиме 4 ( 802.3ad) – так как именно в этом режиме работы были достигнуты максимальные показатели. Так же был отключен IPS и QoS, как в настройках подключения, так и через GPU (Груповая политика — mmc).
Никаких других настроек над системой не проводилось.
Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 63-70MB/Sec
RAMDrive -> iSCSI 365-400MB/Sec
Перезапись файла:
iSCSi -> RAMDrive 40-60MB/Sec
RAMDrive -> iSCSI 340-380MB/Sec
Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.
Так же были проведены тесты с помощью утилиты sqlio.
Результаты команды ping от сервера до клиента
PING
# ping -s 65000 10.10.250.3
PING 10.10.250.3 (10.10.250.3) 65000(65028) bytes of data.
65008 bytes from 10.10.250.3: icmp_seq=503 ttl=128 time=1.24 ms
65008 bytes from 10.10.250.3: icmp_seq=504 ttl=128 time=1.21 ms
65008 bytes from 10.10.250.3: icmp_seq=505 ttl=128 time=1.24 ms
65008 bytes from 10.10.250.3: icmp_seq=506 ttl=128 time=1.12 ms
^C
— 10.10.250.3 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 507003ms
Загрузка сети не поднималась больше 23%, средняя загрузка процессора составляла 48-72% на каждое ядро.
Как видно скорость передачи данных снова не синхронна и очень мала для заявленой технологии, но тем не менее скорость записи на хранилище (iSCSI) была намного выше чем между двумя одинаковыми ОС на базе Debian Linux, в результате чего далее будет проведен тест между клиентом с ОС Windows 2003 Server и серевером с предустановленой ОС openSolaris.
Результаты тестирования openSolaris – Windows
В качестве ОC сервера был установлен дистрибутив ОС UNIX (openSolaris), в качестве клиентской ОС осталась установленная ранее MS Windows 2003 Server Standard R2.
Для начала на сервере настроим Link Agregation 802.3ad, т.к openSolaris может работать только в этом режиме NicTeaming’а.
Сначала проверим доступные сетевые интерфейсы, для этого выполним
Далее мы отключаем все интерфейсы которые будем использовать при создании NicTeaming’а, создадим сам NicTeaming и поднимем интерфейс с NicTeamimg’ом обратно, для этого выполняем следующие действия:
Затем создадим RAMDrive объемом в 1.1Гб в который поместим наше iSCSI хранилище и создадим там файловую систему, для этого выполним следущее:
Теперь создадим iSCSI-Tagreg, для этого необходимо доставить 2 пакета в систему:
Настраиваем ZFS iSCSI Volume на сервере Target
Далее необходимо запустить и настроить службу iSCSI-Target, для этого делаем следущее
Главное здесь что поставлен размер блока 128б, если будет меньше – то это будет сказывается на производительности
Ну вот мы имеем настроеный iSCSI-Target с NicTeaming в режиме 802.3ad.
Тестирования проводились в 2-х вариантах, 1-ый с включенным и настроеным CISCO и настроеными интерфейсами клиента и сервера на LACP и PagP, 2-ой в автоматическом режиме настройки.
Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 80-120MB/Sec
RAMDrive -> iSCSI 350-400MB/Sec
Перезапись файла:
iSCSi -> RAMDrive 80-90MB/Sec
RAMDrive -> iSCSI 350-400MB/Sec
Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.
Так же были проведены тесты с помощью утилиты sqlio.
Результаты команды ping от сервера до клиента
PING
# ping -s 65000 10.10.250.3
PING 10.10.250.3 (10.10.250.3) 65000(65028) bytes of data.
65008 bytes from 10.10.250.3: icmp_seq=503 ttl=128 time=1.27 ms
65008 bytes from 10.10.250.3: icmp_seq=504 ttl=128 time=1.11 ms
65008 bytes from 10.10.250.3: icmp_seq=505 ttl=128 time=1.12 ms
65008 bytes from 10.10.250.3: icmp_seq=506 ttl=128 time=1.17 ms
^C
— 10.10.250.3 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 506021ms
Во время работы с ненастроеной CISCO на LACP и PagP, оборудование CISCO 2-ы повисло. После повторного включения CISCO скорость передачи данных была синхронна, и на протяжении 6 минут была равно 350МВ/сек в каждую сторону. После чего снова началась рассинхронизация скорости передачи данных.
Повторить результат или понять причину не удалось.
Общее заключение
Добиться синхронных результатов скорости передачи данных хотя бы в 250-350MB/сек, так и не удалось не смотря на описание технологии где сказано что этого можно добиться. В различных условиях тестирования скорость отличалась не сильно, хотя при работе в связке openSolaris и Windows 2003 был почти достигнут желаемый результат, но повторить его так и не удалось. Возможно если повторить эксперимент позже с более новыми драйверами и другим оборудованием – результаты будут другие, но на данный момент достичь желаемого сейчас нам не удалось, возможно нужно более тщательно подбирать используемое оборудование для обеспечения лучшей совместимости. При отказе одного из интерфейсов (физическое выключение кабеля из CISCO) потери были минимальны, данные передавались сразу же на другой интерфейс. Поэтому данную технологию можно использовать для повышения отказоустойчивости работы сети.
В качестве тестовой площадки выступало следущее оборудование:
2 компьютера с идентичной конфигурацией (CPU 3.0Ghz, RAM 6Gb, HDD 160Gb, 1 LAN OnBoard, 1PCI-E External LAN 4 port)
Сетевое оборудование CISCO Catalyst 2960S и CISCO Catalyst 3560G
Продолжительность тестирования:
Продолжительность тестирования составило 18 рабочих дней.
Тестирование
Тестирование проводилось в 3 этапа: Linux – Linux, Linux – Windows, openSolaris – Windows.
Режимы работы NicTeaming (Bonding):
0 — balance-rr При передачи данных меняет интерфейсы поочередно(Round-robin).
1 — active-backup Один из интерфейсов активен. Если активный интерфейс выходит из строя, другой интерфейс присваивает MAC-адрес и становится активным. Данный режим предоставляет только отказоустойчивость и не требует специальной поддержки со стороны коммутатора.
2 — balance-xor Передачи распределяются между интерфейсами на основе формулы ((MAC-адрес источника) XOR (MAC-адрес получателя)) % число интерфейсов. Один и тот же интерфейс работает с определённым получателем. Режим даёт балансировку нагрузки и отказоустойчивость.
3 — broadcast Передаёт все пакеты на все интерфейсы объединения, обеспечивая повышения отказоустойчивости.
4 — 802.3ad Это классический IEEE 802.3ad, динамическое объединение каналов. Требует поддержки 802.3ad от коммутатора и восстановления скорости и дуплекса от драйвера каждого из интерфейсов.
5 — balance-tlb Адаптивная балансировка нагрузки передачи. Входящий трафик получается только активным интерфейсом, исходящий же распределяется в зависимости от текущей загрузки каждого интерфейса. Не требует специальной поддержки коммутатора.
6 — balance-alb Адаптивная балансировка нагрузки — обеспечивает балансировку нагрузки как передачи (TLB, transmit load balancing), так и приёма для IPv4 через ARP. Не требует специальной поддержки коммутатором, но требует возможности изменять MAC-адрес устройства.
Результаты тестирования Linux – Linux.
В качестве Операционной Системы для тестирования (ОС – сокращение в дальнейшем) был выбран дистрибутив Debian Linux Lenny stable x64.
Для установки драйверов понадобилось дополнительно установить ряд пакетов: net-tools, ethtool, ifenslave-2.6, build-essential, make.
Затем создаем bonding (он же NicTeaming), для этого создаем сетевой интерфейс bond0 который будет объединять в себе 4 интерфейса, eth1, eth2, eth3, eth4. Для этого правим файл /etc/network/interfaces
auto bond0
iface bond0 inet static
address 10.10.250.2
netmask 255.255.255.0
network 10.10.250.0
bond_mode balance-rr
bond_miimon 100
bond_downdelay 200
bond_updelay 200
slaves eth1 eth2 eth3 eth4Таким же способом на 2 компьютере создан интерфейс с IP: 10.10.250.3.
Сделали сервером компьютер с IP 10.10.250.2. Здесь и в дальнейшем условимся, что сервер – это ПК с IP адресом 10.10.250.2, а клиент – это ПК с IP адресом 10.10.250.3.
Так как мы решили тестировать по протоколу iSCSI и не ограничивать себя в скорости работы с жетскими дисками, мы будем использовать RAMDrive.
Для этого создадим на сервере RAMDrive в котором развернем iSCSI ресурс.
mount -t tmpfs -o size=3000M tmpfs /mnt/tmpfs/ затем устанавливаем iSCSI-Target
sudo apt-get install iscsi-targetПосле этого настраиваем iSCSI путем редактирования его конфигурационного файла /etc/iet/iet.conf
Target test.802:test-debian.lun0
IncomingUser
OutgoingUser
Lun 0 Path=/mnt/tmpfs/image.img,Type=fileio
Alias LUN0
MaxConnections 1И создаем само iSCSI хранилище размером 2.1Гб в RAMDriv’e емкостью 3Гб.
dd if=/dev/zero of=/mnt/tmpfs/image.img bs=1024k count=2000После чего перезапускаем службу iSCSI и службу сетевых интерфейсов
/etc/init.d/networks restart
/etc/init.d/iscsi-target restartПосле чего проверяем NicTeaming(bonding) выполнив команду:
cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.2.5 (March 21, 2008)
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200На клиенте был установлен пакет open-iscsi и перезапущены сервисы сетевых интерфейсов и iSCSI-Initiator, после чего выполнили команду
iscsiadm -m node --targetname test.802:test-debian.lun0" --portal "10.10.250.2:3260" –login Затем мы подключили iSCSI хранилище и RAMDrive выполнив
mount -t tmpfs -o size=3000M tmpfs /mnt/RAMDrive/mount –t auto /dev/sdb1 /mnt/iSCSI/ Наиболее оптимльном режимом работы оказался balance-rr, вот его результаты:
Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 185-310MB/Sec
RAMDrive -> iSCSI 135-185MB/Sec
Перезапись файла:
iSCSi -> RAMDrive 180-320MB/Sec
RAMDrive -> iSCSI 150-175MB/Sec
Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.
PING
# ping -s 65000 10.10.250.2
PING 10.10.250.2 (10.10.250.2) 65000(65028) bytes of data.
65008 bytes from 10.10.250.2: icmp_seq=503 ttl=128 time=1.34 ms
65008 bytes from 10.10.250.2: icmp_seq=504 ttl=128 time=1.31 ms
65008 bytes from 10.10.250.2: icmp_seq=505 ttl=128 time=1.32 ms
65008 bytes from 10.10.250.2: icmp_seq=506 ttl=128 time=1.34 ms
^C
— 10.10.250.2 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 507016ms
Ресурсы обоих систем Debian Linux были вполне свободны:
SWAP – 4Gb использовался 1-3%
RAM – 6Gb, из них 3Gb отведено под виртуальный диск, свободно всегда оставалось 600-800Mb.
Загрузка процессора составляла 7-30%
Загрузка сети 18-27%
Как видно из результатов, скорость передачи данных не синхронна и очень мала для заявленого 500-650М/сек по описанию технологии с применением NicTeaming’а на 4-х портах сетевого адаптера. В режиме наибольшей прорускной способности (802.3ad) оборудование CISCO зависло 2 раза.
Попытка использовать протокол NFS дала прирост в скорости чтения на 10-15%, но на столько же снизило скорость записи.
Результаты тестирования Linux – Windows
В качестве ОC сервера остался Debian Linux Lenny stable, в качестве клиентской ОС был установлен MS Windows 2003 Server Standard R2.
На клиенте был установлен RAMDrive и Microsoft iSCSI Initiator, а так же создан NicTeaming (Bonding) в режиме 4 ( 802.3ad) – так как именно в этом режиме работы были достигнуты максимальные показатели. Так же был отключен IPS и QoS, как в настройках подключения, так и через GPU (Груповая политика — mmc).
Никаких других настроек над системой не проводилось.
Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 63-70MB/Sec
RAMDrive -> iSCSI 365-400MB/Sec
Перезапись файла:
iSCSi -> RAMDrive 40-60MB/Sec
RAMDrive -> iSCSI 340-380MB/Sec
Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.
Так же были проведены тесты с помощью утилиты sqlio.
Результаты команды ping от сервера до клиента
PING
# ping -s 65000 10.10.250.3
PING 10.10.250.3 (10.10.250.3) 65000(65028) bytes of data.
65008 bytes from 10.10.250.3: icmp_seq=503 ttl=128 time=1.24 ms
65008 bytes from 10.10.250.3: icmp_seq=504 ttl=128 time=1.21 ms
65008 bytes from 10.10.250.3: icmp_seq=505 ttl=128 time=1.24 ms
65008 bytes from 10.10.250.3: icmp_seq=506 ttl=128 time=1.12 ms
^C
— 10.10.250.3 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 507003ms
Загрузка сети не поднималась больше 23%, средняя загрузка процессора составляла 48-72% на каждое ядро.
Как видно скорость передачи данных снова не синхронна и очень мала для заявленой технологии, но тем не менее скорость записи на хранилище (iSCSI) была намного выше чем между двумя одинаковыми ОС на базе Debian Linux, в результате чего далее будет проведен тест между клиентом с ОС Windows 2003 Server и серевером с предустановленой ОС openSolaris.
Результаты тестирования openSolaris – Windows
В качестве ОC сервера был установлен дистрибутив ОС UNIX (openSolaris), в качестве клиентской ОС осталась установленная ранее MS Windows 2003 Server Standard R2.
Для начала на сервере настроим Link Agregation 802.3ad, т.к openSolaris может работать только в этом режиме NicTeaming’а.
Сначала проверим доступные сетевые интерфейсы, для этого выполним
dladm show-linkДалее мы отключаем все интерфейсы которые будем использовать при создании NicTeaming’а, создадим сам NicTeaming и поднимем интерфейс с NicTeamimg’ом обратно, для этого выполняем следующие действия:
pfexec ifconfig igb0 unplumb # Выключаем интерфейсы igb0 – igb3
pfexec ifconfig igb1 unplumb
pfexec ifconfig igb2 unplumb
pfexec ifconfig igb3 unplumbpfexec dladm create-aggr -l igb0 -l igb1 -l igb2 -l igb3 aggr01pfexec ifconfig aggr01 plumb 10.10.250.2 netmask 255.255.255.0 upЗатем создадим RAMDrive объемом в 1.1Гб в который поместим наше iSCSI хранилище и создадим там файловую систему, для этого выполним следущее:
ramdiskadm -a ram1 1200m
zpool create rampool1 /dev/ramdisk/ram1zfs list rampool1 Теперь создадим iSCSI-Tagreg, для этого необходимо доставить 2 пакета в систему:
pfexec pkg install SUNWiscsit
pfexec pkg install storage-serverНастраиваем ZFS iSCSI Volume на сервере Target
# zfs create rampool1/iscsiram1Далее необходимо запустить и настроить службу iSCSI-Target, для этого делаем следущее
# svcadm enable iscsitgt — запускаем службу iscsitgt
# svcs iscsitgt
STATE STIME FMRI
online 10:25:18 svc:/system/iscsitgt:default# zfs create -b 128k -V 1100m rampool1/iscsiram1Главное здесь что поставлен размер блока 128б, если будет меньше – то это будет сказывается на производительности
# zfs set shareiscsi=on rampool1/iscsiram1 # iscsitadm create target -b /dev/zvol/rdsk/rampool1/iscsiram1 openSolaris-ISCSI-Target# iscsitadm list target -vTarget: openSolaris-ISCSI-Target
iSCSI Name: iqn.opensolaris.open.ru:02:dcd36c1f-2572-6dc5-d6b0-b5522c4daf56.openSolaris-ISCSI-Target Connections: 0
ACL list:
TPGT list:
LUN information:
LUN: 0
GUID: 0
VID: SUN
PID: SOLARIS
Type: disk
Size: 1.1G
Backing store: /dev/zvol/rdsk/rampool1/iscsiram1
Status: onlineНу вот мы имеем настроеный iSCSI-Target с NicTeaming в режиме 802.3ad.
Тестирования проводились в 2-х вариантах, 1-ый с включенным и настроеным CISCO и настроеными интерфейсами клиента и сервера на LACP и PagP, 2-ой в автоматическом режиме настройки.
Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 80-120MB/Sec
RAMDrive -> iSCSI 350-400MB/Sec
Перезапись файла:
iSCSi -> RAMDrive 80-90MB/Sec
RAMDrive -> iSCSI 350-400MB/Sec
Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.
Так же были проведены тесты с помощью утилиты sqlio.
Результаты команды ping от сервера до клиента
PING
# ping -s 65000 10.10.250.3
PING 10.10.250.3 (10.10.250.3) 65000(65028) bytes of data.
65008 bytes from 10.10.250.3: icmp_seq=503 ttl=128 time=1.27 ms
65008 bytes from 10.10.250.3: icmp_seq=504 ttl=128 time=1.11 ms
65008 bytes from 10.10.250.3: icmp_seq=505 ttl=128 time=1.12 ms
65008 bytes from 10.10.250.3: icmp_seq=506 ttl=128 time=1.17 ms
^C
— 10.10.250.3 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 506021ms
Во время работы с ненастроеной CISCO на LACP и PagP, оборудование CISCO 2-ы повисло. После повторного включения CISCO скорость передачи данных была синхронна, и на протяжении 6 минут была равно 350МВ/сек в каждую сторону. После чего снова началась рассинхронизация скорости передачи данных.
Повторить результат или понять причину не удалось.
Общее заключение
Добиться синхронных результатов скорости передачи данных хотя бы в 250-350MB/сек, так и не удалось не смотря на описание технологии где сказано что этого можно добиться. В различных условиях тестирования скорость отличалась не сильно, хотя при работе в связке openSolaris и Windows 2003 был почти достигнут желаемый результат, но повторить его так и не удалось. Возможно если повторить эксперимент позже с более новыми драйверами и другим оборудованием – результаты будут другие, но на данный момент достичь желаемого сейчас нам не удалось, возможно нужно более тщательно подбирать используемое оборудование для обеспечения лучшей совместимости. При отказе одного из интерфейсов (физическое выключение кабеля из CISCO) потери были минимальны, данные передавались сразу же на другой интерфейс. Поэтому данную технологию можно использовать для повышения отказоустойчивости работы сети.