Чудеса с multipath-ом в NW6.5SP5

[Сергей Дубров]

Играюсь тут с multipath-ом на Netware 6.5SP5. Использую средства Netware и оно вроде бы работает, но как-то странно:

1. Failover происходит не всегда чётко (имитирую отказ выдёргиванием активного кабеля), пару раз сервер просто подвисал.

2. После имитации отказа и успешного failover-а скорость линейного чтения с массива возрастает почти ровно в два раза! Никакой load balancing при этом не активен, один из кабелей в этот момент физически ВЫДЕРНУТ!

Скорость замеряю портлоковским stormgr-ом, читаю блоками по 128 секторов (64 кб, как выяснилось, это "любимый" размер у этого железа - больше/меньше - скорость падает). До fail-а скорость в районе 140-150 Мбайт/сек, после - до 270! Если воткнуть на место "отказавший" кабель и дождаться failback-а - скорость остаётся на прежнем (высоком) уровне. Перезагружаешь сервер - опять 140-150 максимум. Чудеса!

Железо: MSA2000 G3 с FC 8G (работает через брокэйдовский 8G коммутатор), плата PCI-E 8x QLogic 2562 (8G, двухпортовая), воткнута в 16x слот обычного десктопа (тестовый сервер). Оба порта от FC-платы через коммутатор воткнуты в FC-порты разных контроллеров MSA. Софт: NW6.5SP5 с ручным апдейтом винсока, драйвер QL2x00.HAM v7.00d (последний на сегодня). STARTUP.NCF выглядит так:

Код: Выделить всё

SET MULTI-PATH SUPPORT = ON
LOAD ACPIDRV.PSM
######## End PSM Drivers ########
LOAD IDECD.CDM
LOAD IDEHD.CDM
LOAD SCSIHD.CDM AEN
######## End CDM Drivers ########
LOAD IDEATA.HAM SLOT=10011
LOAD IDEATA.HAM SLOT=10012
LOAD QL2x00.HAM SLOT=10019 /LUNS /ALLPATHS /ALLPORTS /PORTDOWN=1 /LINKDOWN=1 /FAILBACK=20 /CONSOLE /HPLEDS /QUALIFIED /MAXLUNS=128 /XTIMEOUT=120
LOAD QL2x00.HAM SLOT=10018 /LUNS /ALLPATHS /ALLPORTS /PORTDOWN=1 /LINKDOWN=1 /FAILBACK=20 /CONSOLE /HPLEDS /QUALIFIED /MAXLUNS=128 /XTIMEOUT=120
######## End HAM Drivers ########
LOAD KEYB.NLM Russia
LOAD CHARSET.NLM CP866


Не помню, где я нашёл такую длинную и красивую строку для QL2x00.HAM, но с ней failover худо-бедно заработал. Если убрать строки /ALLPATHS /ALLPORTS (== /PORTNAMES), т.е. попытаться использовать multipath средствами встроенными в HAM-драйвер - вообще не работает.

У кого какой опыт по этому поводу имеется?

P.S. В последний месяц много игрался с iSCSI - собрал все, какие можно шишки, зато теперь пришло полное и уверенно понимание, что и как нужно делать, главное - подобрать нужную комбинацию компонентов . Через некоторое время соберусь, опишу результаты (запись на клиенте получал до 50 Мбайт/сек, это БЕЗ оптимизаций типа jumbo frames).

[xxlsuper]

P.S. В последний месяц много игрался с iSCSI - собрал все, какие можно шишки, зато теперь пришло полное и уверенно понимание, что и как нужно делать, главное - подобрать нужную комбинацию компонентов . Через некоторое время соберусь, опишу результаты (запись на клиенте получал до 50 Мбайт/сек, это БЕЗ оптимизаций типа jumbo frames).

Интересно увидеть описание как и что делать, у нас в рабочем сервере по iscsi как в прочем и при записи на раид, более 30 МБайт/сек скорость выжать не получается, хотя сервер вроде неплох, Fuijtsu RX300S3 2 Xeon 3550, 2 GB RAM, 2x1Gb broadcom 5715 lan, комутатор cisco 3750G, iscsi software target - Starwind v5.0 и также пробовали M$ iscsi target Win 2008 R2

