Microsoft Windows: DFS に移行する

[アーティクル]
08/25/2016

まだ以前のファイルとフォルダーのレプリケーションソリューションを使用している場合は、今が分散ファイルシステムに移行すべきときです。

Gary Olsen

分散ファイルシステム (DFS) は、Windows NT の時代から存在していました。DFS には、さまざまな構成とオプションが用意されており、スタンドアロン構成とドメイン構成のどちらでも利用できます。DFS は、リモートサーバー間で、ファイルとフォルダーの冗長なレプリケーションを効率的に行うテクノロジとして定評があります。リモートサーバーを共通の名前空間の配下に置くと、ユーザーは、DFS 共有をホストしているサーバー名を指定することなく、DFS 共有に接続できるようになります。

残念ながら、これまで DFS のベストプラクティスに関する包括的なドキュメントが提供されたことはありませんでした。そこで、この記事では、これまでに、採用、判明、および推奨されてきたベストプラクティスの概要を紹介することにしました。新しい情報はマイクロソフト Web サイトで公開されているので、最新情報についてはここを参照してください。

DFS および分散ファイルシステムという用語は、Windows Server 2000、Windows Server 2003、Windows Server 2003 R2 で使用できるレガシー名前空間システムを言及する際に使用されます。また、Windows Server 2008 では、レガシーシステムとして扱われます。DFS では、レプリケーションエンジンとして、問題の多いファイルレプリケーションサービス (FRS) を使用していました。

Windows Server 2003 R2 では、大幅に強化されたレプリケーションエンジンと新しい DFS 名前空間システムが導入されました。この記事では「レガシー DFS」という用語は、Windows Server 2000、Windows Server 2003、および Windows Server 2008 のレガシー DFS を指して使います。新しい DFS 名前空間は DFS-N、新しいレプリケーションエンジンは DFS レプリケーション (DFS-R) と呼びます。

Windows Server 2003 のレガシー DFS と FRS

Windows Server 2000 と Windows Server 2003 のレガシー DFS では、厄介で複雑な管理コンソールと用語を使用していました。また、FRS にも問題がありました。Windows Server 2003 では、この問題のいくつかが緩和されましたが、問題を解決するには至りませんでした。そのため、Windows Server 2003 R2 と Windows Server 2008 では、DFS-R というまったく新しいレプリケーションエンジンが導入されました。

現在、マイクロソフトのメインストリームサポートの対象外となっている Windows Server 2003 を使用していて、Windows Server 2003 R2 と Windows Server 2008 で使用できる新しい DFS と DFS-R に移行していない場合は、移行する必要があります。このセクションでは、レガシー DFS と FRS に関する潜在的な問題とベストプラクティスを少し紹介しましょう。

FRS では、New Technology File System (NTFS) ジャーナルを使用して変更を検出します。NTFS ジャーナルは、ファイルシステムのファイルやフォルダーに変更が加えられたときに変更されます。残念ながら、FRS では、変更をレプリケートする必要があるかどうかを検出することができません。

通常、ウイルス対策ツールやディスク最適化ツールなど、ファイルをスキャンするアプリケーションでは、ファイルのセキュリティ記述子を変更します。この処理により NTFS ジャーナルに変更が加えられ、ファイルが変更されていないにもかかわらず FRS でファイルがレプリケートされます。Windows Server 2003 の FRS に加えられた変更により、この問題は緩和されましたが、解決には至りませんでした。Windows Server 2003 で加えられた変更は次のとおりです。

過剰なレプリケーションを抑制する: 特定のファイルが頻繁にレプリケートされていることが FRS で検出されると、イベントがログに記録され、そのようなファイルのレプリケーションが抑制されます。この変更により、ステージング領域がいっぱいになって FRS が停止することを回避できますが、有効なファイルを知らないうちに削除してしまう可能性があります。
FRS がステージング領域を過剰に使用することを回避する: ステージング領域の使用率が 90% になると、古いファイルを削除して、使用率が 60% になるようにします。この動作により FRS が強制終了されることは回避できますが、必要な変更内容が削除される可能性があります。
データのシードを回避する: FRS では、WAN 経由で大量のデータをレプリケートすることを回避するために、積極的に複数のサーバーにデータをシードできないようにすることが可能です。回避策は、少量のデータをコピーして、必要なデータをコピーすることです。

ベストプラクティス

レガシー DFS と FRS の管理と使用に関するベストプラクティスは、動的に変化するデータを DFS 共有に置いておくことは本質的に良くないという概念に基づいています。ファイルの数が多いと、FRS は、その影響を簡単に受けます。また、頻繁に変更されるデータのレプリケートでも問題が発生します。たとえば、ユーザープロファイルのマイドキュメントをホストするのには使用するべきではありません。

レガシー DFS と FRS に関する他のベストプラクティスには、次のようなものがあります。

