Linux 매뉴얼 페이지에 따르면 원시 디스크와 파티션을 볼륨 그룹에 추가할 수 있습니다.
다른 문서(RedHat, CentOS 또는 openSUSE)에서 모든 예는 원시 디스크 대신 VG에 파티션을 추가하는 것을 나타냅니다. 일반적인(모범) 사례는 무엇입니까?
답변1
RHEL6 LVM 관리 가이드
~에 따르면RHEL 6 논리 볼륨 관리 가이드전체 드라이브를 LVM 볼륨 그룹의 물리 볼륨으로 사용하려는 경우에도 파티션을 나누는 것이 좋습니다.
"RHEL6 논리 볼륨 관리자 관리 LVM 관리자 가이드" 가이드에서 발췌
2.1.2. 디스크의 다중 파티션
LVM을 사용하면 디스크 파티션에서 물리 볼륨을 생성할 수 있습니다. 일반적으로 다음과 같은 이유로 전체 디스크를 포함하는 단일 파티션을 생성하여 LVM 물리 볼륨으로 레이블을 지정하는 것이 좋습니다.
행정편의성
각 실제 디스크가 한 번만 나타나는 경우 시스템의 하드웨어를 추적하는 것이 더 쉽습니다. 디스크에 오류가 발생한 경우 특히 그렇습니다. 또한 단일 디스크에 여러 물리적 볼륨이 있으면 부팅 시 알 수 없는 파티션 유형에 대한 커널 경고가 발생할 수 있습니다.
LVM 가이드
부분11.1 LVM Howto의 디스크 또는 디스크 파티션을 초기화합니다.조항은 다음과 같습니다:
LVM Howto에서 발췌
전체 디스크의 경우:
디스크에서 pvcreate를 실행합니다.
# pvcreate /dev/hdb이렇게 하면 디스크 시작 부분에 볼륨 그룹 설명자가 생성됩니다.
권장되지 않음
전체 디스크에 걸쳐 있는 파티션이 아닌 전체 디스크를 PV로 사용하는 것은 관리 문제를 일으킬 수 있으므로 권장되지 않습니다. 디스크를 보는 다른 운영 체제는 LVM 메타데이터를 인식하지 못하고 디스크를 사용 가능한 것으로 표시하므로 덮어쓸 가능성이 높습니다. LVM 자체는 전체 디스크 PV를 매우 잘 처리합니다.
LVM이 파티션 테이블을 사용하여 디스크를 초기화할 수 없다는 오류가 나타나면 먼저 올바른 디스크에서 작업하고 있는지 확인하십시오. 이것이 사실이라고 확신하는 경우 다음 명령을 실행하십시오.
위험한
다음 명령은 작업 중인 디스크의 파티션 테이블을 삭제합니다. 올바른 디스크인지 확인하세요.
# dd if=/dev/zero of=/dev/diskname bs=1k count=1 # blockdev --rereadpt /dev/diskname
결론적으로
이는 HDD를 물리적 볼륨으로 추가하기 전에 HDD의 개별 파티션을 포맷해야 하는지 여부를 결정할 때 제가 신뢰하는 주요 소스입니다. 다른 답변(및 설명)에서 알 수 있듯이 파티션 없이 전체 드라이브를 추가하면 문제가 발생할 수 없습니다.
저는 그것을 안전벨트를 착용하고 운전하는 것에 비유합니다. 사고를 당해본 적이 없다면 안전벨트는 아무런 역할도 하지 못하지만, 만약 사고를 당했다면 틀림없이 착용했을 것입니다.
후속 조치 #1(@Joel의 의견에 대한 응답)
위의 두 가이드에는 두 가지 좋은 이유가 있다고 생각합니다. 둘 다 공식 가이드입니다. 하나는 RH에서 제공하고 다른 하나는 LVM 팀에서 편집한 Howto입니다.
이것이 또 다른 이유입니다. HDD를 분할하지 않음으로써 HDD에 사용 방법을 명확하게 식별할 수 있는 ID가 명시적으로 설정되지 않습니다.
fdisk -l
...
/dev/sda6 318253056 956291071 319019008 8e Linux LVM
시스템 관리자로서 나와 다른 사람들은 8e를 사용하지 않을 때보다 이 특정 드라이브를 사용하는 방법에 대해 더 나은 아이디어를 가지고 있습니다.
@Joel님의 말씀에 감사드립니다. 저는 또한 Fortune 500대 기업에서 근무하면서 데스크탑/서버 물리적/가상 배포는 물론 대규모 스토리지 배포에 수백 대의 Linux를 배포했기 때문에 무슨 뜻인지 이해합니다.
답변2
보편적으로 인식되는 설명자(메타데이터)를 갖는 것이 더 좋으며 MBR은 그러한 설명자 역할을 합니다. GPT조차도 이전 MBR 기반 파티션 테이블을 사용하여 존재를 나타냅니다.
실제로 일부 디스크 공간이 손실되지만 이는 무시할 수 있는 수준이며 디스크에 무엇이 있는지(그리고 어디에 있는지) 알면 얻을 수 있는 이점은 자명합니다.
답변3
디스크 공간의 100%를 차지하는 파티션에 물리 볼륨을 생성하는 것은 결코 올바른 일이 아닙니다. 내가 "거의"라고 말하는 이유는 단지 어떤 일을 해야 할 이유가 생각나지 않는다고 해서 그것을 할 이유가 없다는 뜻은 아니라는 나의 태도 때문입니다. 즉, 디스크가 LVM을 사용하는 경우 파티션을 공간의 100%에 배치할 이유가 없습니다.
일부 고정 파티션을 복원해도 큰 이점은 없습니다. SAN 지원 물리 볼륨이고 이를 수행하는 경우 볼륨 그룹의 스토리지 공간을 확장하는 방법은 두 가지뿐입니다.
- 더 큰 새 LUN을 프로비저닝하고, 볼륨 그룹에 추가하고, 어떻게든 분할한 LUN을 pvmove하고, 볼륨 그룹에서 제거하고, SAN 사용자에게 취소하도록 지시합니다. 이는 가능할 수도 있고 온라인으로 수행할 수도 있지만(성능 저하가 있고 SAN 측 스토리지 풀에 두 LUN을 모두 수용할 수 있는 충분한 SAN 공간이 있다고 가정할 때) 가능합니다.
- 유일한 다른 방법은 파티션을 다루는 것으로 돌아가는 것입니다. 이는 사람들이 btrfs, lvm, zfs 등과 같이 잘 설계된 볼륨 관리 체계를 선호하는 이유 중 하나입니다. 물리적 볼륨의 파티션 테이블을 편집하고
partprobe새로운 크기를 읽을 수 있게 해줄 수 있지만 개인적인 경험에 따르면 이는 2번 중 1번만 작동하며 파일 시스템을 마운트 해제해야 합니다(예:오프라인사람들이 볼륨 관리자를 좋아하는 또 다른 이유).
전체 디스크를 사용하는 경우 SAN 관리자가 LUN을 확장할 수 있으며, SCSI 버스를 다시 검색하면 LUN의 새 크기를 얻은 다음 pvresize물리 볼륨을 확장할 수 있습니다. 파일 시스템을 오프라인으로 전환하지 않고도 이 모든 작업을 수행할 수 있습니다.
MBR 비트가 꺼진 상태에서는 일반적으로 한 시스템에서 PV를 가져와 엔터프라이즈 환경의 다른 시스템에 제공하지 않습니다. 이렇게 하더라도 LVM인 경우 LUN을 제공하는 운영 체제가 LVM을 지원하기를 원할 것입니다. 그렇지 않으면 그들에게 그것을 제시하는 요점이 무엇입니까? 그렇다면 모든 물리 볼륨 정보, 볼륨 그룹 정보 및 논리 볼륨을 볼 수 있습니다(이것이 볼륨 그룹의 유일한 PV라고 가정). 그래서 그렇게 기록합니다.
원래:전체 디스크를 100%로 분할하는 것은 사과 파이를 가져온 웨이터에게 칼도 달라고 요청하는 것과 같습니다. 그가 그렇게 하면 당신은 칼을 옆으로 치우고 파이에 얼굴을 묻습니다. 의미: 한 번만 사용하려는 경우 하나의 도구를 사용하여 무언가를 더 작은 부분으로 나누는 것은 의미가 없습니다.
답변4
내 경험상 테스트 중이거나 디스크/스토리지를 사용할 수 없는 소규모 환경에서는 파티션을 사용하는 것이 좋습니다. 이것은 학교에 적합하거나 차고에서 일할 때 적합합니다. 현실 세계에서는 필요에 따라 디스크를 확장할 수 있는 가상 서버를 사용하여 파티션 대신 LVM이 원시/전체 디스크를 관리하도록 하는 것이 더 좋습니다. 서버를 다시 시작하지 않고도 쉽고 유연한 관리가 가능합니다. 이렇게 하면 시간이 얼마나 절약되는지 아시나요? 이를 관리해야 할 모든 서버에 곱하십시오! 분할/슬라이싱으로 인해 커널이 새 테이블을 인식하지 못할 수 있으므로 서버를 다시 시작해야 하는 문제에 여러 번 직면했습니다. 원시 디스크를 사용하는 LVM은 LVM에 원시 디스크/가상 디스크를 추가하고 파일 시스템을 확장해야 할 때 유용합니다. XXX가 디스크(sdb, sdc, sdd 등)인 "echo 1 >/sys/block/XXX/device/rescan"과 같은 간단한 명령을 실행하면 재부팅 및 붐 없이 디스크가 추가 공간을 위해 다시 검색됩니다! 파일 시스템을 동적으로 확장할 수 있습니다. Linux 서버를 다시 시작하지 않고 디스크를 확장하는 데 약 5분이 소요됩니다. 파티션된 디스크의 경우 프로세스가 복잡합니다.