[Сергей Дубров]

Про iSCSI я напишу позже, недельки через полторы-две, сейчас другим занимаюсь. Совершенно ошарашен сложностью и неудобством включения поддержки MPIO (multipath) в линухе. По сравнению с NW и вендой - жуть как непросто. Сначала последовал рекомендациям и скачал последнюю версию multipathtool с производителя (HP), но он не поддерживает SLES 11 SP1, только SLES 11 максимум. А вручную там... мама не горюй. Тут и редактирование /etc/multipath.conf, и активизация multipathd и т.д. Кошмар

[Константин Ошмян]

Сергей, приветствую!

У меня работает мультипас на NetWare, кажется, я об этом писал. Соврешенно без проблем; правда, у меня SP8 (со всеми текущими пост-фиксами), и вся FC-инфраструктура (адаптеры/свитчи/дисковый массив) на 4Гб. Конфигурация в STARTUP-е - аналогична твоей, но без лишних параметров (они и так по дефолту в разумные значения выставляются):

Код: Выделить всё

SET MULTI-PATH SUPPORT = ON
[...]
LOAD QL2X00.HAM SLOT=3 /LUNS /ALLPATHS /PORTNAMES /CONSOLE
LOAD QL2X00.HAM SLOT=4 /LUNS /ALLPATHS /PORTNAMES /CONSOLE

Единственная проблема, которая была, возникала при имитации сгорания джибика на свитче, обращённого в сторону массива (т.е. когда физическая связь "адаптер в сервере" <-> "свитч" есть, но пользоваться этим линком нельзя, т.к. он дальше обрывается). Но эта проблема решилась обновлением драйвера QL2X00 как раз до "твоей" версии 7.0.d.

Ну и при переключении на мультипас средствами драйвера - не забывать выключить указанный SET.

С мультипасом для Линукса я тоже разбирался - тут по анекдоту: "Ну, ужас. Но не ужас-ужас-ужас!" Могу написать по шагам, что у меня вышло.

[Сергей Дубров]

Привет, Константин!

Сергей, приветствую!
...
Ну и при переключении на мультипас средствами драйвера - не забывать выключить указанный SET.

Хм, странно, а в ридми у qlogic-а написано немного другое:

"If you want to use NetWare Multi-Path IO (MPIO), you need to ensure that startup.ncf contains the following
line before loading any drivers:

SET MULTI-PATH SUPPORT = ON

NOTE: QLogic recommends using this line regardless of whether you want NetWare MPIO failover or QLogic
HAM failover."

С мультипасом для Линукса я тоже разбирался - тут по анекдоту: "Ну, ужас. Но не ужас-ужас-ужас!" Могу написать по шагам, что у меня вышло.

Напиши, если несложно. А то я уже начал потрошить содержимое скрипта INSTALL из хипишного "Device Mapper Multipath Enablement Kit for HP StorageWorks Disk Arrays" (v4.4.1 (14 Jan 2011)). Несмотря на "свежесть" кита, поддержки SLES 11 SP1 в нём так и нет . Сделал уже:

chkconfig multipathd on
chkconfig boot.multipath on

вручную запустил

/etc/init.d/boot.multipath start
/etc/init.d/multipathd start

После чего multipath -ll стала выдавать вот такое:

Код: Выделить всё

zzz:/tmp # multipath -ll
3600c0ff000dae83a931d504d01000000 dm-0 HP,P2000G3 FC/iSCSI
size=279G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=150 status=active
| `- 4:0:0:0 sdb 8:16 active ready running
|-+- policy='round-robin 0' prio=10 status=enabled
| `- 4:0:1:0 sdc 8:32 active ready running
|-+- policy='round-robin 0' prio=150 status=enabled
| `- 5:0:0:0 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
  `- 5:0:1:0 sde 8:64 active ready running