複数のターゲットサーバー用の DFS 共有のデータを初期化するには、1 つの共有のデータをシードして、それをレプリケートします。データの量は少量にします。同時に複数の共有に多数のファイルを追加すると、FRS で状況を把握できなくなります。データが複数の DFS サーバーにある場合は、各サーバーのデータを順にレプリケートします (複数サーバーのデータを一度にレプリケートしないようにします)。初回のデータのシードが完了すると、その後、FRS では、変更のみをレプリケートします。
ウイルス対策ソフトウェア、最適化のソフトウェアなど、ファイルやフォルダーをスキャンするプログラムが FRS に対応していることを確認します。広く知られているプログラムには、この機能が備わっているので、スキャンによる不要なファイルのレプリケーションを回避できます。
データの冗長性を確保するため、複数のサーバーに複数のルートターゲットを作成します。ルートターゲットには、構成データが含まれます。
DFS リンクに複数のターゲットを作成することでデータの冗長性を確保します。この設定により、同じデータが継続して複数のターゲットにレプリケートされるようになります。いずれかのサーバーがダウンしていても、ユーザーは、別のサーバーにリダイレクトされます。DFS では、Active Directory の "クライアント認識" 機能を使用して、ユーザーから一番近いところにある DFS サーバーを特定します。
DFS データのレプリケーションは必須ではありませんが、データの冗長性を確保するためにレプリケートすることをお勧めします。レプリケートしない場合、DFS では、共有の共通名しか提供しません。
ドメインコントローラー (DC) では、DFS 共有をホストしないでください。SYSVOL では DC で DFS を使用するため、SYSVOL と DFS 共有が同じサーバーにない方が、レプリケーションに関する問題を特定しやすくなります。SYSVOL では、DFS サービスを使用するため、DC で DFS を無効にすることはできません。そのため、DC では、DFS リンクやルートターゲットをホストしないでください。
データ管理のため、ハブとスポーク構成のリンクターゲット間では、一方向の FRS レプリケーションを構成します。スポークターゲットに作成されたデータは、ハブにレプリケートされません。

レガシー DFS と FRS の制限事項

FRS では、数バイトしか変更されていなくても、ファイル全体がレプリケートされます。DFS または FRS が効率的にレプリケートできるのは、1 つの共有につき約 65 GB という制限があります。この制限を超えると、不一致やパフォーマンスの低下が生じます。その他の制限事項には、次のようなものがあります。

Windows Server 2003 Standard Edition では、1 台につき 1 つの DFS ルートしか持つことができません。ただし、Enterprise Edition には、制限がありません。DFS ルートの数が増えると、DFS サービスの起動にかかる時間も長くなります。
ドメインベースの各 DFS 名前空間で使用できるリンクは 5,000 個に制限されています。リンクの数が増えると、DFS の構成を変更したときにパフォーマンスの低下が生じます。
DFS のパスには 260 文字という制限があります。この制限を超えると、アプリケーションが DFS のデータにアクセスできなくなります。データには、明示的にドライブ文字を割り当てることでアクセスできるようになります。
クラスターノードでは、ドメインベースの DFS は構成できないので、スタンドアロンの DFS を使用する必要があります。

複数ドメインの DFS 構成の制限事項には、次のようなものがあります。

ドメインベースの DFS ルートのルートターゲットは、同じドメインに存在している必要があります。ただし、リンクターゲットは他のドメインに存在していてもかまいません。
クライアントは、信頼関係のあるドメインの DFS サーバーにアクセスできます。
クライアントから別のドメインのリンクターゲットにアクセスするときには、リンクターゲットの完全修飾ドメイン名 (FQDN) を使用します (詳細については、サポート技術情報の記事 244380 を参照してください)。
FRS は、ターゲットが (信頼関係のある) 別のドメインに存在する DFS リンクのレプリケートに使用できます (ただし、この操作を実行するにはエンタープライズの管理者権限が必要です)。

詳細については、DFS FAQ (英語) を参照してください。

Windows Server 2003 R2 および Windows Server 2008 の DFS-N と DFS-R

Windows Server 2003 R2、Windows Server 2008、および Windows Server 2008 R2 の新しい DFS-N と DFS-R は、レガシーの DFS と FRS から大幅に向上しています。DFS-R では、ブロックレベルでデータをレプリケートするので、ファイル全体ではなく、ファイルに加えられた変更のみをレプリケートします。

たとえば、ファイルサイズが 3 MB の PowerPoint スライドのタイトルを変更した場合、レガシー DFS では、3 MB のファイル全体がレプリケートされますが、DFS-R では、変更された数バイトのみがレプリケートされます。この変化は、ネットワークとディスクの両方のパフォーマンスに大きな違いをもたらします。また、変更がレプリケートされるときのユーザーから見たパフォーマンスも向上します。DFS-R では、大量のデータを処理して、そのデータを動的かつ効率的に変更できます。

DFS-R は、Windows Server 2003 R2 と Windows Server 2008 でのみ使用できます。Windows Server 2003 R2 に関しては DFS データのレプリケートにしか使用できませんが、Windows Server 2008 と Windows Server 2008 R2 では DFS データと SYSVOL データをレプリケートできます。レプリケーションに DFS-R を使用するには、DFS サーバーでのみ Windows Server 2003 R2、Windows Server 2008、または Windows Server 2008 R2 が実行されている必要があります。DC をアップグレードする必要はありません。

