VMware의 Linux-왜 파티셔닝을 사용합니까?

가상화 된 환경 (필자의 경우 ESXi)에 Linux VM을 설치할 때 각 마운트 지점에 별도의 디스크를 추가하는 대신 디스크를 분할해야하는 이유가 있습니까 (ext4를 사용하는 경우)?

내가 볼 수있는 유일한 것은 fdisk와 같은 디스크에 데이터가 있는지 확인하는 것이 다소 쉽다는 것입니다.

반면에, 파티션을 사용 하지 않는 좋은 이유가 있습니다 (/ boot 이외의 경우).

• 디스크를 훨씬 쉽게 확장 할 수 있습니다. VM의 디스크 크기 (일반적으로 VCenter)를 늘린 다음 VM에서 장치를 다시 검색하고 온라인으로 파일 시스템의 크기를 조정하면됩니다.
• 기본 LUN과 파티션을 정렬 할 때 더 이상 문제가 없습니다.

나는이 주제에 대해 많이 찾지 못했습니다. 중요한 것을 놓친 적이 있습니까?

이것은 흥미로운 질문입니다 ...

나는 확실한 대답이 없다고 생각하지만,이 주제를 둘러싼 모범 사례가 시간이 지남에 따라 어떻게 변화했는지에 대한 역사적 맥락을 제시 할 수 있습니다.

2007 년부터 VMware 환경에서 다양한 형태로 배포 된 수천 개의 Linux VM을 지원해야했습니다. 배포 방식이 발전 했으며 다른 엔지니어가 구축 한 시스템 상속 및 리팩토링에 대한 독특하고 ( 불행한 ) 경험 이있었습니다 .

옛날 ...

그 당시 (2007 년) 초기 VMware 시스템은 베어 메탈 시스템처럼 분할되었습니다. VMware 측에서는 2GB 두께의 분할 파일을 사용하여 VM의 데이터를 구성하고 있었으며 가상화가 작동 할 수 있다는 것이 기 뻤기 때문에 여러 VMDK의 개념에 대해서는 생각조차하지 않았습니다!

가상 인프라 ...

ESX 3.5와 초기 ESX / ESXi 4.x 릴리스 (2009-2011)에 의해, 나는 모 놀리 식 Thick 프로비저닝 VMDK 파일 위에 정상으로 분할 된 Linux를 사용하고있었습니다 . 스토리지를 미리 할당해야했기 때문에 실제 하드웨어와 비슷한 방식으로 Linux 디자인에 대해 생각해야했습니다. 운영 체제에 대해 36GB, 72GB, 146GB VMDK를 생성하고 일반적인 /, / boot, / usr, / var, / tmp를 분할 한 다음 "data"또는 "growth"파티션에 다른 VMDK를 추가했습니다 (/ 홈, / opt 또는 응용 프로그램에 따라 다름). 다시 말하지만이 시대의 실제 하드 디스크 크기의 스위트 스팟은 146GB였으며 사전 할당이 필요했기 때문에 (NFS를 사용하지 않는 한) 공간을 보존해야했습니다.

씬 프로비저닝의 출현

VMware 는 이후 ESXi 4.x 릴리스에서 씬 프로비저닝과 관련 하여 더 나은 기능을 개발 했으며 이로 인해 새 시스템을 설치하기 시작했습니다. 전체 기능 세트가 5.0 / 5.1에 추가되면서 새로운 유형의 유연성으로보다 창의적인 디자인이 가능해졌습니다. 이것은 vCPU 수와 개별 VM에 커밋 할 수있는 RAM의 양에 따라 가상 시스템의 기능 향상에 보조를 맞추고있었습니다. 과거보다 더 많은 유형의 서버 및 응용 프로그램을 가상화 할 수 있습니다. 컴퓨팅 환경이 완전히 가상화되기 시작한 것은 맞습니다.

LVM은 끔찍합니다 ...

