LVM과 Matryoshka의 공통점은 무엇입니까?

안녕하세요.
md RAID + LVM을 사용하여 KVM용 데이터 스토리지 시스템을 구축한 실제 경험을 커뮤니티와 공유하고 싶습니다.

프로그램에는 다음이 포함됩니다.

• NVMe SSD에서 md RAID 1을 구축합니다.
• SATA SSD 및 일반 드라이브에서 md RAID 6을 조립합니다.
• SSD RAID 1/6의 TRIM/DISCARD 작업 기능.
• 공통 디스크 세트에 부팅 가능한 md RAID 1/6 어레이 생성.
• BIOS에 NVMe 지원이 없는 경우 NVMe RAID 1에 시스템을 설치합니다.
• LVM 캐시 및 LVM 씬을 사용합니다.
• BTRFS 스냅샷을 사용하고 백업을 위해 보내기/받기.
• BTRFS 스타일 백업을 위해 LVM 씬 스냅샷과 Thin_delta를 사용합니다.

관심이 있으시면 고양이를 참조하십시오.

성명서

저자는 이 기사의 자료/예제/코드/팁/데이터를 사용하거나 사용하지 않음으로 인해 발생하는 결과에 대해 어떠한 책임도 지지 않습니다. 어떤 방식으로든 이 자료를 읽거나 사용함으로써 귀하는 이러한 행위의 모든 결과에 대해 책임을 지게 됩니다. 가능한 결과는 다음과 같습니다.

• 바삭하게 튀긴 NVMe SSD.
• 녹화 리소스를 완전히 사용하고 SSD 드라이브에 오류가 발생했습니다.
• 백업 복사본을 포함하여 모든 드라이브의 모든 데이터가 완전히 손실됩니다.
• 컴퓨터 하드웨어에 결함이 있습니다.
• 시간, 신경, 돈을 낭비했습니다.
• 위에 나열되지 않은 기타 결과.

철

사용 가능한 항목은 다음과 같습니다.

Z2013 칩셋을 탑재하고 Intel Core i87/Haswell을 갖춘 7년경 마더보드.

• 프로세서 4코어, 8스레드
• 32GB DDR3 RAM
• 1개의 16 또는 2개의 8 PCIe 3.0
• 1x4 + 1x1 PCIe 2.0
• 6 x 6GBps SATA 3 커넥터

SAS 어댑터 LSI SAS9211-8I가 IT/HBA 모드로 플래시되었습니다. RAID 지원 펌웨어는 의도적으로 HBA 펌웨어로 교체되어 다음을 수행합니다.

1. 언제든지 이 어댑터를 버리고 다른 어댑터로 교체할 수 있습니다.
2. TRIM/Discard는 디스크에서 정상적으로 작동했습니다. 왜냐하면... RAID 펌웨어에서는 이러한 명령이 전혀 지원되지 않으며 일반적으로 HBA는 버스를 통해 어떤 명령이 전송되는지 신경 쓰지 않습니다.

하드 드라이브 - 노트북의 경우 8 폼 팩터에 7TB 용량을 갖춘 HGST Travelstar 1000K1 2.5개. 이러한 드라이브는 이전에 RAID 6 어레이에 있었습니다. 그들은 또한 새로운 시스템에서도 사용될 것입니다. 로컬 백업을 저장합니다.

추가로 다음이 추가되었습니다.

6개 SATA SSD 모델 Samsung 860 QVO 2TB. 이러한 SSD에는 대용량이 필요하고, SLC 캐시의 존재, 신뢰성, 저렴한 가격이 요구되었습니다. 폐기/XNUMX 지원이 필요하며 이는 dmesg의 줄로 확인됩니다.

kernel: ata1.00: Enabling discard_zeroes_data

NVMe SSD 모델 Samsung SSD 2 EVO 970GB 500개.

이러한 SSD의 경우 필요에 맞는 임의 읽기/쓰기 속도와 리소스 용량이 중요합니다. 그들을 위한 라디에이터. 반드시. 전적으로. 그렇지 않으면 첫 번째 RAID 동기화 중에 바삭해질 때까지 튀겨주세요.

PCIe 8 2x 슬롯에 설치된 2 x NVMe SSD용 StarTech PEX2M3.0E8 어댑터. 이것은 다시 HBA일 뿐이지만 NVMe용입니다. 내장형 PCIe 스위치가 있기 때문에 마더보드에서 PCIe 분기 지원이 필요하지 않다는 점에서 저렴한 어댑터와 다릅니다. x1 PCIe 1.0 슬롯이더라도 PCIe를 사용하는 가장 오래된 시스템에서도 작동합니다. 당연히 적절한 속도로. 거기에는 RAID가 없습니다. 보드에는 내장 BIOS가 없습니다. 따라서 시스템은 NVMe로 부팅하는 방법을 마법처럼 배우지 않으며, 이 장치 덕분에 NVMe RAID도 학습하지 않습니다.

이 구성 요소는 시스템에 무료 8x PCIe 3.0이 하나만 존재하기 때문에 발생했으며, 여유 슬롯이 2개 있는 경우 4페니 PEX2M1E600 또는 유사 제품으로 쉽게 교체할 수 있으며 어디에서나 XNUMX달러에 구입할 수 있습니다. 루블.

모든 종류의 하드웨어나 내장 칩셋/BIOS RAID를 의도적으로 거부한 이유는 모든 데이터를 보존하면서 SSD/HDD 자체를 제외한 전체 시스템을 완전히 교체할 수 있기 때문입니다. 이상적으로는 완전히 새롭거나 다른 하드웨어로 이동할 때 설치된 운영 체제도 저장할 수 있습니다. 가장 중요한 것은 SATA 및 PCIe 포트가 있다는 것입니다. 라이브 CD나 부팅 가능한 플래시 드라이브와 비슷하지만 매우 빠르고 약간 부피가 큽니다.

Юмор그렇지 않으면 무슨 일이 일어나는지 알 수 있습니다. 때로는 긴급하게 전체 어레이를 가져가야 할 때도 있습니다. 하지만 데이터를 잃고 싶지 않습니다. 이를 위해 언급된 모든 미디어는 표준 케이스의 5.25 베이 슬라이드에 편리하게 위치해 있습니다.

물론, Linux에서 SSD 캐싱의 다양한 방법을 실험하기 위해서입니다.

하드웨어 습격은 지루합니다. 전원을 켜십시오. 작동하거나 작동하지 않습니다. 그리고 mdadm에는 항상 옵션이 있습니다.

부드러운

이전에는 EOL에 가까운 하드웨어에 Debian 8 Jessie가 설치되어 있었습니다. RAID 6은 LVM과 쌍을 이루는 위에서 언급한 HDD로 구성되었습니다. kvm/libvirt에서 가상 머신을 실행했습니다.

왜냐하면 저자는 휴대용 부팅 가능한 SATA/NVMe 플래시 드라이브를 만드는 데 적합한 경험을 갖고 있으며, 또한 일반적인 적절한 템플릿을 깨지 않기 위해 대상 시스템으로 이미 충분히 안정화되었지만 아직 18.04년이 넘는 Ubuntu 3를 선택했습니다. 앞으로도 지원.

