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

Linuxにおけるマルチパス処理で従来の一般的な実装では、デバイスマッパーフレームワークを使用します。SCSIデバイスなどのほとんどのデバイスタイプでは、デバイスマッパーのマルチパス処理が唯一使用可能な実装です。デバイスマッパーのマルチパスは、高度に設定可能で、柔軟性に優れています。

Linux NVM Express (NVMe)カーネルサブシステムでは、カーネルでマルチパス処理をネイティブに実装します。通常高速で遅延が非常に小さいNVMeデバイスの演算オーバーヘッドが、この実装で軽減されています。ネイティブNVMeマルチパス処理ではユーザスペースコンポーネントは不要です。SLE 15以降、ネイティブマルチパス処理がNVMeマルチパスデバイスのデフォルトになっています。詳細については、17.2.4項 「マルチパス処理」を参照してください。

この章では、デバイスマッパーマルチパスおよびそのユーザスペースコンポーネントmultipath-toolsについて説明します。multipath-toolsは、ネイティブのNVMeマルチパス処理も限定的にサポートしています(18.13項 「その他のオプション」を参照)。

デバイスマッパーのマルチパスは一般的な技術です。マルチパスデバイスの検出で必要なことは、低レベルデバイス(SCSIなど)がカーネルによって検出されることと、デバイスのプロパティが複数の低レベルデバイスを(実際に異なるデバイスではなく)同じボリュームへの異なる「パス」として確実に識別することのみです。

multipath-toolsパッケージは、ベンダと製品名によってストレージアレイを検出します。これには、広範なストレージ製品に対してデフォルト設定が組み込まれています。ご使用のストレージアレイのハードウェアドキュメントを参照してください。Linuxのマルチパス処理設定に対して独自の推奨事項を提示しているベンダもあります。

使用しているストレージアレイの組み込み設定に変更を適用する必要がある場合、18.8項 「マルチパス設定」を参照してください。

重要: 組み込みのハードウェアプロパティに関する免責条項

multipath-toolsには、多くのストレージアレイ用の事前設定が組み込まれています。あるストレージ製品用にこのような事前設定が存在することは、そのストレージ製品のベンダがdm-multipathで製品をテストしたことを意味しませんし、ベンダがその製品でdm-multipathの使用に関して保証やサポートを行うことも「意味しません」。サポート関連の質問については、ベンダのドキュメントを必ず参照してください。

あるパスから別のパスにフェールオーバーするための特殊なコマンドや標準と異なるエラー処理方法が必要なストレージアレイもあります。これらの特殊なコマンドと方法は、Linuxカーネルのハードウェアハンドラによって実装されています。最新のSCSIストレージアレイは、SCSI標準で定義されている「Asymmetric Logical Unit Access」(ALUA)ハードウェアハンドラをサポートしています。ALUAの他に、SLEカーネルには、Netapp E-Series (RDAC)、Dell/EMC CLARiiON CXアレイファミリ、およびHPのレガシアレイ用のハードウェアハンドラが含まれています。

Linuxカーネル4.4以降では、ほとんどのアレイ(ALUAをサポートするすべてのアレイを含む)のハードウェアハンドラをLinuxカーネルで自動検出します。要件は、それぞれのデバイスが検出されるときにデバイスハンドラモジュールがロードされることだけです。この要件は、multipath-toolsパッケージが適切な設定ファイルをインストールすることによって実現します。デバイスハンドラは、特定のデバイスにアタッチされると、変更できなくなります。

インストールタイプは、ルートデバイスを処理する方法で区別されます。18.4項 「マルチパスシステムでのSUSE Linux Enterprise Serverのインストール」では、インストール中およびインストール後にさまざまなセットアップを作成する方法について説明しています。

サードパーティSANアレイ管理ツールやご使用のストレージアレイのユーザインタフェースを使用して、論理デバイスを作成し、それらをホストに割り当てます。両側でホストの資格情報を正しく設定してください。

実行中のホストにボリュームを追加したり、削除したりできますが、変更を検出するには、SCSIターゲットを再スキャンし、ホスト上でマルチパス処理を再設定する必要がある場合があります。18.14.6項 「新規デバイスのスキャン(再起動なし)」を参照してください。

注記: ストレージプロセッサ

一部のディスクアレイでは、ストレージアレイがストレージプロセッサを使用してトラフィックを管理します。1つのプロセッサがアクティブとなり、もう1つのプロセッサは障害が発生するまでパッシブとなります。パッシブストレージプロセッサに接続している場合、目的のLUNが表示されないか、表示はされるがアクセスしようとするとI/Oエラーが発生する場合があります。

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

マルチパス処理は、SCSIデバイスなどの基本的なストレージデバイスの上にセットアップされます。マルチレイヤのストレージスタックでは、マルチパス処理は常に最下位レイヤです。ソフトウェアRAID、論理ボリューム管理、ブロックデバイスの暗号化などのその他のレイヤは、マルチパス処理の上に重ねられます。したがって、複数のI/Oパスを持ち、ソフトウェアRAIDで使用予定の各デバイスは、まず、マルチパス処理用に設定してから、ソフトウェアRAIDデバイスとして作成する必要があります。

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

