iSCSIは、SCSIコマンドをTCP/IPネットワーク上でやり取りし、離れたストレージを「ローカルディスクのように」扱えるようにするプロトコルです。既存のイーサネット基盤を活用できるため、専用インフラを新設せずにストレージ接続を拡張しやすい点が特徴です。
一方で、ネットワーク設計(帯域・遅延・冗長化)や、認証・暗号化を含む運用設計が不十分だと、性能低下や障害切り分けの難しさにつながります。本記事では、iSCSIの基本からメリット、代表的な利用場面、設定・運用の要点までを整理します。
iSCSIは、SCSI(Small Computer System Interface)のコマンドをIPネットワークで転送し、ストレージをブロックデバイスとして接続するための規格です。サーバ(ホスト)側からは、ネットワーク越しのストレージがローカルディスクのように見えるため、OSやアプリケーションは通常のディスクとして扱えます。

iSCSIは、IPネットワークでストレージを扱うニーズを背景に提案され、のちにIETFで標準化されました。現在は、仮想化基盤やバックアップ、拠点間連携など、幅広い場面で利用されています。
SCSIは、ストレージ等を扱うためのコマンドセット(および周辺仕様)の総称です。iSCSIは、そのSCSIコマンドをネットワーク上で運べるようにしたもので、物理的な直結(内蔵/直結ストレージ)に依存せず、IP経由でブロックストレージにアクセスできます。
ここでは、iSCSIが評価される代表的なポイントを、現場目線で整理します。
iSCSIの核は「SCSIをIPで運べる」ことです。ストレージ専用インフラを新設せずに、既存のネットワーク運用の延長でストレージ接続を構成できます(もちろん、性能・安定性を求めるなら専用セグメント化等の設計は重要です)。
サーバとストレージの配置自由度が上がり、拡張・移設・冗長化の選択肢が増えます。仮想化基盤では、共有ストレージとしての活用により、移行や可用性設計(クラスタ等)に組み込みやすい点もメリットです。
イーサネットを前提にできるため、専用HBAや専用スイッチ中心の構成と比べて、導入のハードルが下がるケースがあります。ただし「安く導入できる」ことと「安定して高性能に運用できる」ことは別なので、用途に応じたネットワーク設計が前提になります。
Fibre Channel(FC)は専用インフラで高性能・低遅延を狙いやすい一方、iSCSIはIP運用の延長で設計できるのが強みです。また、NASはファイル共有(SMB/NFS)を中心にした用途に向き、iSCSIはブロックストレージとしてアプリ側に「ディスク」を提供したい用途で選ばれます。
iSCSIは、イニシエータ(アクセスする側)とターゲット(ストレージを提供する側)で構成されます。ここでは代表的な利用例を紹介します。
仮想化基盤の共有ストレージ、バックアップ領域、アプリケーション用ボリュームなどで広く使われます。設計の要点は、帯域確保・遅延の抑制・冗長化(スイッチ/経路/ターゲット)を、用途に合わせて組み立てることです。
部門システムのストレージ集約、サーバ増設時の容量追加、DR(災害対策)向けのレプリケーションなどで利用されます。「ファイル共有」ではなく「ディスクを提供したい」要件(DB、仮想化、特定アプライアンス等)で適合しやすい傾向があります。
iSCSIはネットワーク品質の影響を受けるため、用途(IOPS重視/スループット重視/レイテンシ重視)に応じて設計します。ジャンボフレームの是非、キュー深度、マルチパスのポリシー、帯域制御などは、環境と要件に合わせて検討します。
ここでは、iSCSI運用の「つまずきやすいポイント」を押さえながら、基本項目を整理します。環境(OS、ストレージ機種、スイッチ構成)により手順は異なるため、具体手順は各製品のドキュメントを参照してください。
ターゲット側では、LUN(提供するボリューム)の作成、アクセス許可(IQN制御等)、認証(CHAP等)の設定を行います。イニシエータ側では、ターゲットの検出、セッション確立、マルチパス設定、OS上でのディスク初期化などを行います。
IPアドレス設計(専用セグメントの有無、冗長経路、ルーティングの扱い)を決めたうえで、ターゲットへ接続します。安定運用を狙う場合、ストレージ用のネットワークは業務トラフィックと分離し、スイッチ/経路も含めて設計するのが基本です。
不安定・遅いといった症状は、iSCSIそのものではなく、ネットワーク(輻輳、ドロップ、再送、MTU不一致)、マルチパス設定、ストレージ負荷、ホスト側ドライバなど複合要因で起きがちです。切り分けのために、ログ、セッション状態、遅延、エラーカウンタ、再送、CPU負荷、ストレージ側のレイテンシを併せて確認します。
代表的な対策は、アクセス制御(接続元制限、IQN制御、ネットワーク分離)、認証(CHAP等)、暗号化(環境によりIPsec等)、および監査ログ/監視の整備です。運用要件(性能・機密性・管理性)とのバランスを取りながら設計します。
iSCSIは「IPでブロックストレージを扱える」という実務的な価値から、今後も一定の需要が続くと考えられます。データ量の増加、仮想化・クラウド活用、DR/バックアップの高度化に伴い、ネットワークとストレージを一体で最適化する設計がより重要になります。
一方で、高速化(25/40/100GbEなど)や低遅延を狙う選択肢が増えるほど、ネットワーク設計の差が体感性能に直結します。iSCSIは「導入のしやすさ」と引き換えに、運用設計の良し悪しが結果に出やすい技術だと言えるでしょう。
iSCSIは、SCSIコマンドをTCP/IPネットワークで転送し、ネットワーク越しにブロックストレージを利用できるようにするプロトコルです。既存のイーサネット基盤を活用できる点が強みで、仮想化基盤、バックアップ、容量拡張など幅広い場面で活用されています。
一方で、性能と安定性はネットワーク設計・冗長化・監視運用に強く依存します。用途に応じた設計と運用を前提に、iSCSIのメリットを最大化していきましょう。
一般にSANは「ブロックストレージをネットワーク越しに提供する仕組み」を指します。iSCSIはその実現手段の一つで、IPネットワーク上でSANを構成できます。
NASはSMB/NFSなどでファイル共有を提供します。iSCSIはブロックデバイス(ディスク)を提供するため、OSやアプリは「ローカルディスク」のように扱えます。
イニシエータはストレージへ接続するホスト側、ターゲットはストレージを提供する側です。ターゲットがLUNを公開し、イニシエータがそれを接続して利用します。
一般にTCP 3260が使われます。ファイアウォールやACLを設計する場合は、この通信を前提に許可範囲を最小化してください。
代表的にはCHAPを使い、接続元の正当性を確認します。加えて、ネットワーク分離や接続元制限(IQNやIP制限)を組み合わせるのが現実的です。
必須かどうかは、通信経路の信頼性と扱うデータの機密性によります。専用セグメント内で閉じる運用でも、要件次第ではIPsec等の暗号化を検討します。
ホスト側のマルチパス構成、スイッチ二重化、ストレージ側の冗長構成をセットで考えます。「経路が片系に寄る」「片系断でI/Oが止まる」といった事故を避けるため、設計と検証が重要です。
ネットワークの遅延・再送・ドロップ、MTU不一致、帯域の競合、マルチパス設定、ストレージ側の負荷を順に確認します。iSCSI単体ではなく「ネットワーク+ホスト+ストレージ」で切り分けるのが近道です。
環境によっては効きますが、全経路(ホストNIC〜スイッチ〜ストレージ)でMTUを揃える必要があります。途中で不一致があると、性能低下や不安定化の原因になります。
超低遅延を強く求める用途や、ネットワーク分離・冗長化・監視を十分に設計できない環境では苦労しやすいです。要件次第では、FCや別方式(クラウドストレージ設計を含む)の検討も現実的です。