언급된 시스템에는 기본적으로 필요한 모든 하드웨어 드라이버가 포함되어 있습니다. 타사 소프트웨어나 드라이버가 필요하지 않습니다.

설치 준비

시스템을 설치하려면 Ubuntu Desktop Image가 필요합니다. 서버 시스템에는 일종의 강력한 설치 프로그램이 있는데, 이는 UEFI 시스템 파티션을 디스크 중 하나에 밀어 넣어 비활성화할 수 없는 과도한 독립성을 보여 모든 아름다움을 손상시킵니다. 따라서 UEFI 모드에서만 설치됩니다. 어떤 옵션도 제공하지 않습니다.

우리는 이것에 만족하지 않습니다.

이유는 무엇입니까?불행하게도 UEFI 부팅은 부팅 소프트웨어 RAID와 호환되지 않습니다. 그 이유는... UEFI ESP 파티션에 대한 예약을 제공하는 사람은 아무도 없습니다. USB 포트의 플래시 드라이브에 ESP 파티션을 배치하도록 제안하는 레시피가 온라인에 있지만 이는 실패 지점입니다. UEFI BIOS가 이 파티션을 보는 것을 방지하지 않는 메타데이터 버전 1의 소프트웨어 mdadm RAID 0.9을 사용하는 레시피가 있지만 이는 BIOS 또는 다른 하드웨어 OS가 ESP에 무언가를 쓰고 다른 하드웨어와 동기화하는 것을 잊어버리는 행복한 순간까지 유지됩니다. 거울.

또한 UEFI 부팅은 NVRAM에 의존하며 이는 디스크와 함께 새 시스템으로 이동하지 않습니다. 마더보드의 일부입니다.

그래서 우리는 새로운 바퀴를 재발명하지 않을 것입니다. 우리는 이미 UEFI 호환 시스템에서 CSM이라는 자랑스러운 이름을 지닌 레거시/BIOS 부팅이라고 불리는 기성품의 오랜 테스트를 거친 할아버지의 자전거를 보유하고 있습니다. 선반에서 꺼내서 윤활유를 바르고 타이어에 공기를 주입한 다음 젖은 천으로 닦으면 됩니다.

Ubuntu의 데스크톱 버전도 레거시 부트 로더를 사용하여 제대로 설치할 수 없지만 여기에는 최소한 옵션이 있습니다.

그래서 우리는 하드웨어를 수집하고 Ubuntu Live 부팅 가능한 플래시 드라이브에서 시스템을 로드합니다. 패키지를 다운로드해야 하므로 귀하에게 적합한 네트워크를 설정해 드리겠습니다. 작동하지 않으면 필요한 패키지를 미리 플래시 드라이브에 로드할 수 있습니다.

데스크탑 환경으로 이동하여 터미널 에뮬레이터를 시작한 다음 다음을 수행합니다.

#sudo bash

어떻게…?위의 줄은 sudo에 대한 holiwars의 정식 트리거입니다. Cbо더 큰 기회가 다가오고о더 큰 책임. 문제는 스스로 감당할 수 있느냐는 것이다. 많은 사람들은 sudo를 이런 식으로 사용하는 것은 적어도 조심스럽지 않다고 생각합니다. 하지만:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

왜 ZFS가 아닌가...?컴퓨터에 소프트웨어를 설치할 때 우리는 기본적으로 이 소프트웨어 개발자에게 하드웨어를 빌려주게 됩니다.
데이터의 안전성을 보장하는 이 소프트웨어를 신뢰할 때 우리는 이 데이터를 복원하는 비용에 해당하는 대출을 받게 되며, 이는 언젠가 갚아야 할 것입니다.

이런 관점에서 볼 때 ZFS는 페라리이고 mdadm+lvm은 자전거에 가깝습니다.

주관적으로 저자는 페라리 대신 알려지지 않은 사람에게 신용으로 자전거를 빌려주는 것을 선호합니다. 문제의 가격은 높지 않습니다. 권리는 필요하지 않습니다. 교통규칙보다 간단합니다. 주차는 무료입니다. 크로스 컨트리 능력이 더 좋습니다. 언제든지 자전거에 다리를 부착할 수 있고, 자전거를 직접 손으로 수리할 수도 있습니다.

그렇다면 왜 BTRFS...?운영 체제를 부팅하려면 기본적으로 Legacy/BIOS GRUB에서 지원되고 동시에 라이브 스냅샷을 지원하는 파일 시스템이 필요합니다. /boot 파티션에 사용하겠습니다. 또한 저자는 /(루트)에 대해 이 FS를 사용하는 것을 선호하며 다른 소프트웨어의 경우 LVM에 별도의 파티션을 생성하고 필요한 디렉터리에 마운트할 수 있다는 점을 잊지 않았습니다.

이 FS에는 가상 머신이나 데이터베이스의 이미지를 저장하지 않습니다.
이 FS는 시스템을 끄지 않고 시스템의 스냅샷을 생성한 다음 보내기/받기를 사용하여 이러한 스냅샷을 백업 디스크로 전송하는 데에만 사용됩니다.

또한 저자는 일반적으로 최소한의 소프트웨어를 하드웨어에 직접 유지하고 IOMMU를 통해 GPU 및 PCI-USB 호스트 컨트롤러를 KVM에 전달하는 등의 방법을 사용하여 가상 머신에서 다른 모든 소프트웨어를 실행하는 것을 선호합니다.

하드웨어에 남은 것은 데이터 저장, 가상화, 백업뿐이다.

ZFS를 더 신뢰한다면 원칙적으로 지정된 응용 프로그램에 대해 상호 교환이 가능합니다.

그러나 저자는 ZFS, BRTFS 및 LVM이 가지고 있는 내장된 미러링/RAID 및 중복성 기능을 의도적으로 무시했습니다.

추가 주장으로 BTRFS에는 무작위 쓰기를 순차적 쓰기로 전환하는 기능이 있으며 이는 HDD의 스냅샷/백업 동기화 속도에 매우 긍정적인 영향을 미칩니다.

모든 장치를 다시 검색해 보겠습니다.

#udevadm control --reload-rules && udevadm trigger

주위를 살펴 보겠습니다.

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


디스크 레이아웃

NVMe SSD

하지만 우리는 어떤 식으로든 표시하지 않을 것입니다. 마찬가지로 BIOS에서는 이러한 드라이브를 볼 수 없습니다. 따라서 완전히 소프트웨어 RAID로 전환됩니다. 거기에는 섹션도 만들지 않을 것입니다. "표준" 또는 "원칙"을 따르려면 HDD와 같은 하나의 큰 파티션을 만드십시오.

SATA HDD

여기서는 특별한 것을 고안할 필요가 없습니다. 모든 항목에 대해 하나의 섹션을 만듭니다. BIOS가 이러한 디스크를 확인하고 심지어 부팅을 시도할 수도 있으므로 파티션을 생성하겠습니다. 시스템이 갑자기 이 작업을 수행할 수 있도록 나중에 이 디스크에 GRUB를 설치할 것입니다.

#cat >hdd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sdg
unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part


SATA SSD

이것이 우리에게 흥미로운 일이 되는 곳입니다.