ベストプラクティス

Windows Server 2003 ドメインに新しいDFS と DFS-R をインストールするには、スキーマを変更する必要があります (詳細については、分散ファイルシステムレプリケーションに関してよく寄せられる質問を参照してください)。

Windows Server 2003 ドメインに DFS-N と DFS-R をインストールするために必要なスキーマの変更は、ある程度の承認が必要になる可能性が高いため、事前の計画が必要です。
レプリケーショングループを使用すると、ブランチサイトのデータを、大容量の SAN ディスクにデータを簡単に格納できるハブサイトのファイルサーバーにレプリケートできます。このシナリオでは、新しいデータがリモートサイトにのみ追加されるようにします。既存のファイルがコア (ハブ）サイトで変更されると、リモートサイトに変更内容がレプリケートされ、リモートサイトのファイルが上書きされます。
Windows Server 2008 と Windows Server 2008 R2 では SYSVOL のレプリケーションに DFS-R を活用してください。特に多数のグループポリシーを展開している大規模なドメインでは、そうすることをお勧めします。Windows Server 2008 ドメインの既定のレプリケーションエンジンは FRS なので、この処理を行うには移行が必要です。
詳細については、Microsoft Directory Service チームの TechNet ブログの記事「DFS-R SYSVOL Migration FAQ for instructions and tips on migrating SYSVOL to DFS-R (DFS-R と SYSVOL 移行に関する FAQ - SYSVOL から DFS-R への移行の指示とヒント、英語)」を参照してください。

SYSVOL を DFS-R に移行する前に修正プログラム 972105、969688、978326、959114、978994 を適用して、次の手順を実行します。

Windows Server 2008 R2 でレガシー DFS と FRS の廃止が始まったら、レガシー DFS の共有を DFS-N と DFS-R に移行します。レガシー DFS と FRS は、どちらも最終的には廃止されます。
展開前にレプリケーショングループのレプリケーショントポロジを設計します。DFS-R トポロジには、DFS と FRS にない多数のオプションがあります。ファイル展開の設計に適したレプリケーション方法を採用するようにします。
DFS-R レプリケーションの状態を監視します。System Center Operations Manager には、DFS レプリケーションを監視するための管理パックが用意されています。また、サードパーティ製のツールもあります。ただし、既存の Ultrasoud ツールと Sonar ツールは、DFS-R に対応していません。

いくつかの制限事項

DFS-R は、より堅牢で効率的なレプリケーションを実現し、動的なデータを適切に処理します。ただし、DFS インフラストラクチャの計画を立てるときには DFS-R のスケーラビリティに関する制限事項を理解しておくことが重要です。レプリケーショングループは、DFS 名前空間の構成とは無関係に定義できます。この 2 つの間に依存関係はありません。ただし、次の制限事項があります。

1 台のサーバーは、最大 256 個のレプリケーショングループのメンバーになることができます。
各レプリケーショングループには、最大 256 個のレプリケートフォルダーを含められます。
各サーバーでは、最大 256 個の接続を確立できます (たとえば、128 個の着信接続と、128 個の発信接続を確立できます)。
各サーバーでは、レプリケーショングループの数、レプリケートフォルダーの数、およびアクティブな同時接続の数を乗算した値が 1,024 以下でなければなりません。
1 つのレプリケーショングループには、最大 256 個のメンバーを含められます。
1 つのボリュームには、最大 800 万個のレプリケートファイルを含めることが可能で、1 台のサーバーでは、最大 1 TB のレプリケートファイルを保持できます。
テスト可能なファイルの最大サイズは 64 GB です。
DFS-R では、FRS と通信できません。

この問題の詳細については、TechNet の記事「DFS レプリケーションのスケーラビリティに関するガイドライン」を参照してください。また、この問題について取り上げているお勧めの FAQ もあります。

全般的な推奨事項は「FRS を真剣に廃止する」という単純なものです。FRS は、何年も前にマイクロソフトが開発を止めた古いテクノロジです。困難な作業に敢えて着手し、(Windows Server 2003 R2 以降の) すべての DFS 共有と (Windows Server 2008 以降の) SYSVOL レプリカを DFS-R に移行してください。

堅牢なパフォーマンスの向上を活用して、より生産的な作業に時間を使ってください。Windows Server 2008 R2 でレガシー DFS と FRS を廃止したことにより、マイクロソフトは、より良いテクノロジに移行すべきときが来たというメッセージを発信しています。この新しいテクノロジに移行することで発生するデメリットは、ほとんどありません。

Gary L. Olsen

Gary L. Olsen は、ジョージア州アトランタにある Hewlett-Packard の Worldwide Technical Expert Center でシステムソフトウェアエンジニアとして働いています。1981 年から IT 業界で働いています。ディレクトリサービスの Microsoft MVP であるだけでなく、Atlanta Active Directory Users Group の委員長を務めています。『Windows 2000: Active Directory Design and Deployment』(New Riders、2000 年) の著者で、『Windows 2003 on HP ProLiant Servers』(Prentice Hall、2004 年) の共著者でもあります。