dm-multipathで複数パスストレージの冗長化を本番設計する｜パス優先度とフェイルオーバー動作確認

サーバーとストレージを結ぶパスが1本しかなければ、HBA・ケーブル・スイッチのどれかが障害を起こした時点でI/Oは止まります。dm-multipathはLinuxカーネルのデバイスマッパー層で複数の物理パスを1つの論理デバイスとして束ね、特定のパスに障害が起きた際に別のパスへ自動的に切り替えます。フェイルオーバーだけでなく、ラウンドロビン等のポリシーによる負荷分散も同じ仕組みで実現できるため、SANやiSCSI環境では事実上の標準的手段として定着しています。

dm-multipathが担う役割と設計の前提

まず整理しておきたいのは、dm-multipathが「ストレージ側の冗長化」ではなく「Linuxホスト側のパス管理」であるという点です。ストレージアレイ自体のRAIDやコントローラ二重化とは別レイヤーで動作し、ホストとアレイの間の物理経路を束ねます。この役割分担を正確に把握しておくことが、設計時の混乱を防ぐ第一歩です。

典型的な構成では、サーバーに2枚のHBAを搭載し、それぞれ別系統のFCスイッチを経由してストレージの2つのポートに接続します。この時点でOSから見えるパスは最低4本（HBA×2 × ストレージポート×2）になり、dm-multipathがこれらを1つの/dev/mapper/デバイスとして見せます。iSCSI環境でも考え方は同じで、NICやスイッチの系統を分けてセッションを複数張ることでパスを確保します。

本番設計前に整理すべきパス構成の考え方

アクティブ/アクティブ構成とアクティブ/パッシブ構成

ストレージアレイのモデルによって、複数パスを同時に使えるアクティブ/アクティブ（A/A）か、一方を予備として待機させるアクティブ/パッシブ（A/P）かが決まります。Pure StorageやEMC PowerStoreなど近年のミッドレンジ以上はA/A対応が多い一方、旧来のアレイにはA/P専用のものが残っています。multipath.confのpath_grouping_policyをA/Pアレイにmultibus（全パスを同一グループに入れる設定）で適用すると、非優先コントローラへのI/Oが発生してアレイ側でエラーが起きることがあります。アレイのベンダードキュメントと照合し、適切なポリシーを選ぶことが設計の起点です。

パス優先度（priority）の仕組み

dm-multipathではパスごとに優先度スコアを付けることができ、スコアが高いパスを優先的に使います。prioパラメータで優先度決定アルゴリズムを指定します。代表的なものとして、ALUA（Asymmetric Logical Unit Access）対応アレイ向けのalua、EMC CLARiion向けのemc、NetApp向けのontap、そして静的に値を設定するconstがあります。aluaは現在最も広く使われており、アレイから優先パスのヒントをSCSIコマンドで自動取得するため、手動設定の手間が少なく運用しやすいという特徴があります。

multipath.confの本番向け設定とパス優先度チューニング

設定ファイルは/etc/multipath.confに置きます。インストール直後はほぼ空の状態か、ディストリビューションによってはデフォルト値だけが記載されています。本番環境向けには以下の3セクションを意識して記述します。

defaults セクションでは全デバイスに共通するデフォルト値を設定します。find_multipaths yesはudevによって自動認識されたデバイスだけをdm-multipathの管理対象とするため、不用意にローカルディスクが巻き込まれるリスクを下げます。user_friendly_names yesにすると/dev/mapper/mpathaのような読みやすい名前が付きますが、名前順がパス検出順に依存するため、UUIDベースの命名（alias明示）を好む現場も少なくありません。

devices セクションはベンダー・製品ごとのチューニングを記述します。多くのメジャーアレイはRHEL/SLES同梱のmultipath-toolsパッケージにデフォルトプロファイルが入っているため、独自設定が必要な場合に差分だけ上書きする形が一般的です。path_checker tur（Test Unit Ready）は汎用性が高く、ベンダー固有の検証コマンドが不要な環境に向いています。一方、一部のアレイではpath_checker readsector0の方が検出精度が高いケースもあるため、ベンダー推奨値を優先することを基本姿勢としてください。

multipaths セクションでは特定のWWIDに対してエイリアスや個別設定を付与します。aliasでわかりやすい名前を付け、prio aluaとpath_grouping_policy group_by_prioを組み合わせることで、ALUAスコアが高いパス群を優先パスグループ、低いパス群を次点パスグループとして自動的に分類します。切り替えコストの高いA/Pアレイではno_path_retry failよりno_path_retry 12（デフォルト4秒間隔なら約48秒の猶予）のように余裕を持たせる設定が、障害時の誤判定を減らします。

フェイルオーバー動作の確認手順

設定後の動作確認は、実際にパスを落として挙動を観察するのが最も確実です。テスト環境または十分なメンテナンスウィンドウを確保した本番環境で実施してください。

