LVM 위험과 경고

최근에 일부 서버에서 1TB보다 큰 하드 드라이브에 LVM을 사용하기 시작했습니다. 유용하고 확장 가능하며 설치가 매우 쉽습니다. 그러나 LVM의 위험과 경고에 대한 데이터를 찾을 수 없습니다.

LVM 사용의 단점은 무엇입니까?

요약

LVM 사용의 위험 :

• SSD 또는 VM 하이퍼 바이저의 캐싱 문제 작성 취약
• 보다 복잡한 온 디스크 구조로 인해 데이터를 복구하기가 더 어렵습니다.
• 파일 시스템의 크기를 올바르게 조정하기가 더 어렵다
• 스냅 샷은 사용하기 어렵고 느리고 버그가 있습니다
• 이러한 문제를 감안할 때 약간의 기술이 필요합니다.

처음 두 개의 LVM 문제는 다음과 같이 결합됩니다. 쓰기 캐싱이 제대로 작동하지 않고 전력 손실 (예 : PSU 또는 UPS 실패)이 발생하면 백업에서 복구해야 할 수 있으므로 상당한 다운 타임이 발생합니다. LVM을 사용하는 주된 이유는 가동 시간이 더 길기 때문에 (디스크 추가, 파일 시스템 크기 조정 등) LVM이 실제로 가동 시간을 줄이지 않도록 쓰기 캐싱 설정을 올바르게하는 것이 중요합니다.

-2018 년 12 월 업데이트 : LVM 스냅 샷의 대안으로 ZFS 및 btrfs의 안정성을 포함하여 업데이트 된 스냅 샷 자료

위험 완화

다음과 같은 경우 LVM은 여전히 ​​잘 작동합니다.

• 하이퍼 바이저, 커널 및 SSD에서 바로 쓰기 캐싱 설정
• LVM 스냅 샷 방지
• 최신 LVM 버전을 사용하여 파일 시스템 크기 조정
• 좋은 백업 되세요

세부

나는 과거에 LVM과 관련된 데이터 손실을 경험 한 적이 상당히 많았습니다. 내가 아는 주요 LVM 위험과 문제는 다음과 같습니다.

VM 하이퍼 바이저, 디스크 캐싱 또는 오래된 Linux 커널로 인해 하드 디스크 쓰기 캐싱에 취약하며 보다 복잡한 온 디스크 구조로 인해 데이터를 복구하기가 어렵습니다. 자세한 내용은 아래를 참조하십시오. 여러 디스크의 완전한 LVM 설정이 복구 가능성없이 손상되는 것을 보았으며 LVM과 하드 디스크 쓰기 캐싱은 위험한 조합입니다.

• 하드 드라이브의 쓰기 캐싱 및 쓰기 순서 변경 은 성능을 높이는 데 중요하지만 VM 하이퍼 바이저, 하드 드라이브 쓰기 캐싱, 오래된 Linux 커널 등으로 인해 블록을 디스크로 올바르게 플러시하지 못할 수 있습니다.
  • 쓰기 장벽 은 커널이 "배리어"디스크 쓰기 전에 특정 디스크 쓰기를 완료하여 갑작스러운 전원 손실 또는 충돌시 파일 시스템 및 RAID가 복구 될 수 있도록 보장합니다. 이러한 장벽은 FUA (Force Unit Access) 작업 을 사용하여 특정 블록을 디스크에 즉시 쓰므 로 전체 캐시 플러시보다 효율적입니다. 배리어는 효율적인 태그 / 네이티브 명령 큐잉 (한 번에 여러 디스크 I / O 요청 발행) 과 결합 하여 하드 드라이브가 데이터 손실 위험을 증가시키지 않으면 서 지능적인 쓰기 재정렬을 수행 할 수 있도록합니다.
