Настройка multipath I/O в SLES10

Хорошо, я тогда опубликую тут - в виде нескольких сообщений для удобочитаемости. Писалась для нашей внутренней сети, но, думаю, применимо более широко (как удобный пример).

Введение

Общие понятия (очень кратко)
Multipath I/O - технология, при которой от компьютера до дискового устройства имеется более одного пути, реализуемого с помощью нескольких адаптеров, шин, свитчей и т.п. Используется для повышения надёжности (отказоустойчивости) и производительности (при распределении нагрузки).
В Linux данная технология реализуется с помощью драйвера Device Mapper Multipath (DM-MP), включенного в ядро, начиная с версии 2.6.13 (август 2005 года).

Применимость к нашей среде
Достаточно стандартной конфигурацией у нас является ситуация, когда для production-систем данные находятся на внешнем дисковом массиве (IBM серии DS6000 или NetApp FAS 2040/2050). Сервер в этом случае, как правило, оборудуется двумя FC-адаптерами, которые коммутируются каждый на свой FC-свитч, куда, в свою очередь, также скоммутированы и оптические интерфейсы дисковых массивов. В результате один и тот же LUN, выделенный на массиве, доступен серверу несколькими путями (2-4) через различные адаптеры, FC-свитчи и контроллеры самого массива. Массивы NetApp, которые будут рассматриваться здесь далее, не позволяют делать распределение нагрузки между своими контроллерами: каждый LUN обслуживается только одним контроллером, но может автоматически переключиться на другой в случае проблем.

Задача
Настроить multipath I/O для работы сервера SLES10sp3 с LUN-ом, выделенным на массиве NetApp. Распределение нагрузки не использовать (поскольку это не позволяет делать массив NetApp в нынешней конфигурации), но настроить отказоустойчивость.
Начальные условия: сервер IBM xSeries 3650 с двумя FC-адаптерами IBM QLE2460 (OEM QLogic QLA2432, 4Gbps). На массиве выделен LUN, доступы на FC-свитчах с помощью зон сделаны, провода скоммутированы. На сервер установлена операционная система SLES10sp3 с обновлениями.

Решение

Начальная ситуация
Без использования драйвера DM-MP Linux видит каждый путь до устройства хранения как отдельный диск, соответственно назначаются и имена устройств:

/dev/sda - первый локальный диск (на самом деле - зеркало из пары дисков, сделанное аппаратным RAID-контроллером);
/dev/sdb - второй локальный диск (аналогично, вторая пара локальных дисков);
/dev/sdc - LUN на массиве NetApp, доступный через первый FC-адаптер;
/dev/sdd - тот же самый LUN, доступный через второй FC-адаптер.

Мы хотим, чтобы в системе появилось новое поблочное устройство, соответствующее выделенному на массиве LUN-у и не зависящее от конкретного пути. Более того, мы хотим, чтобы все последующие настройки (разбиение диска, монтирование файловой системы и т.п.) ссылались на это новое устройство по имени (допустим, apps), которое бы не зависело ни от пути, ни от контроллера, ни от того, в каком порядке будут опознаны и пронумерованы системой любые другие дисковые устройства (например, при добавлении/удалении других локальных дисков или новых LUN-ов, выделенных на этом же или другом массиве).

Теория (небольшое отступление)
Драйвер DM-MP умеет "собирать" вместе разные пути к одному и тому же устройству, создавая новое поблочное устройство с отдельным именем. Все пути (до того же устройства) при этом группируются в группы путей; причём распределение нагрузки может выполняться лишь в пределах группы. В свою очередь, при отказе путей может происходить переключение на другую группу (fail-over) и возврат обратно (fail-back).Т.е. при наличии нескольких групп будет активна лишь одна из них, остальные будут резервными. При наличии нескольких путей в активной группе при отказе одного из них он просто временно исключается из этой группы (работа продолжается по остальным путям этой группы). При отказе всех путей в активной группе происходит переключение на резервную группу путей. На самом деле всё несколько сложнее, поскольку каждый путь (и группа путей) имеет ещё и свой приоритет, который тоже учитывается.
Для поставленной задачи из этого следует, что два доступных пути должны попасть каждый в свою группу.

Практика

