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

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

Типичный вывод команды "multipath -ll" должен выглядеть так:

sanarch3 (3600508b4000683de0000c00000a20000) dm-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  [active][ready]
 \_ 1:0:0:5 sdk 8:160 [active][ready]
\_ round-robin 0 [prio=20][enabled]
 \_ 0:0:1:5 sdg 8:96  [active][ready]
 \_ 1:0:1:5 sdo 8:224 [active][ready]

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

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

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

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

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

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

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

Лучшая история войны 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, действительно ли ваше хранилище является активным / активным, активное пассивное хранилище не позволяет постоянно переключаться с контроллера, это требует затрат на хранилище и также создаст проблемы на стороне клиента. В первой конфигурации он не был определен в конфигурации, то есть вы принимаете конфигурацию по умолчанию, определенную в multipath (проверьте /usr/share/doc/mulitpath.conf.anotted), или посмотрите на вывод multipathd -k show config, чтобы получить лучший вид. (в любом случае просмотрите конфигурацию по умолчанию со спецификациями хранилища, потому что они не всегда самые лучшие: у меня была проблема с HDS et rhel)

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