• VM 하이퍼 바이저 도 비슷한 문제가있을 수 있습니다. VMware, Xen , KVM, Hyper-V 또는 VirtualBox 와 같은 VM 하이퍼 바이저에서 Linux 게스트에서 LVM을 실행 하면 쓰기 캐싱 및 쓰기 다시 쓰기로 인해 쓰기 장벽이없는 커널에 유사한 문제 가 발생할 수 있습니다. 주문. 하이퍼 바이저 설명서에서 "디스크 비우기"또는 연속 기입 캐시 옵션 ( KVM , VMware , Xen , VirtualBox 및 기타에 있음)에 대해 신중하게 확인한 후 설정으로 테스트하십시오. VirtualBox와 같은 일부 하이퍼 바이저 에는 게스트의 디스크 플러시를 무시 하는 기본 설정 이 있습니다.
• LVM이있는 엔터프라이즈 서버는 항상 배터리 지원 RAID 컨트롤러 를 사용하고 하드 디스크 쓰기 캐싱을 비활성화해야합니다 (컨트롤러에는 배터리 백업 쓰기 캐시가 빠르고 안전합니다) . 이 XFS FAQ 항목 작성자 의이 주석 을 참조하십시오 . 커널에서 쓰기 장벽 을 해제하는 것이 안전 할 수도 있지만 테스트하는 것이 좋습니다.
• 배터리 지원 RAID 컨트롤러가없는 경우 하드 드라이브 쓰기 캐싱을 비활성화하면 쓰기 속도가 크게 느려지지만 LVM은 안전합니다. 또한 커널 캐싱이 무결성에 영향을 미치지 않도록 ext3의 data=ordered옵션 (또는 data=journal추가 안전 barrier=1을 위해 ) 과 동등한 옵션을 사용해야합니다 . (또는 기본적으로 장벽 을 활성화 하는 ext4를 사용하십시오 .) 가장 간단한 옵션이며 성능 비용으로 우수한 데이터 무결성을 제공합니다. (리눅스 는 기본 ext3 옵션 을 더 위험한 data=writeback것으로 변경 했으므로 FS의 기본 설정에 의존하지 마십시오.)
• 하드 드라이브 쓰기 캐싱을 비활성화하려면 : (SATA의 경우) hdparm -q -W0 /dev/sdX모든 드라이브를 추가 /etc/rc.local하거나 SCSI / SAS에 sdparm을 사용하십시오. 그러나 XFS FAQ 의이 항목 에 따르면 (이 주제에 매우 적합 함) 드라이브 오류 복구 후 SATA 드라이브가이 설정을 잊어 버릴 수 있습니다. 따라서 SCSI / SAS를 사용하거나 SATA를 사용해야하는 경우 매분 정도 실행되는 크론 작업의 hdparm 명령.
• 성능 향상 을 위해 SSD / 하드 드라이브 쓰기 캐싱을 활성화하려면 복잡한 영역입니다. 아래 섹션을 참조하십시오.
• 4KB 물리 섹터와 같은 고급 포맷 드라이브를 사용하는 경우 아래를 참조하십시오. 쓰기 캐싱을 비활성화하면 다른 문제가 발생할 수 있습니다.
• UPS 는 엔터프라이즈와 SOHO 모두에게 중요하지만 LVM을 안전하게 보호하기에는 충분하지 않습니다. 하드 크래시 또는 전원 손실 (예 : UPS 오류, PSU 오류 또는 랩탑 배터리 소진)은 하드 드라이브 캐시의 데이터를 잃을 수 있습니다.
• 아주 오래된 리눅스 커널 (2009 년 2.6.x) : 아주 오래된 커널 버전 2.6.32 이전에는 불완전한 쓰기 장벽 지원이 있습니다 ( 2.6.31은 약간의 지원 이 있고 2.6.33은 모든 유형의 장치 대상에서 작동 합니다)- RHEL 6은 많은 패치와 함께 2.6.32 를 사용합니다 . 이러한 이전 2.6 커널이 이러한 문제로 패치되지 않은 경우 하드 드라이브의 쓰기 버퍼에 데이터를 남겨 두는 하드 크래시 (일반 SATA 드라이브의 경우 드라이브 당 32MB)로 인해 대량의 FS 메타 데이터 (저널 포함)가 손실 될 수 있습니다. 커널이 이미 디스크에 있다고 생각하는 가장 최근에 작성된 FS 메타 데이터 및 저널 데이터의 32MB를 잃는 것은 대개 많은 FS 손상 및 데이터 손실을 의미합니다.
• 요약 : LVM과 함께 사용되는 파일 시스템, RAID, VM 하이퍼 바이저 및 하드 드라이브 / SSD 설정에주의해야합니다. LVM을 사용하는 경우 백업이 매우 양호해야하며 LVM 메타 데이터, 물리 분할 설정, MBR 및 볼륨 부트 섹터를 구체적으로 백업해야합니다. SCSI / SAS 드라이브는 쓰기 캐싱 방법에 대해 거짓말을 할 가능성이 적으므로 SATA 드라이브를 사용하는 것이 좋습니다. SATA 드라이브를 사용하려면 더 많은주의가 필요합니다.

