iSCSIで同一LUNを2台サーバーに同時接続は危険？IQN重複の落とし穴と安全な共有方法

NASのiSCSI LUNをサーバーAで使っているところへ、同じIQNのままサーバーBからも接続して「今は動いている」――この状況は、後から静かに破綻しやすい典型パターンです。本記事では、同一LUN同時接続がなぜ危険なのか、2台で安全に同じデータを使う方法、切断できない警告の実務的な止めどころまで、運用目線で整理します。

相談でよくある状況（今回の論点）

現場で起きがちな相談は、だいたい次の形にまとまります。

• NAS（iSCSIターゲット）にあるLUNを、サーバーAがiSCSIで接続し、NTFS/ReFSなどでフォーマットして運用している
• サーバーBからも同じLUNへ接続した（しかもIQNを同じにして、ターゲット側から同一イニシエーターのように見せている）
• とりあえず読み書きはできているように見えるが、不安がある
• 切断しようとすると「アクティブなサービスがある」等の警告でログオフできない
• （補足）2台は別ドメインで、片方で作成・更新したファイルがもう片方で見えないことがある

結論：クラスター未構成の2台サーバーから同一iSCSI LUNを同時マウントして使うのは基本NG

クラスターや共有ディスク制御の仕組みがない状態で、2台のOSが同一LUN（同じディスク）を同時にマウントして運用するのは推奨されません。

最大の理由はシンプルで、2台のOSがディスク上の書き込み順序・メタデータ更新・ロックを調停できないためです。結果として、ファイルが見えない・更新が巻き戻る・突然消える・最終的にファイルシステム破損（NTFSのメタデータ破損や整合性崩壊）に繋がるリスクが非常に高くなります。

そして怖いのは「今は動く」ことです。壊れ方は、すぐではなく数時間〜数日〜数週間後に遅れて出ることがあり、障害の切り分けが難しくなりがちです。

iSCSIはファイル共有ではなく「ブロックデバイス直結」

まず前提として、iSCSIはネットワーク越しにディスク（ブロックデバイス）を提供します。つまり、OSから見ると「ローカルディスクが1本増えた」のと同じ扱いです。

この性質が、SMB共有（ファイル共有）と決定的に違います。

観点	SMB共有（NASの共有フォルダー）	iSCSI（LUN/ブロック）
共有の単位	ファイル/フォルダー	ディスク（ブロック）
同時アクセスの調停	サーバー（NAS）がロック/整合性を制御	基本はOSが単独利用を前提（調停なし）
2台から同時に使う	通常運用として想定（マルチクライアント）	クラスター等の前提がないと危険
典型用途	部署共有、アプリのデータ置き場、ファイルサーバー	DB、仮想化ストレージ、単体サーバーのデータディスク
「更新が見えない」	基本起きにくい（NASが整合性/キャッシュを統制）	起き得る（キャッシュ/メタデータが分離し矛盾）

要するに、「2台で同じファイルを共有したい」ならSMBが本職です。iSCSIは「1台が安全に使う」か、「クラスターなどの調停がある前提で共有する」かのどちらかになります。

なぜファイルシステムが壊れるのか（実務で起きる“壊れ方”）

OSがディスクを扱うとき、読み書きは常に「即ディスク」ではありません。性能のために、書き込みをまとめたり順序を最適化したり、メタデータ更新をキャッシュしたりします。

1台構成なら、OSが「自分が唯一の管理者」という前提で順序と整合性を保てます。しかし2台が同じディスクを同時に管理すると、以下のような競合が発生します。

• キャッシュの不整合：Aが更新してもBは古い状態をキャッシュし続け、見えない/古い内容が見える
• メタデータ競合：ディレクトリエントリ、割り当てビットマップ、MFTなどの更新が衝突し、整合性が崩れる
• ロックが効かない：SMBのような「サーバー側でのファイルロック制御」がないため、二重更新が素通りする
• 障害時の復旧が難しい：破損が遅れて顕在化し、「何が原因だったか」追いにくい

特にWindowsのNTFS/ReFSは、同一ボリュームを非クラスターで2台から同時マウントすることを前提としていません。クラスター環境ではSCSI-3 Persistent Reservation（PR）等を使い「誰が所有者か」「どのノードが書いてよいか」を制御しますが、通常構成ではその調停がありません。

「今のところ動いている」のはなぜ？（安心材料ではなく危険なサイン）

同一LUNを2台で触っても、一定条件では“たまたま”破綻が表面化しないことがあります。

