iSCSIかFibre Channelか — あなたのインフラに適した選択は？
かつてNetAppのストレージシステムを持つ会社で働いていたとき、LinuxサーバーをSANに接続する際に最初に出てくる疑問は常に：iSCSIかFibre Channel（FC）か？でした。これは「どちらが優れているか」ではなく「現在のインフラに適しているのはどちらか」という問いです。
FCはレイテンシが1ms以下でスループットも非常に安定していますが、専用のHBAカード（約$300〜500/枚）や専用FCスイッチが必要で、初期コストは数万ドルに達することも。iSCSIは既存のEthernet/IP環境で動作し、特別なハードウェアは不要です。10GbEなら中規模企業のワークロードには十分なスループットが得られます。SMBやdev/test環境では、現実的な選択肢はかなり明確です。
iscsiadm対Cockpit対iSNS：何を使うべきか？
CentOS/RHELでiSCSI initiatorを管理する方法はいくつかあります。実際に三つとも試した結果をご紹介します：
- iscsiadm（CLI）：公式ツールで全機能対応、スクリプト化も可能 — 本番環境で使えるのはこれ。構文はやや冗長ですが、慣れれば問題ありません。
- Cockpit + iSCSIモジュール：ブラウザGUI、CLI不慣れな管理者に便利 — ただしコントロールが少なく、エラー時のデバッグが難しい。
- iSNS（Internet Storage Name Service）：iSCSIのDNSのようなもの、大規模ストレージ環境での自動検出 — 別途iSNSサーバーのインストールが必要で、数十LUN程度なら過剰です。
sendtargets対静的ノード対iSNS
あまり解説されていませんが、セットアップ時に重要な部分です：
- sendtargets：iSCSIポータルに直接クエリし、サーバーがターゲットのリストを返す — シンプルで、ポータルのアドレスが分かれば使えます。筆者が90%の場面で使う方法。
- 静的ノード（Static node）：ディスカバリーなしでターゲットのIQNを直接設定 — ターゲットが確定していてより細かく制御したい場合に使用。
- iSNS：大規模エンタープライズ環境での自動検出 — 専用iSNSサーバーが必要で、ターゲットが数百台ある場合に適切。
実際のところ、90%のケースではsendtargets + iscsiadmだけで十分です — 補助サーバーへの依存なし、スクリプト化も容易で、デバッグもはるかにシンプルです。
実践的な導入：インストールからディスクマウントまで
ステップ1：iSCSI Initiatorのインストール
CentOS Stream 9はiscsi-initiator-utilsパッケージを使用します：
sudo dnf install -y iscsi-initiator-utils
sudo systemctl enable --now iscsidinitiatorのIQN（iSCSI Qualified Name）を確認します — ストレージシステム上のサーバーの「識別アドレス」です：
cat /etc/iscsi/initiatorname.iscsi
# 出力例：InitiatorName=iqn.1994-05.com.redhat:xxxxxxxxIQNはマシンごとに一意です。IQNを変更せずにVMをクローンすると、アクティブなセッションと競合が発生します — サーバーをマイグレーションした際に実際に遭遇したエラーです。
ステップ2：CHAP認証の設定
「内部ストレージネットワークに認証は不要」という理由でこのステップは省略されがちです。しかし、iSCSIにはデフォルトの暗号化がなく、トラフィックは平文で送信されます。CHAPは少なくとも認証を提供し、ターゲットをネットワークセグメント全体に公開しないようにします：
sudo vi /etc/iscsi/iscsid.conf以下の行を見つけて修正します：
# CHAPを有効にする
node.session.auth.authmethod = CHAP
# 認証情報（ストレージ管理者に確認すること）
node.session.auth.username = your_username
node.session.auth.password = your_password
# Mutual CHAPが必要な場合（ターゲットがinitiatorを逆方向に認証する）
node.session.auth.username_in = target_username
node.session.auth.password_in = target_passwordステップ3：Discovery — iSCSIターゲットの検出
sendtargetsを使って検出します（192.168.1.100はiSCSIポータルのIPに置き換えてください）：
sudo iscsiadm -m discovery -t sendtargets -p 192.168.1.100:3260出力には利用可能なターゲットが一覧表示されます：
192.168.1.100:3260,1 iqn.2024-01.com.company:storage.lun01
192.168.1.100:3260,1 iqn.2024-01.com.company:storage.lun02ステップ4：ターゲットへのログイン
検出したすべてのターゲットにログインします：
sudo iscsiadm -m node --loginall=automaticまたは特定のターゲットにログインします：
sudo iscsiadm -m node \
--targetname "iqn.2024-01.com.company:storage.lun01" \
--portal "192.168.1.100:3260" \
--loginアクティブなセッションを確認します：
sudo iscsiadm -m session -P 1ステップ5：ディスクの認識を確認
ログインが成功すると、カーネルはLUNを通常のSCSIデバイスとして認識します — 再起動は不要です：
lsblk
# または
sudo fdisk -l | grep "Disk /dev/sd"/dev/sdb、/dev/sdc…などが新たに表示されていれば — それがiSCSI LUNです。
ステップ6：フォーマットとマウント
# XFSでフォーマット（ストレージワークロードに推奨）
sudo mkfs.xfs /dev/sdb
# マウントポイントを作成
sudo mkdir -p /mnt/iscsi-data
# テストマウント
sudo mount /dev/sdb /mnt/iscsi-data
# 確認
df -hT /mnt/iscsi-dataステップ7：起動時の自動マウント — このステップを見落とさないでください
iSCSIマウントが通常のディスクと異なる重要な点：マウント前にネットワークが準備されている必要があります。/etc/fstabに_netdevオプションがないと、マウントタイムアウト待ちでサーバーがブート画面で止まる可能性があります — このミスだけで起動のたびに90秒余計にかかるのを実際に見たことがあります：
sudo blkid /dev/sdb # UUIDを取得sudo vi /etc/fstab
# 以下の行を追加（実際のUUIDに置き換えること）：
UUID=xxxx-xxxx-xxxx /mnt/iscsi-data xfs defaults,_netdev,nofail 0 0nofailオプションにより、ストレージターゲットが利用できない場合でもサーバーのブートが止まりません。関連サービスを有効化します：
sudo systemctl enable iscsi iscsid
sudo systemctl enable remote-fs.target実践的なヒント — 緊急マイグレーション作業から学んだこと
CentOS 8のEOL時、1週間でRocky Linuxへ5台のサーバーを緊急マイグレーションしなければなりませんでした — ストレージのダウンタイムが本番データベースに直接影響するため、iSCSIが最もストレスのある部分でした。その作業から学んだことをまとめます：
- マイグレーション前にIQNを記録する：旧マシンと新マシンのIQNは異なります。ストレージ管理者がIQNでACLを設定している場合は更新を依頼する必要があります — そうしないとログインしてもLUNが見えず、デバッグに半日費やすことになります。
- 可能であればマルチパスを使用する：
device-mapper-multipathパッケージにより、同じLUNへの複数パスが可能になります — 1本のネットワーク経路が切断されても自動フェイルオーバー。本番データベースでは「あると便利」ではなく、ほぼ必須です。 - MTUの整合性を確認する：Jumbo Frames（MTU 9000）はiSCSIのスループットを大幅に改善しますが、NIC → スイッチ → ストレージアレイまでのパス全体で統一する必要があります。MTUの不一致はパケットフラグメンテーションを引き起こし、スループットが30〜40%低下しますがログには異常が表示されません — このタイプのバグは見つけるのに数時間かかります。
- ストレージトラフィック用に専用ネットワークを使用する：管理トラフィックとNICを共用しないこと。少なくとも専用VLANを使用する — バックアップジョブが実行中にデータベースのストレージを詰まらせる事態を防ぎます。
よくあるエラーのトラブルシューティング
ログイン失敗 — 認証エラー
# ノードにCHAPを直接更新
sudo iscsiadm -m node \
--targetname "iqn.2024-01.com.company:storage.lun01" \
--portal "192.168.1.100:3260" \
-o update \
-n node.session.auth.authmethod -v CHAP
sudo iscsiadm -m node \
--targetname "iqn.2024-01.com.company:storage.lun01" \
--portal "192.168.1.100:3260" \
-o update \
-n node.session.auth.username -v your_user \
-n node.session.auth.password -v your_passリブート後にターゲットが再接続されない
# ノードのスタートアップモードをautomaticに設定
sudo iscsiadm -m node -o update -n node.startup -v automatic
# サービスが実行中か確認
sudo systemctl status iscsid iscsiメンテナンス時の安全なログアウト
# 先にアンマウント — 重要、このステップをスキップしないこと
sudo umount /mnt/iscsi-data
sudo sync
# その後にログアウト
sudo iscsiadm -m node --logoutall=allCentOS Stream 9上のiSCSIは本番環境対応で、データベースストレージとして十分な安定性を持っています — 実際に数十LUNの環境で運用していますが問題は発生していません。セットアップが失敗する原因はツールの複雑さではなく、よく見落とされる三つのポイントです：CHAP認証、HAのためのマルチパス、そしてfstabの_netdev。この三つを正しく設定すれば、残りはかなりスムーズに進みます。
