ext4システムとしてマウントされ、使用中の10TB論理ボリュームを持つ既存のLVMボリュームグループがあります。
lvconvert --type cache --cachepool storage/lvmcache-data storage/data
ext4ファイルシステムがマウントされたときにこのコマンドを実行するのは安全ですか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キャッシュの設定
...
キャッシュプールを追加または削除できます。活性量で見ると、マウントされたファイルシステムを使用している場合でも。しかし、仕事に少しオーバーヘッドがあるのでパフォーマンスへの影響 特に完全なデータ同期が必要なため、書き込みストレージモードでキャッシュボリュームを削除するとこの現象が発生します。
また、次のテストでこれを確認しました。
仮想マシンに
sda
(2 GB)、sdb
(4 GB)、sdc
(4 GB)、sdd
(1 GB)の4つの追加ストレージデバイスを作成します。これらのデバイスのサイズは重要ではありません。ここでは、LVMの柔軟性を説明するためにさまざまなサイズのデバイスを使用しています。小さなsdd
デバイスが最も高速でキャッシュとして使用されると仮定できます。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
ファームウェアにはより多くの摩耗レベリング領域があり、ドライブの寿命が延び、通常はパフォーマンスが向上します。ディレクトリ内の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
エラーが検出された場合は、ループを再開でき、停止するかエラーが検出されるまでストレージのテストと検証を続けます。
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
モードは別々のデバイスを使用してメタデータとデータを保存できるようにするため、非常に高速なデバイスが複数ある場合はパフォーマンスを向上させることができます。後でキャッシュデバイスを削除したい場合は、データを破損することなくすぐに次のことを実行できます。
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