シンプロビジョニングとは、最初は少しのスペースを使用し、データが書き込まれると「成長」する論理ボリュームの作成です。 ZFSでは、このFSの哲学により、これが長い間実装されてきました。 VMwareでは、これはすべての製品で使用されます。 今日、Linuxで広く使用されているLVM2が登場しました。 また、主要な革新の1つは、スナップショットを事前に予約する必要がないシンスナップショットですが、変更されたデータとともに「成長」します。 パフォーマンスの低下がないことを宣言しながら、ネストされたスナップショット（任意の深さのスナップショットのスナップショット）も許可および推奨されます。 使用のいくつかのニュアンスについては、記事で説明します。
安定した動作のために、LVM2のシンプロビジョニングには3.4カーネルが必要です。 Red Hatでは、バックポートされ、「クラシック」2.6.32で実行されます。
Debian Wheezyシンプロビジョニングは、lvm2 --with-thin = internalおよびその他の問題をコンパイルするときにキーが不足しているため利用できません。 必要に応じて、テストの目的で、このパッケージをソースからコンパイルできます。
スナップショットではなく、サーバーで使用する「シン論理ボリューム」のパフォーマンスに興味がありました。 せっかちな人のために、私はすぐに言います-生産性の低下が観察され、重要なものです。 以下の詳細。
mdadmを使用して作成されたRAID1上のCentOS 6.4 2.6.32-279.2.1.el6.x86_64と同じサーバーで、「シンプール」を作成します。
lvcreate -L 50G -T /dev/VG/thin_pool
および通常の論理ボリューム（LV）：
lvcreate -L 50G /dev/VG/thick_vol
これらのデバイスへの線形読み取りおよび書き込みのパフォーマンスを測定します。
シンプール：
記録：
dd if=/dev/zero of=/dev/mapper/VG-thin_pool bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 15.9126 s, 65.9 MB/s
読書：
dd if=/dev/mapper/VG-thin_pool of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.19247 s, 250 MB/s
LV：
-記録：
FIO: : iodepth=2, bw=943120 B/s, iops=230, avg=8645.48 usec
# dd if=/dev/zero of=/dev/VG/thick_vol bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 15.8432 s, 66.2 MB/s
-読書：
FIO: : iodepth=2, bw=775490 B/s, iops=189, avg=10536.95 usec
# dd if=/dev/VG/thick_vol of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.04925 s, 259 MB/s
ご覧のとおり、LVとシンプールのパフォーマンスに違いはありません。
シンプールにシンボリュームを作成する
lvcreate -V 100G -T -n thin_vol /dev/mapper/VG-thin_pool
パフォーマンスを確認します。
記録：
FIO: : iodepth=2, bw=1100.5KB/s, iops=275, avg=7241.55 usec
dd if=/dev/zero of=/dev/mapper/VG-thin_vol bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 38.7505 s, 27.1 MB/s
読書：
FIO: : iodepth=256, bw=86100KB/s, iops=21524, avg=11860.53 usec
dd if=/dev/mapper/VG-thin_vol of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.45363 s, 235 MB/s
シンボリュームでの線形記録が通常のLVの2倍遅いことは非常に明らかです（27.1 MB / s対66.2 MB / s）。 同時に、ランダムな書き込み速度も向上し、ランダムな読み取りでは実際のパフォーマンスを測定することはまったくできませんでした。キャッシュからの読み取りレベルのみが表示され、キャッシュのリセットは役に立ちませんでした。
リニアレコーディングのパフォーマンスの低下は驚くべきものであり、これはmdadmのRAID1の存在による可能性があるため、別のマシンでテストし、ファイルシステムレベルでパフォーマンスを調べる必要がありました。 VMware Workstation Debian Wheezy 7.3 3.10-0.bpo.3-amd64仮想マシンSSDドライブ。
パフォーマンスを確認します。
LV：
記録：
dd if=/dev/zero of=/delete.img bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 3.49623 s, 300 MB/s
読書：
FIO: : iodepth=384, bw=158839KB/s, iops=39709, avg= 9.64 msec
dd if=/delete.img of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 2.31352 s, 453 MB/s
シンLV：
記録：
dd if=/dev/zero of=/mnt/thin/delete.img bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 7.15546 s, 147 MB/s
読書：
FIO: : iodepth=384, bw=176574KB/s, iops=44143, avg=8675.36 usec
dd if=/mnt/thin/delete.img of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 2.33435 s, 449 MB/s
ランダム記録のパフォーマンスを測定できませんでした。
繰り返しますが、前のテストと同様に、リニア記録の速度が半分に低下します。 おそらくこれは、仮想マシンのニュアンスによるものです。
更新： RAIDと仮想マシンのない「クリーン」サーバーでもう1回テストを行いました。 ライン録音パフォーマンスの低下なし！ 最初の2回のテストにおけるテストの一方的な側面に関連して誤解を招く恐れのある聴衆に謝罪します。 その結果、特定のケースごとにパフォーマンスをテストする必要があると思います。
結果：
- いずれの場合もシンボリュームを使用する場合、たとえばmdadmとVMware仮想マシンを使用するRAID 1では、「クラシック」LVに比べてリニア記録の速度が2倍低下するため、リニア記録のパフォーマンスをテストする必要があります。
- 同時に、シンボリュームでのランダムな記録では、このような低下は見られず、速度はLVの場合と同じレベルです。
- Debianでは、標準リポジトリが不足しているため、本番環境ではまだ使用しません。