iSCSIからNVMe-oFへの段階移行｜レイテンシ計測・マルチパス設計・フェイルバック検証

iSCSIからNVMe-oFへの移行が現実解になった背景

ネットワーク越しにブロックストレージを提供するプロトコルとして、iSCSIは長年にわたって現場を支えてきました。TCPスタックの上に実装されるため特別なハードウェアを必要とせず、Linuxカーネルのiscsidとオープンソースのターゲット実装だけで完結するシンプルさが、幅広い環境で採用されてきた理由です。

ところが全フラッシュアレイ（AFA）やNVMe SSDが標準化された現在、iSCSIのレイテンシ特性がボトルネックになる局面が増えています。iSCSIはNVMeコマンドをSCSIコマンドセットに変換してTCPでカプセル化するため、プロトコル変換のオーバーヘッドとTCPの輻輳制御が組み合わさり、マイクロ秒単位の応答が求められるデータベースやVDIのワークロードでは無視できない遅延が発生します。

NVMe-oF（NVMe over Fabrics）はこの問題を根本から解決するアプローチです。NVMeコマンドをそのままファブリックに載せるため変換コストがなく、2026年時点ではLinuxカーネル標準モジュール（nvme-fabrics・nvmet）とNVMe/TCPトランスポートの組み合わせが、専用ハードウェアなしに利用できる最有力の構成として実運用に乗っています。

トランスポート選択と2026年のディストリビューション対応状況

NVMe-oFのトランスポートは大きく三種類あります。RDMA（InfiniBandやRoCEv2）、Fibre Channel、そしてTCPです。このうちNVMe/TCPはカーネル5.0以降で利用可能になり、RHEL 9系・Ubuntu 24.04 LTS・Debian 12以降では追加パッチなしに動作します。RoCEv2は最も低いレイテンシを実現しますが、RDMA対応NICと適切なスイッチ設定が前提となります。

既存のiSCSI環境が10GbEや25GbEの汎用NICで構成されている場合、NVMe/TCPへの移行は段階的かつリスクの低い選択肢です。同一のネットワーク機器を流用しながらプロトコルだけを切り替えられるため、インフラ投資を最小化しつつ改善効果を定量的に検証できます。

ターゲット側はカーネルモジュールnvmetとnvmet-tcpを組み合わせたソフトウェアターゲット、またはNVMeデバイスを直接エクスポートできるストレージアプライアンスのどちらも使用できます。SPDK（Storage Performance Development Kit）ベースのユーザー空間実装も選択肢にありますが、まずはカーネル標準の構成で動作を確認してから検討するのが現実的な順序です。

移行判断のためのレイテンシ計測手順

段階移行を判断・説明可能にするには、移行前後の数値を同一条件で取得しておくことが不可欠です。現場でよく使われる方法は、fioによるランダム4KB読み取りのレイテンシパーセンタイル計測です。まずiSCSIデバイス（例：/dev/sdb）でベースラインを取得します。

fio --name=latency-baseline \
    --filename=/dev/sdb \
    --rw=randread \
    --bs=4k \
    --iodepth=1 \
    --numjobs=1 \
    --time_based \
    --runtime=60 \
    --lat_percentiles=1 \
    --output-format=json \
    --output=iscsi_baseline.json

NVMe-oF接続後は同じパラメータで/dev/nvme0n1を対象にして比較します。注目すべき指標は平均レイテンシよりも99パーセンタイル（p99）と99.9パーセンタイル（p99.9）です。テールレイテンシがワークロードの体感品質に直結するためです。

手軽なスポット確認にはiopingも有効です。

# iSCSI
ioping -c 100 /dev/sdb

# NVMe-oF
ioping -c 100 /dev/nvme0n1

同一の25GbE NIC・同一サーバー構成でiSCSIとNVMe/TCPを比較した場合、p99レイテンシが30〜50%程度改善されるケースが報告されています。ただし結果はワークロードパターンとネットワーク構成に大きく依存するため、自環境での実測を移行判断の根拠としてください。

ANA対応マルチパス設計：Native Multipathとdm-multipathの使い分け

iSCSI環境ではdm-multipathによるマルチパスが一般的です。NVMe-oFに移行する際、このマルチパスの設計方針を再検討する必要があります。

NVMe-oFにはANA（Asymmetric Namespace Access）という仕組みがあります。ANAは各パスにOptimized・Non-Optimized・Inaccessibleといった状態を付与し、コントローラーが最適なパスをクライアントに通知します。Linuxカーネルはこの情報を使って自動フェイルオーバーを処理するため、dm-multipathなしのNative NVMe Multipathが推奨される構成となっています。

