☰

ファイルシステムをマウントするときに、既存のLVMボリュームグループにLVMキャッシュデバイスを追加するのは安全ですか？

tag-icon • tag-icon lvm performance cache safety
ファイルシステムをマウントするときに、既存のLVMボリュームグループにLVMキャッシュデバイスを追加するのは安全ですか？

ext4システムとしてマウントされ、使用中の10TB論理ボリュームを持つ既存のLVMボリュームグループがあります。

lvconvert --type cache --cachepool storage/lvmcache-data storage/dataext4ファイルシステムがマウントされたときにこのコマンドを実行するのは安全ですかstorage/data？（これは影響を与えるstorage/lvmcache-data場合に備えて以前に設定されました。）lvconvert --type cache-pool --cachemode writeback --poolmetadata storage/lvmcache-metadata storage/lvmcache-data

私の考えでは、ファイルシステムがマウントされているオンラインボリュームにキャッシュを動的に追加するのは安全ですが、ドキュメントが見つかりません。

ベストアンサー1

LVMの作成者はどこにも明示的に文書化していませんが、次のように説明します。https://blog.delouw.ch/2020/01/29/using-lvm-cache-for-storage-tiering/

もう一つの利点はDMキャッシュdm-writecacheとは異なり、キャッシュは次のようになります。オンラインで作成、アクティブ化、破壊。

dm-cacheこれは、モジュールの代わりにモジュールを使用する限り、論理ボリュームがマウントされているdm-writecache間にLVMキャッシュを追加および削除することが安全であることを意味します。

LVMのcachemode設定writebackはdm-writecache。

また、RedHatのマニュアルは次の場所にあります。https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/administration_guide/sect-lvm_cache#idm140401735629408次のように教えてください。

19.8.3。 LVMキャッシュの設定
...
キャッシュプールを追加または削除できます。活性量で見ると、マウントされたファイルシステムを使用している場合でも。しかし、仕事に少しオーバーヘッドがあるのでパフォーマンスへの影響 特に完全なデータ同期が必要なため、書き込みストレージモードでキャッシュボリュームを削除するとこの現象が発生します。

また、次のテストでこれを確認しました。

  1. 仮想マシンにsda（2 GB）、sdb（4 GB）、sdc（4 GB）、sdd（1 GB）の4つの追加ストレージデバイスを作成します。これらのデバイスのサイズは重要ではありません。ここでは、LVMの柔軟性を説明するためにさまざまなサイズのデバイスを使用しています。小さなsddデバイスが最も高速でキャッシュとして使用されると仮定できます。

  2. sda、sdb、およびsdcを使用してLVMリポジトリを構築し、すべてのデバイスのすべてのスコープを取得します（この例ではボリュームグループを呼び出し、論理ボリュームを呼び出しますstorage）。data

    pvcreate /dev/sda /dev/sdb /dev/sdc
vgcreate storage /dev/sda /dev/sdb /dev/sdc
lvcreate -l100%FREE -n data storage
mkfs.ext4 /dev/mapper/storage-data
mkdir -p /root/test
mount /dev/mapper/storage-data /root/test

    実際には、デバイス全体より少し短いパーティションを作成し、LVM物理ボリュームにこれらのパーティションを使用することをお勧めします。複数のメーカーの「1TB」デバイスは数メガバイトほど異なる可能性があるため、デバイスを簡単に交換できます。私は、他のSSDデバイスで同じサイズのパーティションを作成できるように、SSDの最後の100 MBをパーティションなしで維持することを好みます。ボーナスにより、SSD デバイスは追加の摩耗平準化領域として使用されないディスク領域を使用できます。安価なドライブを使用する場合は、まったく使用しない10〜20％を残すことをお勧めします。通常、安価なドライブは、ユーザーがアクセス可能な領域以外の摩耗レベリング領域がはるかに少ないためです。ユーザーがアクセスできる特定の領域をそのまま維持または解放すると、TRIMファームウェアにはより多くの摩耗レベリング領域があり、ドライブの寿命が延び、通常はパフォーマンスが向上します。

  3. ディレクトリ内の2つの別々の端末で2つのfioテストループを並列に開始します/root/test。

    最初のループ：

    while fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite --size=500m --blocksize=4k --ioengine=libaio --fsync=1m --iodepth=1 --direct=1 --numjobs=1 --group_reporting --verify=sha1 --do_verify=0 --verify_state_save=1 --verify_backlog=1024 && fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --blocksize=4k --ioengine=libaio --fsync=1m --iodepth=1 --direct=1 --numjobs=1 --group_reporting --verify=sha1 --do_verify=1 --verify_state_save=1 --verify_backlog=1024 --verify_dump=1 --verify_only ; do printf "\nOK -- %s\n\n\n" "$(date --iso=sec)"; done

    2番目のループ（他の端末から）：

    while fio --name TEST --eta-newline=5s --filename=fio-tempfile2.dat --rw=randwrite --size=500m --blocksize=4k --ioengine=libaio --fsync=1m --iodepth=4 --direct=1 --numjobs=4 --group_reporting --verify=sha1 --do_verify=0 --verify_state_save=1 --verify_backlog=1024 && fio --name TEST --eta-newline=5s --filename=fio-tempfile2.dat --rw=randread --size=500m --blocksize=4k --ioengine=libaio --fsync=1m --iodepth=2 --direct=1 --numjobs=8 --group_reporting --verify=sha1 --do_verify=1 --verify_state_save=1 --verify_backlog=1024 --verify_dump=1 --verify_only ; do printf "\nOK -- %s\n\n\n" "$(date --iso=sec)"; done

    名前の付いた2つのファイルを生成fio-tempfile.datし、fio-tempfile2.dat合計5つのプロセスを経て継続的に作成および検証され、ファイルの内容が検証されます。ddシングルバイトが修正されると、ループがエラーを検出するかどうかをテストしました。

    dd if=/dev/zero of=fio-tempfile.dat seek=1000000 count=1 bs=1

    エラーが検出された場合は、ループを再開でき、停止するかエラーが検出されるまでストレージのテストと検証を続けます。

  4. sddファイルシステムへのアクセスが安全であることを確認するために、上記のテストループを実行しながら、既存のストレージに新しいキャッシュデバイス（）を追加します。

    pvcreate /dev/sdd