VM 수준의 완전 핫 추가 기능이 확립되어 있고 일반적인 경우 (2011-2012), 나는 고객의 VM에 대한 가동 시간을 어떤 비용 ( 멍청한 ) 으로 유지하기 위해 노력하는 회사와 협력하고있었습니다 . 따라서 여기에는 온라인 VMware CPU / RAM 증가와 기존 VMDK의 위험한 LVM 디스크 크기 조정 이 포함되었습니다 . 이 환경에서 대부분의 Linux 시스템은 LVM 위에 ext3 파티션이있는 단일 VMDK 설정이었습니다. LVM 계층이 운영에 복잡성과 불필요한 위험 을 추가했기 때문에 이는 끔찍 했습니다. 예를 들어, / usr에 공간이 부족하면 백업에서 시스템을 복원해야하는 잘못된 결정이 발생할 수 있습니다. 이는 부분적으로 프로세스 및 문화 관련 이었지만 여전히 ...

파티션 스노 버 ...

나는 이것을 바꾸려고 노력 했다. 나는 리눅스에서 약간의 파티션 스놉 이며 모니터링과 운영 요구에 따라 파일 시스템을 분리해야한다고 생각합니다. 또한 VMware와 특히 LVM이 마음에 들지 않는 것을 좋아합니다. 따라서 잠재적으로 커질 수있는 파티션에 VMDK 파일 추가를 확장했습니다. / opt, / var, / home은 필요한 경우 자체 가상 머신 파일을 가져올 수 있습니다. 그리고 그것들은 원시 디스크 일 것입니다. 때때로 이것은 특정 소형 파티션을 즉시 확장하는 더 쉬운 방법이었습니다.

오바마 케어 ...

매우 유명한 클라이언트 의 온 보딩을 통해 나는 매우 눈에 띄는 애플리케이션 환경 을 만드는 데 사용되는 Linux VM 참조 템플릿을 설계해야했습니다 . 응용 프로그램의 보안 요구 사항에는 고유 한 마운트 집합이 필요 했기 때문에 개발자와 함께 성장하지 않은 파티션을 하나의 VMDK에 넣은 ​​다음 성장 가능성이 있거나 특정 요구 사항 (암호화, 감사 등) 결국이 VM은 5 개 이상의 VMDK로 구성되었지만 향후 데이터 크기 조정 및 보호에 최고의 유연성을 제공했습니다.

내가 오늘하는 일은 ...

오늘날 Linux 및 기존 파일 시스템에 대한 일반적인 설계는 하나의 가상 VMDK (파티션 된)에 대한 OS이고 다른 모든 것에 대한 별도의 VMDK입니다. 필요에 따라 핫 추가합니다. ZFS와 같은 고급 파일 시스템의 경우 OS 용 VMDK와 ZFS zpool의 역할을하는 다른 VMDK이며 크기를 조정하거나 추가 ZFS 파일 시스템 등에 조각 할 수 있습니다.

당신은 여러면에서 옳습니다. 나는 논쟁을 볼 수 있습니다-까다로울 수있는 한 가지 문제가 있습니다. 리소스 풀을 사용하는 경우 (그리고 내가 싫어하는 것을 알지 못한다면) VM에 디스크가 더 있으면 더 많은 IO 시간을 얻을 수 있습니다. 극단적 인 리소스가 제한된 상황에서 두 개의 디스크가있는 VM은 하나보다 두 배 많은 IO 리소스를 얻을 수 있습니다 단일 디스크. 이것은 당신에게 문제가되지 않을 수도 있지만, 나는 그것을 지적 할 것이라고 생각했습니다.

편집-아 그리고 그것은 약간의 스냅 속도를 약간 느리게 만들지 만 다시는 문제가되지 않을 수 있습니다.

특정 "대규모 가상화 소프트웨어 회사"의 인프라에서 근무할 때 종종 vm 파일 시스템의 크기를 늘려야했습니다. 우리는 당시 ext3 / 4를 사용했습니다.

가상 디스크를 늘리는 것은 매우 쉽습니다. 라이브 OS에서 새로운 장치 크기를 선택하는 것은 상대적으로 쉽습니다 (/ sys에서 찌르기) .ext3 / 4 파일 시스템의 라이브 크기를 조정하는 것은 쉽지만 항상 불가능한 것처럼 보입니다. 파티션 크기 조정.

fdisk를 사용하여 gparted를 사용하거나 파티션 테이블을 다시 쓰거나 크기를 조정해야했지만 항상 커널에 의해 잠겨 있었고 커널이 새 레이아웃을 선택하도록 재부팅해야했습니다 (partprobe도 수행하지 않았습니다).