マルチパスデバイスがすべてのデバイス間で同じ名前であるようにしてください。詳細については、18.12項 「マルチパスデバイス名とWWID」を参照してください。

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

pacemakerとsbdなどフェンシングに共有ストレージを使用するクラスタリングソフトウェアと共にマルチパス処理を使用する場合、特別な注意が必要です。詳細については18.9.2項 「クラスタ化されたサーバでのキューポリシー」を参照してください。

後で、システムにマルチパスSANデバイスを追加する目的で、最初にFabricとストレージを設定せずに、ローカルディスク上でインストールを実行したい場合があります。この場合、インストールは、非マルチパスシステム上でのインストールのように続行します。インストール後、multipath-toolsがインストールされますが、systemdサービス(multipathd.service)は無効になります。システムは、18.3.2.2項 「ローカルディスクのルートファイルシステム」のinitramfsでマルチパスを無効にするで説明しているように設定されます。SANハードウェアを追加する前に、multipathd.serviceを有効にし、開始する必要があります。ルートデバイス用に/etc/multipath.confにblacklistエントリを作成することをお勧めします(18.11.1項 「multipath.confのblacklistセクション」を参照)。

マルチパスデバイスが、インストール時にシステムに接続される場合、YaSTはそれらを検出し、パーティショニングステージに入る前にマルチパスを有効にするかどうかを尋ねるポップアップウィンドウを表示します。

このプロンプトで「いいえ」を選択すると(非推奨)、インストールは18.4.1項 「接続されているマルチパスデバイスを使用しないインストール」のように続行します。パーティショニングステージでは、後でマルチパスマップの一部になるデバイスを使用/編集しないでください。

マルチパスのプロンプトで「はい」を選択すると、インストール中にmultipathdが実行されます。/etc/multipath.confのblacklistセクションにはデバイスは追加されないため、パーティショニングダイアログでは、ローカルディスクを含むすべてのSCSIデバイスとDASDデバイスがマルチパスデバイスとして表示されます。インストール後、18.3.2.1項 「マルチパスのルートファイルシステム(SANブート)」で説明されているように、すべてのSCSIデバイスとDASDデバイスがマルチパスデバイスになります。

デバイスマッパーマルチパス(DM-MP)モジュール(dm-multipath.ko)は、Linuxに一般的なマルチパス処理機能を提供します。DM-MPIOは、SCSIおよびDASDデバイスに対してSUSE Linux Enterprise Serverでマルチパス処理を行う際に推奨されるソリューションであり、NVMeデバイスにも使用できます。

注記: NVMeデバイスに対してDM-MPを使用する

SUSE Linux Enterprise Server 15以降、ネイティブNVMeマルチパス処理(18.2.1項 「マルチパスの実装: デバイスマッパーとNVMe」を参照)がNVMeに推奨され、デフォルトで使用されています。ネイティブNVMeマルチパス処理を無効にし、代わりにデバイスマッパーマルチパスを使用するには(「非推奨」)、カーネルパラメータnvme-core.multipath=0を指定してブートします。

デバイスマッパーマルチパスモジュールは次のタスクを処理します。

次のタスクは、デバイスマッパーのマルチパスモジュールではなく、multipath-toolsパッケージのユーザスペースコンポーネントによって処理されます。

multipath-toolsパッケージのコンポーネントの詳細については、18.6.2項 「multipathdデーモン」を参照してください。

注記: マルチパスが防ぐ障害

DM-MPIOは、メディアエラーなどのデバイス自体の障害ではなく、デバイスへのパスの障害からシステムを保護します。デバイス自体の障害は、レプリケーションなど別の方法で防ぐ必要があります。

multipathdは、最新Linuxデバイスマッパーのマルチパスにおけるセットアップの最重要部分です。これは通常、systemdサービスmultipathd.serviceを通じて開始されます(18.7.1項 「マルチパスサービスの有効化、起動、および停止」を参照)。

multipathdは次のタスクを実行します(設定によって異なるものもあります)。

multipathdでは、コマンドラインのクライアントとしても動作し、インタラクティブコマンドを実行デーモンに送信することでコマンドを処理します。デーモンにコマンドを送信する一般的な構文は次のとおりです。

> sudo multipathd COMMAND

あるいは、

> sudo multipathd -k'COMMAND'

複数の後続のコマンドを送信できる対話的モードもあります。

> sudo multipathd -k

注記: multipathとmultipathdを同時に動作させる方法

多くのmultipathdのコマンドには、multipathの同等コマンドがあります。たとえば、multipathd show topologyの動作はmultipath -llの動作と同じです。顕著な違いは、multipathdコマンドは実行中のmultipathdデーモンの内部状態を問い合わせるのに対して、multipathはカーネルおよびI/O操作から直接情報を取得することです。

マルチパスデーモンが実行中である場合、multipathdコマンドを使用してシステムを変更することをお勧めします。このようにしないと、デーモンが設定の変更に気づき、変更に反応する場合があります。場合によっては、適用された変更をデーモンで元に戻そうとします。multipathは、実行中のデーモンが検出された場合、マップの破棄やフラッシュなどの特定の危険性のあるコマンドをmultipathdに自動的に委任します。

