☰

파일 시스템을 마운트할 때 기존 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(2GB), sdb(4GB), sdc(4GB), sdd(1GB) 등 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의 마지막 100MB 정도를 파티션하지 않은 상태로 유지하는 것을 선호합니다. 보너스로 SSD 장치는 추가 마모 평준화 영역으로 사용되지 않는 디스크 영역을 사용할 수 있습니다. 저렴한 드라이브를 사용하는 경우에는 전혀 사용하지 않는 10~20%를 남겨 두는 것이 좋습니다. 일반적으로 저렴한 드라이브는 사용자가 접근할 수 있는 영역 이외의 마모 레벨링 영역이 훨씬 적기 때문입니다. 사용자가 액세스할 수 있는 특정 영역을 그대로 유지하거나 를 해제하면 TRIM펌웨어에 더 많은 마모 레벨링 영역이 있어 드라이브 수명이 연장되고 일반적으로 성능이 향상됩니다.

  3. 디렉터리에 있는 두 개의 별도 터미널에서 두 개의 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

    두 번째 루프(다른 터미널에서):

    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명령 후에는 데이터 캐시와 메타데이터 캐시 논리 볼륨이 모두 손실되므로(기록 없이 해제됨) 캐시 장치를 다시 연결하려면 처음부터 새로 구축해야 합니다(all lvcreate및 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

관련 정보