mdadm과 비교한 LVM raid 상태

저는 팀의 선배이고 여러 환경을 가지고 있습니다(제 기억이 맞다면 지금은 약 5개지만, 연말까지 더 많은 환경을 확보할 예정입니다).

이러한 환경의 규모는 물리적 호스트 8~25개(일반적으로 CPU 및 메모리에 완전히 로드됨)이며, 각 호스트에서 실행되는 가상 서버는 50~400개입니다.

스토리지는 항상 파이버 채널에 있지만 패브릭 스위치와 디스크 어레이는 고객(고객이 받는 거래, 소유한 스토리지 회사와의 관계 등)에 따라 크게 다릅니다.

각 환경은 DWDM을 통해 상호 연결된 2개의 데이터 센터에 걸쳐 있습니다(두 개의 DC 네트워크(ip 및 fc)가 하나로 표시됨). 물론 네트워크는 VLAN과 FC 구역화에 따라 더 작은 부분으로 나누어집니다.

우리는 vmware(쿨하게 실행됨), virsh의 원본 qemu+kvm, Pacemaker 클러스터에서 실행되는 virsh의 qemu+kvm, ovirt가 조정하는 virsh의 qemu+kvm을 포함한 다양한 하이퍼바이저를 보유하고 있습니다.

우리는 하이퍼바이저 클러스터링과 VM 내 클러스터링을 사용합니다.

가장 오래된 환경은 10년이 넘었지만 주기적으로 개조됩니다(상상할 수 있다면 엄청난 일입니다).

이 모든 것을 설명하는 이유는 무엇입니까? 보시다시피 이 동물원은 매우 역동적입니다. 거의 4년 동안 매일 이 모든 기술이 실제로 작동하는 모습을 볼 수 있어서 감사했습니다. 이러한 환경에는 일반적으로 수천 개의 LVM 볼륨이 있으며 결국 작업 중에 모든 볼륨을 만지게 될 것이라는 점은 추가할 필요가 없습니다.

가장 오래된 환경은 전적으로 LVM을 기반으로 했으며, 제가 말할 수 있는 것은: 작동하지 않을 때까지 작동했다는 것입니다.

LVM의 가장 큰 문제는 그것이 어리석은 일을 하면 스스로 책임을 져야 한다는 것입니다. 이는 예상치 못한 경우(또는 필요할 때) 및 프로덕션 환경(개발이 아닌 테스트 또는 사전 프로덕션이 아닌)에서 종종 발생합니다.

또한 명령은 매우 바로크적이고 다소 되돌릴 수 있지만 볼륨에서 데이터 펌핑을 시작할 때만 가능합니다. 이런 일이 발생하고 나중에 오류를 발견하면 볼륨을 굽고 새 볼륨을 시작하면 됩니다. 더 빠르고 강력하며 실수도 줄어들 것입니다.

기본적으로 전체 LVM 설정이 손실되었음을 의미하는 몇 가지 이상한 LVM 오류를 보았습니다.

가장 충격적인 점은 초보 관리자가 LVM 스택을 수백 기가의 스토리지로 확장하여 확장된 LV의 크기가 갑자기 -4조로 보고되었다는 것입니다. 볼륨의 이상한 음수 크기로 인해 umount, fsck 또는 기타 복구 도구를 실행할 수 없으며 다른 문제가 발생합니다. 다행스럽게도 디렉터리에 들어가는 것이 여전히 작동했기 때문에 전체 VM을 다시 빌드하고 rsync를 사용하여 (대부분 읽기 전용) 데이터를 전송했습니다. 그런 다음 데이터 팀은 분석을 수행했으며 누락된 데이터를 찾지 못했습니다. 따라서 아마도 여유 공간이 어떤 방식으로든 엉망이 되었을 가능성이 높습니다. 그러나 최종 결과는 LVM이 이러한 복잡한 상황을 만들고 기본 데이터 복구 도구도 실행할 수 없는 볼륨을 잠그는 것입니다.

