KuriKumaChan’s diary

Kuri ちゃんと Kuma ちゃんの飼い主の独り言

QNAP NAS の ボリュームタイプ変更 (1) - 復習と現状の再確認

QNAP では 3種類(Static, Thick, Thin)のボリュームタイプがサポートされていて、NAS のセットアップの時点でどれかのタイプを利用するのか指定しなくてはなりません。これらに関する情報は決して少なくはないのですが、今ひとつ「しっかり納得できた」感が薄く、「とりあえず設定してみた」、と言うレベルで使っている人も多いのではないかと思います。そういう私自身も前の TS-431p の頃から「とりあえず設定してみた」まま使い続けていています。もちろん個人的な利用であればアクセス頻度もアクセス人数も極めて限定的なのでそうそう大きな差が出てることでは無いのでしょう。
たまたま今回 NAS のひとつのボリュームの容量が若干不安になっているので、HDD の容量アップもしくはボリュームタイプをもう少し腹落ちするまで理解した上で場合によっては思い切ってボリュームタイプの変更も考えてみようと思います。
なお、QNAP の資料をベースにしていますが、ここで登場する "Storage pool" や "Thin provisioning" という概念は QNAP 独自のものでは無く、Windows をはじめとする各種サーバーシステム、ストレージシステムでは現在標準的に提供されている機能のようです。もしもっと調べたいという QNAP ユーザーの方がいらっしゃいましたら、検索時に敢えて "QNAP" という単語を入れずに検索した方が沢山の情報に接することができます。

今回は一部用語をあえて日本語訳を使わず英文表記のまま使っている部分があります。これは QNAP に限りませんが、日本語訳に一貫性が無かったりするためです。
また、ここではディスク」という用語を HDD/SSD を含めた物理的なディスクドライブの総称として使うことにします。

基本的な用語の再確認 - 「ストレージプール」の理解が最重要!

一通り調べてから考え直してみると、二つの用語が明確になると理解が早まりそうですので最初にまとめておきます。以下の説明と合わせて、この後いくつか掲載している図を参照いただけるとわかりやすいかと思います。

「ボリューム」

  • いわゆる「ボリューム」として Finder / explorer で人間がファイルやディレクトリにアクセスする際に直接参照する対象ですね(Windows では「ドライブレター」で表す「ドライブ」のことですがここではボリュームという名称で統一します。)。システム上の設定としては、ボリューム単位で各種ファイルシステムを使ったフォーマットをした上でファイルを作成するのはパソコンも NAS も皆共通なことです。

  • ここでのポイントは、ドライブをどこに作成(配置)するかがポイントになります。

    • 一番シンプルな構成ではディスク一つを丸々一つのドライブに設定することですが、パソコンでは必要に応じて一つのディスクを論理的に分割して「データ用ボリューム(ドライブ)」など複数のボリューム(ドライブ)を作成することもできます。
    • しかし、通常複数のディスクをまたがったドライブを作成することはできません。そこでドライブをディスクではなく、次のストレージプールにボリュームを作成することでディスクやその容量を意識しなくても良くなります。

「ストレージプール」

  • これはパソコンには無い概念です。ひとつ以上複数のディスク・RAIDグループ(RAID構成をした論理的なドライブをここではRAIDグループと呼ぶことにします)をまとめたものを「一つのストレージプール」という一まとまりの記憶領域として設定することができます。それぞれのディスクや RAID グループの容量を超えた連続した記憶域として扱えるので、スペース効率が向上します

3種類のボリュームタイプ

いちばんわかりやすかった資料は QNAP のこちらの資料で、一覧表もあって網羅的に整理されていると思いますが、ポイントだけ先にまとめておきます。一覧表は最後に参考資料として転載させていただきました。

Static volume(静的ボリューム)

  • 一番シンプルで私たちがパソコンなどで接することが多いタイプで、ディスクもしくは RAID グループに直接作成します。それゆえ最大容量はディスクもしくは RAID グループの容量が上限となります。同時にディスク内に空きスペースがあったとしても他のディスクに作成されたドライブが使うことはできません。

  • 容量は最初に作成した時点の容量が確保されます。

  • 残りの二つで提供されるような高度な機能はありません。

  • ボリューム自体のパフォーマンスは他の二つより高速です。(逆に言えば他の二つは高機能にするオーバーヘッドがあると言うことですね。)

Thick volume(シックボリューム)

  • Thick と Thin はいずれも「事前にひとつ以上のディスクもしくは RAID グループに作成したストレージプール上に作成する」ので、物理的な単体ディスク容量を超えたスペースも利用可能です。Thich, Thin を合わせて "Flexible Volumes" と呼び、容量のメリット以外にも QNAP では smapshot, Qtier などの高機能なオプションが利用可能となります。

  • Thick と Thin は双方向で変換が可能。

  • Thick はあらかじめストレージプールに設定した容量のスペースを占有します。

  • パフォーマンスは QNAP の資料では Thick は Thin に比べて "slightly better" としています。