첫째, 드라이브 크기는 2TB입니다. 이는 우리가 사용할 MBR의 허용 범위 내에 있습니다. 필요한 경우 GPT로 대체할 수 있습니다. GPT 디스크에는 MBR 호환 시스템이 처음 4테라바이트 내에 있는 경우 처음 2개의 파티션을 볼 수 있도록 하는 호환성 레이어가 있습니다. 가장 중요한 점은 이러한 디스크의 부팅 파티션과 bios_grub 파티션이 시작 부분에 있어야 한다는 것입니다. 이를 통해 GPT 레거시/BIOS 드라이브에서 부팅할 수도 있습니다.

그러나 이것은 우리의 경우가 아닙니다.

여기서는 두 개의 섹션을 생성하겠습니다. 첫 번째 크기는 1GB이며 RAID 1 /boot에 사용됩니다.

두 번째는 RAID 6에 사용되며 드라이브 끝에 할당되지 않은 작은 영역을 제외하고 남은 여유 공간을 모두 차지합니다.

이 표시되지 않은 영역은 무엇입니까?네트워크 소스에 따르면 당사의 SATA SSD에는 6~78GB 크기의 동적으로 확장 가능한 SLC 캐시가 내장되어 있습니다. 드라이브 데이터 시트의 "기가바이트"와 "기비바이트"의 차이로 인해 "무료"로 6기가바이트를 얻습니다. 나머지 72GB는 사용되지 않은 공간에서 할당됩니다.

여기서는 SLC 캐시가 있고 공간은 4비트 MLC 모드에서 점유된다는 점에 유의해야 합니다. 이는 사실상 4GB의 여유 공간마다 1GB의 SLC 캐시만 얻을 수 있다는 것을 의미합니다.

72GB에 4를 곱하면 288GB가 됩니다. 이는 드라이브가 SLC 캐시를 최대한 활용할 수 있도록 표시하지 않을 여유 공간입니다.

따라서 총 312개의 드라이브에서 최대 2GB의 SLC 캐시를 효과적으로 얻을 수 있습니다. 모든 드라이브 중 XNUMX개는 중복성을 위해 RAID에 사용됩니다.

이 정도의 캐시를 사용하면 실제 생활에서 쓰기가 캐시에 저장되지 않는 상황이 거의 발생하지 않습니다. 이는 QLC 메모리의 가장 슬픈 단점, 즉 캐시를 우회하여 데이터를 쓸 때 쓰기 속도가 매우 느린 것을 매우 잘 보완합니다. 귀하의 부하가 이에 해당하지 않는 경우 데이터 시트의 TBW를 고려하여 해당 부하에서 SSD가 얼마나 오래 지속되는지 자세히 생각해 보는 것이 좋습니다.

#cat >ssd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part


배열 만들기

먼저 컴퓨터의 이름을 바꿔야 합니다. 이는 호스트 이름이 mdadm 내부 어딘가에 있는 배열 이름의 일부이고 어딘가에 영향을 미치기 때문에 필요합니다. 물론 나중에 배열 이름을 바꿀 수 있지만 이는 불필요한 단계입니다.

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

왜 깨끗하다고 ​​가정합니까...?배열 초기화를 방지합니다. 이는 RAID 레벨 1과 6 모두에 유효합니다. 새로운 배열이라면 초기화 없이 모든 것이 작동할 수 있습니다. 게다가 SSD 어레이 생성 시 초기화하는 것은 TBW 자원 낭비입니다. 우리는 조립된 SSD 어레이에서 가능한 경우 TRIM/DISCARD를 사용하여 이를 "초기화"합니다.

SSD 어레이의 경우 RAID 1 DISCARD가 즉시 지원됩니다.

SSD RAID 6 DISCARD 어레이의 경우 커널 모듈 매개변수에서 이를 활성화해야 합니다.

이 시스템의 레벨 4/5/6 어레이에 사용되는 모든 SSD가 Discard_zeroes_data를 지원하는 경우에만 이 작업을 수행해야 합니다. 때때로 커널에 이 기능이 지원된다고 알려주지만 실제로는 지원되지 않거나 기능이 항상 작동하지 않는 이상한 드라이브를 발견할 때가 있습니다. 현재 거의 모든 곳에서 지원이 가능하지만 오래된 드라이브와 펌웨어에 오류가 있습니다. 이러한 이유로 RAID 6에서는 DISCARD 지원이 기본적으로 비활성화되어 있습니다.

주의: 다음 명령은 "XNUMX"으로 어레이를 "초기화"하여 NVMe 드라이브의 모든 데이터를 삭제합니다.

#blkdiscard /dev/md0

문제가 발생하면 단계를 지정해 보세요.

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

왜 이렇게 커...?청크 크기를 늘리면 청크 크기를 포함한 블록의 무작위 읽기 속도에 긍정적인 영향을 미칩니다. 이는 적절한 크기 이하의 하나의 작업을 단일 장치에서 완전히 완료할 수 있기 때문에 발생합니다. 따라서 모든 장치의 IOPS가 합산됩니다. 통계에 따르면 IO의 99%는 512K를 초과하지 않습니다.

쓰기당 RAID 6 IOPS 항상 한 드라이브의 IOPS보다 작거나 같습니다. 무작위 읽기의 경우 IOPS가 한 드라이브의 IOPS보다 몇 배 더 클 수 있으며 여기서는 블록 크기가 매우 중요합니다.
저자는 RAID 6의 설계상 잘못된 매개변수를 최적화하려는 시도의 요점을 파악하지 못하고 대신 RAID 6의 장점을 최적화합니다.
NVMe 캐시와 씬 프로비저닝 트릭을 통해 RAID 6의 열악한 무작위 쓰기 문제를 보완할 것입니다.

아직 RAID 6에 대해 DISCARD를 활성화하지 않았습니다. 따라서 지금은 이 어레이를 "초기화"하지 않겠습니다. 나중에 OS를 설치한 후에 이 작업을 수행하겠습니다.

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

NVMe RAID의 LVM

속도를 위해 루트 파일 시스템을 /dev/md1인 NVMe RAID 0에 배치하려고 합니다.
그러나 스왑, 메타데이터, LVM 캐시 및 LVM 씬 메타데이터와 같은 다른 요구 사항을 위해서는 이 빠른 어레이가 여전히 필요하므로 이 어레이에 LVM VG를 생성할 것입니다.

#pvcreate /dev/md0
#vgcreate root /dev/md0

루트 파일 시스템용 파티션을 만들어 보겠습니다.

#lvcreate -L 128G --name root root

RAM 크기에 따라 스왑용 파티션을 만들어 보겠습니다.

#lvcreate -L 32G --name swap root

OS 설치

전체적으로 우리는 시스템을 설치하는 데 필요한 모든 것을 갖추고 있습니다.

Ubuntu Live 환경에서 시스템 설치 마법사를 시작합니다. 일반 설치. 설치할 디스크를 선택하는 단계에서만 다음 사항을 지정해야 합니다.

• /dev/md1, - 마운트 지점 /boot, FS - BTRFS
• /dev/root/root(일명 /dev/mapper/root-root), - 마운트 지점 /(루트), FS - BTRFS
• /dev/root/swap (일명 /dev/mapper/root-swap) - 스왑 파티션으로 사용
• /dev/sda에 부트로더 설치

BTRFS를 루트 파일 시스템으로 선택하면 설치 프로그램은 /(루트)의 경우 "@", /home의 경우 "@home"이라는 두 개의 BTRFS 볼륨을 자동으로 생성합니다.

