トップ回答者
Windows Server 2012 R2 へのファイルサーバ移行時のクォータの容量制限について

質問
-
いつもお世話になります。
初めて質問させていただきます。現在、Windows Server 2003 R2 EE で構築していたファイルサーバを Windows Server 2012 R2 Std へ
乗せかえるため構築中です。
旧サーバから新サーバへファイルコピーをする際に、それぞれ同サイズのクォータ(FSRMによるハードクォータ)を
設定しているのにもかかわらず、コピー先で制限にかかりディスク容量不足となってしまいます。1.コピー方法について
コピーの際は以下のように robocopyコマンドを使用しています。
robocopy src dst /MIR /DCOPY:T /COPY:DAT /V /NP /NFC /LOG+:logfile /R:0 /XD "\System Volume Infomation" "\RECYCLER"
2.クォータの設定について
クォータの設定方法は以下の通りです。
ドライブ━「Share」フォルダ
┣「A」フォルダ(ハードクォータ設定)
┃ ┣「A-1」フォルダ(ハードクォータ設定)
┃ ┗「A-2」フォルダ(ハードクォータ設定)※このフォルダが制限にかかっているとします。
┣「B」フォルダ(ハードクォータ設定)
┃ ┣「B-1」フォルダ(ハードクォータ設定)
…以下、同様に複数フォルダ
3.その他、留意事項や気になる点
・親フォルダのハードクォータで制限はかかっていません。
・対象ドライブはデータ重複除去機能を使用しています。(旧サーバでは未使用)
・制限にかかるフォルダ(上記A-2フォルダ)は圧縮属性持ちです。(フォルダのプロパティ-詳細設定による)
※robocopy では圧縮属性はコピーできないため、コピー前に圧縮属性のフォルダを作成しました。4.疑問点
(1)仕様が変わったということでしょうか?
フォルダのプロパティで表示される「ディスク上のサイズ」はクォータ制限サイズ以下ですが、
フォルダのプロパティで表示される「サイズ」はクォータ制限サイズと同じです。
これは、クォータ制限の対象が「サイズ」となっているということですが、旧サーバでは
クォータ制限の対象が「ディスク上のサイズ」でした。
WS2003とWS2012で仕様が変わったのでしょうか?(2)データ重複除去の影響があるのでしょうか?
Technetの「データ重複除去の展開計画」※によると、
ボリュームルートフォルダへのハードクォータの設定でなければ、問題ないと読み取れたのですが、
>FSRM クォータでは、重複除去されたファイルはファイルの論理サイズに基づいて処理されます。
とあるのは、圧縮属性持ちのフォルダであっても、元のサイズに基づいて処理されるということでしょうか?
※リンクが貼れなかったので、後で修正出来れば追記します。(3)その他、考えられる原因はありますでしょうか?
不足情報等ありましたら、追記いたします。
以上、大変長文となりましたが、ご教授をお願いいたします。- 編集済み fukuo78 2015年8月4日 3:15 誤字修正及び質問追加
回答
-
推測ですので、間違っていたらご容赦ください。
まず、2008の頃のFSRMの資料、
https://technet.microsoft.com/en-us/library/cc754810%28v=ws.10%29.aspx
によると、FSRM quota の Disk usage calculationは、Actual disk spaceです。これは通常ファイルをエクスプローラーのプロパティで見たときの「ディスク上のサイズ(size on disk)」のことだと思います。size on diskは以下に書かれているように、通常ファイルの場合は「サイズ」をアロケーションユニットサイズ(クラスタサイズ)で切り上げた値になります。一方NTFS圧縮されたり、スパースファイルだったりすると、「サイズ」よりも小さい値になりそうです。
https://technet.microsoft.com/en-us/magazine/hh148159.aspx
よって、(データ重複除去未使用の場合、)NTFS圧縮するとFSRMクォータの使用量が減るということだと思います。一方、2012以降のデータ重複除去を使う場合は、
https://technet.microsoft.com/en-us/library/hh831454.aspx
に「When FSRM quotas encounter a deduplicated file, File Server Resource Manager accounts for it based on the file’s logical size. 」とあるので、(通常ファイルと異なり)データ重複除去されたファイルについては、ファイルのlogical sizeで使用量を計測する、ということのようですので、ファイルのプロパティの「サイズ」の方で計測するようです。結局のところ、
・(データ重複除去無しで)NTFS圧縮されたファイル = 「ディスク上のサイズ」で使用量を計測。(NTFS圧縮によりクォータ使用量が減る)
・データ重複除去されたファイル=「サイズ」で使用量を計測。(データ重複除去してもクォータ使用量が減らない)
という違いがあるのは仕様通り、ということではないかと思います。
あと、データ重複除去は、内部的に(NTFS圧縮のような)圧縮機能を持っていてデフォルトで有効化されていますので、NTFS圧縮を併用するのはあまり意味が無いのではないかと思います。圧縮が有効かどうかは Get-DedupVolume | fl の結果のNoCompress欄で確認できます。
すべての返信
-
推測ですので、間違っていたらご容赦ください。
まず、2008の頃のFSRMの資料、
https://technet.microsoft.com/en-us/library/cc754810%28v=ws.10%29.aspx
によると、FSRM quota の Disk usage calculationは、Actual disk spaceです。これは通常ファイルをエクスプローラーのプロパティで見たときの「ディスク上のサイズ(size on disk)」のことだと思います。size on diskは以下に書かれているように、通常ファイルの場合は「サイズ」をアロケーションユニットサイズ(クラスタサイズ)で切り上げた値になります。一方NTFS圧縮されたり、スパースファイルだったりすると、「サイズ」よりも小さい値になりそうです。
https://technet.microsoft.com/en-us/magazine/hh148159.aspx
よって、(データ重複除去未使用の場合、)NTFS圧縮するとFSRMクォータの使用量が減るということだと思います。一方、2012以降のデータ重複除去を使う場合は、
https://technet.microsoft.com/en-us/library/hh831454.aspx
に「When FSRM quotas encounter a deduplicated file, File Server Resource Manager accounts for it based on the file’s logical size. 」とあるので、(通常ファイルと異なり)データ重複除去されたファイルについては、ファイルのlogical sizeで使用量を計測する、ということのようですので、ファイルのプロパティの「サイズ」の方で計測するようです。結局のところ、
・(データ重複除去無しで)NTFS圧縮されたファイル = 「ディスク上のサイズ」で使用量を計測。(NTFS圧縮によりクォータ使用量が減る)
・データ重複除去されたファイル=「サイズ」で使用量を計測。(データ重複除去してもクォータ使用量が減らない)
という違いがあるのは仕様通り、ということではないかと思います。
あと、データ重複除去は、内部的に(NTFS圧縮のような)圧縮機能を持っていてデフォルトで有効化されていますので、NTFS圧縮を併用するのはあまり意味が無いのではないかと思います。圧縮が有効かどうかは Get-DedupVolume | fl の結果のNoCompress欄で確認できます。
-
詳しいご説明大変感謝いたします。
とても理解できました。その後、データ重複除去を解除してみたところ、使用量が「ディスク上のサイズ」で計測されましたので、恐らくご推測の通りなのかと思われます。
クォータの制限容量を増やすことで対応しようかと思います。ただ、もしデータ重複除去を有効にしたディスクの容量をフルに活用しようとする場合、この仕様だとクォータの合計がディスクのサイズを超えることになってしまいます。
データ重複除去による削減容量がどこまで信用できるか(重複除去したファイルが編集等により復活する?など)、まだわからない状態ですので、そのあたりの情報は別途調べてみようかと思います。また、Get-DedupVolume | fl で確認しました。
NoCompress は False と圧縮は有効になっていましたので、NTFS圧縮も意味がない状態でした。
(余談ですが、Format-List を fl と省略できるのは知りませんでした。)
今後の運用としまして、NTFS圧縮は使用しないようにいたします。以上、ご回答ありがとうございました。
回答としてマークいたします。