많은 시스템을 LVM으로 옮겼고 파일 시스템 크기를 조정하는 것이 쉽고 즐겁고 즐거운 경험이되었습니다!

• VM 외부의 가상 디스크 이미지 늘리기
• VM에서
  • 디스크 메트릭을 다시 검색하기 위해 / sys를 찌릅니다 (에코 "1"> / sys / class / scsi_device // device / rescan)
  • pvresize / dev / sdX (LVM에서 물리 볼륨 크기 조정)
  • lvresize --extents + 100 % FREE / dev / VG / lvolXX (LVM에서 논리 볼륨 크기 조정)
  • resize2fs (파일 시스템 크기 조정)

이 모든 것은 라이브 시스템에서 안전하게 수행 할 수 있으며 재부팅 할 필요가 없습니다!

베어 디스크가 아닌 이유는 무엇입니까? 베어 디스크는 아직 충분히 널리 받아 들여지고 있다고 생각하지 않지만 우리는 훨씬 더 광범위하게 받아 들여지고 있다고 생각합니다. btrfs 메일 링리스트에 이와 관련된 스레드가 있습니다 :

http://www.spinics.net/lists/linux-btrfs/msg24730.html

그러나 베어 디스크는 재검색과 resize2fs 만 있으면됩니다.

따라서 요약하면 가능하다면 파티션 테이블을 피하십시오.

작성된 귀하의 질문은 VMWare (ESXi)에 관한 것이지만 KVM에서 동일한 아이디어를 얻은 후에 파티션 테이블을 사용하도록 다시 전환 한 상황을 추가하고 싶습니다.

LVM 볼륨을 VM의 디스크로 사용하고 파티션을 사용하지 않고 (전체 가상 디스크를 PV로 사용) VM 내에서 LVM 볼륨 그룹을 생성하면이 VG가 호스트 시스템의 VM 외부에서 볼 수 있습니다. 파티션을 PV로 사용하는 경우에는 해당되지 않습니다.

물론, 코너 케이스이지만 그러한 설정이 필요한지 고려할 가치가 있습니다.

이 작업을 수행하는 것이 더 나은지 여부는 시스템에 따라 다릅니다.

각 설정의 장단점이 있습니다.

그러나 단일 드라이브의 주요 장점은 다음과 같습니다.

1. 단순성 : 단일 드라이브에는 단일 파일이있어 쉽게 배포 및 복제 할 수 있습니다.
2. 호스트 OS에 대한 신호 : 단일 파일은 단일 데이터 블록으로 취급되므로 호스트 OS는 게스트 컴퓨터 액세스 시퀀스가 ​​모두 하나의 파일에 있음을 알게됩니다. 모든 드라이브 이미지를 동일한 파일에 저장하면 일부 호스트 OS 구성에서이 작업을 수행 할 수 있지만 반드시 그런 것은 아닙니다.

그러나 멀티 드라이브에는 장점이 있습니다.

1. 베어 메탈 선호도 / 수동 위치 : 단일 드라이브를 사용하면 드라이브의 단일 베어 메탈 선호도에 고정됩니다.
2. 크기 제한 : 시스템에 드라이브 또는 파일 크기에 제한이있는 경우 매우 큰 시스템에서 충돌 할 수 있습니다.
3. 보안을위한 읽기 전용 볼륨 : 이것이 가장 큰 장점입니다. OS의 마스터 볼륨이 VM 측에서만 읽기 인 경우 VM의 프로그램이 게스트의 기본 OS를 편집하지 못하도록 차단하는 주요 보안 이점을 제공합니다. 별도의 데이터 드라이브를 사용하면 클린 룸 템플릿 데이터없이 유지 관리 및 업데이트를 위해 읽기 / 쓰기로 부팅 할 수있는 읽기 전용 드라이브를 만들 수 있으므로 서버 내에서 중요한 OS 디렉토리를 수정할 수 없습니다.

또 다른 옵션이 있습니다 : 응용 프로그램 데이터를 NFS 볼륨에 마운트하십시오. 좋은 파일러가 필요합니다 (모든 NFS 구현이 동일하지는 않습니다).

NFS 볼륨이 가득 차면 볼륨을 확장하면 Linux 클라이언트에 추가 공간이 즉시 표시됩니다.

응용 프로그램과 공급 업체는 NFS에 데이터를 지원해야하며 신중한 NAS 설계가 필요하지만 가상화 된 환경에 대한 모든 스토리지 솔루션을 사용하십시오.

이 접근 방식의 또 다른 이점은 스토리지 공급 업체에 스냅 샷 / 클로닝 기술 (zfs 또는 Netapp 등)이 데이터를 백업하고 테스트 / 개발 환경을 만드는 것이 매우 쉽다는 것입니다.

일부 Linux 배포판에서 디스크를 분할해야하는 이유는 부트 로더와 함께 사용할 수있는 모든 레거시 조각 (예 : 에뮬레이트 된 BIOS)이 있기 때문입니다. 이로 인해 디스크 크기를 조정하기가 더 어려워지고 LVM 또는 기타 유사한 비센스를 사용하는 경우가 많습니다.

단순히 전체 볼륨에 파일 시스템을 만들어 마운트 할 수 있습니다 /. 이는 매우 사용자 정의 된 (또는 사용자 정의 가능하거나 선택되지 않은) Linux 배포에서 작동합니다. 마지막으로 Ubuntu 12.04 로이 작업을 시도했을 때 설치 관리자는 바보 같은 파티션 테이블을 모든 재즈를 설치해야하므로 처리 방법을 몰랐습니다. 이것은 가상화 세계에서 범용 배포의 문제 중 하나입니다.

다른 하나는 실제로 파티션을 덜 전통적인 용도로 사용할 수 있습니다. 예를 들어 ChromeOS 와 CoreOS 에는 시스템 업그레이드를위한 두 개의 읽기 전용 루트 파티션이 있습니다.

지금까지 언급되지 않은 한 가지 이유는 Google Compute와 같은 일부 인프라에서 디스크 크기에 따라 디스크 IO 성능이 선형 적으로 증가하기 때문입니다 . 다시 말해, 하나의 큰 파티션 된 드라이브는 여러 개의 작은 드라이브보다 더 나은 IO 성능을 갖습니다.

그러나 일반적으로 그렇지는 않습니다. Chopper3에서 언급했듯이 대부분의 경우 여러 드라이브가 더 나은 IO 성능을 갖습니다. 궁극적으로 모든 가상 드라이브가 단일 물리적 드라이브에 매핑되면 차이가 없어야합니다.

내 경험상 더 나은 접근 방식은 OS 용 1 VMDK를 사용하는 것이며 일반적으로 다음과 같은 방식으로 파티션을 나눕니다.

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

필자는 보통 최소 Linux 배포판 (~ 800MB) + 필요한 소프트웨어를 설치하기 때문에 8GB가 충분하다는 것을 알았습니다. 로그도 해당 파티션으로 이동하지만 올바르게 설정하고 (1 주일 동안 로그 회전) 다른 곳 (syslog / elasticsearch)으로 배송하면 일반적으로 파티션을 채우지 않습니다.

데이터는 다른 VMDK로 추가되며 보통 베어 디스크 (예 : / dev / sdb)를 통해 파일 시스템을 직접 포맷합니다. 이를 통해 VmWare에서 볼륨의 크기를 조정하고 다시 파티션 / 마운트 / 재부팅 할 필요없이 VM에서 직접 크기를 조정할 수 있습니다.

두 가지 이유로 파티션을 나눕니다.

1. 문서-한 번은 "훈련 된"EMC 관리자가 LUN을 훔쳐서 문서화되지 않았고 할당되지 않은 것처럼 보였으며 한밤중에 갑자기 오프라인 상태가 된 Oracle 데이터베이스로 페이징되었습니다. 그는 관련없는 앱의 다른 볼륨에 대해 LUN을 다시 프로비저닝했습니다. 그 이후로 나는 문서화에 대한 편집증이다.
2. 디스크를 과다 프로비저닝합니다. 플래터를 사용하면 저속 실린더의 데이터를 차단하고 SSD를 사용하면 수명 / MTBF가 연장됩니다.