Шаг 1. Осматриваемся
В первую очередь - убеждаемся в том, что установлен пакет multipath-tools:

nw04:~ # rpm -q multipath-tools
multipath-tools-0.4.7-34.54.1
nw04:~ #

При необходимости - устанавливаем.

Либо с командной строки (команда insserv multipathd), либо через YaST (System -> System Services (Runlevel) -> выбрать multipathd -> Enable).
Проверяем состояние демона (rcmultipathd status), при необходимости - запускаем (rcmultipathd start).
N.B.! Не путать демон multipathd (с буквой "d" в конце) и команду multipath (без этой буквы)!

Затем смотрим командой multipath -v3 -d все возможные доступные дисковые устройства и пути к ним. Эта команда выдаёт довольно много информации, но для нас важно убедиться, что она показывает все интересующие нас пути и идентифицирует устройство на "той стороне". Немного сокращённый пример:

nw04:~ # multipath -v3 -d
dm-4: device node name blacklisted
[...]
sdd: not found in pathvec
sdd: mask = 0x1f
sdd: dev_t = 8:48
sdd: size = 838914048
sdd: subsystem = scsi
sdd: vendor = NETAPP
sdd: product = LUN
sdd: rev = 7320
sdd: h:b:t:l = 4:0:1:0
sdd: tgt_node_name = 0x500a0980882cf55
sdd: serial = P3aQh4XJdfKH
sdd: getuid = /sbin/scsi_id -g -u -s /block/%n (controller setting)
sdd: uid = 360a98000503361516834584a64664b48 (callout)
sdd: prio = ontap (controller setting)
sdd: ontap prio = 4
sdc: not found in pathvec
sdc: mask = 0x1f
sdc: dev_t = 8:32
sdc: size = 838914048
sdc: subsystem = scsi
sdc: vendor = NETAPP
sdc: product = LUN
sdc: rev = 7320
sdc: h:b:t:l = 3:0:0:0
sdc: tgt_node_name = 0x500a0980882cf55
sdc: serial = P3aQh4XJdfKH
sdc: getuid = /sbin/scsi_id -g -u -s /block/%n (controller setting)
sdc: uid = 360a98000503361516834584a64664b48 (callout)
sdc: prio = ontap (controller setting)
sdc: ontap prio = 1
sdb: not found in pathvec
sdb: mask = 0x1f
sdb: dev_t = 8:16
sdb: size = 286515200
sdb: subsystem = scsi
sdb: vendor = ServeRA
sdb: product = VOL1
sdb: rev = V1.0
sdb: h:b:t:l = 2:0:1:0
sdb: serial = C4C67DD1
sdb: getuid = /sbin/scsi_id -g -u -s /block/%n (config file default)
sdb: uid = SServeRA_VOL1_C4C67DD1 (callout)
sdb: prio = const (config file default)
sdb: const prio = 1
sda: not found in pathvec
sda: mask = 0x1f
sda: dev_t = 8:0
sda: size = 143153152
sda: subsystem = scsi
sda: vendor = ServeRA
sda: product = Vol0
sda: rev = V1.0
sda: h:b:t:l = 2:0:0:0
sda: serial = 22CA3FD2
sda: getuid = /sbin/scsi_id -g -u -s /block/%n (config file default)
sda: uid = SServeRA_Vol0_22CA3FD2 (callout)
sda: prio = const (config file default)
sda: const prio = 1
sr0: device node name blacklisted
[...]
ram0: device node name blacklisted
===== paths list =====
uuid hcil dev dev_t pri dm_st chk_st vend/pr
360a98000503361516834584a64664b48 4:0:1:0 sdd 8:48 4 [undef][undef] NETAPP,
360a98000503361516834584a64664b48 3:0:0:0 sdc 8:32 1 [undef][undef] NETAPP,
SServeRA_VOL1_C4C67DD1 2:0:1:0 sdb 8:16 1 [undef][undef] ServeRA
SServeRA_Vol0_22CA3FD2 2:0:0:0 sda 8:0 1 [undef][undef] ServeRA
params = 0 0 2 1 round-robin 0 1 1 8:48 512 round-robin 0 1 1 8:32 128
status = 2 0 0 0 2 1 A 0 1 0 8:48 A 0 E 0 1 0 8:32 A 0
[...]