下記のリストでは、使用頻度が高いmultipathdコマンドについて説明します。

パス状態の変更、キューの有効化または無効化などを実行できるコマンドも利用できます。詳細についてはmultipathd(8)を参照してください。

マルチパスのセットアップはほとんど自動化されており、multipathdで処理されますが、multipathも一部の管理タスクで依然として役立ちます。このコマンドの使用例を次に示します。

-vオプションによって、出力の詳細レベルが制御されます。指定した値によって、/etc/multipath.confのverbosityオプションが上書きされます。18.13項 「その他のオプション」を参照してください。

mpathpersistユーティリティを使用して、デバイスマッパーマルチパスのデバイスでSCSIの永続的な予約を管理します。永続的な予約を行うと、SCSIの論理ユニットへのアクセスが特定のSCSIイニシエータに制限されます。マルチパス設定では、指定ボリュームですべてのI_T関連付け(パス)に同じ予約キーを使用することが重要です。そのようにしないと、あるパスデバイスで予約を作成すると別のパスでI/Oエラーが発生する場合があります。

このユーティリティを/etc/multipath.confファイルのreservation_key属性と共に使用して、SCSIデバイスの永続的な予約を設定します。このオプションが設定されている場合(のみ)、multipathdデーモンは新しく検出したパスまたは復帰したパスの永続的な予約をチェックします。

この属性は、multipath.confのdefaultsセクションまたはmultipathsセクションに追加できます。例:

multipaths {
    multipath {
        wwid             3600140508dbcf02acb448188d73ec97d
        alias            yellow
        reservation_key  0x123abc
    }
}

永続的な管理に適用可能なすべてのmpathデバイスに対してreservation_keyパラメータを設定した後、multipathd reconfigureを使用して設定を再ロードします。

注記: 使用 “reservation_key file”

特別な値であるreservation_key fileがmultipath.confのdefaultsセクションで使用される場合、mpathpersistを使用して/etc/multipath/prkeysファイルで予約キーを動的に管理できます。

これは、マルチパスマップで永続的な予約を処理する際のお勧めの方法です。この方法はSUSE Linux Enterprise Server 12 SP4から使用できます。

mpathpersistコマンドを使用して、SCSIデバイスで構成されるマルチパスマップの永続的な予約を問い合わせて、設定します。詳細については、mpathpersist(8)のマニュアルページを参照してください。このコマンドラインオプションは、sg3_utilsパッケージのsg_persistのオプションと同じです。sg_persist(8)のマニュアルページでは、このオプションの意味を詳細に説明しています。

次の例では、DEVICEは/dev/mapper/mpathaなど、デバイスマッパーのマルチパスデバイスを示しています。下記のコマンドは、読みやすくするために長いオプションと共にリストしています。すべてのオプションには、mpathpersist -oGS 123abc DEVICEのように1文字の置換文字が含まれています。

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

> sudo systemctl enable multipathd

実行中のシステムでサービスを手動で開始するには、次のように入力します。

> sudo systemctl start multipathd

サービスを再開するには、次のように入力します。

> sudo systemctl restart multipathd

ほとんどの状況で、サービスの再開は不要です。単にmultipathdに設定を再ロードさせるには、次のコマンドを実行します。

> sudo systemctl reload multipathd

サービスのステータスを確認するには、次のように入力します。

> sudo systemctl status multipathd

現行セッションのマルチパスサービスを停止するには、次のコマンドを実行します。

> sudo systemctl stop multipathd multipathd.socket

サービスを停止しても既存のマルチパスマップは削除されません。未使用マップを削除するには、次のコマンドを実行します。

> sudo multipath -F

警告: multipathd.serviceを常に有効にしておいてください

マルチパスハードウェアを備えたシステムでは、multipathd.serviceを常に有効にして実行しておくことを強くお勧めします。このサービスは、systemdのソケットアクティベーションメカニズムをサポートしていますが、このメカニズムに依存することはお勧めしません。このサービスが無効になっていると、マルチパスマップは起動時にセットアップされません。

注記: マルチパスの無効化

上記の警告にもかかわらずマルチパスを無効にする必要がある場合(サードパーティのマルチパス処理ソフトウェアを導入するなど)、次のように進めます。マルチパスデバイスへのハードコード化された参照をシステムで使用していないことを確認します(18.15.2項 「デバイス参照の問題の理解」を参照)。

1回のシステムブートに対してのみマルチパス処理を無効にするには、カーネルパラメータのmultipath=offを使用します。これはブートシステムとinitramfsの両方に影響します。この場合はinitramfsを再構築する必要はありません。

multipathdサービスを恒久的に無効にして、今後のシステムブートでこのサービスが開始されないようにするには、次のコマンドを実行します。

> sudo systemctl disable multipathd multipathd.socket
> sudo dracut --force --omit multipath

(マルチパスサービスを無効または有効にするときには必ずinitramfsを再構築してください。詳細については、18.7.4項 「initramfsの同期状態の維持」を参照してください。)

「multipathを手動で実行するときにも」マルチパスデバイスが設定されないようにする場合は、initramfsを再構築する前に、/etc/multipath.confの最後に次の行を追加します。

