инициатор open-iscsi в Linux не видит пассивную сторону активной / пассивной цели open-e

У меня есть сервер Linux, на котором запущен SLES11 SP4, который использует open-iscsi и multipathing для подключения к LUN, который представлен из кластера хранения Open-E DSS v7 с активным / пассивным аварийным переключением.

Сервер Linux db03 имеет свой интерфейс bond0 с IP 10.0.100.66/22 в нашей сети iSCSI. Каждая сторона кластера Open-E имеет два IP-адреса в сети iSCSI: 10.0.100.71 и 10.0.100.72 на первом узле и 10.0.100.73 и 10.0.100.74 На втором.

Итак, когда переключения при отказе не произошло, обнаружение выглядит следующим образом:

db03:~ # iscsiadm -m discovery -t sendtargets -p 10.0.100.71:3260
10.0.100.71:3260,1 opene.lun602
10.0.100.72:3260,1 opene.lun602

Когда обе цели подключены, это статус множественного пути:

db03:~ # multipath -ll
opene.lun602 (2697a42a45d5dcbdb) dm-0 SCST_BIO,izcegeu6eeb2jaeJ
size=500G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
  |- 7:0:0:0 sda        8:0   active ready running
  `- 8:0:0:0 sdb        8:16  active ready running

В случае аварийного переключения оба этих соединения переходят в failed faulty, У меня остается 0 путей и все ошибки ввода-вывода, пока ядро ​​не решит перемонтировать файловую систему в режиме только для чтения.

В этот момент я могу вручную попробовать другое обнаружение, соединить две другие цели ... Но на стороне Linux автоматическое переключение не происходит.

Поэтому мне интересно:

• Есть ли способ, которым Linux может регулярно обнаруживать подобные изменения? Я не нашел ни одного.

• Есть ли способ указать программному обеспечению Open-E DSS объявить другие пути, но сигнализировать, что они являются резервными? (В какой-то момент нам удалось отобразить в кластере все 4 пути, но они были неправильно показаны как active ready что явно не может быть хорошей идеей вместе с активным / пассивным кластером, где вы должны направлять ввод-вывод только в активную часть.)

• Как VMWare с этим справляется? Кластер VMWare, подключенный к другому LUN, настроенному таким же образом, не обнаруживает таких проблем.

Для справки это мой multipath.conf:

cat /etc/multipath.conf
multipaths {
    multipath {
        wwid        2697a42a45d5dcbdb
        alias       opene.lun602
    }
}
devices {
    device {
        vendor          "SCST_FIO|SCST_BIO"
        product         "*"
        path_selector       "round-robin 0"
        path_grouping_policy    multibus
        rr_min_io       100
    }
}