В данный момент важно убедиться, что sdc и sdd - это просто разные пути к одному и тому же накопителю (serial и uid у них совпадают, а Vendor и Product у них - NETAPP и LUN соответственно). Эта информация нам нужна для следующего шага.

Шаг 2. Настраиваем конфиг-файл
Драйвер DM-MP пользуется настроечным файлом /etc/multipath.conf . Изначально такой файл отсутствует, но есть пример multipath.conf.synthetic и прокомментированная версия multipath.conf.annotated , которые расположены в папке /usr/share/doc/packages/multipath-tools/ . На их основе я сделал файл, приведённый в Приложении 1. Смысл основных параметров приведён ниже в Приложении 2.
NB! Если кто-то ещё будет делать конфигурацию "с нуля", то имейте в виду, что в дистрибутивах SUSE утилиты scsi_id и mpath_prio_* расположены не там, где указано в этих файлах-примерах, а в /sbin/ .

Шаг 3. Пытаемся взлететь
Просим драйвер прочитать наши настройки:

multipath -v2 -l

и смотрим, что получилось:

Код: Выделить всё: nw04:~ # multipath -ll apps (360a98000503361516834584a64664b48) dm-0 NETAPP,LUN [size=400G][features=0][hwhandler=0] \_ round-robin 0 [prio=4][active] \_ 4:0:1:0 sdd 8:48 [active][ready] \_ round-robin 0 [prio=1][enabled] \_ 3:0:0:0 sdc 8:32 [active][ready] nw04:~ #

В данном примере мы видим, что есть одно multipath-устройство с именем dm-0 и длинным uid, указанным в первой строчке в скобках. Этому устройству назначен алиас apps. Устройство доступно по двум путям, каждый находится в своей группе. Первая группа - активна, имеет приоритет 4 (чем больше число, тем выше приоритет) и содержит путь через устройство sdd. Вторая группа имеет приоритет 1 и пока в статусе запасной (enabled), в ней тоже только один путь - через устройство sdc.

Кроме того, если посмотеть содержимое директории /dev , то можно заметить, что появились следущие файлы:

/dev/dm-0 - первое поблочное устройство, созданное device mapper-ом (потом могут появиться dm-1, dm-2 и т.д.);
/dev/mapper/apps - то же самое устройство, но имеющее постоянное имя (заданное нами в конфиг. файле). При создании дисковых разделов тут могут появиться apps-part1, apps-part2 и т.д.
/dev/disk/by-name/apps - символическая ссылка на /dev/dm-0 . В отличие от последнего, имеет постоянное имя. Именно это имя и рекомендуется использовать в дальнейшем во всех конфигах. Аналогично предыдущему пункту, при создании партишенов появятся файлы (символические ссылки) с именами apps-part1, apps-part2 и т.д.

Шаг 4. Необязательный
Если надо поменять содержимое конфиг. файла, то для перечитывания его содержимого последовательность действий такая:

остановить демон multipathd:
- rcmultipathd stop
очистить прежнюю конфигурацию:
- multipath -f
заново собрать разные пути в одно устройство:
- multipath -v2 -l
заново запустить демон:
- rcmultipathd start

Шаг 5. Последние причёсывания перед перезагрузкой

Убеждаемся, что соответствующие службы выставлены в автозагрузку:
- chkconfig multipathd on
- chkconfig boot.multipath on
Убеждаемся, что соответствующий драйвер FC-адаптера добавлен в загрузочный образ. В нашем случае (для адаптеров QLogic) это драйвер qla2xxx. Он должен быть упомянут в строчке для переменной INITRD_MODULES в файле /etc/sysconfig/kernel . При необходимости можно добавить вручную.
Для драйвера адаптеров QLogic добавить параметр, диктующий им любые ошибки ввода/вывода тут же сообщать следующему уровню (в данном случае - драйверу DM-MP), а не пытаться обрабатывать самостоятельно. Для этого нужно в файл /etc/modprobe.conf.local добавить следующую строчку:
- options qla2xxx qlport_down_retry=1
После всех настроек - пересоздать загрузочный образ командой mkinitrd . После этого можно перезагрузиться и проверить конфигурацию.

