9211-8i HBA (режим IT) с расширителем Supermicro
Мне удалось добиться того, что все мои диски отображаются с "multipath -l". Теперь вопрос, как добавить их в ZFS Zpool? Все попытки использования имен dm* naming или /dev/mapper заканчиваются неудачей, когда устройство занято или уже активно. Я не могу найти правильный синтаксис для vdev_id.conf либо. dmesg определенно сообщает обо всех моих расширителях, и все 24 накопителя перечислены по одному для каждого расширителя. LSI говорит, что они не поддерживают эту функцию в 9211-8i. Это всего лишь часть "поддерживаемых функций", но покупатель должен выяснить, как заставить работать аварийное переключение или многолучевое распространение. Конечно, они предлагают более комплексное решение, в котором они поддерживают эти вещи. Шокер
Может кто-нибудь прокомментировать или указать мне в правильном направлении на следующее. Я устанавливаю коробку CentOS (Rocks6) с LBA 9211-8i HBA (режим IT) и расширителем Supermicro SAS (24 накопителя). Если я подключу оба кабеля к расширителю, я получу 48 устройств, и я предполагаю, что мне нужно настроить многолучевое распространение из прочитанного. Но я не могу найти подходящее руководство для создания работающего multipath.conf. Multipath, похоже, способен обнаруживать все совпадающие идентификаторы устройств, но я никогда не получаю никаких устройств, перечисленных в multipath -l. И я не уверен, поддерживает ли эта установка многолучевое распространение или просто аварийное переключение. Я думаю, что может не хватать способности водителя выяснить, какие устройства имеют более высокий приоритет. Среди прочего
Apr 08 21:16:23 | found multiple paths with wwid 35000c50004415bcb, multipathing sdaw
Apr 08 21:16:23 | Found matching wwid [35000c50004415bcb] in bindings file. Setting alias to mpathp
Apr 08 21:16:23 | sdy: ownership set to mpathp
Apr 08 21:16:23 | sdy: not found in pathvec
Apr 08 21:16:23 | sdy: mask = 0xc
Apr 08 21:16:23 | sdy: get_state
Apr 08 21:16:23 | sdy: path checker = readsector0 (controller setting)
Apr 08 21:16:23 | sdy: checker timeout = 30000 ms (sysfs setting)
Apr 08 21:16:23 | sdy: state = running
Apr 08 21:16:23 | sdy: state = 3
Apr 08 21:16:23 | sdy: state = running
Apr 08 21:16:23 | sdy: detect_prio = 2 (config file default)
Apr 08 21:16:23 | sdy: prio = const (config file default)
Apr 08 21:16:23 | sdy: const prio = 1
Apr 08 21:16:23 | sdaw: ownership set to mpathp
Apr 08 21:16:23 | sdaw: not found in pathvec
Apr 08 21:16:23 | sdaw: mask = 0xc
Apr 08 21:16:23 | sdaw: get_state
Apr 08 21:16:23 | sdaw: path checker = readsector0 (controller setting)
Apr 08 21:16:23 | sdaw: checker timeout = 30000 ms (sysfs setting)
Apr 08 21:16:23 | sdaw: state = running
Apr 08 21:16:23 | sdaw: state = 3
Apr 08 21:16:23 | sdaw: state = running
Apr 08 21:16:23 | sdaw: detect_prio = 2 (config file default)
Apr 08 21:16:23 | sdaw: prio = const (config file default)
Apr 08 21:16:23 | sdaw: const prio = 1
Apr 08 21:16:23 | mpathp: pgfailback = 15 (controller setting)
Apr 08 21:16:23 | mpathp: pgpolicy = multibus (controller setting)
Apr 08 21:16:23 | mpathp: selector = round-robin 0 (controller setting)
Apr 08 21:16:23 | mpathp: features = 0 (internal default)
Apr 08 21:16:23 | mpathp: hwhandler = 0 (controller setting)
Apr 08 21:16:23 | mpathp: rr_weight = 2 (controller setting)
Apr 08 21:16:23 | mpathp: minio = 1 rq (config file default)
Apr 08 21:16:23 | mpathp: no_path_retry = -2 (controller setting)
Apr 08 21:16:23 | pg_timeout = NONE (internal default)
Apr 08 21:16:23 | mpathp: retain_attached_hw_handler = 1 (config file default)
Apr 08 21:16:23 | mpathp: set ACT_CREATE (map does not exist)
Apr 08 21:16:23 | mpathp: domap (0) failure for create/reload map
Apr 08 21:16:23 | mpathp: ignoring map
1 ответ
По сути, я сдул как можно больше и начал все сначала. Второй раз, кажется, все сработало, как и ожидалось. У меня, вероятно, была одна или две переменные в multipath.conf, которые все испортили. На этот раз я позволил начать без файла, а затем сделал небольшие правки. Начиная с CentOS 6.3, я думаю, что это лучший способ начать.
Создание томов ZFS не вызывало проблем с момента перезапуска процесса настройки многолучевого распространения с нуля.