설치를 시작해보자..

부트로더 설치 중 오류를 나타내는 모달 대화 상자가 표시되면서 설치가 종료됩니다. 안타깝게도 표준 수단을 사용하여 이 대화 상자를 종료하고 설치를 계속할 수는 없습니다. 시스템에서 로그아웃했다가 다시 로그인하면 깨끗한 Ubuntu Live 데스크탑이 생성됩니다. 터미널을 열고 다시 다음을 수행합니다.

#sudo bash

설치를 계속하려면 chroot 환경을 생성하십시오.

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

chroot에서 네트워크와 호스트 이름을 구성해 보겠습니다.

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

chroot 환경으로 들어가 보겠습니다.

#chroot /mnt/chroot

우선, 우리는 패키지를 제공할 것입니다:

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

불완전한 시스템 설치로 인해 잘못 설치된 모든 패키지를 확인하고 수정해 보겠습니다.

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

문제가 해결되지 않으면 먼저 /etc/apt/sources.list를 편집해야 할 수도 있습니다.

TRIM/DISCARD를 활성화하도록 RAID 6 모듈의 매개변수를 조정해 보겠습니다.

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

배열을 약간 조정해 보겠습니다.

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

그게 뭐였지..?우리는 다음을 수행하는 일련의 udev 규칙을 만들었습니다.

• RAID 2020의 블록 캐시 크기를 6년에 적합하도록 설정하십시오. 기본값은 Linux를 만든 이후로 변경되지 않았으며 오랫동안 적합하지 않은 것 같습니다.
• 어레이 확인/동기화 기간 동안 최소 IO를 예약합니다. 이는 로드 시 어레이가 영구 동기화 상태에 빠지는 것을 방지하기 위한 것입니다.
• 어레이 확인/동기화 중 최대 IO를 제한합니다. 이는 SSD RAID 동기화/확인으로 인해 드라이브가 바삭바삭해지지 않도록 하기 위해 필요합니다. 이는 특히 NVMe의 경우에 해당됩니다. (라디에이터 기억하시나요? 농담이 아니었어요.)
• APM을 통해 디스크가 스핀들 회전(HDD)을 중지하는 것을 금지하고 디스크 컨트롤러의 절전 시간 초과를 7시간으로 설정합니다. 드라이브에서 APM을 비활성화할 수 있는 경우 APM을 완전히 비활성화할 수 있습니다(-B 255). 기본값을 사용하면 드라이브가 XNUMX초 후에 중지됩니다. 그런 다음 OS는 디스크 캐시를 재설정하려고 하고 디스크가 다시 회전하며 모든 것이 다시 시작됩니다. 디스크에는 최대 스핀들 회전 수가 제한되어 있습니다. 이러한 간단한 기본 주기로 인해 몇 년 안에 디스크가 쉽게 종료될 수 있습니다. 모든 디스크가 이 문제를 겪는 것은 아니지만 우리 디스크는 적절한 기본 설정을 갖춘 "노트북" 디스크이므로 RAID가 미니 MAID처럼 보입니다.
• 디스크에 미리 읽기 설치(회전) 1MB - 6개의 연속 블록/청크 RAID XNUMX
• 어레이 자체에서 미리 읽기를 비활성화합니다.

/etc/fstab을 편집해 봅시다:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
왜 그런 겁니까..?UUID로 /boot 파티션을 검색하겠습니다. 배열 이름 지정은 이론적으로 변경될 수 있습니다.

/dev/mapper/vg-lv 표기법에서 LVM 이름으로 나머지 섹션을 검색할 것입니다. 그들은 파티션을 매우 고유하게 식별합니다.

우리는 LVM에 UUID를 사용하지 않습니다. LVM 볼륨과 해당 스냅샷의 UUID는 동일할 수 있습니다./dev/mapper/root-root..를 두 번 마운트합니까?예. 정확히. BTRFS의 특징. 이 파일 시스템은 다른 하위 볼륨을 사용하여 여러 번 마운트될 수 있습니다.

동일한 기능으로 인해 활성 BTRFS 볼륨의 LVM 스냅샷을 생성하지 않는 것이 좋습니다. 재부팅하면 놀랄 수도 있습니다.

mdadm 구성을 다시 생성해 보겠습니다.

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

LVM 설정을 조정해 보겠습니다.

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1
}
EOF

그게 뭐였지..?볼륨의 90%로 점유 공간의 5%에 도달하면 LVM 씬 풀의 자동 확장을 활성화했습니다.

LVM 캐시의 최대 캐시 블록 수를 늘렸습니다.

LVM이 다음에서 LVM 볼륨(PV)을 검색하지 못하도록 차단했습니다.

• LVM 캐시(cdata)를 포함하는 장치
• LVM 캐시를 사용하여 캐시된 장치, 캐시를 우회( _코리그). 이 경우 캐시된 장치 자체는 여전히 캐시를 통해 검색됩니다(단지 ).
• LVM 캐시 메타데이터(cmeta)가 포함된 장치
• 이름이 image인 VG의 모든 장치. 여기에는 가상 머신의 디스크 이미지가 있으며 호스트의 LVM이 게스트 OS에 속한 볼륨을 활성화하는 것을 원하지 않습니다.
• 이름이 backup인 VG의 모든 장치. 여기에는 가상 머신 이미지의 백업 복사본이 있습니다.
• 이름이 "gpv"(게스트 물리 볼륨)로 끝나는 모든 장치

LVM VG에서 여유 공간을 확보할 때 DISCARD 지원을 활성화했습니다. 조심하세요. 이로 인해 SSD에서 LV를 삭제하는 데 시간이 많이 걸립니다. 이는 특히 SSD RAID 6에 적용됩니다. 그러나 계획에 따르면 씬 프로비저닝을 사용할 것이므로 전혀 방해가 되지 않습니다.

initramfs 이미지를 업데이트해 보겠습니다.

#update-initramfs -u -k all

Grub을 설치하고 구성합니다.

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

어떤 디스크를 선택해야 할까요?sd*인 모든 사람. 시스템은 작동 중인 SATA 드라이브 또는 SSD에서 부팅할 수 있어야 합니다.

왜 os-prober를 추가했나요..?과도한 독립성과 장난스러운 손을 위한 제품입니다.

RAID 중 하나가 성능 저하 상태에 있으면 제대로 작동하지 않습니다. 이 하드웨어에서 실행되는 가상 머신에 사용되는 파티션에서 OS 검색을 시도합니다.

필요하시면 남겨두셔도 되지만, 위의 사항을 모두 염두에 두시기 바랍니다. 버릇없는 손을 없애는 방법을 온라인에서 찾아보는 것이 좋습니다.

이로써 초기 설치가 완료되었습니다. 이제 새로 설치된 OS로 재부팅할 차례입니다. 부팅 가능한 Live CD/USB를 제거하는 것을 잊지 마세요.

#exit
#reboot

SATA SSD 중 하나를 부팅 장치로 선택합니다.

SATA SSD의 LVM

이 시점에서 우리는 이미 새 OS로 부팅하고, 네트워크를 구성하고, 터미널 에뮬레이터를 열고, 다음을 시작했습니다.

#sudo bash

