「実験的なささいなこと」の継続。 前の部分はここで読むことができます 。
本日のリリースは、約束のリリースになります。 私が約束したことを成し遂げ、DFSを使用して興味深いことを行う方法を説明します。 もちろん、これはファイルデータの完全なフォールトトレランスではなく、少なくともオンラインバックアップに似たものになります。
まず、DFSを使用してファイルクラスターを配置する価値はないという経験的信念を繰り返します。 これらの目的ではなく、DFSが作成されました。 そして、私をすべてdotでるために、ここに私の議論があります：
- DFSでは、どのファイルレプリカが正しいかを判断する方法はありません。
- 1つのサイトに複数のレプリカがある場合、DFS自体は、ストレージサーバーの負荷によって判断して、ユーザーリクエストをレプリカAまたはレプリカBに送信する場所を選択します。 （レプリカを選択するための設定はいくつかありますが、本質は変わりません。サイト内に複数のレプリカがある場合、特定のレプリカを選択することは予測できません。
- これらのニュアンスにより、ユーザーAがレプリカAと連絡を取り、そこでデータを操作し、ユーザーBがレプリカBと連絡を取り、そこでデータを操作する状況をシミュレートできます。 その結果、変更されたデータのTWOブランチが形成され、DFSはどのデータが正しいかを認識せず、最新の変更があるものを選択するだけです。 この状況で、ファイルストレージを使用した場合、またはさらに悪いことにデータベースを使用した場合に何が起こるか想像できます。
- さて、開いているファイルの複製が無期限に遅延する可能性があることは注目に値します。 最も単純な例は、家を出るときにオフィス文書を閉じないユーザーです。
上記のすべてから、DFSはブランチへのデータ転送、ほとんど変更されないデータ（注文、注文、アーカイブ）および同様のタスクの同期に最適であると言えます。 ただし、DFSを使用することで少し複雑になる可能性がありますが、これは通常ではありませんが、それでも便利な方法です。
DFSに基づいて一種のオンラインレプリカを構築できます。これは、ほとんどの場合機能せず（つまり、データ同期に関するほとんどの問題が発生しないことを意味します）、メインレプリカが失敗した場合にオンにできます。
次のようになります。
ここでは（例としてDepartmentフォルダーを使用）、同じフォルダーの2つのレプリカが作成され、レプリケーショングループとレプリケーションジョブが構成されます（これはすべてセットアップウィザードによって行われ、問題は発生しません）。 アイデアのスマックは、ストレージサーバーへのリンクの1つが無効になっていることです。 レプリカがある場合、サーバー間のレプリケーションは指定どおりに行われますが、DFSを介してこのフォルダーにアクセスするユーザーは、最初のアクティブなサーバーにのみリダイレクトされます。
2番目のサーバーは、可能な限りデータを複製し、「オンフック」のようになります。 緊急の場合、2番目のサーバーへのリンクをオンにし、最初のサーバーへのリンクをオフにすると、ユーザーは再びネイティブデータにアクセスできます。これは、DFSレプリケーションが実行できたのと同じくらい関連します（実際にはこれは完全な関連性、つまり0.5-2秒前の状態、開いているファイルが閉じられるまでレプリケートされない場合、つまりアプリケーションによってロック解除されるまで2-3日までの状態です）。
それは素晴らしいようです！ 緊急にこのスーパーシステムを実行しました！ しかし、すべての良い点に加えて、非常に良い点はありません：
- DfsrPrivate隠しフォルダー（データ複製用のサービスフォルダー）の各ボリュームには、最低2倍のマージンが必要です。 データストレージの2倍のコスト（同じものが両方のサーバーに格納され、一度に1つだけで動作する）を考えると、これはもう魅力的ではないように見えます。 このようなフォールトトレランスの場所は、データ自体の少なくとも4倍以上を割り当てる必要があります。
- ユーザーは、DFSを使用しているときにブレーキがかかることがあります。 正確な理由を理解することはできませんでしたが、それは常にいくつかのレプリカが存在し、ネットワークにゼロ以外の負荷がかかった結果でした。 レプリカが1つだけになるとすぐに、ブレーキは小さくなりました。 それは間違いなく作業中のレプリケーションとは関係がなく、DFS名の解決に関するいくつかの問題に非常に似ていました。
- 「時間X」で切り替えた新しいレプリカをユーザーが見るには、おそらくコンピューターを再起動する必要があります。そうしないと、古いパスをたどろうとします。
- 動作中のレプリカに自動的に切り替える-私はしませんでした、なぜなら これには標準的な方法はなく、テクノロジー自体に多くのマイナスがある状況で奇跡的なスクリプトを書くのは無謀なように思えました。
説明した例でわかるように、非常に重要な利点に加えて。 また、かなり大きな欠点もあるため、優先順位を付け、賛否両論を検討し、特定の状況で何をすべきかを自分で決定します。
ところで、Windows Server 2008（R2）では、DFS（および特にそのレプリケーションサービス）が根本的に改善され、おそらくいくつかの問題が正常に解決されたことがわかっています。 それを試してみてください-おそらく提案されたスキームははるかにうまくいくでしょう。
継続する。