• 実際には片方がほぼ読み取りで、書き込みが偏っている
• 更新頻度が低い（メタデータ更新が少なく衝突しにくい）
• タイミングよくキャッシュがフラッシュされ、矛盾が露呈しづらい
• 障害が「壊れたように見える」前に、片方を再起動してキャッシュが消えている

しかし、こうした状態は運が良いだけで、運用が続けば続くほど破綻確率は上がります。今回の補足にある「片方で作成・更新したファイルがもう片方で見えない」は、まさに整合性が取れていない兆候であり、“既に危険域”と捉えるべきです。

安全に「2台で同じデータを使う」ための選択肢

目的が「2台のサーバーから同じデータを参照・更新したい」なのか、「片方は待機系で切替時に同じディスクを使いたい」なのかで最適解が変わります。代表的な選択肢を整理します。

やりたいこと	推奨構成	同時アクセス	メリット	注意点
2台から同じファイルを共有したい	NASでSMB共有	可	ファイル共有として自然・安全、運用が簡単	権限設計（ACL/資格情報）をきちんと
可用性も欲しい（ファイルサーバーHA）	Windows Failover Cluster（ファイルサーバー役）＋共有ストレージ	構成による	切替が自動化しやすい	要件が増える（検証・設計・運用）
仮想化基盤で共有ストレージを使いたい	Failover Cluster＋CSV（Hyper-V等）	可（CSV前提）	共有ディスクを複数ノードで安全に扱える	ストレージ側の要件（PR対応等）確認必須
iSCSIを使いたいが2台で取り合いたくない	サーバーごとに別LUN	不可（共有しない）	ローカルディスク同等で安全	データ共有は別手段（SMB/レプリケーション）
同じ内容を2台で持ちたい（同期したい）	ファイル同期（用途限定）/アプリのレプリケーション	用途次第	共有ディスク不要	DB/仮想ディスク等は同期方式に注意

最も現実的で安全：NAS側でSMB共有を作り、各サーバーはネットワーク共有として使う

「2台で同じデータを触りたい」相談の多くは、実はブロック共有ではなくファイル共有が正解です。

• NASで共有フォルダー（SMB）を作る
• サーバーA/Bは \\NAS名\共有名 をマウントして利用する
• アクセス権はNAS側の共有権限＋NTFS/ACL（NASの機能）で設計する

別ドメインでも、次のような落としどころがあります。

• NASにローカルユーザー（またはNASのディレクトリサービス機能）を作り、サーバーA/Bから資格情報で接続する
• サーバー側の「資格情報マネージャー」にNAS用のユーザー/パスワードを保存し、安定して接続できるようにする
• 可能ならドメイン信頼や統合認証（NASのAD参加など）を検討する

どうしても同一ストレージを2台で扱う必要がある：クラスター前提の仕組みを入れる

「同一LUNを複数ノードで触ってよい」世界には、必ず前提条件があります。代表例がWindows Failover ClusterとCSV（Cluster Shared Volumes）です。

ただし、ここは要件が一気に増えます。ストレージ側がSCSI-3 PR等を適切に扱えるか、マルチパス（MPIO）設計、ネットワーク冗長、障害時の切替設計、運用監視などを含めた“システム”になります。単に「2台で同じLUNを見たい」だけで導入すると、かえって不安定になります。

iSCSIは使うが共有はしない：サーバーごとに別LUNに分ける

iSCSIを使う目的が「NASの容量をブロックとして使いたい（ローカルディスク拡張に近い）」であれば、設計は単純です。

• サーバーA用LUN、サーバーB用LUNを分ける（同一LUNを共有しない）
• 各LUNに対してアクセス制御（IQN許可、CHAPなど）を適切に設定する
• データ共有が必要なら、別途SMB共有やアプリ側の仕組みで実現する

IQNを同一にする運用が抱えるリスク（推奨されない理由）

IQN（iSCSI Qualified Name）は、iSCSIターゲットから見た「接続元（イニシエーター）の識別子」です。これを2台のサーバーで同一にすると、ターゲット側は2台を区別しづらくなり、制御・監査・切り分けが難しくなります。

起きやすい問題	具体的な困りごと	現場での症状例
アクセス制御が曖昧になる	「どのサーバーが許可されているか」を正しく表現しにくい	意図せず別サーバーが接続できてしまう／禁止しづらい
ログや監査が追いづらい	接続元が同一に見えて、追跡が困難	障害時に「AかBか」が分からない
セッション管理が不安定	切断・再接続時の扱いが複雑化	Aを落としたらBの接続も揺れる、など
運用ミス誘発	設定の意図がチームに伝わりにくい	引継ぎ後に事故りやすい

