ReFSとNTFSにおける最適なアロケーションユニットサイズとは?

新しいボリュームを作成する際に,アロケーションユニットサイズ(allocation uniti size)を指定しなければなりません。もちろんデフォルトのままでもよいですが,パフォーマンスにも影響を及ぼすため,最適なアロケーションユニットサイズについて知っておくことは大切です。

そこで,MicrosoftがTechnetで公開している最適なアロケーションユニットサイズについての公式情報をまとめました。

ReFSNTFSでは,システムの扱い方が全く異なるため,アロケーションユニットサイズの選び方も変わってきますので,十分に注意したいところです。

そもそもアロケーションユニットサイズとは?

Microsoftのファイルシステムの管理方法は,クラスターサイズという考え方がベースになっています。クラスターサイズというのは,アロケーションユニットサイズ(allocation unit size)としても知られている単位で,ディスクスペースを使用する際の最小単位です。

たとえば,アロケーションユニットサイズが64Kに設定されている場合,つまりディスクを使用する際の最小単位が64Kということになりますので,仮に,1Kのファイルを保存したとしても,64K分の領域が確保されます。同様に,65Kのファイルを保存すると,128K分のディスクスペースを消費することになります。

ReFSとNTFSは,ディスクスペースの粒度についてファイル毎に持つことはしないため,ディスクごとに設定したそのクラスターサイズ(アロケーションユニットサイズ)が,すなわちファイルの最小単位になります。

ReFSもNTFSも,色々なクラスターサイズを設定することが可能です。粒度を細かくすればディスクスペースを効果的に用いることができたり,あるいは大きくすれば,アクセス速度を上げたりすることもできます。

しかし,最適なアロケーションユニットサイズを決めるためには,ディスクのI/O性能や,キャパシティによっても考え方が変わってくる部分ですので,どのような要素を踏まえてサイズを決定したらよいかをしっかりと抑えておきたいと思います。

I/Oアンプリフィケーションについて

アロケーションユニットサイズを考えるうえで,まずはディスクI/Oについてどのような影響があるのかを考える必要があります。

そのサイズによっては,I/Oが非常に大きくなってしまい,ディスクへの負荷が増大してしまいます。

しかし,I/Oというのは実は複雑な処理が関係しています。例えば,1つのI/Oを要求したとしても,場合によっては別のI/Oをトリガーする必要が生じてしまい,意図しないI/Oの増加を生み出してしまう場合があります。

この現象によって,ストレージパフォーマンスの最適化を阻害する以下のシナリオ発生するかもしれません。

例えば,ディスクにWriteの要求が発生した場合,まずはメモリに書き込み,そしてふさわしい時にディスクに書き込むという動作になります。これにより,ストレージのI/Oを劇的に減らすことができ,パフォーマンスを向上させています。

しかし,ディスクに書き込む最中に,読み込みの要求が発生した場合,その読み込みが終わるまで処理を待たされてしまいます。これは,ディスクのWrite性能に非常に大きな悪影響を及ぼします。

このシナリオで生じる現象を,I/Oアンプリフィケーションと言います。

ReFSのアロケーションユニットサイズについて

ReFSでは基本的に,4Kか64Kのクラスターサイズを選択することが可能です。デフォルトでは4Kが選択されることになります。(特定の場合では,64Kしか選択できないかもしれません。)

ReFSではアロケーションユニットサイズは4Kか64Kを選択できる

ReFSではアロケーションユニットサイズは4Kか64Kを選択できる

そして,Microsoftは,ほとんどのReFSボリュームにおいて4Kを推奨しています。そうすることで,上述したI/Oアンプリフィケーションを軽減させることができます。

一般的に言って,クラスターサイズがI/Oサイズを超えた場合,別のI/Oを発生させてしまいます。例えば,64KでReFSがフォーマットされていた場合のシナリオを考えてみましょう。

もし,1Kのファイルを読みだそうと思う場合,ReFSは,残りの63K分の領域も読みよらなければなりません。それが完了するまで,次の書き込み動作に移ることができません。その時間は無駄が発生するということです。

あるいは,ブロックの複製というオペレーションを行った場合でも,ReFSはすべてのクラスターを読みださなければならず,63K分の領域もコピーしなければ次の動作に移れないということです。

また,ReFSの整合性ストリームを使用している場合,サブクラスターで小さな書き込みがあったとしても,すべてのクラスターにおけるデーターの再配置,再書き込みが必要となってしまいます。そしてチェックサムで整合性を取り直さなければなりません。これによって,追加のI/Oが発生してしまい,ReFSは次の書き込みを行うことができません。これは,I/Oのパフォーマンスを劇的に遅くすることになります。

それで結論として,64Kではなく4Kのクラスターサイズを使用することで,クラスターサイズよりも小さいI/Oが発生した時に,不要なI/Oアンプリフィケーションを避けることができます。

NTFSのアロケーションユニットサイズについて

NTFSでは,512から64Kまでのアロケーションユニットサイズを選択することが可能です。

NTFSでは512から64Kまでのアロケーションユニットサイズを選択できる

NTFSでは512から64Kまでのアロケーションユニットサイズを選択できる

NTFSにおいても,基本的に4Kを選択することが推奨されています。そうすることで,4Kよりも小さなファイルを保存した時に,無駄なディスクスペースを消費しなくて済むからです。

とはいえ,4Kよりも小さいアロケーションユニットサイズを選択することは避けてください。粒度が細かすぎると,無駄な処理を発生させてしまうからです。

それで,NTFSにおいては,4Kあるいは,64Kを選択した方がよいケースの2つが存在します。では,64Kを選択したほうが良いどんなケースがあるでしょうか。

まず,4Kのクラスターサイズを選択した場合には,ボリュームの最大サイズが16TBに制限されます。それで,VHDXファイルをストアしたり,SQLをデプロイする際などの,巨大なボリュームが必要とされる場合には,64Kのアロケーションユニットサイズを選択するのが良いでしょう。

また,NTFSには,フラグメンテーションの上限値も存在します。ファイルのメタデータは,150万以上を持つことができません。一昔前なら問題なかった仕様ですが,現在ではそういう状況も発生しうるかもしれません。とはいえ,必要であれば,format /Lというオプションを用いて,600万まで拡張することも可能です。

それで,フラグメンテーションが問題になりえる環境においては,その影響を受けにくい64Kを選ぶと良いでしょう。例えば,データの重複排除を行う場合や,SQLのデプロイ,ファイルが点在している場合などです。

ちなみに,64KではNTFSのコンプレッション(圧縮)に対応していませんので,その場合には,4Kを選択しつつ,上述のformat /Lで回避するしかないでしょう。

ReFSとNTFSの推奨アロケーションユニットサイズまとめ

ReFSでは,デフォルトの4Kを利用しましょう。

NTFSでも,デフォルトの4Kを選べば大丈夫です。とはいえ,明確な目的がある場合,例えばHyper-V環境でVHDXをストアしたり,SQLのデプロイ,デデュープリケーション(重複排除)を有効にする場合,または巨大なファイル群をストアすることが分かっているボリュームなどには,64Kを指定しましょう。

以上,ReFSとNTFSにおける最適なアロケーションユニットサイズの選択について,Microsoftが推奨している方法でした。

コメント

  1. […] 別の記事で,ReFSとNTFSにおける最適なアロケーションユニットサイズについて書いておりますので,興味がある方はご参照ください。 […]