원래 시스템도 손실되어 교체 후 해체해야 했습니다. 나와 우리 건축가는 내려진 명령을 분석했는데, 그것은 완전히 책에 따라 이루어졌기 때문에 거기서 무슨 일이 일어나고 있는지 잘 모르겠습니다.

또한 확장된 LVM 미러링을 소량 사용합니다 cling(LV 하위 장치를 물리 계층의 올바른 데이터 센터에 연결하기 위해). 이렇게 하면 교차 DC 링크가 파손된 경우 미러가 적어도 한쪽 면에 조립됩니다. 제가 말하고자 하는 것은 한밤중에 이러한 설정을 다루고 싶지 않다는 것입니다.

우리는 LVM 스냅샷이 수정된 것으로 추정됨에도 불구하고 사용할 용기가 없었습니다. 온라인에는 이러한 문제에 대한 공포 이야기가 너무 많아서 시도해 보기가 꺼려집니다. 특히 이제 이러한 문제를 완전히 피할 수 있는 도구가 있기 때문에 더욱 그렇습니다.

일반적인 사용과 관련하여 LVM과 Linux 파일 시스템의 전반적인 상태에 대한 주요 문제점은 자체 검사가 불가능하다는 것입니다.

아직 LVM 이미지를 파헤칠 시간이 없었지만 LVM 이미지가 실제로 블록의 체크섬을 계산한다는 사람 또는 명시적인 서면 확인을 아직 찾지 못했습니다(crc32라도 모든 체크섬이 이 작업을 수행함). 그렇다면 LVM 이미지 재계산을 실행하더라도 실제로는 무엇을 하고 있을까요? 진행률 카운터가 100%에 도달하고 불일치 카운터가 0이면 미러 간의 데이터가 일치한다는 의미입니까, 아니면 전체 체크섬이 오류 없이 완료되었음을 의미합니까(이 둘은 완전히 다른 것입니다, 그렇죠)?

LVM에서 직면한 두 번째 문제는 좀 더 간접적입니다. 가장 일반적인 파일 시스템은 다음과 같습니다. , , , , , , , , , , , , , , , , , , , , , , 사용자 데이터 에 대한 체크섬이 ext4없습니다 . 90년대에는 괜찮았을지 모르지만 지금은 큰 문제입니다. 이제 더 명확해졌습니다. 실제 사용자 데이터 콘텐츠에 관심이 있기 때문에 사용자 데이터 메타데이터에는 실제로 관심이 없습니다. 어쨌든 저장의 요점은 무엇입니까? 사진이 마지막으로 변경된 시기를 알고 싶거나 사진의 내용을 실제로 보고 싶으십니까?xfsjfs

최소한 기본적인 사용자 데이터 체크섬을 추가하려는 계획이 있지만 xfs아직은 없습니다.

이것이 왜 중요합니까? 클러스터 설정에서는 펜싱이 자주 발생하며, 때로는 이러한 펜싱이 결국 스톤서클을 초래하기도 합니다. 그렇다면 사건이 발생한 후 클러스터가 마침내 안정화되면 이제 데이터가 괜찮다고 어떻게 말할 수 있습니까?

LVM + FS를 사용하면 방법이 없기 때문에 간단히 할 수 없습니다. 응, 백업에 비하면...그냥 놔두자, 그렇지?

마지막으로 LVM은 취약합니다. 특히 패시브/액티브 클러스터 볼륨 또는 클러스터 lvm 설정의 경우 어떤 lvm 부분이 루트를 lvm.conf에 빌드하는지 표시해야 합니다. 그렇지 않으면 LVM은 어떤 부분이 클러스터링되어 있는지, 어떤 루트가 시작하려는지 알지 못하므로 모든 부분을 조립합니다. 이는 클러스터에서 큰 문제입니다. 이 문제를 해결하려면 lvm.conf의 복사본도 initrd에 복사되었는지 확인해야 합니다(dracut 참조). 이 모든 것을 보장하지 않으면 다음에 두 개 이상의 노드가 동시에 시작될 때 둘 다 동일한 lvm 볼륨을 활성화하려고 시도합니다. 그러면 재미를 상상할 수 있습니다.