성능을 위해 쓰기 캐싱을 사용 가능하게 유지 (및 거짓말 드라이브에 대처)

보다 복잡하지만 성능이 뛰어난 옵션은 SSD / 하드 드라이브 쓰기 캐싱을 활성화하고 커널 2.6.33+에서 LVM과 함께 작동하는 커널 쓰기 장벽에 의존하는 것입니다 (로그에서 "배리어"메시지를 찾아 두 번 확인).

또한 RAID 설정, VM 하이퍼 바이저 설정 및 파일 시스템 이 쓰기 장벽을 사용 하는지 확인해야합니다 (즉, 드라이브는 주요 메타 데이터 / 저널 쓰기 전후에 보류중인 쓰기를 플러시해야합니다). XFS는 기본적으로 사용 장벽을 수행하지만, ext3로하지 않습니다 사용한다 EXT3으로, 그래서 barrier=1마운트 옵션에서 여전히 사용 data=ordered또는 data=journal위와 같이.

• 불행히도 일부 하드 드라이브와 SSD 는 실제로 캐시 를 디스크로 플러시했는지 (특히 오래된 드라이브이지만 일부 SATA 드라이브와 일부 엔터프라이즈 SSD 포함 ) 여부에 대해 자세히 설명합니다 . XFS 개발자 의 훌륭한 요약이 있습니다 .
• 거기의 드라이브를 거짓말에 대한 간단한 테스트 도구 (펄 스크립트), 또는 참조 다른 툴이 배경 드라이브 캐시의 결과로 쓰기 재정렬에 대한 테스트를. 이 답변 에는 소프트웨어 RAID의 쓰기 장벽 문제를 발견 한 SATA 드라이브의 유사한 테스트 가 포함되었습니다. 이러한 테스트는 실제로 전체 스토리지 스택을 실행합니다.
• NCQ ( Native Command Queuing)를 지원하는 최신 SATA 드라이브 는 거짓말을 할 가능성 이 적 거나 NCQ로 인해 쓰기 캐싱없이 제대로 작동하며 쓰기 캐싱을 비활성화 할 수없는 드라이브는 거의 없습니다.
• SCSI / SAS 드라이브는 일반적으로 SATA의 NCQ와 유사한 SCSI Tagged Command Queuing을 통해 쓰기 캐싱이 필요하지 않기 때문에 정상 입니다.
• 하드 드라이브 또는 SSD가 캐시를 디스크로 플러시하는 데 거짓말을하는 경우 실제로 쓰기 장벽에 의존 할 수 없으며 쓰기 캐싱을 비활성화해야합니다. 이것은 LVM뿐만 아니라 모든 파일 시스템, 데이터베이스, 볼륨 관리자 및 소프트웨어 RAID에 대한 문제입니다 .

쓰기 캐시 사용이 SSD 수명에 중요하기 때문에 SSD 는 문제가됩니다. 수퍼 커패시터가있는 SSD를 사용하는 것이 가장 좋습니다 (정전시 캐시 플러시를 활성화하여 캐시가 후기 입이 아닌 후기 입 가능).

• 쓰기 캐시 제어시 대부분의 엔터프라이즈 SSD는 정상이어야하며 일부는 수퍼 커패시터를 포함합니다.
• 일부 저렴한 SSD에는 쓰기 캐시 구성으로 해결할 수없는 문제가 있습니다 . PostgreSQL 프로젝트의 메일 링리스트 및 안정적인 쓰기 위키 페이지 는 좋은 정보 소스입니다. 소비자 SSD 에는 데이터 쓰기 를 유발하는 주요 쓰기 캐싱 문제 가있을 수 있으며 슈퍼 커패시터가 포함되어 있지 않으므로 정전으로 인해 손상 될 수 있습니다.

고급 포맷 드라이브 설정-쓰기 캐싱, 정렬, RAID, GPT

