web-dev-qa-db-ja.com

device-mapper-multipathの障害のあるパスを「修正」するにはどうすればよいですか

動作していたマルチパス構成がありますが、「障害のある」パスが表示されます。

[root@nas ~]# multipath -ll
sdd: checker msg is "readsector0 checker reports path is down"
mpath1 (36001f93000a63000019f000200000000) dm-2 XIOTECH,ISE1400
[size=200G][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=1][active]
 \_ 1:0:0:1 sdb 8:16  [active][ready]
\_ round-robin 0 [prio=0][enabled]
 \_ 2:0:0:1 sdd 8:48  [active][faulty]

同時に、私はこれらの3行を/var/log/messagesで何度も見ています。

Feb  5 12:52:57 nas kernel: sd 2:0:0:1: SCSI error: return code = 0x00010000
Feb  5 12:52:57 nas kernel: end_request: I/O error, dev sdd, sector 0
Feb  5 12:52:57 nas kernel: Buffer I/O error on device sdd, logical block 0

そして、この線もかなり頻繁に現れます

Feb  5 12:52:58 nas multipathd: sdd: readsector0 checker reports path is down

私が理解していないことの1つは、readsector0ファイルがturを使用するように言っているときに、なぜ/etc/multipath.confチェックメソッドを使用するかです。

[root @ nas〜] #tail -n15 /etc/multipath.conf

devices {
        device {
                vendor                  "XIOTECH "
                product                 "ISE1400         "
                path_grouping_policy    multibus
                getuid_callout          "/sbin/scsi_id -g -u -d /dev/%n"
                path_checker            tur
                prio_callout              "none"
                path_selector           "round-robin 0"
                failback                    immediate
                no_path_retry           12
                user_friendly_names yes
        }
}

ここでアップストリームのドキュメントを見ると、この段落は関連しているようです: http://christophe.varoqui.free.fr/usage.html

For each path:

\_ Host:channel:id:lun devnode major:minor [path_status][dm_status_if_known]

The dm status (dm_status_if_known) is like the path status
(path_status), but from the kernel's point of view. The dm status has two
states: "failed", which is analogous to "faulty", and "active" which
covers all other path states. Occasionally, the path state and the 
dm state of a device will temporarily not agree. 

私にとっては24時間を十分に超えているので、一時的なものではありません。

これらすべてを背景として、私の質問は
-ここで根本原因を特定するにはどうすればよいですか?
-手動/コマンドラインで、実行中のチェックを実行するにはどうすればよいですか
-multipath.confを無視するのはなぜですか(間違っていましたか?)

何かアイデアがありましたら、よろしくお願いします。他に情報を提供できることがあれば、コメントで知らせて、投稿に編集します。

2
cagenut

Multipath.confに微妙なバグがあり、vendorおよびproductが正規表現レベルで一致しています。一連の先行スペースを追加したため、multipathdが失敗しますシステム上の実際のデバイスと構成を一致させます。 echo 'show config' | multipathd -kの出力を調べると、SANのtwoデバイスセクションが見つかります。これは、追加したすべての余分なスペースと一致するセクションであり、デフォルトの構成(存在する場合)が提供されます内部データベースによって。

Multipath.confを次のように調整します。

            vendor                  "XIOTECH "
            product                 "ISE1400.*"

SCSI Inquiryは、ASCIIゼロで終了する8文字以下のベンダーフィールドを想定しています。8つすべてを使用しない場合は、フィールドにスペースを埋め込んで8文字にする必要があります。マルチパスは仕様を法律の手紙に解釈すると、本当に確実にしたい場合は、"XIOTECH.*"を実行することもできます。

これらの変更を行ったら、initscripts、multipath -Fを使用してmultipathdを停止し、構成をフラッシュしてからmultipathdを再起動します。これで、設定ファイルが尊重されるはずです。それでも問題が解決しない場合は、再起動してください。

設定ファイルが守られていないことに疑いがある場合は、常にエコーの呪文を使用して実行中の設定を調べ、データベースにロードされているものを設定ファイルと比較してください。

3
ppetraki