VPN 越しの DFS レプリケーション: ロックは得られない

リンクは暗号化され、常時接続で十分に高速です。だから共有フォルダーは両拠点で同じフォルダーのように振る舞うはずだ、というのが、後になって人を驚かせる多くの DFS レプリケーション設計の前提です。DFSR はマルチマスターかつ非同期で、各レプリカはバージョンを独立に追跡し、プロトコルにはサーバー間でロックを保持する仕組みがありません。VPN は両者間のトラフィックを運ぶだけで、その前提が必要とする調整を一切追加しません。書き込みパターンと容量モデルを設計してください。さもなければ、最初の本当の競合がサポート案件になります。

神話: VPN はレプリカを一つのファイルシステムにする

トンネルはトランスポートです。二台のサーバー間に許可された経路を与え、途中のホップを隠します。誰がファイルを編集できるのか、バージョンがどの順序で届くのか、二つの編集が競合したら何が起きるのかについては何も語りません。

暗号化と可用性はリンクの性質であり、一貫性はレプリケーションエンジンとあなたのワークフローの性質です。

DFSR が実際に複製するもの

各サーバーは独自のコピーと独自のバージョンメタデータを保持します。変更は接続とスケジュールが許すときに伝播し、エンジンはリモート差分圧縮を使って変更された部分だけを送ります。どちらの更新も届かないうちに二つのレプリカが同じファイルを変更すると、一方のバージョンが勝ち、もう一方は競合コピーとして脇に移されます。ブロックには DFSR が提供しない分散ロックが必要なので、どのサーバーも二番目の編集を妨げませんでした。

名前空間パスはコピーに到達しやすくしますが、コピーを整合させはしません。

ステージング領域は作業容量であり、バックアップではない

ステージングは、レプリケーションが変更を組み立てる間に使う作業領域です。Microsoft のサイズ設定ガイダンスは、複製フォルダー内で最も大きい 32 個のファイルの合計サイズを最小値とし、初回レプリケーション中は追加の余裕が役立つとしています。そのため、小さな文書のツリーと大きなアーカイブを複数置くフォルダーでは、必要なステージングの形が異なります。ステージングが尽きると、レプリケーションはネットワーク障害のように見える形で止まります。データからサイズを見積もり、データが変わったら見直し続けてください。

ステージングはバックアップではなく、変更の伝播はバージョン履歴ではありません。

事前シードは最適化であり、近道ではない

大規模な既存ツリーでは、Robocopy によるサポートされた事前シードが初回同期でリンクを渡る量を減らせます。また Microsoft のガイダンス はファイル情報の保持と、ロックされたファイルやスキップされたファイルの扱いを説明しています。これは最適化であり、宛先がすでに正しいという約束ではないため、初回レプリケーションは完了させて検証する必要があります。この検証を飛ばすと、拠点は複製セットに一度も入っていなかったファイルを配信するようになります。

ユーザーが宛先に依存する前に初期状態を検証してください。最初の苦情が出てからでは遅すぎます。

時間帯を選び、「最新」の定義を決める

レプリケーションスケジュールと帯域制御は、パートナーがデータを交換できる時間を決めます。勤務時間外の狭い時間帯は、日中に滞留を残す正しい設計です。ただし、リモートのコピーは朝までに最新であればよい、と全員が合意していることが条件です。

その一文を書き留めてください。「滞留は四十分」という表現が警告になるのは、目標を誰も定義していない場合だけです。

単一ファイルではなく、ワークフローで受け入れる

実際に人が使うファイルでテストします。大きな文書、日常的な編集、削除、そして両拠点での意図的な同時編集です。競合時の挙動が事業側に伝えた内容と一致すること、バックアップからの復旧経路がレプリカとは別であることを確認してください。そのうえで数週間、変更量、キューの増加、ステージングの余裕をサービス時間帯に対して観測します。VPN の容量は複数ある制約の一つで、最初に突き当たる制約になることはほとんどありません。

遅延と編集ルールを文書化した設計は、同一のコピーを約束する設計よりもはるかにサポートしやすいものです。