• 4 개의 KiB 물리 섹터를 사용하는 최신 Advanced Format 드라이브 에서는 드라이브 쓰기 캐싱을 유지하는 것이 중요 할 수 있습니다. 대부분의 이러한 드라이브는 현재 512 바이트 논리 섹터 ( "512 에뮬레이션" )를 에뮬레이션 하고 일부는 512 바이트 물리 실제로 4 KiB를 사용하는 동안
• 고급 포맷 드라이브의 쓰기 캐시를 끄면 애플리케이션 / 커널이 512 바이트 쓰기를 수행하는 경우 성능에 큰 영향을 미칠 수 있습니다. 드라이브는 캐시를 사용하여 단일 4 KiB 물리적을 수행하기 전에 8 x 512 바이트 쓰기를 누적합니다. 쓰다. 캐시를 비활성화하면 영향을 확인하기 위해 테스트하는 것이 좋습니다.
• 4 KiB 경계에서 LV를 정렬하는 것은 성능에 중요하지만 LVM PE (Physical Extents)가 기본적으로 4MiB이므로 PV의 기본 파티션이 정렬되는 한 자동으로 발생해야합니다. 여기에서 RAID를 고려해야합니다.이 LVM 및 소프트웨어 RAID 설정 페이지 에서는 볼륨의 끝에 RAID 수퍼 블록을 배치하고 필요에 pvcreate따라 PV를 정렬 하는 옵션을 사용하여 RAID 수퍼 블록을 배치 할 것을 제안 합니다. 이 LVM 전자 메일 목록 스레드 는 2011 년 동안 커널에서 수행 한 작업과 단일 LV에서 512 바이트 및 4KiB 섹터로 디스크를 혼합 할 때 부분 블록 쓰기 문제를 가리 킵니다.
• 고급 포맷을 사용한 GPT 파티셔닝은 특히 부팅 + 루트 디스크에 대해 첫 번째 LVM 파티션 (PV)이 4 KiB 경계에서 시작되도록주의해야합니다.

보다 복잡한 온 디스크 구조로 인해 데이터를 복구하기가 더 어렵습니다 .

• 적절한 도구가 없기 때문에 하드 크래쉬 또는 전원 손실 후 (잘못된 쓰기 캐싱으로 인해) 필요한 LVM 데이터를 복구하는 것은 수동 프로세스입니다. LVM은의 메타 데이터를 백업하는 데 능숙하여 /etc/lvmLV, VG 및 PV의 기본 구조를 복원 할 수 있지만 파일 시스템 메타 데이터 손실에 도움이되지는 않습니다.
• 따라서 백업에서 전체 복원이 필요할 수 있습니다. 여기에는 LVM을 사용하지 않을 때 빠른 저널 기반 fsck보다 훨씬 많은 다운 타임이 포함되며 마지막 백업 이후 작성된 데이터는 손실됩니다.
• TestDisk , ext3grep , ext3undel 및 기타 도구 는 비 LVM 디스크에서 파티션 및 파일을 복구 할 수 있지만 LVM 데이터 복구를 직접 지원하지는 않습니다. TestDisk는 손실 된 물리 분할에 LVM PV가 포함되어 있음을 발견 할 수 있지만 이러한 도구 중 어느 것도 LVM 논리 볼륨을 이해하지 못합니다. PhotoRec 와 같은 파일 조각 도구 및 파일 도구 는 파일 시스템을 우회하여 데이터 블록에서 파일을 다시 어셈블 할 때 작동하지만 귀중한 데이터에 대한 최후의 최하위 수준의 접근 방식이며 조각난 파일에는 덜 적합합니다.
• 수동 LVM 복구 어떤 경우에는 가능하지만, 복잡하고 시간이 소요됩니다 - 볼 이 예제를 하고 이 , 이 , 및 이 에 대한 복구하는 방법.

파일 시스템의 크기를 정확하게 조정하기 어렵습니다 -쉬운 파일 시스템 크기 조정은 LVM의 이점으로 제공되는 경우가 많지만 LVM 기반 FS의 크기를 조정하려면 6 가지 쉘 명령을 실행해야합니다. 이는 전체 서버에서 여전히 가능하며 경우에 따라 가능합니다. FS를 마운트 한 상태에서 최신 백업을 수행하지 않고 동등한 서버 (예 : 프로덕션 서버의 재해 복구 복제본)에서 사전 테스트 된 명령을 사용하여 후자를 위험에 빠뜨리지 않습니다.

