iSCSIでLinuxサーバのストレージを後付け拡張する構成と障害時切り戻し設計

なぜiSCSIがストレージ後付け拡張の選択肢になるのか

物理ディスクの増設が難しいベアメタルサーバや、既存のSANインフラを活かしたいケースで、iSCSI（Internet Small Computer Systems Interface）は依然として有力な選択肢です。NFS/SMBのようなファイルシステム共有とは異なり、iSCSIはブロックデバイスをネットワーク越しに提供するため、OSからはローカルディスクと同等に見えます。LVMの論理ボリュームをiSCSI経由でマウントすれば、後からオンラインでサイズを変更することも可能です。

現場での典型的な利用シナリオは、「NASアプライアンスやLinuxストレージサーバをiSCSIターゲットとして構築し、各Linuxサーバ（イニシエータ）から接続してデータ領域を分離する」というものです。運用を継続しながらストレージを追加できる点が魅力である一方、ネットワーク障害時の影響範囲が大きくなるため、切り戻しを前提とした設計が欠かせません。

構成の全体像とネットワーク要件

iSCSIの構成は「ターゲット（ストレージを提供する側）」と「イニシエータ（ストレージを利用する側）」の2ロールに分かれます。Linuxでは、ターゲット側にtargetcli（LIO: Linux I/O Target）、イニシエータ側にopen-iscsiを使うのが2026年時点の標準構成です。かつて使われていたtgt（tgt-admin）やiscsitargetは多くのディストリビューションでメンテナンス終了扱いとなっており、新規構築では避けるべきです。

ネットワーク要件として最低限押さえておくべき点を以下に示します。

• 専用セグメントの確保：iSCSIトラフィックは帯域を大きく消費するため、業務NICとは分離したVLANまたは専用NICを使うことが推奨されます。
• ジャンボフレームの検討：MTU 9000設定はスループット改善に有効ですが、経路上のスイッチ・NIC全体で統一しなければ断片化の原因になります。部分的な設定変更は逆効果です。
• ファイアウォール設定：ターゲット側のTCP 3260番ポートを、イニシエータのIPアドレスからのみ許可します。外部に開放するポートではありません。

ターゲット側の構築手順（LIO / targetcli）

ターゲットサーバ（ここではUbuntu 24.04 LTSを例とします）でのセットアップ手順を示します。まずパッケージをインストールし、サービスを有効化します。

sudo apt install targetcli-fb
sudo systemctl enable --now rtslib-fb-targetctl

次にtargetcliの対話シェルに入り、バックストアとしてLVMの論理ボリュームを登録します。ここでは/dev/vg_iscsi/lv_dataを使う例を示します。

sudo targetcli
/backstores/block> create name=lun0 dev=/dev/vg_iscsi/lv_data
/iscsi> create iqn.2026-01.com.example:storage01
/iscsi/iqn.2026-01.com.example:storage01/tpg1/luns> create /backstores/block/lun0
/iscsi/iqn.2026-01.com.example:storage01/tpg1/acls> create iqn.2026-01.com.example:initiator01
/> saveconfig
/> exit

IQN（iSCSI Qualified Name）の命名規則はiqn.YYYY-MM.逆順ドメイン:識別子です。ACLにイニシエータのIQNを登録することで、接続を特定のサーバに限定できます。CHAP認証を追加する場合はtpg1/acls/iqn.xxx配下でユーザ名・パスワードを設定しますが、なりすましリスクを考慮すると双方向CHAP（mutual CHAP）の設定が推奨されます。

イニシエータ側の接続手順と再起動後の自動ログイン

接続先となるLinuxサーバ（イニシエータ）ではopen-iscsiを導入します。

sudo apt install open-iscsi
sudo systemctl enable --now iscsid

イニシエータのIQNは/etc/iscsi/initiatorname.iscsiに記載されています。ターゲット側のACLと一致させる必要があるため、事前に確認します。

cat /etc/iscsi/initiatorname.iscsi
# InitiatorName=iqn.2026-01.com.example:initiator01

ターゲットを検出し、ログインします。

sudo iscsiadm -m discovery -t sendtargets -p 192.168.10.10
sudo iscsiadm -m node -T iqn.2026-01.com.example:storage01 -p 192.168.10.10 --login

接続後、lsblkで新しいブロックデバイス（/dev/sdbなど）が現れることを確認します。このデバイスに対してパーティション作成・フォーマット・マウントを行うか、LVMのPVとして追加することで、ローカルディスクと同等に扱えます。