우리는 계속합니다.

SATA SSD에서 어레이 "초기화":

#blkdiscard /dev/md2

작동하지 않으면 다음을 시도하십시오.

#blkdiscard --step 65536 /dev/md2
SATA SSD에 LVM VG를 생성합니다:

#pvcreate /dev/md2
#vgcreate data /dev/md2

왜 또 VG..?실제로 우리는 이미 root라는 이름의 VG를 가지고 있습니다. 하나의 VG에 모든 것을 추가하는 것은 어떨까요?

VG에 PV가 여러 개 있는 경우 VG가 올바르게 활성화되려면 모든 PV가 온라인에 있어야 합니다. LVM RAID는 예외이며 의도적으로 사용하지 않습니다.

우리는 RAID 6 어레이 중 하나에 오류(읽기 데이터 손실)가 있는 경우 운영 체제가 정상적으로 부팅되어 문제를 해결할 수 있는 기회를 제공하기를 정말로 원합니다.

이를 위해 첫 번째 추상화 수준에서 각 유형의 물리적 "미디어"를 별도의 VG로 격리합니다.

과학적으로 말하면, 다양한 RAID 어레이는 다양한 "신뢰성 도메인"에 속합니다. 이를 하나의 VG에 밀어 넣어 추가적인 공통 실패 지점을 생성해서는 안 됩니다.

"하드웨어" 수준에 LVM이 있으면 다양한 RAID 어레이를 다양한 방식으로 결합하여 임의로 잘라낼 수 있습니다. 예를 들어 - 실행 동시에 bcache + LVM 씬, bcache + BTRFS, LVM 캐시 + LVM 씬, 캐시가 포함된 복잡한 ZFS 구성 또는 기타 지옥 같은 혼합을 시도하고 비교해 보세요.

"하드웨어" 수준에서는 오래된 "thick" LVM 볼륨 이외의 다른 볼륨은 사용하지 않습니다. 이 규칙의 예외는 백업 파티션일 수 있습니다.

내 생각엔 이 순간쯤이면 이미 많은 독자들이 중첩 인형에 대해 뭔가를 의심하기 시작했을 것이다.

SATA HDD의 LVM

#pvcreate /dev/md3
#vgcreate backup /dev/md3

또 새로운 VG..?우리는 데이터 백업에 사용할 디스크 어레이에 장애가 발생하더라도 운영 체제가 계속 정상적으로 작동하면서 백업이 아닌 데이터에 대한 액세스를 평소와 같이 유지하기를 정말로 원합니다. 따라서 VG 활성화 문제를 방지하기 위해 별도의 VG를 생성합니다.

LVM 캐시 설정

NVMe RAID 1에 LV를 생성하여 캐싱 장치로 사용하겠습니다.

#lvcreate -L 70871154688B --name cache root

왜 이렇게 적지...?사실 우리의 NVMe SSD에도 SLC 캐시가 있습니다. 4비트 MLC에서 차지하는 여유 공간으로 인해 18GB의 "무료" 및 3GB의 동적 공간이 제공됩니다. 이 캐시가 소진되면 NVMe SSD는 캐시가 있는 SATA SSD보다 훨씬 빠르지 않습니다. 실제로 이러한 이유로 LVM 캐시 파티션을 NVMe 드라이브의 SLC 캐시 크기의 두 배보다 훨씬 크게 만드는 것은 의미가 없습니다. 사용된 NVMe 드라이브의 경우 저자는 32~64GB의 캐시를 만드는 것이 합리적이라고 생각합니다.

주어진 파티션 크기는 64GB의 캐시를 구성하고 캐시 메타데이터 및 메타데이터 백업 복사본을 수용하는 데 필요합니다.

또한, 더티 시스템 종료 후 LVM은 전체 캐시를 더티로 표시하고 다시 동기화합니다. 또한 시스템이 다시 재부팅될 때까지 이 장치에서 lvchange를 사용할 때마다 이 작업이 반복됩니다. 따라서 적절한 스크립트를 사용하여 즉시 캐시를 다시 생성하는 것이 좋습니다.

SATA RAID 6에 LV를 생성하여 캐시된 장치로 사용하겠습니다.

#lvcreate -L 3298543271936B --name cache data

왜 XNUMX테라바이트만..?따라서 필요한 경우 다른 요구 사항에 SATA SSD RAID 6을 사용할 수 있습니다. 캐시된 공간의 크기는 시스템을 중지하지 않고도 즉석에서 동적으로 늘릴 수 있습니다. 이렇게 하려면 캐시를 일시적으로 중지했다가 다시 활성화해야 하지만, 예를 들어 bcache에 비해 LVM 캐시의 독특한 장점은 이 작업을 즉시 수행할 수 있다는 것입니다.

캐싱을 위한 새로운 VG를 만들어 보겠습니다.

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

캐시된 장치에 LV를 생성해 보겠습니다.

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

여기서 우리는 즉시 /dev/data/cache의 모든 여유 공간을 차지하여 다른 모든 필수 파티션이 /dev/root/cache에 즉시 생성되었습니다. 잘못된 위치에 무언가를 생성한 경우 pvmove를 사용하여 이동할 수 있습니다.

캐시를 생성하고 활성화해 보겠습니다.

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

왜 이렇게 청크사이즈가..?실제 실험을 통해 저자는 LVM 캐시 블록의 크기가 LVM 씬 블록의 크기와 일치할 때 가장 좋은 결과를 얻을 수 있음을 알 수 있었다. 또한, 크기가 작을수록 랜덤 녹화 구성이 더 잘 수행됩니다.

64k는 LVM 씬에 허용되는 최소 블록 크기입니다.

후기 주의하세요..!예. 이 유형의 캐시는 캐시된 장치에 대한 쓰기 동기화를 연기합니다. 즉, 캐시가 손실되면 캐시된 장치의 데이터가 손실될 수 있습니다. 나중에 저자는 이러한 위험을 보상하기 위해 NVMe RAID 1 외에 어떤 조치를 취할 수 있는지 알려줄 것입니다.

이 캐시 유형은 RAID 6의 열악한 무작위 쓰기 성능을 보완하기 위해 의도적으로 선택되었습니다.

우리가 얻은 것을 확인해 봅시다:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Devices
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

/dev/data/cache에는 [cachedata_corig]만 있어야 합니다. 문제가 있으면 pvmove를 사용하세요.

필요한 경우 다음 명령 하나로 캐시를 비활성화할 수 있습니다.

#lvconvert -y --uncache cache/cachedata

이것은 온라인으로 이루어집니다. LVM은 캐시를 디스크에 동기화하고 제거한 다음, 캐시데이터_corig의 이름을 다시 캐시데이터로 바꿉니다.

LVM 씬 설정

LVM 씬 메타데이터에 필요한 공간을 대략적으로 추정해 보겠습니다.

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

4GB로 반올림: 4294967296B

LVM PV 메타데이터에 대해 4194304를 곱하고 8594128896B를 추가합니다: XNUMXB
NVMe RAID 1에 별도의 파티션을 생성하여 LVM 씬 메타데이터와 백업 복사본을 배치해 보겠습니다.

#lvcreate -L 8594128896B --name images root