• 업데이트 : 최신 버전의 lvextend지원 -r( --resizefs) 옵션-사용 가능한 경우 특히 FS를 축소하는 경우 LV와 파일 시스템의 크기를 조정하는 것이 더 안전하고 빠른 방법이며 대부분이 섹션을 건너 뛸 수 있습니다.
• LVM 기반 FS 크기 조정에 대한 대부분의 안내서는 FS가 LV의 크기보다 약간 작아야한다는 사실을 고려하지 않습니다. 자세한 설명은 여기를 참조하십시오 . 파일 시스템을 축소 할 때는 새로운 크기를 FS 크기 조정 도구 (예 : resize2fsext3) 및 lvextend또는 또는 로 지정해야합니다 lvreduce. 주의를 기울이지 않으면 1GB (10 ^ 9)와 1GiB (2 ^ 30)의 차이 또는 다양한 도구가 크기를 올림 또는 내림하는 방식 으로 인해 크기가 약간 다를 수 있습니다 .
• 계산을 정확하게 수행하지 않으면 (또는 가장 명백한 단계를 넘어서는 추가 단계를 사용하면) LV에 비해 너무 큰 FS로 끝날 수 있습니다. FS를 완전히 채울 때까지 몇 달 또는 몇 년 동안 모든 것이 좋아 보일 것입니다.이 시점에서 심각한 손상을 입을 수 있습니다.이 문제를 알지 못하면 그 당시 실제 디스크 오류가 발생할 수 있으므로 이유를 찾기가 어렵습니다. 그 상황을 구름. (이 문제는 파일 시스템의 크기를 줄이는 데만 영향을 줄 수 있지만, 파일 시스템의 크기를 어느 방향 으로든 조정하면 사용자 오류로 인해 데이터 손실의 위험이 증가한다는 것이 분명합니다.)

• LV 크기는 FS 크기보다 2 x LVM PE (Physical Extent) 크기만큼 커야합니다. 그러나이 링크의 출처는 신뢰할 수 없으므로 자세한 내용은 위의 링크를 확인하십시오. 종종 8MiB를 허용하는 것으로 충분하지만, 예를 들어 100MiB 또는 1GiB를 더 안전하게하는 것이 더 안전 할 수 있습니다. 4 KiB = 4096 바이트 블록을 사용하여 PE 크기 및 논리 볼륨 + FS 크기를 확인하려면 다음을 수행하십시오.

  KiB의 PE 크기 :
  vgdisplay --units k myVGname | grep "PE Size"
  
  모든 LV의 크기 :
  lvs --units 4096b
  
  (ext3) FS의 크기, 4 개의 KiB FS 블록 크기를 가정합니다.
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• 반대로, 비 LVM 설정은 FS 크기를 매우 안정적으로 쉽게 조정할 수 있도록합니다. Gparted를 실행 하고 필요한 FS 크기를 조정하면 모든 것이 가능합니다. 서버에서는 parted셸에서 사용할 수 있습니다 .

  • Gparted Live CD 또는 Parted Magic 을 사용하는 것이 가장 좋습니다. 이것은 배포판 버전보다 최근에 버그가없는 Gparted & 커널이 많기 때문에 배포판의 Gparted가 파티션을 제대로 업데이트하지 않아서 전체 FS를 잃어 버렸습니다. 핵심. 배포판의 Gparted를 사용하는 경우, 파티션을 변경 한 직후 커널을 다시 볼 수 있도록 재부팅해야합니다.

스냅 샷은 사용하기 어렵고 느리고 버그 가 있습니다. 스냅 샷에 사전 할당 된 공간이 부족하면 자동으로 삭제 됩니다. 지정된 LV의 각 스냅 샷은 해당 LV에 대한 델타 (이전 스냅 샷이 아님)이며 쓰기 작업이 많은 파일 시스템을 스냅 샷 할 때 많은 공간이 필요할 수 있습니다 (모든 스냅 샷이 이전 스냅 샷보다 큼). 스냅 샷에 여유 공간이 부족하지 않기 때문에 원래 LV와 동일한 크기의 스냅 샷 LV를 생성하는 것이 안전합니다.

스냅 샷도 매우 느릴 수 있습니다 ( 이러한 MySQL 테스트에서 LVM이없는 것보다 3 ~ 6 배 느림 ) . 다양한 스냅 샷 문제를 다루는이 답변을 참조하십시오 . 스냅 샷에 많은 동기 쓰기가 필요 하기 때문에 속도가 느려집니다 .

