multipath-tools による SAN マルチパス段階移行｜パス障害シミュレーションとフェイルオーバー計測・切り戻し

SANストレージへの接続では、ホスト側に複数のHBAポートを用意し、ファブリック経由で複数のストレージポートに接続するマルチパス構成が標準です。Linuxでこの冗長パスを束ねて管理するのが multipath-tools（multipathd）であり、Red Hat系なら device-mapper-multipath、Debian/Ubuntu系なら multipath-tools パッケージがその実装にあたります。既存環境への新規導入や設定変更では、いきなりすべてのボリュームをマルチパスデバイス化するのではなく、一部から段階的に移行するアプローチが現場での標準的な進め方です。

段階移行が有効な理由と前提の整理

段階移行のアプローチが推奨される理由は主に二点あります。一つ目はI/O中断リスクの局所化です。移行対象を絞ることで、設定ミスがあっても影響範囲を最小限に抑えられます。二つ目はフェイルオーバー動作の事前検証で、段階移行の中に意図的なパス障害テストを組み込み、切り替え動作が期待どおりであることを確認してから範囲を広げられます。

前提として、以下の確認を移行前に済ませておきます。

• 対象ホストに multipath-tools または device-mapper-multipath がインストールされていること
• multipathd.service が起動・自動起動設定済みであること
• 移行対象ボリュームのWWIDが特定できていること
• メンテナンス時間または縮退運転が許容できるタイミングであること

環境確認と multipath.conf の初期設定

移行前に現在の状態を確認します。

# バージョン確認
multipathd show version

# デーモン状態確認
systemctl status multipathd

# 認識済みマルチパスデバイス一覧
multipath -l

# ブロックデバイスとWWIDの対応確認
lsblk -o NAME,TYPE,WWID

multipathd が起動していない場合は systemctl enable --now multipathd で起動と自動起動設定を同時に行います。

設定ファイルは /etc/multipath.conf です。段階移行の最初のフェーズでは、移行対象のWWIDだけを multipaths セクションに追加し、それ以外はブラックリストで除外する構成が安全です。以下は想定例です。

defaults {
    user_friendly_names yes
    find_multipaths yes
    polling_interval 5
}

blacklist {
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^hd[a-z]"
    devnode "^nvme[0-9]+"
}

multipaths {
    multipath {
        wwid "3600508b1001xxxxxxxxxxxxxxxxxxxxxxxx"
        alias san_vol01
        path_grouping_policy failover
        path_checker tur
        failback immediate
        no_path_retry 3
    }
}

alias を明示的に設定しておくと、再起動後も /dev/mapper/san_vol01 という固定名でデバイスを参照できます。設定変更後は multipathd reconfigure で再読み込みします。

段階移行の手順

ステップ1：対象ボリュームの特定と設定追加

multipath -ll と lsblk -o NAME,TYPE,WWID を組み合わせて、現在マルチパス管理下にあるデバイスとそうでないデバイスを整理します。移行対象のWWIDが確定したら、/etc/multipath.conf の multipaths セクションに追加し、ブラックリストから除外します。

ステップ2：反映と確認

multipathd reconfigure
multipath -v3 2>&1 | grep -i "san_vol01"

-v3 オプションで詳細なデバッグ出力が得られます。期待するパス数（例：2パス）が認識されているかを確認します。

ステップ3：fstabとマウントの切り替え

/etc/fstab のデバイスパスを /dev/sdX から /dev/mapper/san_vol01 に変更します。切り替えはアンマウント→再マウントで行います。

umount /mnt/san01
mount /dev/mapper/san_vol01 /mnt/san01
df -h /mnt/san01

パス障害シミュレーションとフェイルオーバー計測

段階移行が完了したボリュームに対して、意図的にパス障害を発生させ、フェイルオーバーの動作と所要時間を計測します。本番全体への適用前に必ず実施します。

障害の発生方法

最も確実なのは、FCスイッチ側でポートを無効化する方法です。ソフトウェアレベルではHBAポートを以下のように無効化できますが、HBAドライバによって挙動が異なるため、事前に検証環境での確認が必須です。

# HBAポートをオフラインにする（ドライバ依存）
echo offline > /sys/class/fc_host/host1/issue_lip

