31.3. データ効率のテスト手順
VDO の検証が成功するかどうかは、適切に設定されたテスト手順に従うかどうかにかかっています。このセクションでは、評価に参加する際に考慮すべきテストの例として、期待される結果とともに従うべき一連の手順を示します。
テスト環境
次のセクションのテストケースでは、テスト環境を以下のように想定します。
- 1 つ以上の Linux 物理ブロックデバイスが使用できる。
- ターゲットブロックデバイス（例：
/dev/sdb）が 512 GB を超える。 - 柔軟な I/O テスター(
fio)バージョン 2.1.1 以降がインストールされている。 - VDO がインストールされている。
テスト環境を完全に把握するために、各テストの開始時に以下の情報を記録する必要があります。
- 使用される Linux ビルド (カーネルビルド番号を含む)。
- rpm -qa コマンドから取得した、インストールされているパッケージの完全なリスト。
- 完全なシステム仕様:
- CPU タイプと数量(
/proc/cpuinfoで入手可能) - インストールされたメモリーと、ベース OS の実行後に利用可能な量(
/proc/meminfoで使用可能)。 - 使用されているドライブコントローラーのタイプ
- 使用されているディスクのタイプと数量
- 実行中のプロセスの完全なリスト( ps aux など)。
- VDO で使用するために作成された物理ボリュームおよびボリュームグループの名前(pvs および vgs の一覧)。
- VDO ボリューム (存在する場合) のフォーマットに使用されるファイルシステム。
- マウントされたディレクトリーの権限。
/etc/vdoconf.yamlの内容。- VDO ファイルの場所。
sosreport を実行すると、必要な多くの情報を取得できます。
ワークロード
VDO を効果的にテストするには、実際のワークロードをシミュレートするデータセットを使用する必要があります。データセットは、さまざまな条件下でのパフォーマンスを実証するために、重複排除や圧縮が可能なデータと可能でないデータの間のバランスを提供する必要があります。
繰り返し可能な特性を持つデータを合成して生成できるツールがいくつかあります。テスト中の使用には、特に VDbench および
fio の 2 つのユーティリティーの使用が推奨されます。
本ガイドでは、
fio を使用します。評価を成功させるためには、引数を理解することが重要です。
| 引数 | 説明 | 値 |
|---|---|---|
--size | fio がジョブごとにターゲットに送信するデータの量 (以下の numjobs を参照)。 | 100 GB |
--bs | fio が生成する各読み取り/書き込み要求のブロックサイズ。Red Hat は、デフォルトの 4KB の VDO と一致する 4KB のブロックサイズを推奨します。 | 4k |
--numjobs |
fio がベンチマークを実行するために作成するジョブの数。
各ジョブは、
--size パラメーターで指定した量のデータを送信します。
1 番目のジョブは、
--offset パラメーターで指定したオフセットでデバイスにデータを送信します。後続のジョブでは、--offset_increment パラメーターが指定されていない限り、ディスクの同じ領域に書き込みます (上書き)。これは、前のジョブがその値で開始した場所からそれぞれのジョブをオフセットします。フラッシュメモリーでピークパフォーマンスを実現するには、最低 2 つのジョブが推奨されます。通常、1 つのジョブで、ローテーションを行うディスク (HDD) のスループットをいっぱいにできます。
|
1 (HDD)
2 (SSD)
|
--thread | fio ジョブをフォークするのではなく、スレッドで実行するように指示します。これにより、コンテキストスイッチを制限することでパフォーマンスが向上する可能性があります。 | <N/A> |
--ioengine |
Linux では、fio を使用してテストできる I/O エンジンが複数あります。Red Hat テストでは、非同期のバッファーなしエンジン (
libaio) が使用されます。別のエンジンに興味がある場合は、Red Hat セールスエンジニアに相談してください。
Linux
libaioエンジンは、1 つ以上のプロセスが同時にランダムな要求を行っているワークロードを評価するために使用されます。libaio は、データが取得される前に、単一のスレッドから複数のリクエストを非同期で作成できるようにします。これにより、リクエストが同期エンジンを介して多くのスレッドによって提供された場合に必要となるコンテキストスイッチの数が制限されます。
| libaio |
--direct |
設定すると、direct は、Linux カーネルのページキャッシュをバイパスしてデバイスにリクエストを送信できるようにします。
Libaio Engine:
libaio は、direct を有効 (=1) にして使用する必要があります。そうしないと、カーネルが、すべての I/O 要求で sync API に頼る可能性があります。
| 1 (libaio) |
--iodepth |
任意の時点で実行している I/O バッファーの数。
通常、高い
iodepth の場合、無作為な読み取りまたは書き込みのパフォーマンスが向上します。深度が高い場合は、コントローラーは常にバッチ処理を要求できます。ただし、iodepth を高く設定しすぎる (通常は 1K を超える) と、望ましくないレイテンシーが発生する場合があります。Red Hat は、128 から 512 までの iodepth を推奨していますが、最後の値はトレードオフであり、アプリケーションがレイテンシーを許容する方法によって異なります。
| 128 (最小値) |
--iodepth_batch_submit | iodepth バッファープールが空になり始めるときに作成される I/O の数。このパラメーターは、テスト中の I/O からバッファー作成へのタスクの切り替えを制限します。 | 16 |
--iodepth_batch_complete | 一括処理 (iodepth_batch_complete) を送信するまでに完了する I/O の数。このパラメーターは、テスト中の I/O からバッファー作成へのタスクの切り替えを制限します。 | 16 |
--gtod_reduce | レイテンシーを計算する時刻の呼び出しを無効にします。この設定は、無効 (=0) にするとスループットが低下するため、レイテンシー測定が必要でない限り有効 (=1) にしてください。 | 1 |
31.3.1. VDO テストボリュームの設定
1.512GB の物理ボリュームに、論理サイズが 1TB の VDO ボリュームを作成する
- VDO ボリュームを作成します。
- 同期ストレージで VDO の
asyncモードをテストするには、--writePolicy=asyncオプションを使用して非同期ボリュームを作成します。# vdo create --name=vdo0 --device=/dev/sdb \ --vdoLogicalSize=1T --writePolicy=async --verbose - 同期ストレージで VDO
同期モードをテストするには、--writePolicy=syncオプションを使用して同期ボリュームを作成します。# vdo create --name=vdo0 --device=/dev/sdb \ --vdoLogicalSize=1T --writePolicy=sync --verbose
- 新しいデバイスを XFS または ext4 ファイルシステムでフォーマットします。
- XFS の場合:
# mkfs.xfs -K /dev/mapper/vdo0
- ext4 の場合:
# mkfs.ext4 -E nodiscard /dev/mapper/vdo0
- フォーマットしたデバイスをマウントします。
# mkdir /mnt/VDOVolume # mount /dev/mapper/vdo0 /mnt/VDOVolume && \ chmod a+rwx /mnt/VDOVolume
31.3.2. VDO の効率のテスト
2.VDO ボリュームの読み取りと書き込みのテスト
- VDO ボリュームに 32GB のランダムデータを書き込みます。
$ dd if=/dev/urandom of=/mnt/VDOVolume/testfile bs=4096 count=8388608
- VDO ボリュームからデータを読み込み、VDO ボリュームではない別の場所に書き込みます。
$ dd if=/mnt/VDOVolume/testfile of=/home/user/testfile bs=4096
diffを使用して、2 つのファイルを比較します。この場合、ファイルが同じであることが報告されます。$ diff -s /mnt/VDOVolume/testfile /home/user/testfile
- ファイルを VDO ボリュームの 2 番目の場所にコピーします。
$ dd if=/home/user/testfile of=/mnt/VDOVolume/testfile2 bs=4096
- 3 番目のファイルと 2 番目のファイルを比較します。これは、ファイルが同じであることを報告するはずです。
$ diff -s /mnt/VDOVolume/testfile2 /home/user/testfile
3.VDO ボリュームの削除
- VDO ボリュームに作成されたファイルシステムをアンマウントします。
# umount /mnt/VDOVolume
- コマンドを実行して、システムから VDO ボリューム
vdo0を削除します。# vdo remove --name=vdo0
- ボリュームが削除されたことを確認します。VDO パーティションの vdo リストにはリスト がないはずです。
# vdo list --all | grep vdo
4.重複排除の計測
- 「VDO テストボリュームの設定」に従って、VDO ボリュームを作成してマウントします。
vdo1からvdo10までの VDO ボリュームに 10 個のディレクトリーを作成し、テストデータセットのコピーを 10 個保持します。$ mkdir /mnt/VDOVolume/vdo{01..10}- ファイルシステムに応じて使用されているディスク領域を調べます。
$ df -h /mnt/VDOVolume Filesystem Size Used Avail Use% Mounted on /dev/mapper/vdo0 1.5T 198M 1.4T 1% /mnt/VDOVolume
結果をリストまとめることを検討してください。統計 ベアファイルシステム シード後 10 回コピーした後 使用されるファイルシステムのサイズ 198 MB 使用されている VDO データ 使用されている VDO 論理 - 次のコマンドを実行して、値を記録します。"Data blocks used" は、VDO で実行している物理デバイスのユーザーデータが使用しているブロック数です。"Logical blocks used" は、最適化前に使用したブロック数になります。これは、計測の開始点として使用されます。
# vdostats --verbose | grep "blocks used" data blocks used : 1090 overhead blocks used : 538846 logical blocks used : 6059434
- VDO ボリュームのトップレベルに、データソースファイルを作成します。
$ dd if=/dev/urandom of=/mnt/VDOVolume/sourcefile bs=4096 count=1048576 4294967296 bytes (4.3 GB) copied, 540.538 s, 7.9 MB/s
- 使用中の物理ディスク領域の量を再度調べます。これは、ちょうど書き込まれたファイルのサイズに応じて、使用されているブロック数の増加を示しているはずです。
$ df -h /mnt/VDOVolume Filesystem Size Used Avail Use% Mounted on /dev/mapper/vdo0 1.5T 4.2G 1.4T 1% /mnt/VDOVolume
# vdostats --verbose | grep "blocks used" data blocks used : 1050093 (increased by 4GB) overhead blocks used : 538846 (Did not change) logical blocks used : 7108036 (increased by 4GB)
- 10 個のサブディレクトリーのそれぞれにファイルをコピーします。
$ for i in {01..10}; do cp /mnt/VDOVolume/sourcefile /mnt/VDOVolume/vdo$i done - 再度、使用されている物理ディスク領域 (使用されているデータブロック) の量を確認します。この数は、ファイルシステムのジャーナリングとメタデータによるわずかな増加を除いて、上記手順 6 の結果と類似している必要があります。
$ df -h /mnt/VDOVolume Filesystem Size Used Avail Use% Mounted on /dev/mapper/vdo0 1.5T 45G 1.3T 4% /mnt/VDOVolume
# vdostats --verbose | grep "blocks used" data blocks used : 1050836 (increased by 3M) overhead blocks used : 538846 logical blocks used : 17594127 (increased by 41G)
- テストデータを書き込む前に見つかった値から、ファイルシステムが使用する領域の値を減算します。これは、ファイルシステムの観点から、このテストで使用される領域の量です。
- 記録された統計で節約する容量を確認します。注記:次の表では、値は MB/GB に変換されています。vdostats の "blocks" は 4,096 B です。
統計 ベアファイルシステム シード後 10 回コピーした後 使用されるファイルシステムのサイズ 198 MB 4.2 GB 45 GB 使用されている VDO データ 4 MB 4.1 GB 4.1 GB 使用されている VDO 論理 23.6 GB* 27.8 GB 68.7 GB 1.6TB フォーマットドライブ用のファイルシステムのオーバーヘッド
5.圧縮の測定
- 物理サイズおよび論理サイズが 10GB 以上の VDO ボリュームを作成します。重複排除を無効にし、圧縮を有効にするオプションを追加します。
# vdo create --name=vdo0 --device=/dev/sdb \ --vdoLogicalSize=10G --verbose \ --deduplication=disabled --compression=enabled - 転送前に VDO 統計を確認します。使用されているデータブロックと論理ブロックを書き留めておきます (両方ともゼロにする必要があります)。
# vdostats --verbose | grep "blocks used"
- 新しいデバイスを XFS または ext4 ファイルシステムでフォーマットします。
- XFS の場合:
# mkfs.xfs -K /dev/mapper/vdo0
- ext4 の場合:
# mkfs.ext4 -E nodiscard /dev/mapper/vdo0
- フォーマットしたデバイスをマウントします。
# mkdir /mnt/VDOVolume # mount /dev/mapper/vdo0 /mnt/VDOVolume && \ chmod a+rwx /mnt/VDOVolume
- VDO ボリュームを同期して、未完了の圧縮を完了します。
# sync && dmsetup message vdo0 0 sync-dedupe
- VDO 統計を再検証します。使用されている論理ブロック - 使用されているデータブロックは、ファイルシステム単体の圧縮により保存されている 4KB ブロックの数になります。VDO は、ファイルシステムのオーバーヘッドと、実際のユーザーデータを最適化します。
# vdostats --verbose | grep "blocks used"
/libのコンテンツを VDO ボリュームにコピーします。合計サイズを記録します。# cp -vR /lib /mnt/VDOVolume ... sent 152508960 bytes received 60448 bytes 61027763.20 bytes/sec total size is 152293104 speedup is 1.00
- Linux キャッシュと VDO ボリュームを同期します。
# sync && dmsetup message vdo0 0 sync-dedupe
- VDO 統計を再検証します。使用されている論理ブロックおよびデータブロックを確認します。
# vdostats --verbose | grep "blocks used"
- 使用されている論理ブロック - 使用されるデータブロックは、
/libファイルのコピーに使用されるスペースの量(4 KB ブロック単位)を表します。 - 合計サイズ (「4.重複排除の計測」 の表から) - (使用される論理-使用されるデータブロック * 4096) = 圧縮により節約されたバイト数
- VDO ボリュームを削除します。
# umount /mnt/VDOVolume && vdo remove --name=vdo0
6.VDO 圧縮の効率のテスト
- 「VDO テストボリュームの設定」に従って、VDO ボリュームを作成してマウントします。
- 用意したデータセットを試します。
7.TRIM および DISCARD について
シンプロビジョニングにより、論理ストレージまたは仮想ストレージ領域を基盤の物理ストレージよりも大きくすることができます。ファイルシステムなどのアプリケーションは、ストレージのより大きな仮想層で実行すると利点があります。データの重複排除などのデータ効率化技術は、すべてのデータを保存するために必要な物理データブロックの数を減らします。このストレージ削減効果を活用するには、物理ストレージ層が、アプリケーションデータが削除されたタイミングを把握する必要があります。
従来のファイルシステムでは、データが削除されたときに基礎となるストレージに通知する必要はありませんでした。シンプロビジョニングされたストレージと連携するファイルシステムは、論理ブロックが不要になったときにストレージシステムに通知するために、
TRIM コマンドまたは DISCARD コマンドを送信します。これらのコマンドは、discard マウントオプションを使用してブロックが削除されるたびに送信できます。または、fstrim などのユーティリティーを実行して、どの論理ブロックが使用されていないかを検出し、TRIM または DISCARD コマンドの形式でストレージシステムに情報を送信するようにファイルシステムに指示することで、制御された方法でこれらのコマンドを送信できます。
重要
シンプロビジョニングの仕組みに関する詳細は、『Red Hat Enterprise Linux 7 Logical Volume Manager Administration Guide』のThinly-Provisioned Logical Volumes (Thin Volumes)を参照してください。
これがどのように機能するかを確認するには、以下を実行します。
- 「VDO テストボリュームの設定」 に従って、新しい VDO 論理ボリュームを作成してマウントします。
- ファイルシステムをトリミングして、不要なブロックを削除します (これには長い時間がかかる場合があります)。
# fstrim /mnt/VDOVolume
- 以下を入力して、以下の表に初期状態を記録します。
$ df -m /mnt/VDOVolume
ファイルシステムで使用されている容量を確認し、vdostats を実行して、使用されている物理データブロックと論理データブロックの数を確認します。 - VDO 上で実行中のファイルシステムに、重複しないデータを含む 1 GB ファイルを作成します。
$ dd if=/dev/urandom of=/mnt/VDOVolume/file bs=1M count=1K
次に、同じデータを収集します。ファイルシステムはさらに 1GB を使用する必要があり、使用されるデータブロックと使用される論理ブロックも同様に増加しました。 fstrim /mnt/VDOVolumeを実行し、新しいファイルの作成後に、これが影響を与えないことを確認します。- 1 GB ファイルを削除します。
$ rm /mnt/VDOVolume/file
パラメーターを確認し、記録します。ファイルシステムは、ファイルが削除されたことを認識していますが、ファイルの削除が基礎となるストレージに通知されていないため、物理ブロックまたは論理ブロックの数に変更がありませんでした。 fstrim /mnt/VDOVolumeを実行し、同じパラメーターを記録します。fstrimは、ファイルシステムの空きブロックを検索し、未使用のアドレスの VDO ボリュームに TRIM コマンドを送信します。これにより、関連する論理ブロックが解放され、VDO が TRIM を処理して基礎となる物理ブロックを解放します。Step 使用されているファイル領域 (MB) 使用されているデータブロック 使用されている論理ブロック 初期 1 GB ファイルを追加 fstrimを実行1 GB ファイルを削除 fstrimを実行
この演習では、TRIM プロセスが必要で、基礎となるストレージが容量の使用率について正確な知識を持つことができます。
fstrim は、多くのブロックを一度に分析して効率を向上させるコマンドラインツールです。別の方法として、マウント時に file system discard オプションを使用する方法があります。discard オプションは、各ファイルシステムブロックの削除後に基礎となるストレージを更新します。これによりスループットは遅くなりますが、使用率認識度は高くなります。未使用のブロックを TRIM または DISCARD する必要性は、VDO に固有のものではないことを理解することも重要です。シンプロビジョニングされたストレージシステムにも同じ課題があります。