스냅 샷은 예 몇 가지 중요한 버그, 있었다 어떤 경우에는 그들이 부팅이 매우 느리게 만들거나 때문에 (완전 실패 부팅 될 수 있습니다 커널이 제한 시간을 초과 할 수 있습니다 그것은 [데비안에 고정 된 LVM 스냅 샷 때 루트 FS 대기 initramfs-tools2015 년 3 월 갱신] ).

• 그러나 많은 스냅 샷 경쟁 조건 버그는 2015 년에 수정 되었습니다.
• 스냅 샷이없는 LVM은 일반적으로 스냅 샷이 핵심 기능만큼 많이 사용되지 않기 때문에 상당히 잘 디버깅 된 것으로 보입니다.

스냅 샷 대안 -파일 시스템 및 VM 하이퍼 바이저

VM / 클라우드 스냅 샷 :

• VM 하이퍼 바이저 또는 IaaS 클라우드 공급자 (예 : VMware, VirtualBox 또는 Amazon EC2 / EBS)를 사용하는 경우 스냅 샷이 LVM 스냅 샷보다 훨씬 나은 대안 인 경우가 많습니다. 백업 목적으로 스냅 샷을 쉽게 만들 수 있습니다 (그러나 수행하기 전에 FS 정지를 고려하십시오).

파일 시스템 스냅 샷 :

• ZFS 또는 btrfs를 사용한 파일 시스템 레벨 스냅 샷은 사용하기 쉽고 일반적으로 LVM보다 우수합니다 (ZFS는 훨씬 더 성숙해 보이고 설치하기 더 번거 로움).

  • ZFS : 몇 년 동안 사용되어 온 커널 ZFS 구현 이 있습니다.
  • btrfs : 프로덕션 사용 준비가 아직 완료되지 않았 으며 (기본적으로 출하되고 btrfs 전용 팀을 보유한 openSUSE에서도 ) RHEL에서 지원을 중단했으며 fsck 및 repair 도구 는 아직 개발 중입니다.

온라인 백업 및 fsck에 대한 스냅 샷

할당 된 공간에주의를 기울이는 한 스냅 샷을 사용하여 백업 의 일관된 소스 를 제공 할 수 있습니다 (이상적으로는 스냅 샷이 백업되는 LV와 크기가 동일 함). 우수한 rsnapshot (1.3.1부터)도 LVM 스냅 샷 생성 / 삭제를 관리합니다. LVM을 사용하여 rsnapshot에 대한이 하우투를 참조하십시오 . 그러나 스냅 샷의 일반적인 문제와 스냅 샷 자체는 백업으로 간주되어서는 안됩니다.

좌심실 스냅 샷 여전히 주요 스냅 샷이 아닌 FS 사용하는 동안, 스냅 샷을 fsck로 - : 당신은 또한 온라인으로 fsck를 할 LVM 스냅 샷을 사용할 수 있습니다 여기에 설명을 하지만, 그건 - 전혀 간단하지 가 사용하는 것이 가장 좋습니다 그래서 e2croncheck 으로 테드 TS 설명 'o , ext3의 관리자.

스냅 샷을 만드는 동안 파일 시스템을 일시적으로 "고정" 해야합니다 . LVM이 스냅 샷을 만들 때 ext3 및 XFS와 같은 일부 파일 시스템 이이를 자동으로 수행합니다 .

결론

이 모든 것에도 불구하고 일부 시스템에서는 여전히 LVM을 사용하지만 데스크톱 설정에서는 원시 파티션을 선호합니다. LVM에서 볼 수있는 주요 이점 은 서버 가동 시간이 길어야하는 경우 FS를 이동하고 크기를 조정할 수있는 유연성입니다. 필요하지 않으면 gparted가 더 쉽고 데이터 손실 위험이 적습니다.

LVM은 VM 하이퍼 바이저, 하드 드라이브 / SSD 쓰기 캐싱 등으로 인해 쓰기 캐싱 설정에 세심한주의가 필요하지만 Linux를 DB 서버로 사용하는 경우에도 마찬가지입니다. gparted임계 크기 계산 등을 포함한 대부분의 도구의 지원이 부족 testdisk하여 사용하기가 더 어려워집니다.

