/usrCD의 Linux 및 FreeBSD 배포판을 알고 있기 때문에 저는 , /var, /opt등과 같은 각 디렉토리에 자체 파티션을 제공하면서 자랐습니다 . 신성한 규칙 중 하나는 /전체 실행을 방지해야 한다는 것이었습니다.
/tmp요즘에는 루트 파티션에 또는 /var가 있고 하나의 응용 프로그램이 사용 가능한 전체 공간(예: 아래 /opt또는 ) 을 차지하여 시스템이 실패하는 시스템을 매우 자주 봅니다 /tmp.
그렇다면 많은 관리자가 파티셔닝에 대한 보다 정교한 접근 방식 대신 하나의 파티션만 사용하는 이유는 무엇입니까? 내가 지난 10년 동안 뭔가를 놓쳤던 걸까?
답변1
단순 파티셔닝은 많은 환경에서 기본값입니다. 많은 클라우드에서 널리 사용되는 OS 이미지, 설치 프로그램의 기본 파티션 구성표는 하나의 디스크를 찾는 자동화를 단순화합니다. 잘 작동하고, 디스크는 온라인에서 엄청난 크기로 확장될 수 있으며, cloud-init는 파일 시스템을 확장합니다.
지저분해질 때까지. 때때로 사람들은 /가 완전히 꽉 차서 인스턴스가 실패하는 서버 오류 문제를 가져옵니다. 로그 파일 제거와 같은 일반적인 작업 후에는 /의 크기를 줄이고 이러한 일이 다시 발생하지 않도록 방지하는 방법을 궁금해하게 됩니다. 까다롭고 재파티셔닝은 실제로 온라인으로 수행할 수 없습니다. 파일 시스템을 줄이려면 반드시 마운트 해제가 필요하므로 복구 환경을 부팅해야 하며 Linux XFS는 어쨌든 줄일 수 없습니다.
제가 이상적인 Linux 스토리지 설정은 부팅 및 OS를 위한 작은 디스크와 애플리케이션 스토리지를 위한 별도의 디스크입니다. 모두 LVM이며 향후 요구 사항을 위해 VG에 여유 공간을 남겨 둡니다. 예를 들어, 데이터베이스 서버의 경우 /dev/sda1에서 부팅하지만 /var/lib/pgsql/의 데이터는 PV /dev/sdb의 다른 VG에 저장됩니다. 이와 같은 구성표를 사용하면 데이터와 OS를 별도로 복원할 수 있으며 새 VM 인스턴스를 생성하지만 동일한 데이터 볼륨으로 이동하는 것과 같은 깔끔한 트릭을 사용할 수 있습니다. 많은 상태가 없는 간단한 애플리케이션 인스턴스에는 너무 복잡할 수 있으므로 스토리지 요구 사항도 간단합니다. 하지만 여전히 가능합니다.
답변2
나는 또한 당신이 언급한 경향을 발견했지만, 대답은 독선적일 것입니다.
과거에는 물리적 디스크가 있는 물리적 머신이 있었습니다. 변경하기가 어려웠고 가동 중지 시간이 필요했습니다. 요즘에는 논리 볼륨 관리자와 가상 머신 덕분에 디스크를 확장하는 것이 매우 쉽습니다.
- 서버 시스템에서 사용되는 모든 파일 시스템은 실시간 확장을 지원합니다.
- RAID 구성은 연결된 시스템에 투명하며 스토리지에 배열됩니다.
- 가상 머신에는 쉽게 확장할 수 있는 가상 디스크가 있습니다.
- 스토리지 시스템에 연결된 물리적 서버에서는 본질적으로 가상 디스크가 제공됩니다.
따라서 많은 관리자는 더 간단한(또는 단순한!) 설정, 단일 파티션 시스템(또는 두 개의 파티션, 데이터만 분리)을 선택하고 모니터링 도구를 사용하여 쉽게 확장할 수 있는 여유 공간이 부족함을 알립니다.
답변3
그 이유 중 하나는 요즘에는 파티션을 다시 포맷하지 않고도 OS 버전을 쉽게 업그레이드할 수 있기 때문일 수 있습니다.
나는 여전히 /home에 대한 전용 파티션을 생성하지만 아마도 더 이상 실제적인 이유는 없을 것입니다.
답변4
"단순함을 유지하라"는 것은 매우 일반적인 디자인 원칙입니다. 오늘날의 VM은 몇 년 전의 물리적 서버와 달리 확장이 쉽습니다.