vgextend storage /dev/sdd
lvcreate -n lvmcache-data -l 98%FREE storage /dev/sdd
lvcreate -n lvmcache-metadata -l 50%FREE storage /dev/sdd
lvconvert --type cache-pool --cachemode writeback --poolmetadata storage/lvmcache-metadata storage/lvmcache-data
lvconvert --type cache --cachepool storage/lvmcache-data storage/data

    最後のコマンドは、データの破損を引き起こすことなくLVMキャッシュデバイスを動的に追加します。キャッシュはシステムの再起動後も問題なく維持されます。データキャッシュの98％とメタデータキャッシュの残りのスペース（1％）のうち50％しか割り当てられていないのは、これらのスペースでキャッシュプールを構築するためにボリュームグループに空き容量が必要な場合、またはそうでなければ失敗するためです。cachevol代替方法を使用することもできますが、cachepoolサードパーティ製のソフトウェアは通常この方法のみをサポートしますcachepool。これは以前の方法だからです。どちらも同じパフォーマンスを持ち、cachepool構築はより複雑ですが、サードパーティの修理および診断ソフトウェアとの相互運用性に優れているため、このソフトウェアを好みます。また、このcachepoolモードは別々のデバイスを使用してメタデータとデータを保存できるようにするため、非常に高速なデバイスが複数ある場合はパフォーマンスを向上させることができます。

  5. 後でキャッシュデバイスを削除したい場合は、データを破損することなくすぐに次のことを実行できます。

    lvconvert --uncache storage/data

    LVMキャッシュがアクティブに使用されている場合（たとえば、上記の例で実行されているテストループ）、かなり時間がかかり、ステータスが引き続き表示されます。

    Flushing 15610 blocks for cache storage/data.
Flushing 11514 blocks for cache storage/data.
Flushing 7418 blocks for cache storage/data.
Flushing 5481 blocks for cache storage/data.
...
Flushing 1 blocks for cache storage/data.
Logical volume "lvmcache-data_cpool" successfully removed
Logical volume storage/data is not cached.

    更新が長時間中断され、更新されていない同じ数のブロックが表示され続けるように見えますが、待機する必要があります。 LVMにマウントされたファイルシステムは常に動作状態を維持します。

    uncache動作中に電源が切れるとどうなるか確認できませんでした。 LVMの起動時にキャッシュがまだ使用されていると仮定し、ジョブをuncache再実行するだけです。

このuncacheコマンドの後、データキャッシュとメタデータキャッシュの論理ボリュームの両方が失われる（記録なしで解放されます）、キャッシュデバイスを再接続するには、最初から新しく構築する必要があります（alllvcreateとlvconvertコマンド）。ステップ4）。操作が完了した後も、キャッシュデバイスはまだボリュームグループの一部であるため、uncache再実行する必要はありません。

いつものように、重要なデータを操作する前に最新のバックアップを完了して確認してください。

以下に基づいて、上記のLVMキャッシュ設定は次のとおりですlsblk -sp。

NAME                                             MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
/dev/mapper/storage-data                         253:3    0    10G  0 lvm  /root/test
├─/dev/mapper/storage-lvmcache--data_cpool_cdata 253:0    0   996M  0 lvm  
│ └─/dev/sdd                                       8:48   0     1G  0 disk 
├─/dev/mapper/storage-lvmcache--data_cpool_cmeta 253:1    0    12M  0 lvm  
│ └─/dev/sdd                                       8:48   0     1G  0 disk 
└─/dev/mapper/storage-data_corig                 253:2    0    10G  0 lvm  
  ├─/dev/sda                                       8:0    0     2G  0 disk 
  ├─/dev/sdb                                       8:16   0     4G  0 disk 
  └─/dev/sdc                                       8:32   0     4G  0 disk

LVMキャッシュを使用するための追加のヒント：

キャッシュに保持する項目を選択するロジックは完全自動ですが、LVMキャッシュを少し調整できます。バラよりman lvmcache詳細を確認してください。いくつかの例：

  • 現在のキャッシュ設定のリスト（デフォルトはリストされていません）：

    lvs -o cachesettings storage/data

  • すべてのキャッシュ設定を消去する（すべてのものにデフォルト値を使用）：

    lvchange --cachesettings '' storage/data

  • キャッシュの10％以上が書き込みバッファリングに使用されている場合は、常に書き込みキャッシュをバックアップストアにフラッシュし始めるようにキャッシュを調整します。

    lvchange --cachesettings 'high_watermark=10' storage/data

  • 何らかの理由でフラッシュの開始後にフラッシュする必要がある項目がある場合は、書き込みキャッシュがフラッシュされ続けるようにキャッシュを調整します。

    lvchange --cachesettings 'low_watermark=0' storage/data

  • バックアップストアにアクセスするときに、更新が50ミリ秒間自動的に一時停止されるようにキャッシュを調整します（更新の遅延を防ぐため）。

    lvchange --cachesettings 'pause_writeback=50' storage/data

  • データが60秒以上キャッシュにある場合、少量のデータでも自動的にバックアップストアにフラッシュされます。

    lvchange --cachesettings 'autocommit_time=60000' storage/data

おすすめ記事