原則は、各サーバーでユニークなIQNを使うことです。その上で、NAS/ターゲット側の許可リストに「サーバーAのIQN」「サーバーBのIQN」をそれぞれ登録します。セキュリティ的にも運用的にも、こちらが正攻法です。

切断できない「アクティブなサービスがある」警告の正体と、止める順番

iSCSIのログオフやディスクのオフラインができないとき、ほぼ確実にそのLUN上のボリュームを何かが掴んでいる（使用中）のが原因です。焦って強制切断すると、書き込み途中のデータやメタデータが中途半端になり、破損を誘発します。

現場で崩れにくい手順は、次の順番です。

手順1：対象が「どのディスク/ボリュームか」を確実に特定する

サーバーにディスクが複数ある場合、見誤ると事故になります。GUIでもPowerShellでもよいので、iSCSIディスクの番号とドライブ文字、ラベルを押さえます。

Get-Disk | Sort-Object Number | Format-Table Number, FriendlyName, BusType, Size, IsOffline
Get-Volume | Format-Table DriveLetter, FileSystemLabel, FileSystem, SizeRemaining, Size

BusTypeがiSCSIになっているディスクや、容量・ラベルで対象を突き止めます。

手順2：そのボリュームを使っているアプリ/サービスを停止する

「アクティブなサービス」は、必ずしもWindowsサービス名そのものとは限りません。常駐監視・バックアップ・索引作成・仮想化など、ディスクを開きっぱなしにするものが典型です。

掴みがちなもの	例	確認のヒント	止め方の方向性
データベース	SQL Server等	DBのデータ/ログがそのドライブにある	DBサービス停止、またはインスタンス停止
仮想化	Hyper-VのVHDX/構成	VMの保存先がそのドライブ	VM停止→必要ならHyper-V関連サービス停止
バックアップ/スナップショット	バックアップエージェント、VSS	ジョブ実行中、保護設定あり	ジョブ停止、エージェント停止
検索/インデックス	Windows Search	索引対象にそのドライブが含まれる	インデックス対象から除外、サービス停止
ウイルス対策	リアルタイムスキャン	ログに大量アクセス、負荷増	一時除外・停止（手順は製品に従う）
ファイル共有	共有フォルダーとして公開	クライアントがファイルを開いている	共有解除、開いているファイルを閉じる

ファイル共有として公開している場合は、Windowsの管理機能で「誰が掴んでいるか」を確認できます。

• 「コンピューターの管理」→「共有フォルダー」→「開いているファイル」
• 「セッション」も確認し、該当クライアントが掴んでいないかを見る

GUI以外では、リソースモニター（resmon）でディスクに紐づくハンドルを追う方法もあります。

• リソース モニター →「CPU」→「関連付けられたハンドル」検索でドライブ文字やパスを検索

手順3：共有解除・アプリ停止後に、ドライブ文字を外す／ボリュームをオフラインにする

アプリが止まっても、OS側のマウント状態が残っていると切断できないことがあります。次のどちらか（または両方）を行います。

• 「ディスクの管理」で対象ディスクをオフラインにする
• ドライブ文字を削除して、アクセス経路を閉じる

PowerShellでオフラインにする例です（番号は環境に合わせて置き換えてください）。

Set-Disk -Number 3 -IsOffline $true

手順4：最後にiSCSIセッションをログオフ（切断）する

ボリュームがオフラインになっていれば、切断時の警告が出にくくなります。PowerShell例（NodeAddressは例です）。

Get-IscsiSession
Disconnect-IscsiTarget -NodeAddress "iqn.2000-01.com.example:target1" -Confirm:$false

GUIの場合は「iSCSI イニシエーター」から対象ターゲットを選び、ログオフ/切断を行います。

それでも切断できないときに疑うべき“盲点”

• ページファイル（仮想メモリ）がそのドライブにある：ページファイルがあるとボリュームを手放せません
• アプリのサービスは止めたが、関連プロセスが残っている：監視プロセスやエージェントが再オープンすることがあります
• バックアップ/スナップショットが走っている：VSSを含む処理は掴みがちです
• ウイルス対策のリアルタイムスキャン：停止方法が製品依存のため、手順を確認

別ドメインで「変更が見えない」現象は、iSCSIの問題というより“同時マウントの副作用”

「別ドメインだから見えないのでは？」と考えたくなりますが、iSCSIの世界ではドメインは本質ではありません。iSCSIはブロックデバイスであり、ファイル共有のようにサーバー側が整合性を配布してくれません。

