답변:
LVM은 실제로 방해가되지 않도록 설계되었습니다. 사용자 공간의 관점에서 볼 때, 디스크 위에 "가상 물"의 또 다른 계층처럼 보이며, 모든 I / O가 실제에 도달하기 전에이를 통과해야한다고 상상하는 것이 당연합니다. 하드웨어.
그러나 그렇지 않습니다. 커널에는 이미 "파일에 쓰기"와 같은 고급 작업을 장치 드라이버에 연결하여 디스크의 실제 블록에 연결하는 매핑 (또는 실제로 여러 계층의 매핑)이 있어야합니다.
LVM을 사용하면 조회가 변경되지만 그게 전부입니다. (어쨌든 발생해야하므로 약간 다르게 수행하는 것은 무시할만한 성능 저하입니다.) 실제로 파일을 작성하는 경우 비트는 다른 방법으로 실제 미디어에 대한 직접 경로를 사용합니다.
LVM이 성능 문제를 일으킬 수있는 경우가 있습니다. LVM 블록이 기본 시스템과 올바르게 정렬되도록하려고합니다.이 시스템은 최신 배포판에서 자동으로 발생합니다. 그리고 당신은 같은 버그의 대상이 된 커널을 사용하지 않을 있는지 확인 이 하나 . 아, 그리고 LVM 스냅 샷을 사용하면 성능이 저하됩니다 (각 활성 스냅 샷에서 점점 증가합니다). 그러나 대부분 그 영향은 매우 적어야합니다.
마지막으로 : 어떻게 테스트 할 수 있습니까? 표준 디스크 벤치마킹 도구는 bonnie ++ 입니다. LVM으로 파티션을 만들고, 테스트하고, 지우고 (같은 장소에서 다른 요소를 동일하게 유지하기 위해) 일반 파일 시스템을 만들고 다시 벤치마킹하십시오. 그들은 거의 동일해야합니다.
LVM은 다른 모든 것과 마찬가지로 혼합 된 축복입니다.
성능과 관련하여 LVM은 비트가 디스크에 닿기 전에 읽어야하는 또 다른 추상화 계층이기 때문에 약간의 방해가됩니다. 대부분의 상황에서이 성능 저하는 실제로 측정 할 수 없습니다.
LVM의 장점은 데이터를 이동하지 않고도 기존 파일 시스템에 더 많은 스토리지를 추가 할 수 있다는 사실입니다. 대부분의 사람들은이 장점을 좋아합니다.
이러한 방식으로 사용되는 LVM의 한 가지 단점은 추가 스토리지가 디스크에 걸쳐있는 경우 (즉, 둘 이상의 디스크를 포함하는 경우) 디스크 장애로 인해 데이터 비용이 발생할 가능성이 높아진다는 것입니다. 파일 시스템이 두 개의 디스크에 걸쳐 있고 두 디스크 중 하나라도 실패하면 손실 될 수 있습니다. 대부분의 사람들에게 이것은 공간 대비 비용으로 인해 수용 가능한 위험입니다 (즉, 이것이 정말로 중요하다면 예산을 올바르게 수행해야합니다). 그리고 그들이 말했듯이 백업 이 양호 하기 때문 입니까?
저에게 LVM을 사용하지 않는 유일한 이유는 재난 복구가 제대로 정의되지 않았기 때문입니다. 스크램블링 된 OS가있는 LVM 볼륨이있는 디스크를 다른 컴퓨터에 쉽게 연결할 수없고 데이터를 복구 할 수 없습니다. LVM 볼륨을 복구하기위한 많은 지침에는 시간이 지남에 따라 vgcfgbackup을 실행 한 다음 결과 / etc / lvmconf 파일을 호스 볼륨을 호스팅하는 시스템에 복사하는 등의 단계가 포함 된 것 같습니다 . 마지막으로 이것을 보았을 때부터 3-4 년 안에 상황이 바뀌었기를 바랍니다. 그러나 개인적으로 저는 이런 이유로 LVM을 사용하지 않습니다.
그렇습니다.
귀하의 경우 호스트 시스템에 비해 VM이 상대적으로 작을 것으로 가정합니다. 이는 나중에 VM에서 스토리지를 확장 할 가능성이 높다는 것을 의미합니다. 이 작업은 VM에 다른 가상 디스크를 추가 한 다음 영향을받는 VM 파일 시스템을 늘리는 것이 가장 좋습니다. 가상 디스크가 호스트 시스템의 동일한 물리적 장치에있을 가능성이 있기 때문에 다중 디스크 스패닝 취약점이 없습니다.
VM이 전혀 중요하지 않다면 어떻게 든 호스트 시스템을 RAID로 사용하게되므로 나중에 스토리지를 확장 할 수있는 유연성이 떨어집니다. 따라서 LVM의 유연성은 필요하지 않을 것입니다.
따라서 호스트 시스템에서 LVM을 사용하지 않지만 LVM을 사용하도록 VM을 설치한다고 가정합니다.
일반적으로 : 새로운 복잡성 계층 ( "일명 더해야 할 일")을 추가하면 더 빠른 것이 없습니다. 참고 : 작업을 수행하는 방식으로 만 작업을 추가하고 변경하지는 않습니다.
어떻게 무언가를 측정 할 수 있습니까? 글쎄, 당신은 LVM으로 하나의 파티션을 만들고 하나는없는 파티션을 만든 다음, 일반적인 벤치 마크를 사용하여 실행하십시오. 의 사람들처럼
http://www.umiacs.umd.edu/~toaster/lvm-testing/
보이는 것처럼 속도에 약간의 영향 만 미칩니다. 그것은 벤치 마크를 실행 한 다른 사람의 발견과 일치하는 것으로 보입니다.
"ext4는 LVM을 사용하지 않고 다른 파일 시스템 벤치 마크보다 빠릅니다."Linux Kernel Mailing List 스레드
그러나 자체적으로 벤치마킹하고 사용하려는 하드웨어와 OS가 동일하게 작동하는지, 추가 복잡성 계층의 영향을 무시할 수있는 경우 탄력적 인 스토리지를 제공하는지 확인하십시오.
게스트 OS에 LVM을 추가해야하는 경우 : 게스트 OS가 탄력적 인 스토리지를 보유해야하는지 여부에 따라 달라 집니까? 필요에 따라 배포해야 할 사항이 결정됩니다.
lvm에서만 성능이 크게 저하되지는 않지만 기꺼이 가져 가려면 zfs를 대신 사용하십시오. 볼륨 관리 및 복구 기능과 다른 모든 훌륭한 기능을 이용할 수 있습니다.
lvm2가 읽기 및 쓰기 속도를 배가시킬 수 있다고 언급 한 사람은 없습니다 (raid0과 유사). 필자는 개인적으로 3 개의 동일한 디스크를 사용하고 스트립 모드에서 lvm2 이상을 읽고, 읽기 및 쓰기 작업은 1/3의 시간이 걸리며, 그 영향은 큰 영향을 미치며, 파일 시스템은 3 배 더 빠릅니다. 나는 알고있다 : 어떤 디스크도 고장 나고 그것들의 모든 데이터는 접근 할 수 없을 것이다. 그러나 BackUp이 반드시 필요하기 때문에 Raid, LVM2, ZFS와 같은 것은 ZUP가 BackUP을 피할 수 없기 때문에 손실을 의미하지는 않습니다. 그래서 나는 결코 미러링, raid5 등을 사용하지 않으며, 항상 최고의 성능을 얻기 위해 스트리핑을 사용하고 BackUP을 동기화했습니다. ZFS는 온더 플라이 압축에 적합하며, 복사 매개 변수가 1보다 큰 것은 미러링과 같지만 ZFS가 가지고 있고 다른 사람이없는 것 중 하나는 비트 썩음 (자발적으로 변경되는 비트)을 즉석에서 자동 복구하는 것입니다. 디스크가 꺼져 있습니다)
다시 시작하려면 : OS 용 lvm2로 스트라이핑 된 여러 (2 개 또는 3 개의) ssd (외부 업그레이드는 OS 복제본을 다시 실행)와 같은 외부 디스크의 백업용 ZFS 만 사용합니다. 변경 불가능한 OS를 사용하는 경향이 있습니다. 그리고 가상 머신과 같이 데이터를 위해 lvm2가 제거 된 다중 (6) 스피 닌 디스크를 사용하여 변경 사항을 다시 실행하십시오. 디스크가 고장 나면 디스크를 교체하고 마지막 백업 만 복원하면됩니다. 요즘에는 쓰기 속도가 1.8GiB / s에 가깝기 때문에 BackUP에서 하나의 가상 머신을 복원하는 데 30 초 (가상 머신 디스크 당 32GiB) 미만이 소요됩니다.
그래서 제 대답은 : 한 가지만 사용하고, 똑똑하고 각 부분의 장점을 최대한 활용하십시오. lvm2는 6 개의 회전 디스크를 사용할 때 mdraid 레벨 0보다 빠릅니다. ssd 스트리핑에 대한 하나의 경고, 2 및 3이 양호합니다. 쓰기 증폭은 제거 된 볼륨에 더 많은 ssd를 추가하면 쓰기 속도가 느려지는 주 원인 일 수 있습니다.
ssd 및 raid0 (스트립 된 볼륨)으로 경고하고, 사물을 완벽하게 정렬하고, 파일 시스템에서 클러스터 크기를 정확하게 지정하고, 뾰족한 크기 등으로 인해 아무도 저하되지 않습니다. 샘플 : 디스크 섹터는 2048이므로 최소 읽기 / 쓰기에서 2K는 512 바이트의 클러스터를 사용하는 파일 시스템을 사용하지 마십시오. 그보다 2K 또는 4K 클러스터 크기를 사용하는 것이 좋습니다. 이제 각각 2K 섹터 인 3xHDD를 사용하므로 모든 읽기 / 쓰기 최적화 파일 시스템 클러스터는 3x2K = 6K이지만 많은 파일 시스템에서는 불가능하지만 64K 클러스터 크기를 사용한다면 64K / 6K = 32 / 3, 불균형을 유발하므로 최적이 아닙니다. 최적의 군집 크기를 얻기 위해 수학을합니다.
최선의 결과는 다음과 같습니다. 클러스터 크기 = stripsize * 스트라이프의 디스크 수; 이렇게하면 각 읽기 / 쓰기의 크기가 모든 디스크가 작동하는 정확한 크기이므로 속도 향상이 거의 없습니다. 64K 스트라이프 크기의 디스크 3 개에 대한 192K 클러스터 크기의 예. 32K 스트라이프 크기의 6 디스크에 대한 다른 예 192K 클러스터 크기.
그리고 항상 4K, 8K, 16K, 32K, 64K 블록의 단일 디스크를 테스트해야합니다. 많은 디스크는 4K와 같이 숫자가 낮 으면 속도가 매우 좋지 않지만 64K, 128K 이상에서는 10 배 이상 빠른 시간을 제공합니다.
예, 큰 클러스터 크기를 사용하면 각 파일의 las 클러스터에서 공간 낭비를 잃을 수 있습니다 (각 1 바이트의 수백만 파일을 사용하는 경우). 샘플로 4K 클러스터 크기의 4TiB 디스크는 각각 1Byte의 4TiB / 4K = 1073741824 파일보다 작을 수 있습니다. 즉, 모든 파일이 1Byte 크기 (클러스터 크기 4K)이고 더 큰 클러스터 크기 최악의 비율 인 경우 1GiB입니다. 파일은 가상 머신과 같이 거대합니다 (샘플로서 32GiB 또는 몇 메가 바이트 근처). 손실은 마지막 클러스터에서만 발생합니다. 파일이 클수록 클러스터 크기가 클수록 성능이 훨씬 좋아 지지만 가상 시스템에서이를 사용하는 방법에주의하십시오.
아무도이 비밀을 말하지 않을 것입니다. 게스트 내부에서 4K 클러스터 크기를 사용하지 말고 가상 디스크가있는 클러스터 크기와 동일한 클러스터 크기를 사용하십시오.
예, 6 개의 회전 디스크로 1.7GiB / s에 가까워지면서 SATA III 버스 속도는 병목 현상이 아니라 디스크 자체가 아니라 병목 현상을 일으 킵니다. 필자는 283MiB / s의 쓰기 속도를 가진 128MiB 캐시의 하이 엔드 디스크 (저렴하지 않은 디스크)를 사용합니다.
당신과 모든 사람들을 위해 : 속도 테스트를 수행하기 전에 클러스터 크기, 스트라이프 크기 및 블록 크기가 어떻게 관련되어야하는지 배우는 것이 가장 좋습니다.
Sata II 포트 메인 보드에서 2x60MiB / s 2.5 인치 5400rpm Sata 디스크로 Linux 부팅 시간을 테스트 한 다음 2xSSD Sata III로 테스트합니다 (Sata III에 연결된 경우 각각 250MiB / s 이상을 쓸 수 있음). 5 분 부팅시 부팅 시간이 2 초 밖에 걸리지 않고 2 초 밖에 걸리지 않습니다. 왜 그렇습니까? 대부분의 부팅 시간 디스크가 사용되지 않기 때문에 램과 CPU에서 작업을 수행하지만 I / O는 수행하지 않습니다.
항상 조잡한 속도 (즉, 최대 속도)뿐만 아니라 실시간으로 수행 할 일을 테스트하십시오.
최대 속도는 비트를 표현할 수 없음을 알고있는 것이 좋습니다. 최대 속도 100 %에서 디스크를 사용하지 않을 수 있습니다. OS 및 APP는 I / O없이 램 및 CPU에서 작업을 수행해야합니다. 전혀 문제가되지 않습니다.
모든 사람들은 SSD가 Windows 부팅 속도를 크게 향상 시키며, FALSE 인 테스트에서 거의 8 분에 가까운 부팅 시간에서 28 초만을 증명한다고 말합니다.
당신이 나를 좋아하는 경우 : 부팅시 리눅스 복사-램, SSD는 회전하는 HDD보다 베팅하지 않을 것입니다. 나는 또한 USB 3.1 Gen2 스틱 (139MiB / s 읽기)을 테스트했으며 부팅 시간은 5 분 부팅, 왜? 램에 복사 할 때는 디스크 / ssd / usb-stick보다 볼트의 나머지 부분에서 다시 사용되지 않고 데이터가 램 드라이브처럼 램에 저장됩니다.
이제 나는 가지고있는 모든 SSD를 판매하고 있습니다. 부팅시 Linux copy-on-ram을 개선하지는 않지만 벤치 마크를하면 5 배 빠릅니다. 벤치 벤치 마크는 거짓 결론을 제공합니다 ... 예, 테스트 및 테스트 주간 근무.
이로 인해 문제가 해결 될 수 있기를 바랍니다 ... 나쁜 클러스터 및 스트라이프 크기의 LVM은 레이어 오버 헤드보다 훨씬 더 많은 영향을 미칩니다.