検索

31.3. データ効率のテスト手順

download PDF
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 を使用します。評価を成功させるためには、引数を理解することが重要です。
表31.1 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 ボリュームを作成する

  1. 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
      
  2. 新しいデバイスを XFS または ext4 ファイルシステムでフォーマットします。
    • XFS の場合:
      # mkfs.xfs -K /dev/mapper/vdo0
      
    • ext4 の場合:
      # mkfs.ext4 -E nodiscard /dev/mapper/vdo0
      
  3. フォーマットしたデバイスをマウントします。
    # mkdir /mnt/VDOVolume
    # mount /dev/mapper/vdo0 /mnt/VDOVolume && \
      chmod a+rwx /mnt/VDOVolume
    

31.3.2. VDO の効率のテスト

2.VDO ボリュームの読み取りと書き込みのテスト

  1. VDO ボリュームに 32GB のランダムデータを書き込みます。
    $ dd if=/dev/urandom of=/mnt/VDOVolume/testfile bs=4096 count=8388608
    
  2. VDO ボリュームからデータを読み込み、VDO ボリュームではない別の場所に書き込みます。
    $ dd if=/mnt/VDOVolume/testfile of=/home/user/testfile bs=4096
    
  3. diff を使用して、2 つのファイルを比較します。この場合、ファイルが同じであることが報告されます。
    $ diff -s /mnt/VDOVolume/testfile /home/user/testfile
    
  4. ファイルを VDO ボリュームの 2 番目の場所にコピーします。
    $ dd if=/home/user/testfile of=/mnt/VDOVolume/testfile2 bs=4096
    
  5. 3 番目のファイルと 2 番目のファイルを比較します。これは、ファイルが同じであることを報告するはずです。
    $ diff -s /mnt/VDOVolume/testfile2 /home/user/testfile
    

3.VDO ボリュームの削除

  1. VDO ボリュームに作成されたファイルシステムをアンマウントします。
    # umount /mnt/VDOVolume
  2. コマンドを実行して、システムから VDO ボリューム vdo0 を削除します。
    # vdo remove --name=vdo0
  3. ボリュームが削除されたことを確認します。VDO パーティションの vdo リストにはリスト がないはずです。
    # vdo list --all | grep vdo

4.重複排除の計測

  1. 「VDO テストボリュームの設定」に従って、VDO ボリュームを作成してマウントします。
  2. vdo1 から vdo10 までの VDO ボリュームに 10 個のディレクトリーを作成し、テストデータセットのコピーを 10 個保持します。
    $ mkdir /mnt/VDOVolume/vdo{01..10}
  3. ファイルシステムに応じて使用されているディスク領域を調べます。
    $ 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 論理   
  4. 次のコマンドを実行して、値を記録します。"Data blocks used" は、VDO で実行している物理デバイスのユーザーデータが使用しているブロック数です。"Logical blocks used" は、最適化前に使用したブロック数になります。これは、計測の開始点として使用されます。
    # vdostats --verbose | grep "blocks used"
    
    data blocks used                : 1090
    overhead blocks used            : 538846
    logical blocks used             : 6059434
    
  5. 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
    
  6. 使用中の物理ディスク領域の量を再度調べます。これは、ちょうど書き込まれたファイルのサイズに応じて、使用されているブロック数の増加を示しているはずです。
    $ 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)
    
  7. 10 個のサブディレクトリーのそれぞれにファイルをコピーします。
    $ for i in {01..10}; do
      cp /mnt/VDOVolume/sourcefile /mnt/VDOVolume/vdo$i
      done
    
  8. 再度、使用されている物理ディスク領域 (使用されているデータブロック) の量を確認します。この数は、ファイルシステムのジャーナリングとメタデータによるわずかな増加を除いて、上記手順 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)
    
  9. テストデータを書き込む前に見つかった値から、ファイルシステムが使用する領域の値を減算します。これは、ファイルシステムの観点から、このテストで使用される領域の量です。
  10. 記録された統計で節約する容量を確認します。
    注記:次の表では、値は MB/GB に変換されています。vdostats の "blocks" は 4,096 B です。
    統計ベアファイルシステムシード後10 回コピーした後
    使用されるファイルシステムのサイズ198 MB4.2 GB45 GB
    使用されている VDO データ4 MB4.1 GB4.1 GB
    使用されている VDO 論理23.6 GB*27.8 GB68.7 GB
    1.6TB フォーマットドライブ用のファイルシステムのオーバーヘッド

