17 デバイスのマルチパスI/Oの管理 #

multipath-toolsパッケージは、次のようなストレージアレイを自動的に検出します。

ただし、他のほとんどのストレージアレイも有効です。ストレージアレイが自動的に検出されると、マルチパス処理のデフォルト設定が適用されます。デフォルト以外の設定を使用したい場合は、手動で/etc/multipath.confファイルを作成および設定する必要があります。自動検出されないハードウェアでも同じ作業が必要になります。詳細については、Section 17.6, “/etc/multipath.conf Fileの作成または修正”を参照してください。

次の点に留意してください。

次のベンダのストレージアレイは、SUSE Linux Enterprise Serverでテスト済みです。

他のベンダのストレージアレイもほとんど機能するはずです。該当するベンダのマニュアルを参照してください。multipath-toolsパッケージによって認識されるデフォルトストレージアレイのリストについては、Section 17.2.1, “マルチパス処理用に自動検出されるストレージアレイ”を参照してください。

あるパスから他のパスにフェールオーバーするには特別なコマンドが必要なストレージアレイ、または非標準の特別なエラー処理が必要なストレージアレイには、より拡張されたサポートが必要なことがあります。したがって、デバイスマッパーマルチパスサービスには、ハードウェアハンドラ用フックがあります。たとえば、そのようなEMC CLARiiON CXファミリアレイ用ハンドラが1つ、既に提供されています。

Important: その他の情報

ハードウェアベンダのマニュアルを参照して、そのハードウェアハンドラをデバイスマッパーマルチパス用にインストールする必要があるかどうか判別してください。

multipath -tコマンドは、特定のハードウェアハンドラで特別な処理を必要とするストレージアレイの内部テーブルを表示します。ただし、表示されるリストは、サポートされているアレイの包括的なリストではありません。特別な処理を必要とし、multipath-toolsの開発者がツールの開発中にアクセスしたアレイだけがリストされます。

Important: ［Exceptions (例外)］

真のアクティブ/アクティブマルチパスサポートをもつアレイは、特別な処理を必要としないので、multipath -tコマンドでは表示されません。

また、multipath -tテーブルでリストされている場合でも、必ずしも、その特定ハードウェアでSUSE Linux Enterprise Serverがテスト済みということではありません。テスト済みのストレージアレイのリストについては、Section 17.2.2, “マルチパス処理サポートについてテスト済みのストレージアレイ”を参照してください。

マルチパスをもつ物理デバイスまたは論理デバイスのマルチパス処理を設定する前に、まず、次のようにディスク管理タスクを実行してください。

LinuxのソフトウェアRAIDの管理ソフトウェアは、マルチパス処理の上で実行されます。複数のI/Oパスを持ち、ソフトウェアRAIDで使用予定の各デバイスは、まず、マルチパス処理用に設定してから、ソフトウェアRAIDデバイスとして作成する必要があります。マルチパスデバイスは自動検出できません。ソフトウェアRAIDは、その下で実行されているマルチパス処理管理を認識しません。

既存のソフトウェアRAID用のマルチパス処理の設定については、Section 17.12, “既存ソフトウェアRAID用マルチパスI/Oの設定”を参照してください。

ストレージリソースのクラスタリング用の高可用性ソリューションは、各ノード上でマルチパス処理サービスをベースとして実行されます。各ノード上の/etc/multipath.confファイル内の構成設定が、クラスタ全体で同一であるようにしてください。

マルチパスデバイスがすべてのデバイス間で同じ名前であるようにしてください。詳細については、Section 17.9.1, “HAクラスタにおけるマルチパスデバイスの名前”を参照してください。

LAN上のデバイスをミラーリングするDRBD (Distributed Replicated Block Device)高可用性ソリューションは、マルチパス処理をベースとして実行されます。複数のI/Oパスを持ち、DRDBソリューションで使用予定のデバイスごとに、マルチパス処理用デバイスを設定してから、DRBDを設定する必要があります。

マルチパスを使用する際に最も重要な要件の1つは、ルートファイルシステムと、システムをブートするために必要な他のファイルシステムすべてについて、initrdとインストール済みシステムの動作が同じになるようにすることです。システムでマルチパスが有効になっている場合はinitrdでも有効にする必要があり、その逆も同様です。詳細については、Section 17.5.1, “マルチパスI/Oサービスの有効化、無効化、起動、および停止”を参照してください。