Native NVMe Multipathを有効にするにはカーネルパラメータを設定します。

# /etc/modprobe.d/nvme.conf
options nvme_core multipath=Y

設定後、nvme list-subsysで各パスの状態とANAステートを確認できます。

nvme list-subsys
# 出力例:
# +- nvme0 tcp traddr=192.168.100.1,trsvcid=8009 live optimized
# +- nvme1 tcp traddr=192.168.100.2,trsvcid=8009 live optimized

既存のdm-multipathと共存させる場合はmultipath=Nのままにして、/etc/multipath.confのblacklistセクションでNVMeデバイスを除外する設定が必要です。NVMeデバイスをdm-multipathで管理することも技術的には可能ですが、ANAの優位性を活かせないため、新規構築では避けることが推奨されています。

段階移行の実施フェーズと接続確立手順

本番環境でiSCSIからNVMe-oFへ移行する場合、一括切り替えはリスクが高いため、以下のような段階的アプローチが現場では取られます。

• フェーズ1：ターゲット並行構成　NVMe-oFターゲット（nvmetまたはストレージアプライアンス）を既存iSCSIターゲットと並行して稼働させます。同一ボリュームを両プロトコルで同時にエクスポートせず、検証用の別ボリュームを用意して動作確認を行います。
• フェーズ2：非本番ホストでの接続テスト　非本番ホストにNVMe/TCPクライアントを設定し、nvme discoverとnvme connectで接続を確立します。レイテンシ計測・マルチパス動作・ANA切り替えをこの段階で徹底的に検証します。
• フェーズ3：本番ホストへの並行追加　本番ホストにNVMe-oF接続を追加しつつ、iSCSIセッションを維持します。新規ワークロードをNVMe-oF側に誘導し、既存ワークロードは引き続きiSCSIで運用します。
• フェーズ4：フルカットオーバー　すべてのワークロードがNVMe-oFに移行したことを確認後、iSCSIセッションを切断します。ターゲット側のiSCSI設定は一定期間保持し、切り戻し手段を確保します。

フェーズ2でのクライアント接続コマンドは以下のとおりです。

# ターゲットのディスカバリ
nvme discover -t tcp -a <ターゲットIP> -s 8009

# 接続
nvme connect -t tcp -a <ターゲットIP> -s 8009 -n 

/etc/nvme/discovery.confに接続設定を書き込んでおくと、nvme connect-allで一括再接続が可能になります。再起動後の自動接続にはnvmf-autoconnect.service（nvme-cliパッケージに含まれる）を有効化します。

フェイルバック検証と切り戻し計画

移行後に最も重要な検証がフェイルバックです。NVMe-oFのANA対応ターゲットでは、コントローラーの系切り替え時にパスのANA状態が変化します。この動作を事前に確認しておかないと、本番障害時に予期せぬI/Oエラーが発生するリスクがあります。

フェイルバック検証の手順は次のとおりです。まず2本のパスがoptimized状態で接続されていることをnvme list-subsysで確認します。次に片方のターゲットパス（NIC障害やスイッチポートダウンを模擬）を切断し、カーネルがANA状態をinaccessibleに更新して残存パスへI/Oが自動的に切り替わることを確認します。

# フェイルオーバー後のANA状態確認
nvme list-subsys

# カーネルログでパス切り替えイベントを確認
dmesg | grep -E "nvme|ana" | tail -20

パスが回復した際にoptimized状態に戻ることも合わせて確認してください。ANA対応ターゲットによっては、フェイルバック後にNon-Optimizedのまま据え置かれる設定になっている場合があります。ターゲット側のANA優先度設定を把握しておくことが重要です。

切り戻し計画においては、iSCSIセッションを即座に復元できる状態を本番移行後も一定期間維持することが推奨されます。具体的には、iSCSIイニシエータの設定（/etc/iscsi/配下）とターゲット側のポータル設定を削除せずに保存しておき、問題発生時はiscsiadm -m node --loginall=allでセッションを復活させます。NVMe-oFとiSCSIを同一ホストで並行稼働させる期間を設けることで、移行の不確実性を大幅に低減できます。

NVMe-oFへの完全移行後も、nvme list-subsysによる定期的なパス状態の監視と、PrometheusのNode Exporterや専用のNVMeエクスポーターを組み合わせた監視体制の整備が安定運用の前提となります。2026年現在、主要なストレージアプライアンスベンダーはNVMe-oFのテレメトリエンドポイントを標準で提供しており、既存の監視インフラへの統合も以前より容易になっています。段階移行を通じて得られたレイテンシのベースライン数値は、その後の監視アラート閾値の設定にも直接活用できます。