フェイルオーバーの監視コマンド

# パス状態のリアルタイム監視
watch -n 1 'multipath -l | grep -A 5 san_vol01'

# multipathd のイベントログを追尾（systemdジャーナル）
journalctl -u multipathd -f

# I/Oを流しながら障害を発生させる場合の想定例
dd if=/dev/zero of=/mnt/san01/testfile bs=1M count=1024 conv=fsync &
PID=$!
# ここでパス障害を発生させる
wait $PID && echo "I/O completed without error"

フェイルオーバー完了後、multipath -l の出力でアクティブパスが切り替わっており、I/Oエラーが発生していないことを確認します。

フェイルオーバー所要時間の目安（想定例）：polling_interval を5秒に設定した場合、パス障害検知から切り替え完了まで5～30秒程度が一般的です。ストレージ・ドライバ・パスチェッカーの組み合わせにより変動するため、SLA要件がある場合は実測値で確認し、polling_interval や no_path_retry を調整します。

切り戻し手順と注意点

フェイルオーバー計測で問題が発見された場合や移行中断が必要な場合の切り戻し手順を事前に準備しておきます。

# マウント先を元のパスに戻す
umount /mnt/san01
# /etc/fstab を /dev/sdX 表記に戻す（エディタで編集後）
mount /dev/sdX /mnt/san01

# マルチパスデバイスを削除
multipath -f san_vol01

multipath -f はI/O中に実行するとデータ損失の恐れがあります。必ずアンマウント後に実行します。

よくあるつまずきとして、multipath -f が device is busy で失敗するケースがあります。デバイスがまだ参照されている状態です。fuser -v /dev/mapper/san_vol01 や lsof | grep san_vol01 で参照プロセスを特定してから再試行します。dmsetup remove は最終手段として位置づけ、参照プロセスの確認を先に行うことが重要です。

また、alias を設定していない場合、再起動後に mpathN の番号が変わることがあります。/etc/fstab では常にWWIDベースの alias 名か、/dev/disk/by-id/ の永続パスを使うことを推奨します。

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

RHEL 9 / Rocky Linux 9 / AlmaLinux 9

RHEL 9系では multipath.conf の defaults セクションに enable_foreign ディレクティブが追加されており、NVMe/FCデバイスを multipathd で管理するかどうかを明示的に制御できます。デフォルト値はバージョン間で変更になることがあるため、メジャーアップグレード後は設定内容を必ず再確認してください。また、RHEL 9.4以降では multipathd のデフォルトパスチェッカーが一部のストレージで変更されている場合があります。リリースノートの確認を推奨します。

Ubuntu 22.04 / 24.04

Ubuntu では multipath-tools と multipath-tools-boot を別途インストールする必要があります。initramfsにマルチパスを組み込む場合は multipath-tools-boot のインストールと update-initramfs -u の実行が必要です。Ubuntu 24.04では、/etc/multipath.conf が存在しない状態で multipathd を起動すると、内蔵NVMeやSATAデバイスまでマルチパス対象とみなされてしまうケースが報告されています。ブラックリストで内蔵デバイスを除外する設定は必ず入れてください。

systemdソケットとの統合

現行環境では multipathd は multipathd.socket ユニットとの連携が前提となっており、multipathd.service だけを管理していると制御コマンドが正常に動作しない場合があります。multipathd show や multipathd reconfigure が応答しない場合は、ソケットの状態も確認します。

systemctl status multipathd.socket
systemctl status multipathd.service

NVMe over Fabricとの共存

NVMe over Fabric（NVMe-oF）環境では、nvme-cli のネイティブマルチパス（nvme list-subsys）と multipathd が競合するケースがあります。NVMe/FCデバイスを multipathd で管理する場合は enable_foreign "nvme" の設定が必要であり、逆にネイティブマルチパスに任せる場合は blacklist での除外が必要です。どちらで管理するかを環境ごとに方針を統一しておくことが、トラブルシューティングの複雑化を防ぐ上で重要です。

また、dm-multipath カーネルモジュールが自動ロードされない環境では、以下の設定で永続化します。

echo "dm-multipath" > /etc/modules-load.d/dm-multipath.conf
modprobe dm-multipath