initrdとシステムが同期されていない場合、システムは正しくブートせず、起動手順を実行すると緊急シェルが起動します。このようなシナリオを回避または修復する方法については、Section 17.15.2, “マルチパスが有効な場合、ブート時にシステムが終了して緊急シェルが起動する”を参照してください。

デバイスマッパーマルチパス(DM-MP)モジュールは、Linuxにマルチパス処理機能を提供します。DM-MPIOは、SUSE Linux Enterprise Serverでのマルチパス処理の推奨ソリューションです。DM-MPIOは、SUSEによって完全にサポートされている製品に付属する唯一のマルチパス処理オプションです。

DM-MPIOは、多様なセットアップでマルチパス処理サブシステムを自動設定します。デバイスごとに最大8個のパスの設定がサポートされています。アクティブ/パッシブ(1つのパスがアクティブで、他のパスがパッシブ)またはアクティブ/アクティブ(ラウンドロビン方式の負荷分散で全パスがアクティブ)の構成がサポートされています。

DM-MPIOフレームワークは、2つの方法で拡張できます。

DM-MPIOのユーザスペースコンポーネントにより、自動的なパスの検出とグループ化のほか、自動的なパスの再テストが実行されるので、障害が発生したパスは、正常に戻ると自動的に復帰します。これにより、管理者の手間を最低限に抑えることができます。

DM-MPIOは、デバイス自体の障害ではなく、デバイスへのパスの障害からシステムを保護します。アクティブなパスの1つが失われると(たとえば、ネットワークアダプタが破損する、光ファイバケーブルが外れるなど)、残りのパスにI/Oをリダイレクトします。アクティブ/パッシブ構成の場合は、パスがパッシブパスの1つにフェールオーバーします。ラウンドロビン式負荷分散構成を使用している場合は、トラフィックの負荷が残りの正常なパス全体に分散されます。すべてのアクティブパスに障害が起きた場合は、アクティブでないセカンダリパスが有効になり、約30秒の遅延でフェールオーバーが開始されます。

ディスクアレイに複数のストレージプロセッサがある場合は、アクセスしたいLUNを所有するストレージプロセッサにSANスイッチが接続していることを必ず確認してください。ほとんどのディスクアレイでは、すべてのLUNが両方のストレージプロセッサに属しているので、両方の接続がアクティブです。

Note: ストレージプロセッサ

一部のディスクアレイでは、ストレージアレイがストレージプロセッサを介してトラフィックを管理するので、一度に1つのストレージプロセッサだけが提示されます。1つのプロセッサがアクティブとなり、もう1つのプロセッサは障害が発生するまでパッシブとなります。間違ったストレージプロセッサ(パッシブなパスをもつプロセッサ)に接続している場合は、予期されたLUNが表示されなかったり、それらのLUNが表示されてもアクセスしようとするとエラーが発生することがあります。

デバイスマッパーマルチパスは、マルチパスデバイスの各パスを個別のSCSIデバイスとして検出します。SCSIデバイス名は、/dev/sdNの形式をとります。ここで、Nは、デバイスに対して自動生成される文字であり、aで始まり、デバイスの生成に応じてシーケンシャルに発行されます(/dev/sda、/dev/sdbなど)。デバイス数が26を超えると、文字が2つ使用され、/dev/sdzの次のデバイスは/dev/sdaa、その次は、その次は/dev/sdabと続きます。

複数のパスが自動的に検出されない場合は、それらを/etc/multipath.confファイルで手動設定できます。multipath.confファイルは、システム管理者によって作成および設定されるまで存在しません。詳細については、Section 17.6, “/etc/multipath.conf Fileの作成または修正”を参照してください。

パッケージmultipath-toolsおよびkpartxでは、自動パス検出とグループ化を扱うツールが提供されています。これらのパッケージは、自動的にパスの定期テストを行うので、障害が発生したパスは、正常に戻ると、自動的に復帰します。これにより、管理者の手間を最低限に抑えることができます。

デフォルトのデバイスハンドラはUdevであり、デバイスは、デバイスノード名ではなく、Worldwide IDによって、システムに自動的に認識されます。これによって、環境設定ファイル(mdadm.confとlvm.conf)がマルチパスデバイスを正しく認識しないという、MDADMおよびLVMの旧リリースにあった問題が解決します。

