Windows Server 2022で「2拠点ストレッチ・ファイルサーバークラスター」を組むとき、iSCSIストレージのSCSI-3永続予約（PR）非対応やクォーラム設計で詰まりがちです。本記事では、HPEサーバー2台＋Synology iSCSI 2台の前提で、共有ディスクに頼らずStorage Replicaで安全に構成する考え方と、約50TBを権限ごと移行する実務手順をまとめます。
2拠点ストレッチ・ファイルサーバークラスターで「やりたいこと」を整理する
数ブロック離れた2つのデータセンター間でストレッチ構成を作りたい場合、目的は大きく次の2つに分解できます。
- 拠点障害（停電・回線断・建屋トラブル）でもファイル共有を継続したい
- 平常時は通常のファイルサーバーとして安定運用し、切替はフェールオーバーで素早く行いたい
ここで重要なのが、「ストレッチ＝共有ストレージ（両拠点から同じLUNを見る）」ではない、という点です。ストレッチを実現するアプローチは複数あり、今回のハードウェア条件では“共有ディスク方式”よりも“各拠点専用ディスク＋ブロック複製”の方が現実的です。
今回の前提（HPE Gen 12×2＋Synology rs4021xs+×2）と設計上の制約
前提構成を、運用目線で要点だけまとめます。
- サーバー：HPE Gen 12 サーバー ×2（Windows Server 2022）
- ストレージ：Synology RS4021xs+ ×2（iSCSI LUNを提供）
- 拠点：数ブロック離れた2データセンター（サイトA/サイトB）
- 狙い：2ノードのファイルサーバークラスタを拠点間で運用
| 論点 | 現場で起きやすい課題 | 設計で押さえるポイント |
|---|---|---|
| 共有ディスク（同一LUNを両ノードから） | SCSI-3 PR非対応だとクラスタディスクとして成立しない可能性 | 共有ディスク前提を捨て、各サイト専用ディスク＋複製に切り替える |
| クォーラム | 2ノード＋2拠点は「同票」になりやすく、通信断で判断が割れる | 第三の投票（ファイル共有ウィットネス／クラウドウィットネス）を必須にする |
| 拠点内冗長 | 各拠点1台ずつだと、サイト内でサーバーが落ちた時の逃げ場がない | 要件として割り切るか、将来の増設余地（予備機/増設）を計画に入れる |
| ネットワーク遅延 | 同期複製は遅延の影響を受け、書き込み性能が落ちることがある | 同期/非同期を要件で選び、複製用ネットワークを分離する |
共有ディスク方式が「Synology iSCSI」で引っ掛かりやすい理由
Windowsフェールオーバークラスタの共有ディスク方式は、基本的に複数ノードが同一LUNへアクセスできることを前提としています。このとき、ディスクの所有権や書き込みを調停するために、ストレージ側がSCSI-3 永続予約（Persistent Reservation）を適切に扱える必要があります。
質問の前提では「Synology rs4021xs+ の iSCSI がSCSI-3 PR非対応」という懸念があり、ここが共有ディスク方式のボトルネックになります。つまり、ストレージアダプタをファイバーに変える以前に、方式そのものを見直した方が安全です。
さらに、ストレッチSAN（両拠点で同じストレージを共有する発想）を低コストに作ろうとすると、拠点間でL2延伸・帯域・冗長・障害切り分けが一気に難しくなります。小規模の2拠点で“数年安定稼働”を狙うなら、構成をシンプルに保つことが最重要です。
おすすめの別案：Storage Replica＋フェールオーバークラスタリングでストレッチ構成にする
結論として、今回の条件（サーバー2台、ストレージ2台、拠点2つ）に最もフィットするのは、共有ディスクではなくStorage Replicaを使う構成です。イメージは「各拠点に専用ディスクを置き、ブロックレベルで複製して同じ内容を保つ」です。
構成イメージ（各サイト専用LUN＋ブロック複製）
- サイトA：HPEサーバー1 → Synology1 のiSCSI LUN（サイトAのデータボリューム）
- サイトB：HPEサーバー2 → Synology2 のiSCSI LUN（サイトBのデータボリューム）
- サーバーは自サイトのストレージにだけ接続する（拠点間でiSCSIを跨がせない）
- Storage ReplicaでサイトAボリューム ⇔ サイトBボリュームを複製
- フェールオーバークラスタは、稼働系サイトのボリュームをオンラインにしてファイルサーバー役割（SMB共有）を提供
| 項目 | 共有ディスク方式 | Storage Replica方式（推奨） |
|---|---|---|
| ストレージ要件 | SCSI-3 PR等、クラスタ用要件が厳しい | 各ノード専用ディスクのため共有ディスク要件を回避しやすい |
| 拠点間構成 | ストレージを“跨がせる”設計になりがちで複雑 | 拠点間は複製トラフィック中心で設計しやすい |
| 障害切り分け | ストレージ/ネットワーク要因が絡みやすい | 「サーバー」「複製」「共有」の責務が分かれ、切り分けしやすい |
| コスト | ストレッチSAN相当を作ろうとすると上がりやすい | 既存のiSCSIストレージを活かしやすい |
SCSI-3 PRの懸念をどう回避できるのか
Storage Replica方式の本質は「共有ディスクを複数ノードで奪い合わない」ことです。両ノードが同一LUNに同時書き込みする前提ではないため、共有ディスク方式で問題になりやすいSCSI-3 PRへの依存が下がります。
その結果、「Synology iSCSIがSCSI-3 PR非対応だからファイバー接続アダプタが必要」という発想から一段離れて、方式を変えて要件を満たすことができます。
同期レプリケーションか、非同期レプリケーションか
Storage Replicaを採用する場合、現場で迷うのが「同期」「非同期」です。数ブロック程度でも、回線品質や混雑で体感が変わるため、要件で割り切るのがコツです。
| 観点 | 同期（Sync） | 非同期（Async） |
|---|---|---|
| データ保護 | 原則、RPOを限りなくゼロに近づけやすい | 遅延・帯域次第で遅れが出る（RPOが発生） |
| 書き込み性能 | 拠点間の遅延の影響を受けやすい | 性能への影響が比較的小さい |
| おすすめ条件 | 低遅延・安定帯域・「絶対に失いたくない」データ | 少しの差分許容・回線品質にばらつき・性能優先 |
| 設計の現実解 | 同期にこだわるなら回線設計（帯域/冗長/QoS）もセットで | 「数分〜数十分の巻き戻り」を業務許容できるかが判断軸 |
ファイルサーバー用途の場合、ユーザー体験としては「保存が遅い」「エクスプローラーが固まる」が直撃します。同期にしたい場合ほど、複製用ネットワークを分離し、帯域と遅延を測ってから決めるのが安全です。
ネットワーク設計のコツ（iSCSI／レプリケーション／クライアント）
2拠点クラスターは、ネットワークを雑にすると一気に不安定になります。特にiSCSIとレプリケーションをクライアント通信と混在させると、ピーク時にレプリケーションが詰まってフェールオーバー時の復旧が遅れる、という事故が起きがちです。
| 用途 | 推奨 | ポイント |
|---|---|---|
| クライアントアクセス（SMB） | 通常LAN（冗長化推奨） | SMB Multichannelを活かすならNIC複数＋帯域確保 |
| クラスタ通信（ハートビート） | 論理分離（VLAN等） | 混雑やブロードキャストの影響を受けにくくする |
| iSCSI | 専用VLAN/専用NIC（MPIO推奨） | 拠点間iSCSIは避け、ローカル接続に閉じる |
| Storage Replica（複製） | 専用VLAN/専用NIC（可能なら帯域確保） | 同期なら特に重要。QoSや時間帯制御も検討 |
また、ジャンボフレームやフロー制御などは、全区間（NIC〜スイッチ〜ストレージ）で整合させないと逆効果になることがあります。最初は標準設定で安定稼働を確認し、必要に応じて段階的にチューニングするのが現実的です。
クォーラム設計は「第三の票」を必ず用意する
2ノードクラスターは、拠点間リンク断（ネットワーク分断）時に「お互いが相手を見失う」状態になりやすく、最悪の場合はサービス停止や想定外の挙動につながります。これを避ける基本がウィットネスです。
- ファイル共有ウィットネス：第三拠点（別オフィスや管理用サーバー）に共有フォルダを用意
- クラウドウィットネス：インターネット経由で第三の票を持たせる（社内要件が許す場合）
質問にある「ファイル共有ウィットネスで対応している」は、そのまま有効な考え方です。ポイントは、ウィットネスを“どちらの拠点にも偏らない場所”に置くことです。サイトAに置くと、サイトA障害時に投票が偏る、というような設計事故が起きます。
構築手順（同一DCで組んでから物理移動する場合の現実的な進め方）
「まず同一データセンター内で組んで、その後片系を移動する」という手順は現場ではよくあります。ただし、移動後にネットワーク設計が変わると手戻りが大きいので、最初から“サイトA/サイトBの完成形”を模擬して構築するのがコツです。
事前に決めておくこと（手戻りを防ぐ）
- サイトA/サイトBのサブネット（同一サブネットで組むのか、拠点ごとに別サブネットか）
- クラスタ名、ファイルサーバー用ネットワーク名（クライアントが接続するUNC）
- ウィットネスの設置場所（第三拠点）
- iSCSIのIP設計（各サイトで閉じる）
- レプリケーション用帯域の確保（ピーク時でも複製が止まらないか）
サブネット設計の選び方（同一サブネット vs マルチサブネット）
| 方式 | メリット | 注意点 |
|---|---|---|
| 同一サブネット（L2延伸など） | クライアントから見るIPが変わらず単純 | L2延伸は障害波及が大きく、ネットワーク側の設計難度が上がる |
| マルチサブネット（拠点ごとに別） | ネットワーク設計が自然で拠点分離しやすい | DNS更新・TTL・クライアントの再接続など、切替時の体感に配慮が必要 |
「数ブロック」の近距離でも、ネットワーク運用方針（L2延伸を許容するか）で選択が変わります。迷ったら、ネットワーク運用のしやすさを優先してマルチサブネットを採るケースが多いです。
構築の大きな流れ
- 各サーバーを自サイトのSynology LUNにだけiSCSI接続し、データ用ボリュームを作成する
- Windows Server 2022にフェールオーバークラスタリング／Storage Replica／MPIOなど必要機能を追加する
- クラスタ検証（Validate）を実施し、2ノードクラスターを作成する
- ファイル共有ウィットネスを設定し、クォーラムを安定させる
- Storage Replicaの複製ペア（パートナーシップ）を作り、初回同期を完了させる
- クラスタにファイルサーバー役割（SMB共有）を載せて公開する
- 片系を物理移動する場合は、同期状態を確認→計画停止→移設→疎通確認→再同期で進める
実装の雰囲気（PowerShell例）
GUIで進める場合でも、要点を理解するために代表的なコマンド例を載せます（環境に合わせて調整してください）。
# 機能追加（例）
Install-WindowsFeature -Name Failover-Clustering,FS-FileServer,Storage-Replica,Multipath-IO -IncludeManagementTools
# クラスタ検証（例）
Test-Cluster -Node "SERVER-A","SERVER-B" -Include "Storage","Inventory","Network","SystemConfiguration"
# クラスタ作成（例：管理用IPは環境に合わせる）
New-Cluster -Name "FSCLUSTER" -Node "SERVER-A","SERVER-B" -StaticAddress "10.10.10.50"
# クォーラム：ファイル共有ウィットネス（例）
Set-ClusterQuorum -FileShareWitness "\\WITNESS-SRV\quorum$"Storage Replicaの作成もPowerShellで可能ですが、初期検証では Windows Admin Center のウィザードを使うと、構成ミスが減りやすいです。いずれにしても重要なのは、複製元/複製先ボリュームの役割と初回同期の完了確認です。
運用設計で失敗しないためのチェックポイント
フェールオーバー時の動きと「手順書」を先に作る
2拠点ストレッチでは、障害時に現場が迷うと復旧が遅れます。以下は最低限、事前に文章化しておきたい項目です。
- サイトA障害時：どの判断でサイトBへ切替えるか（監視アラート、停電情報、回線断の検知など）
- 切替時に「誰が」「どの順番で」作業するか（連絡網、承認、実作業）
- 復旧後に元サイトへ戻す手順（戻すタイミング、複製方向の扱い、確認項目）
- ネットワーク分断時（両サイトは生きているが通信できない）の判断基準
バックアップは別物として必ず持つ
Storage Replicaは可用性（止まらない）のための仕組みであり、バックアップ（戻せる）の代替ではありません。誤削除、ランサムウェア、論理破壊は複製されます。
- 「別媒体」「別権限」「世代管理」を満たすバックアップを設計する
- 復元テスト（実際に戻るか）を定期的に実施する
- 共有フォルダの監査ログやアクセスログも、事故調査に役立つため保全を検討する
Synology側の実務的な作り込み（iSCSI LUN）
SynologyをiSCSIストレージとして使う場合、Windowsのクラスタ用途では次のような実務ポイントがあります（細部は環境差があるため、検証しながら決めるのが前提です）。
- 容量は余裕を持って割り当て：複製・スナップショット・バックアップ運用を見越して空きを確保
- 性能要件を先に決める：同時接続数、平均/ピークIO、ファイルサイズ傾向で必要性能が変わる
- iSCSIは専用ネットワーク＋MPIO：片系断でもI/Oが止まりにくい構成にする
- 監視項目を決める：CPU/RAM/ディスク待ち、NICエラー、ボリューム逼迫、リンク状態
それでも「別案」を複数持っておきたい場合の選択肢
Storage Replica案が最有力でも、要件や予算、社内標準で採れないケースもあります。その場合の現実的な代替案を、向き不向きも含めて整理します。
拠点内冗長を強める（各拠点2台以上）
Microsoft的な推奨に寄せるなら、各拠点に複数ノードを置いてサイト内でも冗長化します。例えば、サイトAに2ノード、サイトBに2ノードの4ノード構成にすれば、サイト内障害と拠点障害の両方に強くなります。
ただし、今回の「サーバー2台」という前提では増設が必要です。もし将来増設の可能性があるなら、今の2台構成を“第一期”として設計し、第二期で増やせる余地（ラック、電源、IP、VLAN、運用）を残すのが現実的です。
DFS名前空間（Namespace）で“移行しやすい名前”にする
可用性そのものをDFSで作るのではなく、クライアントが参照するパスを抽象化する目的でDFS名前空間を使う案です。
- ユーザーの接続先を「\\files.example.local\share」のような論理名に統一
- 裏側の実体（クラスタ名やサーバー名）が変わっても、移行時の影響を小さくできる
これは後述する50TB移行でも効きます。「今回の更新だけ」ではなく、次の更新も視野に入れるなら、DFS名前空間は投資対効果が高いです。
ファイル単位レプリケーション（DFS-R等）は慎重に
DFS Replication（DFS-R）はファイル単位での複製で、用途が合えば便利ですが、大容量（50TB級）＋更新が多い共有では運用が重くなりやすいです。ファイルロック、競合、バックログ、初回同期など現場のつらさが出やすいので、2拠点の“本番ファイルサーバー”をこれで作るのは、要件がよほど合う場合に限定するのが無難です。
50TBのファイル共有データを新クラスターへ移行する現実的な方法
次に「既存のストレッチファイルサーバークラスター」から「新しいHPE＋Synology構成」へ、約50TBを権限ごと移行する話です。結論から言うと、現場で勝ち筋になりやすいのは次の2択です。
- 管理と引き継ぎを重視するなら：Storage Migration Service（SMS）
- 制御性と実績重視なら：robocopyで“初回フル＋差分同期＋最終切替”
移行前に必ずやるべき「見積もり」と「段取り」
50TB移行で失敗する原因の多くは、ツールではなく段取り不足です。まずは以下を明確にします。
- 移行対象の共有一覧（容量、ファイル数、更新頻度、重要度）
- 切替時の許容停止時間（完全停止できるのは何時間か）
- 移行期間（何日かけて差分同期するか）
- ネットワーク帯域（夜間にどれだけ使えるか、QoSの有無）
- バックアップとロールバック（戻せる状態を作ってから切替える）
帯域が足りないと、永遠に終わらない
ざっくりでも良いので、転送の現実を掴むと計画が立ちます。50TBは、理論値ではなく実効スループットで考えるのがコツです。
| 回線の目安 | 実効転送（例） | 50TBの初回コピーの目安 | 現場での評価 |
|---|---|---|---|
| 1Gbps | 80〜110MB/s程度 | 数日〜1週間規模 | 差分同期前提なら可。業務時間の帯域確保が鍵 |
| 10Gbps | 500MB/s〜1GB/s程度（条件次第） | 1日〜数日規模 | “週末で終わらせる”現実味が出る |
| 混雑・制限あり | 数十MB/s以下 | 長期化しやすい | 共有単位で分割、夜間専用、オフライン搬送も検討 |
この時点で「間に合わない」と分かったら、共有を分割する、優先度の低い共有は後回しにする、夜間に専用時間を確保するなど、計画側で勝ちにいくのが重要です。
選択肢：Storage Migration Service（SMS）を使う
Storage Migration Service（SMS）は、Windows Admin Centerから利用できる移行支援機能で、単なるファイルコピーではなく共有設定やアクセス権の引き継ぎまで含めて整理しやすいのが強みです。
SMSが向いているケース
- 共有数が多く、共有名・権限・設定の引き継ぎを体系立ててやりたい
- 進捗やログをGUIで追いたい（関係者に説明しやすい）
- 切替時に“丸ごと移行”を狙いたい（ただし環境要件は事前検証が必須）
SMSの進め方（実務フロー）
- インベントリ：共有、ACL、容量、隠し共有、特殊設定を棚卸し
- 転送（初回）：運用しながらバックグラウンドでコピー
- 差分同期：切替日まで複数回実施してギャップを縮める
- 切替（カットオーバー）：短時間停止で最終同期→接続先を新環境へ
ポイントは「SMSは万能ではないので、小さな共有でパイロット移行してから本番に入る」ことです。特にクラスター絡み（旧環境の構成や役割）によっては、想定通りに引き継がれない項目が出ることがあります。パイロットの結果をもとに、切替時の作業手順書を固めるのが成功パターンです。
選択肢：robocopyで“初回フル＋差分同期＋最終切替”
大容量移行の現場で最も使われるのがrobocopyです。理由はシンプルで、挙動が読みやすく、ログが残り、調整余地が多いからです。ツールに慣れているなら、今でも強い選択肢です。
定番の進め方
- 初回フルコピー：運用中のまま、夜間や空いている時間帯に大きくコピー
- 差分同期を繰り返す：毎晩などで更新分を詰める
- 最終切替：短時間の停止で最終差分→共有公開先を切替
robocopyのコマンド例（ACL含めたミラー）
robocopy "\\OLD-FS\Share" "D:\Share" /MIR /COPYALL /DCOPY:DAT /R:0 /W:0 /MT:32 /TEE /LOG:"C:\Logs\share_mig.log"よく使うオプションの意図を整理すると、現場の事故が減ります。
- /MIR：ミラー（削除も反映）※運用次第ではリスク。最初は/ Eで始める手もある
- /COPYALL：データ＋属性＋タイムスタンプ＋ACL＋所有者＋監査などを含める
- /DCOPY:DAT：フォルダーの属性も保持
- /R:0 /W:0：リトライ地獄を避け、エラーをログで追えるようにする
- /MT：マルチスレッド（上げすぎると逆効果になることもあるので検証）
- /LOG：ログ保存（切替後の監査に重要）
robocopy運用で必ず入れておきたい“検証”
- 共有単位で、移行後にアクセスできるユーザー/できないユーザーを確認（代表ユーザーでテスト）
- 長いパス、深い階層、特殊文字を含むファイル名のテスト
- アプリが参照するパス（部署システム、スクリプト、バックアップソフト）の洗い出し
- 切替当日の問い合わせ窓口（想定問答）の準備
robocopyは「共有名やIPの切替」「クラスター役割の入替」までは面倒を見ません。その分、切替の設計を先に決めておくのが重要です。
選択肢：Storage Replicaを絡めた段階的移行（上級者向け）
旧環境と新環境の間で、条件が合えばStorage Replicaを使って差分を詰め続け、最終的に新環境を稼働系にする、というアプローチもあります。
- 最初にrobocopyで大半を移す（“初回の重い部分”を先に終わらせる）
- その後、SRで差分を継続同期
- 切替日に新側を稼働系へ
ただし、旧環境のOSバージョン、クラスター構成、ネットワーク、運用制約で難易度が上がるため、検証環境を確保できるチーム向けです。「短期間で確実に」を優先するなら、SMSかrobocopyが堅実です。
実務でのおすすめ（50TB移行の意思決定表）
| 優先したいこと | 第一候補 | 補足 |
|---|---|---|
| 共有設定・権限・切替をできるだけ自動化したい | Storage Migration Service | まず小さな共有でパイロット。条件により挙動が変わるため事前検証が鍵 |
| 移行を細かく制御し、ログを握って進めたい | robocopy（段階移行） | 切替（名前/IP/DFS等）を別途設計するのが前提 |
| 最小のダウンタイムに徹底的にこだわりたい | SMS or SR併用（高度） | ネットワークと検証体制がある場合に強い |
新クラスター移行後に“効く”追加の工夫
名前の固定化（次の移行も楽にする）
今回の更新で終わりではなく、次回更新も想定するなら、クライアントが参照するパスを工夫すると効果が大きいです。
- DFS名前空間でUNCを固定化する
- どうしてもDFSが難しいなら、DNSエイリアス（CNAME）運用を検討する（運用ルール必須）
- 共有名の統一（部署ごとのローカル命名を是正）
性能チューニングは「移行後の落ち着いたタイミング」で
移行直後は問い合わせ対応や差分修正で忙しく、チューニングの変更がトラブルを増やします。まずは標準設定で安定運用を固め、次に以下を段階的に進めるのが安全です。
- SMB Multichannelの効果測定（NIC追加や帯域最適化）
- レプリケーション帯域の見直し（同期/非同期、QoS、時間帯制御）
- 監視の整備（容量逼迫、遅延、エラー率、複製状態）
まとめ：HPE＋Synologyで2拠点ストレッチを“壊れにくく”作るコツ
- Synology iSCSIで共有ディスク方式にこだわると、SCSI-3 PRなどの要件で詰まりやすい
- 今回の構成はStorage Replica＋フェールオーバークラスタが相性良く、各拠点専用ストレージでシンプルに組める
- 2ノード＋2拠点はクォーラムが肝。第三拠点のウィットネスを必須にする
- 50TB移行はツールより段取り。SMSかrobocopy段階移行で、差分同期と短時間切替を前提に計画する
「同一DCで組んでから移設」という現場の都合があっても、最初から完成形のネットワーク/サイト構成を模擬しておけば手戻りは最小化できます。最終的に“運用が簡単で、障害時に迷わない”構成こそが、長期安定稼働の近道です。
コメント