5.圧縮の測定

  1. 物理サイズおよび論理サイズが 10GB 以上の VDO ボリュームを作成します。重複排除を無効にし、圧縮を有効にするオプションを追加します。
    # vdo create --name=vdo0 --device=/dev/sdb \
                 --vdoLogicalSize=10G --verbose \
                 --deduplication=disabled --compression=enabled
    
  2. 転送前に VDO 統計を確認します。使用されているデータブロックと論理ブロックを書き留めておきます (両方ともゼロにする必要があります)。
    # vdostats --verbose | grep "blocks used"
  3. 新しいデバイスを XFS または ext4 ファイルシステムでフォーマットします。
    • XFS の場合:
      # mkfs.xfs -K /dev/mapper/vdo0
      
    • ext4 の場合:
      # mkfs.ext4 -E nodiscard /dev/mapper/vdo0
      
  4. フォーマットしたデバイスをマウントします。
    # mkdir /mnt/VDOVolume
    # mount /dev/mapper/vdo0 /mnt/VDOVolume && \
      chmod a+rwx /mnt/VDOVolume
    
  5. VDO ボリュームを同期して、未完了の圧縮を完了します。
    # sync && dmsetup message vdo0 0 sync-dedupe
  6. VDO 統計を再検証します。使用されている論理ブロック - 使用されているデータブロックは、ファイルシステム単体の圧縮により保存されている 4KB ブロックの数になります。VDO は、ファイルシステムのオーバーヘッドと、実際のユーザーデータを最適化します。
    # vdostats --verbose | grep "blocks used"
  7. /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
    
  8. Linux キャッシュと VDO ボリュームを同期します。
    # sync && dmsetup message vdo0 0 sync-dedupe
  9. VDO 統計を再検証します。使用されている論理ブロックおよびデータブロックを確認します。
    # vdostats --verbose | grep "blocks used"
    • 使用されている論理ブロック - 使用されるデータブロックは、/lib ファイルのコピーに使用されるスペースの量(4 KB ブロック単位)を表します。
    • 合計サイズ (「4.重複排除の計測」 の表から) - (使用される論理-使用されるデータブロック * 4096) = 圧縮により節約されたバイト数
  10. VDO ボリュームを削除します。
    # umount /mnt/VDOVolume && vdo remove --name=vdo0

6.VDO 圧縮の効率のテスト

  1. 「VDO テストボリュームの設定」に従って、VDO ボリュームを作成してマウントします。
  2. ボリュームを削除せずに、「4.重複排除の計測」「5.圧縮の測定」 で実験を繰り返します。vdostats の領域節約への変更を監視します。
  3. 用意したデータセットを試します。

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)を参照してください。
これがどのように機能するかを確認するには、以下を実行します。
  1. 「VDO テストボリュームの設定」 に従って、新しい VDO 論理ボリュームを作成してマウントします。
  2. ファイルシステムをトリミングして、不要なブロックを削除します (これには長い時間がかかる場合があります)。
    # fstrim /mnt/VDOVolume
  3. 以下を入力して、以下の表に初期状態を記録します。
    $ df -m /mnt/VDOVolume
    ファイルシステムで使用されている容量を確認し、vdostats を実行して、使用されている物理データブロックと論理データブロックの数を確認します。
  4. VDO 上で実行中のファイルシステムに、重複しないデータを含む 1 GB ファイルを作成します。
    $ dd if=/dev/urandom of=/mnt/VDOVolume/file bs=1M count=1K
    
    次に、同じデータを収集します。ファイルシステムはさらに 1GB を使用する必要があり、使用されるデータブロックと使用される論理ブロックも同様に増加しました。
  5. fstrim /mnt/VDOVolume を実行し、新しいファイルの作成後に、これが影響を与えないことを確認します。
  6. 1 GB ファイルを削除します。
    $ rm /mnt/VDOVolume/file
    パラメーターを確認し、記録します。ファイルシステムは、ファイルが削除されたことを認識していますが、ファイルの削除が基礎となるストレージに通知されていないため、物理ブロックまたは論理ブロックの数に変更がありませんでした。
  7. 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 に固有のものではないことを理解することも重要です。シンプロビジョニングされたストレージシステムにも同じ課題があります。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.