まず現在のパス状態を確認します。multipathd show pathsを実行すると、各パスのデバイス名・状態（ready / faulty / shaky）・優先度グループが一覧表示されます。multipathd show topologyはツリー形式でグループ構成を示し、どのパスが現在アクティブかが視覚的に把握できます。これらの出力をテスト前の正常状態のベースラインとして記録しておくことを推奨します。

パスを意図的に落とす方法は環境によって異なります。iSCSI環境であればイニシエーター側でセッションを切断する手順が取りやすく、FC環境ではスイッチのポートを一時的に無効化する方法があります。ソフトウェア的に確認するだけならmultipathd -k'fail path sdX'でデーモンに特定パスの障害を通知することも可能です。

パスを落とした後、multipathd show topologyの再実行とjournalctl -u multipathdのログで、フェイルオーバーが想定通りのグループへ切り替わっているかを検証します。フェイルオーバー完了後もI/Oが継続していることをアプリケーション層から確認するには、fioによる連続書き込みテストをバックグラウンドで並走させておくと、I/O中断の有無を数値で把握できます。フェイルオーバーにかかる時間はpolling_interval（デフォルト5秒）とpath_checkerの応答待ち時間に依存するため、SLAと照らし合わせて必要であればポーリング間隔を短縮します。ただし短縮しすぎるとストレージへの問い合わせが増加してアレイ負荷が上がるトレードオフがあり、現場では10〜15秒前後に落ち着くケースが多いです。

切り戻しと運用上の注意点

障害パスが復旧したとき、dm-multipathが自動的にそのパスを優先グループへ戻す（フェイルバック）かどうかはfailbackパラメータで制御します。failback immediateはパス復旧を検知次第すぐに切り戻しますが、不安定なパスが繰り返し復旧・障害を起こす「パスフラッピング」が発生すると、不必要なI/O切り替えが頻発します。failback manualにしておき、運用者がパスの安定を確認してからmultipathd -k'reinstate path sdX'で明示的に復帰させる運用は、高可用性が要求される本番環境で採られることが多いです。

ブラックリスト（blacklistセクション）の管理も重要です。ローカルのNVMeやSATAディスクがdm-multipathに誤って取り込まれると、マルチパスデバイスとして見えることでfsckやLVMの操作に影響が出る場合があります。devnode "^sda$"のような正規表現や、WWIDでの除外設定を明示的に記述することを推奨します。設定反映後はmultipath -v3 2>&1 | lessの詳細ログでどのデバイスが対象として扱われているかをデバッグできます。設定変更後は必ずsystemctl reload multipathdまたはmultipathd reconfigureで反映し、デーモン再起動によるI/O中断を避ける運用が定石です。

2026年現行環境での差分と注意点

RHEL 9系（およびAlmaLinux・Rocky Linux等の互換ディストリビューション）ではmultipath-toolsの設定ファイル分割が進んでおり、/etc/multipath/conf.d/ディレクトリに断片ファイルを置くスタイルが推奨されています。従来の単一/etc/multipath.confも引き続き機能しますが、ベンダー提供のデフォルトプロファイルがconf.d/以下に配置される構成が増えているため、設定の優先順位（後から読まれたファイルが上書きする）を意識しないと意図しない値が適用される場合があります。multipath -tで現在有効な設定を出力して確認する習慣が有用です。

Ubuntu 24.04 LTS（Noble Numbat）でもmultipath-toolsパッケージの構成は同様の方向性で、multipathd.serviceがsystemdユニットとして管理されます。クラウドインスタンスやコンテナホストでローカルディスクのみを使う構成では、multipathd が予期せぬデバイスを掴まないようfind_multipaths noと明示的なブラックリストを設定してからサービスを起動する手順が定着しつつあります。

NVMe-oF（NVMe over Fabrics）環境では、従来のSCSI系dm-multipathとは別に、カーネルのNVMeネイティブマルチパス機能（起動パラメータnvme_core.multipath=Yで有効化）が並立しています。NVMe-oFを使う場合はどちらのマルチパスレイヤーを使うかを明確に決め、混在させないことがトラブル回避の原則です。RHEL 9ではNVMeネイティブマルチパスがデフォルト有効になっているため、既存のdm-multipath構成との干渉を事前に確認する必要があります。

Kubernetes環境でCSIドライバー経由のブロックデバイスをdm-multipathで管理するケースも増えており、ノード上のdaemonsetとmultipath.confの設定が競合する事例が報告されています。Rook/CephやLonghornなどのCSIドライバーが推奨するブラックリスト設定（多くはWWIDベースの除外）を必ず確認してから展開することが、現場での定石になっています。設計段階でストレージ担当・インフラ担当・アプリケーション担当が同じ設定ファイルを確認する場を設けることが、後工程のトラブルを大きく減らします。