Теперь, как я понимаю, нужно отредактировать /etc/multipath.conf ? В качестве шаблона взял хипишный HPDMmultipath-4.4.1/conf/multipath.conf.HPTemplate.SLES11 - но, несмотря на комментарии и подсказки в файле, быстро разобраться с содержимым не удалось.

[Константин Ошмян]

Про SET MULTI-PATH SUPPORT ты прав - извини, это я [с прямым углом попутал] с IBM-овским драйвером SDD спутал.

Сергей, я всё это делал на SLES10sp3 (мне нужно было для OES2). Не знаю - большая ли разница со SLES11sp1 (там я просто не смотрел). Я бы выложил, наверное, свою заметку в "Грабли" (поскольку целая статья по объёму), но у меня нет прав создать там новую тему.

Можно попросить админов завести в разделе "Грабли" тему "Настройка multipath I/O в SLES10"

[Timur Kazimirov]

у нас в рабочем сервере по iscsi как в прочем и при записи на раид, более 30 МБайт/сек скорость выжать не получается

Для указанной конфигурации чтение со стораджа на клиент 30 МБайт/сек не такая уж и плохая скорость (можно, разумеется, и повыше, скажем до 50, но это не принципиально), а вот на запись тут явно что-то не так.

[Сергей Дубров]

Про SET MULTI-PATH SUPPORT ты прав - извини, это я [с прямым углом попутал] с IBM-овским драйвером SDD спутал.

Насколько я в этом деле разобрался, у разных производителей поддержка multipath может быть реализована по-своему, в т.ч. и требующая выключения SET MULTI-PATH SUPPORT. Так что запутаться легко .

Сергей, я всё это делал на SLES10sp3 (мне нужно было для OES2). Не знаю - большая ли разница со SLES11sp1 (там я просто не смотрел).

Есть там разница, н-р, при перегенерации initrd с поддержкой мультипаса раньше надо было писать 'mkinitrd -f mpath', сейчас - 'mkinitrd -f multipath'. Ещё есть отличия, но они не очень принципиальны (хотя в мануалах описываются для каждой версии отдельно), но могут крови попортить, если буквально следовать инструкции не от той версии .

Я бы выложил, наверное, свою заметку в "Грабли" (поскольку целая статья по объёму), но у меня нет прав создать там новую тему.

Можно попросить админов завести в разделе "Грабли" тему "Настройка multipath I/O в SLES10"

Что-то я с ходу не нашёл, как там открыть тему . Константин, давай ты напишешь это здесь, а я перенесу сообщение в "Грабли".

UPD: перенос в "Грабли" мне тоже недоступен (логично, коль создать тему с нуля я там тоже не могу). Тогда надо Юру Белякова просить. Но ты пиши, а уж перенести в нужный раздел это всегда успеется .

[Сергей Дубров]

NB! Если кто-то ещё будет делать конфигурацию "с нуля", то имейте в виду, что в дистрибутивах SUSE утилиты scsi_id и mpath_prio_* расположены не там, где указано в этих файлах-примерах, а в /sbin/ .

Костя, спасибо огромное, очень хорошее и полезное описание. Но, как я и говорил, отличия для разных версий SLES есть. Н-р, в SLES11 SP1 утилита scsi_id "живёт" как раз в /lib/udev/, а не в /sbin/, как у тебя. Это в хипишном файле-шаблоне учтено (я там это и подсмотрел в примере для SLES11).

[Константин Ошмян]

Да, конечно. Я потому и просил в "Граблях" озаглавить статью как "Настройка multipath I/O в SLES10". Думал, что когда буду разбираться со SLES11sp1 (без sp теперь уже точно не буду ), то пройдусь по ней ещё разочек и добавлю ещё одно приложение - "Отличия для SLES11".

[Сергей Дубров]