LVM을 사용하는 경우 스냅 샷에주의를 기울이십시오. 가능하면 VM / 클라우드 스냅 샷을 사용하거나 LFS를 완전히 피하기 위해 ZFS / btrfs를 조사하십시오. 스냅 샷이있는 LVM에 비해 ZFS 또는 btr이 충분히 성숙 된 것을 알 수 있습니다.

결론 : 위에 나열된 문제와 해결 방법을 모르는 경우 LVM을 사용하지 않는 것이 가장 좋습니다.

나는 그 게시물을 +1하고, 적어도 나는 대부분의 문제가 존재한다고 생각한다. 몇 대의 서버와 몇 개의 100TB 데이터를 실행하는 동안 이들을 확인하십시오. 나에게 리눅스의 LVM2는 누군가가 가진 "영리한 아이디어"처럼 느껴진다. 이들 중 일부와 마찬가지로 그들은 때때로 "영리하지 않은"것으로 판명되었습니다. 즉, 커널과 사용자 공간 (lvmtab) 상태를 엄격하게 분리하지 않으면 손상 문제가 발생할 수 있기 때문에 실제로 해결해야 할 수도 있습니다 (코드가 맞지 않으면)

자,이 분리가 PV 손실 처리를 통한 차이점과 PV가 없어진 VG의 온라인 재 활성화 등의 이유로 인해 다시 시작되었다는 것입니다. "원래 LVM"의 바람은 무엇입니까 (AIX 상태 처리가 충분하지 않으므로 LVM2에서 HP-UX)가 불량으로 바뀝니다. 심지어 (. 내가 사용할 수없는 것으로 표시되지 않습니다 디스크를 제거하면 심지어하지 않습니다 나를 쿼럼 손실 감지 (하하) 또는 주 처리에 대해 얘기하지 않는 이 망할 상태 열)

다시 : 안정성 pvmove ... 왜

pvmove 데이터 손실

내 블로그에서 최고 순위 기사 hmmm? 지금은 phyiscal lvm 데이터가 여전히 pvmove 중반의 상태에 걸려있는 디스크를 봅니다. 내가 생각하는 몇 가지 기억이 있었고, 사용자 공간에서 라이브 블록 데이터를 복사하는 것이 좋은 생각은 슬프습니다. lvm 목록에서 인용 한 인용문은 "vgreduce --missing이 pvmove를 처리하지 않는 것 같습니다"라는 의미입니다. 실제로 pvmove 중에 디스크가 분리되면 lvm 관리 도구가 lvm에서 vi로 변경됩니다. 아 그리고 블록 읽기 / 쓰기 오류 후에 pvmove가 계속되고 실제로 더 이상 대상 장치에 데이터를 쓰지 않는 버그가 있습니다. 이런 씨발?

재 : 스냅 샷 새 데이터를 스냅 샷 lv 영역으로 업데이트 한 다음 스냅을 삭제하면 다시 병합하여 CoW가 안전하지 않게 수행됩니다. 즉, 새 데이터를 원래 LV로 최종 병합하는 동안 IO 스파이크가 심하며, 더 중요한 것은 데이터 손상 위험이 훨씬 더 높다는 것을 의미합니다. 벽, 그러나 원본.

이점은 3 대신에 1 번의 쓰기 작업을 수행하는 것입니다. 빠르고 유쾌하지 않은 알고리즘을 선택하는 것은 VMware와 MS 같은 사람들에게 "Unix"에서 기대하는 것입니다. 기본 데이터가 아닌 다른 디스크 드라이브 에 스냅 샷 백업 저장소가 있고 (물론 다른 하나에 백업하는 경우) 많은 성능 문제가 발생하지 않았습니다.

다시 : 장벽 나는 LVM에서 그것을 비난 할 수 있는지 확실하지 않습니다. 내가 아는 한 그것은 devmapper 문제였습니다. 그러나 최소한 2.6 커널부터 2.6.33까지이 문제에 대해 신경 쓰지 않는 것에 대한 비난이있을 수 있습니다. AFAIK Xen은 가상 머신에 O_DIRECT를 사용하는 유일한 하이퍼 바이저입니다. 커널 때문에 "루프"를 사용할 때의 문제 여전히 그것을 사용하여 캐시합니다. Virtualbox는 적어도 이와 같은 기능을 비활성화하는 설정이 있으며 Qemu / KVM은 일반적으로 캐싱을 허용하는 것으로 보입니다. 모든 FUSE FS에도 문제가 있습니다 (O_DIRECT 없음)