再起動後の自動接続には、ノード設定でnode.startup = automaticを指定します。

sudo iscsiadm -m node -T iqn.2026-01.com.example:storage01 -p 192.168.10.10 --op update -n node.startup -v automatic

systemdのopen-iscsi.serviceがiscsid.serviceを依存管理するため、サービスの起動順序は自動で解決されます。ただしiSCSIデバイス上にマウントポイントを設ける場合は、/etc/fstabに_netdevオプションを必ず付与してください。これを省くと再起動時にfsckが誤動作するケースがあります。

障害時の切り戻し設計と実操作手順

iSCSIはネットワーク経由のストレージであるため、ネットワーク障害・ターゲットサーバの停止・スイッチ再起動などで接続が断たれるリスクがあります。切り戻しを前提とした設計では、次の3点が核心になります。

• マルチパス（DM-Multipath）の活用：multipath-toolsをイニシエータ側に導入し、複数のNIC・スイッチ経路を束ねることでSPOF（単一障害点）を排除します。Ubuntu系ではmultipath -F && systemctl restart multipathdで設定を反映できます。
• アンマウント手順の明文化：iSCSI切断前にファイルシステムをアンマウントし、デバイスへの参照をなくしてからセッションをログアウトする順序を守らないと、カーネルのブロックレイヤが応答不能になる場合があります。この順序をRunbookとして明文化し、障害訓練で実際に試しておくことが本番障害時の混乱を防ぐ最大の手立てです。
• ローカルディスクへのフォールバック準備：iSCSI上のデータをローカルディスクにrsync等で定期同期しておき、障害時はマウントポイントを切り替えるだけで業務を継続できる構成にしておくと、切り戻しのRTOを大幅に短縮できます。

切り戻し操作の具体的な流れとしては、まずiSCSI上で動いているサービスを停止し、マウントを解除してからセッションをログアウトします。

sudo systemctl stop myapp.service
sudo umount /mnt/iscsi_data
sudo iscsiadm -m node -T iqn.2026-01.com.example:storage01 -p 192.168.10.10 --logout

その後、ローカルディスクをマウントしてサービスを再起動します。iSCSIターゲット側でLVMスナップショットを定期取得しておくと、データ破損時のポイントインタイムリカバリも可能になります。lvcreate -s -n snap_data -L 10G /dev/vg_iscsi/lv_dataのように手動スナップショットを組み込む、あるいはLVM thin provisioningで差分スナップショットを自動化する方法が広く採用されています。

接続状態の確認にはiscsiadm -m session -P 3を使います。出力にState: logged inが表示されていれば正常です。セッションが消失した際の自動再接続はnode.session.timeo.replacement_timeoutパラメータで制御されており、デフォルト値（120秒）のままでは業務影響が大きい場合は30秒程度に短縮することが検討されます。

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

2026年時点での主要ディストリビューション（Ubuntu 24.04 LTS / RHEL 9系 / Debian 12）におけるiSCSI運用の差分を整理します。

パッケージ名の違いとして、targetcliはFedora/RHEL系、targetcli-fbはDebian/Ubuntu系という区別があります。設定の永続化がtargetcli saveconfigにより/etc/target/saveconfig.jsonへ書き出される点は共通です。RHEL 9系ではtarget.serviceのユニット名でsystemdに統合されており、起動・停止の管理はsystemctlで統一されています。

iSCSIデバイス上にルートファイルシステムを置くdisklessブート構成では、initramfsへの組み込みが引き続き必要です。RHEL系ではdracut、Debian系ではinitramfs-toolsへの追加設定が求められます。この点は自動化されておらず、見落としがちなため注意が必要です。

セキュリティ面では、iSCSIトラフィックをVLAN分離だけに頼らず、IPsecや専用ストレージネットワーク（ゾーニング）と組み合わせる構成が増えています。クラウドハイブリッド環境でiSCSIを使う場合は、暗号化トンネル越しに接続するアーキテクチャが標準になりつつあります。

NVMe-oFCやNFS over RDMAといった新しいプロトコルが注目を集める中でも、iSCSIはEthernetインフラをそのまま活用できる手軽さから、既存環境の後付け拡張手段として実用的な選択肢であり続けています。構成の複雑さよりも運用の確実性を重視する現場では、今後も継続して活用されるでしょう。切り戻し設計をあらかじめ組み込んでおくことが、長期運用における安定性の鍵になります。