무엇 때문에..?여기서 질문이 생길 수 있습니다. LVM 씬 메타데이터가 NVMe에 계속 캐시되고 빠르게 작동한다면 왜 별도로 배치해야 할까요?

여기서는 속도가 중요하지만 주된 이유는 아닙니다. 문제는 캐시가 실패 지점이라는 것입니다. 여기에 무슨 일이 일어날 수도 있으며, LVM 씬 메타데이터가 캐시되면 모든 것이 완전히 손실될 수 있습니다. 완전한 메타데이터가 없으면 씬 볼륨을 조합하는 것이 거의 불가능합니다.

메타데이터를 캐시되지 않지만 빠른 별도의 볼륨으로 이동함으로써 캐시 손실 또는 손상이 발생할 경우 메타데이터의 안전을 보장합니다. 이 경우 캐시 손실로 인한 모든 손상은 씬 볼륨 내부에 국한되므로 복구 절차가 몇 배나 단순화됩니다. 높은 확률로 이러한 피해는 FS 로그를 사용하여 복원됩니다.

또한 이전에 씬 볼륨의 스냅샷을 촬영한 후 캐시가 적어도 한 번 완전히 동기화된 경우 LVM 씬의 내부 설계로 인해 캐시 손실 시 스냅샷의 무결성이 보장됩니다. .

씬 프로비저닝을 담당할 새 VG를 만들어 보겠습니다.

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
풀을 만들어 보겠습니다.

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
왜 -Z y이 모드의 실제 목적은 공간을 재분배할 때 한 가상 머신의 데이터가 다른 가상 머신으로 유출되는 것을 방지하는 것 외에도 64k보다 작은 블록의 무작위 쓰기 속도를 높이기 위해 제로화를 추가로 사용하는 것입니다. 씬 볼륨의 이전에 할당되지 않은 영역에 대한 64k 미만의 쓰기는 캐시에서 64K 에지 정렬이 됩니다. 이렇게 하면 캐시된 장치를 우회하고 캐시를 통해 작업을 완전히 수행할 수 있습니다.

LV를 해당 PV로 이동해 보겠습니다.

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

검사:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Devices
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

테스트를 위해 씬 볼륨을 생성해 보겠습니다.

#lvcreate -V 64G --thin-pool thin-pool --name test images

테스트 및 모니터링을 위해 패키지를 설치합니다.

#apt-get install sysstat fio

다음은 스토리지 구성의 동작을 실시간으로 관찰할 수 있는 방법입니다.

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

구성을 테스트하는 방법은 다음과 같습니다.

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

주의하여! 자원!이 코드는 각각 36초 동안 실행되는 4개의 서로 다른 테스트를 실행합니다. 테스트의 절반은 기록을 위한 것입니다. NVMe에 4초만에 많은 내용을 녹음할 수 있습니다. 초당 최대 3GB. 따라서 각 쓰기 테스트를 실행하면 최대 216GB의 SSD 리소스를 소모할 수 있습니다.

읽기와 쓰기가 혼합되어 있나요?예. 읽기 및 쓰기 테스트를 별도로 실행하는 것이 합리적입니다. 또한 이전에 작성된 쓰기가 읽기에 영향을 미치지 않도록 모든 캐시를 동기화하는 것이 좋습니다.

결과는 캐시와 씬 볼륨이 채워지면서 첫 번째 실행과 후속 실행 동안 크게 달라지며, 시스템이 마지막 실행 중에 채워진 캐시를 동기화했는지 여부에 따라 달라집니다.

무엇보다도 방금 스냅샷을 찍은 이미 가득 찬 씬 볼륨의 속도를 측정하는 것이 좋습니다. 작성자는 첫 번째 스냅샷을 생성한 직후, 특히 캐시가 아직 완전히 가득 차지 않은 경우 무작위 쓰기가 어떻게 급격히 가속화되는지 관찰할 기회를 가졌습니다. 이는 쓰기 시 복사 의미 체계, 캐시와 씬 볼륨 블록의 정렬, RAID 6에 대한 무작위 쓰기가 RAID 6의 무작위 읽기로 바뀌고 이어서 캐시에 쓰기로 인해 발생합니다. 우리 구성에서는 RAID 6에서 무작위 읽기가 쓰기보다 최대 6배(어레이의 SATA SSD 수) 더 빠릅니다. 왜냐하면 CoW용 블록은 씬 풀에서 순차적으로 할당되며, 대부분의 경우 기록도 순차적으로 전환됩니다.

이 두 기능을 모두 유용하게 사용할 수 있습니다.

"일관적인" 스냅샷 캐시

캐시 손상/손실 시 데이터 손실 위험을 줄이기 위해 저자는 이 경우 무결성을 보장하기 위해 스냅샷을 회전하는 방식을 도입할 것을 제안합니다.

첫째, 씬 볼륨 메타데이터는 캐시되지 않은 디바이스에 상주하기 때문에 메타데이터는 일관되고 가능한 손실은 데이터 블록 내에서 격리됩니다.

다음 스냅샷 순환 주기는 캐시 손실 시 스냅샷 내부 데이터의 무결성을 보장합니다.

1. 이름이 <name>인 각 씬 볼륨에 대해 이름이 <name>.cached인 스냅샷을 생성합니다.
2. 마이그레이션 임계값을 합리적인 높은 값으로 설정해 보겠습니다. #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. 루프에서 캐시의 더티 블록 수를 확인합니다. #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' 100이 될 때까지. 100이 너무 오랫동안 누락된 경우 캐시를 연속 쓰기 모드로 일시적으로 전환하여 생성할 수 있습니다. 그러나 SATA 및 NVMe SSD 어레이의 속도 특성과 TBW 리소스를 고려하면 캐시 모드를 변경하지 않고도 순간을 빠르게 포착할 수 있거나 하드웨어가 전체 리소스를 완전히 소모하게 됩니다. 몇 일. 리소스 제한으로 인해 시스템은 원칙적으로 항상 쓰기 부하가 XNUMX% 미만일 수 없습니다. 쓰기 로드가 XNUMX% 미만인 NVMe SSD는 리소스를 완전히 소모합니다. 3-4 일. SATA SSD는 수명이 두 배밖에 되지 않습니다. 따라서 우리는 대부분의 로드가 읽기에 사용되며 쓰기에 대한 평균 로드가 낮고 매우 높은 활동이 상대적으로 단기적으로 급증한다고 가정합니다.
4. XNUMX을 포착하거나 만들자마자 <name>.cached의 이름을 <name>.committed로 바꿉니다. 이전 <name>.committed가 삭제됩니다.
5. 선택적으로 캐시가 100% 가득 찬 경우 스크립트를 통해 다시 생성하여 지울 수 있습니다. 캐시가 반쯤 비어 있으면 쓰기 시 시스템이 훨씬 빠르게 작동합니다.
6. 마이그레이션 임계값을 XNUMX으로 설정합니다. #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata 이렇게 하면 캐시가 기본 미디어와 일시적으로 동기화되지 않습니다.
7. 캐시에 많은 변경 사항이 쌓일 때까지 기다립니다. #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' 아니면 타이머가 꺼질 거예요.
8. 우리는 다시 반복합니다.

