lpfc + multipath + ubuntu - путь продолжает переключаться

Ваша конфигурация выглядит странно; обычно у вас будет 4 пути к одному устройству (то есть 4 устройства /dev/sdX на устройство с несколькими путями). Контроллер массива обычно может информировать хост о приоритете для каждого пути, поэтому у вас есть 2 пути с более высоким приоритетом и 2 с более низким приоритетом. Затем dm-multipath мультиплексирует IO по двум высокоприоритетным путям (опция "селектор" со значением по умолчанию rr_min_io=100). Теперь у вас есть 2 группы путей с одинаковым приоритетом, поэтому, возможно, dm-multipath распределяет IO по обоим из них, что, возможно, не то, чего хочет от вас администратор SAN. Еще одна странная вещь - устройства помечены как "undef", а не как "готово". Еще одна странная вещь заключается в том, что нумерация вашего пути выглядит довольно странно (все идет по одному и тому же пути?). Вы действительно уверены, что все правильно соединено, правильно зонировано и т. Д.?

Типичный вывод "multipath -ll" должен выглядеть следующим образом

sanarch3 (3600508b4000683de0000c00000a20000) дм-6 HP,HSV200
[size=2.0T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=100][active]
 \_ 0:0:0:5 SDC 8:32  [активно] [готово]
 \_ 1:0:0:5 SDK 8:160 [активно] [готово]
\_ round-robin 0 [prio=20][включено]
 \_ 0:0:1:5 sdg 8:96  [активно] [готово]
 \_ 1:0:1:5 sdo 8:224 [активно] [готово]

Там вы видите 4 пути, сгруппированных в 2 приоритетные группы, и IO выполняется на устройствах sdc и sdk, в то время как sdg и sdo простаивают и используются только во время сбоя.

РЕДАКТИРОВАТЬ Итак, причина, почему вы должны увидеть 4 пути, состоит в том, что у вас есть 2 порта HBA, а массив имеет 2 резервных контроллера. Затем у вас есть 2 резервные сети с последним уровнем коммутации, обеспечивающим межсетевые соединения. Таким образом, оба HBA видят оба контроллера, следовательно, 4 пути для каждого LUN. Вы можете видеть это в моем примере выше для нумерации идентификатора SCSI, которая выглядит как [идентификатор хост-контроллера]:[идентификатор канала]:[идентификатор целевого контроллера]:[идентификатор LUN]. Затем вы можете увидеть, что активные пути находятся на контроллере № 0, поскольку в этом случае контроллер № 0 "владеет" LUN; IO возможен через другой контроллер, но с потерей производительности, поскольку другому контроллеру (в зависимости от реализации контроллера) потребуется перенаправить IO на контроллер-владелец. Следовательно, контроллер сообщает, что пути, ведущие к контроллеру № 0, имеют более высокий приоритет.

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

У IBM SAN обычно есть хорошо определенные примеры multipath.conf в их документации, разве вы не начали с этого? Я оставлю эту часть в качестве упражнения для читателя. Кроме того, ваш администратор SAN должен вам немного больше поддержки. Несколько быстрых моментов

• Колебания пути, как вы описали, обычно происходят из-за неправильной настройки средства проверки пути, в двух ваших итерациях вы переходите от readsector0 к none, что, вероятно, принимает многолучевое значение по умолчанию для этой марки и модели, вероятно tur (готовый тестовый модуль).

• Не определена проверка приоритетов, нет проверки приоритетов, нет приоритетов.

• Вероятно, требуется аппаратный обработчик, который хорошо определен в документации.

Лучшая военная история IBM 1815, которую я нашел, была такова:

• Установите драйвер rdac, modprobe scsi_dh_rdac и добавьте его в свой initrd
• Используйте следующий файл multipath.conf:

blacklist {
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^hd[a-z]"
    devnode "^sda"
    device {
        vendor "Maxtor*"
        product "OneTouch*"
    }
}
blacklist_exceptions {
    device {
            vendor  "IBM"
            product "1815*"
    }
}
defaults {
    failback                immediate
    no_path_retry           queue
    user_friendly_names     no
    path_grouping_policy    failover
}
devices {
    device {
            vendor                  "IBM"
            product                 "1815*"
            failback                manual
            hardware_handler        "1 rdac"
            path_checker            rdac
            prio_callout            "/sbin/mpath_prio_rdac /dev/%n"
    }
}

Дайте нам знать, как это получается. Удачи!

Прежде всего, вы определяете multibus, вы уверены, что ваше хранилище поддерживает это? Спросите администратора SAN, является ли ваше хранилище действительно активным / активным, активное пассивное хранилище не позволяет все время переключаться с контроллера, это требует затрат на хранилище и создает проблемы на стороне клиента. В первом конфиге он не был определен в конфиге, то есть вы берете конфигурацию по умолчанию, определенную в многолучевом режиме (проверьте /usr/share/doc/mulitpath.conf.anotted), или посмотрите на выходные данные команды multipathd -k show config, чтобы лучший обзор.(в любом случае, просмотрите конфигурацию по умолчанию с вашими спецификациями хранилища, потому что они не всегда лучшие: у меня были некоторые проблемы с HDS и др.)

Во-вторых, вы сказали, что у FS нет проблем с целостностью, вы уверены, что ваша FS использует многопоточное устройство??? Если я предполагаю, что вы используете LVM, вы проверили настройки фильтра в lvm.conf? если это не так, lvm будет использовать устройство напрямую, а не MPIO, это может быть еще большей проблемой с активным / пассивным хранилищем, так как lvm заставит использовать контроллер, который может быть не предпочтительным... Я надеюсь, что это помогает Regard