LINUX.ORG.RU
ФорумAdmin

Linux iSCSI target + VMWare initiator + Bonding


0

3

День добрый.

Вопрос не только и не столько по линуксу, но надеюсь мне кто-нибудь поможет.

Дано: Linux сервер в качестве iSCSI таргета (SCST), свищЪ цыско 3750X, VMWare ESXi 5.0 в качестве инициатора iSCSI:

Схема простая (на деле инициаторов больше, но для простоты один):

[ LINUX ] <--- 4 x 1G bonding ---> [ Catalyst 3750-X ] <--- 4 x 1G bonding ---> [ ESXi ]
На таргете на bond-интерфейсе подняты 4 айпишника из разных подсетей /24, на ESXi аналогично.

Со стороны инициатора iSCSI-таргет видится как раз через эти 4 адреса и настроен Multipath I/O для аггрегации каналов.

Проблема: ускорение работы iSCSI получаю только при записи на таргет, а при чтении выше 110MB/s никак получить не могу:

root@debian-service:/# dd of=/dev/sdb if=/dev/zero bs=16M count=1024
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB) copied, 68.1552 s, 252 MB/s

root@debian-service:/# echo 3 > /proc/sys/vm/drop_caches

root@debian-service:/# dd if=/dev/sdb of=/dev/null bs=16M count=1024
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB) copied, 156.66 s, 110 MB/s

При этом траффик равномерно распределяется между интерфейсами как на линуховом таргете, так и на цыске, которая разбрасывает пакеты в порты, к которым подключен ESXi:

stack.3750x#sh int gi1/0/16 | i packets output
     3999028 packets output, 6024197158 bytes, 0 underruns
stack.3750x#sh int gi2/0/16 | i packets output
     3999193 packets output, 6024212765 bytes, 0 underruns
stack.3750x#sh int gi1/0/10 | i packets output
     4017750 packets output, 6038267108 bytes, 0 underruns
stack.3750x#sh int gi2/0/10 | i packets output
     3999012 packets output, 6024197456 bytes, 0 underruns

Т.е. алгоритм балансировки вроде как работает, но почему-то в одном направлении всё-таки появляется затык в 1Гбит/cек.

Посоветуйте в какую сторону глядеть. На стороне таргета затыков нет, запись и чтение локально идут с одинаковой скоростью.

«алгоритм балансировки вроде как работает» и «всё-таки появляется затык в 1Гбит/cек» - какие то противоречивые утверждения. Посмотри точные скорости по каждому порту.

ventilator ★★★ ()

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

val-amart ★★★★★ ()
Ответ на: комментарий от ventilator

Алгоритм балансировки работает в том смысле, что драйвер bonding и цыска разбрасывают пакеты по интерфейсам, входящим в bond равномерно, как и нужно, но где-то судя по всему образовывается боттлнек... Причем я грешу именно на линуховую сторону, т.к. при чтении с таргета распределением пакетов занимается отправляющая сторона, т.е. iSCSI таргет.

Скорость по каждому порту составляет получается 25% от гигабита.

blind_oracle ★★★★★ ()
Ответ на: комментарий от val-amart

Соединение инициатора и таргета - это одна TCP сессия, которую бондинг не может размазать на 4 интерфейса. Точнее линуховый бондинг в режиме round-robin может, но это косяк, т.к. появляются пакеты вне очереди и т.п. Да и по скорости 4 гигабитных интерфейса дадут в лучшем случае 2.7Гбит судя по докам к ядру.

Поэтому поверх бондинга строится multipath, а это уже 4 сессии, которые хорошо раскладываются по интерфейсам. В VMWare врубается режим round-robin для этого таргета и траффик идёт по всем сессиям равномерно. В моем случае при записи так и есть.

Я бы отказался от бондинга вообще для упрощения структуры, но интерфейсов не так много и выделить 4 из них чисто под iSCSI больно жирно.

Конфиги запостю завтра, но там ничего волшебного: 1. на таргете обычный 802.3ad (LACP) bonding из четырёх интерфейсов в режиме layer2+3 2. на свитче, соответственно, тоже LACP в сторону таргета и static etherchannel в сторону ESXi т.к. он LACP не умеет. Режим балансировки src-dst-ip. 3. на ESXi сделаны 4 vmkernel интерфейса под iscsi и каждый привязан к одному физическому интерфейсу.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Флоу контрол не пробовал выключать на свитчах/сетевках? Выключи и посмотри не появятся ли дропы.

ventilator ★★★ ()
Ответ на: комментарий от blind_oracle

чисто ради теста, можешь попробовать просто мультипасинг? честно говоря, ничего толкового на ум не приходит..

val-amart ★★★★★ ()
Ответ на: комментарий от ventilator

На цыске оно по дефолту вырублено, на сетевухах посмотрю, но врядли дело в нем т.к. в статистике пауз-кадров не видел...

blind_oracle ★★★★★ ()
Ответ на: комментарий от val-amart

Да, мне тоже не приходит :) со стороны инициатора по сути уже и так просто мультипасинг т.к. каждый айскази порт привязан к одному физическому. Попробую то же самое на линуксовой стороне.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

root@debian-service - это виртуалка внутри vmware? Насколько я помню то в esxi включено кеширование записи по дефолту, памяти на хост машине больше чем 17 гигов?

ventilator ★★★ ()

А как там с загрузкой проца и прочего? Может затык не в сети, а в железе?

Дисковая подсистема обеспечивает скорость? Без iSCSI скорость какая по той же схеме?

aleks13 ()
Ответ на: комментарий от ventilator

Да, виртуалка, к которой подключен этот iSCSI диск в режиме Raw Mapped LUN.

На хост машине 96Гб памяти, но большая ее часть забита другими виртуалками, да и на таргете я вижу при записи резко возросшую нагрузку на проц и I/O, а при чтении она в 2-3 раза меньше, как раз соответственно разнице в скоростях read & write.

Сам таргет достаточно мощный и может вытянуть гораздо большую нагрузку, так что затык не в его производительности.

blind_oracle ★★★★★ ()
Ответ на: комментарий от aleks13

Загрузка незначительная, там Xeon E3 3.3Ghz, при чтении нагрузка процентов 10-20 на одном ядре, остальные курят бамбук. При записи серьёзнее, но тоже далеко не предел, idle еще дофига.

blind_oracle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.