마이그레이션 임계값에 어려움이 있는 이유는 무엇입니까...?문제는 실제로 "무작위" 녹음이 실제로 완전히 무작위가 아니라는 것입니다. 크기가 4KB인 섹터에 무언가를 썼다면 다음 몇 분 안에 동일한 섹터 또는 인접(+- 32K) 섹터 중 하나에 레코드가 생성될 가능성이 높습니다.

마이그레이션 임계값을 64으로 설정하여 SATA SSD에 대한 쓰기 동기화를 연기하고 여러 변경 사항을 캐시의 XNUMXK 블록 하나에 집계합니다. 이는 SATA SSD의 리소스를 크게 절약합니다.

코드는 어디에 있나요..?불행하게도 저자는 100% 독학하고 "google" 중심 개발을 수행하기 때문에 bash 스크립트 개발에 자신이 부족하다고 생각합니다. 따라서 그는 자신의 손에서 나오는 끔찍한 코드를 누구도 사용해서는 안 된다고 믿습니다. 또 다른.

나는 이 분야의 전문가들이 필요하다면 위에서 설명한 모든 논리를 독립적으로 묘사할 수 있을 것이며, 아마도 저자가 시도한 것처럼 시스템화된 서비스로 아름답게 디자인할 수도 있을 것이라고 생각합니다.

이러한 간단한 스냅샷 순환 방식을 사용하면 SATA SSD에서 하나의 스냅샷을 지속적으로 완전히 동기화할 수 있을 뿐만 아니라, Thin_delta 유틸리티를 사용하여 생성 후 어떤 블록이 변경되었는지 알아낼 수 있으므로 손상을 국소화할 수 있습니다. 복구를 크게 단순화합니다.

libvirt/KVM에서 다듬기/삭제하기

왜냐하면 데이터 저장소는 libvirt를 실행하는 KVM에 사용됩니다. 그러면 VM이 여유 공간을 차지하는 것뿐만 아니라 더 이상 필요하지 않은 것도 확보하도록 가르치는 것이 좋습니다.

이는 가상 디스크에서 TRIM/DISCARD 지원을 에뮬레이션하여 수행됩니다. 이렇게 하려면 컨트롤러 유형을 virtio-scsi로 변경하고 xml을 편집해야 합니다.

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>

게스트 OS의 이러한 DISCARD는 LVM에서 올바르게 처리되며 블록은 캐시와 씬 풀 모두에서 올바르게 해제됩니다. 우리의 경우에는 다음 스냅샷을 삭제할 때 주로 지연된 방식으로 발생합니다.

BTRFS 백업

미리 만들어진 스크립트를 다음과 함께 사용하세요. крайней 주의와 자기 책임으로. 작성자는 이 코드를 직접 작성했으며 자신을 위해 독점적으로 작성했습니다. 숙련된 Linux 사용자 중 다수가 유사한 도구를 갖고 있으므로 다른 사람의 도구를 복사할 필요가 없다고 확신합니다.

백업 장치에 볼륨을 생성해 보겠습니다.

#lvcreate -L 256G --name backup backup

BTRFS로 형식을 지정해 보겠습니다.

#mkfs.btrfs /dev/backup/backup

마운트 지점을 생성하고 파일 시스템의 루트 하위 섹션을 마운트해 보겠습니다.

#mkdir /backup
#mkdir /backup/btrfs
#mkdir /backup/btrfs/root
#mkdir /backup/btrfs/back
#ln -s /boot /backup/btrfs
# cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2
/dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2
EOF
#mount -a
#update-initramfs -u
#update-grub

백업용 디렉터리를 만들어 보겠습니다.

#mkdir /backup/btrfs/back/remote
#mkdir /backup/btrfs/back/remote/root
#mkdir /backup/btrfs/back/remote/boot

백업 스크립트용 디렉터리를 만들어 보겠습니다.

#mkdir /root/btrfs-backup

스크립트를 복사해 보겠습니다.

무서운 bash 코드가 많이 있습니다. 자신의 책임하에 사용하십시오. 작가에게 화난 편지를 쓰지 마세요...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".@base"
PEND_SUFFIX=".@pend"
SNAP_SUFFIX=".@snap"
MOUNTS="/backup/btrfs/"
BACKUPS="/backup/btrfs/back/remote/"

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function backup()
{
SOURCE_PATH="$MOUNTS$1"
TARGET_PATH="$BACKUPS$1"
SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"
TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"
SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"
TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"
if [ -d "$SOURCE_BASE_PATH" ] then
echo "$SOURCE_BASE_PATH found"
else
echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found out of sync with source... removing..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found"
else
echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
fi
if [ -d "$SOURCE_PEND_PATH" ] then
echo "$SOURCE_PEND_PATH found removing..."
btrfs subvolume delete -c $SOURCE_PEND_PATH
sync
fi
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ] then
echo "$TARGET_PEND_PATH found removing..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs subvolume delete -c $SOURCE_BASE_PATH
sync
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH
mv $TARGET_PEND_PATH $TARGET_BASE_PATH
sync
}

function list()
{
LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"
LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"
find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"
btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2
sync
}

function removeall()
{
DATE_OFFSET="$2"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$1" "$SNAPSHOT"
done < <(list "$1" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1"
;;
"list")
list "$1"
;;
"remove")
wait_lock_or_terminate
remove "$1" "$2"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


그것은 무엇을 하는가..?BTRFS 스냅샷을 생성하고 BTRFS 보내기/받기를 사용하여 다른 FS에 복사하기 위한 간단한 명령 세트가 포함되어 있습니다.

첫 번째 출시는 상대적으로 길 수 있습니다. 왜냐하면... 처음에는 모든 데이터가 복사됩니다. 추가 출시는 매우 빠를 것입니다. 왜냐하면... 변경사항만 복사됩니다.

cron에 넣을 또 다른 스크립트는 다음과 같습니다.

더 많은 bash 코드#cat >/root/btrfs-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh"
RETENTION="-60 day"
$BACKUP_SCRIPT backup root/@
$BACKUP_SCRIPT removeall root/@ "$RETENTION"
$BACKUP_SCRIPT backup root/@home
$BACKUP_SCRIPT removeall root/@home "$RETENTION"
$BACKUP_SCRIPT backup boot/
$BACKUP_SCRIPT removeall boot/ "$RETENTION"
EOF


그것은 무엇을 하는가..?백업 FS에 나열된 BTRFS 볼륨의 증분 스냅샷을 생성하고 동기화합니다. 그 후에는 60일 전에 생성된 모든 사진이 삭제됩니다. 실행 후 나열된 볼륨의 날짜가 지정된 스냅샷이 /backup/btrfs/back/remote/ 하위 디렉터리에 나타납니다.

코드 실행 권한을 부여해 보겠습니다.

#chmod +x /root/btrfs-backup/cron-daily.sh
#chmod +x /root/btrfs-backup/btrfs-backup.sh

그것을 확인하고 cron에 넣어봅시다:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup
#cat /var/log/syslog | grep btrfs-backup
#crontab -e
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup


LVM 씬 백업

백업 디바이스에 가상 풀을 생성해 보겠습니다.

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

ddrescue를 설치해 봅시다. 왜냐면... 스크립트는 이 도구를 사용합니다:

#apt-get install gddrescue

스크립트용 디렉터리를 만들어 보겠습니다.

#mkdir /root/lvm-thin-backup

스크립트를 복사해 보겠습니다.