Re : 크기 LVM이 표시된 크기의 "반올림"을 수행한다고 생각합니다. 또는 GiB를 사용합니다. 어쨌든 VG Pe 크기를 사용하고 LV의 LE 번호를 곱해야합니다. 그것은 올바른 순 크기를 제공해야하며 그 문제는 항상 사용 문제입니다. fsck / mount (hello, ext3) 동안 그러한 것을 알지 못하거나 온라인 "fsck -n"(hello, ext3)이없는 파일 시스템에 의해 악화됩니다.

물론 그것은 당신이 그런 정보에 대한 좋은 소스를 찾을 수 없다는 것을 말하고 있습니다. "VRA를위한 LE는 몇 개입니까?" "PVRA, VGDA 등의 물리적 오프셋은 무엇입니까?"

LVM2는 원래의 것과 비교하여 "UNIX를 이해하지 못하는 사람들은 그것을 제대로 재발 명하지 못합니다."의 주요 예입니다.

몇 달 후 업데이트 : 지금까지 테스트를위한 "전체 스냅 샷"시나리오를 시작했습니다. 이들이 가득 차면 스냅 샷은 원래 LV가 아니라 차단됩니다. 내가 이것을 처음 게시했을 때 나는 틀렸다. 일부 문서에서 잘못된 정보를 찾았거나 이해했을 수도 있습니다. 내 설정에서 나는 항상 그것들을 채우지 못하게 매우 편집증이되어서 결코 수정되지 않았습니다. 스냅 샷을 확장 / 축소하는 것도 가능합니다.

여전히 해결하지 못한 것은 스냅 샷의 나이를 식별하는 방법입니다. 성능에 관해서는 "thin"페도라 프로젝트 페이지에 스냅 샷 기법이 개정되고있어 각 스냅 샷마다 속도가 느려지지 않는다는 메모가 있습니다. 그들이 어떻게 구현하고 있는지 모르겠습니다.

백업에 스냅 샷을 사용하려는 경우 스냅 샷이있을 때 주요 성능 저하에 대비하십시오. 자세한 내용은 여기를 참조 하십시오 . 그렇지 않으면 모두 좋습니다. 필자는 수십 대의 서버에서 몇 년 동안 lvm을 프로덕션 환경에서 사용해 왔지만 사용하는 주요 이유는 볼륨을 쉽게 확장 할 수없는 원자 적 스냅 샷이기 때문입니다.

btw 1TB 드라이브를 사용하려는 경우 파티션 정렬에 대해 기억하십시오.이 드라이브에는 아마도 4kB 물리 섹터가있을 것입니다.

아담,

또 다른 장점 : 새로운 물리 볼륨 (PV)을 추가하고 모든 데이터를 해당 PV로 옮긴 다음 서비스 중단없이 기존 PV를 제거 할 수 있습니다. 지난 5 년 동안이 기능을 4 번 이상 사용했습니다.

아직 명확하게 지적하지 못한 단점은 LVM2에 대해 다소 가파른 학습 곡선이 있다는 것입니다. 대부분 추상화에서 파일과 기본 미디어 사이에 생성됩니다. 서버 세트에서 집안일을 공유하는 소수의 사람들과 만 작업하는 경우 팀 전체에 엄청난 복잡성이 발생할 수 있습니다. IT 업무에 전념하는 대규모 팀에는 일반적으로 그러한 문제가 없습니다.

예를 들어, 우리는이 작업을 여기에서 광범위하게 사용하고 있으며 전체 팀에게 기본적으로, 언어 및 올바르게 부팅되지 않는 시스템 복구에 대한 기본 사항을 가르치는 데 시간이 걸렸습니다.

특히주의해야 할 한 가지 사항 : LVM2 논리 볼륨에서 부팅하는 경우 서버 충돌시 복구 작업이 어려워졌습니다. Knoppix와 친구들에게 항상 적합한 것은 아닙니다. 따라서 우리는 / boot 디렉토리가 자체 파티션에 있고 항상 작고 고유하다고 결정했습니다.

전반적으로, 나는 LVM2의 팬입니다.