В vmware esxi iscsi multipath — большая деградация сети. В чем может быть проблема?

Question

[Дмитрий]

Коллеги, бьюсь iscsi multipath activ\active в esxi и не могу победить проблему.

Дано:

1) VLAN4 (iSCSI-1) VLAN7 (iSCSI-2)
2) ESXI хост (2 адаптера, vDS, 2 порт-группы в разных VLAN (iSCSI-1(id4) iSCSI-2(id7)), соответственно на адаптерах IP из подсетей iSCSI
3) SDS Nexenta с настроенным мультипатчингом все в тебх же VLAN4,7. В хранилках диски SATA + SSD (RAID10).
4) На vmware в настройках path стоит round robin, чтобы добиться active\active переключения.

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

Дальше, начинаем копировать \ перемещать виртуалку с хранилища без multipath на хранилище с multipath и наблюдаем скорость около 50mbps. Отключаем один из портов на коммутаторе, который смотрит на хранилку с multipath, VMWARE отрабатывает RR, остается один активный LINK, скорость поднимается до 100-250mbps.

В чем может быть проблема?

P.S. Jumbo Frames и Link Aggregation не используем.

Answer 1

[athacker]

Тут товарищ боролся с такой же проблемой: https://forums.freenas.org/index.php?threads/iscsi...

Заявлено, что поборол. Только хранилка была FreeNAS, а не Nexenta.

Comments

[Дмитрий]

В целом да, он поборол. Верная ссылка с решением вот www.gatt-it.co.uk/the-gatt-it-blog/how-to-set-the-... . Вся загвоздка в ограничении iops в 1000. Меняем под свои значения и все начинает работать.

[athacker]

Дмитрий: А "свои" значения -- это какие? Многие вендоры в своих методичках рекомендуют ставить в Round-Robin не 1000, а 1 IOPS на канал. По крайней мере, я такое читал у HP и у IBM в руководствах к хранилкам. Но там никакого объяснения нет, почему это нужно делать. По этому поводу Дункан Эппинг однажды написал статью ( www.yellow-bricks.com/2010/03/30/whats-the-point-o... ), где заявлял, что "не вижу решительно ни одной причины, почему нужно дефолтное значение в 1000 IOPS на один path менять на что-то другое". Он там результаты тестов приводит, что ничего особо не меняется, если 1000 поменять на 1. Но дело было давно, статья 2010 года.

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

[Дмитрий]

athacker: Вообще, я попробовал поиграться со значениям большими чем 1000. И проблема ушла. С 1 IOPS играться не пробовал. Да, согласен, вендоры пишут про 1IOPS на канал, но опять-таки не понятен данный посыл. Но и 1000 IOSP на канал ИМХО маловато. Возможно есть в VMWare некое профилирование, которое не найдено мной, так как смущает в выводе к device ID подобная фраза:
IOOperation Limit: 1000
Limit Type: Default

Тоесть есть и не Default?

[athacker]

Дмитрий: конечно, есть. впишите туда что-нибудь отличное от 1000 -- вот вам и не default :-)

Вообще же, чисто по логике, не должно быть совсем никакой разницы, 1 там IOPS, 1000 или 10000. Каналы обычно симметричные в таких случаях, и мне лично непонятно вообще, почему это так влияет на производительность.

Ну точнее, в случае хранилок всё понятно. Там вообще RoundRobin использовать не рекомендуется, по логике работы системы с двумя контроллерами. Но в случае самосбора или Nexenta Community Edition (без кластеризации хранилища) производительность вообще меняться не должна в зависимости от канала.

[Дмитрий]

athacker: Но факт остается фактом... При дефолтных значениях деградация присутствует. Сегодня попробую поставить значение 1 и посмотреть что будет. Но ИМХО, какой-то это не верный путь, при учете того что хранилок штук 5, на каждой презентуется по 4-6 LUNов, около 15 серверов (нод) в кластере и изменения нужно вносить на каждой ноде для каждого LUNa.