LVM2の場合のようにmdadmでは、デバイスノードパスではなく、IDによってデバイスをアクセスする必要があります。したがって、/etc/mdadm.conf内のDEVICEエントリを次のように設定してください。

DEVICE /dev/disk/by-id/*

ユーザフレンドリな名前を使用している場合は、次のようにパスを指定し、マルチパス処理の設定後に、デバイスマッパー名だけがスキャンされるようにします。

DEVICE /dev/disk/by-id/dm-uuid-.*-mpath-.*

マルチパスデバイスを設定し、管理するには、multipath(8)コマンドを使用します。このコマンドの一般的な構文は、次のようになります。

multipath [-v verbosity_level] [-b bindings_file] [-d] [-h|-l|-ll|-f|-F|-B|-c|-q|-r|-w|-W|-t|-T] [-p failover|multibus|group_by_serial|group_by_prio|group_by_node_name] [DEVICENAME]

詳細については、man 8 multipathを参照してください。

mpathpersistユーティリティを使用して、デバイスマッパーマルチパスのデバイスでSCSIの永続的な予約を管理できます。このコマンドの一般的な構文は、次のようになります。

mpathpersist [options] [device]

詳細については、man 8 mpathpersistを参照してください。

このユーティリティを/etc/multipath.confファイルのサービスアクション予約キー(reservation_key属性)と共に使用して、SCSIデバイスの永続的な予約を設定します。この属性はデフォルトでは使用されません。この属性が設定されていない場合、multipathdデーモンは、新しく検出されたパスまたは復元されたパスの永続的な予約があるかどうかを確認しません。

reservation_key <RESERVATION_KEY>

この属性はdefaultsセクションまたはmultipathsセクションに追加できます。次に例を示します。

multipaths {
  multipath {
    wwid   XXXXXXXXXXXXXXXX
    alias      yellow
    reservation_key  0x123abc
  }
}

永続的な管理の対象にするすべてのマルチパスデバイスに対してreservation_keyパラメータを設定し、次のコマンドを実行してmultipathdデーモンを再起動します。

tux > sudo systemctl restart multipathd

設定後、mpathpersistコマンドで予約キーを指定できます。

マルチパスサービスを有効にしてブート時に起動するには、次のコマンドを実行します。

tux > sudo systemctl enable multipathd

稼働中のシステムでサービスを手動で起動したり、サービスの状態を確認したりするには、次のいずれかのコマンドを入力します。

tux > sudo systemctl start multipathd
tux > sudo systemctl status multipathd

現在のセッションでマルチパスサービスを停止して無効にし、システムの次回ブート時にサービスが起動しないようにするには、次のコマンドを実行します。

tux > sudo systemctl stop multipathd
tux > sudo systemctl disable multipathd

Important: initrdの再構築

マルチパスサービスを有効または無効にした場合は、initrdの再構築も必要です。そうしないと、システムがブートしなくなるおそれがあります。マルチパスサービスを有効にする場合は、次のコマンドを実行してinitrdの再構築も行います。

tux > dracut --force --add multipath

マルチパスサービスを無効にする場合は、次のコマンドを実行してinitrdを再構築します。

tux > dracut --force -o multipath

(オプション)さらに、マルチパスを手動で起動するときにもマルチパスデバイスが設定されないようにする場合は、initrdを再構築する前に、/etc/multipath.confの最後に次の行を追加します。

blacklist {
    wwid ".*"
}

SANデバイスのマルチパスI/Oを設定する前に、必要に応じて、次のようにSANデバイスを準備してください。

HBAドライバがLUNを認識しない場合は、lsscsiを使用して、SCSIデバイスがオペレーティングシステムによって正しく認識されているかどうかチェックできます。LUNがHBAドライバによって認識されない場合は、SANのゾーン化セットアップをチェックします。特に、LUNのマスキングがアクティブであるかどうか、LUNがサーバに正しく割り当てられているかどうかをチェックしてください。

LUNがHBAドライバによって認識されても、対応するブロックデバイスが存在しない場合は、カーネルパラメータを追加して、SCSIデバイスのスキャン動作を変更する必要があります(LUNが連続的に番号付けされていないことを示すなど)。詳細については、SUSEナレッジベース(https://www.suse.com/support/kb/doc.php?id=3955167)にあるTID 3955167: Troubleshooting SCSI (LUN) Scanning Issuesを参照してください。

複数のパスをもつパーティショニングデバイスは、推奨できませんが、サポートされています。kpartxツールを使用すると、再起動なしでマルチパスデバイスにパーティションを作成できます。マルチパス処理の設定前に、YaSTのパーティショナ機能またはサードパーティーのパーティショニングツールの使用により、デバイスをパーティショニングすることもできます。

マルチパスデバイスはデバイスマッパーデバイスです。コマンドラインツール(parted、kpartx、fdiskなど)を使用してデバイスマッパーデバイスを変更することはできますが、他の層を更新するために必要なudevイベントが生成されるとは限りません。デバイスマッパーデバイスをパーティション化した後、マルチパスマップをチェックして、デバイスマッパーデバイスがマップされていることを確認する必要があります。デバイスが見つからない場合は、マルチパスデバイスを再マップするかサーバを再起動すると、マルチパスマップにある新しいパーティションをすべて検出できます。

マルチパスデバイス上にあるパーティションのデバイスマッパーデバイスは、独立したデバイスと同じではありません。デバイス全体を使用するLVM論理ボリュームを作成する場合、パーティションが含まれないデバイスを指定する必要があります。マルチパスパーティションをLVM論理ボリュームのターゲットデバイスとして設定すると、LVMは、ベースを成す物理デバイスがパーティション化されていると認識し、作成に失敗します。SANデバイスを再分割する必要がある場合、SANデバイス上のLUNを分割し、各LUNを別個のマルチパスデバイスとしてサーバに認識させることができます。

/etc/multipath.confファイルは、以下のセクションで構成されています。詳細は、man 5 multipath.confを参照してください。

/etc/multipath.confファイルの作成または修正を行った場合、ファイルを保存する際に変更が自動的には適用されません。セットアップの“ドライ実行”を行って、マルチパスのマップを更新する前に、マルチパスセットアップを確認することができます。

サーバのコマンドプロンプトで、次のように入力します。

tux > sudo multipath -v2 -d

このコマンドによりデバイスがスキャンされ、変更をコミットしたときにセットアップがどのようになるかが表示されます。/etc/multipath.confファイルを修正してドライ実行を行う際に、変更前の(またはデフォルトの)マルチパス設定で、multipathdデーモンがすでに実行されていることを前提とします。変更内容に問題がなければ、次の手順に進みます。

出力の例を以下に示します。

26353900f02796769
[size=127 GB]
[features="0"]
[hwhandler="1    emc"]

\_ round-robin 0 [first]
  \_ 1:0:1:2 sdav 66:240  [ready ]
  \_ 0:0:1:2 sdr  65:16   [ready ]

\_ round-robin 0
  \_ 1:0:0:2 sdag 66:0    [ready ]
  \_ 0:0:0:2 sdc   8:32   [ready ]

パスは、優先度グループでグループ化されます。一度に1つの優先度グループだけがアクティブに使用されます。アクティブ/アクティブ構成をモデル化するには、すべてのパスを同じグループにします。アクティブ/パッシブ構成をモデル化する場合は、並行してアクティブにしないパスを複数の別の優先度グループに振り分けます。これは、通常、デバイス検出時に自動的に行われます。

出力として、順序、グループ内でのI/O負荷の分散に使用されるスケジュールポリシー、および各優先度グループのパスが表示されます。また、各パスに対して、その物理アドレス(ホスト:バス:ターゲット:LUN)、デバイスノード名、メジャー:マイナー番号、および状態が表示されます。

ドライ実行で冗長レベルの-v3を使用することによって、すべての検出されたパス、マルチパス、およびデバイスマップを表示できます。WWIDおよびデバイスノードの両方でブラックリスト化されたデバイスが表示されます。

2つのQlogic HBAをXiotech Magnitude 3000 SANに接続した64ビットSLES 11 SP2サーバでの-v3出力の例を、次に示します。例を短くするため、複数エントリの一部は省略されています。

tux > sudo multipath -v3 d
dm-22: device node name blacklisted
< content omitted >
loop7: device node name blacklisted
< content omitted >
md0: device node name blacklisted
< content omitted >
dm-0: device node name blacklisted
sdf: not found in pathvec
sdf: mask = 0x1f
sdf: dev_t = 8:80
sdf: size = 105005056
sdf: subsystem = scsi
sdf: vendor = XIOtech
sdf: product = Magnitude 3D
sdf: rev = 3.00
sdf: h:b:t:l = 1:0:0:2
sdf: tgt_node_name = 0x202100d0b2028da
sdf: serial = 000028DA0014
sdf: getuid= "/lib/udev/scsi_id --whitelisted --device=/dev/%n" (config file default)
sdf: uid = 200d0b2da28001400 (callout)
sdf: prio = const (config file default)
sdf: const prio = 1
[...]
ram15: device node name blacklisted
[...]
===== paths list =====
uuid              hcil    dev dev_t pri dm_st  chk_st  vend/prod/rev
200d0b2da28001400 1:0:0:2 sdf 8:80  1   [undef][undef] XIOtech,Magnitude 3D
200d0b2da28005400 1:0:0:1 sde 8:64  1   [undef][undef] XIOtech,Magnitude 3D
200d0b2da28004d00 1:0:0:0 sdd 8:48  1   [undef][undef] XIOtech,Magnitude 3D
200d0b2da28001400 0:0:0:2 sdc 8:32  1   [undef][undef] XIOtech,Magnitude 3D
200d0b2da28005400 0:0:0:1 sdb 8:16  1   [undef][undef] XIOtech,Magnitude 3D
200d0b2da28004d00 0:0:0:0 sda 8:0   1   [undef][undef] XIOtech,Magnitude 3D
params = 0 0 2 1 round-robin 0 1 1 8:80 1000 round-robin 0 1 1 8:32 1000
status = 2 0 0 0 2 1 A 0 1 0 8:80 A 0 E 0 1 0 8:32 A 0
sdf: mask = 0x4
sdf: path checker = directio (config file default)
directio: starting new request
directio: async io getevents returns 1 (errno=Success)
directio: io finished 4096/0
sdf: state = 2
[...]

/etc/multipath.confファイルに対する変更は、multipathdの実行中は有効になりません。変更を行ったら、ファイルを保存して閉じ、次のコマンドを実行して、変更内容を適用してマルチパスマップを更新してください。

異なるパス上のデバイスを識別するため、マルチパスは、各デバイスに対してWorld Wide Identification (WWID)を使用します。2つのデバイスパスのWWIDが同じである場合、それらは同じデバイスを表すものと想定されます。やむを得ない理由がある場合を除き、WWIDの生成方法を変更しないことをお勧めします。詳細については、man multipath.confを参照してください。

以下を行って、マルチパスデバイスがすべてのデバイス間で同じ名前であるようにしてください。

Note: ユーザフレンドリ名

実際にユーザフレンドリ名を使用する必要がある場合は、以下の操作により、システム定義のユーザフレンドリ名を、クラスタ内のすべてのノードについて同一にすることができます。

1. 1つのノード上の/etc/multipath.confファイル内で、

   1. user_friendly_names構成オプションをyesに設定して有効にします。

      マルチパスは、/var/lib/multipath/bindingsファイルを使用して、/dev/mapperディレクトリ内でmpath<N>の形式で、デバイスに永続的かつ固有の名前を割り当てます。

   2. (オプション) bindingsファイルに対して別の場所を指定するには、/etc/multipath.confファイルのdefaultsセクションにある、bindings_fileオプションを設定します。

      デフォルトの場所は、/var/lib/multipath/bindingsです。

2. ノード上のマルチパスデバイスをすべて設定します。

3. /etc/multipath.confファイルを、ノードからクラスタ内の他のすべてのノードの/etc/ディレクトリにコピーします。

4. bindingsファイルを、ノードから、クラスタ内の他のすべてのノード上のbindings_fileパスにコピーします。

5. /etc/multipath.confファイルの変更後、dracut -fを実行してシステム上にinitrdを再作成してから、ノードを再起動して変更内容を有効にする必要があります。詳細については、Section 17.6.4, “/etc/multipath.confファイルの変更を適用したマルチパスマップの更新”を参照してください。これは、影響を受けるすべてのノードに適用されます。

multipathコマンドを-pオプション付きで使用して、パスフェールオーバーポリシーを設定します。

tux > sudo multipath DEVICENAME -p POLICY

次のポリシーオプションの1つで、POLICYを置き換えます。

デバイスのフェールオーバーポリシーは、手動で、/etc/multipath.confファイルに入力する必要があります。すべての設定とオプションの例は、/usr/share/doc/packages/multipath-tools/multipath.conf.annotatedファイルにあります。

SCSIターゲットポートグループの報告(sg_rtpg(8))コマンドを使用します。詳細については、sg_rtpg(8)のマニュアルページを参照してください。

オペレーティングシステムをマルチパスデバイスにインストールするには、マルチパスソフトウェアがインストール時に実行されている必要があります。multipathdデーモンは、システムのインストール時に自動的にアクティブになりません。このデーモンは、YaSTパーティショナのマルチパスの設定オプションを使用することによって起動できます。

multipath=offをカーネルコマンドラインに追加します。この変更はYaSTのブートローダモジュールで行うことができます。ブートローダのインストール › Kernel Parameters (カーネルパラメータ)の順に開き、両方のコマンドラインにパラメータを追加します。

これは、ルートデバイスだけに影響します。他のすべてのデバイスは影響されません。

ご使用のシステムがマルチパス処理用に設定されており、後からSANにストレージを追加する必要がある場合は、rescan-scsi-bus.shスクリプトを使用して新しいデバイスをスキャンすることができます。デフォルトでは、このスクリプトは典型的なLUN範囲ですべてのHBAをスキャンします。このコマンドの一般的な構文は、次のようになります。

tux > sudo rescan-scsi-bus.sh [options] [host [host ...]]

ほとんどのストレージサブシステムでは、このスクリプトはオプションを指定しなくても正常に実行されます。ただし、特殊な場合は、次のオプションを1つ以上使用する必要があります。詳細については、rescan-scsi-bus.sh --helpを実行してください。

Warning: EMC PowerPath環境

EMC PowerPath環境では、SCSIバスをスキャンする場合に、オペレーティングシステムに付属するrescan-scsi-bus.shユーティリティまたはHBAベンダスクリプトを使用しないでください。ファイルシステムが破損する可能性を避けるため、EMCでは、Linux用EMC PowerPathのベンダマニュアルに記載されている手順に従うよう求めています。

次のプロシージャを使用して、システムを再起動せずに、デバイスをスキャンして、マルチパス処理に使用できるようにします。

本項の例を使用して、新たに追加したマルチパスLUNを再起動なしで検出します。

Warning: EMC PowerPath環境

EMC PowerPath環境では、SCSIバスをスキャンする場合に、オペレーティングシステムに付属するrescan-scsi-bus.shユーティリティまたはHBAベンダスクリプトを使用しないでください。ファイルシステムが破損する可能性を避けるため、EMCでは、Linux用EMC PowerPathのベンダマニュアルに記載されている手順に従うよう求めています。

マルチパスI/Oのステータスをクエリすると、マルチパスマップの現在のステータスが出力されます。

multipath -lオプションを使用すると、パスチェッカが最後に実行された時点での現行パスステータスが表示されます。ただし、パスチェッカは実行されません。

multipath -llオプションを使用すると、パスチェッカが実行され、パス情報が更新され、最後に、現在のステータス情報が表示されます。このコマンドは、常にパスステータスの最新情報を表示します。

tux > sudo multipath -ll
3600601607cf30e00184589a37a31d911
[size=127 GB][features="0"][hwhandler="1 emc"]

\_ round-robin 0 [active][first]
  \_ 1:0:1:2 sdav 66:240  [ready ][active]
  \_ 0:0:1:2 sdr  65:16   [ready ][active]

\_ round-robin 0 [enabled]
  \_ 1:0:0:2 sdag 66:0    [ready ][active]
  \_ 0:0:0:2 sdc  8:32    [ready ][active]

デバイスごとに、デバイスのID、サイズ、機能、およびハードウェアハンドラが表示されます。

デバイスへのパスは、自動的に、デバイス検出時に優先度グループとしてグループ化されます。一度に1つの優先度グループだけがアクティブになります。アクティブ/アクティブ構成の場合、すべてのパスが同じグループに属します。アクティブ/パッシブ構成の場合、パッシブパスは別個の優先度グループに属します。

グループごとに、次の情報が表示されます。

パスごとに、次の情報が表示されます。

queue_if_no_pathを有効にすることで、すべてのパスで同時に障害が発生した場合は、I/Oをキューに登録するように、マルチパス処理を設定する必要があるかもしれません。設定しておかないと、すべてのパスに障害が発生するとI/Oもすぐに失敗してしまいます。ドライバ、HBA、またはファブリックにスプリアスエラーが発生したというシナリオでは、それらのエラーですべてのパスが失われるI/Oをすべて待ち行列に入れ、エラーを上方にプロパゲートしないように、DM-MPIOを設定してください。

マルチパスデバイスをクラスタで使用する場合は、queue_if_no_pathを無効にすることができます。これにより、I/Oがキューに入る代わりに、パスがエラーになり、そのI/Oエラーがエスカレートしてクラスタリソースのフェールオーバーを引き起こします。

ただし、queue_if_no_pathを有効にすると、パスが回復しない限り、I/Oがいつまでもキューに留まることになるので、multipathdが実行中であり、シナリオに有効なことを必ず確認してください。確認しておかないと、再起動するまで、またはキューの代わりに手動でフェールオーバーに戻すまで、影響を受けたマルチパスデバイスでI/Oが無限に停止する可能性があります。

シナリオをテストするには:

待ち行列内のI/Oをすべてのパスがエラーになるシナリオ用に設定するには:

すべてパスが同時にエラーとなり、I/Oが待ち行列に入って停止している場合は、次のプロシージャを実行します。

IBM Zデバイスのマルチパス処理に関するテストを実施した結果、dev_loss_tmoパラメータをinfinity (2147483647)に、fast_io_fail_tmoパラメータを 5秒に設定する必要があることわかりました。IBM Zデバイスを使用している場合は、/etc/multipath.confファイルを変更して、値を次のように指定します。

defaults {
       dev_loss_tmo 2147483647
       fast_io_fail_tmo 5
}

dev_loss_tmoパラメータは、マルチパスリンクに不良のマーキングがされるまでの秒数を設定します。パスに障害が発生したら、そのパスの現在のI/Oが失敗します。デフォルト値は使用するデバイスドライバによって異なります。ドライバの内部タイムアウトを使用するには、値をゼロ(0)に設定します。「infinity」(2147483647)に設定することもできます。これにより、最大値が2147483647秒(68年)に設定されます。

fast_io_fail_tmoパラメータは、リンク障害を検出した場合に、I/Oが失敗するまでの待機時間を設定します。ドライバに到達したI/Oは失敗します。ブロックしたキューにI/Oがある場合は、I/Oはdev_loss_tmoで指定された時間が経過するまでは失敗せず、キューのブロックが解除されます。

/etc/multipath.confファイルを変更した場合、その変更内容は、マルチパスマップを更新するまで、またはmultipathdデーモンを再起動(systemctl restart multipathd)するまで適用されません。

NetAppデバイスでマルチパスを使用する場合は、/etc/multipath.confファイルで次の設定を行うことを推奨します。

マルチパスデバイス上で実行する場合は、オプション--noflushを必ず使用する必要があります。

たとえば、テーブルのリロードを行うスクリプトでは、マルチパストポロジ情報が必要なので、再開時に--noflushオプションを使用して、残っているI/Oがフラッシュされないようにします。

load
resume --noflush

マルチパスデバイスにルート(/)があるシステムは、すべてのパスに障害が発生し、それらのパスがシステムから削除されると、停止することがあります。これは、ストレージサブシステム(ファイバチャネルストレージアレイなど)からdev_loss_tmoタイムアウトを受信するからです。

システムデバイスがマルチパスを使用して設定され、マルチパスのno_path_retry設定がアクティブな場合は、ストレージサブシステムのdev_loss_tmo設定を適宜変更して、すべてのパスがダウンするシナリオでデバイスが削除されないようにする必要があります。dev_loss_tmo値をマルチパスのno_path_retry設定以上にすることを強くお勧めします。

ストレージサブシステムのdev_los_tmoの推奨設定は、次のとおりです。

<dev_loss_tmo> = <no_path_retry> * <polling_interval>

マルチパス値については、次の定義が適用されます。

これらの各マルチパス値は、/etc/multipath.conf環境設定ファイルから設定する必要があります。詳細については、Section 17.6, “/etc/multipath.conf Fileの作成または修正”を参照してください。

Btrfsを使用したレガシBIOSシステムでは、許可がないためgrub2-installが失敗する可能性があります。これを修正するには、/boot/grub2/SUBDIR/サブボリュームが読み書き(rw)モードでマウントされるようにしてください。SUBDIRはx86_64-efiまたはi386-pcにできます。

ブート中にシステムが終了して緊急シェルが起動し、次のようなメッセージが表示されます。

[  OK  ] Listening on multipathd control socket.
         Starting Device-Mapper Multipath Device Controller...
[  OK  ] Listening on Device-mapper event daemon FIFOs.
         Starting Device-mapper event daemon...
         Expecting device dev-disk-by\x2duuid-34be48b2\x2dc21...32dd9.device...
         Expecting device dev-sda2.device...
[  OK  ] Listening on udev Kernel Socket.
[  OK  ] Listening on udev Control Socket.
         Starting udev Coldplug all Devices...
         Expecting device dev-disk-by\x2duuid-1172afe0\x2d63c...5d0a7.device...
         Expecting device dev-disk-by\x2duuid-c4a3d1de\x2d4dc...ef77d.device...
[  OK  ] Started Create list of required static device nodes ...current kernel.
         Starting Create static device nodes in /dev...
[  OK  ] Started Collect Read-Ahead Data.
[  OK  ] Started Device-mapper event daemon.
[  OK  ] Started udev Coldplug all Devices.
         Starting udev Wait for Complete Device Initialization...
[  OK  ] Started Replay Read-Ahead Data.
         Starting Load Kernel Modules...
         Starting Remount Root and Kernel File Systems...
[  OK  ] Started Create static devices
[*     ] (1 of 4) A start job is running for dev-disk-by\x2du...(7s / 1min 30s)
[*     ] (1 of 4) A start job is running for dev-disk-by\x2du...(7s / 1min 30s)

...

Timed out waiting for device dev-disk-by\x2duuid-c4a...cfef77d.device.
[DEPEND] Dependency failed for /opt.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Postfix Mail Transport Agent.
Welcome to emergency shell
Give root password for maintenance
(or press Control-D to continue):

この問題は次の状況で発生します。

バージョン 0.4.9以降のマルチパスツールでは、/etc/multipath.confファイルのdefaults{}セクションまたはdevices{}セクションのprio設定を使用します。キーワードprioが、multipath{)セクションの個別のmultipaths定義に指定された場合は、暗黙のうちに無視されます。

マルチパスツール0.4.8では、multipaths{)セクションの個別のmultipath定義内のprio設定で、defaults{}またはdevices{}セクションのprio設定を上書きすることができました。

multipath-tools-0.4.8からmultipath-tools-0.4.9に更新すると、引数を必要とするPrioritizerの場合、/etc/multipath.confファイル内のprio設定が壊れます。multipath-tools-0.4.9では、Prioritizerの指定にはprioキーワードが使われ、引数を必要とするPrioritizerの指定には、prio_argsキーワードが使われます。これまでは、Prioritizerとその引数はいずれも、同じprio行で指定していました。

たとえば、multipath-tools-0.4.8では、次の行を使用してPrioritizerとその引数を同じ行で指定していました。

prio "weightedpath hbtl [1,3]:.:.+:.+ 260 [0,2]:.:.+:.+ 20"

multipath-tools-0.4.9以降への更新後は、このコマンドを使用するとエラーになります。メッセージの例を以下に示します。

<Month day hh:mm:ss> | Prioritizer 'weightedpath hbtl [1,3]:.:.+:.+ 260
[0,2]:.:.+:.+ 20' not found in /lib64/multipath

この問題を解決するには、テキストエディタで、/etc/multipath.confファイル内のprio行を変更します。2つの行を作成して、prio行にPrioritizerを指定し、その下のprio_args行にPrioritizerの引数を指定します。

prio "weightedpath"
prio_args "hbtl [1,3]:.:.+:.+ 260 [0,2]:.:.+:.+ 20"

sudo systemctl restart multipathdを実行してmultipathdデーモンを再起動し、変更を有効にします。

SUSE Linux Enterprise ServerのマルチパスI/Oの問題のトラブルシューティングについては、SUSEナレッジベースにある、次のTID (技術情報ドキュメント)を参照してください。