Приложения

Приложение 1. Пример файла multipath.conf

Код: Выделить всё: ## ## This is a template multipath-tools configuration file ## Uncomment the lines relevent to your environment ## defaults { udev_dir /dev polling_interval 10 selector "round-robin 0" # path_grouping_policy multibus # getuid_callout "/lib/udev/scsi_id -g -u -s /block/%n" # prio const # path_checker directio rr_min_io 100 max_fds 8192 rr_weight priorities failback immediate no_path_retry fail user_friendly_names no } blacklist { # wwid 26353900f02796769 devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^hd[a-z][[0-9]*]" devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]" #disable multipathing for ServeRAID device { vendor ServeR.* product VOL1|Vol0 } } #blacklist_exceptions { # devnode "^dasd[c-d]+[0-9]*" # wwid "IBM.75000000092461.4d00.34" #} multipaths { multipath { wwid 360a98000503361516834584a64664b48 alias apps } # multipath { # wwid 1DEC_____321816758474 # alias red # path_grouping_policy multibus # path_checker directio # path_selector "round-robin 0" # failback manual # rr_weight priorities # no_path_retry 5 # rr_min_io 100 # } } devices { device { vendor "NETAPP" product "LUN.*" path_grouping_policy "group_by_prio" getuid_callout "/sbin/scsi_id -g -u -s /block/%n" # prio_callout "/sbin/mpath_prio_ontap /dev/%n" features "1 queue_if_no_path" prio "ontap" rr_min_io "128" } # device { # vendor "COMPAQ " # product "HSV110 (C)COMPAQ" # path_grouping_policy multibus # getuid_callout "/lib/udev/scsi_id -g -u -s /block/%n" # path_checker directio # path_selector "round-robin 0" # hardware_handler "0" # failback 15 # rr_weight priorities # no_path_retry queue # rr_min_io 100 # product_blacklist LUN_Z # } # device { # vendor "COMPAQ " # product "MSA1000 " # path_grouping_policy multibus # } }

Приложение 2. Комментарии к файлу multipath.conf
В нашем примере файл содержит 4 секции:

Секция defaults содержит умолчания: настройки, которые используются, если не задано где-то ещё. В частности, параметр polling_interval задаёт периодичность опроса состояния каждого пути.
Секция blacklist определяет список поблочных устройств, которые драйвером DM-MP обрабатываться не должны. Это либо устройства, которые заведомо не относятся к технологии multipath I/O (как loop или ram), либо устройства, которые создаются самим этим или аналогичным драйвером (dm-, md). Директива devnode называет устройства по имени спец. файла (в директории /dev); мы же сюда добавили ещё и подсекцию device, в которой описали локальные диски (парой Vendor/Product). Как видно из этого примера, допустимы регулярные выражения.
Секция devices (с одной подсекцией device) в нашем случае относится к нашему дисковому массиву. Если устройство показывает Vendor-а и Product как NETAPP и LUN* соответственно (а это будет так для всех LUN-ов, расположенных на массиве NetApp), то применяем к такому устройству настройки из этой секции. В данном случае используется политика группировки путей в группы (параметр path_grouping_policy) по приоритету, т.е. для каждого значения приоритета создаётся отдельная группа путей. Сам приоритет, в свою очередь, вычисляется с помощью внешней программы (параметр prio_callout), которая знает специфику работы с массивами NetApp (mpath_prio_ontap). Т.е. значения приоритетов 1 и 4 из данного примера были вычислены этой программой, которая сама определила, через какой из путей работать выгоднее (т.е. какой из них ведёт к "правильному" контроллеру массива).
Секция multipaths (с одной подсекцией multipath) является ещё более специализированной и, соответственно, более приоритетной, чем секция devices. В данном случае она относится к конкретному LUN-у на дисковом массиве и задаёт постоянный алиас для него по его UID. Благодаря этому для данного LUN-а будут созданы файлы устройств (в директории /dev) с фиксированным именем, которое не зависит ни от путей, ни от аппаратной конфигурации сервера: какие бы ещё адаптеры, диски, массивы и LUN-ы мы к нему ни добавляли, имя устройства для данного LUN-а останется постоянным.

[

конец статьи

]