
インフラエンジニア向けに、ストレージ装置のディスクをOSにディスク認識する際の容量に関するポイントを解説します。
この情報を意識しない場合、実際に利用する容量「実効容量」が足りないなどという状況に陥りますので、ぜひ学んで正しく設計するよう心がけて頂ければと思います。
Contents
OSへのディスク認識
ストレージ装置は大量のディスクを搭載し、RAIDを設定します。
RAIDの中にはボリュームという単位で論理的な要領を設定します。これをLUNと言います。詳しくはこちらの記事を参照ください。
ストレージ装置のボリュームは、OSに認識されるディスクとして扱うことが出来ます。サーバーOSは、このように物理ディスクではなく論理ディスクを認識することがほとんどです。
ディスク容量の設計では、ボリュームがOSへ認識される過程で使用可能な容量が減ることに注意が必要です。容量が減るポイントごとに解説します。
ディスクラベルによる減少
OSで管理するためにそのディスクの先頭にラベル情報を書き込む必要があります。OSで使うための目印のようなものです。
ディスクにラベル情報を書き込む操作を、「ラベル付け」や「フォーマットする」という言葉を使う場合があります。
Linux OSなら、UEFIやMBR、SolarisならEFIやVTOCといった種類が相当します。これにより容量が減少します。ディスクラベルは1セクタ分の容量を確保しますので、その分容量が減少します。
1セクターの容量は、HDDの場合長らく512バイトでしたが、4,092バイトのディスクが登場しています。
パーティションのアライメント
次に、OSでディスクを利用する場合にはパーティションを作成します。パーティションとは、ディスクやボリュームを論理的に分割した単位で、ここからここまではパーティションの何番というデータ保存領域である、という範囲指定のようなイメージです。
Linux OSでパーティション作成を行う際には、先頭位置を1MiB(1メビバイト=1024Kバイト=2の20乗)から作成します。そのためラベル情報と合わせて1MiB分容量が減ります。これをアライメントと言います。
車のタイヤ調整でも使う用語ですね。
なぜそんなことをするのでしょうか。
ディスクやボリュームには、それ自体にデータの区切りが存在します。ディスクには、ディスクラベルの説明で登場した、セクターと呼ぶデータを保存する集合単位があります。ディスク装置は、その集合単位ごとにエラー訂正情報などを記録する仕組みになっています。
このアライメントをせずにそのままパーティションを作成すると、ラベル情報の分開始位置がずれますから、以下のようにデータの保存単位ごとに微妙にずれてしまい、結果的にディスク性能が悪くなるという問題が発生します。

⇒オレンジ色の部分に書き込みたいが、セクター範囲をまたいでしまう。

⇒アライメントサイズを合わせることでぴったりデータを書き込める。
ボリューム管理ソフトウェア
OSが認識したディスクに対して、ボリューム管理ソフトウェアというものを使う場合があります。OSが認識するディスクを、ボリュームとして管理するためのミドルウェアです。
これはRAIDで作ったボリュームとはまた別の概念になります。OSの内部で、ボリュームという概念で管理することがあります。ややこしいですよね。
- RAIDの中に作るボリュームはハードウェアボリューム
- ボリューム管理ソフトウェアによって作るボリュームはソフトウェアボリューム
このように理解するとよいかと思います。

上記の図のように、一旦OSで論理ディスクと認識され、さらにソフトウェアボリュームに変わります。
なぜ、またボリュームが登場するのでしょうか。
ソフトウェアボリュームは主に、複数台のサーバ間でディスクを共有する場合に必要です。Oracle Databaseの「ASM」、富士通クラスタソフトウェアの「PRIMECLUSTER GDS」、Veritas社の「Veritas Volume Manager」などです。主に、排他制御することで、複数サーバからの同時利用によってデータの破壊から保護することを目的とし、I/Oの高速化を同時に図るソフトウェアもあります。
これらボリューム管理ソフトウェアは、OSが認識したディスクに対して管理領域として数MB~数GB程度の容量を確保<します。実効容量がこれによって大きく減ってしまうことが無いよう注意が必要です。製品のマニュアルなどで設計時に確認することをお勧めします。
※マニュアル記載例:PRIMECLUSTER GDSの場合
https://software.fujitsu.com/jp/manual/manualfiles/M060038/J2UZ7241/02Z2A/gdslaa/gdsl0211.html
ファイルシステムかrawデバイスか
このように論理ディスクとして認識されたストレージ装置のボリュームは、OSが利用するにあたって容量が減少します。
最後に、そのディスクにデータを書き込む際の方式が大きく2通りあります。それは、論理ディスクにファイルシステムを作成するか、rawデバイスとして使用するかの2通りです。
ファイルシステム
ファイルシステムとは、データをディレクトリやファイルとして扱うようにする仕組みです。パソコンのようにファイルを作成したりということは、ファイルシステムという機能が実現しています。
Linux OSのファイルシステムは、XFSやext4といった種類があります。
そして、このファイルシステムも管理領域を必要とするため、ファイルシステムを作成すると、さらに利用可能な容量が減少することになります。
大体どの程度容量が減るのかは、各ファイルシステムによって異なりますが、一般的に0.87~0.93倍程度になってしまうことが多いようです。
rawデバイス
rawデバイスとは、論理ディスクにファイルシステムを介さずに直接データを書き込む仕組みです。
ファイルシステムの場合は、論理ディスクをマウントするという操作を行うことで、ディレクトリなどの扱いが可能となりますが、rawデバイスの場合は、ディスク、または
パーティション全体をそのまま利用するため、細かい単位でのデータ書き込みが出来ないという条件があります。
ディスク全体の複製によるバックアップなどに用いられるほか、先ほど登場したボリューム管理ソフトウェアがrawデバイスとして一度管理下に置き、ソフトウェアボリュームを作成するという用法があります。
作成したソフトウェアボリュームにもファイルシステムが作成可能ですが、データベースミドルウェアなどは、独自の形式でデータを書き込むことで高速化を図るため、あえてrawデバイスのまま利用することもあります。
まとめ
ディスクは、OSに認識され、使用可能とされるまでの間に容量が目減りしていきます。RAID装置のボリュームをそのまま利用する場合と、ソフトウェアボリュームを使う場合があることも説明しました。
ファイルシステムによっても容量が減少します。
ストレージで初期に設定したボリュームサイズから、目減りした結果の実効容量を把握しておかなければ、設計フェーズで容量不足の原因を生み出してしまうことになりかねないので注意しましょう。