Так пока руки и не дошли до написания настройки iSCSI в NW, постараюсь ближе к выходным сделать. У меня другой вопрос в связи с этим: не могу найти ни точного подтверждения ни опровержения - поддерживается ли multipath в Netware для iSCSI? Вот у M$ всё чётко и конкретно (http://www.microsoft.com/windowsserver2 ... o/faq.mspx):

Q. Does Microsoft MPIO work with iSCSI?
A. Yes, Microsoft MPIO is fully compatible with the Microsoft iSCSI Initiator.

Для NW натыкался на упоминание, что multipath для iSCSI поддерживается, но только для fault tolerance, а load balancing в пожеланиях. Но хотелось бы поконкретнее - даже для ft других подтверждения поддержки multipath-а я не вижу. Встречались рекомендации использовать network card teaming, со словами, что это точно обеспечит ft, но, поскольку пара инициатор-target одна, никакого load balanced в принципе не будет.

Вопрос: SET MULTI-PATH SUPPORT = ON в startup.ncf - действует ли для iSCSI? В первом приближении устроит даже FT (будем использовать двухпортовые интеловские адаптеры), хотя и от load balancing не откажусь

[Константин Ошмян]

У меня другой вопрос в связи с этим: не могу найти ни точного подтверждения ни опровержения - поддерживается ли multipath в Netware для iSCSI?
[...]
Для NW натыкался на упоминание, что multipath для iSCSI поддерживается, но только для fault tolerance, а load balancing в пожеланиях. Но хотелось бы поконкретнее - даже для ft других подтверждения поддержки multipath-а я не вижу.

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

Ну вот, хотел сослаться на новелловскую документацию - а они после выхода OES2SP3 убрали с сайта мануалы по NetWare
Но у нас в загашниках осталось в виде PDF-ов , поэтому процитирую, но придётся поверить на слово.

То, что встроено в NetWare на уровне операционки, поддерживает multipath при доступе к томам NSS, но лишь для fault tolerance, а не для load balancing. Собственно, в мануале Novell Storage Services(TM) File System Administration Guide (stor_nss_lx_nw.pdf) глава 14 (Managing Multipath I/O to Devices (NetWare)) начинается со следующих утверждений:

Novell® Storage Services(TM) for NetWare® supports multipath I/O (MPIO), a fault-tolerant and highavailability storage solution. This section describes how to configure and manage multipath I/O for devices on NetWare. (прим.: про load-balancing ни слова)

14.1 Planning Your Multipath I/O Solution for NSS on NetWare
Media Manager for NetWare supports multipath I/O to dynamically manage multiple, redundant connection paths between a server and its external storage devices, according to priorities you set. A single path serves as the primary, active interconnect; the other paths serve as failover paths. In the event of a failure in the active interconnect, NSS automatically and dynamically recovers to another available failover path. This feature is only available if you have multiple interconnect paths in your server-to-storage configuration.
[...]
IMPORTANT: The NSS Media Manager supports fault tolerance with its multipath solution; it does not support load balancing across the multiple paths. Some third-party multipathing systems support load balancing across the multiple connection paths. When you use third-party multipath solutions, make sure you do not turn on Media Manager multi MPIO.

Что же касается мультипасинга применительно именно к iSCSI, то соответствующий мануал (OES 2 : iSCSI 1.1.3 for NetWare Administration Guide, stor_iscsi_nw.pdf) вообще ни о чём подобном не упоминает. Так что, похоже, и вправду надёжнее будет сделать через транк средствами драйвера эзернет-адаптера.

[Сергей Дубров]

У меня другой вопрос в связи с этим: не могу найти ни точного подтверждения ни опровержения - поддерживается ли multipath в Netware для iSCSI?
[...]
Для NW натыкался на упоминание, что multipath для iSCSI поддерживается, но только для fault tolerance, а load balancing в пожеланиях. Но хотелось бы поконкретнее - даже для ft других подтверждения поддержки multipath-а я не вижу.

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

Я, может, не очень точно выразился - да, именно так, ты прав - в NW multipath поддерживает только отказоустойчивость, причём гарантировано только при работе по fc, про iscsi - ни звука. Про load balancing было вскользь упомянуто в одном из тидов, типа desired feature. Было это году в 2007, но так ничего по этому и не изменилось.

Так что, похоже, и вправду надёжнее будет сделать через транк средствами драйвера эзернет-адаптера.

Да, похоже, что это действительно будет самый простой и работающий вариант, по крайней мере, ft будет обеспечен точно. Load balancing, скорее всего, в этом варианте не получится сделать вообще - P2000 G3, которую мы в итоге будем покупать, не умеет ethernet-ы в транки собирать (в отличие от, скажем, P4000 ex LeftHand, где это совершенно штатная функция - чистый линуховый bonding).

А вот интересно, если я один и тот же lun через разные контроллеры презентую - как она (NW) себя вести будет? Крышу ей не сорвёт? Уточнение схемы: есть двухпортовый eth-адаптер, каждый порт из сервера идёт на свой коммутатор (коммутаторы между собой не связаны). Как нужно настраиваться в этом случае? Ведь я буду "видеть" один и тот же lun в четырёх экземплярах (два порта X два контроллера, включены перекрёстно в каждый из коммутаторов).

[Константин Ошмян]

А вот интересно, если я один и тот же lun через разные контроллеры презентую - как она (NW) себя вести будет? Крышу ей не сорвёт? Уточнение схемы: есть двухпортовый eth-адаптер, каждый порт из сервера идёт на свой коммутатор (коммутаторы между собой не связаны). Как нужно настраиваться в этом случае? Ведь я буду "видеть" один и тот же lun в четырёх экземплярах (два порта X два контроллера, включены перекрёстно в каждый из коммутаторов).

Думаю, что в этом случае можно воспользоваться штатным мультипасингом от операционки. Мне кажется, что ему-то пофигу, как ты до устройства добираешься - через FC, iSCSI или ещё как (может, ты два обычных SCSI-контроллера в сервер воткнул и подцепил на одну SCSI-шину для отказоустйчивости). Главное, что есть несколько путей до одного и того же устройства (LUN-а) - значит, можно собирать эти пути в один девайс штатным мультипасингом. Но, как мы уже выяснили, тогда распределения нагрузки точно не будет - только отказоустойчивость.

[Сергей Дубров]

А вот интересно, если я один и тот же lun через разные контроллеры презентую - как она (NW) себя вести будет? Крышу ей не сорвёт? Уточнение схемы: есть двухпортовый eth-адаптер, каждый порт из сервера идёт на свой коммутатор (коммутаторы между собой не связаны). Как нужно настраиваться в этом случае? Ведь я буду "видеть" один и тот же lun в четырёх экземплярах (два порта X два контроллера, включены перекрёстно в каждый из коммутаторов).

Думаю, что в этом случае можно воспользоваться штатным мультипасингом от операционки. Мне кажется, что ему-то пофигу, как ты до устройства добираешься - через FC, iSCSI или ещё как (может, ты два обычных SCSI-контроллера в сервер воткнул и подцепил на одну SCSI-шину для отказоустйчивости). Главное, что есть несколько путей до одного и того же устройства (LUN-а) - значит, можно собирать эти пути в один девайс штатным мультипасингом. Но, как мы уже выяснили, тогда распределения нагрузки точно не будет - только отказоустойчивость.

Да, я тоже склоняюсь к этой мысли - это уже забота ос, как ей разбираться с несколькими экземплярами одного и того же lun-а, ведь, в конце-концов, используется самый обычный SCSIHD.CDM, который в курсе, что один и тот же диск (lun) может быть доступен боле чем по одному пути. Плохо, что это нигде явно в документации не расписывается, приходится гадать/экспериментировать. На стенде у меня была машина с одним выделенным iSCSI-интерфейсом, но СХД "смотрела" в сеть в четырёх экземплярах (два контроллера по два гигабитных интерфейса каждый), т.е., один и тот же lun был виден четыре раза - и новеловский iscsi работал нормально. Вот только ft проверить не удалось - на машине второго iscsi-ethernet-а не было, а бегать в зал, чтобы оторвать один из четырёх интерфейсов схд для тестирования failover-а, было далековато .

Кстати, я обещал написать про iscsi поподробнее - это я сделаю, но сейчас пока хочу отметить одну вещь, которую уже подтвердили многие - реализация iscsi в SP8 хуже, чем в SP7, самое заметное - значительно ниже скорость работы.