내부에 배쉬가 많이 있습니다 ...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".base"
PEND_SUFFIX=".pend"
SNAP_SUFFIX=".snap"
BACKUPS="backup"
BACKUPS_POOL="thin-pool"

export LVM_SUPPRESS_FD_WARNINGS=1

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function read_thin_id {
lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'
}

function read_pool_lv {
lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'
}

function read_lv_dm_path {
lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'
}

function read_lv_active {
lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'
}

function read_lv_chunk_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'
}

function read_lv_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'
}

function activate_volume {
lvchange -ay -Ky "$1/$2"
}

function deactivate_volume {
lvchange -an "$1/$2"
}

function read_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

function thindiff()
{
DIFF_VG="$1"
DIFF_SOURCE="$2"
DIFF_TARGET="$3"
DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)

if [ "$DIFF_SOURCE_POOL" == "" ] then
(>&2 echo "Source LV is not thin.")
exit 1
fi

if [ "$DIFF_TARGET_POOL" == "" ] then
(>&2 echo "Target LV is not thin.")
exit 1
fi

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ] then
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
fi

DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)
DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)
DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"
DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" != "-" ] then
(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")
sleep 5
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
fi

dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" == "-" ] then
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
fi

#We keep output in variable because metadata snapshot need to be released early.
DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'

}

function thinsync()
{
SYNC_VG="$1"
SYNC_PEND="$2"
SYNC_BASE="$3"
SYNC_TARGET="$4"
SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)
SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)

activate_volume $SYNC_VG $SYNC_PEND

while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
if [ "$SYNC_ACTION" == "copy" ] then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

if [ "$SYNC_ACTION" == "discard" ] then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

function discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
if [ "$DISCARD_LV_PATH" != "" ] then
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
fi
DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)
DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")
lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1
}

function backup()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"
TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
sync
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
sync
fi
fi
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1
echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)
TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
echo "Discarding target at $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
if [ "$SOURCE_PEND_LV_PATH" != "" ] then
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
if [ "$TARGET_PEND_LV_PATH" != "" ] then
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")
lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"
activate_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1
sync

TARGET_DATE_SUFFIX=$(suffix)
lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1
sync
lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1
sync
lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1
sync
lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1
lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1
sync
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function verify()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function resync()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"

CMP_OFFSET=0
while [[ "$CMP_OFFSET" != "" ]] ; do
CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )
if [[ "$CMP_MISMATCH" != "" ]] ; then
CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))
SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))
SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))
echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
else
CMP_OFFSET=""
fi
done
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function list()
{
LIST_SOURCE_VG="$1"
LIST_SOURCE_LV="$2"
LIST_TARGET_VG="$BACKUPS"
LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"
LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"
lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_VG="$BACKUPS"
REMOVE_TARGET_LV="$1"
lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"
sync
}

function removeall()
{
DATE_OFFSET="$3"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
wait_lock_or_terminate
verify "$1" "$2"
;;
"resync")
wait_lock_or_terminate
resync "$1" "$2"
;;
"remove")
wait_lock_or_terminate
remove "$1"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2" "$3"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


그것은 무엇을 하는가...?씬 스냅샷을 조작하고 ddrescue 및 blkdiscard를 사용하여 Thin_delta를 통해 수신된 두 씬 스냅샷 간의 차이를 다른 블록 장치와 동기화하기 위한 명령 세트가 포함되어 있습니다.

cron에 넣을 또 다른 스크립트는 다음과 같습니다.

조금 더 배쉬#cat >/root/lvm-thin-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"
RETENTION="-60 days"

$BACKUP_SCRIPT backup images linux-dev
$BACKUP_SCRIPT backup images win8
$BACKUP_SCRIPT backup images win8-data
#etc

$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"
$BACKUP_SCRIPT removeall images win8 "$RETENTION"
$BACKUP_SCRIPT removeall images win8-data "$RETENTION"
#etc

EOF


그것은 무엇을 하는가...?이전 스크립트를 사용하여 나열된 씬 볼륨의 백업을 생성하고 동기화합니다. 스크립트는 마지막 동기화 이후 변경 사항을 추적하는 데 필요한 나열된 볼륨의 비활성 스냅샷을 남겨 둡니다.

백업 복사본을 만들어야 하는 씬 볼륨 목록을 지정하여 이 스크립트를 편집해야 합니다. 제공된 이름은 설명 목적으로만 사용됩니다. 원하는 경우 모든 볼륨을 동기화하는 스크립트를 작성할 수 있습니다.

권리를 부여합시다 :

#chmod +x /root/lvm-thin-backup/cron-daily.sh
#chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

그것을 확인하고 cron에 넣어봅시다:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
#cat /var/log/syslog | grep lvm-thin-backup
#crontab -e
0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup

첫 번째 출시는 오랜 시간이 걸릴 것이기 때문에... 씬 볼륨은 사용된 모든 공간을 복사하여 완전히 동기화됩니다. LVM 씬 메타데이터 덕분에 어떤 블록이 실제로 사용 중인지 알 수 있으므로 실제로 사용된 씬 볼륨 블록만 복사됩니다.

후속 실행은 LVM 씬 메타데이터를 통한 변경 사항 추적 덕분에 데이터를 증분적으로 복사합니다.

무슨 일이 일어났는지 봅시다:

#time /root/btrfs-backup/cron-daily.sh
real 0m2,967s
user 0m0,225s
sys 0m0,353s

#time /root/lvm-thin-backup/cron-daily.sh
real 1m2,710s
user 0m12,721s
sys 0m6,671s

#ls -al /backup/btrfs/back/remote/*
/backup/btrfs/back/remote/boot:
total 0
drwxr-xr-x 1 root root 1260 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 322 мар 26 02:00 .@base
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base
drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup
LV LSize
linux-dev 128,00g
linux-dev.base 128,00g
thin-pool 1,38t
win8 128,00g
win8-data 2,00t
win8-data.base 2,00t
win8.base 128,00g
LV LSize
backup 256,00g
images-linux-dev.base 128,00g
images-linux-dev.snap.2020-03-08-10-09-11 128,00g
images-linux-dev.snap.2020-03-08-10-09-25 128,00g
...
images-win8-data.base 2,00t
images-win8-data.snap.2020-03-16-14-11-55 2,00t
images-win8-data.snap.2020-03-16-14-19-50 2,00t
...
images-win8.base 128,00g
images-win8.snap.2020-03-17-04-51-46 128,00g
images-win8.snap.2020-03-18-03-02-49 128,00g
...
thin-pool <2,09t


이것이 중첩 인형과 무슨 관련이 있나요?

LVM LV 논리 볼륨이 다른 VG에 대한 LVM PV 물리 볼륨일 수 있다는 점을 고려하면 가능성이 높습니다. LVM은 중첩 인형처럼 재귀적일 수 있습니다. 이는 LVM에 극도의 유연성을 제공합니다.

PS

다음 기사에서는 홈 데스크탑, 홈 인터넷 및 P2P 네트워크를 사용하여 여러 대륙에서 중복성을 갖춘 지리적 분산 스토리지/VM 클러스터를 생성하기 위한 기반으로 여러 유사한 모바일 스토리지 시스템/KVM을 사용하려고 합니다.

출처 : habr.com