同一LUNを2台で同時にマウントしている場合、変更が見えない＝キャッシュ/メタデータ整合性が崩れている可能性が高いです。

症状	起きている可能性	やるべき対応
Aで作ったファイルがBで見えない	キャッシュの不整合、ディレクトリ更新の競合	同時マウントを即中止し、片系に統一
同名ファイルの上書きが不安定	ロック不成立、書き込み競合	SMB共有へ移行、またはクラスター導入検討
CHKDSKが必要と言われる/エラーが出る	ファイルシステム破損が進行中	単独マウントで整合性チェック、バックアップ確保
突然フォルダーが空に見える	メタデータ破損/参照不整合	アクセス停止、スナップショット/バックアップから復旧検討

すでに2台で同一LUNを触ってしまった場合の“現実的な”収束方法

ここはスピードが大切です。目的は「今以上に壊さない」ことと「正しい共有方式へ移す」ことです。

収束の基本方針

• 同時アクセスをやめる：まず片方（サーバーBなど）からLUNを切り離す
• 正（一次）を決める：どちらのサーバー側の状態を正とするか決め、以後はその1台だけがLUNをマウントする
• バックアップ/スナップショットを確保する：NASにスナップショット機能があるなら、整合性に注意しつつ保全を検討（可能ならアプリ停止後）
• 整合性チェックは“単独マウントで”：CHKDSK等は必ず単独でマウントした状態で実施する

データ移行の定番（SMB共有へ寄せる）

「2台から同じデータを使う」目的なら、最終形はSMB共有になりやすいです。移行時は、ファイル属性・ACL・タイムスタンプを保ったコピーが重要です。Windows同士ならrobocopyが定番です。

robocopy "X:\Data" "\\NAS\Share\Data" /MIR /COPY:DATSOU /R:2 /W:5 /MT:16 /LOG:C:\temp\robocopy.log

• /MIR はミラーです（消えるファイルも反映される）。運用に合わせて慎重に使ってください。
• ACLをどう持っていくか（NAS側で継承させるか、コピーするか）は設計ポイントです。

どうしてもiSCSIを使い続けるなら押さえるべき設計ポイント

iSCSI自体が悪いわけではありません。問題は“使い方”です。iSCSIを安全に運用する基本をまとめます。

基本ルール

• 1つのLUNは原則1台のサーバーに割り当てる（クラスター等の例外を除く）
• IQNはサーバーごとにユニークにする（同一IQNを複数台で使わない）
• ターゲット側は許可するIQNを明示し、不要な接続を防ぐ
• 可能ならCHAPなどで認証を入れ、誤接続を減らす
• 冗長が必要ならMPIOを含む設計（NIC/スイッチ/パス）を検討する

「2台で使う必要がある」なら、方式を切り替える発想が重要

共有の要件があるのにiSCSIで解決しようとすると、設計の歪みが出ます。次の判断軸で切り替えるのが失敗しにくいです。

要件	寄せるべき方式	理由
複数サーバーから同時に同じファイルを更新したい	SMB共有	ファイルロックと整合性をサーバー側で制御できる
サーバー切替（待機系）が目的で、同時ではない	フェイルオーバークラスター（共有ディスク）	所有権を制御し「同時書き込み」を防げる
仮想化で共有ストレージが必要	CSV/クラスタリング前提	複数ノードのI/O調停が前提になる
単体サーバーの容量拡張	iSCSI（単独割当）	ローカルディスク同等に扱える

再発防止のチェックリスト（運用ルール化がおすすめ）

最後に、事故が起きやすいポイントを“運用ルール”として固定しておくと強いです。

• iSCSIのLUN台帳を作る（LUN名、容量、用途、割当サーバー、IQN、作成日、変更履歴）
• ターゲット側のアクセス制御は「許可リスト方式」にする（必要なIQNだけ許可）
• 同一LUNを別サーバーで検証したい場合は、スナップショット/クローンで別LUNを作って接続する（本番LUNを直に共有しない）
• 「2台で同じデータを使いたい」要件が出たら、まずSMB共有/ファイルサーバー設計で検討する
• 切断手順は「アプリ停止→共有解除→オフライン→ログオフ」の順で手順書化する

同一LUNの同時マウントは、短期的に動いても長期的には破綻しやすいため、早めにSMB共有またはクラスター前提の構成へ切り替えることをおすすめします。特に「変更が見えない」症状が出ている場合は、運用を続けるほど復旧コストが増えやすいので、優先度高めで収束させてください。