Show Table of Contents
30.3. データ効率のテスト手順
以下の詳細なテスト手順に従うことで、VODO の検証を正しく行うことができます。このセクションでは、想定される結果とともに一連の手順を説明します。これは、評価を行うタイミングを図るテストの一例としても参照できます。
テスト環境
次のセクションのテストケースでは、テスト環境を以下のようなものと仮定します。
- 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 は、テスト中の使用におすすめです。
このガイドでは
fioを使用します。評価を成功させるには、引数の理解が不可欠です。
表30.1 fio オプション
| 引数 | 説明 | 値 |
|---|---|---|
--size | データ fio のサイズがジョブごとのターゲットに送信されます (以下の numjobs を参照)。 | 100 GB |
--bs | fio によって生成される各読み書きリクエストのブロックサイズ。Red Hat では、VOD の 4 KB デフォルトに一致するように 4 KB ブロックサイズを推奨しています。 | 4k |
--numjobs |
fio がベンチマークを実行するために作成するジョブの数。
各ジョブは、
--size パラメーターで指定されたデータの量を送信します。
最初のジョブは、
--offset パラメーターで指定したオフセットで、デバイスにデータを送信します。後続のジョブは、--offset_increment パラメーターが指定されていない限り、ディスクの同じ領域を書き込みます (上書き)。これにより、以前のジョブがその値によって開始された各ジョブがオフセットされます。フラッシュでパフォーマンスを最大限まで引き出すには、最低でも 2 つのジョブが必要です。回転ディスク (HDD) スループットのサチュレートには、1 つのジョブで十分です。
|
1 (HDD)
2 (SSD)
|
--thread | fio ジョブに、フォークされるのではなく、スレッドで実行するように命令します。これにより、コンテキストスイッチを制限することでパフォーマンスを向上できる可能性があります。 | <N/A> |
--ioengine |
Linux では、複数の I/O エンジンを利用できます。これは、fio を使用してテストできます。Red Hat のテストでは、非同期のバッファなしのエンジンを使用します (
libaio)。別のエンジンについては、Red Hat セールスエンジニアまでご相談ください。
Linux
libaio エンジンは、1 つ以上のプロセスがランダムなリクエストを同時に行うワークロードを評価するのに使用されます。libaio では、データが取得される前に、単一のスレッドから非同期的に複数のリクエストを作成できます。これにより、リクエストが同期的なエンジンから manythreads によって与えられる場合に必要となるコンテキストスイッチの数が制限されます。
| libaio |
--direct |
これを設定すると、Linux カーネルのページキャッシュをバイパスするデバイスにリクエストを送信できるようになります。
Libaio エンジン:
libaio は、direct を有効化 (=1) して使う必要があります。または、カーネルは、すべての I/O リクエストの sync AIPI にリゾートすることがあります。
| 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 | バッチを送信する前に完了する I/O の数 (iodepth_batch_complete)。このパラメーターは、テスト中の I/O からバッファー生成を切り替えるタスクを制限します。 | 16 |
--gtod_reduce | レイテンシーを計算するために時刻の呼び出しを無効化します。この設定が有効化されると (=0) スループットが低減します。レイテンシー測定が必要な場合を除き、有効化 (=1) してください。 | 1 |
30.3.1. VDO テストボリュームの設定
1. 512 GB の物理ボリューム上で、論理サイズ 1 TB で VDO ボリュームを作成します
- VDO ボリュームを作成します。
- 同期ストレージのトップ上で VDO
asyncモードをテストするには、--writePolicy=asyncオプションを指定して非同期ボリュームを作成します。# vdo create --name=vdo0 --device=/dev/sdb \ --vdoLogicalSize=1T --writePolicy=async --verbose - 同期ストレージ上で VDO
syncモードをテストするには、--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
30.3.2. VDO 効率のテスト
2. VDO ボリュームへの読み書きテスト
- 32 GB のランダムデータを VDO ボリュームに書き込みます。
$ 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 listには、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 論理 - 以下のコマンドを実行して値を記録します。「使用済みデータブロック」は、VDO 下で実行している物理デバイス上のユーザーデータによって使用されているブロック数です。「使用済み論理ブロック」は、最適化前に使用したブロックの数です。これは、測定の開始地点として使用されます。
# vdostats --verbose | grep "blocks used" data blocks used : 1090 overhead blocks used : 538846 logical blocks used : 6059434
- VOD ボリュームのトップレベルでのデータソースファイルの作成
$ 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 ”ブロック” は 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.6 TB フォーマットドライブのファイルシステムオーバーヘッド
5. 圧縮の測定
- 最低でも 10 GB の物理サイズ、論理サイズの VDO ボリュームを作成します。重複排除を無効化して圧縮を有効にするオプションを追加します。
# vdo create --name=vdo0 --device=/dev/sdb \ --vdoLogicalSize=10G --verbose \ --deduplication=disabled --compression=enabled - 転送する前に VDO 統計を調べます。使用しているデータブロックと論理ブロックをメモします (両方とも 0)。
# 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 統計を調べます。使用論理ブロックと使用データブロックは、ファイルシステムのみの圧縮で節約した 4 KB ブロックの数です。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 Zと DISCARD について
シンプロビジョニングでは、基礎となる物理ストレージよりも論理ストレージ容量または仮想ストレージ容量を大きくできます。ファイルシステムなどのアプリケーションは、より大きな仮想レイヤーのストレージで実行できるといったメリットを得ることができます。また、データ重複排除などのデータ効率技術により、すべてのデータを保存する必要があった物理的なブロックの数を減らすことができます。これらのストレージ節約からメリットを得るには、物理ストレージ層が、アプリケーションデータが削除されたときを把握する必要があります。
従来のファイルシステムは、データが削除されたときに、基礎となるストレージに通知を行う必要はありませんでした。シンプロビジョニングしたストレージを扱うファイルシステムは、
TRIM または DISCARD コマンドを送信して、論理ブロックが不要になった際にストレージシステムに通知します。これらのコマンドは、ブロックが dscard マウントオプションを指定して削除されれば送信できます。または、これらのコマンドは、使用されていない論理ブロックを検出し、TRIM または DISCARD コマンドという形式で、ストレージシステムに情報を送信するようにファイルシステムに命令する fstrim などのユーティリティを実行することで統制下で送信できます。
仕組みは、以下の手順に従うことで見ることができます。
- 「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
そして、同じデータを収集します。ファイルシステムは、さらに 1 GB を使用しているはずです。また、使用したデータブロックや論理ブロックは同じように増大します。 fstrim /mnt/VDOVolumeを実行して、新しいファイルを作成後にも影響がないことを確認します。- 1 GB ファイルを削除します。
$ rm /mnt/VDOVolume/file
パラメーターを確認して記録します。ファイルシステムは、ファイルが削除されたことを認識してますが、物理ブロックや論理ブロックの数に変更はありません。これは、ファイル検出が、基礎となるストレージに通信していないためです。 fstrim /mnt/VDOVolumeを実行して、同じパラメーターを記録します。fstrimは、ファイルシステムの空きブロックを検索し、TRIM コマンドを、使用していないアドレスの VDO ボリュームに送信します。これにより、関連の論理ブロックがリリースされ、VDO が TRIM を処理し、基礎となる物理ブロックがリリースされます。ステップ 使用されるファイル容量 (MB) 使用されているデータブロック 使用されている論理ブロック Initial 1 GB ファイルの追記亜 fstrimの実行1 GB ファイルの削除 fstrimの実行
この演習から、TRIM プロセスが必要であるため、基礎となるストレージが使用容量を正確に把握できます。
fstrim は、より効率を高めるために 1 度に多くのブロックを解析するコマンドラインツールです。代替の方法としては、マウントの際にファイルシステム discard オプションを使用することが考えられます。この破棄 (discard) オプションは、各ファイルシステムのブロックが削除された後に基礎となるストレージを更新します。これにより、スループットの速度が低減する可能性がありますが、使用率をより正確に把握できます。また、TRIM または DISCARD する必要があることが VDO に限らないということを理解することが重要です。すべてのシンプロビジョニングしたストレージシステムが同じ課題を抱えています。