Тестирование технологии 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

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/bond0


Ethernet 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.

Затем мы подключили iSCSI хранилище и RAMDrive выполнив
mount -t tmpfs -o size=3000M tmpfs /mnt/RAMDrive/

mount –t auto /dev/sdb1 /mnt/iSCSI/ 
— /dev/sdb1 – это сетевое iSCSI хранилище, посмотреть новый диск в системе можно с помощью fdisk –l после выполнения команды iscsiadm описаной выше.

Наиболее оптимльном режимом работы оказался 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 unplumb

pfexec dladm create-aggr -l igb0 -l igb1 -l igb2 -l igb3 aggr01
# Создаем NicTeaming в режиме 802.3ad
pfexec ifconfig aggr01 plumb 10.10.250.2 netmask 255.255.255.0 up
# Поднимаем настроеный интерфейс NicTeaming’a aggr01 и задаем ему IP и маску подсети.

Затем создадим RAMDrive объемом в 1.1Гб в который поместим наше iSCSI хранилище и создадим там файловую систему, для этого выполним следущее:

ramdiskadm -a ram1 1200m
zpool create rampool1 /dev/ramdisk/ram1

zfs list rampool1 
# Проверим новый пул созданный из RAM.

Теперь создадим 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
— создали том zfs на 1.1Гб

Главное здесь что поставлен размер блока 128б, если будет меньше – то это будет сказывается на производительности

# zfs set shareiscsi=on rampool1/iscsiram1 
— добавили в настройки тома
# iscsitadm create target -b /dev/zvol/rdsk/rampool1/iscsiram1 openSolaris-ISCSI-Target
— создаем target iscsi для нашего пула
# iscsitadm list target -v
— проверяем создание таргета, отсюда берем инфу для конфигурации сервера – initiator

Target: 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) потери были минимальны, данные передавались сразу же на другой интерфейс. Поэтому данную технологию можно использовать для повышения отказоустойчивости работы сети.


0 комментариев

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.