초보 관리자가 클러스터를 구성하고 조립한 후(그리고 특별히 제가 지시한 경우) 이 문제를 해결해야 했던 적이 몇 번이나 되었는지 모릅니다. 자신이 적어둔 메모를 자주 잊어버린다 해도 이는 이 단계가 어렵다는 것을 의미합니다.

이것은 일반적으로 첫 번째 펜싱 이후에만 나타나기 때문에 동료에게 해결하도록 맡길 수 있는 정말 멋진 시한폭탄입니다 :).

그래서 수년에 걸쳐 저는 LVM이 사라져야 한다고 믿게 되었습니다. LVM은 그 목적을 달성했지만 ZFS와 BTRFS는 할 수 있는 모든 것, 더 나은 것, 그리고 더 많은 것을 할 수 있습니다.

ZFS와 BTRFS는 모두 모든 풀 메타데이터를 풀에 직접 저장합니다. dracut 바인딩 btrfs/zfs.confs가 없으면 풀은 처음부터 그래야 하므로 init ramdisk에서 완전히 연결이 끊어집니다. 커널 명령줄에서 사용할 풀의 루트를 지정할 수 있습니다.

무엇보다도, 오류 발생 후 BTRFS 및 ZFS에서 정리를 실행하고 실제로 스토리지를 다시 검색하여 실제 정보를 얻을 수 있습니다.사용자 데이터(!)실수. 스크러빙은 킬러 기능이며 차세대 FS를 실행해야 하는 이유입니다. 정리하면 자동으로 데이터가 손상되지 않는다는 사실을 실제로 확신할 수 있습니다.

두 번째로 중요한 것은,스냅샷은 효과가 있습니다. 언제나. 스냅샷은 COW 시스템의 기본 작업 단위이자 모든 것의 핵심이기 때문에 작동하지 않으면 더 큰 문제가 발생합니다.

마지막으로, "나쁜" 편이라면 대량의 데이터를 처리할 수 있는 능력 때문에 BTRFS를 사용하는 것이 좋습니다. 그것들을 분할하고, 축소하고, 균형을 재조정하는 등 많은 이상한 일을 할 수 있습니다. 최적의 지점을 찾을 때까지 BTRFS 시스템의 디스크를 사용하여 춤을 출 수 있습니다. 이는 스토리지를 구입할 여유가 없는 값싼 Linux 관리자(Linux 관리자의 90%를 의미)의 궁극적인 꿈입니다. 또는 최상의 솔루션을 찾을 때까지 동일한 데이터에 계속 액세스하면서 스토리지를 3번 재구축하는 것을 좋아하는 사람.

ZFS는 이 영역에서 기능을 천천히 늘리고 있지만 여전히 BTRFS의 확장성과는 거리가 멀습니다. 그러나 ZFS의 한 가지 점은 BTRFS(리눅스 버기와 약간 비슷함)와 달리 ZFS는 강력한 데이터 트럭(심지어 탱커)이라는 것입니다.

ZFS는 많은 테스트를 거쳤으며 도구는 믿을 수 없을 정도로 세련되었습니다. BTRFS와 비교하면 얼마가 어디에 지출되는지 즉시 확인할 수 있습니다. 팁: 루트 액세스 없이 BTRFS 풀에 대해 쿼리 명령을 실행할 수도 없는 반면, ZFS를 사용하면 모든 ZFS 작업에 대한 완전한 액세스 제어 목록이 있고 이를 특정 사용자에게 위임할 수 있습니다.

전체적으로 내 직감은 몇 년 안에 ZFS가 기능 패리티 측면에서 천천히 BTRFS와 경쟁할 것이라는 점입니다. 반면에 제가 추정한 BTRFS는 20%만 완성된 것으로 영원히 미완성 상태로 남을 것입니다. 이는 모두 Linux 세계에서 너무 흔한 일입니다.

하지만 어느 쪽이든 많은 LVM 문제를 줄일 수 있습니다.