lpfc + многопутевой + человечность - путь продолжает переключаться

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

Типичный вывод от "многопутевого-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 приоритетных группы, и IO сделан по устройствам sdc и sdk, в то время как ЦУР и sdo неактивны и используются только во время отказа.

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

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

First of all, you define multibus, are you sure your Storage support this? Ask your SAN admin if your storage is a real active/active one, active passive storage do not allow to switch from controler all the time, this has a cost for the storage and will give you problems on the client side as well. In the first config it was not defined in the config, meaning you take the default config define in multipath (check /usr/share/doc/mulitpath.conf.anotted) or look at the output of multipathd -k show config to have a better view.(anyway aleays review the default config with your storage specs, because they are not always the best: i've had some issue with HDS et rhel)

The second thing, you said no integrity problem on the FS, are your sure your FS is using the multipathed device??? If I assume you use LVM, did you check the Filter settings in lvm.conf? if this is not well setted, lvm will use the device in direct instead of using MPIO, this can be even more a problem with active/passive storage, since lvm will force the use of a controller thay may not be the prefered one.... I hope it helps Regard

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"
    }
}

Сообщите нам, как это получится. Удачи!