Thin volume(シンボリューム)

  • Thin の最大の特徴は実際に書き込まれたデータのサイズしか消費しないということです("thin provisioning")。

  • Thin ではボリュームサイズをストレージプールの容量を超えて設定することができます("over-allocation")。ただしこれは設定だけの話であって、10TB のプールに 20TB のデータを格納できるわけではなく、管理者は実際のスペース使用状況をモニターして適切な対応を取る必要があることには変わりません。これはおそらくパーソナルユースではほとんどメリットにはならないと思いますが、複数のユーザー(部門)があるような環境でストレージの管理者がいる場合には最大限のスペース柔軟性を得られるのでしょう。

www.qnap.com

わかりやすい図は

図で理解するのが一番良いと思うのですが、全体を網羅的に一枚の図で説明しているものは見当たりませんでしたが、基本となるストレージプールの位置付けがわかりやすいのは QNAP の YouTube で使われていたものです。 この図の最大のポイントは、

  • static volume は HDD/SSD(/RAID) 上に直接作成される

  • HDD/SSD(/RAID) 上にストレージプールを作成しその上に Thick/Thin volume を作成することで、Thick/Thin volume は直接 HDD/SSD(/RAID) を意識しなくて良い/制約から解放される

と言うことです。

QNAP の YouTube で用いられていた一番シンプルなチャート

他のサーバーシステムでは

他のサーバーシステムの資料を見ていると、ストレージプールの中にストレージプールを作成できたり、Thick にも種類があったりと、世の中色々な高機能化が進んでいるようです。これも SSD をはじめとするキャッシュやプロセッサ能力の向上に因るものなのでしょうね。個人ユースでは QNAP の機能でも使いきれない感じですが。

私の現状の構成

現在は static と Thick の併用

改めて自分の TS-453Be での設定状況を確認してみます。
最初にドライブと RAID 構成を確認すると、4台の 3TB の HDD を 2台ずつ二つの RAID 1 のグループに設定しています。

4台の ディスク で "RAID 1" 構成の「RAIDグループ」を二つ設定
RAIDグループ2 にはストレジプールを設定しボリュームはシックの設定

ボリュームタイプとしては、Static と Thick を使っています。「なぜ?」と聞かれてもあまり積極的な理由は多分無かったはずで、「自分が一番馴染んでいて一番高速」な static と、「QNAP が色々と高機能をアピールしているタイプもひとつ使っておくか」ぐらいで選んだと思います。

パフォーマンスは本当に違うの?

今までのキャッシュ化/10GbE に関するパフォーマンス測定は "Blackmagic Disk Speed Test" を使っていました。これは見た目はカッコイイのですが、メーターが示す瞬間の状態しか得られないので、スクリーンショットを撮るタイミングの情報しか残せませんでした。ただ実感としては static volume で測定したほうが 5% くらい高速だったと認識していて、今までのスクリーンショット大半が static で測定したものを載せていたと思います。
しかしもう少し数字でちゃんと測定/記録したいと考え、"AmorphousDiskMark" という Windows のツールに似た雰囲気のツールを導入して再測定してみました。
測定結果をざっくり言うと、「Sequential write で数% static が早いがその他はほぼ同等。体感上の差は無し。」と言う感じだと思います。volume の特性があってもキャッシュの効果がそれを打ち消しているのかもしれません。

static volume の結果

Thick volume の結果

static volume の結果 2

Thick volume の結果 2

念のためそれぞれの HDD のモデルも書いておきます。

モデル 容量
HDD 1 WD30EFRX-68EUZN0 2.73 TB (3 TB)
HDD 2 WD30EFRX-68EUZN0 2.73 TB (3 TB)
HDD 3 WD30EFAX-68JH4N0 2.73 TB (3 TB)
HDD 4 WD30EFRX-68EUZN0 2.73 TB (3 TB)

と言うことで、私の理解のポイントとしては以下の通りです。

  1. ストレージプールを設定するか否かがスペース効率と各種機能利用の分かれ道

  2. 最高速の static でもキャッシュ利用の元では体感するような差は無い

この認識のもと、次回 HDD 交換と新しい構成を考えたいと思います。


参考)ボリュームタイプの比較表

出典はこちら

Static Thick Thin
Summary Best overall read/write performance, but does not support most advanced features Good balance between performance and flexibility Enables you to allocate storage space more efficiently
Read/write speed Fastest for random writes Good Good
Flexibility Inflexible
A volume can only be expanded by adding extra drives to the NAS.
Flexible
A volume can easily be resized.
Very flexible
A volume can be resized. Also unused space can be reclaimed and added back into the parent storage pool.
Parent storage space RAID group Storage pool Storage pool
Volumes allowed in parent storage space One One or more One or more
Initial size Size of the parent RAID group User-specified Zero
Storage pool space is allocated on-demand, as data is written to the volume. This is called thin provisioning.
Maximum size Size of the parent RAID group Size of the parent storage pool Twenty times the amount of free space in the parent storage pool
The size of a thin volume can be greater than that of its parent storage pool. This is called over-allocation.
Effect of data deletion Space is freed in the volume Space is freed in the volume QTS can reclaim the space and add it back into the parent storage pool.
Method of adding storage space Add disks to the NAS
Replace existing disks with higher capacity disks
Allocate more space from the parent storage pool Allocate more space from the parent storage pool
Snapshot support (fast backup and recovery) No Yes Yes
Qtier (automatic data tiering) support No Yes Yes