blacklist {
    wwid .*
}

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

マルチパスデバイスが検出され、multipathd.serviceが有効になっている場合、マルチパスマップは自動的に作成されるはずです。作成されない場合、18.15.3項 「緊急モードでのトラブルシューティング手順」に、状況の調査に使用できるシェルコマンドのリストが表示されます。LUNがHBAドライバによって認識されない場合は、SANのゾーン化セットアップをチェックします。特に、LUNのマスキングがアクティブであるかどうか、LUNがサーバに正しく割り当てられているかどうかをチェックしてください。

LUNがHBAドライバによって認識できるが、対応するブロックデバイスが作成されない場合は、追加のカーネルパラメータが必要な場合があります。SUSE KnowledgeのTID 3955167: Troubleshooting SCSI (LUN) Scanning Issues (https://www.suse.com/support/kb/doc.php?id=3955167)を参照してください。

マルチパスマップには、そのパスデバイスのようなパーティションを設けることができます。パーティションテーブルのスキャンとパーティションのデバイスノードの作成は、ユーザスペースでkpartxツールによって実行されます。kpartxは、udevルールによって自動的に起動します。通常、手動での実行は不要です。マルチパスのパーティションを参照する方法については、18.12.4項 「マルチパスマップの参照」を参照してください。

注記: kpartxの起動の無効化

/etc/multipath.confのskip_kpartxオプションを使用して、選択したマルチパスマップでのkpartxの起動を無効にできます。たとえば、これは仮想化ホストで有用である場合があります。

マルチパスデバイス上のパーティションテーブルとパーティションは、YaSTまたはfdiskやpartedなどのツールを使用して、通常どおり操作できます。パーティションテーブルに適用する変更は、パーティション処理ツールが終了するとシステムによって記録されます。これが動作しない場合(デバイスがビジーであることが原因であることが多い)、multipathd reconfigureを試すか、またはシステムを再起動してください。

重要

初期RAMファイルシステム(initramfs)とブートシステムが、すべてのブロックデバイスのマルチパス処理の使用に関して一貫した動作をしていることを確認します。マルチパス設定の変更を適用した後にinitramfsを再構築します。

システムでマルチパス処理が有効になっている場合はinitramfsでも有効にする必要があり、その逆も同様です。このルールの唯一の例外は18.3.2.2項 「ローカルディスクのルートファイルシステム」のオプションinitramfsでマルチパスを無効にするです。

マルチパス設定は、ブートシステムとinitramfsの間で同期する必要があります。したがって、/etc/multipath.conf、/etc/multipath/wwids、/etc/multipath/bindingsのいずれかのファイル、その他の設定ファイル、またはデバイスの識別に関係のあるudevルールを変更した場合、次のコマンドを使用してinitramfsを再構築します。

> sudo dracut -f

initramfsとシステムが同期されていない場合、システムは正しくブートせず、起動手順を実行すると緊急シェルが起動する可能性があります。このようなシナリオを回避または修復する方法については、18.15項 「MPIOのトラブルシューティング」を参照してください。

> sudo dracut --force --add multipath

> sudo dracut --force --omit multipath

/dev/mapper/3600a098000aad73f00000a3f5a275dc8-part1

> sudo dracut --force --omit multipath --persistent-policy=by-uuid

変更する設定のみが含まれている最低限の/etc/multipath.confを作成することをお勧めします。多くの場合、/etc/multipath.confを作成する必要はありません。

考え得る設定ディレクティブすべてを含む設定テンプレートで作業したい場合、次のコマンドを実行します。

multipath -T >/etc/multipath.conf

18.14.1項 「設定のベストプラクティス」も参照してください。

/etc/multipath.confファイルでは、セクション、サブセクション、およびオプション/値のペアの階層を使用します。

構文は、次のようにします。

section {
    subsection {
        option1 value
        option2      "complex value!"
        option3    "value with ""quoted"" word"
    } ! subsection end
} # section end

/etc/multipath.confファイルは、以下のセクションで構成されています。一部のオプションは複数のセクションで使用できます。詳細についてはmultipath.conf(5)を参照してください。

設定変更を適用するには、次のコマンドを実行します。

> sudo multipathd reconfigure

忘れずにinitramfsの設定と同期してください。18.7.4項 「initramfsの同期状態の維持」を参照してください。

警告: multipathを使用して設定を適用しない

multipathを実行中にmultipathdコマンドを使用して新しい設定を適用しないでください。適用すると、セットアップに一貫性がなくなり、セットアップが破損する可能性があります。

注記: 変更したセットアップの確認

変更した設定を適用する前にテストできます。そのためには次のコマンドを実行します。

> sudo multipath -d -v2

このコマンドは、提案されたトポロジを使用して作成される新しいマップを表示しますが、マップが削除/フラッシュされるかどうかは表示しません。より多くの情報を得るには、詳細度を上げて次のコマンドを実行します。

> sudo multipath -d -v3 2>&1 | less

スタンドアロンサーバに対してマルチパスI/Oを設定する際は、no_path_retryで値をqueueに設定することにより、サーバのオペレーティングシステムを、I/Oエラーの受信から可能な限り保護することができます。この設定では、マルチパスのフェールオーバーが発生するまでメッセージはキューに入ります。「無限」のキューを望まない場合(上記を参照)、通常の状況下でストレージパスが回復するのに十分大きいとみなされる数値を選択します(上記を参照)。

高可用性クラスタ内のノードに対してマルチパスI/Oを構成するときには、マルチパスでリソースのフェールオーバーをトリガするためにI/O障害が報告されるようにして、マルチパスのフェールオーバーが解決されるのを待たなくて済むようにするとよいでしょう。クラスタ環境では、no_path_retry 設定を、ストレージシステムへの接続が失われた場合に、クラスタノードがクラスタ検証プロセスに関連するI/Oエラー(ハートビート許容値の50%を推奨)を受信するように変更する必要があります。また、パスの障害によるリソースのピンポンを避けるため、マルチパスのfailbackをmanualまたはfollowoverに設定するとよいでしょう。

/etc/multipath.confファイルには、multipathdとmultipathで無視する必要があるすべてのデバイスを列挙するblacklistセクションを含めることができます。次の例は、デバイスを除外する考えられる方法を示しています。

blacklist {
    wwid 3600605b009e7ed501f0e45370aaeb77f 1
    device {  2
        vendor ATA
        product .*
    }
    protocol scsi:sas 3
    property SCSI_IDENT_LUN_T10 4
    devnode "!^dasd[a-z]*" 5
}

> sudo multipathd show paths format "%d %P"

デフォルトでは、multipath-toolsは、SCSI、DASDまたはNVMeを除くすべてのデバイスを無視します。技術的には、組み込みのdevnode除外リストは、次の否定された正規表現です。

    devnode !^(sd[a-z]|dasd[a-z]|nvme[0-9])

特定のデバイスのみをマルチパス処理用に設定することが望ましい場合があります。この場合、デバイスはデフォルトで除外され、マルチパスマップの一部となるデバイスに対して例外が定義されます。この目的でblacklist_exceptionsセクションが存在します。これは通常、次の例のように使用されます。この例では、製品文字列「NETAPP」のストレージを除くすべてが除外されます。

blacklist {
     wwid .*
}
blacklist_exceptions {
     device {
         vendor ^NETAPP$
         product .*
     }
}

blacklist_exceptionsセクションでは、上記のblacklistセクションで説明されているすべての方法がサポートされます。

blacklist_exceptionsのpropertyディレクティブは必須です。なぜなら、マルチパスのパスデバイスとみなされるために、すべてのデバイスは少なくとも1つの「許可された」udevプロパティを持つ「必要がある」ためです(プロパティの値は重要ではありません)。propertyの組み込みのデフォルトは次のとおりです。

    property (SCSI_IDENT_|ID_WWN)

この正規表現に一致するudevプロパティを少なくとも1つ持つデバイスのみが含まれます。

blacklistオプション以外にも、/etc/multipath.confには、どのデバイスをマルチパスのパスデバイスとみなすかに影響するその他の設定がいくつかあります。

マルチパス操作では、同じストレージボリュームへのパスを表すデバイス検出の信頼性が高いことが非常に重要です。multipath-toolsは、この目的でデバイスのWWID (World Wide Identification: ワールドワイドID)を使用します(これはUUID (Universally Unique ID: ユニバーサルユニークIDまたはUID (Unique ID: ユニークID)と呼ばれることもあります(ユーザIDと混同しないでください)。マップデバイスのWWIDは、常にそのパスデバイスのWWIDと同じです。

デフォルトでは、パスデバイスのWWIDは、sysfsファイルシステムからデバイスの属性を読み取ることによって、または固有のI/Oコマンドを使用して、udevルールで決定されるデバイスのudevプロパティから推測されます。デバイスのudevプロパティを確認するには、次のコマンドを実行します。

> udevadm info /dev/sdx

WWIDを導出するためにmultipath-toolsによって使用されるudevプロパティを次に示します。

警告: WWIDの変更を回避する

使用中のマルチパスマップのWWIDは変更できません。設定の変更により、マップされたパスデバイスのWWIDが変更された場合は、マップを破棄し、新しいWWIDで新しいマップをセットアップする必要があります。これは、古いマップを使用中には実行できません。極端な場合、WWIDの変更によってデータが破損する可能性があります。したがって、マップのWWIDが変更される結果となる設定変更の適用は、「厳格に回避する」必要があります。

/etc/multipath.confでuid_attrsオプションを有効にすることは許可されています。18.13項 「その他のオプション」を参照してください。

/etc/multipath.confのmultipathsセクションで、次のように任意のマップ名を設定できます。

multipaths {
    multipath {
        wwid 3600a098000aad1e3000064e45f2c2355
        alias postgres
    }
}

エイリアスは表現力が豊かですが、各マップに個別に割り当てる必要があるため、大規模なシステムでは面倒な場合があります。

multipath-toolsは、自動生成されたエイリアス、いわゆる「ユーザフレンドリ名」もサポートしています。エイリアスの命名規則は、mpathINDEXというパターンに従います。ここでINDEXは小文字です(aで始まります)。したがって、最初に自動生成されるエイリアスはmpathaで、その後mpathb、mpathcと続き、mpathzまで続きます。その後は、mpathaa、mpathabなどが続きます。

マップ名は、永続的である場合のみ有用です。multipath-toolsは、/etc/multipath/bindingsファイル(「バインディングファイル」)で割り当てられた名前を追跡します。新しいマップが作成されると、最初にこのファイルでWWIDが検索されます。WWIDが見つからない場合、最も可用性が低いユーザフレンドリ名がこれに割り当てられます。

18.12.2項 「マルチパスマップのエイリアスの設定」で説明されているように、明示的なエイリアスがユーザフレンドリ名よりも優先されます。

/etc/multipath.confの次のオプションは、ユーザフレンドリ名に影響します。

警告: 高可用性クラスタのマップ名

クラスタ操作では、クラスタ内のすべてのノードにわたってデバイス名を同じにする必要があります。multipath-toolsの設定は、ノード間で同期状態を保つ必要があります。user_friendly_namesを使用している場合、multipathdは実行時に/etc/multipath/bindingsファイルを変更する可能性があります。このような変更は、すべてのノードに対して動的に複製する必要があります。同じことが/etc/multipath/wwidsにも当てはまります(18.11.3項 「デバイスの選択に影響するその他のオプション」を参照)。

注記: 実行時のマップ名の変更

実行時にマップ名を変更できます。このセクションで説明されている方法のいずれかを使用して、multipathd reconfigureを実行すると、システム操作を妨げることなくマップ名が変更されます。

技術的には、マルチパスマップは、デバイスマッパーデバイスです。これには、/dev/dm-nという形式の汎用名があります(nは整数)。これらの名前は永続的ではありません。これらは、マルチパスマップを参照するために使用「しない」でください。udevを実行すると、これらのデバイスへのさまざまなシンボリックリンクが作成されます。これらは、永続的な参照としてより適切です。これらのリンクは、特定の設定変更に対する不変性の点で異なります。次の一般的な例は、すべて同じデバイスを指しているさまざまなシンボリックリンクを示しています。

/dev/disk/by-id/dm-name-mpathb1 -> ../../dm-1
/dev/disk/by-id/dm-uuid-mpath-3600a098000aad73f00000a3f5a275dc82 -> ../../dm-1
/dev/disk/by-id/scsi-3600a098000aad73f00000a3f5a275dc83 -> ../../dm-1
/dev/disk/by-id/wwn-0x600a098000aad73f00000a3f5a275dc84 -> ../../dm-1
/dev/mapper/mpathb5 -> ../dm-1

filter = [ "a|/dev/disk/by-id/dm-uuid-mpath-.*|", "r|.*|" ]

kpartxツールで作成されたマルチパスマップ上の「パーティション」の場合、親デバイス名またはWWIDとパーティション番号から派生した同様のシンボリックリンクがあります。

/dev/disk/by-id/dm-name-mpatha-part2 -> ../../dm-5
/dev/disk/by-id/dm-uuid-part2-mpath-3600a098000aad1e300000b4b5a275d45 -> ../../dm-5
/dev/disk/by-id/scsi-3600a098000aad1e300000b4b5a275d45-part2 -> ../../dm-5
/dev/disk/by-id/wwn-0x600a098000aad1e300000b4b5a275d45-part2 -> ../../dm-5
/dev/disk/by-partuuid/1c2f70e0-fb91-49f5-8260-38eacaf7992b -> ../../dm-5
/dev/disk/by-uuid/f67c49e9-3cf2-4bb7-8991-63568cb840a4 -> ../../dm-5
/dev/mapper/mpatha-part2 -> ../dm-5

パーティションにはby-uuidリンクもあることが多く、デバイス自体を参照するのではなく、デバイスに含まれているファイルシステムを参照します。多くの場合、これらのリンクが推奨されます。これらは、ファイルシステムが別のデバイスまたはパーティションにコピーされても不変です。

警告: initramfsのマップ名

dracutは、initramfsを構築するとき、initramfsのデバイスへのハードコード化された参照を作成します。デフォルトでは、/dev/mapper/$MAP_NAME参照を使用します。これらのハードコード化された参照は、initramfsで使用されているマップ名がinitramfs構築中に使用した名前と一致しない場合、起動中には見つからず、起動エラーになります。通常、この状況にはなりません。その理由は、dracutがすべてのマルチパス設定ファイルをinitramfsに追加するためです。ただし、initramfsが異なる環境(レスキューシステム、またはオフライン更新中など)から構築されている場合、この問題が発生する可能性があります。この起動エラーが発生しないようにするには、18.7.4.2項 「initramfsの永続的なデバイス名」で説明されているように、dracutのpersistent_policy設定を変更します。

Fabricの状態が不安定だと、パスデバイスの動作が不安定になる可能性があります。I/Oエラーの発生、回復、障害の再発が頻繁に起こります。このようなパスデバイスは、「ぎりぎりの」または「不安定な」パスと呼ばれることもあります。このセクションでは、この問題に対処するためにmultipath-toolsが提供するオプションをまとめています。

注記: multipathdのぎりぎりのパスチェックアルゴリズム

パスデバイスで、最初の失敗が発生してからmarginal_path_double_failed_timeが経過する前に、2回目の失敗(良好→不良の移行)が発生した場合、multipathdは、監視期間marginal_path_err_sample_timeの間、1秒あたり10回の要求の速度でパスの監視を開始します。監視期間中のエラー率がmarginal_path_err_rate_thresholdを超えると、このパスはぎりぎりに分類されます。marginal_path_err_recheck_gap_time経過後、パスは、再び通常状態に移行します。

このアルゴリズムは、4つの数値パラメータmarginal_path_がすべて正の値に設定されていて、marginal_pathgroupsがfpinに設定されていない場合に使用されます。これは、SUSE Linux Enterprise Server 15 SP1およびSUSE Linux Enterprise Server 12 SP5以降で利用できます。

パラメータsan_path_err_threshold、san_path_err_forget_rate、およびsan_path_err_recovery timeを使用したより単純なアルゴリズムも利用可能で、SUSE Linux Enterprise Server 15 (GA)で推奨されています。multipath.conf(5)の「不安定なパスの検出」セクションを参照してください。

設定ディレクティブの数が多いと最初は気後れします。通常、クラスタ環境で作業していない限り、空の設定で良い結果を得ることができます。

ここでは、スタンドアロンサーバの一般的な推奨事項を紹介します。これらは「必須ではありません」。背景情報については、前の各セクションの該当するパラメータのマニュアルを参照してください。

defaults {
    deferred_remove      yes
    find_multipaths      smart
    enable_foreign       nvme
    marginal_pathgroups  fpin    # 15.4 only, if supported by fabric
}
devices {
    # A catch-all device entry.
    device {
        vendor                .*
        product               .*
        dev_loss_tmo          infinity
        no_path_retry         60            # 5 minutes
        path_grouping_policy  group_by_prio
        path_selector         "historical-service-time 0"
        reservation_key       file          # if using SCSI persistent reservations
    }
    # Follow up with specific device entries below, they will take precedence.
}

/etc/multipath.confファイルを変更した後、18.8.4項 「multipath.confの変更の適用」の説明に従って設定を適用します。

マルチパスサブシステムの概要を簡単に確認するには、multipath -llまたはmultipathd show topologyを使用します。これらのコマンドの出力の形式は同じです。前のコマンドはカーネルの状態を読み取り、後のコマンドはマルチパスデーモンのステータスを出力します。通常、両方の状態は同じです。出力の一例を次に示します。

> sudo multipathd show topology
mpatha1 (3600a098000aad1e300000b4b5a275d452) dm-03 NETAPP,INF-01-004
size=64G features='3 queue_if_no_path pg_init_retries 50'5 hwhandler='1 alua'6 wp=rw7
|-+- 8policy='historical-service-time 2'9 prio=5010 status=active11
| |-12 3:0:0:113 sdb 8:1614 active15 ready16 running17
| `- 4:0:0:1 sdf 8:80  active ready running
`-+- policy='historical-service-time 2' prio=10 status=enabled
  `- 4:0:1:1 sdj 8:144 active ready running

マルチパスのパスデバイスの状態を次に示します。

LVM2には、マルチパスデバイスを検出するためのサポートが組み込まれています。これは/etc/lvm/lvm.confでデフォルトでアクティブになっています。

    multipath_component_detection=1

これは、デバイスのプロパティに関する情報もudevから取得するようにLVM2が設定されている場合のみ安定して動作します。

    external_device_info_source="udev"

これは、SUSE Linux Enterprise 15 SP4ではデフォルトですが、以前のリリースでは違います。マルチパスデバイスを除くすべてのデバイスを無視するLVM2のフィルタ式を作成することも可能です(通常は不要です)。18.12.4項 「マルチパスマップの参照」を参照してください。

すべてのパスで同時に障害が発生し、I/Oがキューに格納される場合、アプリケーションが長時間停止する可能性があります。これを解決するために、次の手順を使用できます。

マルチパス処理の上部でMD RAIDアレイは、システムのudevルールによって自動的にセットアップされます。/etc/mdadm.confの特別な設定は不要です。

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

> sudo rescan-scsi-bus.sh [-a] [-r] --hosts=2-3,5

各オプションには次のような意味があります。

その他のオプションのヘルプを表示するには、rescan-scsi-bus.sh --helpを実行します。

multipathdが実行中で、新しいSANデバイスが検出される場合、18.11項 「マルチパス処理のためのデバイスの選択」で説明されている設定に従って、マルチパスマップとして自動的にセットアップされるはずです。

警告: Dell/EMC PowerPath環境

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

ブロックデバイスは、マルチパスマップの一部にするか、または直接使用(ファイルシステムとしてマウント、スワップとして使用、LVM物理モジュール、その他)することができます。デバイスがすでにマウントされている場合、これをmultipathdでマルチパスマップの一部にしようとすると失敗し、「デバイスまたはリソースがビジーです」(Device or resource busy)というエラーが表示されます。逆に、すでにマルチパスマップの一部になっているデバイスをsystemdがマウントしようとすると同じエラーが発生します。

起動中のストレージデバイスのアクティブ化は、systemd、udev、multipathdおよび他のいくつかのツール間の複雑なやりとりで処理されます。udevルールが中心的な役割を果たします。これらは、デバイスの使用方法を他のサブシステムに指示するデバイスのプロパティを設定します。マルチパス関連のudevルールは、マルチパス処理用に選択されたデバイスに対して次のプロパティを設定します。

SYSTEMD_READY=0
DM_MULTIPATH_DEVICE_PATH=1

パーティションデバイスは、これらのプロパティをその親から継承します。

これらのプロパティが正しく設定されていない場合、一部のツールがこれらのプロパティに従っていない場合、またはプロパティが設定されるのが遅すぎる場合、multipathdと他のサブシステムとの間で競合状態が発生する可能性があります。競合に勝ち残れるのは1つだけです。それ以外は、「デバイスまたはリソースがビジーです」(Device or resource busy)というエラーが表示されます。

このコンテキストにおける1つの問題は、LVM2スイートのツールがデフォルトではudevプロパティを評価しないことです。これらは、デバイスがマルチパスコンポーネントかどうかを判定する独自のロジックを使用しますが、このロジックは、システムの残りの部分のロジックと一致しない場合があります。この回避方法は、18.14.3項 「マルチパスデバイスでのLVM2の使用」で説明されています。

注記: 起動デッドロックの例

ルートデバイスがマルチパス処理されておらず、マルチパスから除外されているデバイスがない、マルチパス処理を備えたシステムを考えてみます(18.3.2.2項 「ローカルディスクのルートファイルシステム」のinitramfsでマルチパスを無効にするを参照)。このルートファイルシステムはinitramfsにマウントされています。systemdはルートファイルシステムに切り換わり、multipathdが起動します。デバイスがすでにマウントされているため、multipathdは、そのデバイスのマルチパスマップをセットアップできません。ルートデバイスはblacklistで設定されていないため、マルチパスデバイスとみなされ、このデバイス用にSYSTEMD_READY=0が設定されます。

起動プロセスの後半で、システムは、/varや/homeなどの追加のファイルシステムをマウントしようとします。通常、これらのファイルシステムはルートファイルシステムと同じデバイス上にあり、デフォルトではルートファイルシステム自体のBTRFSサブボリュームとして配置されます。ただし、systemdは、SYSTEMD_READY=0のためにこれらをマウントできません。「デッドロック状態」: dm-multipathデバイスを作成できず、systemdの基礎となるデバイスはブロックされます。追加のファイルシステムをマウントできず、起動に失敗します。

この問題の解決策はすでに存在します。 multipathdはこの状況を検出し、デバイスをsystemdにリリースします。これにより、ファイルシステムのマウントを続行できます。ただし、一般的な問題を理解することが重要です。より分かりにくい形で発生する可能性もあるからです。

デバイス参照の問題の例は18.7.4.2項 「initramfsの永続的なデバイス名」で示しました。通常、1つのデバイスノードを指すシンボリックリンクは複数存在します(18.12.4項 「マルチパスマップの参照」を参照)。ただし、これらのリンクは常に存在するわけではありません。udevは、現在のudevルールに従ってリンクを作成します。たとえば、マルチパス処理をオフにすると、/dev/mapper/の下にあるマルチパスデバイス用のシンボリックリンクはなくなります。したがって、/dev/mapper/デバイスへの参照は失敗します。

このような参照はさまざまな場所に(特に/etc/fstabおよび/etc/crypttab、initramfs、またはカーネルコマンドラインにも)表示されます。

この問題を回避する最も安全な方法は、起動と起動の間で持続しない種類のデバイス参照またはシステム設定に依存する種類のデバイス参照の使用を避けることです。一般的に、ファイルシステム(およびスワップ領域のような類似のエンティティ)は、含む側のデバイスではなく、ファイルシステム自体のプロパティ(UUIDやラベルなど)によって参照することをお勧めします。このような参照を使用できず、たとえば、/etc/crypttabで、デバイス参照が必要な場合は、オプションを注意深く評価する必要があります。たとえば、18.12.4項 「マルチパスマップの参照」では、最良のオプションは/dev/disk/by-id/wwn-リンクかもしれません。これはmultipath=offでも機能するからです。

微妙に異なるエラー状況が多数あるため、ステップバイステップのリカバリガイドを提供することは不可能です。ただし、これまでのサブセクションから背景知識を得ていれば、マルチパス処理の問題が原因でシステムが緊急モードになった場合、その問題を理解できるはずです。デバッグを始める前に、次の質問を確認してください。

最後の質問の答えがわからない場合、サンプルのdracut緊急プロンプトを次に示します。これは、ルートを切り替える前に出力されます。

Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.

You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.

Give root password for maintenance
(or press Control-D to continue):

rdsosreport.txtが記載されているということは、システムがまだinitramfsから実行されていることを明確に示しています。それでも不明な場合は、ログインして/etc/initrd-releaseファイルが存在するかチェックします。このファイルは、initramfs環境にのみ存在します。

ルートを切り替えた後に緊急モードになった場合、緊急プロンプトは同じように見えますが、rdsosreport.txtは記載されません。

Timed out waiting for device dev-disk-by\x2duuid-c4a...cfef77d.device.
[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):

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